Bug#796806: fix pending upload

[Martín Ferrari]

So, I can reliably reproduce this if I run the build with nice and have
some processes eating the cpu away. I have added the information to the
upstream bug, but in the meantime I am uploading a new release that just
disables these tests.


-- 
Martín Ferrari (Tincho)

Bug#797560: diffoscope: option to treat absent files as empty

[Jérémy Bobbio]

Control: tag -1 + pending

Jakub Wilk:
> I'd like an option for treating absent files as if they were empty, similar
> to "diff -N".

This has not been easy, but this will be in the next release
(--new-file is the switch).

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#757829: ITP: docker-registry -- the Docker toolset to pack, ship, store, and deliver content

[Tianon Gravi]

retitle 757829 ITP: docker-registry -- the Docker toolset to pack,
ship, store, and deliver content
owner 757829 !
thanks

I'm going to package this up now. :)  It's since been re-written in Go
with a new protocol, and lives in
https://github.com/docker/distribution, which is currently pulled in
as part of Docker's source, so I'm going to split that out too (and
add a proper dependency instead).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#797855: spice-gtk:spice-common/common/generated_* not reliably generated from source

[Liang Guo]

Hi, Chris,

On Thu, Sep 3, 2015 at 3:00 PM, Chris Lamb  wrote:
> Hi Liang,
>
>> I cannot reproduce this error on my build environment. it looks this
>> is caused by lack dependency on python-six module.
>
> Not completely. Please re-read my initial bug report:
>
>> > Depending on the timezone of the build system, the package may FTBFS as
>> > the `spice-common/python_modules/codegen.py` tool used to regenerate
>> > these files requires python-six which is not included in the
>> > Build-Depends.
>> >
>> > (ie. I don't believe simply including python-six as a build-dependency
>> > entirely resolves the issue)
>
> If any of that is unclear, please let me know and I will try and
> rephrase it.
>
> Just as a summary, adding python-six is not complete fix - your package
> would still not being built from the generated sources.
>

spice_codegen.py is called in your build procedure, but not in mine.
even I build
with a brand new pbuilder environment.  with following command line:

TZ=/usr/share/zoneinfo/Etc/GMT-14 pbuilder build spice-gtk_0.29-1.dsc

Do you know the reason?

I remove spice-common/common/generated* to force build system regenerate
these files, the generated files are same with the original file.

Would you like show me the build log with python-six on Build-deps ?

Thanks,
-- 
Liang Guo

Bug#797787: [uscan] manpage updates

[Osamu Aoki]

Hi,

I have updated the manpage patch series.

This includes build system update for po4a.

This one includes a fix to the pending manpage issue to documemt the new
filename scheme for http://site/?.  Closes: #573631

I also included tested version of pagemangle rule with test code ;-)
 * generic way to mangle the whole web page.
 * s3.amazonaws.com special case code is marked deprecated.
 * address needs for fullsourcemangle.  Closes: #395439
 * text in ... is a special case.  Closes: #705989
 * s/data-realurl/href/g is a special case.  Closes: #773390

Quite frankly, I almost feel like asking you to remove the
s3.amazonaws.com specific code.  This kind of thing should not be hard
coded into generic code.  I only made them to warn user for now.
(I do not think we have use case yet for this pattern anyway.)

The last patch is for better DEBUG mode.

Please also do not forget to apply
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796986
 uscan: repacksuffix does not adjust version passed to uupdate
You can not add suffix earlier ssince mk-origtargz behavior is not
deterministic.

Once all these are applied, I will touch packaging of multitarballs

Osamu
From b2d8128f499d2be342618243104ac71c7c24d036 Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Tue, 1 Sep 2015 13:19:31 +
Subject: [PATCH 1/8] Add POD to uscan.pl

 * Newly formatted manpage by POD.  Closes: #797787
---
 scripts/uscan.pl | 965 +++
 1 file changed, 965 insertions(+)
 mode change 100755 => 100644 scripts/uscan.pl

diff --git a/scripts/uscan.pl b/scripts/uscan.pl
old mode 100755
new mode 100644
index 33f3ad4..20ef97f
--- a/scripts/uscan.pl
+++ b/scripts/uscan.pl
@@ -22,6 +22,971 @@
 # You should have received a copy of the GNU General Public License
 # along with this program. If not, see .
 
