Bug#851641: linux-image-3.16.0-4-amd64 panic:double fault

[张永肃]

hi Ben
Thanks very much for your reply.
> I looked for information on this hardware, and the first thing I found
> was that you previously reported several crashes to Debian on this same
> hardware:
> https://bugs.debian.org/834487
> https://bugs.debian.org/838658
> https://bugs.debian.org/847839

we don't see any hardware error message or ECC error. (we use mcelog
and the servers have BMC)

we found many machines happened this panic . if it is hardware
problem, I think maybe panic in different stacks.
and I found the same panic in another hardware,too:

[308495.512050] PANIC: double fault, error_code: 0x0
[308495.512077] CPU: 4 PID: 161103 Comm: parameter_serve Not tainted
3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u2
[308495.512079] Hardware name: Inspur SA5248M4/X10DRT-PS, BIOS 2.01 11/21/2016
[308495.512080] task: 883b5dfb0a20 ti: 883f3a9b task.ti:
883f3a9b
[308495.512082] RIP: 0010:[]  []
sysret_check+0x1/0x4e
[308495.512088] RSP: 0018:ffd8  EFLAGS: 00010217
[308495.512090] RAX:  RBX: 816900f0 RCX:

[308495.512091] RDX: 883f3a9b3fd8 RSI: 883f3a9b3d88 RDI:
883f3c885040
[308495.512092] RBP:  R08: 883f3a9b R09:
b629
[308495.512092] R10: 00010498cc7d R11:  R12:
c9ffe0b8
[308495.512093] R13: c9ffe000 R14: 0001 R15:

[308495.512095] FS:  7fb567de3700() GS:88407f90()
knlGS:
[308495.512096] CS:  0010 DS:  ES:  CR0: 80050033
[308495.512097] CR2: ffc8 CR3: 003f44e3 CR4:
003407e0
[308495.512098] DR0:  DR1:  DR2:

[308495.512099] DR3:  DR6: fffe0ff0 DR7:
0400
[308495.512100] Stack:
[308495.512119] BUG: unable to handle kernel paging request at ffd8
[308495.512149] IP: [] show_stack_log_lvl+0x108/0x170
[308495.512181] PGD 1816067 PUD 1818067 PMD 0
[308495.512208] Oops:  [#1] SMP
[308495.512224] Modules linked in: 8021q garp stp mrp llc tcp_westwood
x86_pkg_temp_thermal coretemp kvm_intel kvm iTCO_wdt
iTCO_vendor_support crc32_pclmul aesni_intel ast aes_x86_64 evdev lrw
joydev gf128mul ttm glue_helper drm_kms_helper ablk_helper cryptd drm
i2c_algo_bit pcspkr i2c_i801 lpc_ich mei_me i2c_core shpchp mei
mfd_core wmi tpm_tis tpm ipmi_watchdog processor thermal_sys
acpi_power_meter acpi_pad button ipmi_si ipmi_poweroff ipmi_devintf
ipmi_msghandler autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid
sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul
crct10dif_common crc32c_intel ahci libahci ehci_pci libata xhci_hcd
ehci_hcd ixgbe dca ptp usbcore scsi_mod pps_core usb_common mdio
[308495.512564] CPU: 4 PID: 161103 Comm: parameter_serve Not tainted
3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u2
[308495.512600] Hardware name: Inspur SA5248M4/X10DRT-PS, BIOS 2.01 11/21/2016
[308495.512627] task: 883b5dfb0a20 ti: 883f3a9b task.ti:
883f3a9b
[308495.512655] RIP: 0010:[]  []
show_stack_log_lvl+0x108/0x170
[308495.512690] RSP: 0018:88407f904e98  EFLAGS: 00010046
[308495.512711] RAX: ffe0 RBX: ffd8 RCX:
88407f8fffc0
[308495.512738] RDX:  RSI: 88407f904f58 RDI:

[308495.512765] RBP: 88407f903fc0 R08: 81706753 R09:
05b4
[308495.512792] R10:  R11: 88407f904c2e R12:
88407f904f58
[308495.512819] R13:  R14: 81706753 R15:

[308495.512846] FS:  7fb567de3700() GS:88407f90()
knlGS:
[308495.512876] CS:  0010 DS:  ES:  CR0: 80050033
[308495.512898] CR2: ffd8 CR3: 003f44e3 CR4:
003407e0
[308495.512925] DR0:  DR1:  DR2:

[308495.512952] DR3:  DR6: fffe0ff0 DR7:
0400
[308495.512979] Stack:
[308495.512989]  0008 88407f904ef0 88407f904eb0
ffd8
[308495.513021]  88407f904f58 ffd8 883b5dfb0a20
0040
[308495.513052]  0001  810165fe
88407f904f58
[308495.513084] Call Trace:
[308495.513096]  <#DF>
[308495.513106]
[308495.513117]  [] ? show_regs+0x7e/0x1f0
[308495.513136]  [] ? df_debug+0x1f/0x30
[308495.513158]  [] ? do_double_fault+0x78/0xf0
[308495.513181]  [] ? double_fault+0x28/0x30
[308495.513204]  [] ? sysret_check+0x1/0x4e
[308495.513225]  <>
[308495.513236]  
[308495.513246] Code: 67 70 81 31 c0 89 54 24 08 48 89 0c 24 48 8b 5b
f8 e8 5b 93 4f 00 48 8b 0c 24 8b 54 24 08 85 d2 74 05 f6 c2 03 74 48
48 8d 43 08 <48> 8b 33 48 c7 c7 4b 67 70 81 89 54 24 14 48 89 4c 24 08
48 89
[308495.513381] RIP  [] show_stack_log_lvl+0x108/0x170
[308495.513408]  RSP 
[308495.513423] CR2: ffd8

> Are you using KVM?
we don't use KVM, the application is just 

Bug#822974: [pkg-gnupg-maint] Backport of GnuPG 2.1

[Daniel Kahn Gillmor]

Hi Luca--

On Mon 2017-01-16 16:14:01 -0500, Luca Capello wrote:
> On Thu, 06 Oct 2016 10:23:25 -0400, Daniel Kahn Gillmor wrote:
>> On Thu 2016-10-06 05:17:54 -0400, Thomas Goirand wrote:
>> > It'd be nice to have a backport of GnuPG 2.1 to Jessie, so that one
> [...]
>> https://bugs.debian.org/822974
>> 
>> last week, the changes i was waiting for did indeed drop into testing,
>> but we have a few minor bugs that i'm in the process of cleaning up
>> which i'd like to avoid inflicting on users of jessie-backports.
>> 
>> It'll happen soon, i promise :)
>
> Any news on this?  At work we have recently deployed OpenPGP (via
> YubiKey 4) for all the sysadmins, installing GnuPG 2 on jessie with the
> following trick:

there is a known bug (in particular, 849845, upstream 2902) affecting
dirmngr in stretch and sid, which makes it very difficult for certain
common configurations to retrieve keys from the network. i'm reluctant
to inflict them on jessie users, and am hoping to get that resolved
before we go with the backport.

> From a quick look, the following are the Build-Depends: needing a
> backport as well:
>
>   libassuan-dev
>   libgcrypt20-dev
>   libgpg-error-dev
>   libksba-dev
>   libnpth0-dev
>
> I have started working on libassuan-dev and go on if no one else is
> doing that already, the idea being a *full* bakcport, i.e. completely
> replacing GnuPG 1.

yes, that's the plan.  backporting these -dev packages to jessie should
be a relatively straightforward process.  If you're up for helping with
that to lay the groundwork for an updated gnupg package, that'd be
great.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#841143: [pkg-gnupg-maint] Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup)

[Daniel Kahn Gillmor]

Hi gniibe--

Thanks for this code review, it's much appreciated!

On Mon 2017-01-16 23:21:15 -0500, NIIBE Yutaka wrote:
> For me, it is a bit difficult to apply the fourth patch only.  So, I
> seek the update of the patch:
>
> 0003-agent-Avoid-tight-timer-tick-when-possible.patch
>
> How about changing the need_tick function, instead?  My intention is to
> make the behavior of gpg-agent as similar as upstream version.

fwiw, i don't want the behavior to be exactly the same as upstream -- i
don't want gpg-agent to wake up every few seconds on platforms where it
shouldn't need to, for example :/

but the change i think you're proposing might be OK -- if it does the
frequent wakeups when it's trying to shut down...

> I mean, changing the first hunk of the patch of gnupg/agent/gpg-agent.c,
> like this (adding the check against shutdown_pending).
>
> --- gnupg.orig/agent/gpg-agent.c
> +++ gnupg/agent/gpg-agent.c
> @@ -2267,6 +2267,29 @@ create_directories (void)
>  }
>  
>  
> +static int
> +need_tick (void)
> +{
 […]
> +  /* if a shutdown was requested, we wait all connections closing.  */
> +  if (shutdown_pending)
> +return 1;

You're just talking about adding this one test, right?

It seems to me like this shouldn't be necessary, since i'd have thought
the child channel (chan_9 in your example) receiving eof would make the
main thread wake back up.

can you explain why that wouldn't be the case?  is there some way to
cause the main thread to trigger a loop when the child channel closes?
Ideally, we don't want to wait a timer tick (up to 2 seconds) before
shutting down.  if we know we're shutting down and the last client has
closed, we should just fall into the main loop itself, right?  The
entire time between when the shutdown is requested and when we finally
shut down is a time that socket is locked and new clients can't
effectively connect, right?

i'm happy to apply your proposed change if there's no better way (it's
certainly better than the indefinite hang you've caught), but it still
feels sloppier than i'd want in general.

any thoughts?

  --dkg


signature.asc
Description: PGP signature

Bug#851657: [git-buildpackage/master] git-pbuilder: Pass --debbuildopts to pbuilder instead of pdebuild

[Guido Günther]

tag 851657 pending
thanks

Date:   Wed Jan 18 08:23:21 2017 +0100
Author: Guido Günther 
Commit ID: 5211ab98f09f77082841538a1b3db935b2f21a2f
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=5211ab98f09f77082841538a1b3db935b2f21a2f
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=5211ab98f09f77082841538a1b3db935b2f21a2f

git-pbuilder: Pass --debbuildopts to pbuilder instead of pdebuild

This requires at least pbuilder 0.228

Closes: #851657

  

Bug#223915: tk-brief: diff for NMU version 5.10-0.1

[Christoph Biedl]

Control: tags 223915 + patch
Control: tags 223915 + pending
Control: tags 249196 + pending

Dear maintainer,

find attached the debdiff (limited to debian/ for an NMU for tk-brief
(versioned as 5.10-0.1), upload to DELAYED/0[*) will follow in a few hours.
Please feel free to tell me if I should delay it longer.

It also switches to the latest upstream version, removes some cruft
from debian/ and makes a few switches in debian/rules.

Regards,

Christoph

[*] For way more than seven days without activity and no indication
that a fix is in progress: 0 daysControl: tags 223915 + patch

Binary files /tmp/XYNCc1rzpn/tk-brief-5.9/dante-article_german.ps.gz and 
/tmp/rjgcX_KHdV/tk-brief-5.10/dante-article_german.ps.gz differ
Binary files /tmp/XYNCc1rzpn/tk-brief-5.9/dante-article-german.ps.gz and 
/tmp/rjgcX_KHdV/tk-brief-5.10/dante-article-german.ps.gz differ
diff -Nru tk-brief-5.9/debian/changelog tk-brief-5.10/debian/changelog
--- tk-brief-5.9/debian/changelog   2010-05-11 06:02:33.0 +0200
+++ tk-brief-5.10/debian/changelog  2017-01-18 07:31:01.0 +0100
@@ -1,3 +1,11 @@
+tk-brief (5.10-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream version. Closes: #249196
+  * Build as a package with orig tarball. Closes: #223915
+
+ -- Christoph Biedl   Wed, 18 Jan 2017 
07:31:01 +0100
+
 tk-brief (5.9-1.1) unstable; urgency=low
 
   [Jari Aalto]
diff -Nru tk-brief-5.9/debian/debhelper.log tk-brief-5.10/debian/debhelper.log
--- tk-brief-5.9/debian/debhelper.log   2010-05-02 00:54:52.0 +0200
+++ tk-brief-5.10/debian/debhelper.log  1970-01-01 01:00:00.0 +0100
@@ -1,16 +0,0 @@
-dh_installdirs
-dh_install
-dh_installman
-dh_installman
-dh_installdocs
-dh_installexamples
-dh_installmenu
-dh_installchangelogs
-dh_link
-dh_compress
-dh_fixperms
-dh_installdeb
-dh_gencontrol
-dh_md5sums
-dh_builddeb
-dh_installdirs
diff -Nru tk-brief-5.9/debian/docs tk-brief-5.10/debian/docs
--- tk-brief-5.9/debian/docs2003-10-25 22:15:52.0 +0200
+++ tk-brief-5.10/debian/docs   2017-01-18 07:24:24.0 +0100
@@ -1 +1 @@
-dante-article_german.ps.gz
+dante99.ps.gz
diff -Nru tk-brief-5.9/debian/rules tk-brief-5.10/debian/rules
--- tk-brief-5.9/debian/rules   2010-05-02 01:04:46.0 +0200
+++ tk-brief-5.10/debian/rules  2017-01-18 07:24:24.0 +0100
@@ -12,7 +12,9 @@
 
touch configure-stamp
 
-build: configure-stamp build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 build-stamp:
dh_testdir
 
@@ -36,9 +38,9 @@
dh_installdirs
dh_install tk_Brief usr/bin
mv debian/tk-brief/usr/bin/tk_Brief debian/tk-brief/usr/bin/tk-brief
-   dh_installman debian/tk_Brief-en.1
-   mv debian/tk-brief/usr/share/man/man1/tk_Brief-en.1 
debian/tk-brief/usr/share/man/man1/tk-brief.1
-   dh_installman --language=de tk_Brief.1
+   dh_installman tk-brief-en.1
+   mv debian/tk-brief/usr/share/man/man1/tk-brief-en.1 
debian/tk-brief/usr/share/man/man1/tk-brief.1
+   dh_installman --language=de tk-brief.1
 
 
 # Build architecture-dependent files here.
diff -Nru tk-brief-5.9/debian/source/format tk-brief-5.10/debian/source/format
--- tk-brief-5.9/debian/source/format   2010-05-11 05:59:22.0 +0200
+++ tk-brief-5.10/debian/source/format  2017-01-18 07:22:46.0 +0100
@@ -1 +1 @@
-3.0 (native)
+3.0 (quilt)
diff -Nru tk-brief-5.9/debian/tk_Brief-en.1 tk-brief-5.10/debian/tk_Brief-en.1
--- tk-brief-5.9/debian/tk_Brief-en.1   2010-05-02 01:16:02.0 +0200
+++ tk-brief-5.10/debian/tk_Brief-en.1  1970-01-01 01:00:00.0 +0100
@@ -1,217 +0,0 @@
-'\" t
-.\" Manual page created with latex2man on Mon Nov 13 07:12:56 CET 2000
-.\" NOTE: This file is generated, DO NOT EDIT.
-.TH "TK\\_BRIEF" "1" "13
- November 2000" "tk_Brief "
-.SH NAME
-tk\-Brief is a graphical user interface for writing single or multiple letters 
-with latex. Even begginers are able to use it without a long time of 
-learning. 
-.PP
-.SH
-SYNOPSIS
-tk_Brief
-[
-.BI "\-a" " an"
-]
-[
-.BI "\-N" " name"
-]
-[
-.BI "\-str" " street"
-]
-[
-.BI "\-o" " city"
-]
-[
-.BI "\-dir" " directory"
-]
-[
-.BI "\-fax" " faxnumber"
-]
-[
-.B "\-h"
-]
-[
-.B "filename"
-]
-.PP
-.SH
-DESCRIPTION
-tk_Brief
-generates a .tex file using a .text 
-file and the input from the input fields. There are different letter styles 
-inplemented, e.g. g\-brief. Although it was originally written for the german 
letter 
-norm, it can create an english or durch letter style. The labels can occur in 
English 
-of Dutch language. tk_Brief
-is written in Tcl/Tk and therefor available 
-on many platforms. 
-.PP
-.SH
-OPTIONS
-.TP
-.BR "\-h"
-Short Help for tk_Brief.
-.TP
-.BI "\-a" " to"
-Commandline option for 'to' field. 
-.TP
-.BI "\-N" " name"
-Commandline option for 'name field. 
-.TP
-.BI "\-str" " street"
-Commandline option dor 'street' field. 
-.TP
-.BI "\-o" " city"
-Commandline 

Bug#851672: pnmixer crashes during startup

[elboulangero]

Hi Namor,

I recommend that you try the very last version of PNMixer, the 0.7.
There's a package available on Launchpad:

https://launchpad.net/~elboulangero/+archive/ubuntu/pnmixer

Alternatively, if you like to compile, the very last version of the code
is availble on Github:

https://github.com/nicklan/pnmixer

The version 0.7 has been completely rewritten, so it's likely that the
crash is fixed. Please let me know how it goes.

Regards,

Arnaud.


On 01/17/2017 08:09 PM, Namor Barcode wrote:
> Package: pnmixer
> Version: 0.6.1-1
>
> When I invoke `pnmixer' without arguments from an ordinary shell
> prompt it crashes.
>
> OS: Debian Testing (Stretch)
> Kernel 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64
>
> Here is dump:
>
> =
> *** buffer overflow detected ***: pnmixer terminated
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f17a3db0bcb]
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f17a3e390e7]
> /lib/x86_64-linux-gnu/libc.so.6(+0xf7220)[0x7f17a3e37220]
> /lib/x86_64-linux-gnu/libc.so.6(+0xf67d9)[0x7f17a3e367d9]
> /lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0xac)[0x7f17a3db4bec]
> /lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x789)[0x7f17a3d874a9]
> /lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x8c)[0x7f17a3e3686c]
> /lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7f17a3e367bd]
> pnmixer(get_mute_state+0x9f)[0x407b6f]
> pnmixer(update_status_icons+0x18f)[0x40826f]
> pnmixer(apply_prefs+0x13b)[0x40b0ab]
> pnmixer(main+0x136)[0x406d16]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f17a3d602b1]
> pnmixer(_start+0x29)[0x406e29]
> === Memory map: 
> 0040-0040f000 r-xp  08:04
> 201698001  /usr/bin/pnmixer 0060f000-0061
> r--p f000 08:04 201698001  /usr/bin/pnmixer
> 0061-00611000 rw-p 0001 08:04
> 201698001  /usr/bin/pnmixer 01eb-023ee000
> rw-p  00:00 0  [heap]
> 7f179b497000-7f179b4ad000 r-xp  08:04
> 201326855  /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f179b4ad000-7f179b6ac000 ---p 00016000 08:04
> 201326855  /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f179b6ac000-7f179b6ad000 r--p 00015000 08:04
> 201326855  /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f179b6ad000-7f179b6ae000 rw-p 00016000 08:04
> 201326855  /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f179b6ba000-7f179b73a000 rw-s  00:05
> 14843927   /SYSV (deleted)
> 7f179b73a000-7f179b742000 r--p  08:04
> 332713 /usr/share/locale/ru/LC_MESSAGES/gdk-pixbuf.mo
> 7f179b742000-7f179b747000 r-xp  08:04
> 332734 
> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
> 7f179b747000-7f179b946000 ---p 5000 08:04
> 332734 
> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
> 7f179b946000-7f179b947000 r--p 4000 08:04
> 332734 
> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
> 7f179b947000-7f179b948000 rw-p 5000 08:04
> 332734 
> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
> 7f179b948000-7f179b967000 r--s  08:04
> 134372547  /usr/share/mime/mime.cache
> 7f179b967000-7f179b986000 r--s  08:04
> 134372547  /usr/share/mime/mime.cache
> 7f179b986000-7f179b9a r--p  08:04
> 67161187   /usr/share/icons/Adwaita/icon-theme.cache
> 7f179b9a-7f179b9ba000 r--p  08:04
> 67161187   /usr/share/icons/Adwaita/icon-theme.cache
> 7f179b9ba000-7f179ba73000 r--p  08:04
> 201510106  /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
> 7f179ba73000-7f179ba81000 r-xp  08:04
> 227004 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
> 7f179ba81000-7f179bc81000 ---p e000 08:04
> 227004 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
> 7f179bc81000-7f179bc82000 r--p e000 08:04
> 227004 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
> 7f179bc82000-7f179bc83000 rw-p f000 08:04
> 227004 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
> 7f179bc83000-7f179bc88000 r-xp  08:04
> 226996 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
> 7f179bc88000-7f179be87000 ---p 5000 08:04
> 226996 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
> 7f179be87000-7f179be88000 r--p 4000 08:04
> 226996 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
> 7f179be88000-7f179be89000 rw-p 5000 08:04
> 226996 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
> 7f179be89000-7f179be8d000 r-xp  08:04
> 239393 

Bug#850478: [git-buildpackage/master] git-pbuilder: Don't remove changes file

[Guido Günther]

tag 850478 pending
thanks

Date:   Wed Jan 18 07:51:39 2017 +0100
Author: Guido Günther 
Commit ID: 534c055c6e6dd599a022cd16107083155c7560a2
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=534c055c6e6dd599a022cd16107083155c7560a2
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=534c055c6e6dd599a022cd16107083155c7560a2

git-pbuilder: Don't remove changes file

Closes: #850478

  

Bug#850478: git-pbuilder deliberately deletes source.changes

[Guido Günther]

Hi  James, Hi Russ,
On Tue, Jan 17, 2017 at 05:42:37PM +, James Clarke wrote:
> On Sat, Jan 07, 2017 at 06:42:12PM +0100, Guido Günther wrote:
> > On Sat, Jan 07, 2017 at 09:30:57AM -0800, Russ Allbery wrote:
> > > Mattia Rizzolo  writes:
> > > > On Fri, Jan 06, 2017 at 06:18:14PM -0800, Russ Allbery wrote:
> > >
> > > >> Yeah, it does that because I didn't know how to do better (and this
> > > >> started life as my personal script for my workflow, and at the time all
> > > >> *_source.changes files were garbage).
> > >
> > > > umh, $pkg_$version_source.changes? :)
> > >
> > > Okay, how do I get $pkg and $version?  :)  git-pbuilder right now doesn't
> > > know any of that stuff.  I suppose I could try to parse debian/changelog
> > > using dpkg-parsechangelog or something
> >
> > gbp buildpackage could pass this in env vars too. In fact I already
> > looked how this could be done and wonder if we should do at least that
> > for stretch? If so I can fix this up in gbp and git-pbuilder until
> > pbuilder is fixed.
> 
> pbuilder (well, pdebuild) is now fixed as of 0.228; could you please
> drop this in git-pbuilder? Thanks :)

I've removed the code in gbp with the attached patch. Russ, can this be
folded into the next git-pbuilder release?
Cheers,
 -- Guido

> 
> > Slightly related: What would be nice if gbp would know which changes
> > file got created by git-pbuilder / pdebuild so it doesn't have to guess
> > which one to use for an upload:
> >
> > 
> > https://github.com/agx/git-buildpackage/blob/master/examples/gbp-posttag-push#L147
> >
> > > But if pdebuild stops generating the bad *_source.changes file, then I can
> > > just delete all that code and everything becomes easier.
> > >
> > > >> > Now, I'm of the view that dpkg-source -b should be used instead,
> > > >> > which is what sbuild uses to create the dsc. This also has the
> > > >> > advantage of not generating .buildinfo files (no annoying
> > > >> > debian/files lingering after the build, either). Then the only
> > > >> > _source.changes generated by pbuilder would be if the user 
> > > >> > requested
> > > >> > it, and therefore having it deleted by git-pbuilder would be 
> > > >> > wrong.
> > > >>
> > > >> Yeah, this seems reasonable to me.  Definitely happy to change
> > > >> git-pbuilder once pdebuild is fixed to not produce the spurious and
> > > >> useless *_changes.file.
> > >
> > > > Indeed, is this a suggestion for pdebuild?
> > >
> > > Yeah, I think you might not have gotten the original message, since I
> > > think the X-Debugs-Cc may have been in the wrong spot?
> 
>From 0a34605b7b14b8b0484906f055e271625884ca64 Mon Sep 17 00:00:00 2001
Message-Id: <0a34605b7b14b8b0484906f055e271625884ca64.1484723006.git@sigxcpu.org>
From: =?UTF-8?q?Guido=20G=C3=BCnther?= 
Date: Wed, 18 Jan 2017 07:51:39 +0100
Subject: [PATCH] git-pbuilder: Don't remove changes file

Closes: #85047
---
 bin/git-pbuilder | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/bin/git-pbuilder b/bin/git-pbuilder
index aa15cf5e..e67698de 100644
--- a/bin/git-pbuilder
+++ b/bin/git-pbuilder
@@ -320,11 +320,7 @@ fi
 # Add all of the additional arguments we got on the command line, but quote
 # them from the shell since they'll undergo another round of shell expansion
 # when the pbuilder runs debbuild.
-source_only=false
 for arg in "$@" ; do
-if [ x'-S' = x"$arg" ] ; then
-source_only=true
-fi
 DEBBUILDOPTS+=" $(shell_quote "$arg")"
 done
 
@@ -337,11 +333,7 @@ else
 pdebuild --buildresult "$OUTPUT_DIR" --pbuilder "$BUILDER" \
 --debbuildopts "$DEBBUILDOPTS" "${PDEBUILDOPTS[@]}" -- "${OPTIONS[@]}"
 fi
-status="$?"
-if [ -n "`ls ../*_source.changes`" ] && [ true != "$source_only" ] ; then
-rm ../*_source.changes
-fi
-exit "$status"
+exit "$?"
 
 # Documentation.  Use a hack to hide this from the shell.  Because of the
 # above exit line, this should never be executed.
-- 
2.11.0

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Paul Wise]

On Wed, Jan 18, 2017 at 4:49 AM, Fabian Greffrath wrote:

> Please note that the "preferred form for modification" is a term
> exclusive to the GPL, it does not necessarily apply to fonts licensed
> under any other license. Also, I am not sure if this is really exactly
> what is meant by the "missing sources" paragraph of the REJECTS FAQs.

It is definitely not exclusive to the GPL; it is widely used to refer
to the source of FLOSS works.

Please try to submit a git commit to Firacode upstream containing only
changes to the generated files. Then you will see that this phrase has
meaning in any software context, including in the world of fonts and
Firacode in particular.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#850425: linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is full" problem only under Xen

[Andy Smith]

On Fri, Jan 06, 2017 at 11:37:11AM +, Andy Smith wrote:
> Andrew Cooper suggested trying two patches:
> > https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614

[…]

> Using a kernel built with those patches the problem has gone away for
> me and has been stable for about a month of production load.

Sarah Newman pointed me at another message from David Vrabel:

https://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03033.html

> > As a workaround, you can give dom0 more than 4 GiB and then the
> > driver will set a 64-bit DMA mask.  I don't think the memory needs
> > to populated so something like dom0_mem=2GiB,max:4GiB might work.

I've booted the stock jessie kernel with hypervisor command line
containing "dom0_mem=2GiB,max:4GiB" and have not yet been able to
induce a crash, whereas without this I can do so within seconds by
triggering a full-speed md array check. Normally I just have
"dom0_mem=2GiB".

This has been running less than 24hrs but is looking good so far.

Thanks,
Andy

Bug#851634: Extensions do not load.

[Jean-Francois Pirus]

Also if this option "--enable-remote-extensions" is not specified, no 
extensions load.

Bug#851731: mount: USB mounts with another name, cant see new USBs content!

[Eamonn Collins]

Package: mount
Version: 2.25.2-6
Severity: normal
Tags: lfs

Dear Maintainer,

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

   * What led up to the situation?

I used the cp commmand to create a debian testing installation usb. I then
unmounted and removed the usb, and entered another usb which has some backup
files on it.

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

I imagine a reset will fix.

   * What was the outcome of this action?

The new USB mounted with the previous USBs name 'Debian testing amd64' and
displays the content of it instead of the content of the new USB. (???) When
trying to umount it says 'permission needed to unmount /dev/loop0 mounted by
another user

   * What outcome did you expect instead?

The usb to be mounted under its actual name and to display its actual content.

Sorry my input can't be better, i am noob still.

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



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

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

Versions of packages mount depends on:
ii  libc6  2.19-18+deb8u7
ii  libmount1  2.25.2-6
ii  libselinux12.3-2
ii  libsmartcols1  2.25.2-6

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.2.8-9

-- no debconf information

Bug#851710: zoneminder: CVE-2016-10140

[Salvatore Bonaccorso]

Control: severity -1 grave

On Tue, Jan 17, 2017 at 09:37:46PM +0100, Salvatore Bonaccorso wrote:
> Source: zoneminder
> Version: 1.30.0+dfsg-2
> Severity: important
> Tags: security upstream patch
> 
> Hi,
> 
> the following vulnerability was published for zoneminder.
> 
> CVE-2016-10140[0]:
> | Information disclosure and authentication bypass vulnerability exists
> | in the Apache HTTP Server configuration bundled with ZoneMinder
> | v1.30.0, which allows a remote unauthenticated attacker to browse all
> | directories in the web root, e.g., a remote unauthenticated attacker
> | can view all CCTV images on the server.
> 
> The package then installs respectively
> /etc/apache2/conf-available/zoneminder.conf with the problematic
> settings.

After discussing with Moritz Muehlenhoff (jmm), decided to raise the
severity to RC, and have the conffile fix included in stretch.

Regards,
Salvatore

Bug#850396: xymon-client: ifstat graph appears to not recognize new net-tools output

[david]

Axel,

On 01/15/2017 09:30 AM, david wrote:


... I was able to reconfigure the
wifi interface (orig: wlp4s0) to be wlan0 using an appropriate udev link
file last night.


This turned out to be a critical part of the troubleshooting.


What I'm seeing with new eyes is that while the msg.$HOST.txt file on
the client has the appropriate [ifstat] block in it with valid data, I'm
still not getting new RRD files, ifstat.*.rrd, generated on the xymon
server for display. The files are dated early this month.


User error here, in part, but it also pointed out what I think is the 
real bug here. I had been trying to use the INTERFACES:REGEXP function 
in the hosts.cfg file, and by only specifying the desired, original 
interface (wlp4s0) the other files would not update as should be expected.


However, this indicates that xymon does NOT currently recognize the udev 
assigned interfaces, at least specifically 'wl*', and I suspect 'en*'. I 
base this on the new, functional flag for this host as:


INTERFACES:"eth0|wlp4s0"

The results are that I get ifstat.eth0.rrd updating now, but no creation 
of the needed ifstat.wlp4s0.rrd file for which valid data is being 
collected.


When I had the wireless interface renamed 'wlan0' using udev rules, I 
started getting ifstat.wlan0.rrd file data mapped.


Based on all this, I believe the bug was incorrectly filed and should be 
listed as something similar to "udev Predictable Network Interface Names 
are not properly recognized".


It's also worth mentioning that the new net-tools doesn't seem to impact 
this issue, either. That was a false suspicion.


Hopefully this all makes sense,

david

Bug#851733: opencc: SIGABRT on i386/armhf architecture

[Boyuan Yang]

Package: opencc
Version: 1.0.4-4
Severity: important

Hi,

Opencc will abort unexpectedly on i386/armhf.

Steps to reproduce:

1. sh -c "opencc"

Stderr:

terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_M_replace_aux

Thanks.



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

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

Versions of packages opencc depends on:
ii  libc6   2.24-9
ii  libgcc1 1:6.3.0-2
ii  libopencc2  1.0.4-4
ii  libstdc++6  6.3.0-2

opencc recommends no packages.

opencc suggests no packages.

-- no debconf information

Bug#850626: tahoe-lafs: Latest setuptools in debian repo is 5.7 but tahoe requires >=11.3, all tahoe commands fail

[Ramakrishnan Muthukrishnan]

Hi James,

Thanks for the bug report. Read on.. 

On Sun, Jan 8, 2017, at 10:21 PM, James Murphy wrote:
> 
> Traceback (most recent call last):
>   File "/usr/bin/tahoe", line 9, in 
> load_entry_point('tahoe-lafs==1.11.0', 'console_scripts', 'tahoe')()
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line
>   356, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line
>   2472, in load_entry_point
> return ep.load()
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line
>   2186, in load
> ['__name__'])
>   File "/usr/lib/python2.7/dist-packages/allmydata/__init__.py", line
>   412, in 
> _vers_and_locs_list, _cross_check_errors =
> get_package_versions_and_locations()
>   File "/usr/lib/python2.7/dist-packages/allmydata/__init__.py", line
>   222, in get_package_versions_and_locations
> for p in pkg_resources.require(install_requires)])
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line
>   745, in require
> needed = self.resolve(parse_requirements(requirements))
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line
>   644, in resolve
> raise VersionConflict(dist, req)
> pkg_resources.VersionConflict: (setuptools 5.7
> (/usr/local/lib/python2.7/dist-packages),
> Requirement.parse('setuptools>=11.3'))

It seem to me from the traceback that you have another set of packages
installed in /usr/local that is a quite old. Could you please move or
delete them and try again? I can't seem to reproduce this in my 'sid'
setup. I upgraded all the packages today but still can't reproduce it.

It will be great if you can clean up or move the python modules in
/usr/local/lib/python2.7/* and try again.

Thanks
-- 
  Ramakrishnan

Bug#851732: schleuder: please Depend: cron-daemon instead of cron

[Daniel Kahn Gillmor]

Package: schleuder
Version: 3.0.0~beta17-1
Severity: normal

Dear Maintainer,

Some people prefer alternate implementations of cron, like
systemd-cron.  If you make schleuder Depends: cron-daemon instead of
Depends: cron, it should work for all implementations.

Thanks for maintaining schleduer in debian!

Regards,

   --dkg

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

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

Bug#848129: pie-link specs should not be passed when pie is not enabled

[Guillem Jover]

On Fri, 2016-12-16 at 10:51:53 +0100, Bálint Réczey wrote:
> 2016-12-15 23:26 GMT+01:00 Matthias Klose :
> > Well, Balint asked to enable the pie defaults in GCC. I wasn't aware that 
> > more
> > work regarding the specs was needed.  Ideally these changes should be done 
> > in
> > one place, not in two.
> 
> Yes, I tested and asked for enabling PIE in GCC because this is the low risk
> method. It is used by Ubuntu and GCC parameter parsing makes enabling it
> from dpkg basically does not work. Setting it through spec files is fragile 
> and
> it is not tested well.

The -specs files should be pretty robust now. Anything not building
with those would IMO be broken with PIE by default from gcc anyway. And
In the end gcc also drives its frontends via specs files internally.

> Please simply drop using spec files for both setting and disabling PIE.

Sorry but dropping the -specs files completely, even if honoring
Matthias request, would be unnacceptable, as I've mentioned before
multiple times now. Maintainers should be able to disable PIE, not
doing so would leave them with the job of figuring out how to do that,
which might mean having to extensively patch the build system or
similar. Making maintainers work harder just because, is not acceptable.
At that point I'd rather we disable PIE globally, really.

Regards,
Guillem

Bug#848129: pie-link specs should not be passed when pie is not enabled

[Guillem Jover]

On Thu, 2016-12-15 at 23:26:11 +0100, Matthias Klose wrote:
> On 15.12.2016 13:27, Guillem Jover wrote:
> > On Wed, 2016-12-14 at 12:54:41 +0100, Matthias Klose wrote:
> >> Package: dpkg-dev
> >> Version: 1.18.15
> >> Severity: important
> >> Tags: sid stretch
> >>
> >> This is seen on all architectures where pie is not enabled by default. 
> >> These
> >> specs should not be passed when pie is not in effect.
> > 
> > I assume you mean enabled by default by gcc.
> 
> No, this particular build log doesn't show any -fPIE/-pie flags, so it is
> neither enabled by dpkg-buildflags nor by gcc.

I only understood this request after reading the gcc patch. So, you meant
not enabled explicitly by the package or by the builder.

> > So we'd need specs files in some places no matter what. And the option
> > of just never using specs files, and not making it possible to disable
> > PIE for example or enable it on other arches explicily would be
> > inconsistent and a pain for maintainers.
> 
> Well, Balint asked to enable the pie defaults in GCC. I wasn't aware that more
> work regarding the specs was needed.  Ideally these changes should be done in
> one place, not in two.

At this point I think it was a mistake to enable this in GCC, given
the current situation…

> I don't think that dpkg-buildflags should have any business passing spec files
> for cases where these spec files are not needed.  This is monkey-patching GCC
> for unrelated or convenience reasons.

They are needed whenever PIE needs to be enabled or disabled, and gcc
does not do that already.

> This did go wrong as seen with #843791, #843826,

These were just bugs, in the same way #849542 was an implementation
bug.

> and now with at least the python2.7 x32 build.  For the latter it is
> not important that the build can/should be fixed or being worked around, but
> that just passing these specs is causing side effects.  The GCC packages don't
> divert dpkg-buildflags either, and I see this in the end as a diversion as 
> well.

gcc in the end does what the upper layers tell it to do, and in the
end the distribution policy is set by the specific packages or by
dpkg-buildflags if the packages decide to use it. By that measure all
packages are diverting gcc whenever they diverge from gcc defaults…

> And I can't find any docs about what these specs are supposed to do.

I'm not sure what kind of documentation you are looking for.

> For the upload of the GCC 6.3.0 release candidate I'm ignoring these spec 
> files
> when they are not needed.  I think this is the least invasive option for the
> upcoming stretch release. A 'note' message is printed when these options are
> ignored, so this shouldn't be an issue with any -Werror option either.

Oh, wow, I saw that, and lost all motivation to discuss this any
further. But there's too much fallout due to this, so it needs to be
addressed one way or another.

That patch is just broken-by-design. It is a complete layer violation. It
also breaks unrelated software such as cmake (#851720) due to that 'note'.
And breaks any package that does not export DEB_BUILD_MAINT_OPTIONS from
debian/rules, such as any using the dpkg architecture.mk fragment or when
calling dpkg-buildflags with the --export=configure or --export=cmdline
options, or similar constructs.

I'll start a thread on d-d, as switching to the behavior that you
request, which I consider pretty suboptimal, impacts porters and
package maintainers. If there's consensus to do the switch then I'll
do that.

> > I find the current situation pretty suboptimal TBH. :/
> 
> Balint and the release team asked to enable this.  I raised concerns that this
> would be too late for the release cycle, but my concerns were ignored (sorry,
> can't find this email in a bug report, must be on some ML).  I'm fine to undo
> the pie enabling for stretch and work on a better solution for buster if 
> anybody
> requests this.  There are plenty of bug reports where people are not happy 
> with
> the pie defaults in GCC.
> 
> Ideally I'd like to see a solution where no spec file changes are required and
> the the appropriate changes are integrated in GCC upstream.

Well, at this point I'd rather remove all traces of PIE support from
dpkg-buildflags and let you and Bálint handle all this mess, unfortunately
this is not possible, as one of the *the* interface to enable this in
packages is precisely dpkg-buildflags…

Regards,
Guillem

Bug#851703: Need to be able to disambiguate suite by distro

[Sean Whitton]

Hello,

On Tue, Jan 17, 2017 at 07:22:08PM +, Ian Jackson wrote:
> Then we need to go through the code in dgit and ensure that the suite
> name is appropriate qualified everywhere.  Probably, $csuite needs to
> be abolished and turned into two variables, one containing the distro
> name and one being just the bare suite.
> 
> There should be separate a config option (separate to
> dgit.default.distro) to specify which distro(s) distro-unqualified
> branch names refer to.  This config option mustn't change often,
> because changing it can change the implied upstream source of a branch
> name.

I take it that Debian's dgit repos won't see any change?  I.e. remain
unqualified?

> [1] Sane possibilities for the branch name would appear to include
> (opinions welcome):
> 
>  My favourites:
> 
>   Format (local branch)  Example
> 
>   dgit/DISTRO=SUITE   raspbian=jessie
>   dgit/DISTRO#SUITE   raspbian#jessie
>   dgit/SUITE@DISTRO   jessie@raspbian
> 
>  Other possibilities:
> 
>   dgit/DISTRO%SUITE   raspbian%jessie
>   dgit/SUITE%DISTRO   jessie%raspbian

'=' could be misleading.  Otherwise I like the '@' as it has a semantic
reading which makes it easy to memorise.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#848893: closed by Andreas Beckmann <a...@debian.org> (Bug#848893: fixed in nvidia-settings 375.26-2)

[Brian Holaday]

Hi Andreas,

I will wait for the patch on jessie-backports (currently the branch is
still on 367.57.2) and will test it once I see the update.

Thanks, Arcade.

On Tue, Jan 10, 2017 at 3:54 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the nvidia-settings package:
>
> #848893: nvidia-settings: When launching "nvidia-settings" -- "undefined
> symbol error"
>
> It has been closed by Andreas Beckmann .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Andreas Beckmann <
> a...@debian.org> by
> replying to this email.
>
>
> --
> 848893: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848893
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Andreas Beckmann 
> To: 848893-cl...@bugs.debian.org
> Cc:
> Date: Tue, 10 Jan 2017 22:51:15 +
> Subject: Bug#848893: fixed in nvidia-settings 375.26-2
> Source: nvidia-settings
> Source-Version: 375.26-2
>
> We believe that the bug you reported is fixed in the latest version of
> nvidia-settings, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 848...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Andreas Beckmann  (supplier of updated nvidia-settings
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Tue, 10 Jan 2017 23:19:38 +0100
> Source: nvidia-settings
> Binary: nvidia-settings libxnvctrl0 libxnvctrl-dev
> Architecture: source
> Version: 375.26-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian NVIDIA Maintainers  alioth.debian.org>
> Changed-By: Andreas Beckmann 
> Description:
>  libxnvctrl-dev - NV-CONTROL X extension (development files)
>  libxnvctrl0 - NV-CONTROL X extension (runtime library)
>  nvidia-settings - tool for configuring the NVIDIA graphics
> driver${nvidia:LegacyDes
> Closes: 848893
> Changes:
>  nvidia-settings (375.26-2) unstable; urgency=medium
>  .
>* pie.patch: New, filter out -pie when linking shared libraries.
>  (Closes: #848893)
> Checksums-Sha1:
>  7051fd4c4fedd12e8a3382eedad1cf83b4b2c24c 2532
> nvidia-settings_375.26-2.dsc
>  14b121ecdf206ae47ef892fbde28ad665472bb09 20696 nvidia-settings_375.26-2.
> debian.tar.xz
> Checksums-Sha256:
>  133733b851fa797f08e6e808b4dc3c3cc24583b44e046d538048d639de096dc2 2532
> nvidia-settings_375.26-2.dsc
>  4f72a9bf92d39a275081b129aae2d8e0651fea7b4bf2a770d6e91f6eab19fe8b 20696
> nvidia-settings_375.26-2.debian.tar.xz
> Files:
>  d61e60d0200c7d7309a742df37d0bb1f 2532 x11 optional
> nvidia-settings_375.26-2.dsc
>  386447836f0643c7670433b1c84fabde 20696 x11 optional
> nvidia-settings_375.26-2.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJYdWCuAAoJEF+zP5NZ6e0I+9kP/iy006ePiDXh8U/tPclStJLP
> Y2j/ckW06qNE1RFYUHZIELQLoodbQrSywEEvBtMY50GC5BnZVMZUvM3SuMFQzsJO
> bcXwLgZuzW2fTqc1fec83c3HFS9+J8kZS0juaBjgUga1HMWpDqjzuh1q0kw06TO6
> CEiDd283x6x1HQwnkD4W1oEk+lhjM5oxNvkaEZTZ1b1J4HRN7R0Q6SDQ7l21wSr5
> 0qiFwIi/gOradIjHtg5RM6CxmeG+Bzr5+ZW406CVOzAMmIeKd+jsxkGBeFtLs7m0
> rKWKNTpeRUfL6rQo2zgXcND42CIaMCAHGKJHy2IZ+MQaDsYWgDu1Y3lZY+OrDM19
> MRItmT1WUmEE3KJqHlIlx4Uyw/DI1feiOeIwTD+KZlwRc/VIdilkc7/A01ICmkY6
> DvVHi6xk+z41wBFg30LvZsEhFa6nWZ/VPHMhzFWE2dvYMi+d8QCIFV3oEF4jdV2h
> Av/WDkCiZVrlOhTpabpI/ISy8Q6OR8Ua07/XC7NtcwCkwfE+dZWCKdH80jAOEqpb
> LRhk31mXBP6duhlixxHLc5d5YLDBmvfAf0dRW3H254rLukD2UyV4RX9NXA8TYkek
> W5vinggmgJs0TKC2khU/f9795EiVAn3PEjtVc5BVZdx40JaWsPYFPQV0ZcOV2EAE
> rzojF9647KG+OWKMIZcx
> =yILY
> -END PGP SIGNATURE-
>
> -- Forwarded message --
> From: Arcademan 
> To: Debian Bug Tracking System 
> Cc:
> Date: Tue, 20 Dec 2016 08:41:15 -0700
> Subject: nvidia-settings: When launching "nvidia-settings" -- "undefined
> symbol error"
> Package: nvidia-settings
> Version: 367.57-1~bpo8+1
> Severity: important
>
> Dear Maintainer,
>
> When launching "nvidia-settings" via the terminal window I see the
> following error:
>
> ERROR: /usr/lib/libnvidia-gtk3.so.367.57: undefined symbol: ctk_init_check
>/usr/lib/libnvidia-gtk3.so.367.57: undefined symbol:
> ctk_get_display
>/usr/lib/libnvidia-gtk3.so.367.57: undefined symbol: ctk_main
> 

Bug#851653: RM: packages with RC bugs requesting omission from testing

[Andreas Beckmann]

On Tue, 17 Jan 2017 23:52:21 +0100 Emilio Pozuelo Monfort
 wrote:
> > # RoM: #848116

treat that as RoQA (aka me), unless a maintainer reassigns it to ftp.d.o

> > remove libkipi/4:15.08.3-2 kamoso/2.0.2-3.1
> 
> A bug should be filed against kamoso. I haven't added this hint.

* kamoso is fixed in sid since early December, but blocked by outdated
mips* binaries
* it has a new dependency, purpose, which is not yet in testing, but RC
free in sid since early December, also blocked by mips*, this will need

unblock purpose/1.1-4


Andreas

Bug#851730: init-system-helpers: update-rc.d fails to disable nbd-server

[Christoph Anton Mitterer]

Package: init-system-helpers
Version: 1.46
Severity: important

Hi.

Not sure why the following happens:
# update-rc.d nbd-server disable
update-rc.d: error: nbd-server Default-Start contains no runlevels, aborting.


Trying to enable it gives the same error:
# update-rc.d nbd-server enable
update-rc.d: error: nbd-server Default-Start contains no runlevels, aborting.


# grep Default-Start /etc/init.d/nbd-server
# Default-Start: 2 3 4 5 


# l /etc/rc*.d | grep nbd
lrwxrwxrwx 1 root root   20 Jan 14 20:12 K01nbd-client -> ../init.d/nbd-client
lrwxrwxrwx 1 root root   20 Jan 14 01:34 K01nbd-server -> ../init.d/nbd-server
lrwxrwxrwx 1 root root   20 Jan 14 01:34 K01nbd-server -> ../init.d/nbd-server
lrwxrwxrwx 1 root root   20 Jan 14 01:34 S03nbd-server -> ../init.d/nbd-server
lrwxrwxrwx 1 root root   20 Jan 14 01:34 S03nbd-server -> ../init.d/nbd-server
lrwxrwxrwx 1 root root   20 Jan 14 01:34 S03nbd-server -> ../init.d/nbd-server
lrwxrwxrwx 1 root root   20 Jan 14 01:34 S03nbd-server -> ../init.d/nbd-server
lrwxrwxrwx 1 root root   20 Jan 14 20:12 K01nbd-client -> ../init.d/nbd-client
lrwxrwxrwx 1 root root   20 Jan 14 01:34 K01nbd-server -> ../init.d/nbd-server
lrwxrwxrwx 1 root root   20 Jan 14 20:12 S15nbd-client -> ../init.d/nbd-client


Thus one cannot cleanly disable this and systemd always starts it again.

Marking it important as this may lead to devices being exported while the user
thinks the daemon was disabled.


Cheers,
Chris.

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

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

Versions of packages init-system-helpers depends on:
ii  perl-base  5.24.1-1

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
ii  insserv  1.14.0-5.4

-- no debconf information

Bug#801670: [Tts-project] Bug#801670: speech-dispatcher: Hangs and does no longer take speech from Orca until killed

[Luke Yelavich]

On Wed, Jan 18, 2017 at 11:50:32AM AEDT, Samuel Thibault wrote:
> I'm wondering what to do with this bug report: 0.8.1 has long been
> uploaded. Perhaps also what Luke was talking about?  Of course, if
> speech-dispatcher still has hangs we need to investigate.

Well, the shutdown stuff I was talking about was released in 0.8.5, so by 
default, Speech Dispatcher should shut itself down after 5 seconds of no 
clients being connected, but if there are other hangs, then yes I agree they 
need to be investigated.

Luke

Bug#810829: dgit: should be possible to use with a reprepro-style small repo

[peter green]

We have a small local repository of packages, managed with
reprepro. In order to streamline management of our local packages, I'd
like to use this repro as an alternative dgit remote.


It's not exactly a small repo but we use reprepro in the raspbian project and 
Ian and I have been working on getting dgit up and running with it. dgit does 
now have a mode where it uses packages files to query repo metadata.


dgit uses a "bag on the side" git repo which will need to be set up. Also a 
small patch to dgit is currently needed to make push work with repos that don't provide 
an API.

I have been documenting how I did it at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851194

Note: I have been more interested in push than pull as dgit pull doesn't shape 
the history in the way I want. As such I have not tested pulling, only pushing 
so-far.

Bug#851194: dgit: please document how to set up dgit infrastructure.

[peter green]

And here is the stuff on the public side.

I assume you already have nginx working. You will need to change the distro 
name and any IP addresses and hostnames to suit your setup.

Install fastcgiwrap git and gitweb

Point dns for your dgit hostname at the server.

Add a server block to your nginx config for the dgit server.

server {
  listen 5.153.225.206:80;
  listen [2001:41c9:1:3ce::10]:80;
  listen   5.153.225.206:443 ssl;
  listen   [2001:41c9:1:3ce::10]:443 ssl;

  server_name dgit.raspbian.org;
  server_name dgit-bm.raspbian.org;

  #static files needed by gitweb
  location /static {
alias /usr/share/gitweb/static/;
autoindex on;
}


  #config based on 
http://weininger.net/configuration-of-nginx-for-gitweb-and-git-http-backend.html
  # static repo files for cloning over https

location ~ 
^.*\.git/objects/([0-9a-f]+/[0-9a-f]+|pack/pack-[0-9a-f]+.(pack|idx))$ {
root /home/dgit/dispatch-dir/distro=raspbian/repos;
}

# requests that need to go to git-http-backend
location ~ 
^.*\.git/(HEAD|info/refs|objects/info/.*|git-(upload|receive)-pack)$ {
root /home/git/repositories;

fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend;
fastcgi_param PATH_INFO $uri;
fastcgi_param GIT_PROJECT_ROOT 
/home/dgit/dispatch-dir/distro=raspbian/repos;
fastcgi_param GIT_HTTP_EXPORT_ALL "";
fastcgi_param REMOTE_USER $remote_user;
include fastcgi_params;
}

# send anything else to gitweb if it's not a real file
try_files $uri @gitweb;
location @gitweb {
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME /usr/share/gitweb/gitweb.cgi;
fastcgi_param PATH_INFO $uri;
fastcgi_param GITWEB_CONFIG /etc/gitweb.conf;
include fastcgi_params;
   }
}

edit gitweb.conf to point it at the git repos. In our case this was

$projectroot = "/home/dgit/dispatch-dir/distro=raspbian/repos";

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Paul Wise]

On Tue, Jan 17, 2017 at 10:29 PM, Fabian Greffrath wrote:

> But the OTF format itself is just as suitable a source format for fonts as
> any other format. Why is it so important what upstream has chosen? It is
> not that font composition is a human-readable-to-binary-one-way-road like
> compilation C source files into object code or HTML documentation to PDF.

FYI, you are mistaken that C code is always "source". C is sometimes
generated from other forms, via transpilers or lexer generators etc.
It can also be obfuscated C code from the real C source (cf #383465).

Likewise for HTML, it is often generated from templates or simple text
languages like markdown.

So like C, OTF can be source or not source, depending on the upstream project.

C to ELF is not a one-way process, there are disassemblers and decompilers.

Likewise for HTML and PDF. LibreOffice and other software can even edit PDF.

Likewise, the conversion from Glyphs to OTF definitely throws away
information. Even the conversion from Glyphsapp to UFO format (which
is sometimes used as a font source format) throws away information
according to the Glyphsapp documentation:

https://glyphsapp.com/tutorials/working-with-ufo

> Thought experiment: Would it feel more "correct" if I forked the firacode
> upstream project, converted their OTF files into fontforge's SFD format,
> checked these into a GIT repo and then distributed these?

That would be a disingenuous workaround for the choices that Firacode
upstream has made and the reality of the Free Software ecosystem for
fonts in 2017. If you convinced Firacode upstream to switch their
source format then that would be different. Or if FontForge or
FontTools or another piece of Free Software started to support
Glyphsapp format, then their choice would be fine for main.

I have a better thought experiment:

Would Debian put a free Java program in main or contrib in the time
when the official JDK was proprietary and GCJ hadn't been implemented
yet?

> Another thought experiment: We have a fairly prominent example of
> binary-only Type1 fonts available in the gsfonts package. They are
> licensed under the GPL, so there is even a "preferred form for
> modification" term that applies to them. Nobody knows how URW++ created
> these fonts and what tools they used, nevertheless a number of viable
> forks have been developed from them, among them GNU FreeFont and TeX Gyre.
> Now, what would happen if URW++ suddenly revealed that they used
> proprietary software to create the fonts and that the files that we have
> are not the canonical sources. Why should it make a difference at all?

It is unfortunate that the gsfonts upstream didn't ask the right
questions before integrating these files into the project. They really
should have done that. At that point in time we would have to remove
the URW++ fonts from Debian since we would not be in compliance with
the GPL.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#719334: crda: Wrong country selected for wlan regulatory domain (sometimes)

[Ben Hutchings]

On Sun, 11 Aug 2013 13:05:48 +0300 Touko Korpela  wrote:
> On Sun, Aug 11, 2013 at 01:29:22AM +0200, Ben Hutchings wrote:
> > Control: tag -1 moreinfo
> > 
> > On Sun, 2013-08-11 at 01:28 +0300, Touko Korpela wrote:
> > > Package: crda
> > > Version: 1.1.2-1
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > for some reason cdra or kernel puts wireless adapter to wrong country mode
> > > (TW). I use NetworkManager for managing networking in this laptop. I have
> > > configured to log automatically in primary WPA2 network. When I select 
> > > other
> > > WPA2 network, TW setting is used instead of correct (FI).
> > [...]
> > 
> > This is not a bug in crda - the kernel is responsible for deciding which
> > regulatory domain(s) are in effect, and crda only tells it the current
> > rules for the domain(s) it's interested in.
> > 
> > I suspect that the access point is a 'parallel import' from Taiwan which
> > is not configured for the correct region.  Does this seem possible?
> > When the access point and the local configuration specify two different
> > domains, the kernel is supposed to use the intersection of the rules for
> > the two domains.
> 
> I got it from Finnish store. That AP (Telewell TW-EA510) is software
> designed/customised some way in Finland.

I'm confused.  Is this the AP for the "other WPA2 network"?

> And I selected Europe as wireless
> region in AP settings. And anyway it shouldn't select Taiwan because it has
> bigger limits for transmit power if I look "max_eirp" number in logs.

Which is the kernel driver for your wireless interface?

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



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

Bug#851729: hurd: exe filename missing for some processes

[Guillem Jover]

Package: hurd
Version: 1:0.9.git20170117-1
Severity: normal

Hi!

I was improving the support to get the process executable in
start-stop-daemon to use the new libps proc_stat_set_flags PSTAT_EXE
attribute, instead of having to use argv[0], and while testing I
noticed that several processes return empty filenames, which makes
this unreliable to use. :/

This is visible from the libps API and from /proc:

  ,---
  for l in /proc/*/exe; do n=$(readlink $l); test -z "$n" || continue;\
echo "$l -> '$n'"; grep Name: /proc/$(echo $l|cut -d/ -f3)/status;\
done
  /proc/12/exe -> ''
  Name:   mach-defpager
  /proc/2/exe -> ''
  Name:   startup
  /proc/3/exe -> ''
  Name:   gnumach
  /proc/4/exe -> ''
  Name:   proc
  /proc/5/exe -> ''
  Name:   ext2fs
  /proc/575/exe -> ''
  Name:   sshd
  /proc/6/exe -> ''
  Name:   exec
  /proc/601/exe -> ''
  Name:   sshd
  /proc/7/exe -> ''
  Name:   auth
  `---

Thanks,
Guillem

Bug#851728: dgit can't import a dsc from an unknown distro

[peter green]

package: dgit

dgit can't import a dsc from an unknown distro

root@odroidu2:/# mkdir tempgit
root@odroidu2:/# cd tempgit/
root@odroidu2:/tempgit# git init
Initialized empty Git repository in /tempgit/.git/
root@odroidu2:/tempgit# dgit import-dsc ../xen_4.8.0-1+rpi1.dsc testbranch
gpgv: Signature made Tue 17 Jan 2017 22:38:36 UTC
gpgv:using RSA key 9B5A65384137C4E2411789DE8D33448CA66931D6
gpgv:issuer "plugw...@raspbian.org"
gpgv: Can't check signature: No public key
dgit: warning: failed to verify signature on ../xen_4.8.0-1+rpi1.dsc
Dgit metadata in .dsc: specified git info (raspbian)
dgit: import-dsc of .dsc with Dgit field, using git hash
.dsc names distro raspbian: fetching rewrite map
fatal: No path specified. See 'man git-pull' for valid url syntax
dgit: failed command: Use of uninitialized value $_ in substitution (s///) at 
/usr/share/perl5/Debian/Dgit.pm line 143.
root@odroidu2:/tempgit#

If I configure dgit so it knows about raspbian I can import the dsc 
successfully but I shouldn't have to. There is a url in the dsc and dgit should 
be able to use it.

The dsc is availble from 
http://plugwash.raspbian.org/jessietest/private/pool/main/x/xen/xen_4.8.0-1+rpi1.dsc
 if you want to test this yourself.

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Scott Kitterman]

On January 17, 2017 3:49:46 PM EST, Fabian Greffrath  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Am Mittwoch, den 18.01.2017, 03:24 +1100 schrieb Ben Finney:
>> Debian recipients should have equal access to make modifications to
>> the work, build the work from modified source, and install the
>> result.
>
>All these modifications could be made to the OTF files *just as well*,
>there is no advantage in using the same font format as upstream does
>for their development. But I figure we are running in circles now. ;)
>
>> The fact of the matter is the Glyphs data files are the preferred
>> form
>> of the work to make modifications.
>
>Please note that the "preferred form for modification" is a term
>exclusive to the GPL, it does not necessarily apply to fonts licensed
>under any other license. Also, I am not sure if this is really exactly
>what is meant by the "missing sources" paragraph of the REJECTS FAQs.

DFSG #2 requires that "The program must include source code".  Preferred form 
of modification is the definition of source that the FTP team uses.  For Debian 
DFSG purposes it's not exclusively GPL relevant.

Scott K

>
>> It would reveal that Debian recipients do not have equal access to
>> the source, for modifying building, and installing the work.
>
>And thus you would file a bug requesting the removal of this package
>from Debian main? Are you even aware of the vast consequences that this
>overly strict interpretation of the "missing sources" paragraph may
>have?
>
> - Fabian
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlh+g2oACgkQy+qOlwzN
>Wd/hVA//X+zpFiwIdA2AUgAuQarC/zLV9RI1SHv4z+ASIvWyALzsLstxinD5fCOY
>M6X6ySeU9ek7O/ZygHg1STgOzcBF42FvEIZscdFF6jMu5eH1zuW+t+8AoEJwMQLK
>Uf50XrN0/ZR5DHHXKqMwfPZ39OOIJ5A9iYlHZEe8bkSYjbwF/HlIcUL53xddwOq9
>bvETmHCeKJYst/QQsmR6sBNtYY2OV0onSoLxVxsbwLmlcKBA5Sg8DpjZBk407MFo
>NGllJACTuEWXZDDypAdohEsln3/yw61F/B3LbakvobEnh4pT9iNiOlOCT5MuIOiu
>yAs0tRFo5sH2rgt3HIlzfHqnCkm4U3+Y4+fHCXJTt5X9HnzC/GuExqP83o21fH3/
>qRFSnx4hDfh/D89HiL/SRhj3mx5xGbjqvYuIuoRpH67loTw73nyv2qblv37eFXUg
>uWTzoc3ln+/AQLaeFmzz8vZM2NPWff9PAKD+0QL9tbbRbAJsNpLZJbxXVC1sLP5Q
>pyjESFt7DinDXPUWUgr1NXiaPJd9+sxcOnOje94B6cZpz3RWKsteTWWjJVmWfrbf
>T5sVcwPo6ALHKX6MVXplO/prLKzvwivpO+U0wq9qKQe0M3PtJ+a6eZxKjOX/9re3
>Qg0zsjagw2V/tYsszATyETAvU9gK21dVAJ8PDPiMduFsXdOV4WE=
>=s0k/
>-END PGP SIGNATURE-

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[Lincoln Stein]

That would have been my guess too, but Bio:: Graphics 2.40 is the right
version. When running build test on a virgin Mint 18.2 system with
Bio::Perl 1.7.1 and Bio::Graphics 2.40 I'm getting 100% test success.  This
is very puzzling.

I'll  take a closer look tonight.

Lincoln

On Tue, Jan 17, 2017 at 6:27 PM gregor herrmann  wrote:

> On Tue, 17 Jan 2017 18:06:02 -0500, Lincoln Stein wrote:
>
>
>
> > Not good! But I believe that Gregor found that all these were caused by
> the
>
> > testing suite not finding the proper data files due to an assumption
> about
>
> > the current working directory. When he fixed this, there were just a
>
> > handful of tests still failing.
>
>
>
> Right, that's when I built from a clone of the debian package git
>
> repo. With your github repo, this was not necessary for reasons I
>
> haven't yet understood.
>
>
>
> > Gregor, is there a patch file that I can
>
> > apply to get up to the same point you got to?
>
>
>
> Oh, scratch what I wrote above, now I get the same with the debian
>
> repo, so no more "Can't find foo in @INC". Good, at least the
>
> failures are consistent now (for whatever reason, maybe the 5.24.1
>
> upload to unstable changed something), and no patch for that part
>
> needed.
>
>
>
> So now we are still at:
>
>
>
>
>
> t/03.render.t .
>
> 1..150
>
> ok 1
>
> ok 2
>
> ok 3
>
> ok 4
>
> ok 5
>
> ok 6
>
> ok 7
>
> ok 8
>
> ok 9
>
> ok 10
>
> ok 11
>
> ok 12
>
> ok 13
>
> ok 14
>
> ok 15
>
> ok 16
>
> ok 17
>
> ok 18
>
> ok 19
>
> ok 20
>
> ok 21
>
> ok 22
>
> ok 23
>
> ok 24
>
> ok 25
>
> ok 26
>
> ok 27
>
> ok 28
>
> ok 29
>
> ok 30
>
> ok 31
>
> ok 32
>
> ok 33
>
> ok 34
>
> ok 35
>
> ok 36
>
> ok 37
>
> ok 38
>
> ok 39
>
> ok 40
>
> ok 41
>
> Dubious, test returned 255 (wstat 65280, 0xff00)
>
> Failed 109/150 subtests
>
> Sometimes this test gets 'stuck'. If this happens, kill the test and Build
> test again.
>
> RenderPanels error:
>
> - EXCEPTION -
>
> MSG: The requested glyph class, ``span'' is not available: Attempt to
> reload Bio/Graphics/Glyph/span.pm aborted.
>
> Compilation failed in require at (eval 138) line 2, <> line 132.
>
>
>
> STACK Bio::Graphics::Glyph::Factory::make_glyph
> /usr/share/perl5/Bio/Graphics/Glyph/Factory.pm:342
>
> STACK Bio::Graphics::Glyph::add_feature
> /usr/share/perl5/Bio/Graphics/Glyph.pm:424
>
> STACK Bio::Graphics::Browser2::RenderPanels::add_features_to_track
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1869
>
> STACK (eval)
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1597
>
> STACK Bio::Graphics::Browser2::RenderPanels::run_local_requests
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1551
>
> STACK Bio::Graphics::Browser2::Render::Slave::render_tracks
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:471
>
> STACK Bio::Graphics::Browser2::Render::Slave::run_operation
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:325
>
> STACK Bio::Graphics::Browser2::Render::Slave::process_request
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:316
>
> STACK Bio::Graphics::Browser2::Render::Slave::process_connection
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:240
>
> STACK Bio::Graphics::Browser2::Render::Slave::request_loop
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:229
>
> STACK Bio::Graphics::Browser2::Render::Slave::run
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:160
>
> STACK toplevel t/04.remoteserver.t:81
>
> -
>
>
>
> Use of uninitialized value in numeric gt (>) at t/04.remoteserver.t line
> 136.
>
> RenderPanels error:
>
> - EXCEPTION -
>
> MSG: The requested glyph class, ``span'' is not available: Attempt to
> reload Bio/Graphics/Glyph/span.pm aborted.
>
> Compilation failed in require at (eval 138) line 2, <> line 132.
>
>
>
> STACK Bio::Graphics::Glyph::Factory::make_glyph
> /usr/share/perl5/Bio/Graphics/Glyph/Factory.pm:342
>
> STACK Bio::Graphics::Glyph::add_feature
> /usr/share/perl5/Bio/Graphics/Glyph.pm:424
>
> STACK Bio::Graphics::Browser2::RenderPanels::add_features_to_track
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1869
>
> STACK (eval)
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1597
>
> STACK Bio::Graphics::Browser2::RenderPanels::run_local_requests
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1551
>
> STACK Bio::Graphics::Browser2::Render::Slave::render_tracks
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:471
>
> STACK Bio::Graphics::Browser2::Render::Slave::run_operation
> /build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:325
>
> STACK Bio::Graphics::Browser2::Render::Slave::process_request
> 

Bug#850077: python-paramiko doesn't work with python-crypto 2.6-4

[Chris Lamb]

Version: 2.6-4+deb7u7

Hi,

> python-paramiko doesn't work with python-crypto 2.6-4

I believe this was fixed in 2.6-4+deb7u7 (or earlier). :)


Regards,

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

Bug#618020: Duplicated --

[Christoph Lehnberger]

merge 618020 680660thanks

Bug#841143: race condition

[NIIBE Yutaka]

Hello,

I'm sorry I didn't put the context.  I am a developer of GnuPG and nPth.
I join the Debian GnuPG mailing list, so that development can go well.
Thus, I receive your bug report.  (I also maintain some packages in
Debian but most are not related to GnuPG.)

Since I felt that there is a kind of not-so-good communication in this
bug of #841143, I am trying to help.

Well, I would like to inform dkg that I review the Debian specific
patches, I mean, they are not ignored.

Ian Jackson  wrote:
> That's the symptoms I saw.  What version did you see this with ?

I'm testing with 2.1.7-2 in Stretch.  It is not reproducible (for me) by
upstream versions.

Today, I managed to have a concrete reproducible case.  Please find an
attached script (gpg-agent-locks-up.sh).

With GPGAGENT=/usr/local/bin/gpg-agent of upstream, the log is:

2017-01-18 09:41:15 gpg-agent[4168] SIGTERM received - shutting down ...
2017-01-18 09:41:17 gpg-agent[4168] DBG: chan_9 <- [eof]
2017-01-18 09:41:18 gpg-agent[4168] gpg-agent (GnuPG) 2.1.18-beta70 stopped


gpg-agent cleanly exits.

With the one in Stretch, the log is:

2017-01-18 09:41:31 gpg-agent[4185] SIGTERM received - shutting down ...
2017-01-18 09:41:33 gpg-agent[4185] DBG: chan_9 <- [eof]
2017-01-18 09:41:36 gpg-agent[4185] SIGTERM received - still 0 open connections
2017-01-18 09:41:36 gpg-agent[4185] gpg-agent (GnuPG) 2.1.17 stopped


It didn't exit even after "[eof]" and needed second SIGTERM.
--
#! /bin/sh

GPGAGENT=/usr/bin/gpg-agent
GPG_CONNECT_AGENT=/usr/bin/gpg-connect-agent

GPGTESTTMPDIR=$HOME/tmp/test-gpg.$$
echo "Test in $HOME/tmp/test-gpg.$$"

mkdir -p $GPGTESTTMPDIR
cat > $GPGTESTTMPDIR/gpg-agent.conf 

Bug#801670: [Tts-project] Bug#801670: speech-dispatcher: Hangs and does no longer take speech from Orca until killed

[Samuel Thibault]

Hello,

Luke Yelavich, on Wed 14 Oct 2015 09:26:45 +1100, wrote:
> On Tue, Oct 13, 2015@08:39:04PM AEDT, Mario Lang wrote:
> > Package: speech-dispatcher
> > Version: 0.8-7
> > Severity: important
> > 
> > I am using Orca with Speech-Dispatcher, and just had speech output hung
> > completely.
> > Restarting Orca and even the complete X11 session did not help.
> > 
> > I had to kill the speech-dispatcher process running under my user
> > manually.
> 
> This brings to mind a work-around that was added to Speech Dispatcher in
> 0.8.1, that would kill the server if a speech synth module died and the
> connection to it was lost. Its not a clean solution, but it would@least
> mean that the Speech Dispatcher daemon could be restarted automatically
> after it died.
> 
> The commit from upstream git where this is fixed is 7a4fae3d.
> 
> As for Speech DIspatcher not being cleaned up when X shuts down, that
> is something that is addressed in the current master development branch,
> although there is no ETA for release, given its a big change, and other
> changes are planned.

I'm wondering what to do with this bug report: 0.8.1 has long been
uploaded. Perhaps also what Luke was talking about?  Of course, if
speech-dispatcher still has hangs we need to investigate.

Samuel

Bug#851727: samba: Suggest chrony as an alternative to ntp

[Vincent Blut]

Package: samba
Version: 2:4.5.2+dfsg-2
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey,

I enabled support for MS-SNTP authentication in Samba to chrony 3.0-1, 
so you may want to suggest it as alternative to ntp. Git formatted patch 
attached!

Cheers,
Vincent

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

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

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAlh+vDEXHHZpbmNlbnQu
ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4CMEg/9GbMEBOtqn4FQTyQ7M8DEdHYo
i/aLlGa4R5H5GfLscL8R7ILGiCTcZWGLkIpKYW7W511k2aYV/D6xgx+c6qnlu891
D+uZmuKj1E3KgHvVRYFvRsQnkr3SyHiLCFwwwqkwLx2nsiIuYEMl/V3rZDtiZyHc
9l8Q8SCvWTQqLrT7JWlawn/TmwWmpHLgt4+duqKh7WrMPfKav8zSKsE6SvIxrEGX
R2/Yp+3hXTuwlW9DE40UqRoHF9Tlb/XQAg6bX+o3+BVRJ04xlEb5jbV9d6ejRUSa
tFW608A3/ZcEtYWTPqR6WKEZo0fjGT+8FwzSfVHiUVLUVnOmZ9KVqfZto4MfYQBs
8Tq96Jvpypth062Q87Urn5Lz2+CJaOw0ZZfAdo/wE8Gp9SrlreXHCrOckEMukQTr
d6CrZkAoK8bsQ1MJewG3/IiDB1HWqrwHE8d5IRTxiwDJB7mk6+FQaA1tWqf0977f
EyNmmW+IEekdvnSKtFTYV+M7cvCY2shqbuyexg5N4FvsWagQVZDcxOFsvDKPIhpQ
8Z0fqQsmmZy9/SQnk6tcG3yGlFmT9ytnY9hmHeFmmwVf1I1ngmfGlURRkMoTn/Oo
45fQ12GCNf/0Ac06z/aHomg0CxyXNi3a178rgh3WBOxjs6rSrO/4R257FKuPyw/r
cfepQ3GioEyQ7l/UtDM=
=CZtL
-END PGP SIGNATURE-
>From 7ee1e926b4fce70969b11b419c9cc5f592655a1d Mon Sep 17 00:00:00 2001
From: Vincent Blut 
Date: Wed, 18 Jan 2017 01:37:07 +0100
Subject: [PATCH] d/control: Suggest chrony as an alternative to ntp

Support for MS-SNTP authentication in Samba has been added to chrony 3.0
and enabled in Debian starting from the 3.0-1 release.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 922577d392..f71cc329ef 100644
--- a/debian/control
+++ b/debian/control
@@ -76,7 +76,7 @@ Suggests: bind9 (>= 1:9.5.1),
   bind9utils,
   ctdb,
   ldb-tools,
-  ntp,
+  ntp | chrony (>= 3.0-1),
   smbldap-tools,
   winbind,
   ufw
-- 
2.11.0

Bug#786593: wordwarvi: please make the build reproducible

[Chris Lamb]

forwarded 786593 https://github.com/smcameron/wordwarvi/pull/5
thanks


Regards,

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

Bug#786593: please provide a --distrobuild build switch to allow reproducible builds

[Chris Lamb]

retitle 786593 wordwarvi: please make the build reproducible
tags 786593 + patch
thanks

Patch attached. (No need to add a "distrobuild" switch now we have
SOURCE_DATE_EPOCH).


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/stamp.c b/stamp.c
index 04b8456..e247c03 100644
--- a/stamp.c
+++ b/stamp.c
@@ -7,10 +7,18 @@ int main(int argc, char *argv[])
 {
struct timeval tv;
int uid;
+   char *source_date_epoch;
 
gettimeofday(, NULL);
uid = getuid();
 
+   source_date_epoch = getenv("SOURCE_DATE_EPOCH");
+   if (source_date_epoch) {
+   printf("static int builder = 0;\n");
+   printf("static uint64_t builtat = %s;\n", source_date_epoch);
+   exit(0);
+   }
+
printf("static int builder = %d;\n", uid);
printf("static uint64_t builtat = %d;\n", tv.tv_sec);
 

Bug#851136: dh-make-perl: docs of where available modules -> debs found

[Kevin Ryde]

gregor herrmann  writes:
>
> 1) missing documentation for how dh-make-perl does the mapping of
>CPAN distributions to Debian packages (which is primarily with
>apt-file but also with DPKG::Parse::Available)

Yes.

> 2) DPKG::Parse::Available reading the /var/lib/dpkg/available file
>which doesn't get updated anymore (?).

I thought dselect, but it didn't work for me.  Due to my setups or no
downloads I imagine.  I hold back a few packages too so wouldn't want it
running amok. :-)

>I'm wondering if using DPKG::Parse::Status which reads
>/var/lib/dpkg/status would make sense.  This then only returns
>installed packages in my understanding but maybe that was the idea
>of this change?  [0]

I had a suspicion apt-file now looks at installed packages too even if
you don't have the dist contents files (which I still usually don't due
to size).  I think I had a wishlist previously that dh-make-perl would
look at locally installed packages, maybe now it does, or mostly.

In either case the docs could say whether currently installed packages
are considered.

Bug#851726: liggghts: FTBFS on single-CPU machines (not enough slots available)

[Santiago Vila]

Package: src:liggghts
Version: 3.5.0+repack1-8
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=cmake 
--builddirectory=/<>/liggghts-3.5.0+repack1/debian/build --parallel
   dh_testdir -i -O--buildsystem=cmake 
-O--builddirectory=/<>/liggghts-3.5.0\+repack1/debian/build 
-O--parallel
   dh_update_autotools_config -i -O--buildsystem=cmake 
-O--builddirectory=/<>/liggghts-3.5.0\+repack1/debian/build 
-O--parallel
   dh_auto_configure -i -O--buildsystem=cmake 
-O--builddirectory=/<>/liggghts-3.5.0\+repack1/debian/build 
-O--parallel
cmake ../.. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.2.1
-- The CXX compiler identification is GNU 6.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done

[... snipped ...]

cd /<>/liggghts-3.5.0+repack1/debian/build/src && /usr/bin/mpicxx   
-Dlibliggghts_EXPORTS 
-DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)"
 -I/usr/include/vtk-6.3 -I/usr/include/freetype2 
-I/usr/include/x86_64-linux-gnu -I/usr/include/eigen3 
-I/<>/liggghts-3.5.0+repack1 
-I/<>/liggghts-3.5.0+repack1/src  -g -O2 
-fdebug-prefix-map=/<>/liggghts-3.5.0+repack1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DLAMMPS_VTK6 -DLAMMPS_VTK -std=c++0x -DLAMMPS_JPEG -fPIC  
 -o CMakeFiles/libliggghts.dir/write_dump.cpp.o -c 
/<>/liggghts-3.5.0+repack1/src/write_dump.cpp
[ 98%] Building CXX object src/CMakeFiles/libliggghts.dir/write_restart.cpp.o
cd /<>/liggghts-3.5.0+repack1/debian/build/src && /usr/bin/mpicxx   
-Dlibliggghts_EXPORTS 
-DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)"
 -I/usr/include/vtk-6.3 -I/usr/include/freetype2 
-I/usr/include/x86_64-linux-gnu -I/usr/include/eigen3 
-I/<>/liggghts-3.5.0+repack1 
-I/<>/liggghts-3.5.0+repack1/src  -g -O2 
-fdebug-prefix-map=/<>/liggghts-3.5.0+repack1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DLAMMPS_VTK6 -DLAMMPS_VTK -std=c++0x -DLAMMPS_JPEG -fPIC  
 -o CMakeFiles/libliggghts.dir/write_restart.cpp.o -c 
/<>/liggghts-3.5.0+repack1/src/write_restart.cpp
[ 99%] Linking CXX shared library libliggghts.so
cd /<>/liggghts-3.5.0+repack1/debian/build/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/libliggghts.dir/link.txt --verbose=1
/usr/bin/mpicxx  -fPIC -g -O2 
-fdebug-prefix-map=/<>/liggghts-3.5.0+repack1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DLAMMPS_VTK6 -DLAMMPS_VTK -std=c++0x -DLAMMPS_JPEG 
-Wl,-z,relro -Wl,--as-needed  -shared -Wl,-soname,libliggghts.so.3 -o 
libliggghts.so.3.3.1 CMakeFiles/libliggghts.dir/angle.cpp.o 
CMakeFiles/libliggghts.dir/angle_hybrid.cpp.o 
CMakeFiles/libliggghts.dir/atom.cpp.o CMakeFiles/libliggghts.dir/atom_map.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_atomic.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_charge.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_ellipsoid.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_hybrid.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_line.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sph.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sph_var.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sphere.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sphere_w.cpp.o CMakeFiles/libliggghts.dir/
 bond.cpp.o CMakeFiles/libliggghts.dir/bond_hybrid.cpp.o 
CMakeFiles/libliggghts.dir/bounding_box.cpp.o 
CMakeFiles/libliggghts.dir/cfd_datacoupling.cpp.o 
CMakeFiles/libliggghts.dir/cfd_datacoupling_file.cpp.o 
CMakeFiles/libliggghts.dir/cfd_datacoupling_mpi.cpp.o 
CMakeFiles/libliggghts.dir/cfd_regionmodel_none.cpp.o 
CMakeFiles/libliggghts.dir/change_box.cpp.o 
CMakeFiles/libliggghts.dir/citeme.cpp.o CMakeFiles/libliggghts.dir/comm.cpp.o 
CMakeFiles/libliggghts.dir/compute.cpp.o 
CMakeFiles/libliggghts.dir/compute_atom_molecule.cpp.o 
CMakeFiles/libliggghts.dir/compute_bond_local.cpp.o 
CMakeFiles/libliggghts.dir/compute_centro_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_cluster_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_cna_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_com.cpp.o 
CMakeFiles/libliggghts.dir/compute_com_molecule.cpp.o 
CMakeFiles/libliggghts.dir/compute_contact_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_coord_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_displace_atom.c
 pp.o CMakeFiles/libliggghts.dir/compute_erotate_multisphere.cpp.o 

Bug#851723: golang-github-elithrar-simple-scrypt: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-elithrar-simple-scrypt
Version: 1.1+git20161119.3.2325946-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/elithrar/simple-scrypt
golang.org/x/crypto/pbkdf2
golang.org/x/crypto/scrypt
github.com/elithrar/simple-scrypt
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/elithrar/simple-scrypt
=== RUN   TestGenerateRandomBytes
--- PASS: TestGenerateRandomBytes (0.00s)
=== RUN   TestGenerateFromPassword
--- PASS: TestGenerateFromPassword (6.56s)
=== RUN   TestCompareHashAndPassword
--- PASS: TestCompareHashAndPassword (0.15s)
=== RUN   TestCost
--- PASS: TestCost (0.05s)
=== RUN   TestDecodeHash
--- PASS: TestDecodeHash (0.00s)
=== RUN   TestCalibrate
--- FAIL: TestCalibrate (5.71s)
scrypt_test.go:137: GenerateFromPassword with scrypt.Params{N:524288, 
R:1, P:1, SaltLen:16, DKLen:32} took 249.695793ms ()
scrypt_test.go:142: 0. GenerateFromPassword was too fast (wanted around 
500ms, got 249.695793ms) with scrypt.Params{N:524288, R:1, P:1, SaltLen:16, 
DKLen:32}.
scrypt_test.go:137: GenerateFromPassword with scrypt.Params{N:262144, 
R:1, P:4, SaltLen:16, DKLen:32} took 466.108213ms ()
scrypt_test.go:137: GenerateFromPassword with scrypt.Params{N:131072, 
R:1, P:8, SaltLen:16, DKLen:32} took 451.196673ms ()
scrypt_test.go:137: GenerateFromPassword with scrypt.Params{N:65536, 
R:1, P:18, SaltLen:16, DKLen:32} took 492.462842ms ()
scrypt_test.go:137: GenerateFromPassword with scrypt.Params{N:8192, 
R:1, P:157, SaltLen:16, DKLen:32} took 425.840832ms ()
FAIL
exit status 1
FAILgithub.com/elithrar/simple-scrypt   12.502s
dh_auto_test: go test -v -p 1 github.com/elithrar/simple-scrypt returned exit 
code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/golang-github-elithrar-simple-scrypt/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

Thanks.

Bug#851724: python-llfuse: FTBFS (failing tests)

[Santiago Vila]

Package: src:python-llfuse
Version: 1.1.1+dfsg-5
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
pybuild --configure -i python{version} -p 2.7
I: pybuild base:184: python2.7 setup.py config 
running config
pybuild --configure -i python{version}-dbg -p 2.7
I: pybuild base:184: python2.7-dbg setup.py config 
running config
[88380 refs]
pybuild --configure -i python{version} -p 3.5
I: pybuild base:184: python3.5 setup.py config 

[... snipped ...]

make[1]: Leaving directory '/<>/python-llfuse-1.1.1+dfsg'
   dh_auto_test -i -O--buildsystem=pybuild
pybuild --test -i python{version} -p 2.7
I: pybuild base:184: cd 
/<>/python-llfuse-1.1.1+dfsg/.pybuild/pythonX.Y_2.7/build; python2.7 
-m pytest --installed "/<>/python-llfuse-1.1.1+dfsg/test/"
= test session starts ==
platform linux2 -- Python 2.7.13, pytest-3.0.5, py-1.4.32, pluggy-0.4.0 -- 
/usr/bin/python2.7
cachedir: ../../../test/.cache
rootdir: /<>/python-llfuse-1.1.1+dfsg/test, inifile: pytest.ini
plugins: catchlog-1.2.2
collecting ... collected 13 items

../../../test/test_api.py::test_inquire_bits PASSED
../../../test/test_api.py::test_listdir PASSED
../../../test/test_api.py::test_sup_groups PASSED
../../../test/test_api.py::test_entry_res PASSED
../../../test/test_api.py::test_xattr PASSED
../../../test/test_examples.py::test_lltest PASSED
../../../test/test_examples.py::test_tmpfs FAILED

=== FAILURES ===
__ test_tmpfs __
Traceback (most recent call last):
  File "/<>/python-llfuse-1.1.1+dfsg/test/pytest_checklogs.py", line 
127, in pytest_runtest_call
check_output(item)
  File "/<>/python-llfuse-1.1.1+dfsg/test/pytest_checklogs.py", line 
119, in check_output
check_test_output(cm._capturing, item)
  File "/<>/python-llfuse-1.1.1+dfsg/test/pytest_checklogs.py", line 
96, in check_test_output
raise AssertionError('Suspicious output to stderr (matched "%s")' % 
hit.group(0))
AssertionError: Suspicious output to stderr (matched "Exception")
- Captured stderr call -
Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
  File "/usr/lib/python2.7/threading.py", line 754, in run
  File "src/misc.pxi", line 261, in llfuse._notify_loop (src/llfuse.c:29495)
  File "/usr/lib/python2.7/Queue.py", line 179, in get
  File "/usr/lib/python2.7/threading.py", line 384, in notify
: 'NoneType' object is not callable
 Interrupted: stopping after 1 failures 
== 1 failed, 6 passed in 0.46 seconds ==
E: pybuild pybuild:276: test: plugin distutils failed with: exit code=2: cd 
/<>/python-llfuse-1.1.1+dfsg/.pybuild/pythonX.Y_2.7/build; python2.7 
-m pytest --installed "{dir}/test/"
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:10: recipe for target 'build-indep' failed
make: *** [build-indep] Error 25
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/python-llfuse/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine.

I know this is strange because it built fine last time on buildd.debian.org,
but I can reproduce the failure in 7 different machines. In case you need help
to reproduce it, please say so. As a last resort I could offer ssh access
to a machine where this happens.

Thanks.

Bug#851725: rclone: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:rclone
Version: 1.35-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang,bash-completion
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/ncw/rclone 
github.com/ncw/rclone/amazonclouddrive github.com/ncw/rclone/b2 
github.com/ncw/rclone/b2/api github.com/ncw/rclone/cmd 
github.com/ncw/rclone/cmd/all github.com/ncw/rclone/cmd/authorize 
github.com/ncw/rclone/cmd/cat github.com/ncw/rclone/cmd/check 
github.com/ncw/rclone/cmd/cleanup github.com/ncw/rclone/cmd/config 
github.com/ncw/rclone/cmd/copy github.com/ncw/rclone/cmd/copyto 
github.com/ncw/rclone/cmd/dedupe github.com/ncw/rclone/cmd/delete 
github.com/ncw/rclone/cmd/genautocomplete github.com/ncw/rclone/cmd/gendocs 
github.com/ncw/rclone/cmd/listremotes github.com/ncw/rclone/cmd/ls 
github.com/ncw/rclone/cmd/lsd github.com/ncw/rclone/cmd/lsl 
github.com/ncw/rclone/cmd/md5sum github.com/ncw/rclone/cmd/memtest 
github.com/ncw/rclone/cmd/mkdir github.com/ncw/rclone/cmd/mount 
github.com/ncw/rclone/cmd/move github.com/ncw/rclone/cmd/moveto 
github.com/ncw/rclone/cmd/purge github.com/ncw/rclone/cmd/rmdir 
github.com/ncw/rclone/cmd/rmdirs github.com/ncw/rc
 lone/cmd/sha1sum github.com/ncw/rclone/cmd/size github.com/ncw/rclone/cmd/sync 
github.com/ncw/rclone/cmd/version github.com/ncw/rclone/crypt 
github.com/ncw/rclone/crypt/pkcs7 github.com/ncw/rclone/dircache 
github.com/ncw/rclone/drive github.com/ncw/rclone/dropbox 
github.com/ncw/rclone/fs github.com/ncw/rclone/fs/all 
github.com/ncw/rclone/fstest github.com/ncw/rclone/fstest/fstests 
github.com/ncw/rclone/googlecloudstorage github.com/ncw/rclone/hubic 
github.com/ncw/rclone/local github.com/ncw/rclone/oauthutil 
github.com/ncw/rclone/onedrive github.com/ncw/rclone/onedrive/api 
github.com/ncw/rclone/pacer github.com/ncw/rclone/rest github.com/ncw/rclone/s3 
github.com/ncw/rclone/swift github.com/ncw/rclone/yandex 
github.com/ncw/rclone/yandex/api
github.com/Unknwon/goconfig
github.com/VividCortex/ewma
github.com/pkg/errors
github.com/spf13/pflag
github.com/tsenart/tb
golang.org/x/crypto/poly1305

[... snipped ...]

--- SKIP: TestObjectModTime (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectMimeType
--- SKIP: TestObjectMimeType (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectSetModTime
--- SKIP: TestObjectSetModTime (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectSize
--- SKIP: TestObjectSize (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectOpen
--- SKIP: TestObjectOpen (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectOpenSeek
--- SKIP: TestObjectOpenSeek (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectUpdate
--- SKIP: TestObjectUpdate (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectStorable
--- SKIP: TestObjectStorable (0.00s)
fstests.go:99: FS not configured
=== RUN   TestFsIsFile
--- SKIP: TestFsIsFile (0.00s)
fstests.go:99: FS not configured
=== RUN   TestFsIsFileNotFound
--- SKIP: TestFsIsFileNotFound (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectRemove
--- SKIP: TestObjectRemove (0.00s)
fstests.go:99: FS not configured
=== RUN   TestObjectPurge
--- SKIP: TestObjectPurge (0.00s)
fstests.go:99: FS not configured
=== RUN   TestFinalise
--- SKIP: TestFinalise (0.00s)
fstests.go:99: FS not configured
PASS
ok  github.com/ncw/rclone/yandex0.021s
?   github.com/ncw/rclone/yandex/api[no test files]
dh_auto_test: go test -v -p 1 github.com/ncw/rclone 
github.com/ncw/rclone/amazonclouddrive github.com/ncw/rclone/b2 
github.com/ncw/rclone/b2/api github.com/ncw/rclone/cmd 
github.com/ncw/rclone/cmd/all github.com/ncw/rclone/cmd/authorize 
github.com/ncw/rclone/cmd/cat github.com/ncw/rclone/cmd/check 
github.com/ncw/rclone/cmd/cleanup github.com/ncw/rclone/cmd/config 
github.com/ncw/rclone/cmd/copy github.com/ncw/rclone/cmd/copyto 
github.com/ncw/rclone/cmd/dedupe github.com/ncw/rclone/cmd/delete 
github.com/ncw/rclone/cmd/genautocomplete github.com/ncw/rclone/cmd/gendocs 
github.com/ncw/rclone/cmd/listremotes github.com/ncw/rclone/cmd/ls 
github.com/ncw/rclone/cmd/lsd github.com/ncw/rclone/cmd/lsl 
github.com/ncw/rclone/cmd/md5sum github.com/ncw/rclone/cmd/memtest 
github.com/ncw/rclone/cmd/mkdir github.com/ncw/rclone/cmd/mount 
github.com/ncw/rclone/cmd/move github.com/ncw/rclone/cmd/moveto 
github.com/ncw/rclone/cmd/purge github.com/ncw/rclone/cmd/rmdir 
github.com/ncw/rclone/cmd/rmdirs github.
 com/ncw/rclone/cmd/sha1sum 

Bug#851722: django-pipeline: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:django-pipeline
Version: 1.6.8-2
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:184: /usr/bin/python setup.py build 
running build

[... snipped ...]

default_collector.clear()
  File "/<>/pipeline/collector.py", line 23, in clear
dirs, files = self.storage.listdir(path)
  File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line 
399, in listdir
for entry in os.listdir(path):
OSError: [Errno 2] No such file or directory: '/<>/tests/static'

==
ERROR: test_pipeline_enabled_and_found 
(tests.tests.test_views.ServeStaticViewsTest)
--
Traceback (most recent call last):
  File "/<>/tests/tests/test_views.py", line 24, in setUp
default_collector.clear()
  File "/<>/pipeline/collector.py", line 23, in clear
dirs, files = self.storage.listdir(path)
  File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line 
399, in listdir
for entry in os.listdir(path):
OSError: [Errno 2] No such file or directory: '/<>/tests/static'

==
ERROR: test_pipeline_enabled_and_not_found 
(tests.tests.test_views.ServeStaticViewsTest)
--
Traceback (most recent call last):
  File "/<>/tests/tests/test_views.py", line 24, in setUp
default_collector.clear()
  File "/<>/pipeline/collector.py", line 23, in clear
dirs, files = self.storage.listdir(path)
  File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line 
399, in listdir
for entry in os.listdir(path):
OSError: [Errno 2] No such file or directory: '/<>/tests/static'

--
Ran 88 tests in 0.931s

FAILED (errors=8, skipped=15)
Creating test database for alias 'default'...
Destroying test database for alias 'default'...
E: pybuild pybuild:276: test: plugin custom failed with: exit code=1: 
PYTHONPATH=. python2.7 /usr/bin/django-admin test --settings=tests.settings
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:24: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
debian/rules:11: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/django-pipeline/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

Thanks.

Bug#851721: git-cola: New upstream release (2.10)

[Ghislain Antony Vaillant]

Package: git-cola
Severity: wishlist

Dear Maintainer,

Version 2.10 is out [1] and there is still time to get it packaged for
Stretch, maybe? ;-)

[1] https://github.com/git-cola/git-cola/releases/tag/v2.10

Cheers,
Ghis


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

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

Bug#844796:

[Richard Ayotte]

Adding /usr/lib/x86_64-linux-gnu/mutter to
/etc/ld.so.conf.d/x86_64-linux-gnu.conf and running ldconfig fixed it
for me. ldconfig doesn't process directories recursively and the
mutter directory was missing.

Here's what the conf looked like before the edit.

# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

Bug#851508: Russian translation for apt-listbugs/ru.po

[Francesco Poli]

On Tue, 17 Jan 2017 09:27:54 +0300 Sergey Alyoshin wrote:

> Updated translation.

Thanks for the explanations and for the updated translation!

I will soon push the translation to the public git repository; it will
be included in the next upload.

Your contribution is really appreciated!
Bye.

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


pgpNB8biu9my9.pgp
Description: PGP signature

Bug#851720: FTBFS on architectures with PIE disabled by default

[James Clarke]

Source: cmake
Version: 3.7.2-1
Severity: important

Hi,
The latest upload FTBFS on architectures which don't have PIE enabled by
default in GCC. This is because dpkg-buildflags includes specs files for
PIE, but GCC has been patched to ignore these and emit a note to stderr,
so several tests[0] which check stderr see unexpected messages of the
form "c++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored
when pie is not enabled".

Regards,
James

[0]: The following tests FAILED:
 296 - RunCMake.BuildDepends (Failed)
 329 - RunCMake.add_subdirectory (Failed)
 381 - RunCMake.install (Failed)
 390 - RunCMake.CrosscompilingEmulator (Failed)
 395 - RunCMake.CPack_DEB (Failed)

Bug#845819: nmu all revers build depends of eigen3

[Emilio Pozuelo Monfort]

On 26/11/16 23:03, Anton Gladky wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Dear release team,
> 
> the new version of header only library eigen3 has recently
> been released and uploaded into the Debian. Thus it would
> be good to rebuild all reverse dependencies of this package
> in the archive.
> 
> The arrached list contains all possible reverse-debendencies,
> which need to be binNMUed.

Why is this needed? Did libeigen break the ABI?

Cheers,
Emilio

Bug#851719: libbytelist-java: Package recent releases

[Miguel Landaeta]

Package: src:libbytelist-java
Version: 1.0.12-3
Severity: normal

The version of libbytelist-java available in the archive is not enough to
build jruby 9.1.6.0, so it must be updated.

I'll take care of it unless someone beat me to it.


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

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

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[gregor herrmann]

On Tue, 17 Jan 2017 18:06:02 -0500, Lincoln Stein wrote:

> Not good! But I believe that Gregor found that all these were caused by the
> testing suite not finding the proper data files due to an assumption about
> the current working directory. When he fixed this, there were just a
> handful of tests still failing. 

Right, that's when I built from a clone of the debian package git
repo. With your github repo, this was not necessary for reasons I
haven't yet understood.

> Gregor, is there a patch file that I can
> apply to get up to the same point you got to?

Oh, scratch what I wrote above, now I get the same with the debian
repo, so no more "Can't find foo in @INC". Good, at least the
failures are consistent now (for whatever reason, maybe the 5.24.1
upload to unstable changed something), and no patch for that part
needed.

So now we are still at:
 

t/03.render.t . 
1..150
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
ok 34
ok 35
ok 36
ok 37
ok 38
ok 39
ok 40
ok 41
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 109/150 subtests 
Sometimes this test gets 'stuck'. If this happens, kill the test and Build test 
again.
RenderPanels error: 
- EXCEPTION -
MSG: The requested glyph class, ``span'' is not available: Attempt to reload 
Bio/Graphics/Glyph/span.pm aborted.
Compilation failed in require at (eval 138) line 2, <> line 132.

STACK Bio::Graphics::Glyph::Factory::make_glyph 
/usr/share/perl5/Bio/Graphics/Glyph/Factory.pm:342
STACK Bio::Graphics::Glyph::add_feature 
/usr/share/perl5/Bio/Graphics/Glyph.pm:424
STACK Bio::Graphics::Browser2::RenderPanels::add_features_to_track 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1869
STACK (eval) 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1597
STACK Bio::Graphics::Browser2::RenderPanels::run_local_requests 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1551
STACK Bio::Graphics::Browser2::Render::Slave::render_tracks 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:471
STACK Bio::Graphics::Browser2::Render::Slave::run_operation 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:325
STACK Bio::Graphics::Browser2::Render::Slave::process_request 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:316
STACK Bio::Graphics::Browser2::Render::Slave::process_connection 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:240
STACK Bio::Graphics::Browser2::Render::Slave::request_loop 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:229
STACK Bio::Graphics::Browser2::Render::Slave::run 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:160
STACK toplevel t/04.remoteserver.t:81
-

Use of uninitialized value in numeric gt (>) at t/04.remoteserver.t line 136.
RenderPanels error: 
- EXCEPTION -
MSG: The requested glyph class, ``span'' is not available: Attempt to reload 
Bio/Graphics/Glyph/span.pm aborted.
Compilation failed in require at (eval 138) line 2, <> line 132.

STACK Bio::Graphics::Glyph::Factory::make_glyph 
/usr/share/perl5/Bio/Graphics/Glyph/Factory.pm:342
STACK Bio::Graphics::Glyph::add_feature 
/usr/share/perl5/Bio/Graphics/Glyph.pm:424
STACK Bio::Graphics::Browser2::RenderPanels::add_features_to_track 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1869
STACK (eval) 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1597
STACK Bio::Graphics::Browser2::RenderPanels::run_local_requests 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/RenderPanels.pm:1551
STACK Bio::Graphics::Browser2::Render::Slave::render_tracks 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:471
STACK Bio::Graphics::Browser2::Render::Slave::run_operation 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:325
STACK Bio::Graphics::Browser2::Render::Slave::process_request 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:316
STACK Bio::Graphics::Browser2::Render::Slave::process_connection 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:240
STACK Bio::Graphics::Browser2::Render::Slave::request_loop 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:229
STACK Bio::Graphics::Browser2::Render::Slave::run 
/build/gbrowse-2.56+dfsg/t/../lib/Bio/Graphics/Browser2/Render/Slave.pm:160
STACK toplevel t/04.remoteserver.t:81
-

Use of uninitialized value in numeric gt (>) at t/04.remoteserver.t line 136.
RenderPanels error: 
- EXCEPTION -
MSG: The requested glyph class, ``span'' is not available: Attempt to reload 

Bug#851613: src:bottleneck: Tests fail if enabled

[Ghislain Vaillant]

On Tue, 2017-01-17 at 22:35 +0100, Pietro Battiston wrote:
> Il giorno mar, 17/01/2017 alle 18.24 +, Ghislain Vaillant ha
> scritto:
> > [...]
> > There are 2 options:
> > 
> > 1) Do an upload with tests enabled, knowing it would FTBFS, and file
> > an
> > RC for it. Once numpy gets eventually fixed, request a binNMU to
> > clear
> > the RC.
> > 
> > 2) Mark #851613 severity RC, wait for a suitable version of numpy to
> > be
> > uploaded and make the upload with tests enabled and clearing the RC.
> > 
> > In the state things are currently, bottleneck should not be released
> > in
> > Stretch. These 2 options would achieve exactly that. Feel free to
> > bring
> > your usual sponsor along to the discussion, perhaps he or she would
> > have a preference.
> > 
> 
> I am a bit confused. It seems to me that bottleneck itself is not in
> worse shape than before the numpy regression was introduced.

It is still not worth releasing as it is. Sure the binary packages do
build, but they fail to test with the current version of Numpy.
Assuming, numpy stays in this version for the release, i.e. without the
fix for the regression, then we'd be effectively releasing a buggy
bottleneck package for Stretch.

In versioning semantics, think of it as:

bottleneck: install_requires = ["numpy>= 1.12.1,<1.12.0"]

> So while
> we can discuss what is the best move for numpy, I don't follow you when
> you say that "In the state things are currently, bottleneck should not
> be released in Stretch". That said, assuming you are right on this,
> does 2) have any disadvantage compared to 1) (other than not fixing
> #851520 immediately)?

I have a better idea. I am forwarding you the modifications I had to
make in order to get the packaging to work with its autopkgtest test
suite, plus associated log from a build done on my machine in a clean
chroot.

The trick here is that I temporarily bypass the test failures so the
build carries on anyway despite the failures. But with this, you will
both get the test logs from the build logs to motivate the RC *and*
autopkgtest logs to check when the regression from numpy is fixed.

Your Python 3 package was also buggy: the substvar to use in d/control
is python3:Depends not python:Depends, and there was no call to
dh_numpy3. I fixed this using a standard override on dh_python{2,3} to
call the appropriate dh_numpy{,3} command. 

You may upload a new version of bottleneck with these changes, and then
raise #851613 to RC once you get the first build logs out.

How's that sounding?

GhisFrom 532aef978651379bb2ce40d5309b9b1c699c2b05 Mon Sep 17 00:00:00 2001
From: Ghislain Antony Vaillant 
Date: Tue, 17 Jan 2017 22:59:19 +
Subject: [PATCH 5/5] Fix dh_python{2,3} / dh_numpy{,3} calls

---
 debian/control | 2 +-
 debian/rules   | 9 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 58bf91e..9a6d192 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Description: Fast NumPy array functions written in C - Python 2
 
 Package: python3-bottleneck
 Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Enhances: python3-pandas
 Description: Fast NumPy array functions written in C - Python 3
  Bottleneck is a collection of fast NumPy array functions written in C.
diff --git a/debian/rules b/debian/rules
index 8ea155e..1852cca 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,5 +16,12 @@ override_dh_auto_test:
 
 override_dh_auto_install:
 	dh_auto_install
-	dh_numpy
 	dh_installchangelogs RELEASE.rst
+
+override_dh_python2:
+	dh_python2
+	dh_numpy
+
+override_dh_python3:
+	dh_python3
+	dh_numpy3
-- 
2.11.0

From d37f6aebd2c89a4024e14c71f7bde215e786109e Mon Sep 17 00:00:00 2001
From: Ghislain Antony Vaillant 
Date: Tue, 17 Jan 2017 19:13:31 +
Subject: [PATCH 4/5] Clean build artefacts

---
 debian/clean | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 debian/clean

diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..320765d
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1,4 @@
+bottleneck/src/move.c
+bottleneck/src/nonreduce.c
+bottleneck/src/nonreduce_axis.c
+bottleneck/src/reduce.c
-- 
2.11.0

From d2ef202ee080cc6480152af4d09edcfcc4596e8e Mon Sep 17 00:00:00 2001
From: Ghislain Antony Vaillant 
Date: Tue, 17 Jan 2017 19:11:17 +
Subject: [PATCH 3/5] Bypass test failures temporarily

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 3d37c48..8ea155e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,9 @@ override_dh_auto_build:
 	dh_auto_build
 	http_proxy='127.0.0.1:9' python setup.py build_sphinx
 
+override_dh_auto_test:
+	dh_auto_test || true
+
 override_dh_auto_install:
 	dh_auto_install
 	dh_numpy
-- 
2.11.0

From 21e9f51431db8019e6b89f5d64d3d8ce86ebb609 Mon Sep 17 

Bug#850801: unblock: win32-loader/0.8.1

[Joerg Jaspert]

On 14548 March 1977, Didier Raboud wrote:
> ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing 

Done

-- 
bye, Joerg

Bug#851678: RM: openchange -- RoQA; incompatible with updated samba

[Paul Wise]

On Tue, Jan 17, 2017 at 10:26 PM, Andreas Beckmann wrote:

> I'm not perfectly convinced about this RM request, but something should
> happen with openchange in stable:

At $work we rely on openchange but not openchangeproxy. We know it was
removed from stretch and later but were assuming we could use it on
jessie, once we have migrated from wheezy. The wheezy to jessie
migration is blocked by some regression bugs in jessie Linux CIFS
support that we are in the process of debugging. Once we have fixed
that, we would like to start migrating systems to jessie. Post-jessie
we don't yet have a strategy but are looking into options.

> * openchangeproxy (1:2.2-5) is uninstallable in stable (#838671)
>   samba-libs has a Breaks: openchangeproxy (<< 1:2.2-6) that stems from
>   the first samba 4.2 upload to jessie-security:

I guess this could be fixed by a new upload that either drops
openchangeproxy or fixes the API/ABI usage.

> * openchange FTBFS in stable (I just mentioned this in #838671)
>   (the version in stable was most likely built against samba 2:4.1.13+dfsg-4)

This looks like the API issue in openchangeproxy mentioned in the
samba changelog from the build log messages you posted.

This is the openchange bug and patch for this specific FTBFS:

https://github.com/openchange/openchange/issues/249
https://github.com/openchange/openchange/commit/73a49af50bf0a496cfe62f49e60a662f1d04d685.patch

> * openchange was removed from unstable due to incompatibility with
>   newer samba versions

Unfortunately the openchange project is dead upstream so it won't be
coming back.

> * downside: openchange builds a lot more packages than just openchangeproxy
>   these are all still installable in stable (according to piuparts)

At $work we rely on openchangeclient and several of the -dev packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#851634: sh -n checks

[積丹尼 Dan Jacobson]

I would add a sh -n test to the build scripts to avoid such errors
getting sent out.

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Ah...the logic is in debian/rescue-mode.postinst; I had assumed it
would be elsewhere.  I'll take some time to study this thoroughly, and
to do a VM install and rescue to see how the LVM case works.  If you
know if it's closer to (1) or (2) in my last email.

Is Feb 5th (Full freeze) the final deadline for this work?  Deadline
being, it needs to have been submitted to ftp-masters before then.

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#851718: xscreensaver-data: high CPU load when m6502 running

[Mark Carroll]

Package: xscreensaver-data
Version: 5.30-1+deb8u2
Severity: wishlist

Dear Maintainer,

On an XFCE4 system the screensaver has cut in and I notice that
computer's fan is now running loudly. Checking "top", the m6502
process is busy indeed -

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
17321 moxie 30  10  265104  13864  12024 S 112.4  0.2  10:33.77 m6502  

In case it is relevant, the graphics card is
Intel Corporation Broadwell-U Integrated Graphics
in an ASUS X555LA laptop.

It would be great if the basic screensavers could be a little more
lightweight: perhaps the inefficient ones could be off in an extras
package.

(Ah, the fan's quieter now, it's switched to metaballs.)

Cheers,

Mark


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

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

Versions of packages xscreensaver-data depends on:
ii  libc6   2.19-18+deb8u7
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.42.1-1+b1
ii  libice6 2:1.0.9-1+b1
ii  libjpeg62-turbo 1:1.3.1-12
ii  libsm6  2:1.2.2-1+b1
ii  libwww-perl 6.08-1
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  libxmu6 2:1.1.2-1
ii  libxpm4 1:3.5.11-1+b1
ii  libxt6  1:1.1.4-1+b1

xscreensaver-data recommends no packages.

Versions of packages xscreensaver-data suggests:
ii  xscreensaver  5.30-1+deb8u2

-- no debconf information

Bug#851194: dgit: please document how to set up dgit infrastructure.

[peter green]

This is a draft of how I set up the private side of the dgit server and client 
for raspbian. It may be incomplete. I have still to document the setup for the 
public side of the dgit server.

I have acheived a succesful push of a patched xen package with this 
configuration.

(replace raspbian and raspbian-related urls in these instructions with the name 
and urls of your distro)

server push setup

add a user dgit

create /home/dgit/ssh-wrap with the following contents

#!/bin/sh
set -e
umask 002

srvdir=/home/dgit
dispatchdir=$srvdir/dispatch-dir
#dgitlive=$srvdir/dgit-live

PERLLIB="$dgitlive${PERLLIB+:}${PERLLIB}" \
#exec $dgitlive/infra/dgit-ssh-dispatch $dispatchdir
exec dgit-ssh-dispatch $dispatchdir

create /home/dgit/dispatch-dir/distro=raspbian
in that directory put
a subdirectory called repos with a subdirectory called _template containing a 
bare git repo all owned by user dgit
a file called keyring.gpg containing the gpg keys with access to push to the 
repo
(you can import keys to the keyring with gpg --no-default-keyring --keyring 
dispatch-dir/distro\=raspbian/keyring.gpg  --import )
a file called policy-hook containing a copy of 
/usr/bin/dgit-repos-policy-trusting
a file called suites containing a list of allowed suites

in /home/dgit/.ssh/authorized-keys add lines like

command="/home/dgit/ssh-wrap" ssh-rsa  

The dgit server has a commit check, unfortunately I found that this commit 
check seems to be too strict (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851716 ). There is supposedly 
a way to disable this through the policy hook but I couldn't make that work.

So as a temporary soloution I just commented out that block of code (it can be 
found in /usr/bin/dgit-repos-server and starts with if (!($policy & 
NOCOMMITCHECK)) { )

Client setup

#!/bin/sh
git config dgit-distro.raspbian.git-url https://dgit.raspbian.org/
git config dgit-distro.raspbian.git-url-suffix .git
git config dgit-distro.raspbian/push.git-url ""
git config dgit-distro.raspbian/push.git-host dgit.raspbian.org
git config dgit-distro.raspbian/push.git-user-force dgit
git config dgit-distro.raspbian/push.git-proto "git+ssh://"
git config dgit-distro.raspbian/push.git-path "/dgit/raspbian/repos"
git config dgit-distro.raspbian.git-check "true"
git config dgit-distro.raspbian.git-check-suffix "/info/refs"
git config dgit-distro.raspbian/push.git-check "ssh-cmd"
git config dgit-distro.raspbian/push.git-create "true"
git config dgit-distro.raspbian.upload-host raspbian
git config dgit-distro.raspbian.mirror http://archive.raspbian.org/raspbian
git config dgit-distro.raspbian.archive-query "aptget:"
git config dgit-suite.wheezy-staging.distro raspbian
git config dgit-suite.jessie-staging.distro raspbian
git config dgit-suite.stretch-staging.distro raspbian

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[Lincoln Stein]

Not good! But I believe that Gregor found that all these were caused by the
testing suite not finding the proper data files due to an assumption about
the current working directory. When he fixed this, there were just a
handful of tests still failing. Gregor, is there a patch file that I can
apply to get up to the same point you got to?

Lincoln

On Tue, Jan 17, 2017 at 2:07 AM, Andreas Tille  wrote:

> Hi Lincoln,
>
> On Mon, Jan 16, 2017 at 06:14:34PM -0500, Lincoln Stein wrote:
> > I need a little help to reproduce Gregor's failed tests, given that I'm a
> > complete newbie wrt the Debian packaging system. I have cloned gbrowse
> > 2.56+dfsg-1 from the Debian Med repository, but I don't know what command
> > line to use to attempt the build. What is the next step? I'm guessing it
> is
> > some form of dpkg-buildpackage, but the number of options is pretty
> > overwhelming!
>
> If you have installed the devscripts package you can try
>
> debuild
>
> which is a wrapper around dpkg-buildpackage and in principle needs no
> options to reproduce the issue.  Debuild will inform you about missing
> Build-Dependencies you need to install - simply use apt-get install what
> is listed if anything is missing.  When doing so I get
>
> ...
> Test Summary Report
> ---
> t/00.compile.t  (Wstat: 3840 Tests: 90 Failed: 15)
>   Failed tests:  1, 3, 5, 7, 10, 15, 17-18, 29, 31, 33, 35
> 41, 45, 47
>   Non-zero exit status: 15
> t/02.rearchitecture.t   (Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 90 tests but ran 0.
> t/03.render.t   (Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 150 tests but ran 0.
> t/04.remoteserver.t (Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 43 tests but ran 0.
> t/05.deferredrendering.t (Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 19 tests but ran 0.
> t/06.featuresearch.t(Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 26 tests but ran 0.
> t/07.karyotype.t(Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 3 tests but ran 0.
> Files=10, Tests=103,  5 wallclock secs ( 0.05 usr  0.01 sys +  4.19 cusr
> 0.30 csys =  4.55 CPU)
> Result: FAIL
> Failed 7/10 test programs. 15/103 subtests failed.
> dh_auto_test: perl Build test --verbose 1 TEST_FILES=t/02.rearchitecture.t
> t/05.deferredrendering.t t/00.compile.t t/01.yeast.t t/07.balancer.t
> t/08.calign.t returned exit code 255
>
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>



-- 
*Lincoln Stein*

Scientific Director (Interim), Ontario Institute for Cancer Research
Director, Informatics and Bio-computing Program, OICR
Senior Principal Investigator, OICR
Professor, Department of Molecular Genetics, University of Toronto


*Ontario Institute for Cancer Research*
MaRS Centre
661 University Avenue
Suite 510
Toronto, Ontario
Canada M5G 0A3

Tel: 416-673-8514
Mobile: 416-817-8240
Email: lincoln.st...@gmail.com
Toll-free: 1-866-678-6427
Twitter: @OICR_news

*Executive Assistant*
*Lisa Duncan*
Tel: 647-260-7970 <(647)%20260-7970>
Email: lisa.dun...@oicr.on.ca 
www.oicr.on.ca

This message and any attachments may contain confidential and/or privileged
information for the sole use of the intended recipient. Any review or
distribution by anyone other than the person for whom it was originally
intended is strictly prohibited. If you have received this message in
error, please contact the sender and delete all copies. Opinions,
conclusions or other information contained in this message may not be that
of the organization.

Bug#810745: postinst script differs from bird

[txt.file]

I just checked the bird and bird-bgp packages and they differ in the
control.tar.gz content.

bird-bgp is missing an preinst file and the postinst file is ~15 lines
shorter. These 15 lines contain an "adduser … bird" command.

kind regards
txt.file
--
This message is signed.

Bug#851653: RM: packages with RC bugs requesting omission from testing

[Emilio Pozuelo Monfort]

On 17/01/17 11:00, Simon McVittie wrote:
> On Tue, 17 Jan 2017 at 09:44:26 +, Simon McVittie wrote:
>> In each case the first package listed is the one with the RC bug, and
>> subsequent packages are reverse dependencies according to
>> dak rm -R -n -s testing.
> 
> Sorry, missed one:
> 
> # RoM: #819404
> remove libnagios-plugin-perl/0.36-2 nagios-plugins-rabbitmq/1:1.2.0-2.1
> 
> (There's also readline6 and gcc-5, but those are more complicated
> because things currently still depend on them, and should presumably
> be tracked as their own bugs.)

I haven't tracked gcc-5, but I've been tracking readline6, see the transition
bug and the tracker at release.debian.org/transitions/. I should be able to
remove that in a few days once heimdal and sdb migrate to testing.

Cheers,
Emilio

Bug#849189: mini transition: libcec

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 23/12/16 12:19, Bálint Réczey wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I would like to update libcec in unstable to the 4.0 version because
> kodi upstream switched to using it from kodi 17 beta 5. At the moment
> kodi package is patched to use the older libcec 3 but this is an
> undesirable divergence from upstream.
> 
> The mini transition would involve libcec and its single reverse
> dependency, kodi, which I plan updating to beta6.
> 
> I'm aware of the transitions freeze but given the minimal impact and
> risk of this transition I think it may get an exception.

I don't think you need a transition bug when there's just one rdep and you
maintain it... But sure, go ahead. I think this warrants an exception.

Cheers,
Emilio

Bug#851697: Cannot push when archive access method is `aptget'

[peter green]

On 17/01/17 20:42, peter green wrote:

On 17/01/17 19:00, Ian Jackson wrote:

Package: dgit
Version: 3.4

If one tries to set up dgit push support for a distro which does not
have an ftpmaster api interface, and instead uses the aptget archive
access method, this happens:

Undefined subroutine ::file_in_archive_aptget called at /usr/bin/dgit line 
1023.

This functionality is missing and needs to be implemented.

Having taken a quick look myself it seems that some of the access methods have a stub 
implementation of that function that just returns "undef". Furthermore it seems 
that the code that calls that function has a path for handling such a return value.

So I copied the stub function from "dummycat" to "aptget".

I'll post up a debdiff with this and any other changes I end up making to dgit 
later.

here is a debdiff adding the stub implementation


diff -Nru dgit-3.2/debian/changelog dgit-3.2+rpi1/debian/changelog
--- dgit-3.2/debian/changelog   2017-01-12 02:11:34.0 +
+++ dgit-3.2+rpi1/debian/changelog  2017-01-17 19:52:37.0 +
@@ -1,3 +1,10 @@
+dgit (3.2+rpi1) stretch-staging; urgency=medium
+
+  * Add dummy implementation of file_in_archive_aptget copied from
+file_in_archive_dummycat (partially fixes: 851697)
+
+ -- Peter Michael Green   Tue, 17 Jan 2017 19:52:37 
+
+
 dgit (3.2) unstable; urgency=medium
 
   Bugfixes:
diff -Nru dgit-3.2/dgit dgit-3.2+rpi1/dgit
--- dgit-3.2/dgit   2017-01-12 01:36:35.0 +
+++ dgit-3.2+rpi1/dgit  2017-01-17 19:52:11.0 +
@@ -1318,6 +1318,8 @@
 return [ (getfield $pre_dsc, 'Version'), $uri ];
 }
 
+sub file_in_archive_aptget () { return undef; }
+
 #-- `dummyapicat' archive query method --
 
 sub archive_query_dummycatapi { archive_query_ftpmasterapi @_; }

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Hi Philipp,

Thank you for the clarification, and sorry for my tardy reply.

On Wed, Jan 04, 2017 at 12:04:09AM +0100, Philipp Kern wrote:
> On 12/19/2016 05:49 AM, Nicholas D Steeves wrote:
> > Which rescue mode, and where?  Please tell me so I can fix it!  From
> > what I've read, setting a default subvolid != 5 was explored by other
> > distributions, and abandoned.
> 
> rescue-mode is in [0]. That presents you with a menu where you can
> select local root filesystems. That should somehow DTRT instead of
> mounting the top-level btrfs filesystem with the root filesystem being
> below. I suppose it'd be also ok to mount it as-is, as long as the shell
> is spawned in the right place. (Although that might be surprising.)
> 
> The mode is triggered by passing "rescue/enable=true" on the kernel
> command-line. d-i ships with boot menu items that do this.
> 
> Kind regards
> Philipp Kern
> 
> [0] https://anonscm.debian.org/cgit/d-i/rescue.git/tree/
> 

Oh, there!  I had already checked that out in
debian-installer/packages/rescue.  :-) From what I gather, DTRT looks
something like one of the following:

1. Use existing choose partition menu
  * select partition menu
  * test if selected partition is a btrfs volume
-  if there are no subvolumes, use present behaviour
  * if subvolumes exist
- install btrfs-progs udeb
- use btrfs subvol list to read subvols
- present a menu

How is this currently handled for LVM?  There is very little code in
"rescue" itself, and I haven't yet managed to figure out how
everything fits together.

2. Alternatively, duplicate the existing LVM code, then modify it for
   btrfs.

If you could point me to whatever 'rescue' ties into for LVM support I
would be very grateful!  From what I've gathered so far, "rescue"
dependency on the btrfs application is provided by the btrfs-progs udeb and
not through initramfs

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#851696: RFS: python-qtpy/1.2.0-1

[Ghislain Vaillant]

Hi Fred,

On Tue, 2017-01-17 at 19:30 +, PICCA Frederic-Emmanuel wrote:
> Hello Ghislain.
> 
> do you know if this version is compatible with the reverse dependencies 
> already in Debian ?

First of, the upstream changelog did not mention any API breakage, only
fixes and new features (support for qtmultimedia).

> python-qtpy
> Reverse Depends:
>   python-spyder
>   python-ginga
>   python-qtawesome
>   python-glue

Both qtpy 1.1.2 and qtpy 1.2.0 works with spyder 3.0.2 (tested in a
venv). Since qtpy was designed for spyder, it is probably the best
possible test we have in hand.

> We are close from the freeze and I do not want to end up with a bunch of 
> autorm packages due to this kind of upload.

I know, and there is still roughly a week to go. Since I use the
packaged spyder, pyzo and git-cola quite extensively, I should be able
to catch potential breakage quite quickly.

> BUT if you can show that there is no problem I am ok to sponsorize this 
> package.

Your call.

Ghis

Bug#851696: RFS: python-qtpy/1.2.0-1

[Ghislain Vaillant]

Hi Fred,

On Tue, 2017-01-17 at 19:30 +, PICCA Frederic-Emmanuel wrote:
> Hello Ghislain.
> 
> do you know if this version is compatible with the reverse dependencies 
> already in Debian ?

First of, the upstream changelog did not mention any breakage, only
fixes and new features (support for qtmultimedia). Upstream has had a
good track record at keeping these in check so far.

> python-qtpy
> Reverse Depends:
>   python-spyder
>   python-ginga
>   python-qtawesome
>   python-glue

Both qtpy 1.1.2 and qtpy 1.2.0 works with spyder 3.0.2 (tested in a
venv). Since qtpy was designed for spyder in the first place, it is
probably the best
possible test we have in hand.

In addition, I have checked pyzo and git-cola. Both works fine with
qtpy 1.1.2 and 1.2.0.

> We are close from the freeze and I do not want to end up with a bunch of 
> autorm packages due to this kind of upload.

Based on my initial testing, I am confident this is safe. I'd still
have a week to fix things if disaster strikes, but I'd be really
suprised.

> BUT if you can show that there is no problem I am ok to sponsorize this 
> package.

Your call.

Ghis

Bug#850981: diaspora-installer: fails to start as bin/bundle points to /usr/local/bin/bundle

[Julian Gilbey]

On Sat, Jan 14, 2017 at 09:23:15PM +0530, Pirate Praveen wrote:
> On Wed, 11 Jan 2017 18:09:30 + Julian Gilbey  wrote:
> > I found that diaspora, installed via diaspora-installer, wouldn't
> > start, as /usr/share/diaspora/bin/bundle pointed to
> > /usr/local/bin/bundle, and I ended up with loads of error messages in
> > the log files.  On changing this link to point to the system-installed
> > /usr/bin/bundle, it got much further!
> > 
> > But maybe this is wrong for some reason I don't understand...
> 
> We usually need the latest version of bundler so we use rubygems
> installed bundler for diaspora-installer. Can you share the error
> messages in the log files?

Hi Pirate,

I just tried installing the latest versions from scratch and they
seem to work, yay!  (I haven't been able to actually test it live, as
I have another instance of diaspora running, but I was able to
install it, configure it and then run it, which is further than I got
last time.

diaspora-common still needs the dbconfig-common purge code in the
prerm/postrm files.  Also, purging diaspora-installer should probably
do an rm -rf /usr/share/diaspora, but I'm not certain about this.

Best wishes,

   Julian

Bug#851717: packaging-tutorial: [INTL:pt] Updated Portuguese translation of documentation.

[Américo Monteiro]

Package: packaging-tutorial
Version: 0.19
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for packaging-tutorial's documentation.
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator'


-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

packaging-tutorial_0.19_pt.po.gz
Description: application/gzip

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Rebecca N. Palmer]

Control: tags -1 patch

One way to reproduce this bug:
# apt-get install pocl-opencl-icd blender
$ gdb blender
open User Preferences -> System
This promptly crashes; beignet-opencl-icd 1.2.1-1 (LLVM 3.8, like pocl) 
also triggers it, but beignet-opencl-icd 1.2.1-2 and mesa-opencl-icd 
(LLVM 3.9, like the graphics part of mesa) don't.


#0  llvm::cl::Option::setArgStr(llvm::StringRef) ()
at /build/llvm-toolchain-3.9-3.9.1/include/llvm/ADT/SmallPtrSet.h:224
No locals.
#1  0x7fffbbe9aacb in llvm::cl::opt<(anonymous 
namespace)::HelpPrinter, true, llvm::cl::parser >::optllvm::cl::desc, llvm::cl::LocationClass<(anonymous 
namespace)::HelpPrinter>, llvm::cl::OptionHidden, 
llvm::cl::ValueExpected, llvm::cl::cat>(char const (&) [17], 
llvm::cl::desc const&, llvm::cl::LocationClass<(anonymous 
namespace)::HelpPrinter> const&, llvm::cl::OptionHidden const&, 
llvm::cl::ValueExpected const&, llvm::cl::cat const&) [clone 
.constprop.300] ()
at 
/build/llvm-toolchain-3.8-3.8.1/include/llvm/Support/CommandLine.h:1041

No locals.
#2  0x7fffbbe9ad08 in _GLOBAL__sub_I_CommandLine.cpp ()
at /build/llvm-toolchain-3.8-3.8.1/lib/Support/CommandLine.cpp:1661
No locals.
#3  0x77de95da in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#4  0x77de96eb in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#5  0x77dedc68 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#6  0x77de9484 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#7  0x77ded419 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#8  0x7fffee0f0ee9 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#9  0x77de9484 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#10 0x7fffee0f1521 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#11 0x7fffee0f0f82 in dlopen () from /lib/x86_64-linux-gnu/libdl.so.2
No symbol table info available.
#12 0x7fffbf9f9212 in ?? () from 
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1

No symbol table info available.
#13 0x7fffbf9f9360 in ?? () from 
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1

No symbol table info available.
#14 0x7fffbf9f98d0 in ?? () from 
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1

No symbol table info available.
#15 0x7fffbf9fa0d3 in clGetPlatformIDs ()
   from /usr/lib/x86_64-linux-gnu/libOpenCL.so.1
No symbol table info available.

The relevant lines of the LLVM build log appear to be

Scanning dependencies of target LLVM
make[4]: Leaving directory '/«PKGBUILDDIR»/build-llvm'
/usr/bin/make -f tools/llvm-shlib/CMakeFiles/LLVM.dir/build.make 
tools/llvm-shlib/CMakeFiles/LLVM.dir/build

make[4]: Entering directory '/«PKGBUILDDIR»/build-llvm'
[ 76%] Building CXX object 
tools/llvm-shlib/CMakeFiles/LLVM.dir/libllvm.cpp.o
cd /«PKGBUILDDIR»/build-llvm/tools/llvm-shlib && /usr/bin/g++-6 
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I/«PKGBUILDDIR»/build-llvm/tools/llvm-shlib 
-I/«PKGBUILDDIR»/tools/llvm-shlib -I/«PKGBUILDDIR»/build-llvm/include 
-I/«PKGBUILDDIR»/include  -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold 
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -O2 -g -DNDEBUG -fPIC-fno-exceptions -o 
CMakeFiles/LLVM.dir/libllvm.cpp.o -c 
/«PKGBUILDDIR»/tools/llvm-shlib/libllvm.cpp

[ 76%] Linking CXX shared library ../../lib/libLLVM-3.9.so
cd /«PKGBUILDDIR»/build-llvm/tools/llvm-shlib && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/LLVM.dir/link.txt --verbose=1
/usr/bin/g++-6  -fPIC -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold -fPIC 
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -O2 -g -DNDEBUG  -Wl,-O3 -Wl,--gc-sections -Wl,-z,relro 
-Wl,-z,defs -shared -Wl,-soname,libLLVM-3.9.so.1 -o 
../../lib/libLLVM-3.9.so.1 CMakeFiles/LLVM.dir/libllvm.cpp.o 
-Wl,-rpath,"\$ORIGIN/../lib" -Wl,--whole-archive [big list of 
../../lib/libLLVM(something).a libraries] -lrt -ldl -ltinfo -lpthread 
-lz -lm
cd /«PKGBUILDDIR»/build-llvm/tools/llvm-shlib && /usr/bin/cmake -E 
cmake_symlink_library ../../lib/libLLVM-3.9.so.1 
../../lib/libLLVM-3.9.so.1 ../../lib/libLLVM-3.9.so

make[4]: Leaving directory '/«PKGBUILDDIR»/build-llvm'
[ 76%] Built target LLVM

i.e. the main libLLVM shared library doesn't use a version script at 
all.  (Some of its other libraries do have "version scripts", but these 
are used for their other function of limiting which symbols are public, 

Bug#851716: dgit: commit checks may be too strict

[peter green]

Package: dgit

I have been trying to set up a dgit server for raspbian.

Unfortunately the dgit server rejected my push claiming commit 
71e128629ec786f3e45f2cffdf0792125b76e520 had missing metadata.

Further investigation shows that this commit is present on dgit.debian.org

https://browse.dgit.debian.org/xen.git/commit/?id=71e128629ec786f3e45f2cffdf0792125b76e520

And further investigation seems to show it originates from xen upstream

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=71e128629ec786f3e45f2cffdf0792125b76e520

I find the checking code almost impenetrable but I think it's refusing the 
commit because the author has an email but no name.

Github seems quite happy with the commit as does git fsck, so IMO this is a 
case of dgit being too strict.

There is supposedly a policy code I can use to make dgit ignore the check but 
whenever I try and add it to my policy I get

dgit-repos-server: policy hook failed (or rejected) (2048)

I have tried three different ways of adding it to the policy

1. Changing bitmask=0 to bitmask=8
2. Adding bitmask=$(( bitmask | `policyflags 'NOCOMMITCHECK'` )) just before 
the exit command
3. Adding bitmask=$(( bitmask | 8 )) just before the exit command

Bug#851003: Can't reproduce FTBFS

[Adrian Bunk]

Adding Lucas, the BTS does not Cc the submitter.

On Tue, Jan 17, 2017 at 02:42:36PM +0100, Ondřej Kobližek wrote:
> Hi,
> I can't reproduce FTBFS.
> My building environment builds package fine.
> 
> Debian reproducible-builds are OK for amd64:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-pyscss.html
> 
> Lowered severity to normal level.
> 
> Ondrej Koblizek

Bug#851715: partman-base: "Partition disks" list should show LVM volume groups

[Samuel Thibault]

Package: partman-base
Version: 189
Severity: normal

Hello,

The typical scenario is this: a new computer with pre-installed windows
which we do want to keep as such (and thus guided partitioning using the
whole disk is a no-go), and install Debian in an LVM or encrypted LVM.
The way I would do it is: first go to the manual menu, set up an LVM
volume group, or setup up an encrypted volume and set up an LVM volume
group, and then select guided partitioning to let d-i partition the
available volume.  This is how it works with RAID, for instance.  But
while in the RAID case, the md volume shows up in the list of disks, in
the LVM case the volume group does not show up.

More precisely, for instance:

create example disk with existing partition:

- dd < /dev/zero > disk bs=1M count=1 seek=1
- /sbin/fdisk disk
  n
  p
  2048
  +1G
  t
  c

then boot the installer and at partitioning step:

- Manual
- Configure the Logical Volume Manager
- Create volume group with the free space on the disk
  (do *not* create logical volumes since the idea is that it's guided
  partitioning which does it).
- Finish
- Guided partitioning
- Guided - use entire disk
- the presented list only shows SCSI1, while it should also list the LVM
  volume group

The LVM+crypt scenario is a matter of inserting this between "Manual"
and "Configure the Logical Volume Manager":

- Configure encrypted volumes
- Create encrypted volumes
- Use the free space on the disk
- Finish

and using the encrypted volume.


For an instance of the RAID case where things do work as expected, with
two physical disks:

- Manual
- Create empty partition tables on both disks
- Configure software RAID
- Create MD device
- RAID1
- 2 active devices
- 0 space device
- select both disks
- Finish
- Guided partitioning
- Guided - use entire disk
- There we can select RAID1

Samuel

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

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

-- 
Samuel
Accroche-toi au terminal, j'enlève le shell...
 -+- nojhan -+-

Bug#851517: piuparts uses apt --allow-downgrades even if it should not

[Sean Whitton]

On Tue, Jan 17, 2017 at 02:02:06PM +0100, Andreas Beckmann wrote:
> Control: tag -1 pending
> 
> On 2017-01-15 23:19, Holger Levsen wrote:
> > On Sun, Jan 15, 2017 at 03:07:07PM -0700, Sean Whitton wrote:
> >> I tested LooseVersion with the version of apt in wheezy:
> 
> do we need LooseVersion?
> 
> at other places (not yet in piuparts.py) we use
> apt_pkg.version_compare() and I'd like to be consistent

No.  I wasn't aware of that other function.  Hopefully that will fix
it -- thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850723: heimdal: FTBFS on x32 because libtommath thinks it’s amd64

[Thorsten Glaser]

Dominique Dumont dixit:

>Done in lilbtommath 1.0-4 and pushed to upstream [1] .

Thank you!

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#851714: gitlab: Cannot push to gitlab repositories with git >= 2.11.0

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg2-2
Severity: grave

Dear Maintainer,

Gitlab repositories will no longer accept remote pushes to protected branches
(which is the default!) with git 2.11.0 installed on the gitlab system, failing
with:

remote: GitLab: You are not allowed to force push code to a protected branch on 
this project.
To (sitename):(user)/(repo).git
 ! [remote rejected] master -> master (pre-receive hook declined)

even for ordinary, non-forced pushes.

This is upstream bug https://gitlab.com/gitlab-org/gitlab-ce/issues/25301

Since gitlab seems pretty useless without the ability to push to a repository
by default, I've marked this grave.


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

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

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  apache2 [httpd]   2.4.25-1
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b2
ii  bundler   1.13.6-2
ii  debconf [debconf-2.0] 1.5.59
ii  git   1:2.11.0-2
ii  gitlab-shell  3.6.6-1
ii  gitlab-workhorse  0.8.5+debian-3
ii  init-system-helpers   1.46
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nodejs4.7.2~dfsg-1
ii  openssh-client1:7.4p1-5
ii  postfix [mail-transport-agent]3.1.3-6
ii  postgresql-client 9.6+178
ii  postgresql-client-9.6 [postgresql-client  9.6.1-2
ii  postgresql-contrib9.6+178
ii  rake  10.5.0-2
pn  redis-server  
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-3
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1
ii  ruby-doorkeeper   4.2.0-3
ii  ruby-dropzonejs-rails 0.7.1-1
ii  ruby-email-reply-parser   0.5.8-1
ii  ruby-fog-aws  0.12.0-1
ii  ruby-fog-azure0.0.2-1
ii  ruby-fog-core 1.42.0-1
ii  ruby-fog-google   0.3.2-1
ii  ruby-fog-local0.3.0-1
ii  ruby-fog-openstack0.1.6-4
ii  ruby-fog-rackspace0.1.1-4
ii  ruby-fogbugz  0.2.1-3
ii  ruby-font-awesome-rails   4.6.3.0-2
ii  ruby-gemnasium-gitlab-service 0.2.6-1
ii  ruby-gemojione3.1.0-2
ii  ruby-github-linguist  4.7.2-2
ii  ruby-github-markup1.5.0+dfsg-4
ii  ruby-gitlab-flowdock-git-hook 1.0.1-2
ii  ruby-gitlab-git  

Bug#851713: .git/info/attributes change not always picked up by git reset [and 1 more messages]

[Ian Jackson]

FTR, adding a `touch' here

   ...
   cat file
   git status

   echo >.git/info/attributes '* -filter'
 + touch file
   git reset --hard
   ...

works around the bug.

Ian.

Bug#851518: cinnamon won't start

[Carsten Kosthorst]

Hi,

I updated today and cinnamon is working again.

Thanks,

Carsten

Bug#851697: Cannot push when archive access method is `aptget'

[Ian Jackson]

peter green writes ("Bug#851697: Cannot push when archive access method is 
`aptget'"):
> So I copied the stub function from "dummycat" to "aptget".

Hrm.  Yes.  That would do.  It's not briliiant because it will mean
you have to pass --ch:--sa or --ch:--sd.

> I'll post up a debdiff with this and any other changes I end up making to 
> dgit later.

Thanks.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Phil Hagelberg]

> I understand this probably goes against some policies, but I would urge
> you to consider removing the search task if including it would add a
> significant burden to the job of packaging. If it would help, I will
> include a deprecation notice in version 2.7.2 of Leiningen recommending
> against the use of the search task.

Upon further reflection, I think it should probably be removed from
upstream as well. Sorry for the confusion.

Further discussion on the upstream issue tracker:

  https://github.com/technomancy/leiningen/pull/2234

Hope this makes the packaging job easier.


signature.asc
Description: PGP signature

Bug#851713: .git/info/attributes change not always picked up by git reset

[Ian Jackson]

Package: git
Version: 1:2.11.0-2
Severity: minor

Changes .git/info/attributes can mean that previously checkout out
versions of files are no longer accurate, because they have had the
wrong filters or whatever applied.

git does not always get this right.  For example, changing the
attributes configuration and then running `git reset --hard' usually
updates the working tree with the new view of the tree objects, but
sometimes doesn't.

To reproduce:

   mkdir -p bug/scripts
   cd bug/scripts
   # put `many' and `try' from this email in bug/scripts/{many,try}
   # chmod +x many try
   ./many

Expected results: `many' runs to completion.

Actual results: a lot of output ending with something like this:

   On branch master
   nothing to commit, working tree clean
   + echo '* -filter'
   + git reset --hard
   HEAD is now at 6ce0887 file
   + cat file
   a
   b
   + diff file ../blob
   1,2c1,2
   < a
   < b
   ---
   > n
   > o

On my modern and rather fast laptop the number of trials before
failure varies from 2 or so to well over 100.  The distributions of
results suggests that the trials are not independent, somehow.

Thanks,
Ian.

#!/bin/bash
set -e
set -x

rm -rf ../expt
mkdir ../expt
cd ../expt
git init

mkdir -p .git/info

git config filter.crazy.smudge '/usr/games/rot13 2'
git config filter.crazy.clean  '/usr/games/rot13 24'
git config filter.crazy.required true

echo >.gitattributes 'file filter=crazy'
git add .gitattributes
git commit -m attrs .gitattributes

(echo a; echo b) >file
git add file
git commit -m file

cat file
git cat-file blob master:file
git cat-file blob master:file >../blob

cat file
git status

echo >.git/info/attributes '* -filter'
git reset --hard

cat file
diff file ../blob
#!/bin/bash
set -e
for s in {0..1000}; do echo == $s ==; ./try; done


-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#851712: kea-admin: Missing 'kea-admin' executable

[Leandro Ariel Kollenberger]

Package: kea-admin
Version: 1.1.0-1
Severity: important

Dear Maintainer,

The kea-admin package should include the 'kea-admin' application,
usually found in /usr/sbin/kea-admin. It is, however, not being
currently included in the generated package. This application is
responsible for initializing the databases that the Kea DHCP server
uses.

I've tryed adding 'usr/sbin/kea-admin' to the 'debian/kea-admin.install' file
and it solves the problem for me.

Thank you!

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_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 kea-admin depends on:
ii  kea-common 1.1.0-1
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-8
ii  libgcc11:6.2.1-5
ii  libstdc++6 6.2.1-5

kea-admin recommends no packages.

kea-admin suggests no packages.

-- no debconf information

Bug#851711: shotwell: new upstream bugfix release

[Emilio Pozuelo Monfort]

Source: shotwell
Version: 0.25.1-1
Severity: wishlist

Hi,

There's a new upstream bugfix release of shotwell (actually two), 0.25.3.

It'd be good to get those bug fixes into stretch.

Cheers,
Emilio

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

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

Bug#851640: --debbuildopts not propagated anymore to cowbuilder

[Vincent Bernat]

 ❦ 17 janvier 2017 11:21 +0100, Mattia Rizzolo  :

> Actually, breaking it completely wasn't my intention, I'll reinstate
> support for it, sorry for the disruption.

The pbuilder from git works fine for me. Thanks!
-- 
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#851692: I'm afraid it's done on purpose

[Maurizio Avogadro]

This is a choice the maintainers did on purpose (see the changelog for
further information).


And there's _no_way_ to circumvent this: you can't put your
--enable-remote-extensions flag in /etc/chromium.d/: it doesn't work,
you'll have to start your browser from the command line for the
foreseeable future.


Having someone making choices in my behalf always irritated me. And I
really don't think Debian users are so unwary.

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Oh, I just remembered I once had a short conversation with RMS about
the distribution of the ghostscript fonts in binary Type1 format albeit
being licensed under the terms of the GPL:


Date: Sun, 13 Feb 2011 14:02:32 -0500
From: Richard Stallman 
To: Fabian Greffrath 
Subject: Re: [ghostscript] opentypefont

These fonts, however, are supplied in a binary, though editable, format
called PFB. In our opinion this file format corresponds to object code
and is clearly not "the preferred form of the work for making
modifications to it."

Karl Berry is the GNU expert on fonts.  He thinks that a Type 1 font
is suitable source code.

Could you tell me how you consider it falls short?

 We sure could do the transformations
from the binary font files, but it just felt "wrong". ;)

Would the files made by this transformation be different from the
source files that the developers might release?


Date: Mon, 14 Feb 2011 14:18:57 -0500
From: Richard Stallman 
To: Fabian Greffrath 
Subject: Re: [ghostscript] opentypefont

They are binary files, so you cannot create diffs between two 
versions. That is, the advantage of the openness of the source is void.

I see your point.  That is an aid for maintenance.

At the same time, the Type 1 font contains all the information
and can be converted automatically to the textual format.
So it is a valid source format.

Thus, I think these packages are valid and free as they are.
However, distributing the ASCII source would be an improvement.
So why not add that to your packages?
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlh+iIkACgkQy+qOlwzN
Wd+/ORAAr5M6KHbkBoUDNUkKu9KlKvC0hDJnaieJdxCUtuHH3sHGTmhAcpXbYjZo
VqqkeTkOrwiPvVs/vQcoQTyplE/TjKhLFC0w74PCUuY/dzPYm7kWmTNeyjdR/UCG
R2fsZNdLKu31/m/FEVAm7Cj3pp8o2DIRVNo75QabDJu6K4oIbVB2Okt4XE2BJJT5
nKHWYC+RthTiAUo9nlRJ+l3xm0zNdZngf99HrV654G0etheMoj9m2XPTeCU6pe1Z
VaegO7lb0/uBtnUm2fwhi6WEsIcx4wQqkXSaH1tlYgBqU4WkEKaRi15sXTmGvQV7
vj5c9Knvaz7AEDbB1cYh0a3M32qJ0v4UEUPUYeUxfRAqMy8l0shzZ7prxWDJBQas
CeqJxihL+aWXvRMhI7cUZ+0C953X2nSNuxnJ27na54NHkDzQ9dW62SDYB3fM6VxQ
8+UWjzbtuQBm+LyNe6VG27eu1ewZKovIGsewCl5GGms6ssbrdYbMHyj6wMF/jPqj
lBp15vDdaM72zXLbO2veNGqZ8tDtEWwwIo8kkm36ydx5lz1xYiwdWAgo8J8bF+O9
MK7oq71eEoZBB9HXC/XX2oXVOBcfvL3jVOoBu4lZf3efV6do5T/q0yn5+VTfrVSI
9grvjEl6dCa73GsWu4gkAdWr/NG3KD82Aoh3btOFt/FKS/u0uZ4=
=9XWx
-END PGP SIGNATURE-

Bug#850970: pvpgn: switch to build depend on the metapackage default-libmysqlclient-dev

[Dmitry Smirnov]

On Tuesday, 17 January 2017 12:54:44 AM AEDT Andreas Beckmann wrote:
> I just uploaded a NMU to DELAYED/2, fixing these issues. Please let me
> know if I should delay it longer.
> 
>  pvpgn (1.8.5-2.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Switch Build-Depends to default-libmysqlclient-dev.  (Closes: #850970)
> * Switch Suggests to default-mysql-* | virtual-mysql-*.  (Closes: #848482)
> * Use secure, canonical Vcs-* URLs.
> 
> Will push commits and tag to the git repo after the upload was accepted
> in the archive.

Thank you very much for your help, Andreas.

-- 
Cheers,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#851709: Acknowledgement (icedove: Icedove frequent crashes (often when switching folders))

[Robin Williams]

Another segfault trace just now.

Thread 1 "icedove-bin" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) thread apply all bt

Thread 112 (Thread 0x7fffb0dfe700 (LWP 9239)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x75ea2653 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x75ea3022 in PR_Wait () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#3  0x721407f1 in mozilla::ReentrantMonitor::Wait (this=0x7fffc62819e0, 
aInterval=aInterval@entry=6) at 
../../../dist/include/mozilla/ReentrantMonitor.h:91
#4  0x7214cc87 in mozilla::ReentrantMonitorAutoEnter::Wait 
(aInterval=6, this=0x7fffb0dfdcb0) at 
../../../dist/include/mozilla/ReentrantMonitor.h:190
#5  nsImapProtocol::ImapThreadMainLoop (this=this@entry=0x7fffc6281800) at 
./mailnews/imap/src/nsImapProtocol.cpp:1351
#6  0x7214ce79 in nsImapProtocol::Run (this=0x7fffc6281800) at 
./mailnews/imap/src/nsImapProtocol.cpp:1068
#7  0x7225ea53 in nsThread::ProcessNextEvent (this=0x7fff71774640, 
aMayWait=, aResult=0x7fffb0dfddd7) at 
./mozilla/xpcom/threads/nsThread.cpp:972
#8  0x72278ae9 in NS_ProcessNextEvent (aThread=, 
aMayWait=aMayWait@entry=true) at ./mozilla/xpcom/glue/nsThreadUtils.cpp:297
#9  0x7245be9b in mozilla::ipc::MessagePumpForNonMainThreads::Run 
(this=0x7fffc46c58c0, aDelegate=0x7fffbbbdf1a0) at 
./mozilla/ipc/glue/MessagePump.cpp:355
#10 0x7244bf62 in MessageLoop::RunHandler (this=0x7fffbbbdf1a0) at 
./mozilla/ipc/chromium/src/base/message_loop.cc:227
#11 MessageLoop::Run (this=this@entry=0x7fffbbbdf1a0) at 
./mozilla/ipc/chromium/src/base/message_loop.cc:201
#12 0x72260742 in nsThread::ThreadFunc (aArg=0x7fff71774640) at 
./mozilla/xpcom/threads/nsThread.cpp:376
#13 0x75ea8549 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#14 0x77bc4464 in start_thread (arg=0x7fffb0dfe700) at 
pthread_create.c:333
#15 0x76e679df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 110 (Thread 0x7fffa8bff700 (LWP 9237)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x75ea2653 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x75ea3022 in PR_Wait () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#3  0x721407f1 in mozilla::ReentrantMonitor::Wait (this=0x7fffc62709e0, 
aInterval=aInterval@entry=6) at 
../../../dist/include/mozilla/ReentrantMonitor.h:91
#4  0x7214cc87 in mozilla::ReentrantMonitorAutoEnter::Wait 
(aInterval=6, this=0x7fffa8bfecb0) at 
../../../dist/include/mozilla/ReentrantMonitor.h:190
#5  nsImapProtocol::ImapThreadMainLoop (this=this@entry=0x7fffc6270800) at 
./mailnews/imap/src/nsImapProtocol.cpp:1351
#6  0x7214ce79 in nsImapProtocol::Run (this=0x7fffc6270800) at 
./mailnews/imap/src/nsImapProtocol.cpp:1068
#7  0x7225ea53 in nsThread::ProcessNextEvent (this=0x7fff71774d90, 
aMayWait=, aResult=0x7fffa8bfedd7) at 
./mozilla/xpcom/threads/nsThread.cpp:972
#8  0x72278ae9 in NS_ProcessNextEvent (aThread=, 
aMayWait=aMayWait@entry=false) at ./mozilla/xpcom/glue/nsThreadUtils.cpp:297
#9  0x7245be4c in mozilla::ipc::MessagePumpForNonMainThreads::Run 
(this=0x7fffc43fde40, aDelegate=0x7fffbbbdee40) at 
./mozilla/ipc/glue/MessagePump.cpp:326
#10 0x7244bf62 in MessageLoop::RunHandler (this=0x7fffbbbdee40) at 
./mozilla/ipc/chromium/src/base/message_loop.cc:227
#11 MessageLoop::Run (this=this@entry=0x7fffbbbdee40) at 
./mozilla/ipc/chromium/src/base/message_loop.cc:201
#12 0x72260742 in nsThread::ThreadFunc (aArg=0x7fff71774d90) at 
./mozilla/xpcom/threads/nsThread.cpp:376
#13 0x75ea8549 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#14 0x77bc4464 in start_thread (arg=0x7fffa8bff700) at 
pthread_create.c:333
#15 0x76e679df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 101 (Thread 0x7fffa31fe700 (LWP 7542)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x75ea2653 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x75ea3022 in PR_Wait () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#3  0x721407f1 in mozilla::ReentrantMonitor::Wait (this=0x7fffa79b61e0, 
aInterval=aInterval@entry=6) at 
../../../dist/include/mozilla/ReentrantMonitor.h:91
#4  0x7214cc87 in mozilla::ReentrantMonitorAutoEnter::Wait 
(aInterval=6, this=0x7fffa31fdcb0) at 
../../../dist/include/mozilla/ReentrantMonitor.h:190
#5  nsImapProtocol::ImapThreadMainLoop (this=this@entry=0x7fffa79b6000) at 
./mailnews/imap/src/nsImapProtocol.cpp:1351
#6  0x7214ce79 in nsImapProtocol::Run (this=0x7fffa79b6000) at 
./mailnews/imap/src/nsImapProtocol.cpp:1068
#7  0x7225ea53 in nsThread::ProcessNextEvent (this=0x7fff9b9b5eb0, 

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Mittwoch, den 18.01.2017, 03:24 +1100 schrieb Ben Finney:
> Debian recipients should have equal access to make modifications to
> the work, build the work from modified source, and install the
> result.

All these modifications could be made to the OTF files *just as well*,
there is no advantage in using the same font format as upstream does
for their development. But I figure we are running in circles now. ;)

> The fact of the matter is the Glyphs data files are the preferred
> form
> of the work to make modifications.

Please note that the "preferred form for modification" is a term
exclusive to the GPL, it does not necessarily apply to fonts licensed
under any other license. Also, I am not sure if this is really exactly
what is meant by the "missing sources" paragraph of the REJECTS FAQs.

> It would reveal that Debian recipients do not have equal access to
> the source, for modifying building, and installing the work.

And thus you would file a bug requesting the removal of this package
from Debian main? Are you even aware of the vast consequences that this
overly strict interpretation of the "missing sources" paragraph may
have?

 - Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlh+g2oACgkQy+qOlwzN
Wd/hVA//X+zpFiwIdA2AUgAuQarC/zLV9RI1SHv4z+ASIvWyALzsLstxinD5fCOY
M6X6ySeU9ek7O/ZygHg1STgOzcBF42FvEIZscdFF6jMu5eH1zuW+t+8AoEJwMQLK
Uf50XrN0/ZR5DHHXKqMwfPZ39OOIJ5A9iYlHZEe8bkSYjbwF/HlIcUL53xddwOq9
bvETmHCeKJYst/QQsmR6sBNtYY2OV0onSoLxVxsbwLmlcKBA5Sg8DpjZBk407MFo
NGllJACTuEWXZDDypAdohEsln3/yw61F/B3LbakvobEnh4pT9iNiOlOCT5MuIOiu
yAs0tRFo5sH2rgt3HIlzfHqnCkm4U3+Y4+fHCXJTt5X9HnzC/GuExqP83o21fH3/
qRFSnx4hDfh/D89HiL/SRhj3mx5xGbjqvYuIuoRpH67loTw73nyv2qblv37eFXUg
uWTzoc3ln+/AQLaeFmzz8vZM2NPWff9PAKD+0QL9tbbRbAJsNpLZJbxXVC1sLP5Q
pyjESFt7DinDXPUWUgr1NXiaPJd9+sxcOnOje94B6cZpz3RWKsteTWWjJVmWfrbf
T5sVcwPo6ALHKX6MVXplO/prLKzvwivpO+U0wq9qKQe0M3PtJ+a6eZxKjOX/9re3
Qg0zsjagw2V/tYsszATyETAvU9gK21dVAJ8PDPiMduFsXdOV4WE=
=s0k/
-END PGP SIGNATURE-

Bug#851233: [debian-mysql] Bug#851233: Security fixes from the January 2017 CPU

[Lars Tangvald]

I've built and tested the updates, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:

> Source: mysql-5.5
> Version: 5.5.53-0+deb8u1
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> The Oracle Critical Patch Update for January 2017 will be released on 
> 
> Tuesday, January 17. According to the pre-release announcement [1], it
>  
> will contain information about CVEs fixed in MySQL 5.5.54.
> 
> The CVE numbers will be available when the CPU is released.
> 
> Regards,
> 
> Norvald H. Ryeng
> 
> [1]
> http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851234: [debian-mysql] Bug#851234: Security fixes from the January 2017 CPU

[Lars Tangvald]

I've built and tested the update, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:

> Source: mysql-5.6
> Version: 5.6.34-1
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> The Oracle Critical Patch Update for January 2017 will be released on 
> 
> Tuesday, January 17. According to the pre-release announcement [1], it
>  
> will contain information about CVEs fixed in MySQL 5.6.35.
> 
> The CVE numbers will be available when the CPU is released.
> 
> Regards,
> 
> Norvald H. Ryeng
> 
> [1]
> http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851235: [debian-mysql] Bug#851235: Security fixes from the January 2017 CPU

[Lars Tangvald]

I've built and tested the updates, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:

> Source: mysql-5.7
> Version: 5.7.16-2
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> The Oracle Critical Patch Update for January 2017 will be released on 
> 
> Tuesday, January 17. According to the pre-release announcement [1], it
>  
> will contain information about CVEs fixed in MySQL 5.7.17.
> 
> The CVE numbers will be available when the CPU is released.
> 
> Regards,
> 
> Norvald H. Ryeng
> 
> [1]
> http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851697: Cannot push when archive access method is `aptget'

[peter green]

On 17/01/17 19:00, Ian Jackson wrote:

Package: dgit
Version: 3.4

If one tries to set up dgit push support for a distro which does not
have an ftpmaster api interface, and instead uses the aptget archive
access method, this happens:

Undefined subroutine ::file_in_archive_aptget called at /usr/bin/dgit line 
1023.

This functionality is missing and needs to be implemented.

Having taken a quick look myself it seems that some of the access methods have a stub 
implementation of that function that just returns "undef". Furthermore it seems 
that the code that calls that function has a path for handling such a return value.

So I copied the stub function from "dummycat" to "aptget".

I'll post up a debdiff with this and any other changes I end up making to dgit 
later.

Bug#851710: zoneminder: CVE-2016-10140

[Salvatore Bonaccorso]

Source: zoneminder
Version: 1.30.0+dfsg-2
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for zoneminder.

CVE-2016-10140[0]:
| Information disclosure and authentication bypass vulnerability exists
| in the Apache HTTP Server configuration bundled with ZoneMinder
| v1.30.0, which allows a remote unauthenticated attacker to browse all
| directories in the web root, e.g., a remote unauthenticated attacker
| can view all CCTV images on the server.

The package then installs respectively
/etc/apache2/conf-available/zoneminder.conf with the problematic
settings.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10140
[1] https://github.com/ZoneMinder/ZoneMinder/pull/1697
[2] 
https://github.com/ZoneMinder/ZoneMinder/commit/6361f143878ce00659f64ce42593951d773e4e63
[3] 
https://github.com/ZoneMinder/ZoneMinder/commit/aa0a4d1f5ad2c493f2bed175991e92c466ac3dc4

Regards,
Salvatore

Bug#851688: systemd: Redirect try-restart in SysV init scripts

[Martin Pitt]

Hello Ondrej,

Ondrej Novy [2017-01-17 20:40 +0100]:
> right. Fixed:
> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=73717f11b9694e47c3dd71ba5f1b7975e0fa6392

I took the liberty to force-push to drop the debian/changelog part (we use gbp
dch) and refer to this bug:

  
https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=b32d5abb7

Thanks!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#561748: proftpd-dfsg: embeds libtool

[Hilmar Preuße]

forwarded 561748 https://github.com/proftpd/proftpd/issues/394
stop

Am 19.12.2009 um 23:34 tastete Michael Gilbert:

Hi,


Your package embeds source code from expat, which makes
security updates very cumbersome, difficult, and potentially
error-prone.  Please update your package to make use of the
shared library.  Thank you for your attention on this matter.

Upstream stated using the systems libtool is currently not supported. 
Marking as forwarded for now.


Hilmar
--
#206401 http://counter.li.org

Bug#850723: heimdal: FTBFS on x32 because libtommath thinks it’s amd64

[Dominique Dumont]

On Mon, 09 Jan 2017 18:03:03 +0100 Thorsten Glaser  wrote:
>. I’ve prepared a
> patch and uploaded the package to the debian-ports “unreleased”
> repository in order to be able to dissolve the heimdal⇐⇒openldap
> circular BD-Uninstallability, but would extremely appreciate if
> you could merge the patch and do a regular maintainer upload soon.

Done in lilbtommath 1.0-4 and pushed to upstream [1] .

Thanks for the patch

All the best

[1] https://github.com/libtom/libtommath/pull/69

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#847935: test report

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Dienstag, den 17.01.2017, 13:33 -0600 schrieb Jason Crain:
> I could be wrong about how poppler's build system works, but I think
> the
> way the cairo backend is linked, you might need an updated
> libpoppler-glib instead of libpoppler.

That's sure possible, that would be this file:

https://people.debian.org/~fabian/jessie/libpoppler-glib8_0.26.5-2+deb8u1.1_amd64.deb

Thanks,

Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlh+ekkACgkQy+qOlwzN
Wd9q9hAAjtRtrdT1Uro1VTCp/wUc50YV6w3cfrU1MVQfmUIw9SbiES4bWMjz4mio
mebGAqzyTFd8hDSIrdum4UjoiPKNeNoDFjCgyGHbrEXSS9z+RgShOf161lzLRIF/
6+ELg8OvfMU2IifS4UU9dJBetEjfL2mjpnaqRtoZxNw1Aw1L8G07PQQQBiD/4UJb
yB6gNmd0CC2QsM2AAQVkt2F0iE1sk187V/9iyVj5JwljzCTxmiPE5q73GekKsQvl
fgVDKfB2eZATmrp7tpqiNBfU8xl8w62fWZvTMfFRvRAaAC1eA7keIM63ehwR25P6
pDW9zywOlMfYL6/c98r54UTVxJe9dB95KBDlDigCoeV4eg71pV8AvyZEGl/dHFPU
jcdP5VOXcaL8vao7MVJ2ivoVxjyjax4eZhInqBx4JzEq0NfKHqlVEbEe56RHy+wr
nUxtGhdlJBjY+iL233ruoo9S2QvnBYI3UMxpOkg7BJfwidEQpiyCV99wCAyo0OCz
rHTU4+PL6633ULsDW2hEMD9QLbTiXfP92X7XwhysW5FK0cEUnvcnSg75hSS1GYhl
MCznhG6ejKQQd6IkMNKBIqxCwFkJz2N53kZEGIop+132z4d6x7emkCoNXUszZNKQ
In27mpkaIyLFjpd+SYxLwwZxQJ49wTOlnxUXBxVseKX2CAxpCo8=
=PaJL
-END PGP SIGNATURE-

Bug#851688: systemd: Redirect try-restart in SysV init scripts

[Ondrej Novy]

Hi,

2017-01-17 19:26 GMT+01:00 Michael Biebl :

>  Debian policy would have to
> be updated as well, to define how exactly try-restart should behave in
> SysV init scripts.
>

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

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Phil Hagelberg]

Elana Hashman  writes:

> Finally following up with some conversations I had at Clojure/conj, I'd 
> like to help get the ball rolling on this again. Based on leiningen 
> 2.7.1's dependencies, here's what we'll need to package/upgrade to make 
> this happen.

Very exciting; thanks!

> Packages that have a higher version in Debian unstable than in leiningen 
> 2.7.1:
>
> libdynapath-clojure aka org.tcrawley/dynapath (2.5.1 > 2.4.1)
> libmaven-indexer-java aka org.apache.maven.indexer/indexer-core (5.1.1 > 
> 4.1.3)
> libcommons-io-java aka commons-io (2.5 > 2.4)

For the record, the versions of both dynapath and commons-io in the
current git version of Leiningen (2.7.2-SNAPSHOT) match those in Debian
unstable.

The indexer is another story. It is use to support the `search' task,
but I really regret leaving that in Leiningen 2.x and am strongly
considering adding a warning not to use it. Since it was originally
introduced the indices it has to download have gotten so large as to be
quite impractical, and users are nearly always better off performing a
search in a web browser against an online index vs downloading their own
copy of the indices.

I understand this probably goes against some policies, but I would urge
you to consider removing the search task if including it would add a
significant burden to the job of packaging. If it would help, I will
include a deprecation notice in version 2.7.2 of Leiningen recommending
against the use of the search task.

Though obviously in most cases diverging from upstream in a situation
like this is a bad idea, the search task is *never* used in an automated
context; if it breaks it will not affect the builds of other projects
which use Leiningen. In addition, in the past three years the only time
anyone has mentioned the search task to me on IRC or elsewhere has been
to ask why it isn't working well and whether it's really going to take
as many hours as it claims to download the rest of the indices. My
suspicion is that the number of users who have the patience to wait for
the indices to actually download (vs switching to a browser and having
the search results displayed immediately) is in the low double digits.

If this is not acceptable then I will bump the version of Maven Indexer
used in Leiningen 2.7.2 to match the version in Debian.

-Phil


signature.asc
Description: PGP signature