+=pod
+
+=head1 NAME
+
+uscan - scan/watch upstream sources for new releases of software
+
+=head1 SYNOPSIS
+
+B [I] [I]
+
+=head1 DESCRIPTION
+
+For the basic usage, B is executed without any arguments from the root
+of the Debianized source tree where you see the F directory.
+Then typically the following happens:
+
+=over
+
+=item * B downloads the upstream tarball with the highest version from
+the remote URL specified in F
+
+=item * B reads the first entry in F to determine the
+source package name I and the last upstream version. 
+
+=item * B saves the downloaded tarball to the parent B<../> directory:
+I<< ../-.tar.gz >>
+
+=item * B invokes B to create the source tarball: I<<
+../_.orig.tar.gz >>
+
+=item * B invokes B to create the Debianized source tree: I<<
+../-/* >>
+
+=back
+
+Here, B allows extensive flexibility.  The upstream tarball in he remote
+URL can be F, the downloaded
+tarball can be F<../foo-1.0.tar.gz>, the source tarball can be
+F<../bar_2.1.0.orig.tar.gz>, and the Debianized source tree can be located at
+F<../bar-2.1.0>.
+
+Note: For simplicity, the compression method used in examples is B with
+B<.gz> suffix.  Other methods such as B, B, and B may also be
+used.
+
+=head1 FORMAT OF THE WATCH FILE
+
+The current version 3 format of F can be summarized as follows:
+
+=over
+
+=item * Leading spaces and tabs are dropped.
+
+=item * Empty lines are dropped. 
+
+=item * A line started by B<#> (hash) is a comment line and dropped.
+
+=item * Single B<\> (back slash) at the end of a line is dropped and the the
+next line is concatenated after removing leading spaces and tabs.
+
+=item * The first non-comment line is:
+
+=over
+
+=item 

Bug#797908: ITP: drf-fsm-transitions -- Django-FSM transitions for Django REST Framework

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: drf-fsm-transitions
  Version : 0.2.0
  Upstream Author : Jacob Haslehurst 
* URL : https://github.com/hzy/drf-fsm-transitions
* License : Expat
  Programming Lang: Python
  Description : Django-FSM transitions for Django REST Framework

 Automatically hook your Django-FSM transitions up to Django REST Framework by
 using the provided viewset mixin. Each transition will be made available
 through its name in the object URL and can be called using POST.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJV6F7WAAoJEGlMre9Rx7W2XvYP/1mmc8twZc9jHXSgOCAgXB6k
7yKsbkycuDaPmpEV+NzV0RPyYxIQEu1BvX4+FGrEX0EyZe7Bmwz3oM8n8FeMJHyP
wZ4VoF/gahhGQSz70/i7J74XyYWyygFGsIwFTspmNWJyudVcyqpJu74n3TBQuKkm
pqp4mgFgAivnOJu9FgaxFyg5rt53OMgQKvtK4bYSQ2e3EeE+dKa36zHd5E1CPJ96
kbGk3GFP2ULSn4Ela3a+x/YnSPRPRW8E2b2M/TbtQUQtO7vVAAQtR07gbBROLZ/6
pZ1Jjc3poKfcAGz4hvcKxSQ7iLxTtCrP1cI/hjqUP+Wv+utTiumjXpGz634jWmRe
XhMhLQYejcxsYIIy7pfJzGSnViQ2syiHqayA7eFHltrI//9f7kNqyAboRk9WYp3W
ct68VL/a27CXXMTHTAoNrLv7w6KWO1av5EUoD3K7A/72ob1tbwKm5X74AkdKaFfL
uPjPE6KHsDzFUcVIS2q96EKDRtdusyFqTNE7Ew9NHeMzG2G0Zu7I6ve8MIHsdF+m
SJqcqVxKjrvEdgdeFRgJKe4n6gxwT/FwGmdruHkMjyNYu3TaA4k3Zv0vGVXFVddh
/iVaxSD5dt+nNFc9363lEXnAf5PXmiFMm6Wg5fEZ5bzcgL0U/nGquIUB4RCGMtAr
4+SC2Q01X1cMoxMx8CDL
=OTlU
-END PGP SIGNATURE-

Bug#766679: ITP: fdkaac -- command line encoder frontend for libfdk-aac

[Fabian Greffrath]

Am Donnerstag, den 03.09.2015, 16:24 +0300 schrieb Marius Gavrilescu:
> Yes, it outputs M4A by default, but it can also output ADIF, ADTS, 
> LATM, LOAS. It does not seem to be able to output raw AAC (that is, 
> ADIF without the header). Not sure how useful that would be.

Pretty useless, that's why I was asking. ;) I am not sure ATM what
format faac outputs if built without mp4v2 support, though.

Regarding M4A format, did you write this part yourself or have you
taken code from another library?

 - Fabian


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

Bug#797899: gpsd: New upstream release available: 3.15

[Raphaël Hertzog]

Source: gpsd
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

Hello,

There's a new upstream release available (3.15). Can you package it
and coordinate its upload to unstable? (I saw that the experimental
version already has a SONAME change so a library transition is required)

FTR, I'm just forwarding this request from a Kali user:
https://bugs.kali.org/view.php?id=2196

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

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

Bug#797909: ITP: django-downloadview -- efficient static file serving with Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: django-downloadview
  Version : 1.8
  Upstream Author : Benoît Bryon 
* URL : https://github.com/fladi/django-downloadview
* License : BSD-3-clause
  Programming Lang: Python
  Description : efficient static file serving with Django

 django-downloadview makes it easy to serve files with Django:
 .
  * manage files with Django (permissions, filters, generation, ...);
  * files are stored somewhere or generated somehow (local filesystem,
remote storage, memory...);
  * django-downloadview helps to stream the files with very little
code;
  * django-downloadview helps to improve performances with reverse
proxies, via mechanisms such as Nginx’s X-Accel or Apache’s
X-Sendfile.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJV6GAMAAoJEGlMre9Rx7W2fIYP/3mV/bB6l4Nb5R3KEgWXjtkm
1Wq+vznWND/odlzK2ElFonrBROnDa7EtoYOT138bDjMcGztdho34KaYbLFODykxk
MDZ4at4mQKwuXqg9cjquYx5iwX2AMDUjuLqUcRn4o7hiRki9pqAvhakPFyfs6gjV
zW6KZU9jlMvckmbkMWWugXq923zsJSXi7foHlwRigQuXCEq0qp91tXTCgWK7p1eq
a/ve4PCxkjFmADp0WTFqyCcm1xqLOICFKjtQefxAsOsoZ40qyII/qQyIegYkhNrm
iA9zzGhxJOKqZAyg4Hp1TDlSMyF8eh395pYCfReu9m+sjwCDynRDJxAT/ysLHPTY
78zEA0jgO7wdK8ngam238OlzAz7td0EG9e/dlIiv9nGnfvSz7jWk1UITRqgE2I/S
I4yOrgDlNTEWWVQ7vckQkkpyi5+d1LREe/WdX9dnxrMFdXitTjNuQ/uzFVZ5a4nX
4sOFUmYd9Hj12zY6BwCihDm5A80lcIjkKCB4XM6sfuWH8gJmXvQYploVFxCDc8Kx
DlmzCHrhOXxMBy6odKyUFdM0zEGxCf1JHh9GCHGxnYL6s9ftX0HQgeAJetV4dAr1
n2asJ2q5y/u9RKPfpvK9yUP3nDnmTDEFMGza74Rl35cuB7iXKBSNzN1t1drA5wnb
S2w8bybnwXNTuD/3Y6GC
=rEvl
-END PGP SIGNATURE-

Bug#766977: elasticsearch not starting

[Rémi Cardona]

On Thu, 16 Jul 2015 11:38:05 -0700 "Nathan D. Smith" 
 wrote:

Any progress on this?

I have the same issues as described above in Jessie. systemctl is
incorrect about the startup state, and it does not run.


I had to edit /etc/default/elasticsearch and uncomment 
START_DAEMON=true. systemctl stop + start and it runs.


However the fact remains, systemd is confusingly reporting ES as being 
started when it is not. IMHO, that's an issue.


AFAICT, most daemon packages in Debian actually start said daemon by 
default. I think the "default" file should just ship with START_DAEMON=true.


Cheers,

Rémi

Bug#797913: Gimp doesn't appear in the list of all applications

[Ben Hutchings]

Package: gnome-shell
Version: 3.14.4-1~deb8u1
Severity: normal

The icon for Gimp is not included in the list of all applications on
the Activities screen.

On a different system running unstable (gnome-shell 3.16.3-1), Gimp
does appear.

Both systems have gimp 2.8.14-1+b1.

Ben.

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-back  0.22.0-1
ii  evolution-data-server3.12.9~git20141128.5242b0-2+deb8u2
ii  gir1.2-accountsservice-1.0   0.6.37-3+b1
ii  gir1.2-atspi-2.0 2.14.0-1
ii  gir1.2-caribou-1.0   0.4.15-1
ii  gir1.2-clutter-1.0   1.20.0-1
ii  gir1.2-freedesktop   1.42.0-2.2
ii  gir1.2-gcr-3 3.14.0-2
ii  gir1.2-gdesktopenums-3.0 3.14.1-1
ii  gir1.2-gdm3  3.14.1-7
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.42.0-2.2
ii  gir1.2-gnomebluetooth-1.03.14.0-2
ii  gir1.2-gnomedesktop-3.0  3.14.1-1
ii  gir1.2-gtk-3.0   3.14.5-1
ii  gir1.2-ibus-1.0  1.5.9-1
ii  gir1.2-mutter-3.03.14.4-1~deb8u1
ii  gir1.2-networkmanager-1.00.9.10.0-7
ii  gir1.2-nmgtk-1.0 0.9.10.0-2
ii  gir1.2-pango-1.0 1.36.8-3
ii  gir1.2-polkit-1.00.105-8
ii  gir1.2-soup-2.4  2.48.0-1
ii  gir1.2-telepathyglib-0.120.24.1-1
ii  gir1.2-telepathylogger-0.2   0.8.1-1
ii  gir1.2-upowerglib-1.00.99.1-3.2
ii  gjs  1.42.0-1
ii  gnome-backgrounds3.14.1-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.14.2-3
ii  gnome-shell-common   3.14.4-1~deb8u1
ii  gnome-themes-standard3.14.2.2-1
ii  gsettings-desktop-schemas3.14.1-1
ii  libatk-bridge2.0-0   2.14.0-2
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18
ii  libcairo21.14.0-2.1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.20.0-1
ii  libcogl-pango20  1.18.2-3
ii  libcogl201.18.2-3
ii  libcroco30.6.8-3+b1
ii  libdbus-glib-1-2 0.102-1
ii  libecal-1.2-16   3.12.9~git20141128.5242b0-2+deb8u2
ii  libedataserver-1.2-183.12.9~git20141128.5242b0-2+deb8u2
ii  libgcr-base-3-1  3.14.0-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libgirepository-1.0-11.42.0-2.2
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.42.0-1
ii  libglib2.0-0 2.42.1-1
ii  libgstreamer1.0-01.4.4-2
ii  libgtk-3-0   3.14.5-1
ii  libical1a1.0-1.3
ii  libjson-glib-1.0-0   1.0.2-1
ii  libmozjs-24-024.2.0-2
ii  libmutter0e  3.14.4-1~deb8u1
ii  libnm-glib4  0.9.10.0-7
ii  libnm-util2  0.9.10.0-7
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpolkit-agent-1-0  0.105-8
ii  libpolkit-gobject-1-00.105-8
ii  libpulse-mainloop-glib0  5.0-13
ii  libpulse05.0-13
ii  libsecret-1-00.18-1+b1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  215-17+deb8u1
ii  libtelepathy-glib0   0.24.1-1
ii  libx11-6 2:1.6.2-3
ii  libxfixes3   1:5.0.1-2+b2
ii  mutter   3.14.4-1~deb8u1
ii  python   2.7.9-1
ii  telepathy-mission-control-5  1:5.16.3-1

Versions of packages gnome-shell recommends:
ii  gdm3  3.14.1-7
ii  gkbd-capplet  3.6.0-1
ii  gnome-contacts3.14.1-1
ii  gnome-control-center  1:3.14.2-3
ii  gnome-user-guide  3.14.1-1
ii  unzip  

Bug#726820: i Would like to package your script

[Javier Fafián Álvarez]

I am learning to package, os i would like to package your scrip. I have
almost packaged you script version 1.02 -last release in github tags- If
you want to release 1.03 i will package it.

I think i have to find a place to upload the sources of the package so you
can check it.

Anyway if you want it, just let me know.



-- Greetings

Bug#495326: aptitude: Misleading description of purge

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Thanks for the pointer.  It will be fixed in the next upload.


-- 
Manuel A. Fernandez Montecelo 

Bug#776096: bsdmainutils: hexdump fails if format_string contains backslash

[Rémi Rampin]

This is a neat workaround, but I really wouldn't say that "it works".

Bug#797904: debhelper manpage: #DEBHELPER# in Perl: bad error handling

[Jakub Wilk]

Package: debhelper
Version: 9.20150811
Severity: minor

debhelper manpage includes this example of how to embed #DEBHELPER# in 
Perl code:


   my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
   #DEBHELPER#
   EOF
   system ($temp) / 256 == 0
 or die "Problem with debhelper scripts: $!";

The division by 256 is useless. But more importantly, it will almost 
always give you incorrect error message if the embedded script fails. 
This is because system() does not set $! if the program exits normally 
with non-zero exit status.


--
Jakub Wilk

Bug#797907: k4dirstat segfaults on start

[Marcin Kucharczyk]

Package: k4dirstat
Version: 3.1-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Starting k4dirstat

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

Run k4dirstat

   * What was the outcome of this action?

k4dirstat 
QObject::connect: Cannot connect (null)::clientAdded(KXMLGUIClient*) to 
KDEPrivate::ToolBarHandler::clientAdded(KXMLGUIClient*)
Segmentation fault


(gdb) r
Starting program: /usr/bin/k4dirstat 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe887c700 (LWP 6736)]
QObject::connect: Cannot connect (null)::clientAdded(KXMLGUIClient*) to 
KDEPrivate::ToolBarHandler::clientAdded(KXMLGUIClient*)

Program received signal SIGSEGV, Segmentation fault.
0x77b91fda in KXMLGUIFactory::removeClient(KXMLGUIClient*) () from 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
(gdb) bt
#0  0x77b91fda in KXMLGUIFactory::removeClient(KXMLGUIClient*) () from 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#1  0x77b9f5f9 in KXmlGuiWindow::createGUI(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#2  0x77ba0c8b in KXmlGuiWindow::setupGUI(QSize const&, 
QFlags, QString const&) () from 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#3  0x77ba0da2 in 
KXmlGuiWindow::setupGUI(QFlags, QString 
const&) () from /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#4  0x0042ef6b in k4dirstat::k4dirstat() ()
#5  0x004296ec in main ()
(gdb) 


   * What outcome did you expect instead?

Normal k4dirstat run


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

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

Versions of packages k4dirstat depends on:
ii  libc6 2.19-19
ii  libkf5configcore5 5.13.0-1
ii  libkf5configgui5  5.13.0-1
ii  libkf5configwidgets5  5.13.0-2
ii  libkf5coreaddons5 5.13.0-1
ii  libkf5i18n5   5.13.0-1
ii  libkf5iconthemes5 5.13.0-1
ii  libkf5jobwidgets5 5.13.0-1
ii  libkf5kiocore55.13.0-1
ii  libkf5kiowidgets5 5.13.0-1
ii  libkf5widgetsaddons5  5.13.0-1
ii  libkf5xmlgui5 5.13.0-1
ii  libqt5core5a  5.4.2+dfsg-9
ii  libqt5gui55.4.2+dfsg-9
ii  libqt5widgets55.4.2+dfsg-9
ii  libstdc++65.2.1-15
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages k4dirstat recommends:
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

k4dirstat suggests no packages.

-- no debconf information

Bug#797911: xfce4-terminal: x-terminal-emulator.1.gz alternative is not being installed

[Jayson Willson]

Package: xfce4-terminal
Version: 0.6.3-1+b1
Severity: normal

x-terminal-emulator.1.gz alternative is not being installed, because in fact
xfce4-terminal is NOT provider of x-terminal-emulator, but
xfce4-terminal.wrapper is, and xfce4-terminal.wrapper does not have
corresponding manpage file. Thus "man x-terminal-emulator" does not work with
xfce4-terminal.wrapper being x-terminal-emulator provider.



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

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

Versions of packages xfce4-terminal depends on:
ii  exo-utils   0.10.2-4
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u2
ii  libglib2.0-02.42.1-1
ii  libgtk2.0-0 2.24.25-3
ii  libpango-1.0-0  1.36.8-3
ii  libvte9 1:0.28.2-5
ii  libx11-62:1.6.2-3
ii  libxfce4ui-1-0  4.10.0-6
ii  libxfce4util6   4.10.1-2

Versions of packages xfce4-terminal recommends:
ii  dbus-x11  1.8.18-0+deb8u1

xfce4-terminal suggests no packages.

-- no debconf information

Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'

[Scott Kitterman]

On Tue, 1 Sep 2015 09:45:33 +0100 Simon McVittie  wrote:
> On Tue, 01 Sep 2015 at 09:20:17 +0100, Simon McVittie wrote:
> > If a particular -dev package requires linking with some other library,
> > it should depend on that library's -dev package (the same principle
> > as depending on the -dev packages of the libraries mentioned in a
> > pkg-config .pc file).
> 
> For kopete, installing libsoprano-dev is enough to build successfully.
> I think this means kdelibs5-dev should depend on libsoprano-dev (and the
> -dev packages for any other libraries that it indirectly requires
> in the same way).
> 
> Adding Build-Depends: libsoprano-dev to kopete seems to be a viable
> workaround that would prevent this bug from stalling the libmsn
> sub-transition within the libstdc++ transition, and potentially
> lower its severity to non-RC. I might NMU kopete with that change if
> it becomes necessary.

This was unfortunately necessary as part of the transition from nepomuk to the 
new baloo package.  At the time upstream did the switch, it was not well 
integrated into KDE4 and so we were stuck with dropping some build-depends to 
get the necessary internal build behavior.  As a team, in the Qt-KDE team 
we've been adding libsoprano-dev to other packages as needed and that's the 
right thing to do for kopete.

Scott K

Bug#732362: vtk 5.10 is coming to unstable soon (TM)

[Gianfranco Costamagna]

Hi, since vtk had to be renamed, and since I did clean it up and upload on 
experimental a loong time ago, I would like
to keep the possibility of the gcc-5 transition rebuilds to push 5.10 on 
unstable soon.

It should just be a matter of binNMUing the depending packages, so I guess this 
one won't be so painful,
now that vtk5.10 is fixed, and many packages switched already to vtk6.

Please tell me if somebody is against this move.

cheers,

G.

Bug#793503: lintian: Please warn on obsolete URLs

[Axel Beckert]

Hi Jakub,

Jakub Wilk wrote:
> * Axel Beckert , 2015-09-02, 22:21:
> ># Known obsolete websites / hosters who closed down or have frozen
> ># content, one hostname per line. Subdomains will be matched, too.
> >
> >code.google.com
> 
> $PROJECT.googlecode.com redirects to code.google.com/p/$PROJECT/, so
> you should probably add "googlecode.com", too.

Thanks for that hint! Will add it.

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

Bug#797912: ITP: node-punycode -- A robust Punycode converter fully RFC compliant

[Bastien ROUCARIES]

Package: wnpp
Owner: "Bastien Roucariès" 
Severity: wishlist

* Package name: node-punycode
  Version : 1.3.2
  Upstream Author : Mathias Bynens
* URL : https://mths.be/punycode
* License : Expat
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : A robust Punycode converter fully RFC compliant

Needed for a dep of browserify, needed in turn for a dep of grunt

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[Gianfranco Costamagna]

Hi Lumin,





Can you please start by fixing the lintian warnings on mentors page?

thanks :)

G.

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[Gianfranco Costamagna]

Hi,

control:

libboost-all-dev (>= 1.55) | libboost1.55-all-dev (>= 1.55),


what is the rationale for that? I guess libboost-all-dev is already enough...

Multi-Arch: no


isn't that the default?

"Pre-Depends: ${misc:Pre-Depends}"

this should be useless


rules:
--builddirectory=
can be passed also in dh call, making useless everywhere


"fakeroot dh binary"

well, I usually don't like such hacks in rules file :)


CUSTOM_JOBS   := "-j4"

well mips porters might hate you for this!


isn't something like
override_dh_auto_build:
dh_auto_configure flags-build1
dh_auto_build -O--parallel --builddirectory=build1
dh_auto_configure flags-build2
dh_auto_build -O--parallel --builddirectory=build2

not good for your purpose?


cheers,

G.

Bug#787423: Excuse me for the noise: 4.46.0-1+debu8u1

[Osamu Aoki]

Hi
On Thu, Sep 03, 2015 at 09:23:00PM +0900, Osamu Aoki wrote:
> This version 4.46.0-1+debu8u1 had typo. s/debu/deb/  Just after I

Excuse me for the noise.  I got a nice auto-REJECT :-) 

 getmail4 - incorrect version number; RoM

No wonder I could not erase...

Thanks.

Osamu

Bug#797910: Fwd: [ITP] RFS: node-jsonparse/1.0.0-1

[Bastien ROUCARIES]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "node-jsonparse"

 * Package name: node-jsonparse
   Version : 1.0.0-1
   Upstream author: jsonparse
   URL: https://github.com/creationix/jsonparse
* License : Expat
   Section : web

  It builds those binary packages:

node-jsonparse - Pure javascript JSON streaming parser for node.js

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

  http://mentors.debian.net/package/node-jsonparse

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

dget -x 
http://mentors.debian.net/debian/pool/main/n/node-jsonparse/node-jsonparse_1.0.0-1.dsc

Needed for browserify in turn needed to build a reverse dep of grunt

Bug#776096: bsdmainutils: hexdump fails if format_string contains backslash

[Sergey Romanov]

Actually, it works. Try
$ echo hello|hexdump -ve '"\\" /1 "x%02X"';printf \\n
\x68\x65\x6C\x6C\x6F\x0A

Bug#797838: faac: build with mp4v2

[Christoph Anton Mitterer]

One idea perhaps:

Could one fulfil the license if the lib was dynamically loaded?

I think about something what e.g. gtkpod does (which is, AFAICS als
gpl2 and still uses  libmp4v2)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#797525: [Reproducible-builds] Bug#797525: diffoscope: multiarch mode

[Jérémy Bobbio]

Control: retitle -1 diffoscope: provide a way to ignore all differences in 
control.tar

Jérémy Bobbio:
> Jakub Wilk:
> > I want to use diffoscope to compare two "Multi-Arch: same" debs of the same
> > version but different architecture, to see differences that will cause
> > co-installation conflicts.
> >
> > This almost works currently, but there's a bit of noise that could be
> > avoided. I'd like an option that does the following:
> > - Ignores all differences in control.tar.
>
> I had already in mind to provide pluggable ignore modules. So having
> support for this use case is on my personal roadmap.

Let's retitle this bug accordingly.

> > - Disables fuzzy matching.
> 
> That will be a separate option.

Pending upload, this will be doable with `--fuzzy-threshold=0`.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#786031: doxypy: diff for NMU version 0.4.2-1.1

[Graham Inggs]

Control: tags 786031 + patch
Control: tags 786031 + pending

Dear maintainer,

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

Regards.
diff -u doxypy-0.4.2/debian/control doxypy-0.4.2/debian/control
--- doxypy-0.4.2/debian/control
+++ doxypy-0.4.2/debian/control
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: David Paleino 
 Build-Depends: debhelper (>= 7.0.50~),
- python-support (>= 0.90.0~)
+ dh-python,
+ python-all
 Standards-Version: 3.8.3
 Homepage: http://code.foosel.org/doxypy
 Vcs-Git: git://git.debian.org/git/collab-maint/doxypy.git
diff -u doxypy-0.4.2/debian/rules doxypy-0.4.2/debian/rules
--- doxypy-0.4.2/debian/rules
+++ doxypy-0.4.2/debian/rules
@@ -13 +13 @@
-   dh  $@
+   dh  $@  --with python2
diff -u doxypy-0.4.2/debian/changelog doxypy-0.4.2/debian/changelog
--- doxypy-0.4.2/debian/changelog
+++ doxypy-0.4.2/debian/changelog
@@ -1,3 +1,10 @@
+doxypy (0.4.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Transition from python-support to dh-python (Closes: #786031)
+
+ -- Graham Inggs   Thu, 03 Sep 2015 16:58:25 +0200
+
 doxypy (0.4.2-1) unstable; urgency=low

   * Initial release (Closes: #565601)

Bug#788364: libmagic1: misdetect some Coreboot images as text

[Jérémy Bobbio]

retitle 788364 diffoscope: garbled output when comparing some Coreboot images
clone 788364 -1
reassign -1 libmagic1
severity -1 libmagic1 normal
retitle -1 libmagic1: misdetect Coreboot images as text files
thanks

Hi Christoph,

diffoscope is the tool that we have created as part of the “reproducible
builds” effort to understand differences between two builds. We now also
use it to compare builds of Coreboot images.

diffoscope uses libmagic (through its Python bindings) to identify the
format of the files its trying to compare. Some coreboot images are
misdetected as text files which results in garbled diffoscope output.

Proper way to detect Coreboot images is probably to look for a CBFS
header. cbfs_find_header() is how upstream does it:
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=util/cbfstool/cbfs_image.c;h=c40bd6641

I could tell diffoscope to detect Coreboot images with a similar
mechanism but it would probably be better to teach libmagic to do it.
Is that easily doable?

Reiner Herrmann:
> file detects them as plain-text:
> 
> > /tmp/b1_coreboot.rom: ISO-8859 text, with very long lines, with no line 
> > terminators
> > /tmp/b2_coreboot.rom: ISO-8859 text, with very long lines, with no line 
> > terminators
> 
> That's why diffoscope also treats them as text.
> I'm not sure this can/should be fixed inside diffoscope, as we rely on
> libmagic detecting them correctly.

Reiner, I remember you had a look into this during DebConf. Have you
made any progress?

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#797903: RM: golang-mux -- RoM; renamed to golang-github-gorilla-mux

[Tianon Gravi]

Package: ftp.debian.org
Severity: normal

In line with the updated pkg-go policy, golang-mux was renamed to
golang-github-gorilla-mux. :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#797838: faac: build with mp4v2

[Fabian Greffrath]

Am Donnerstag, den 03.09.2015, 16:04 +0200 schrieb Christoph Anton
Mitterer:
> I think about something what e.g. gtkpod does (which is, AFAICS als
> gpl2 and still uses  libmp4v2)

If they get away with it...

 - Fabian


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

Bug#797905: linux-image-3.16.0-4-amd64: TCP slow start very slow in high RTT network

[Kx Mp]

Package: src:linux
Version: 3.16.7-ckt11-1+deb8u3
Severity: normal

Dear Maintainer,

I'm running debian in vmware workstation and using tc to add network
latency.
And I'm running nginx with 100MB file to test network speed.
when I use hybla with 250ms rtt, it takes 16seconds to download 2MB data.
In wheezy it can be finished within 3seconds, and I find that htcp and
cubic is also slower than wheezy release when RTT is high.


-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64
root=UUID=b68c0162-66bf-4482-8ea8-00df5e9f02c1 ro quiet

** Not tainted

** Kernel log:
[2.160540] ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0x1068 irq
15
[2.280625] usb 1-1: New USB device found, idVendor=0e0f, idProduct=0003
[2.280628] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[2.280630] usb 1-1: Product: VMware Virtual USB Mouse
[2.280631] usb 1-1: Manufacturer: VMware
[2.293507] hidraw: raw HID events driver (C) Jiri Kosina
[2.299668] usbcore: registered new interface driver usbhid
[2.299670] usbhid: USB HID core driver
[2.301757] input: VMware VMware Virtual USB Mouse as
/devices/pci:00/:00:11.0/:02:00.0/usb1/1-1/1-1:1.0/0003:0E0F:0003.0001/input/input2
[2.301914] hid-generic 0003:0E0F:0003.0001: input,hidraw0: USB HID
v1.10 Mouse [VMware VMware Virtual USB Mouse] on usb-:02:00.0-1/input0
[2.333568] ata2.00: ATAPI: VMware Virtual IDE CDROM Drive, 0001,
max UDMA/33
[2.350204] ata2.00: configured for UDMA/33
[2.350688] scsi 2:0:0:0: CD-ROMNECVMWar VMware IDE CDR10
1.00 PQ: 0 ANSI: 5
[2.351226] scsi 2:0:0:0: Attached scsi generic sg1 type 5
[2.362429] sr0: scsi3-mmc drive: 1x/1x writer dvd-ram cd/rw xa/form2
cdda tray
[2.362433] cdrom: Uniform CD-ROM driver Revision: 3.20
[2.362808] sr 2:0:0:0: Attached scsi CD-ROM sr0
[2.402059] usb 1-2: new full-speed USB device number 3 using uhci_hcd
[2.545280] usb 1-2: New USB device found, idVendor=0e0f, idProduct=0002
[2.545283] usb 1-2: New USB device strings: Mfr=0, Product=1,
SerialNumber=0
[2.545284] usb 1-2: Product: VMware Virtual USB Hub
[2.553177] hub 1-2:1.0: USB hub found
[2.557359] hub 1-2:1.0: 7 ports detected
[2.624154] EXT4-fs (sda1): mounted filesystem with ordered data mode.
Opts: (null)
[3.951721] systemd[1]: Cannot add dependency job for unit
display-manager.service, ignoring: Unit display-manager.service failed to
load: No such file or directory.
[4.129629] TCP: hybla registered
[4.298036] random: nonblocking pool is initialized
[4.392022] systemd-udevd[147]: starting version 215
[4.770481] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[4.770491] ACPI: Power Button [PWRF]
[4.778803] ACPI: AC Adapter [ACAD] (on-line)
[4.884866] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[4.914723] vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq
16
[4.914822] vmw_vmci :00:07.7: Using capabilities 0xc
[4.915045] vmw_vmci :00:07.7: irq 72 for MSI/MSI-X
[4.915182] vmw_vmci :00:07.7: irq 73 for MSI/MSI-X
[4.919786] Guest personality initialized and is active
[4.919877] VMCI host device registered (name=vmci, major=10, minor=59)
[4.919878] Initialized host personality
[4.954781] piix4_smbus :00:07.3: SMBus Host Controller not enabled!
[4.999180] [drm] Initialized drm 1.1.0 20060810
[5.057330] [drm] DMA map mode: Using physical TTM page addresses.
[5.057439] [drm] Capabilities:
[5.057441] [drm]   Rect copy.
[5.057442] [drm]   Cursor.
[5.057442] [drm]   Cursor bypass.
[5.057443] [drm]   Cursor bypass 2.
[5.057443] [drm]   8bit emulation.
[5.057444] [drm]   Alpha cursor.
[5.057444] [drm]   Extended Fifo.
[5.057445] [drm]   Multimon.
[5.057445] [drm]   Pitchlock.
[5.057446] [drm]   Irq mask.
[5.057446] [drm]   Display Topology.
[5.057447] [drm]   GMR.
[5.057448] [drm]   Traces.
[5.057448] [drm]   GMR2.
[5.057449] [drm]   Screen Object 2.
[5.057449] [drm]   Command Buffers.
[5.057450] [drm]   Command Buffers 2.
[5.057450] [drm]   Guest Backed Resources.
[5.057451] [drm] Max GMR ids is 64
[5.057452] [drm] Max number of GMR pages is 65536
[5.057453] [drm] Max dedicated hypervisor surface memory is 0 kiB
[5.057453] [drm] Maximum display memory size is 32768 kiB
[5.057454] [drm] VRAM at 0xe800 size is 32768 kiB
[5.057455] [drm] MMIO at 0xfe00 size is 256 kiB
[5.057457] [drm] global init.
[5.072183] [TTM] Zone  kernel: Available graphics memory: 181744 kiB
[5.072186] [TTM] Initializing pool allocator
[5.072191] [TTM] Initializing DMA pool allocator
[5.072595] [drm] Supports vblank timestamp 

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

Hi Gianfranco Costamagna,

On Thu, 2015-09-03 at 13:41 +, Gianfranco Costamagna wrote:

> Can you please start by fixing the lintian warnings on mentors page?

Now caffe is lintian clean.
and I've stripped some lines in dch.

Please have a look at it. :-)

Thanks.

http://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_0.~rc2+git20150902+e8e660d3-1.dsc


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

Bug#766679: ITP: fdkaac -- command line encoder frontend for libfdk-aac

[Fabian Greffrath]

Am Donnerstag, den 03.09.2015, 16:48 +0300 schrieb Marius Gavrilescu:
> Looking at the code, src/m4af.{c,h} handles the M4A format. I find no
> mention of m4af.c or m4af_create on the web except for fdkaac, so I
> assume it was written by nu774.

Thank you for your answers!

BTW, faac only outputs ADTS if built without MP4 support, i.e. in
Debian.

 - Fabian


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

Bug#766679: ITP: fdkaac -- command line encoder frontend for libfdk-aac

[Marius Gavrilescu]

Fabian Greffrath  writes:

> Thank you for your answers!

You're welcome.
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Bug#252166: re-submitting #215245

[Sergey Romanov]

A simple workaround would be to use %x instead of "%e %B %Y". I also
was considering using %Ex, but found out that its output doesn't
differ from %x in all locales I tried (en_US.UTF-8, de_DE.UTF-8,
ru_RU.UTF-8).

The attached patch should be applied after ncal_options.diff in quilt series.

$ LC_ALL=en_US.UTF-8 ncal -e
April  5 2015  # right

$ LC_ALL=de_DE.UTF-8 ncal -e
 5 April 2015  # wrong: lacks the ordinal dot, should be: 5. April 2015

$ LC_ALL=ru_RU.UTF-8 ncal -e
 5 Апрель 2015  # wrong, should be: 5 апреля 2015

With the patch applied,
$ LC_ALL=en_US.UTF-8 ./ncal -e
04/05/2015

$ LC_ALL=de_DE.UTF-8 ./ncal -e
05.04.2015

$ LC_ALL=ru_RU.UTF-8 ./ncal -e
05.04.2015
Description: Display Easter date according to locale rules
 Use the %x strftime format instead of ad-hoc "%e %B %Y" and "%B %e %Y"
Author: Sergey Romanov 
Bug-Debian: https://bugs.debian.org/252166
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/usr.bin/ncal/ncal.c
+++ b/usr.bin/ncal/ncal.c
@@ -587,20 +587,6 @@ printeaster(int y, int julian, int ortho
datedt;
struct tm tm;
charbuf[MAX_WIDTH];
-#ifndef D_MD_ORDER
-   static int d_first = -1; /* XXX */
-   char * str = nl_langinfo(D_FMT);
-
-   if (d_first < 0) {
-   for (; *str && *str != 'd' && *str != 'm'; str++);
-   d_first = (*str == 'm') ? 0 : 1;
-   }
-#else
-   static int d_first = -1;
-
-   if (d_first < 0)
-   d_first = (*nl_langinfo(D_MD_ORDER) == 'd');
-#endif
/* force orthodox easter for years before 1583 */
if (y < 1583)
orthodox = 1;
@@ -617,7 +603,7 @@ printeaster(int y, int julian, int ortho
tm.tm_year = dt.y - 1900;
tm.tm_mon  = dt.m - 1;
tm.tm_mday = dt.d;
-   strftime(buf, sizeof(buf), d_first ? "%e %B %Y" : "%B %e %Y",  );
+   strftime(buf, sizeof(buf), "%x",  );
wprintf(L"%s\n", buf);
 }
 

Bug#766679: ITP: fdkaac -- command line encoder frontend for libfdk-aac

[Marius Gavrilescu]

Fabian Greffrath  writes:

> Regarding M4A format, did you write this part yourself or have you
> taken code from another library?

I just packaged fdkaac. It was developed by nu774 on github.

Looking at the code, src/m4af.{c,h} handles the M4A format. I find no
mention of m4af.c or m4af_create on the web except for fdkaac, so I
assume it was written by nu774.
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Bug#797901: lynx: No client certificate support

[Simon Kainz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: lynx
Version: 2.8.9dev6-3
Tags: patch
Control: block -1 by 797059
X-Debbugs-CC: debian-accessibil...@lists.debian.org

Dear Maintainer,

lynx has currently no support for client certificates, which, due to
the recent introduction of client certificate usage for Debian SSO,
renders websites protected by this system unusable for lynx users.

The attached patch adds the following features to lynx:

* Support for 1 client certificate and 1 key file
* Configurable via:
- /etc/lynx-cur/lynx.cfg, variables SSL_CLIENT_CERT_FILE and
  SSL_CLIENT_KEY_FILE
- Environment variables: SSL_CLIENT_CERT_FILE and
  SSL_CLIENT_KEY_FILE
- Built-In Option Menu (Options "SSL client certificate
  file","SSL client key file")


This patch was reviewed by a long time lynx user, trying out
http://contributors.debian.net.


Please note that you need to apply this patch [1] (Bug 797059 [2]) first.


Cheers,

Simon



[1]
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;att=1;filename=gnutls_add_rehandshake_support.diff;bug=797059

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797059
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJV6FB8AAoJEBy08PeN7K/pwPkQALdiJvKX+7hBz27dD8Uat/gF
+f8mopJegp6ezgTzPfZ9EPJT/UPoDLHu3HpAM/iSU1W33qVgfZQIed9gp8mcm87S
7f83ly0JkmyYa4niHWPTfZUIW2KvaeNyf1bsUN5iITKoARUPi/sOyrVayEXINYB0
IN5ZSgAJ/oBXDeHQCxcroO0mUrdQyUZil+oVwaZWzfxaNi8rccjzILg35ZQfUSdy
uyzkHElj4bj6GAD0VWOLVoiSPCjAuW5RMkFJzYz6ypCZTGXNT/L40bvoHaOojBe5
Mrp102tPOFIcQgCZO4AC8M+3M10qr2k/AgH1BvedNVlhZ7ACeJsbcHbiUZDogzYs
g3AwRBDrHZDTx5vu/2hKeOeekD3izwjmIEJcmdVgHZfkJPu7NubeJ2qIJcL0EfHO
T0eS8RSg1IBpdysCEQA9vXDzuNtL/qWoWjeAoJ388PfB6zHzR6M7b+KegI5WItba
L8xV/C3+4i0vPkp1Eca4VPEzPEyQB9dwC5pDNeByGngIaGhReZx+QCpAuIhuUD+W
yd/kmLt7cpL7IAOSDFJwL+tbLw+DgC3/bujAPhx4NAd8MOy2XN9GTGlkuBzSKmso
o8mqsE4oEjalbu/KQ7bIUWWaHbjwgG1UhwBxJahfbEgVfOgP3cBEQimpT65XYlkJ
rR/2KpZbFRl00tdiba5J
=bmnH
-END PGP SIGNATURE-
Description: Add client certificate support
 This feature is neccessary to enable lynx to use Debian SSO
 infrastructure, which now relies on client certificates.
 .
 Currently, client certificates and their corresponding key files
 must be in PEM format.
Author: Simon Kainz 

---
Origin: other
Forwarded: no
Reviewed-By: Mario Lang 
Last-Update: 2015-09-03

--- lynx-cur-2.8.9dev6.orig/WWW/Library/Implementation/HTTP.c
+++ lynx-cur-2.8.9dev6/WWW/Library/Implementation/HTTP.c
@@ -162,6 +162,9 @@ SSL *HTGetSSLHandle(void)
 {
 #ifdef USE_GNUTLS_INCL
 static char *certfile = NULL;
+static char *client_keyfile = NULL;
+static char *client_certfile = NULL;
+
 #endif
 
 if (ssl_ctx == NULL) {
@@ -204,6 +207,9 @@ SSL *HTGetSSLHandle(void)
 	}
 #endif
 #ifdef USE_GNUTLS_INCL
+
+
+	
 	if ((certfile = LYGetEnv("SSL_CERT_FILE")) != NULL) {
 	CTRACE((tfp,
 		"HTGetSSLHandle: certfile is set to %s by SSL_CERT_FILE\n",
@@ -225,10 +231,40 @@ SSL *HTGetSSLHandle(void)
 	}
 #endif
 	atexit(free_ssl_ctx);
+
 }
 #ifdef USE_GNUTLS_INCL
+
+
+	 if (non_empty(SSL_client_key_file))
+	{
+	client_keyfile=SSL_client_key_file;
+		CTRACE((tfp,
+			"HTGetSSLHandle: client key file is set to %s by config SSL_CLIENT_KEY_FILE\n",
+			client_keyfile));
+	}
+	
+	
+
+	 if (non_empty(SSL_client_cert_file))
+	{
+	client_certfile=SSL_client_cert_file;
+		CTRACE((tfp,
+			"HTGetSSLHandle: client cert file is set to %s by config SSL_CLIENT_CERT_FILE\n",
+			client_certfile));
+	}
+	
+	
+
+
+
 ssl_ctx->certfile = certfile;
 ssl_ctx->certfile_type = GNUTLS_X509_FMT_PEM;
+ssl_ctx->client_keyfile = client_keyfile;
+ssl_ctx->client_keyfile_type = GNUTLS_X509_FMT_PEM;
+ssl_ctx->client_certfile = client_certfile;
+ssl_ctx->client_certfile_type = GNUTLS_X509_FMT_PEM;
+
 #endif
 ssl_okay = 0;
 return (SSL_new(ssl_ctx));
--- lynx-cur-2.8.9dev6.orig/WWW/Library/Implementation/tidy_tls.h
+++ lynx-cur-2.8.9dev6/WWW/Library/Implementation/tidy_tls.h
@@ -78,6 +78,11 @@ typedef struct _SSL_CTX {
 int (*verify_callback) (int, X509_STORE_CTX *);
 int verify_mode;
 
+char *client_certfile;
+int client_certfile_type;
+char *client_keyfile;
+int client_keyfile_type;
+
 } SSL_CTX;
 
 struct _SSL {
--- lynx-cur-2.8.9dev6.orig/lynx.cfg
+++ lynx-cur-2.8.9dev6/lynx.cfg
@@ -3561,6 +3561,20 @@ NESTED_TABLES: false
 SSL_CERT_FILE:/etc/ssl/certs/ca-certificates.crt
 #SSL_CERT_FILE:NULL
 
+.h2 SSL_CLIENT_CERT_FILE
+# Set SSL_CLIENT_CERT_FILE to the file that contains a client certificate
+# (in PEM format) in case the $SSL_CLIENT_CERT_FILE environment variable is 
+# not set, e.g.,
+#
+#SSL_CLIENT_CERT_FILE:/home/qux/certs/cert.crt
+
+.h2 SSL_CLIENT_KEY_FILE
+# Set SSL_CLIENT_KEY_FILE to the file that contains a client certificate
+# key (in PEM format), in case the $SSL_CLIENT_KEY_FILE environment variable 
+# is not set, e.g.,
+#

Bug#797873: libkf5wallet5-bin for kwalletd5 not installed

[Diederik de Haas]

On Thursday 03 September 2015 10:30:51 Martin Steigerwald wrote:
> And indeed only kwalletd not kwalletd5 was running. That was due to the fact
> that libkf5wallet-bin which contains the necessary binary was not
> installed.
> 
> Not sure exactly where, but somewhere there needs to be at least a
> recommends for that, I´d say. I thought about a recommends in libkf5wallet5
> itself.

On my system that is already the case.

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

Bug#786097: solarwolf: diff for NMU version 1.5-2.1

[Graham Inggs]

Control: tags 786097 + patch
Control: tags 786097 + pending

Dear maintainer,

I've prepared an NMU for solarwolf (versioned as 1.5-2.1). The diff
is attached to this message.

Regards.
diff -u solarwolf-1.5/debian/control solarwolf-1.5/debian/control
--- solarwolf-1.5/debian/control
+++ solarwolf-1.5/debian/control
@@ -2,7 +2,7 @@
 Section: games
 Priority: optional
 Maintainer: Josselin Mouette 
-Build-Depends-Indep: python (>= 2.1), python-support (>= 0.4)
+Build-Depends-Indep: python-all, dh-python
 Build-Depends: debhelper (>= 4.1.25)
 Standards-Version: 3.7.2

diff -u solarwolf-1.5/debian/rules solarwolf-1.5/debian/rules
--- solarwolf-1.5/debian/rules
+++ solarwolf-1.5/debian/rules
@@ -41,7 +41,7 @@
dh_installchangelogs
dh_compress
dh_fixperms
-   dh_pysupport
+   dh_python2
dh_installdeb
dh_gencontrol
dh_md5sums
diff -u solarwolf-1.5/debian/changelog solarwolf-1.5/debian/changelog
--- solarwolf-1.5/debian/changelog
+++ solarwolf-1.5/debian/changelog
@@ -1,3 +1,10 @@
+solarwolf (1.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Port from python-support to dh-python (closes: #786097).
+
+ -- Graham Inggs   Thu, 03 Sep 2015 17:19:25 +0200
+
 solarwolf (1.5-2) unstable; urgency=low

   * data/levels.txt: fix typos in level names

Bug#797783: [buildd-tools-devel] Bug#797783: sbuild fails without any error message when /var/lib/sbuild is not writable in the chroot

[Raphael Hertzog]

On Thu, 03 Sep 2015, Johannes Schauer wrote:
> Unfortunately I'm still not able to reproduce your problem.
> 
> The one missing configuration option that you have and I do not is
> union-type=overlay. If I enable that in my schroot config, then I get:
> 
>   union-type: Unknown filesystem union type ‘overlay’
> 
> So I guess more configuration is required for this?

In a jessie environment (in particular the kernel), you can use "aufs"
instead of "overlay". In stretch/sid (with a newer kernel), you need
"overlay" but it also requires a version of schroot which is only in
unstable right now...

> Can you confirm that you do not see this problem without an overlay either?

Yes, I confirm it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#797712: failing with gpg2, error reading key: Legacy key

[Eduard Bloch]

Hallo,
* Guilhem Moulin [Thu, Sep 03 2015, 11:46:42AM]:
> Control: tag -1 moreinfo unreproducible
> 
> On Wed, 02 Sep 2015 at 22:20:03 +0200, Eduard Bloch wrote:
> > $ gpg2 --homedir ~/.caff/gnupghome.alt --list-key 
> > 7C3AB9CFD230BD30DD009C591E7091B1F14A64A2
> > gpg: checking the trustdb
> > gpg: keydb_get_keyblock failed: Legacy key
> > gpg: keydb_get_keyblock failed: Legacy key
> > gpg: keydb_get_keyblock failed: Legacy key
> > ... LOTS OF THEM ...
> > gpg: keydb_get_keyblock failed: Legacy key
> > gpg: no ultimately trusted keys found
> > pub   rsa4096/F14A64A2 2009-05-22 [expires: 2017-07-21]
> > uid [ unknown] Aaron M. Ucko 
> > uid [ unknown] Aaron M. Ucko 
> > uid [ unknown] [jpeg image of size 6064]
> > sub   rsa4096/0ABAADF9 2009-05-22 [expires: 2017-07-21]
> 
> What's the return value of that command btw?  Does running the command a
> second time afterwards (with the GNUPGHOME left by the first execution)
> produce the same output and return value?  Same question with
> ‘--trust-model=always’.
> 
> Also, do you have any v3 keys in your keyring?  What's the output of
> 
>   gpg --homedir ~/.caff/gnupghome.alt --with-fingerprint --with-fingerprint 
> --with-colons --list-keys |
>   grep -icE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$'
> 
> (you need to set ‘--with-fingerprint’ twice to list subkey fingerprints
> as well.)

84

;-) Have I mentioned that I installed signing-party a decade ago and used it
rarelly, like once in 2-3 years?

$ stat secring.gpg 
  File: ‘secring.gpg’
...
Modify: 2006-05-06 13:19:30.0 +0200

Regards,
Eduard.


signature.asc
Description: Digital signature

Bug#797915: ITP: setuptools_scm -- blessed package to manage your versions by scm tags for Python

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: setuptools-scm
  Version : 1.7.0
  Upstream Author : Ronny Pfannschmidt
* URL : https://github.com/pypa/setuptools_scm
* License : Expat
  Programming Lang: Python
  Description : blessed package to manage your versions by scm tags for 
Python
 setuptools_scm handles managing your Python package versions in scm metadata.
 It also handles file finders for the suppertes scm's.

The newest ipython depends on pickleshare, which depends on path.py,
which depends on this package. I'll maintain this package within the Debian
Python Modules Team.

Thanks,

Snark on #debian-python

Bug#744255: aptitude has issues installing or purging a specific package - gfxboot-themes Package: aptitude

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi shirish,

2014-04-12 00:52 shirish शिरीष:

Package: aptitude
Version: 0.6.10-1
Severity: normal

Dear Maintainer,
I was trying to install gfxboot-themes when during the install it
kinda hung while installing.

$ sudo aptitude install gfxboot-themes
The following NEW packages will be installed:
 gfxboot-themes
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.0 MB of archives. After unpacking 92.5 MB will be used.
Get: 1 http://debian.ec.as6453.net/debian/ jessie/main gfxboot-themes
all 4.5.2-1.1-2 [11.0 MB]
Fetched 11.0 MB in 8min 32s (21.4 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
D01: ensure_diversions: new, (re)loading
D01: ensure_statoverrides: new, (re)loading
Selecting previously unselected package gfxboot-themes.
(Reading database ... 453773 files and directories currently installed.)
Preparing to unpack .../gfxboot-themes_4.5.2-1.1-2_all.deb ...
D01: process_archive oldversionstatus=not installed
Unpacking gfxboot-themes (4.5.2-1.1-2) ...
D01: process_archive updating info directory
D01: generating infodb hashfile
D01: ensure_diversions: new, (re)loading
Setting up gfxboot-themes (4.5.2-1.1-2) ...
D01: deferred_configure updating conffiles

It comes at that last line and just hanged there. I waited for quite
some time but nothing happened, it kinda stuck there.

I then tried to purge it and that too became stuck :-

$ sudo aptitude purge gfxboot-themes -y
The following packages will be REMOVED:
 gfxboot-themes{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 92.5 MB will be freed.

As can be seen it is stuck there. I did check that the installation happened.

$ apt-show-versions -a gfxboot-themes
gfxboot-themes:all 4.5.2-1.1-2 install ok installed
gfxboot-themes:all 4.5.2-1.1-2 jessie   debian.ec.as6453.net
No testing-updates version
gfxboot-themes:all 4.5.2-1.1-2 unstable debian.ec.as6453.net
No experimental version
gfxboot-themes:all/jessie 4.5.2-1.1-2 uptodate

Any ideas would be good. Looking forward to know what might have gone wrong.



This looks to me as a problem with the package installations /
uninstallation scripts.  If the scripts do strange things and hang,
there is not much that aptitude can do there, until there is a new
version of the package that has the scripts working properly and solves
the mess.

It looks like this package had serious issues at the time, c.f. [1].  I
don't know if the issue is related, though.

In any case, could you purge the package in the end, after perhaps
upgrading to a new version of the package, or did the problem continue
for a while / until now?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752231


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

On Thu, 2015-09-03 at 15:13 +, Gianfranco Costamagna wrote:
> 
> Hi,
> 
> control:
> 
> libboost-all-dev (>= 1.55) | libboost1.55-all-dev (>= 1.55),
> what is the rationale for that? I guess libboost-all-dev is already enough...

I've removed libboost1.55-all-dev (>= 1.55) locally.

> Multi-Arch: no
> isn't that the default?

Really? let me look up for some doc...
if so I'll strip them.

> "Pre-Depends: ${misc:Pre-Depends}"
> 
> this should be useless

Since it's generated by default with debmake (next-gen dh-make),
I didn't notice that.

I've stripped them locally.

> 
> rules:
> --builddirectory=
> can be passed also in dh call, making useless everywhere

(I'm not sure I'm following you at this point)
Initially I wrote rules as so:

%:
  dh $@ --builddirectory=XX1
if flag
  dh $@ --builddirectory=XX2
endif

Then I found that I can't control the rules
within my understanding (because of the another conditional build
-- cuda version)

And current rules is easy for me to understand and maintain.

> "fakeroot dh binary"
> 
> well, I usually don't like such hacks in rules file :)

This is just part of custom target, which is not included in
the standard build process, and it's for user's custom localbuild.

Inspired by Debian's OpenBLAS, I provided 2 custom targets:
custom-cpu and custom-cuda
and that's the way I found that works and can generate the packages.

For detail please see debian/README.Debian :-)

> CUSTOM_JOBS   := "-j4"
> 
> well mips porters might hate you for this!

I think I should clarify the variable.

As said above and said in `debian/README.Debian`, this is
just a job number control of custom-* targets, and has no
effect on standard dpkg-buildpackage process jobs, which is
controlled by ENVs and --parallel.

> isn't something like
> override_dh_auto_build:
> dh_auto_configure flags-build1
> dh_auto_build -O--parallel --builddirectory=build1
> dh_auto_configure flags-build2
> dh_auto_build -O--parallel --builddirectory=build2
> 
> not good for your purpose?

override_dh_auto_build:
dh_auto_build --builddirectory=${CAFFE_CPU_BUILDDIR} \ 
-- all caffe pycaffe  
ifeq (y, $(flag_build_caffe_cuda)) 
dh_auto_build --builddirectory=${CAFFE_CUDA_BUILDDIR} \ 
-- all caffe pycaffe  
endif 

Cafffe_cuda is a conditional build, which means the build
against caffe_cuda should only be triggered on i386|amd64.

IMHO squashing dh_auto_configure and dh_auto_build into
override_dh_auto_build can make understanding dh behaviour
harder...

I'll have a search on codesearch.d.n soon and see how others
handle issues alike.



In all, I'm satisfied with current rules, as it's easy to understand,
and tweak.

Thank you so much for reviewing it.
I'll do another mentors upload soon, after an investigation on
codesearch.d.n



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

Bug#797771: RFS: [ITP] tzlocal/1.2-1

[Gianfranco Costamagna]

Hi Henrique,

Do you think we should rename it?

I can upload a new version on ftpmaster with changelog and control renamed.

the python package has the correct name, and the source name is the pypi one...

cheers,

G.





Il Giovedì 3 Settembre 2015 20:12, Henrique de Moraes Holschuh 
 ha scritto:
On Wed, 02 Sep 2015, Edward Betts wrote:

>  * Package name: tzlocal
> 
> It builds those binary packages:
> 
>   python-tzlocal - tzinfo object for the local timezone
>   python3-tzlocal - tzinfo object for the local timezone (Python 3 version)

I usually don't bother with this for source packages, but "tzlocal" is a
name with high chances of creating annoying colisions.

Since this source package is extremely unlikely to ever create non-python
packages, maybe you should name the source package also "python-tzlocal"?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#797921: [deluged] error: attributes() got an unexpected keyword argument 'apply_with_init'

[jnqnfe]

Package: deluge
Version: 1.3.10-3
Severity: important

Deluge refuses to start. Running it from a terminal produces the
following output:

user@userPC:~$ deluge
Gtk-Message: Failed to load module "canberra-gtk-module"
Traceback (most recent call last):
  File "/usr/bin/deluge", line 9, in 
load_entry_point('deluge==1.3.10', 'gui_scripts', 'deluge')()
  File "/usr/lib/python2.7/dist-packages/deluge/main.py", line 132, in
start_ui
UI(options, args, options.args)
  File "/usr/lib/python2.7/dist-packages/deluge/ui/ui.py", line 149, in
__init__
from deluge.ui.gtkui.gtkui import GtkUI
  File "/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/__init__.py",
line 1, in 
from gtkui import start
  File "/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/gtkui.py",
line 82, in 
from deluge.ui.client import client
  File "/usr/lib/python2.7/dist-packages/deluge/ui/client.py", line 37,
in 
from twisted.internet import reactor, ssl, defer
  File "/usr/lib/python2.7/dist-packages/twisted/internet/ssl.py", line
223, in 
from twisted.internet._sslverify import (
  File "/usr/lib/python2.7/dist
-packages/twisted/internet/_sslverify.py", line 192, in 
verifyHostname, VerificationError =
_selectVerifyImplementation(OpenSSL)
  File "/usr/lib/python2.7/dist
-packages/twisted/internet/_sslverify.py", line 167, in
_selectVerifyImplementation
from service_identity import VerificationError
  File "/usr/lib/python2.7/dist-packages/service_identity/__init__.py",
line 12, in 
from . import pyopenssl
  File "/usr/lib/python2.7/dist
-packages/service_identity/pyopenssl.py", line 14, in 
from ._common import (
  File "/usr/lib/python2.7/dist-packages/service_identity/_common.py",
line 136, in 
@attributes(["pattern"], apply_with_init=False)
TypeError: attributes() got an unexpected keyword argument
'apply_with_init'

Bug#797923: mutt: Updated Danish translation

[Morten Bo Johansen]

Package: mutt
Version: 1.5.23-3.1
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

An updated version of the Danish translation of the mutt
message catalog is attached.

Thanks,
Morten

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

System: Linux 4.1.0-2-amd64 (x86_64)
ncurses: ncurses 6.0.20150810 (compiled with 5.9)
libidn: 1.32 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

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

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/xtitles.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features-old/patch-1.5.4.vk.pgp_verbose_mime.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch
debian-specific/dont_document_not_present_features.patch
debian-specific/document_debian_defaults.patch
debian-specific/assumed_charset-compat.patch
debian-specific/467432-write_bcc.patch
debian-specific/566076-build_doc_adjustments.patch
misc/define-pgp_getkeys_command.patch
misc/gpg.rc-paths.patch
misc/smime.rc.patch
misc/fix-configure-test-operator.patch
upstream/531430-imapuser.patch
upstream/543467-thread-segfault.patch
upstream/542817-smimekeys-tmpdir.patch
upstream/548577-gpgme-1.2.patch
upstream/553321-ansi-escape-segfault.patch
upstream/547980-smime_keys-chaining.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/603288-split-fetches.patch

Bug#797925: python-service-identity: Breaks deluge

[Adam Sjøgren]

Package: python-service-identity
Version: 14.0.0-1
Severity: normal

Dear Maintainer,

After upgrading the python-service-identity package, deluge (1.3.10-3) won't
start - it dies with this stack trace:

$ deluge
Traceback (most recent call last):
  File "/usr/bin/deluge", line 9, in 
load_entry_point('deluge==1.3.10', 'gui_scripts', 'deluge')()
  File "/usr/lib/python2.7/dist-packages/deluge/main.py", line 132, in start_ui
UI(options, args, options.args)
  File "/usr/lib/python2.7/dist-packages/deluge/ui/ui.py", line 149, in __init__
from deluge.ui.gtkui.gtkui import GtkUI
  File "/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/__init__.py", line 1, 
in 
from gtkui import start
  File "/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/gtkui.py", line 82, in 

from deluge.ui.client import client
  File "/usr/lib/python2.7/dist-packages/deluge/ui/client.py", line 37, in 

from twisted.internet import reactor, ssl, defer
  File "/usr/lib/python2.7/dist-packages/twisted/internet/ssl.py", line 223, in 

from twisted.internet._sslverify import (
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_sslverify.py", line 
192, in 
verifyHostname, VerificationError = _selectVerifyImplementation(OpenSSL)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_sslverify.py", line 
167, in _selectVerifyImplementation
from service_identity import VerificationError
  File "/usr/lib/python2.7/dist-packages/service_identity/__init__.py", line 
12, in 
from . import pyopenssl
  File "/usr/lib/python2.7/dist-packages/service_identity/pyopenssl.py", line 
14, in 
from ._common import (
  File "/usr/lib/python2.7/dist-packages/service_identity/_common.py", line 
136, in 
@attributes(["pattern"], apply_with_init=False)
TypeError: attributes() got an unexpected keyword argument 'apply_with_init'
$ 

Downgrading to the version in testing (1.0.0-3) makes deluge work again.

It may be that a newer version of deluge, not yet in Debian, includes a fix,
as deluge 1.3.11 and python-service-identity 14.0.0 is reported to work
together on Arch.

Best regards,

  Adam

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

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

Versions of packages python-service-identity depends on:
ii  python-characteristic  0.1.0-1
ii  python-openssl 0.15.1-2
ii  python-pyasn1  0.1.8-1
ii  python-pyasn1-modules  0.0.5-0.1
pn  python:any 

Versions of packages python-service-identity recommends:
ii  python-idna  2.0-3

python-service-identity suggests no packages.

-- no debconf information

Bug#797926: transition: openssl: remove SSLv3 methods

[Kurt Roeckx]

Package: release.debian.org

Hi,

I would like to remove the last support for SSLv3 in openssl.
This means that I'll be dropping 3 symbols from the shared
library:
SSLv3_method();
SSLv3_server_method();
SSLv3_client_method();

Those can still be used to set up SSLv3 connections, while using
the SSLv23_* methods won't talk SSLv3.

This change will result in the define OPENSSL_NO_SSL3_METHOD
becoming defined.  Some software in Debian already checks for
either that define or the presence of the functions to enable
support for it or not.  I find those changes very unfortunate,
they should just have dropped SSLv3 support completly.

My question is how you want to proceed with this.  I see a few
options:
- Change the soname, rebuild everything against that new soname.
- Just drop the symbols, adding Breaks on at least some
  packages like curl and python that are known to need a rebuild
  against the changed headers.

As far as I know all the major packages making use of those
symbols should be fixed now, or have a fix available.


Kurt

Bug#797931: elinks: Does not support SSL rehandshakes

[Guillem Jover]

Package: elinks
Version: 0.12~pre6-10
Severity: normal

Hi!

I've been playing a bit with the new Debian SSO setup, and when trying
elinks, it could not even connect to the sites before authenticating:

  
  
  
  

It gives the following error message:

,---
  Unable to retrieve https://tracker.debian.org/:

  Resource temporarily unavailable
`---

When tracking this down, it appears one of the problems is due to not
handling SSL rehandshakes at all. When trying to fix that with the
attached patch, it started complaining about being unable to rehandshake
with:

,---
elinks: SSL rehandshake error: No or insufficient priorities were set.
`---

And, here I've run out of time. Hope at least this serves as a
starting point for someone else.

Thanks,
Guillem
diff --git a/src/network/ssl/socket.c b/src/network/ssl/socket.c
index 2ecdd71..f763ebd 100644
--- a/src/network/ssl/socket.c
+++ b/src/network/ssl/socket.c
@@ -246,8 +246,18 @@ ssl_read(struct socket *socket, unsigned char *data, int len)
 #endif
 
 #ifdef CONFIG_GNUTLS
-		if (err == GNUTLS_E_REHANDSHAKE)
-			return -1;
+		if (err == GNUTLS_E_REHANDSHAKE) {
+			err = gnutls_handshake(socket->ssl);
+			if (err < 0) {
+fprintf(stderr, "elinks: SSL rehandshake error: %s\n", gnutls_strerror(err));
+errno = S_SSL_ERROR;
+return SOCKET_INTERNAL_ERROR;
+			}
+			rd = gnutls_record_recv(socket->ssl, data, len);
+			if (rd > 0)
+return rd;
+			err = rd;
+		}
 #endif
 
 		if (err == SSL_ERROR_WANT_READ ||

Bug#792882: /bin/machinectl: Re: /bin/machinectl: machinectl fails to login to container

[Felipe Sateler]

On 3 September 2015 at 15:24, Ritesh Raj Sarraf  wrote:
> there's nothing interesting on the console log, that I
> could provide.

Maybe the journal has information? journalctl -M $machine should give
you the logs of the machine.


-- 

Saludos,
Felipe Sateler

Bug#797922: Crash at creating bug report for some packages

[Mechtilde Stehmann]

Package: reportbug
Version: 6.6.4
Severity: important
Tags: upstream

Hello,

I want to work at a bug report for a package I pack. I have installed a beta
version of calendar-exchange-provider for testing the package. I test the
reportbug too.

Looking at the appropriate bugs, reportbug crashes.

The hash of that conffile is "e7bedf87b78de66f99e6e7fea664a152".

I worked out that the problem was the first character of this hash. It crashes
because of the beginning "e".

Kind regards

Mechtilde



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

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

Versions of packages reportbug depends on:
ii  apt   1.0.9.10
ii  python2.7.9-1
ii  python-reportbug  6.6.4
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  emacs23-bin-common  23.4+1-4.1+b1
ii  emacs24-bin-common  24.5+1-1
ii  file1:5.22+15-2
ii  gnupg   1.4.19-5
pn  postfix | exim4 | mail-transport-agent  
ii  python-gtk2 2.24.0-4
ii  python-gtkspell 2.25.3-13
pn  python-urwid
ii  python-vte  1:0.28.2-5
ii  xdg-utils   1.1.0~rc1+git20111210-7.4

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.10
ii  python-debian 0.1.27
ii  python-debianbts  1.14
pn  python:any

python-reportbug suggests no packages.

-- Configuration Files:
/etc/reportbug.conf changed [not included]

Bug#797921: Acknowledgement ([deluged] error: attributes() got an unexpected keyword argument 'apply_with_init')

[jnqnfe]

Appears to be an incompatibility with the new version python-service
-identity which went from v1.0.0-3 to 14.0.0-1 yesterday.

Bug#797924: nmu: boost1.58_1.58.0+dfsg-3

[Fernando Seiti Furusato]

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

Dear Release Team,

While trying to build clblas, it failed due to a problem with boost.
I see that there is at least one more package failing due this.
I rebuilt boost and it worked here so I assume this will fix it.

nmu boost1.58_1.58.0+dfsg-3 . ppc64el . -m "Rebuild since it is causing other
packages to ftbfs"

Thanks!

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: ppc64el (ppc64le)

Bug#797927: python-debtcollector: Please update to 0.7.0

[Barry Warsaw]

Source: python-debtcollector
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Version 0.7.0 is the latest version on PyPI and it fixes some
compatibility problems with Python 3.5.  Please consider upgrading the
experimental version to 0.7.0.  Also, please change the debian/watch
file to use the pypi.debian.net redirector.

Cheers!


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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJV6JfHAAoJEBJutWOnSwa/xvkQAKhhm8bgaOCE9lUFvuq82yfp
M6/2IH9p9npsgAZwMIYxKW8oCYIDr2VgdHbx0fOztCTEQQeh3vzHwDndbuGPxCZS
TJq/vYTaSShmPy8gRQWvh5I0mNGxskQc9Zq5nMvDIl5hqjekUD3JTrLOhRzFOCz6
+Qs6H+QhJTTYuu4jRF4JaqbUHyDRxs7y/qtpkvhLCwJxW43Mg3YLSzqbs309GcEe
YMUnziv36FMj+bF/ZMwrQOaw59+bPCP/zxXrozKcK0zSlSMiOCLU0ITqauFlH5Cc
7ZCODJWC2ftSTYWivO7dOYdTtGumMbtZRsplfIRn++CRRmJYRFb6La6uJSsxWqhQ
Sx87mEn+fK1FlLFk6mUpRK99vZQUNA9aXqYtVE9B6ABleSYqBSBBRSAmlkQiaetM
I/e0TdUwCcoFcDqmghTqFyw8vsJJiFLng0kw6ELvid9VTnm/fcZIKPFdL3/ys3d+
gk+szrIgWQLj/TFcmjQiXRklczbj371+k6SlOJjzuqnM+Ri5TByYvxpFrSSrP3WR
xGtYOILPSySF9vdZgFqNkHvVqPDgcddglwY+3fImXwlemgFt+jyCzuAqMbq03RVV
eqZBGeaY5e54/z5P4upGRsAwl/2g6qeonAHgwOvRJmPGd/QJnH5Snho9LKx4RXzX
AIh6KtHsg+h06hHX3q/L
=jBDR
-END PGP SIGNATURE-

Bug#756766: Initial work-patch on this bug

[Raphael Hertzog]

Hi,

On Wed, 02 Sep 2015, Orestis Ioannou wrote:
> I have enabled only the unstable repository and I don't have many news
> to test what i ve done. Is there any other solution to test/work this
> besides adding more repositories?

s/repositories/news/ ?

If you want to test this, you have to add many news to a single package.
You can do that manually I guess (either in an interactive Python shell
or with the help of "./manage.py tracker_receive_news"), or better, you
script it.

And then you reuse that code for functional testing with selenium (cf
functional_tests/tests.py).

> I attach the initial patch although there still work to be done (avoid
> copy pasting pagination code, add some tests, redirection from the old
> PTS)

There's possibly also room for simplication by using generic views like
django.views.generic.list.ListView, they support pagination natively...

You should also avoid duplication between templates and factorize
the HTML code to display the list of news.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#797771: RFS: [ITP] tzlocal/1.2-1

[Edward Betts]

Yes, let's rename it. I'll figure out how to move it in the Python Library
team subversion and upload a copy with the name python-tzlocal for the source
package to mentors.debian.net

-- 
Edward.

Bug#797928: ITP: python-cbor -- Python Implementation of RFC 7049. Concise Binary Object Representation (CBOR)

[Agustin Henze]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org


   Package name: python-cbor
Version: 0.1.21
Upstream Author: 2014-2015 Brian Olson
URL: https://bitbucket.org/bodhisnarkva/cbor
License: Apache-2.0
Description: Python Implementation of RFC 7049. Concise Binary Object
Representation (CBOR).
 CBOR is comparable to JSON, has a superset of JSON’s ability, but serializes
 to a binary format which is smaller and faster to generate and parse.
 .
 The two primary functions are cbor.loads() and cbor.dumps(). This library
 includes a C implementation which runs 3-5 times faster than the Python
 standard library’s C-accelerated implementanion of JSON. This is also includes
 a 100% Python implementation

-- 
TiN

Bug#289072: aptitude: Please consider a different color for the packages short descriptions

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hello Justin,

2005-01-07 00:47 Justin Pryzby:

Package: aptitude
Version: 0.2.15.8-1
Severity: normal

I just completely missed the short descriptions while browsing package
lists for 20 minutes .. maybe this is a bug on my lcd screen though.


Is the short description that you mention the horizontal line in the
main view, between the package list and the bottom half with package
description and information, with blue background and white bold text?

I don't know if in the version that you reported it the color schemes
were different and less visible.  I agree that sometimes might not be
very noticeable, but on the other hand I don't think that it can be made
much more clear.  For me, the visual cue that makes it noticeable is
that when one moves to different packages, the lengths of description
are different so it gets my attention.  And if I miss it, no big issue,
I can go into Package Info screen to see the short and long description
in a more clear way.


From a UI point of view, I think that one's eyes/brain consider that

just a horizontal separation line, so it doesn't strike as containing
important information for the brain to consume.  However, aptitude's
curses interface is quite limited compared to full GUI applications, and
short of making the text blink or not have text on that line and instead
add it below (in which case, we do not make use of a line of text --
whether that's good or bad, depends on one's point of view), I don't
know how to improve it.

So at the moment I am marking this bug as 'moreinfo', to see if anybody
has suggestions about how to improve this, or at least opinions if it's
worthy to do.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#797930: ITP: pickleshare -- File system based database that uses Python pickles

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: pickleshare
  Version : 0.5
  Upstream Author : Ville Vainio
* URL : https://github.com/pickleshare/pickleshare
* License : Expat
  Programming Lang: Python
  Description : File system based database that uses Python pickles
 Like shelve, a PickleShareDB object acts like a normal dictionary. Unlike
 shelve, many processes can access the database simultaneously. Changing a
 value in database is immediately visible to other processes accessing the
 same database.
 .
 Concurrency is possible because the values are stored in separate files.
 Hence the "database" is a directory where all files are governed by
 PickleShare.

The newest ipython depends on this package. I'll maintain this package 
within the Debian Python Modules Team.


Thanks,

Snark on #debian-python

Bug#797933: xsddiagram 0.17

[Mathieu Malaterre]

Package: xsddiagram

It would be nice to package 0.17.

New features:
- Possible to generate text in place of images
- Some bug fixes

Bug#786204: sushi: diff for NMU version 1.4.0+dfsg-1.1

[Andrey Rahmatullin]

Control: tags 786204 + patch
Control: tags 786204 + pending

Dear maintainer,

I've prepared an NMU for sushi (versioned as 1.4.0+dfsg-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
WBR, wRAR
diff -Nru sushi-1.4.0+dfsg/debian/changelog sushi-1.4.0+dfsg/debian/changelog
--- sushi-1.4.0+dfsg/debian/changelog	2012-06-09 21:11:40.0 +0600
+++ sushi-1.4.0+dfsg/debian/changelog	2015-09-03 22:43:24.0 +0500
@@ -1,3 +1,10 @@
+sushi (1.4.0+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Port from python-support to dh-python (Closes: #786204)
+
+ -- Andrey Rahmatullin   Thu, 03 Sep 2015 22:43:23 +0500
+
 sushi (1.4.0+dfsg-1) unstable; urgency=low
 
   * New upstream release (Closes: #655964, #638661, #640420, #652783).
diff -Nru sushi-1.4.0+dfsg/debian/control sushi-1.4.0+dfsg/debian/control
--- sushi-1.4.0+dfsg/debian/control	2012-06-09 21:10:27.0 +0600
+++ sushi-1.4.0+dfsg/debian/control	2015-09-03 22:42:51.0 +0500
@@ -2,9 +2,8 @@
 Section: net
 Priority: extra
 Maintainer: Devid Antonio Filoni 
-Build-Depends: debhelper (>= 7.0.50~), python, libdbus-1-dev, intltool,
+Build-Depends: debhelper (>= 7.0.50~), python, dh-python, libdbus-1-dev, intltool,
  libglib2.0-dev (>= 2.26), libnice-dev, libminiupnpc-dev (>= 1.5)
-Build-Depends-Indep: python-support
 DM-Upload-Allowed: yes
 Standards-Version: 3.9.3
 Homepage: http://redmine.ikkoku.de/projects/sushi/wiki
diff -Nru sushi-1.4.0+dfsg/debian/rules sushi-1.4.0+dfsg/debian/rules
--- sushi-1.4.0+dfsg/debian/rules	2012-06-09 21:28:06.0 +0600
+++ sushi-1.4.0+dfsg/debian/rules	2015-09-03 22:42:33.0 +0500
@@ -3,7 +3,7 @@
 WAF=env WAFDIR=$(CURDIR) ./waf
 
 %:
-	dh $@ 
+	dh $@ --with python2
 
 override_dh_auto_clean:
 	cd maki && $(WAF) distclean


signature.asc
Description: Digital signature

Bug#797771: RFS: [ITP] tzlocal/1.2-1

[Henrique de Moraes Holschuh]

On Wed, 02 Sep 2015, Edward Betts wrote:
>  * Package name: tzlocal
> 
> It builds those binary packages:
> 
>   python-tzlocal - tzinfo object for the local timezone
>   python3-tzlocal - tzinfo object for the local timezone (Python 3 version)

I usually don't bother with this for source packages, but "tzlocal" is a
name with high chances of creating annoying colisions.

Since this source package is extremely unlikely to ever create non-python
packages, maybe you should name the source package also "python-tzlocal"?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#795817: keychain broken with GnuPG 2.1.7 from unstable

[Boris]

I'm experiencing the same issue with gnupg-agent 2.1.7-2 from unstable.
The cause is that "gpg-agent --daemon" now returns "2" instead of "0" if the 
daemon is already running, which is not accepted as a valid return by older 
versions of keychain.

This seems to issue #30 in keychain's github [1]. While the title suggests 
that it's specific to OSX, it sounds like exactly the same problem. The issue 
was fixed with the commit bf30f9188 [2].

Cheers,
Boris

[1] https://github.com/funtoo/keychain/issues/30
[2] https://github.com/funtoo/keychain/commit/bf30f9188aa07782cd738da2e5e3

Bug#247487: aptitude: Better description text for 'g' in the title bar

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending

Hello Bernhard,

2004-05-05 13:43 Bernhard Trummer:

Package: aptitude
Version: 0.2.14.1-2
Severity: minor

Hello.
In the title bar, the description text for the 'g' key is always:
"Download/Install/Remove Pkgs". However, compared to 'u', one has
to press 'g' two times to really download, install and/or remove
any packages.

So I suggest to display only this description text, if the next
press of the 'g' key really will start the download/installation.
In all other cases, a different description text should be shown,
such as "Preview changes to be done", or something similar.

Thank you.


I think that the request makes sense, but that line is static and always
the same in all views (so it's a bit of a detour to change the code of
that part to suit this particular issue); and in any case it is supposed
to be a extremely terse reference, like a tooltip, and there is not
space for many explanations.

Another argument for not changing it is that it has been like this for
more than a decade (as this report shows), without many complaints about
it.

However, as I say I think that the request makes sense, so to take this
into account, I was thinking in changing it to something like "Preview &
Perform Actions (Download/Install/...)", but looks a bit ugly/confusing
with so many words and spaces (most other elements in a menu are 1 key +
1 word).

I later settled on prepending just 'Preview & ' to the same text, so it
becomes: 'Preview & Download/Install/Remove Pkgs'.

I will consider to change it to something else, or to leave it as it
was, so if someone feels strongly in one way or the other please tell
me, preferably before the next release.

Otherwise this change goes into the next upload, so marking it as
pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#247487: [Aptitude-devel] Bug#247487: aptitude: Better description text for 'g' in the title bar

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> > In the title bar, the description text for the 'g' key is always:
> > "Download/Install/Remove Pkgs". However, compared to 'u', one has
> > to press 'g' two times to really download, install and/or remove
> > any packages.

Not necessarily. That's the default setting. You can also configure
that "g" immediately starts doing things without the preview.

> However, as I say I think that the request makes sense, so to take this
> into account, I was thinking in changing it to something like "Preview &
> Perform Actions (Download/Install/...)", but looks a bit ugly/confusing
> with so many words and spaces (most other elements in a menu are 1 key +
> 1 word).
> 
> I later settled on prepending just 'Preview & ' to the same text, so it
> becomes: 'Preview & Download/Install/Remove Pkgs'.

Which is wrong if the preview has been disabled in the config.

> I will consider to change it to something else, or to leave it as it
> was, so if someone feels strongly in one way or the other please tell
> me, preferably before the next release.

What about 'Preview/Download/Install/Remove Pkgs'?

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

Bug#797926: transition: openssl: remove SSLv3 methods

[Jonathan Wiltshire]

user release.debian@packages.debian.org
usertag 797926 transition

On Thu, Sep 03, 2015 at 08:51:05PM +0200, Kurt Roeckx wrote:
> My question is how you want to proceed with this.  I see a few
> options:
> - Change the soname, rebuild everything against that new soname.
> - Just drop the symbols, adding Breaks on at least some
>   packages like curl and python that are known to need a rebuild
>   against the changed headers.

Personally I would prefer a proper transition, but not until g++5 is out of
the way (others may disagree).


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: Digital signature

Bug#796855: gcc-5: guile-2.0 fails to build with offset problem on armel

[Rob Browning]

Hector Oron  writes:

> As a workaround, if you build package with -O2 (no optimization the
> package seems to build fine on abel.d.o):

You mean -O0, perhaps?

And regardless, if there's an optimization level that will work, then
that's great (should have though to try that myself), and I can upload a
new package soon.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#797929: RM: node -- ROM; no activity, open security issues, de facto orphaned

[Iain R. Learmonth]

Package: ftp.debian.org
Severity: normal

Hi,

This package has not seen any activity for a while, it has open security
issues and no member of the Debian Hamradio Maintainers team has
expressed an active interest in reviving this package. Please remove it
from the archives.

Thanks,
Iain.

Bug#789130: bsdmainutils: [ncal] prints wrong week number

[Sergey Romanov]

It depends on the current locale and what day, Sunday or Monday,
counts as start of the week. In C/POSIX, the first Sunday of the year
starts week 1:
$ LC_ALL=C ncal -wd 2015-01
January 2015
Su 4 11 18 25
Mo 5 12 19 26
Tu 6 13 20 27
We 7 14 21 28
Th  1  8 15 22 29
Fr  2  9 16 23 30
Sa  3 10 17 24 31
   53  1  2  3  4

$ LC_ALL=C ncal -Mwd 2015-01
January 2015
Mo 5 12 19 26
Tu 6 13 20 27
We 7 14 21 28
Th  1  8 15 22 29
Fr  2  9 16 23 30
Sa  3 10 17 24 31
Su  4 11 18 25
1  2  3  4  5

But in de_DE.UTF-8, it's ISO 8601 (i.e. %V): weeks start on a Monday,
and week 1 must contain at least four days:
$ LC_ALL=de_DE.UTF-8 ncal -wd 2015-01
Januar 2015
Mo 5 12 19 26
Di 6 13 20 27
Mi 7 14 21 28
Do  1  8 15 22 29
Fr  2  9 16 23 30
Sa  3 10 17 24 31
So  4 11 18 25
1  2  3  4  5

$ LC_ALL=de_DE.UTF-8 ncal -wd 2016-01
Januar 2016
Mo 4 11 18 25
Di 5 12 19 26
Mi 6 13 20 27
Do 7 14 21 28
Fr  1  8 15 22 29
Sa  2  9 16 23 30
So  3 10 17 24 31
   53  1  2  3  4

$ date -d 2015-01-03 +'%U %V %W'
00 01 00
$ date -d 2015-01-04 +'%U %V %W'
01 01 00
$ date -d 2015-01-05 +'%U %V %W'
01 02 01

Bug#797920: p7zip build dependency not needed

[Matthias Klose]

Package: src:rpm
Version: 4.12.0.1+dfsg1-3
Tags: patch

$ egrep -r '7zr|p7zip' .
$

the build dependency is not needed and can be dropped.

Bug#792882: /bin/machinectl: Re: /bin/machinectl: machinectl fails to login to container

[Ritesh Raj Sarraf]

Package: systemd-container
Version: 225-1
Followup-For: Bug #792882


Hello Michael / Martin,

I'm following up on this bug report with the new issue, after the new
systemd package, which includes the new systemd-container package.


So, the initial problem in this bug report was about dependency on
dbus/systemd inside the container. That dependency satisfied, there
was/is another problem with PAM, for which there is no resolution yet.

Time being, the workaround it to add the TTY device name in securetty.


Now the new problem is that even though I satisfy all the workaround, it
still does not allow a login to the containers. I've tried it with
opensuse 13.1, Fedora 22 and Debian Sid.

As shown below, there's nothing interesting on the console log, that I
could provide.


Can you provide some help here?
Do you see this as a bug to be filed upstream?


chutzpah:/var/lib/machines/fedora# vi etc/securetty 
chutzpah:/var/lib/machines/fedora# cd
chutzpah:~# machinectl start fedora 
chutzpah:~# machinectl login fedora 
Connected to machine fedora. Press ^] three times within 1s to exit session.

^]^]
Connection to machine fedora terminated.
chutzpah:~# machinectl start deb-template
chutzpah:~# machinectl login deb-template
Connected to machine deb-template. Press ^] three times within 1s to exit 
session.


^]^]^]
Connection to machine deb-template terminated.

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

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

Versions of packages systemd-container depends on:
ii  libblkid12.26.2-9
ii  libbz2-1.0   1.0.6-8
ii  libc62.19-19
ii  libcap2  1:2.24-11
ii  libcurl3-gnutls  7.44.0-1
ii  libgcrypt20  1.6.3-2
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  libseccomp2  2.2.3-1
ii  libselinux1  2.3-2+b1
ii  systemd  225-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

systemd-container recommends no packages.

systemd-container suggests no packages.

-- debconf-show failed

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

Two more things: do you have v3 private material as well?  You can count
them with

  gpg --with-fingerprint --with-fingerprint --with-colons --list-secret-keys |
  grep -icE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$'

Are the key(s) specified in your ~/.caffrc (‘keyid’, ‘also-encrypt-to’,
‘local-user’) all v4 keys?

-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#797922: Crash at creating bug report for some packages

[Mechtilde]

Package: reportbug
Version: 6.6.4
Followup-For: Bug #797922

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2242, in 
main()
  File "/usr/bin/reportbug", line 1104, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1405, in user_interface
status = utils.get_package_status(package)
  File "/usr/lib/python2.7/dist-packages/reportbug/utils.py", line 362, in
get_package_status
conffiles = conffiles + [re.findall(r' (.+) ([^ |^(obsolete)]+).*$',
line)[0]]
IndexError: list index out of range



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

** /home/mechtilde/.reportbugrc:
reportbug_version "6.3.1"
mode advanced
ui text
email "o...@mechtilde.de"
smtphost "mail.dasr.de"
smtpuser "stehmann"
smtptls

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

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

Versions of packages reportbug depends on:
ii  apt   1.0.9.10
ii  python2.7.9-1
ii  python-reportbug  6.6.4
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  emacs23-bin-common  23.4+1-4.1+b1
ii  emacs24-bin-common  24.5+1-1
ii  file1:5.22+15-2
ii  gnupg   1.4.19-5
pn  postfix | exim4 | mail-transport-agent  
ii  python-gtk2 2.24.0-4
ii  python-gtkspell 2.25.3-13
pn  python-urwid
ii  python-vte  1:0.28.2-5
ii  xdg-utils   1.1.0~rc1+git20111210-7.4

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.10
ii  python-debian 0.1.27
ii  python-debianbts  1.14
pn  python:any

python-reportbug suggests no packages.

-- Configuration Files:
/etc/reportbug.conf changed [not included]

-- no debconf information

Bug#797932: kdenlive: Kdenlive ignores environment language settings

[Gsc]

Package: kdenlive
Version: 15.04.3-2
Severity: normal
Tags: l10n

Dear Maintainer,

In KDE System Settings and GNOME settings, I've selected Polish as preferred
translation. In .bashrc and .profile, I've exported LC_ALL to pl_PL.utf8. When
I use any application like Kate, gedit or GIMP, the UI is displayed in Polish.
The same applies for Jessie/stable. If I launch Kdenlive in stable (0.9.10-2),
the UI, apart from the Effects names, is displayed in Polish. But if I launch
Kdenlive in Stretch (15.04.3-2), then UI (apart from standard KDE translations
like Copy or Settings) isn't translated, but uses English. It also applies to
unstable release (15.08).

I have kdenlive-data installed, which contains… Which probably should contain
/usr/share/locale/pl/LC_MESSAGES/kdenlive.mo, as in stable. I can't find this
file in Stretch. When I look for "kdenlive.mo" (sid, amd64) at
packages.debian.org, it's found (37 results, same as in Jessie). But, again,
there's no such file in package list of files. I haven't tried building Kdenlive
from source.

Upstream apparently exists:
https://websvn.kde.org/branches/stable/l10n-kf5/pl/messages/kdemultimedia/

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

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

Versions of packages kdenlive depends on:
ii  ffmpeg7:2.7.2-1
ii  kdenlive-data 15.04.3-2
ii  libc6 2.19-19
ii  libgcc1   1:5.1.1-14
ii  libgl1-mesa-glx [libgl1]  10.6.3-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libkf5archive55.13.0-1
ii  libkf5attica5 5.13.0-1
ii  libkf5auth5   5.12.0-1
ii  libkf5bookmarks5  5.12.0-1
ii  libkf5codecs5 5.13.0-1
ii  libkf5completion5 5.12.0-1
ii  libkf5configcore5 5.13.0-1
ii  libkf5configgui5  5.13.0-1
ii  libkf5configwidgets5  5.12.0-1
ii  libkf5coreaddons5 5.13.0-1
ii  libkf5dbusaddons5 5.13.0-1
ii  libkf5guiaddons5  5.13.0-1
ii  libkf5i18n5   5.13.0-1
ii  libkf5iconthemes5 5.12.0-1
ii  libkf5itemviews5  5.13.0-1
ii  libkf5jobwidgets5 5.12.0-1
ii  libkf5kiocore55.12.0-1
ii  libkf5kiofilewidgets5 5.12.0-1
ii  libkf5kiontlm55.12.0-1
ii  libkf5kiowidgets5 5.12.0-1
ii  libkf5newstuff5   5.12.0-1
ii  libkf5notifications5  5.12.0-1
ii  libkf5notifyconfig5   5.12.0-1
ii  libkf5plotting5   5.13.0-1
ii  libkf5service55.12.0-1
ii  libkf5solid5  5.13.0-1
ii  libkf5sonnetui5   5.13.0-1
ii  libkf5textwidgets55.12.0-1
ii  libkf5widgetsaddons5  5.13.0-1
ii  libkf5xmlgui5 5.12.0-1
ii  libmlt++3 0.9.8-1
ii  libmlt6   0.9.8-1
ii  libqt5concurrent5 5.4.2+dfsg-5
ii  libqt5core5a  5.4.2+dfsg-5
ii  libqt5dbus5   5.4.2+dfsg-5
ii  libqt5gui55.4.2+dfsg-5
ii  libqt5network55.4.2+dfsg-5
ii  libqt5opengl5 5.4.2+dfsg-5
ii  libqt5script5 5.4.2+dfsg-4
ii  libqt5svg55.4.2-3
ii  libqt5widgets55.4.2+dfsg-5
ii  libqt5xml55.4.2+dfsg-5
ii  libstdc++65.1.1-14
ii  libv4l-0  1.6.3-1
ii  melt  0.9.8-1

Versions of packages kdenlive recommends:
ii  dvdauthor0.7.0-1.3
ii  dvgrab   3.5-2+b2
ii  frei0r-plugins   1.4-3
ii  genisoimage  9:1.1.11-3
ii  recordmydesktop  0.3.8.1+svn602-1+b1
ii  swh-plugins  0.4.15+1-7

Versions of packages kdenlive suggests:
ii  khelpcenter  4:5.3.2-2

-- no debconf information

Bug#543786: partman-auto-raid: having to name devices explicitly is clumsy

[Gabriel Parrondo]

I'd like to see this change included. It's been merged in Ubuntu since
forever and works very well.

It also makes it possible to transparently create a degraded array
when only one disk is available.

With excplicit device naming all devices must be available at install
time, or a different preseed.cfg must be used.

Bug#797934: elinks: Support for SSL authentication using client certs

[Guillem Jover]

Package: elinks
Version: 0.12~pre6-10
Severity: wishlist

Hi!

Was checking into the Debian SSO implementation
, and noticed that elinks
does not support client certs. I've implemented this, but due to the
GnuTLS rehandshake issue, I've not been able to test them. Once the
other issue is fixed I could probably take another look at this. It
might also make sense to have two options, one for the public and
private key files.

Thanks,
Guillem
diff --git a/src/network/ssl/ssl.c b/src/network/ssl/ssl.c
index 363245d..6310018 100644
--- a/src/network/ssl/ssl.c
+++ b/src/network/ssl/ssl.c
@@ -147,6 +147,21 @@ init_gnutls(struct module *module)
 GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
 	}
 
+	if (get_opt_bool("connection.ssl.client_cert.enable")) {
+		unsigned char *client_cert;
+
+		client_cert = get_opt_str("connection.ssl.client_cert.file");
+		if (!*client_cert) {
+			client_cert = getenv("X509_CLIENT_CERT");
+			if (client_cert && !*client_cert)
+client_cert = NULL;
+		}
+
+		if (client_cert) {
+			gnutls_certificate_set_x509_key_file(xcred,
+client_cert, client_cert, GNUTLS_X509_FMT_PEM);
+		}
+	}
 }
 
 static void
@@ -181,6 +196,22 @@ static union option_info gnutls_options[] = {
 		"restart ELinks for the changes to take effect. "
 		"This option affects GnuTLS but not OpenSSL.")),
 
+	INIT_OPT_TREE("connection.ssl", N_("Client Certificates"),
+		"client_cert", OPT_SORT,
+		N_("X509 client certificate options.")),
+
+	INIT_OPT_BOOL("connection.ssl.client_cert", N_("Enable"),
+		"enable", 0, 0,
+		N_("Enable or not the sending of X509 client certificates "
+		"to servers which request them.")),
+
+	INIT_OPT_STRING("connection.ssl.client_cert", N_("Certificate File"),
+		"file", 0, "",
+		N_("The location of a file containing the client certificate "
+		"and unencrypted private key in PEM format. If unset, the "
+		"file pointed to by the X509_CLIENT_CERT variable is used "
+		"instead.")),
+
 	NULL_OPTION_INFO,
 };
 

Bug#797216: libapache2-mod-svn: path based authentication fails with kerberos

[Andreas Korsten]

* James McCoy wrote:
> Thanks.  One last thing.  Would you be able to perform the same test
> against a server running unstable's libapache2-mod-svn, apache2, etc.?

I had to install a new machine, hence the delay.

Another thing I noticed: If I replace "* =" by "* = r" (which in my case
means "any valid user") as the last line in the SVN authz file, "svn ls"
works.  I can't commit, though.

Andreas


|Running pre_send hooks
|compress: Initialization.
|compress: Initialization.
|Sending request headers:
|OPTIONS /svn-krb/${REPO} HTTP/1.1
|User-Agent: SVN/1.7.19 neon/0.29.6
|Keep-Alive:
|Connection: TE, Keep-Alive
|TE: trailers
|Host: ${FQDN}
|Content-Type: text/xml
|Accept-Encoding: gzip
|DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
|DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
|DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
|Content-Length: 104
|Accept-Encoding: gzip
|
|Sending request-line and headers:
|Doing DNS lookup on ${FQDN}...
|req: Connecting to ${IPv4}:443
|Sending request body:
|Body block (104 bytes):
|[]
|Request sent; retry is 0.
|[status-line] < HTTP/1.1 401 Unauthorized
|[hdr] Date: Thu, 03 Sep 2015 17:13:36 GMT
|Header Name: [date], Value: [Thu, 03 Sep 2015 17:13:36 GMT]
|[hdr] Server: Apache/2.4.16 (Debian)
|Header Name: [server], Value: [Apache/2.4.16 (Debian)]
|[hdr] Content-Length: 468
|Header Name: [content-length], Value: [468]
|[hdr] Keep-Alive: timeout=5, max=100
|Header Name: [keep-alive], Value: [timeout=5, max=100]
|[hdr] Connection: Keep-Alive
|Header Name: [connection], Value: [Keep-Alive]
|[hdr] Content-Type: text/html; charset=iso-8859-1
|Header Name: [content-type], Value: [text/html; charset=iso-8859-1]
|[hdr]
|End of headers.
|Running post_headers hooks
|Reading 468 bytes of response body.
|Got 468 bytes.
|Read block (468 bytes):
|[
|
|401 Unauthorized
|
|Unauthorized
|This server could not verify that you
|are authorized to access the document
|requested.  Either you supplied the wrong
|credentials (e.g., bad password), or your
|browser doesn't understand how to supply
|the credentials required.
|
|Apache/2.4.16 (Debian) Server at ${FQDN} Port 443
|
|]
|Running post_send hooks
|Request ends, status 401 class 4xx, error line:
|401 Unauthorized
|Running destroy hooks.
|Request ends.
|svn: E175002: Unable to connect to a repository at URL 
'https://${FQDN}/svn-krb/${REPO}'
|svn: E175002: Server sent unexpected return value (401 Unauthorized) in 
response to OPTIONS request for 'https://${FQDN}/svn-krb/${REPO}'
|sess: Destroying session.
|sess: Destroying session.

Bug#797712: failing with gpg2, error reading key: Legacy key

[Guilhem Moulin]

On Thu, 03 Sep 2015 at 19:14:59 +0200, Eduard Bloch wrote:
> * Guilhem Moulin [Thu, Sep 03 2015, 11:46:42AM]:
>> Also, do you have any v3 keys in your keyring?  What's the output of
>> 
>> gpg --homedir ~/.caff/gnupghome.alt --with-fingerprint --with-fingerprint 
>> --with-colons --list-keys |
>> grep -icE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$'
>> 
>> (you need to set ‘--with-fingerprint’ twice to list subkey fingerprints
>> as well.)
> 
> 84
> 
> ;-) Have I mentioned that I installed signing-party a decade ago and used it
> rarelly, like once in 2-3 years?

No you did not :-)  v3 keys completely broken and are no longer
supported by GnuPG 2.1.  Caff support for v3 keys was somewhat hackish
at first (2004-2005), then was completely removed in 2005 (r110).

Currently it warns you of the existence of v3 master keys (and ignore
them), but there is no special handling of v3 subkeys.  It looks like
GnuPG 2.1 chokes on v3 (sub)keys; possibly because a trust value has
been assigned to those.

How many of these v3 keys are v3 subkeys of a v4 master key?  Does it
help to delete them?

gpg --homedir ~/.caff/gnupghome.alt --trust-model=always --with-fingerprint 
--with-colons --list-keys |
grep -iE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$' >/tmp/v3-keys

wc -l /tmp/v3-keys

xargs -a /tmp/v3-keys gpg --homedir ~/.caff/gnupghome.alt 
--trust-model=always --batch --delete-keys

caff --debug $KEYID

The above only deal with v3 master keys.  As for v3 subkeys,

gpg --homedir ~/.caff/gnupghome.alt --trust-model=always --with-fingerprint 
--with-fingerprint --with-colons --list-keys |
grep -iE '^fpr:([^:]*:){8}[0-9A-F]{32}(:.*)?$' >/tmp/v3-subkeys

wc -l /tmp/v3-subkeys

xargs -a /tmp/v3-subkeys gpg --homedir ~/.caff/gnupghome.alt 
--trust-model=always --batch --delete-keys

caff --debug $KEYID


Thanks for your help in cornering this bug ;-)
Cheers,
-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#797917: Actually this bug makes clang not so useful

[Gianfranco Costamagna]

Control: reassign -1 clang-3.5
Control: retitle -1 clang should use the new CXX11_ABI
Control: severity -1 serious

Well this bug makes clang almost useless with the new gcc compiler.

according to [1] there might be no fix.

I hope somebody with more knowledge can come up with a fix, 
-D_GLIBCXX_USE_CXX11_ABI
seems to be not working



[1] 
http://clang-developers.42468.n3.nabble.com/GCC-5-1-ABI-GLIBCXX-USE-CXX11-ABI-td4045387.html
cheers,

G.

Bug#797855: spice-gtk:spice-common/common/generated_* not reliably generated from source

[Chris Lamb]

Hi Liang,

> spice_codegen.py is called in your build procedure, but not in mine.

Sure, no problem :)  Without codegen being called:

 
https://reproducible.debian.net/rbuild/unstable/amd64/spice-gtk_0.29-1.rbuild.log

With codegen being called:

 
https://reproducible.debian.net/logs/unstable/amd64/spice-gtk_0.29-1.build2.log.gz

If it helps, here is a diff between the two:

 
https://reproducible.debian.net/logdiffs/unstable/amd64/spice-gtk_0.29-1.diff.gz


Regards,

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

Bug#797906: jessie-pu: package dolibarr/3.5.5+dfsg1-2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On 2015-09-03 15:44, Laurent Destailleur (eldy) wrote:

A security error CVE-2015-3935 was reported for Dolibarr ERP CRM
package. This bug is fixed into official package 3.5.7 of Dolibarr.
Package 3.5.7 is a maintenance release compared to 3.5.5 and contains
only fixes. But not only bugs reported to debian, it includes also
other fixes (but they are all related to stability or security).
I think it is a better solution to validate this maintenance release
based on the new upstream version of Dolibarr than applying a patch of
the only CVE-2015-3935.

[...]

So I just need to know if it's ok to push such a version 3.5.7 (fixes
for 3.5.* branch) instead of only one fix for only the few (the only)
reported debian bugs,
since it provides more stability and is or me a more secured process.


Certainly not whilst neither the CVE fix nor 3.5.7 are in unstable 
(which still has 3.5.5 without the fix, afaict).


Regards,

Adam

Bug#797712: failing with gpg2, error reading key: Legacy key

[Eduard Bloch]

Hallo,
* Guilhem Moulin [Wed, Sep 02 2015, 11:49:43PM]:
> Hi,
> 
> On Wed, 02 Sep 2015 at 22:20:03 +0200, Eduard Bloch wrote:
> > * Guilhem Moulin [Tue, Sep 01 2015, 10:43:19PM]:
> >> On Tue, 01 Sep 2015 at 22:11:23 +0200, Eduard Bloch wrote:
> > But I saw no trustdb check when caff is working...
> 
> caff doesn't create a trust database because it doesn't rely on the WoT

caff doesn't but, for example, an obvious step after a KSP is to run gpg
--homedir ~/.caff/gnupghome --import something.gpg (the keyring
distributed for that signing party). This simple operation gets you a
trustdb installed into ~/.caff/gnupghome . And yes, I learned about
--key-file option now after reading the manpage.

However, I am no longer sure that my problem is really related to
trustdb. I just restored the suspicious gnupghome directory then removed
trustdb.gpg there and tried again. Result: the original error "Legacy
key". So, the apparent fix via single --check-db run is probably a red
herring and the original issue (failing automated migration) still
persists.

> > This makes me wonder, I see --no-auto-check-trustdb in your gpg options... 
> > maybe this is the
> > key? It needs to update trustdb prior to migration but it's forbidden.
> 
> Then this should be forwarded to upstream GnuPG. --trust-model=always
> should skip any operation on the trust database, including trust value
> updates.

Ok... it's not explained like this in the manpage but I'd assume it.

> > It shouldn't do anything if no update is needed. I checked that:
> > restored broken dir, reproduced mentioned problem, called the command,
> > watched the update finished, called caff again, and it worked just fine.
> 
> Yes it does something: if a there was no ‘~/.caff/gnupghome/trustdb.gpg’
> file then it is created.  IMHO it's a quite ugly hack to involve a trust
> database operation since caff has never relied on a trust model.  I'll
> rather forward the issue to GnuPG.

Agreed. This whole thing looks more and more like a gpg2 issue.

> Your test shows that gpg2 is able to perform the keyring migration (with
> --trust-model=always) on a fresh ‘~/.caff/gnupghome’, ie, when no trust
> database exists.  So this should only be an issue if you have been
> fiddling around with ‘gpg --homedir ~/.caff/gnupghome’ manually, right?

I only said that --check-trustdb has fixed it and I suspected some
things from that moment. And "manually" is such an ugly word...

Regards,
Eduard.


signature.asc
Description: Digital signature

Bug#797917: libboost-program-options-dev: clang++: undefined reference to boost::program_options::arg

[Danny Edel]

Package: libboost-program-options-dev
Version: 1.58.0.1

Dear maintainer,

I cannot link against recent boost_program_options with clang++, while
it works fine with g++. I have attached a small test program that
demonstrates the bug.

$ g++ -o options options.cpp -lboost_program_options
$ ./options --filename asdf
Filename is asdf
(No problem, works as intended)

$ clang++ -o options options.cpp -lboost_program_options

/tmp/options-18b2b2.o: In function
`boost::program_options::typed_value, char>::name() const':

options.cpp:(.text._ZNK5boost15program_options11typed_valueINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcE4nameEv[_ZNK5boost15program_options11typed_valueINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcE4nameEv]+0x4c):
undefined reference to `boost::program_options::arg'

clang: error: linker command failed with exit code 1 (use -v to see
invocation)


I believe this is because the symbol is only exported using the new
[abi:cxx11] which apparently g++ understands but clang++ doesn't.

$ nm -D /usr/lib/x86_64-linux-gnu/libboost_program_options.so | c++filt
| grep boost::program_options::arg
0027d920 B boost::program_options::arg[abi:cxx11]


I am running debian sid, so these should be quite recent versions:

$ g++ --version
g++ (Debian 5.2.1-15) 5.2.1 20150808

$ clang++ --version
Debian clang version 3.5.2-2 (tags/RELEASE_352/final) (based on LLVM 3.5.2)

I also tested with clang-3.8 package, same results (undefined reference
to boost::program_options::arg)

$ clang++-3.8 --version
Debian clang version 3.8.0-svn245286-1 (trunk) (based on LLVM 3.8.0)


Is it possible to compile boost_program_options (and possibly other
not-pure-header-parts of boost) in a dual-abi way, so that Clang can
link to it aswell? Or did I miss a flag on calling clang as a user?


On a jessie VM, the above commands work as expected, so from a user
perspective, this is a regression. I'm not sure whether this is a boost
or a clang issue, please redirect if I reported against the wrong package.


Thank you,

- Danny
#include 
#include 
#include 

using namespace std;
using namespace boost::program_options;

int main(int argc, char** argv) {
	string fname;
	options_description opts("Options");
	opts.add_options()
		("filename,f", value()->required(),
		 "Specify file name");

	variables_map vm;
	store( command_line_parser(argc,argv).options(opts).run(), vm);
	notify(vm);

	cout << "Filename is " << fname << endl;
	return 0;
}

Bug#797906: jessie-pu: package dolibarr/3.5.5+dfsg1-2

[Laurent Destailleur (aka Eldy)]

Sorry. I didn't understood your answer (my english is not my mother
language).

You are speaking about "unstable".

I am speaking about pushing a CVE fix into stable 3.5.5. This fix is part
of a patch that include other fix and this patch is called 3.5.7.
My question is can I push fix1 + fix2 + fix3 with "1 push, called 3.5.7"
even if only fix1 was declared on debian.


My understood is that unstable has a different cycle than stable and is
dedicated for next debian stable. So version that will be pushed into
"unstable" will be 3.8 (a major release that will include upstream with fix
found into maintenance official project release of 3.5.* branch, 3.6.*
branch, 3.7.* branch + new features, so including the CVE included in 3.5.7
and not yet pushed to debian becuse debian is 3.5.5)
Do you mean
* i need first to update upstream of "unstable" with 3.8 (so it will
include the CVE fix) to be ok to fix stable with the maintenances fixes of
3.5.7
or
* i can't push 3.5.7 into stable even if it contains only CVE or stability
fix compared to 3.5.5, and I must prepare a 3.5.5bis that will include only
the CVE reported to debian and not other discovered and fixed into 3.5.7
official projet ?




2015-09-03 18:43 GMT+02:00 Adam D. Barratt :

> Control: tags -1 + moreinfo
>
> On 2015-09-03 15:44, Laurent Destailleur (eldy) wrote:
>
>> A security error CVE-2015-3935 was reported for Dolibarr ERP CRM
>> package. This bug is fixed into official package 3.5.7 of Dolibarr.
>> Package 3.5.7 is a maintenance release compared to 3.5.5 and contains
>> only fixes. But not only bugs reported to debian, it includes also
>> other fixes (but they are all related to stability or security).
>> I think it is a better solution to validate this maintenance release
>> based on the new upstream version of Dolibarr than applying a patch of
>> the only CVE-2015-3935.
>>
> [...]
>
>> So I just need to know if it's ok to push such a version 3.5.7 (fixes
>> for 3.5.* branch) instead of only one fix for only the few (the only)
>> reported debian bugs,
>> since it provides more stability and is or me a more secured process.
>>
>
> Certainly not whilst neither the CVE fix nor 3.5.7 are in unstable (which
> still has 3.5.5 without the fix, afaict).
>
> Regards,
>
> Adam
>



-- 
EMail: e...@destailleur.fr
Web: http://www.destailleur.fr

Google+: https://plus.google.com/+LaurentDestailleur/
Facebook: https://www.facebook.com/Destailleur.Laurent
Twitter: http://www.twitter.com/eldy10

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for
Dolibarr project via Paypal: cont...@destailleur.fr)
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for
AWStats project via Paypal: cont...@destailleur.fr)
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

Bug#785057: wiki.debian.org: unblock IPredator VPN

[DNS]

Hi guys,

i got the same problem that i use ippredator and it seems their whole ip
range is blocked for the wiki :-( wasn't it only single ips spammin?

In germany some freifunk communities use ippredator as vpn so all the
clients of these nodes won't be able to see any debian wiki page...
isn't it possible to only block write access at least?

Actually i couldn't find any other page on the net blocking ippredator
than wiki.debian.org, and no dnsbl has an entry of a ippredator ips that
ive checked http://multirbl.valli.org ...so i really wonder

Greetings

Bug#797919: Exim configuration breaks with long header lines

[Alex Schumann]

Package: exim4
Version: 4.80-7+deb7u



The SMTP Spec states that:

> 2.1.1. Line Length Limits
>   There are two limits that this standard places on the number of
>   characters in a line. Each line of characters MUST be no more than
>   998 characters, and SHOULD be no more than 78 characters, excluding
>   the CRLF.

However, if exim gets a message in the queue whose line length is longer
than 998 chars it will happily send it to other hosts, thus violating the
protocol.

In addition, MANY  MTAs (including gmail) will respond to an over-length
line by hanging up on the connection (TCP RST) without any error message.
Exim misclassifies this as a host error (as documented in
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-smtp_processing.html#SECToutSMTPerr)


As a result, sending messages that contain long header lines to a local
server for delivery to a remote site  can interrupt delivery of legitimate
messages to that remote site. This has been seen with certain "References"
headers.

As a proposed work-around, a way might be found to limit long header length
in the ACL area, to push the problem up stream toward its source.

I have also reported this upstream to exim, where a more proper solution is
being considered: https://bugs.exim.org/show_bug.cgi?id=1684

Expected behavior: A  message with too-long header line bounces back to
sender with useful message

Observed behavior: All messages to the same MTA as the destination of the
message with malformed header experience delays. Log shows "closed
connection in response to sending data block", and "retry time not reached
for any host"

How to reproduce:

Use netcat or telnet to connect to exim, and send it an email containing a
header such as:

Subject: test
From: your@address
To: your@address
x-test:
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

Bug#797906: jessie-pu: package dolibarr/3.5.5+dfsg1-2

[Adam D. Barratt]

On Thu, 2015-09-03 at 19:05 +0200, Laurent Destailleur (aka Eldy) wrote:
[...]
> Do you mean 
> * i need first to update upstream of "unstable" with 3.8 (so it will
> include the CVE fix)

That would be the first step, yes. Then we'd consider which of:

> to be ok to fix stable with the maintenances fixes of 3.5.7
> or
> * i can't push 3.5.7 into stable even if it contains only CVE or
> stability fix compared to 3.5.5, and I must prepare a 3.5.5bis that
> will include only the CVE reported to debian and not other discovered
> and fixed into 3.5.7 official projet ?

would be most appropriate.

Regards,

Adam

Bug#797916: ITP: path.py -- module wrapper for os.path

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: path.py
  Version : 8.1
  Upstream Author : Mikhail Gusarov
* URL : https://github.com/jaraco/path.py
* License : Expat
  Programming Lang: Python
  Description : A module wrapper for os.path
 path.py implements a path objects as first-class entities, allowing common
 operations on files to be invoked on those path objects directly.

The newest ipython depends on pickleshare, which depends on this
package. I'll maintain it within the Debian Python Modules Team.

Thanks,

Snark on #debian-python

Bug#797149: konsole: no longer possible to re-order tabs

[Hillel Lubman]

This bug is now fixed upstream: 
https://bugs.kde.org/show_bug.cgi?id=347094 [1]


Until this will come to Debian, you can use a keyboard shortcut 
workaround. Ctrl+Shift+LeftArrow / Ctrl+Shift+RightArrow.



Links:
--
[1] https://bugs.kde.org/show_bug.cgi?id=347094

Bug#797918: python3-matplotlib: Matplotlib startup feels extremely slow

[Nikolaus Rath]

Package: python3-matplotlib
Version: 1.4.2-3.1
Severity: normal

Since upgrading from Wheezy, the startup of matplotlib seems extremely
slow. Scripts that previously appeared to show results instantanously 
now take multiple seconds until the first plot appears.

I tried debugging this with a very simple test script:

#!/usr/bin/env python3
import matplotlib.pyplot as plt
plt.plot([1, 2, 3])
plt.show()

Looking at the strace output, I found a large number of seemingly
completely pointless lseek() calls. For example:

open("/usr/lib/python3.4/encodings/__pycache__/unicode_escape.cpython-34.pyc", 
O_RDONLY|O_CLOEXEC) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=1842, ...}) = 0
lseek(8, 0, SEEK_CUR)   = 0
fstat(8, {st_mode=S_IFREG|0644, st_size=1842, ...}) = 0
read(8, 
"\356\f\r\n\240#5T\240\4\0\0\343\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0@\0\0"..., 
1843) = 1842
read(8, "", 1)  = 0
close(8)= 0
open("/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", O_RDONLY|O_CLOEXEC) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x7ffe52ac0a90) = -1 ENOTTY (Inap
fstat(8, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
lseek(8, 0, SEEK_CUR)   = 0
fcntl(8, F_DUPFD_CLOEXEC, 0)= 9
fcntl(9, F_GETFL)   = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(9, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f5403f06000
lseek(9, 0, SEEK_CUR)   = 0
lseek(8, 0, SEEK_CUR)   = 0
lseek(9, 0, SEEK_SET)   = 0
fstat(9, {st_mode=S_IFREG|0644, st_size=741536, ...}) = 0
lseek(9, 741376, SEEK_SET)  = 741376
read(9, "+\0++"..., 160) = 160
lseek(9, 0, SEEK_SET)   = 0
lseek(9, 0, SEEK_SET)   = 0
lseek(9, 0, SEEK_SET)   = 0
read(9, "\0\1\0\0\0\23\1\0\0\4\FFTMh\275QN\0\0\1<\0\0\0\34GDEF"..., 4096) = 
4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
lseek(9, 4096, SEEK_SET)= 4096
[...]

Note that there are no other syscalls between the lseek() - Python simply 
seeks to the same position over and over again. I am not 100% sure that
this is the cause of the slow-down, but it certainly looks like
something is wrong here.

$ strace -o log python3 test.py
$ grep lseek log | wc -l
1871

$ strace -o log python3 -c 'print("Hello")'
Hello
$ grep lseek log | wc -l
31


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

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

Versions of packages python3-matplotlib depends on:
ii  libc6   2.19-18
ii  libfreetype62.5.2-3
ii  libgcc1 1:4.9.2-10
ii  libjs-jquery1.7.2+dfsg-3.2
ii  libjs-jquery-ui 1.10.1+dfsg-1
ii  libpng12-0  1.2.50-2+b2
ii  libstdc++6  4.9.2-10
ii  libtcl8.6   8.6.2+dfsg-2
ii  libtk8.68.6.2-1
ii  python-matplotlib-data  1.4.2-3.1
ii  python3 3.4.2-2
ii  python3-dateutil2.2-2
ii  python3-nose1.3.4-1
ii  python3-numpy [python3-numpy-abi9]  1:1.8.2-2
ii  python3-pyparsing   2.0.3+dfsg1-1
ii  python3-six 1.8.0-1
ii  python3-tz  2012c+dfsg-0.1

Versions of packages python3-matplotlib recommends:
ii  python3-pil  2.6.1-2
ii  python3-tk   3.4.2-1+b1

Versions of packages python3-matplotlib suggests:
pn  dvipng
ii  ghostscript   9.06~dfsg-2+deb8u1
ii  gir1.2-gtk-3.03.14.5-1
ii  inkscape  0.48.5-3
ii  ipython3  2.3.0-2
ii  librsvg2-common   2.40.5-1
ii  python-matplotlib-doc 1.4.2-3.1
pn  python3-cairocffi 
ii  python3-gi [python3-gobject]  3.14.0-1
ii  python3-gi-cairo  3.14.0-1
ii  python3-pyqt4 4.11.2+dfsg-1
ii  python3-scipy 0.14.0-2
ii  python3-sip   4.16.4+dfsg-1
pn  python3-tornado   

Bug#675322: ITA: at -- Delayed job execution and batch processing

[Jose M Calhariz]

I have done preparation work for a new Debian package 3.1.16-2.
Created a new upstream version 3.1.17 with minor changes, just to
check how I will release new versions in the future.  All the work is
published in the git repository of at in collab-maint.

I am waiting for my sponsor to upload the Debian package of at.

Jose M Calhariz

-- 
--
Fulano afirmã, mas o Arnold Swarzenegar.


signature.asc
Description: Digital signature

Bug#797914: ITP: jasp -- graphical statistical package designed to familiar to users of SPSS

[Jonathon]

Package: wnpp
Severity: wishlist
Owner: Jonathon 

* Package name: jasp
  Version : 0.7.1.12
  Upstream Author : Jonathon Love 
* URL : https://jasp-stats.org
* License : AGPL
  Programming Lang: C++, JavaScript, R
  Description : graphical statistical package designed to familiar to users 
of SPSS

 JASP is a graphical statistical package designed to familiar to users of SPSS, 
which provides both classical and Bayesian statistical methods

Bug#797636: RFS: variety/0.5.4-1 [ITP]

[Gianfranco Costamagna]

Hi James,


>Uhhh, I don't see it either. Upstream uses distutils, and I've never

>changed the setup.py myself when I packaged it.


you might want to ask them to change :)


>Noted. uscan is called with a bunch of arguments in get-orig-source to
>comply with policy, so I assume they do something different than plain
>"uscan" on the command line.


yes, but the plain uscan should work too


>To be honest, I haven't got a clue what these errors are about. setup.py
>is building something and trying to find dependencies, I guess.
>I've added a bunch of build-deps which suppress the "Python module not
>found" errors for external libraries (bs4, dbus, etc.), but the internal
>Variety libraries (varietyconfig, IVarietyPlugin, etc.) still raise
>errors. None of it is fatal though, and I can still build it with
>pbuilder and such.
>Related: https://answers.launchpad.net/variety/+question/213828
>
>I haven't patched the setup.py file yet, since install_requires needs
>setuptools instead of distutils as far as I can tell. Is switching to
>setuptools for this a good idea?
>



it might be, but in a future release.

Built,
thanks for your contribution to Debian!

cheers,

G.

Bug#752517: aptitude: wrong %v %V order in man aptitude section -F

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending

Hi Manuel,

2014-06-24 13:05 Manuel:

Package: aptitude
Version: 0.6.11-1
Severity: normal

man aptitude section -F says

-F , --display-format 
Specify the format which should be used to display output from the search and 
versions commands. For instance, passing “%p %V %v” for  will display a 
package's name, followed by its currently installed version and its available version 
...
[...]


Thanks, this will be fixed in the next upload.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#795288: nmu: libsigc++-2.0_2.4.1-2

[Jonathan Wiltshire]

On Thu, Sep 03, 2015 at 09:56:50AM +0100, Edmund Grimley Evans wrote:
> Control: severity -1 important
> 
> synfigstudio is failing to build because of this:
> 
> https://buildd.debian.org/status/fetch.php?pkg=synfigstudio=arm64=1.0-1%2Bb2=1441235058
> 
> The "synfig" command gives:
> 
>  *** Error in `synfig': munmap_chunk(): invalid pointer: 0x14e27940 
> ***

Could you outline why you believe a binNMU would fix the issue please?

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#797947: RM: kcometen4 -- RoQA; incompatible with Plasma 5

[Felix Geyer]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the kcometen4 source and binary package.
kcometen4 is a kscreensaver that KDE Plasma 5 does not support anymore.

Thanks,
Felix

Bug#797771: RFS: [ITP] tzlocal/1.2-1

[Henrique de Moraes Holschuh]

On Thu, 03 Sep 2015, Gianfranco Costamagna wrote:
> The question was actually:
> 
> do you think we should rename now that is in the new queue?

Yes, it is not too late.

> we can upload as soon as it is accepted, or ask ftpmasters to kick it out
> and upload again.

I think it is likely better to ask them to remove the upload with the
"wrong" name and upload it again.  That way, a package with the "tzlocal"
name will not have existed in any of the archives (outside of NEW) for any
length of time.

> Not sure this new upload will automatically override the existing one.

I am not sure, either.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh