Bug#820061: linux-image-amd64: kernel hangs since debian 8.4

[Benoît Tonnerre]

Package: linux-image-amd64
Version: 3.16.7-ckt25-1
Severity: normal

Hi,

Since yesterday (update to debian 8.4) some PC at work, hangs randomly.

All the machines freeze when reading e-mails, searching things online, reading
PDF, lauching PHP Storm, etc ...

All the machines are from Dell (tested on Dell 990 and Dell 9010).

They are all equiped with a SSD disk.

Updating to linux-image-4.4.0-0.bpo.1-amd64 seems to resolve the issue.

I found this in /var/log/syslog :


Apr  4 18:52:55 pci003-01 kernel: [   79.316412] BUG: unable to handle kernel
NULL pointer dereference at 0008
Apr  4 18:52:55 pci003-01 kernel: [   79.317910] IP: []
radeon_fence_ref+0xd/0x50 [radeon]
Apr  4 18:52:55 pci003-01 kernel: [   79.318687] PGD 0
Apr  4 18:52:55 pci003-01 kernel: [   79.319445] Oops: 0002 [#1] SMP
Apr  4 18:52:55 pci003-01 kernel: [   79.320209] Modules linked in: md4 hmac
nls_utf8 cifs dns_resolver pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O)
vboxdrv(O) cpufreq_stats cpufreq_userspace cpufreq_conservative
cpufreq_powersave nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache
sunrpc snd_pcm_oss snd_mixer_oss fuse joydev x86_pkg_temp_thermal
intel_powerclamp intel_rapl coretemp kvm_intel kvm iTCO_wdt iTCO_vendor_support
crc32_pclmul evdev snd_hda_codec_realtek snd_hda_codec_generic aesni_intel
aes_x86_64 radeon lrw gf128mul glue_helper dcdbas ablk_helper cryptd ttm
drm_kms_helper pcspkr serio_raw drm i2c_i801 i2c_algo_bit i2c_core lpc_ich
snd_hda_intel mfd_core snd_hda_controller snd_hda_codec snd_hwdep snd_pcm
snd_timer tpm_tis snd tpm soundcore mei_me mei button shpchp video processor
thermal_sys parport_pc ppdev lp parport autofs4 hid_generic usbhid hid ext4
crc16 mbcache jbd2 raid1 md_mod sg sr_mod sd_mod cdrom crc_t10dif
crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel psmouse ahci
libahci ehci_pci ehci_hcd libata scsi_mod e1000e usbcore ptp usb_common
pps_core
Apr  4 18:52:55 pci003-01 kernel: [   79.326413] CPU: 3 PID: 1604 Comm: Xorg
Tainted: G   O  3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-1
Apr  4 18:52:55 pci003-01 kernel: [   79.327346] Hardware name: Dell Inc.
OptiPlex 990/06D7TR, BIOS A19 08/26/2015
Apr  4 18:52:55 pci003-01 kernel: [   79.328278] task: 8802216c0a20 ti:
88003639c000 task.ti: 88003639c000
Apr  4 18:52:55 pci003-01 kernel: [   79.329223] RIP: 0010:[]
[] radeon_fence_ref+0xd/0x50 [radeon]
Apr  4 18:52:55 pci003-01 kernel: [   79.330192] RSP: 0018:88003639fb18
EFLAGS: 00010292
Apr  4 18:52:55 pci003-01 kernel: [   79.331154] RAX:  RBX:
8802218f55f8 RCX: 8802218f4d08
Apr  4 18:52:55 pci003-01 kernel: [   79.332125] RDX: 0001 RSI:
 RDI: 
Apr  4 18:52:55 pci003-01 kernel: [   79.333110] RBP: 8802218f5550 R08:
8802218f4000 R09: 
Apr  4 18:52:55 pci003-01 kernel: [   79.334119] R10: 0002 R11:
88003639fe08 R12: 0020
Apr  4 18:52:55 pci003-01 kernel: [   79.335117] R13: 88003639fbe0 R14:
88003639fbb0 R15: 8802218f55f8
Apr  4 18:52:55 pci003-01 kernel: [   79.336120] FS:  7fd8f5323980()
GS:88022dc6() knlGS:
Apr  4 18:52:55 pci003-01 kernel: [   79.337143] CS:  0010 DS:  ES: 
CR0: 80050033
Apr  4 18:52:55 pci003-01 kernel: [   79.338142] CR2: 0008 CR3:
000223b3e000 CR4: 000407e0
Apr  4 18:52:55 pci003-01 kernel: [   79.339125] Stack:
Apr  4 18:52:55 pci003-01 kernel: [   79.340065]  a04900bc
0020 eea00100 88003639fcd0
Apr  4 18:52:55 pci003-01 kernel: [   79.341006]  8802218f4000
8802216c0a20 8802216c0a20 0001
Apr  4 18:52:55 pci003-01 kernel: [   79.341952]  
  
Apr  4 18:52:55 pci003-01 kernel: [   79.342899] Call Trace:
Apr  4 18:52:55 pci003-01 kernel: [   79.343854]  [] ?
radeon_sa_bo_new+0x25c/0x460 [radeon]
Apr  4 18:52:55 pci003-01 kernel: [   79.344808]  [] ?
radeon_ib_get+0x2e/0xd0 [radeon]
Apr  4 18:52:55 pci003-01 kernel: [   79.345758]  [] ?
radeon_cs_ioctl+0x13c/0x730 [radeon]
Apr  4 18:52:55 pci003-01 kernel: [   79.346702]  [] ?
drm_ioctl+0x1c7/0x5b0 [drm]
Apr  4 18:52:55 pci003-01 kernel: [   79.347637]  [] ?
__do_page_fault+0x1d1/0x4f0
Apr  4 18:52:55 pci003-01 kernel: [   79.348572]  [] ?
radeon_drm_ioctl+0x46/0x80 [radeon]
Apr  4 18:52:55 pci003-01 kernel: [   79.349500]  [] ?
do_vfs_ioctl+0x2cf/0x4b0
Apr  4 18:52:55 pci003-01 kernel: [   79.350437]  [] ?
__sys_recvmsg+0x65/0x80
Apr  4 18:52:55 pci003-01 kernel: [   79.351355]  [] ?
SyS_ioctl+0x81/0xa0
Apr  4 18:52:55 pci003-01 kernel: [   79.352265]  [] ?
system_call_fast_compare_end+0x10/0x15
Apr  4 18:52:55 pci003-01 kernel: [   79.353167] Code: e4 48 8b 3b 89 c1 89 ea
48 c7 c6 80 f6 51 a0 31 c0 e8 68 17 f7 e0 eb cb 66 0f 1f 44 00 00 66 66 66 66
90 48 89 f8 ba 01 00 00 00  0f c1 57 08 83 c2 01 83 fa 01 7e 01 c3 80 3d 0e
43 11 00 00
Apr  4 18:52:55 

Bug#820060: python-biom-format: broken on big-endian architectures

[Steve Langasek]

Package: python-biom-format
Version: 2.1.4+dfsg-1
Severity: serious

As seen at http://buildd.debian.org/python-biom-format, this package fails
to build on all big-endian architectures in the archive (mips, powerpc,
s390x).  While this build failure has only appeared with the upload of
2.1.5+dfsg-1, this is not a regression in that version of the upstream
source; instead, the package was already broken, but what has changed now is
that a new version of dh-python correctly finds the tests and runs them at
build time where before dh_auto_test was silently passing.

I'm not sure if this points to breakage in python-biom-format, or in
something lower down the stack that it depends on.  I've confirmed that
python-numpy autopkgtests run ok on powerpc (except for openblas - and the
tests can't be run on s390x because openblas is not built for that
architecture), and h5py autopkgtests run ok on s390x.  python-scipy's
autopkgtests fail with SIGABRT on both powerpc and s390x, maybe related,
maybe not (test_random_complex_exact (test_basic.TestLstsq) ... *** Error in
`python3.5': free(): invalid pointer: 0x1172c2a8 ***).

And hdf5 itself doesn't have any autopkgtests, and any build-time tests
pass; and h5py in any case should catch any bugs with its own testsuite
before python-biom-format.

So it seems most likely that this is a bug in python-biom-format itself
rather than any of its dependencies, thus assigning here.

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


signature.asc
Description: Digital signature

Bug#819703: Debian entitlement

[-]

Hi, I also think the author is stubborn.

However, there is a workaround and that does not even need a patch or
update. Just set "lock: True" in "$HOME/.xscreensaver":

# XScreenSaver Preferences File
# Workaround stubborn "This version of xscreensaver is VERY OLD! Please
upgrade!" bug

timeout:0:05:00
cycle:0:10:00
lock:True
lockTimeout:0:06:00
passwdTimeout:0:00:30
splash:False
splashDuration:0:00:00
fade:False
unfade:False

mode:   off


This disables the pop when you login. I don't know why but it works. I
found this out because some of my machines did not have this nagging.

All my systems have been updated with this workaround. Since the stubborn
author may read this and surely this loop hole will be patche dout int he
next version I have decded to abndon "xscreensaver" and switch to
"light-locker". I'll will be rolling out this fix to my systems.

Debian should remove "xscreensaver" and suggest people use "light-locker".

Bug#819950: [patch] Allow opera to access ~/.opera/ too

[Petter Reinholdtsen]

[Reiner Herrmann]
> You could try running firejail with --tracelog.
> When the process tries to access a blacklisted file, this will be logged
> to syslog.

I tried, but could not find any log entries for opera from firejail. :(

-- 
Happy hacking
Petter Reinholdtsen

Bug#820038: Copy signatures into udebs

[Jose R R]

Thus, in practice it means that an out of Linux source tree module,
like Reiser4, will be a reason for Debian-Installer (d-i) to baulk at
install?

On Mon, Apr 4, 2016 at 4:02 PM, Ben Hutchings  wrote:
> Package: kernel-wedge
> Version: 2.94
> Severity: normal
>
> We will probably implement module signing using detached signatures
> which kmod will concatenate to the modules at load time (see #820010).
> mkinitramfs will need to copy the detached signatures along with all
> the modules it includes in each udeb.
>
> It might also be necessary to add special support for signed kernel
> images, although linux-signed may end up generating the udebs for
> that directly.
>
> Ben.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages kernel-wedge depends on:
> ii  debhelper  9.20160313
> ii  make   4.1-9
>
> kernel-wedge recommends no packages.
>
> kernel-wedge suggests no packages.
>
> -- no debconf information
>



-- 
Jose R R
http://metztli.it
-
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
-
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
-

Bug#819969: libjpeg9: CVE-2016-3616: null pointer dereference in cjpeg

[Salvatore Bonaccorso]

Hi Bill,

On Mon, Apr 04, 2016 at 09:10:16PM +0200, Bill Allombert wrote:
> On Mon, Apr 04, 2016 at 02:35:03PM +0200, Salvatore Bonaccorso wrote:
> > Source: libjpeg9
> > Version: 1:9b-1
> > Severity: important
> > Tags: security upstream
> > 
> > Hi,
> > 
> > the following vulnerability was published for libjpeg9. The issue
> > is in the cjpeg utility.
> > 
> > CVE-2016-3616[0]:
> > null pointer dereference in cjpeg
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> Hello Salvatore,
> 
> Upstream has confirmed that only cjpeg is affected, and so
> only libjpeg-progs and not the binary package libjpeg9.

Yes this is true, thus I have reported to the Source package since
vulnerable code is present. Untested, but I guess the same patch
applies as was for libjpeg-turbo to resolve the problem in the cjpeg
utility.

Thanks for quick followup and regards,
Salvatore

Bug#819860: [dhclient] can not obtain one dhcp lease on TAP device connected to 802.1q vlan interface via one bridge

[LACROIX Jean Marc]

Le 05/04/2016 05:38, Michael Gilbert a écrit :

contlol: severity -1 normal

On Sun, Apr 3, 2016 at 3:43 AM, LACROIX Jean Marc wrote:

On recent Debian Kernel (3.16.7-ckt25-1) based on Jessie 8.4, i try to
setup one bridge (br-admin) with 2 externals devices.


The description that follows isn't totally clear, are you saying that
this worked correctly prior to the 8.4 kernel update?

Best wishes,
Mike



Sorry, but this is the first test, i have never made some tests before 
to this releas.


Thank you tell me what is not totally clear.
Best regards.

--
--
 -- Jean-Marc LACROIX --
  -- mailto : jeanmarc.lacr...@free.fr --
---

Bug#820057: Acknowledgement (mirror submission for mirror.akl.tmnetwork.co.nz)

[Alex Smith (Platform)]

Hi there,

One minor correction on the submission, the location on this one should be 
"Auckland, New Zealand" rather than Wellington.

Alex Smith
Systems Engineer – Trade Me
E: a...@trademe.co.nz | P: 022 059 9037

Bug#820059: jessie-pu: package xapian-core/1.2.19-1

[Olly Betts]

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

I'd like to update xapian-core in jessie to fix a bug which can cause
database corruption.  This is triggered by certain usage patterns, which
the recoll package performs:

https://bugs.debian.org/808610

It also affects some other users, but recoll is one I'm sure is affected
in jessie.

The attached patch is from the upstream git repo - it's been on git
master since 2015-04-28, and in upstream stable releases since
2015-05-20.

(wheezy is similarly affected - I can make a separate request for that
if you OK this one, but if you want to OK both now that's fine with me.
The patch for wheezy should be essentially identical).

Cheers,
Olly
Description: Increment cursor version of cancel or reopen
 Potentially increment the cursor version on cancel() or when the database is
 reopened, and flag the current cursor version as used when a cursor is
 rebuilt.
 .
 Fixes database corruption issues with certain usage patterns, which recoll
 can trigger.
Author: Olly Betts 
Origin: upstream, https://trac.xapian.org/changeset/826d1a19cc356e7bf66c1681626e70af32967447/git and https://trac.xapian.org/changeset/d784290ce015958474f965817f7a41f1483c3e03/git
Bug: https://trac.xapian.org/ticket/675
Bug-Debian: https://bugs.debian.org/808610
Forwarded: https://trac.xapian.org/ticket/675
Last-Update: 2016-04-05

--- a/backends/brass/brass_cursor.cc
+++ b/backends/brass/brass_cursor.cc
@@ -1,7 +1,7 @@
 /* brass_cursor.cc: Btree cursor implementation
  *
  * Copyright 1999,2000,2001 BrightStation PLC
- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
+ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 Olly Betts
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -99,6 +99,7 @@
 C[level].n = B->C[level].n;
 C[level].p = B->C[level].p;
 version = B->cursor_version;
+B->cursor_created_since_last_modification = true;
 }
 
 BrassCursor::~BrassCursor()
--- a/backends/brass/brass_table.cc
+++ b/backends/brass/brass_table.cc
@@ -1446,6 +1446,11 @@
 
 base_letter = ch;
 
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
+
 /* ready to open the main file */
 
 RETURN(true);
@@ -1985,6 +1990,11 @@
 changed_n = 0;
 changed_c = DIR_START;
 seq_count = SEQ_START_POINT;
+
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
 }
 
 / B-tree reading /
--- a/backends/chert/chert_cursor.cc
+++ b/backends/chert/chert_cursor.cc
@@ -1,7 +1,7 @@
 /* chert_cursor.cc: Btree cursor implementation
  *
  * Copyright 1999,2000,2001 BrightStation PLC
- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
+ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 Olly Betts
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -97,6 +97,7 @@
 C[level].n = B->C[level].n;
 C[level].p = B->C[level].p;
 version = B->cursor_version;
+B->cursor_created_since_last_modification = true;
 }
 
 ChertCursor::~ChertCursor()
--- a/backends/chert/chert_table.cc
+++ b/backends/chert/chert_table.cc
@@ -1449,6 +1449,11 @@
 
 base_letter = ch;
 
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
+
 /* ready to open the main file */
 
 RETURN(true);
@@ -2007,6 +2012,11 @@
 changed_n = 0;
 changed_c = DIR_START;
 seq_count = SEQ_START_POINT;
+
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
 }
 
 / B-tree reading /
--- a/backends/flint/flint_cursor.cc
+++ b/backends/flint/flint_cursor.cc
@@ -1,7 +1,7 @@
 /* flint_cursor.cc: Btree cursor implementation
  *
  * Copyright 1999,2000,2001 BrightStation PLC
- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
+ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 Olly Betts
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -97,6 +97,7 @@
 C[level].n = B->C[level].n;
 C[level].p = B->C[level].p;
 version = B->cursor_version;
+B->cursor_created_since_last_modification = true;
 }
 
 FlintCursor::~FlintCursor()
--- a/backends/flint/flint_table.cc
+++ b/backends/flint/flint_table.cc
@@ -1438,6 +1438,11 @@
 
 base_letter = ch;
 
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
+
 /* ready to open the main file */

Bug#815202: packages: machines and sponsors information is outdated

[Paul Wise]

On Tue, Apr 5, 2016 at 9:05 AM, Stéphane Blondon wrote:

> There are no commit since two years, so I'm not sure it's still alive.

Nevertheless, it is the way forward.

> I tried to extract the useful code from the script. It depends on the
> libnet-ldapapi-perl package and the configuration of the machine which
> is running the LDAP.

The Debian LDAP can be accessed from any machine, anonymous access
will only return the public data (including hostname stuff). So you
shouldn't need to run on db.d.o nor read the config file at all.

> - Perhaps providing the full data in JSON format by db.d.o would provide
> an easy access for several Debian services/tools.

Direct LDAP access should be machine-readable enough for almost all
services and others can easily add a proxy script.

> - Or providing a python script which could be reused by the django site
> in the future?

I agree that any future machines list in ud (one doesn't exist yet)
should have some filtering options.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#815167: [Pkg-freeipa-devel] Bug#815167: fix build failure with bind9 from experimental

[Timo Aaltonen]

05.04.2016, 07:56, Timo Aaltonen kirjoitti:
> 05.04.2016, 07:50, Michael Gilbert kirjoitti:
>> control: severity -1 serious
>>
>> Raising severity now that bind 9.10 is in unstable this now blocks its
>> transition.
> 
> Well I've been working on 4.3 which in turn needs native pkcs11 support
> in bind9, see
> 
> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1565392
> 
> If you have time to review the patch then that would be lovely..

heh, and then I realized this was a bug against bind-dyndb-ldap and not
freeipa, duh.. I'll upload bind-dyndb-ldap to sid.


-- 
t

Bug#815167: [Pkg-freeipa-devel] Bug#815167: fix build failure with bind9 from experimental

[Timo Aaltonen]

05.04.2016, 07:50, Michael Gilbert kirjoitti:
> control: severity -1 serious
> 
> Raising severity now that bind 9.10 is in unstable this now blocks its
> transition.

Well I've been working on 4.3 which in turn needs native pkcs11 support
in bind9, see

https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1565392

If you have time to review the patch then that would be lovely..

-- 
t

Bug#820058: mirror submission for mirror.wlg.tmnetwork.co.nz

[Systems Team]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.wlg.tmnetwork.co.nz
Type: leaf
Archive-architecture: amd64 i386 
Archive-http: /debian/
Archive-rsync: debian/
IPv6: no
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Systems Team 
Country: NZ New Zealand
Location: Wellington, New Zealand
Sponsor: Trade Me Limited http://www.trademe.co.nz/

Bug#820057: mirror submission for mirror.akl.tmnetwork.co.nz

[Systems Team]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.akl.tmnetwork.co.nz
Type: leaf
Archive-architecture: amd64 i386 
Archive-http: /debian/
Archive-rsync: debian/
IPv6: no
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Systems Team 
Country: NZ New Zealand
Location: Wellington, New Zealand
Sponsor: Trade Me Limited http://www.trademe.co.nz/

Bug#815167: fix build failure with bind9 from experimental

[Michael Gilbert]

control: severity -1 serious

Raising severity now that bind 9.10 is in unstable this now blocks its
transition.

Best wishes,
Mike

Bug#816325: [pkg-dhcp-devel] Bug#816325: org.freedesktop.PolicyKit1 was not provided by any .service files

[Michael Gilbert]

control: severity -1 important
control: tag -1 moreinfo, unreproducible

On Mon, Feb 29, 2016 at 4:11 PM, Joerg Frings-Fuerst wrote:
> $ systemctl start isc-dhcp-server
> Failed to start isc-dhcp-server.service: The name org.freedesktop.PolicyKit1 
> was not provided by any .service files

The org.freedesktop.PolicyKit1.service file is provided by the
policykit-1 package.  Do you have that installed?

Anyway, I tried removing that, but the server still started fine for
me with systemd.  Have you created your own isc-dhcp-server.service
file?  If so, what does it contain?

Best wishes,
Mike

Bug#820056: writeable file 'foo': already in use

[sacrificial-spam-address]

Package: bind9
Version: 1:9.10.3.dfsg.P4-6
Architecture: i386
Severity: important

Discussion of this issue can be found at
http://bind-users-forum.2342410.n4.nabble.com/Single-slave-zone-definition-for-two-view-cache-file-name-problem-td12.html
https://www.linuxquestions.org/questions/linux-server-73/bind-9-10-same-zone-in-two-views-4175572231-print/

Like many people running split DNS (multiple views), a large number
of my zones are common to the two.  So when setting this up, I did the
obvious thing:

zone "internal" {
match-clients { ... };
recursion yes;
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
include "/etc/bind/named.conf.common";

/* Zones private to this view */
};

zone "external" {
match-clients { any; };
recursion no;
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
include "/etc/bind/named.conf.common";

/* Zones private to this view */
};

Where named.conf.common contains various zones my name server
is authoritative for, and some zones it is secondary for like like:

zone "foo" {
type slave;
file "/etc/bind/cache/db.cache.foo";
masters { foo_name_servers; };
allow-transfer { any; };
};

While comments from the BIND maintainers suggest that it may have been
buggy, it was a sensible thing to do and worked for many years.  BIND 9.10
now detects this and fails to start, producing error messages like:

Apr  4 20:55:00 ns named[27115]: /etc/bind/named.conf.common:81: writeable file 
'/etc/bind/cache/db.cache.foo': already in use: /etc/bind/named.conf.common:81

Needless to say, named not starting leads to complete DNS failure and
is a pretty unhappy state to upgrade to.  (Thus the "Severity: important".)

At first, I thought this was a bug (how can a config file line conflict
with itself?), but then I realized that the conflict was between the
two views.

There does not appear to be any simple workaround.  The best solution
appears to be to use the new BIND 9.10 "in-view" feature, which allows a
zone in one view to be a reference to the same zone in a different view.
When this is done, both views may share the same cache file.

The down side is that this violates one of the important principles of
programming: only specify something in one place.  Instead, I have to have
a "master" definition and several "in-view" declarations referencing
the master.

I wish BIND would either deal with the problem after noticing it (by
automatically doing the equivalent of the in-view), or provide a way to
import every zone in a view, avoiding the need for a long list of in-view
declarations.


In case it helps anyone else, here's my current workaround:

One file declares a non-published view "common" as follows:

view "common" {
match-clients { none; };

zone "foo" {
...
};
...
};

Then I use the following sed script on that file (which relies on each
"zone" header being on a line by itself, preceded by a tab)

# Script to convert each zone in a view to a series of in-view declarations
1i\
// Automatically generated by Makefile and in-view.sed\
// MANUAL EDITS WILL BE LOST
/^  zone/{
a\
in-view "common";\
};
p
}

And I created a Makefile that applies the recipe
sed -n -f in-view.sed $< > $@
to produce a series of references that can then be included within
each view:

zone "foo" {
in-view "common";
};

Bug#818637: please fix

[積丹尼 Dan Jacobson]

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1558331

Bug#820055: wpa_cli interface_add/interface_remove interface_name fails with "UNKNOWN COMMAND"

[Pičugins Arsenijs]

Package: wpa
Version: 2.3

I want to use wpa_cli to add/remove a wireless interface to a running 
wpa_supplicant instance. I try to use "wpa_cli interface_add wlan1" and it 
prints out "UNKNOWN COMMAND". Same if I use wpa_cli command line. If I use 
"interface_add" without arguments, it asks me to use at least one argument. If 
I use "wpa_cli interface_list", it doesn't print out any interface (which is 
weird, since "wpa_cli interface" prints an interface which was supplied to 
wpa_supplicant by /etc/network/interfaces using wpa_conf directive).
I grepped through wpa 2.3 source and this message appears in wpa_supplicant 
ctrl_iface.c file, but I can't quite figure out what are the circumstances when 
it is returned as a reply.

I am using Debian GNU/Linux 8.0, kernel 4.1.19-v7+ and glibc6 2.4. It's 
Raspbian, if that's important. I can check it on a Debian PC if necessary.

Bug#819860: [dhclient] can not obtain one dhcp lease on TAP device connected to 802.1q vlan interface via one bridge

[Michael Gilbert]

contlol: severity -1 normal

On Sun, Apr 3, 2016 at 3:43 AM, LACROIX Jean Marc wrote:
> On recent Debian Kernel (3.16.7-ckt25-1) based on Jessie 8.4, i try to
> setup one bridge (br-admin) with 2 externals devices.

The description that follows isn't totally clear, are you saying that
this worked correctly prior to the 8.4 kernel update?

Best wishes,
Mike

Bug#819943: really should add an unforbid-version command

[積丹尼 Dan Jacobson]

So indeed in the man page

   To remove the forbidden version without installing the
   candidate version, the current version should be appended: "install
   =".


is utterly totally wrong. Please remove it.

set debian-reference-en
aptitude forbid-version $@
aptitude search $@ #shows F
aptitude install $@=2.59 # abort with n, we don't want to install it.
aptitude search $@ #still F

Note I use Aptitude::CmdLine::Always-Prompt "true";

Please change it to

   Currently there is no way to remove the forbidden version without 
installing the
   candidate version.

Or better

   Currently there is no way to remove the forbidden version NOTATION 
without installing the
   candidate version.

Yes I know about hold.

Bug#819703: Debian entitlement

[Peter Nowee]

On Mon, Apr 04, 2016 at 03:48:44PM +, ireulx wrote:
> When did the Free Software Community come to mean Debian users?
> When did 'needs' come to mean 'wants'?
> 
> Debian Social Contract (1997)
> -
> We will support people who create or use both free and non-free works on 
> Debian.
> We will be guided by the needs of our users and the free software community.
> 
> Debian Social Contract (2016)
> -
> We will support people who use Debian.
> We will be guided by the wants of our users.
> When a creator that has been part of the free software community for decades
> makes a polite request we will tell them that they "obviously haven't 
> understood
> how distributions work and what stable releases are" (i.e. that they need to
> conform to our way of doing things).
> We will then change their code against their wishes and call them "ignorant",
> "stubborn", "crazy" and a "dick."
> We will focus on the distribution _we_ want to use, not on the broader free
> software community.
> P.S. Our petty wants are more important than upstream's needs.
>   

I don't agree with the picture you are trying to paint here.

First, I see that many commenters here are trying to consider the 
upstream creator's interests. Several people here have come up with 
solutions that will help the author reduce the number of old bug 
reports he receives.

Second, judging by his comments here and in his code, the author was 
from the very beginning fully aware that the time-activated warnings 
were going to cause problems in the context of Debian stable. He either 
intended or did not care about that. So who is breaking the social 
contract here?

Anyway, I changed my mind a bit on what I think should be done with 
this package in Debian right now:

I still think the warnings can and should be patched out in stable / 
Jessie and I still think we should at the same time try to reduce the 
flow of bug reports to the upstream author, who has indeed been part of 
the free software movement for decades, for example by adding a Debian 
bug tracker URL near his URL/email address. I don't think we should be 
removing his email address.

However, with regard unstable/future versions of Debian, I think that 
the upstream author has shown that he is willing to go to great lengths 
to prevent the perpetual use of individual releases of his software. 
Given the problems caused by his actions so far, that it all seems to 
have been quite premeditated and that his recent comments show that he 
does not have any regrets, I fear he might take even more damaging 
action in the future if his demands are not met. In short, I do not 
trust him anymore. Removing his software from unstable ensures that he 
cannot do any more damage.

That said, I still think that making it difficult for users to 
perpetualy use an individual software release goes against both the 
letter ("permission to use") and spirit of free software. Making the 
coercion part of the software itself and referring to it as a 'feature' 
that is 'behaving as intended' does not change that. I hope the author 
can reflect on that.

Finally, could the maintainer (Tormod) please comment? Is an update in 
the works? Or would you welcome a non-maintainer upload (NMU)?

Best regards,
Peter Nowee


signature.asc
Description: Digital signature

Bug#819980: ITP: nuntius-linux -- Get notifications from your Android phone or tablet over Bluetooth.

[Barak A. Pearlmutter]

> Why "-linux" in the name if it doesn't seem to be Linux-specific?

Good question.

That's just the name of the source package, following upstream's repo name,
which is parallel to their nuntius-android source repo. The binary package
would be just nuntius.

Bug#819207: new name: "arch-test"

[Adam Borowski]

I do consider archdetect.udeb misnamed, as it doesn't deal with "arch"s in
Debian sense at all -- even its sources say "subarch" everywhere.  Elsewhere
the name used is "flavour".

However, it was first.

Thus, I think I'll go with "arch-test".  Enumerating architectures is
something only humans will do for sysinfo reasons, other software will
likely call arch-detect/arch-test to query a single given architecture,
so "test" should be good.

-- 
A tit a day keeps the vet away.

Bug#819703: you miss the point so much that you should stop shipping xscreensaver

[Eli the Bearded]

Like it or not, JWZ considers xscreensaver to be frontline system
security. If it doesn't LOCK YOUR SCREEN, it's broken. If you don't
want to track the security updates, you are (in his mind) harming users.
That is why he specifically suggests Gnome's screensaver: it's a as
hardened as a luggage lock. 

A version, today, over about five months old is going to have at least
one security hole: you can crash out of the password prompt (at least in
some cases) by hot swapping monitors at a critical time.

So:

A) Track the current version.

B) Backport all the bug fixes.

C) Fork to xluggagelock (or your name of choice for the insecure
version)

D) Stop pretending to include xscreensaver.

At least, that's how I think you'll satisfy JWZ.

Bug#820052: RFP: uefi-shim -- UEFI shim boot loader to support Secure Boot

[Steve Langasek]

Control: retitle -1 ITP: shim -- UEFI shim boot loader to support Secure Boot
Control: owner -1

On Tue, Apr 05, 2016 at 02:34:09AM +0100, Ben Hutchings wrote:
> Package: wnpp
> Severity: wishlist

> * Package name: uefi-shim
>   Version : 0.9
>   Upstream Author : Red Hat, Inc
> * URL : https://github.com/rhinstaller/shim
> * License : OpenSSL license (I think)
>   Programming Lang: C
>   Description : UEFI shim boot loader to support Secure Boot

I have previously committed to maintaining this package in Debian; this is
only blocked on the availability of a Debian master key to embed in it (no
point in building binaries until this is done).

Retitling the ITP package name to 'shim', which is how this is named in
Ubuntu.  Yes it's generic, but that is the upstream name and it's how it's
been named in Ubuntu.  If the ftp masters have objections to this name I
don't mind changing it, but barring such objections I believe the
consistency is preferred.

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


signature.asc
Description: Digital signature

Bug#819980: ITP: nuntius-linux -- Get notifications from your Android phone or tablet over Bluetooth.

[Adam Borowski]

On Mon, Apr 04, 2016 at 03:12:03PM +0100, Barak A. Pearlmutter wrote:
> * Package name: nuntius-linux
> * URL : https://github.com/holylobster
>   Description : Get notifications from your Android phone or tablet over 
> Bluetooth.
> 
> Delivers notifications from your Android phone or tablet to your computer 
> over Bluetooth.
> To use, you will need to install a companion tool on your phone or tablet and 
> pair it via Bluetooth.

Why "-linux" in the name if it doesn't seem to be Linux-specific?

-- 
A tit a day keeps the vet away.

Bug#820054: RM: indicator-applet -- RoQA; long-standing FTBFS, depends on removed gnome parts

[Adam Borowski]

Package: ftp.debian.org
Severity: normal


Hi!
I think it's time to remove indicator-applet.  It has a long-standing FTBFS,
wasn't a part of jessie, and gnome libraries it depends on have been since
removed.  Popcon 281 inst, 18 vote.

Bug#820046: guitarix: does not respect DEB_BUILD_OPTIONS=parallel max value

[Hermann Meyer]

If you use the DEB_BUILD_OPTIONS=parallel flag, you must past the 
$(NUMJOBS) somehow to the waf configure flags.

https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options

guitarix wscript accept the -j$(NUMJOBS) parameter.

regards
hermann

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Hi Mattia,

On 4 April 2016 at 22:04, Mattia Rizzolo  wrote:
> meh, there is git, let me use it!
> https://anonscm.debian.org/git/collab-maint/grip.git

Actually, it would be pretty nice if the RFS template grabbed the
"Vcs-Git" field. I'll remember to add it manually in the next time.

> Though as I said on the other one I'm wary of taking out the tarball
> without pristine-tar, so I'm going to use the tarball you uploaded to
> mentors with the git repo.

Ok. No problem.

> I pinged onovy and see if we can upload src:responses before this, so
> that the tests are enabled.

Ondrej Novy sent an e-mail earlier today, where I was cc'ed, to the
main package maintainer, Simon Chopin, asking if it is OK to upload
the updated package. He also took the opportunity to do lot of
improvements[1] in the packaging work as a whole.

> The package itself looks cool instead, so I'm just going to wait for
> onovy to reply and discover when he plans on uploading.

So... Nothing to fix? I guess I'll have to start sending some
bad-shaped packages then. :-)

Thank you again, Mattia!

Regards,
Tiago.

[1]: http://anonscm.debian.org/git/python-modules/packages/responses.git

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820053: mutt: %s in mailcap's "test=" field not expanded

[Bill Brelsford]

Package: mutt
Version: 1.5.24-1+b1
Severity: normal

Dear Maintainer,

After displaying a text/plain attachment (via autoview) with a
mailcap file containing

  text/plain; myprog %s; test=echo f=%s t=%t >/tmp/foo; copiousoutput

file /tmp/foo contains "f= t=text/plain" rather than the expected
"f=/tmp/muttJuO9nd t=text/plain".  (And the filename is not passed
to myprog.)


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

System: Linux 4.4.0-1-686-pae (i686)
ncurses: ncurses 6.0.20160319 (compiled with 6.0)
libidn: 1.32 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

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

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

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

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

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

Bug#820052: RFP: uefi-shim -- UEFI shim boot loader to support Secure Boot

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: uefi-shim
  Version : 0.9
  Upstream Author : Red Hat, Inc
* URL : https://github.com/rhinstaller/shim
* License : OpenSSL license (I think)
  Programming Lang: C
  Description : UEFI shim boot loader to support Secure Boot

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Tiago Ilieve]

Mattia,

On 4 April 2016 at 21:37, Mattia Rizzolo  wrote:
> yep, saw the mail that day, but didn't pay much attention back then.

There's no problem.

> This is basically a security feature, I think, not a bug.
>
> Though you should be able to fix it more manually by directly editing
> the HEAD file.
>
> but this time I just run the command for you :)
>
> This turned the HEAD file to be group Debian again and I can't have it
> back to scm_collab-maint as I'm not in the collab-maint anymore.
>
> Yeah, permissions on collab-maint (and alioth in general) are just a
> mess
> If you have troubles with file permissions on collab-maint feel free to
> mail me if you don't have any nearby DD..

Turns out that the "Debian" group is for DDs... Makes sense. Thanks
for fixing this. I'll surely reach you in case I need something like
that again.

> DSA has nothing to do with alioth (sadly?), there is only one active
> person with root on moszumanska (which is the guy that replied to you
> last time, iirc), but he won't chgrp the directory (as afaik he made
> them gid:Debian exactly because he wants to avoid external messing with
> repositories (if the root directory was writable by you you would be
> able to do anything with the config and the hooks, and that's a security
> trouble on collab-maint where everybody has access).

I see. The problem is that the repository is writable by the owner,
who can edit any configs/hooks. I had a problem in this case because I
was not the one who created it.

It is indeed quite hard to take care of a place where so many people
can write to.

> Yep, even if I'm always wary of this.
> I'm a guy who prefers using the tarballs as provided upstream.
> I wrote this item before noticing that you used .xz, so a different
> tarball than upstream.
> Fine by me, I see how this is enough for this case.

Now I understood. You mean a byte-to-byte identical tarball, not
identical regarding its contents only. I see this as enough by now
too. If the upstream starts releasing signed tarballs we can changed
that.

> ok, yes I know it's more popular.  To me it seems "Expat" is known only
> within Debian, heh :)

Actually, now that you mentioned I guess I had never ever heard of the
"Expat License" outside Debian...

> going to set myself as owner, will look at it somewhen tomorrow though.

Well, looks like you already take a look a few minutes ago. :-)

> Well, I uploaded it :D
>
> I also tagged the repository.

It is on the NEW queue right now. The tag detail is also pretty nice.
Fetched it.

Thank you very much, Mattia!

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820050: RFP: grub2-signed -- Signed versions of GRUB for UEFI Secure Boot

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: grub2-signed
  Version : 1.65
  Upstream Author : Colin Watson 
* URL : https://launchpad.net/ubuntu/+source/grub2-signed
* License : GPL-3+
  Programming Lang: Python
  Description : Signed versions of GRUB for UEFI Secure Boot

Bug#811214: RFS: retroarch/1.3.0-1 [ITP]

[Sérgio Benjamim]

RetroArch is in the new queue! Thanks Gianfranco!

I updated some of the libretro cores, for mupen64plus and beetle-psx 
it's better to stick with the old ones (not so old...). Lot of commits 
nowadays, it's better to wait them stay calm.


sergio-br2

Bug#820051: virtualbox: apt-get installation routine recommends package linux-image, which doesn't exist

[Harald N.]

Package: virtualbox
Version: 4.3.36-dfsg-1+deb8u1
Severity: minor
Tags: d-i

Dear Maintainer,


When installing Virtualbox, it recommends the package Linux-image, which cannot
be installed/doesn't exist

Here the log of my actions:


-> # apt-get install virtualbox

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  cpp-4.8 dkms fakeroot gcc gcc-4.8 gcc-4.9 libasan0 libasan1 libatomic1 libc-
dev-bin libc6-dev libcilkrts5 libfakeroot libgcc-4.8-dev libgcc-4.9-dev
libgsoap5 libitm1 liblsan0 libtsan0 libubsan0 libvncserver0
  linux-compiler-gcc-4.8-x86 linux-headers-3.16.0-4-amd64 linux-
headers-3.16.0-4-common linux-headers-amd64 linux-kbuild-3.16 linux-libc-dev
manpages-dev virtualbox-dkms virtualbox-qt
Vorgeschlagene Pakete:
  gcc-4.8-locales gcc-multilib autoconf automake libtool flex bison gdb gcc-doc
gcc-4.8-multilib gcc-4.8-doc libgcc1-dbg libgomp1-dbg libitm1-dbg
libatomic1-dbg libasan0-dbg libtsan0-dbg libquadmath0-dbg
  gcc-4.9-multilib gcc-4.9-doc gcc-4.9-locales libasan1-dbg liblsan0-dbg
libubsan0-dbg libcilkrts5-dbg glibc-doc vde2 virtualbox-guest-additions-iso
Empfohlene Pakete:
  linux-image
Die folgenden NEUEN Pakete werden installiert:
  cpp-4.8 dkms fakeroot gcc gcc-4.8 gcc-4.9 libasan0 libasan1 libatomic1 libc-
dev-bin libc6-dev libcilkrts5 libfakeroot libgcc-4.8-dev libgcc-4.9-dev
libgsoap5 libitm1 liblsan0 libtsan0 libubsan0 libvncserver0
  linux-compiler-gcc-4.8-x86 linux-headers-3.16.0-4-amd64 linux-
headers-3.16.0-4-common linux-headers-amd64 linux-kbuild-3.16 linux-libc-dev
manpages-dev virtualbox virtualbox-dkms virtualbox-qt
0 aktualisiert, 31 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 49,1 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 197 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] y

Followed by the output of the installation.

#
#


-> # apt-get install linux-image
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Package linux-image is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'linux-image' has no installation candidate

#
#

-> # cat /etc/apt/sources.list
#

# deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-1
20160123-19:03]/ jessie contrib main

#deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-1
20160123-19:03]/ jessie contrib main
#
#deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-2
20160123-19:03]/ jessie contrib main

#deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 DVD Binary-3
20160123-19:03]/ jessie contrib main

deb http://security.debian.org/ jessie/updates main contrib
#deb-src http://security.debian.org/ jessie/updates main contrib

# jessie-updates, previously known as 'volatile'
# A network mirror was not selected during install.  The following entries
# are provided as examples, but you should amend them as appropriate
# for your mirror of choice.
#
deb http://ftp.debian.org/debian/ jessie-updates main contrib non-free
#deb-src http://ftp.debian.org/debian/ jessie-updates main contrib non-free



deb http://ftp.at.debian.org/debian/ jessie main contrib non-free
#
#

I hope, I did not just fail completely...

Yours,
H.




-- System Information:
Debian Release: 8.4
  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=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u4
ii  libcurl3-gnutls  7.38.0-4+deb8u3
ii  libgcc1  1:4.9.2-10
ii  libgsoap52.8.17-1
ii  libpng12-0   1.2.50-2+deb8u2
ii  libpython2.7 2.7.9-2
ii  libsdl1.2debian  1.2.15-10+b1
ii  libssl1.0.0  1.0.1k-3+deb8u4
ii  libstdc++6   4.9.2-10
ii  libvncserver00.9.9+dfsg2-6.1+deb8u1
ii  libvpx1  1.3.0-3
ii  libx11-6 2:1.6.2-3
ii  libxcursor1  1:1.1.14-1+b1
ii  libxext6 2:1.3.3-1
ii  libxml2  2.9.1+dfsg1-5+deb8u1
ii  libxmu6  2:1.1.2-1
ii  libxt6   1:1.1.4-1+b1
ii  python   2.7.9-1
ii  python2.72.7.9-2
pn  python:any   
ii  virtualbox-dkms  4.3.36-dfsg-1+deb8u1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore4  

Bug#819197: Acknowledgement (dgedit - french localisation for the menu item)

[trebmuh]

Thanks.

Bug#815202: packages: machines and sponsors information is outdated

[Stéphane Blondon]

Le 01/04/2016 06:43, Paul Wise a écrit :
> DSA would very much like to kill the existing codebase behind the
> db.d.o website in favour of a rewrite in django:
> 
> https://github.com/Debian/ud

There are no commit since two years, so I'm not sure it's still alive.



> The existing codebase is available here:
> 
> https://anonscm.debian.org/cgit/mirror/userdir-ldap-cgi.git/tree/machines.cgi

I tried to extract the useful code from the script. It depends on the
libnet-ldapapi-perl package and the configuration of the machine which
is running the LDAP.

The syntax is correct but I can't run it on the machine (I don't have
the access rights).

However, I wonder if this perl script is the best strategy:

- Perhaps providing the full data in JSON format by db.d.o would provide
an easy access for several Debian services/tools.
- Or providing a python script which could be reused by the django site
in the future?

Whatever the chosen solution, I can't try to it due to lack of access
rights. (I think it's normal I don't have it.)

-- 
Stéphane


packagemachines.pl
Description: Perl program


signature.asc
Description: OpenPGP digital signature

Bug#820048: lxmenu-data: menu and themes seem missing start icon

[Richard Jasmin]

Package: lxmenu-data
Version: 0.1.4-1
Severity: normal
Tags: patch

Dear Maintainer,

lxde seems somehow missing things.
And by missing I mean the menu icon.

on SIN, its called the start menu button icon.

Ive looked but nowhere on my system can I find any icon for it anywhere. I have
many themes installed but none seem to have the necessary file.

patch:
not per se, but somewhat of a fix.

/usr/share/icons/Bluecurve/24x24/apps/icon-panel-menu.png
This file is not found under ANY LXDE(gtk3) theme.
Please put it back or ask theme creators to add it.



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

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

-- no debconf information

Bug#820049: letsencrypt: error: prepare is a flag but is being set to 'False

[Antoine Beaupré]

Package: letsencrypt
Version: 0.4.1-1~bpo8+1
Severity: normal

I don't quite understand how i got into this situation. I just installed
the letsencrypt package from backport - i was using LE using a
virtualenv built from the git repo ("cf218dd Release 0.3.0") before.

That created a "renewal" file which I am trying to use now:

# letsencrypt -c /etc/letsencrypt/renewal/wiki.reseaulibre.ca.conf 
--renew-by-default
usage:
  letsencrypt [SUBCOMMAND] [options] [-d domain] [-d domain] ...

The Let's Encrypt agent can obtain and install HTTPS/TLS/SSL certificates.  By
default, it will attempt to use a webserver both for obtaining and installing
the cert. Major SUBCOMMANDS are:

  (default) runObtain & install a cert in your current webserver
  certonly Obtain cert, but do not install it (aka "auth")
  install  Install a previously obtained cert in a server
  renewRenew previously obtained certs that are near expiry
  revoke   Revoke a previously obtained certificate
  rollback Rollback server configuration changes made during install
  config_changes   Show changes made to server config during installation
  plugins  Display information about installed plugins
letsencrypt: error: prepare is a flag but is being set to 'False'

There is indeed a "prepare" flag in the config, but it was put there by
the LE client - i certainly didn't customize that file myself, or at
least, not that I remember. Even if I comment out that parameter, a ton
more yield the same error.

A.

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

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

Versions of packages letsencrypt depends on:
ii  dialog  1.2-20140911-1
ii  python  2.7.9-1
ii  python-letsencrypt  0.4.1-1~bpo8+1
pn  python:any  

letsencrypt recommends no packages.

Versions of packages letsencrypt suggests:
pn  python-letsencrypt-apache  
pn  python-letsencrypt-doc 

-- no debconf information

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Mon, Apr 04, 2016 at 06:02:56PM -0300, Tiago Ilieve wrote:
> dget -x http://mentors.debian.net/debian/pool/main/g/grip/grip_4.1.0-1.dsc

meh, there is git, let me use it!
https://anonscm.debian.org/git/collab-maint/grip.git

Though as I said on the other one I'm wary of taking out the tarball
without pristine-tar, so I'm going to use the tarball you uploaded to
mentors with the git repo.

> Tests are commented out in "debian/rules" because they depend on a newer
> version of "python-responses". I've filled a bug (#820020[2]) which is now
> pending (thanks Ondrej Novy!). This can be fixed as soon as the updated 
> package
> hits unstable.

I pinged onovy and see if we can upload src:responses before this, so
that the tests are enabled.

The package itself looks cool instead, so I'm just going to wait for
onovy to reply and discover when he plans on uploading.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#820038: Copy signatures into udebs

[Ben Hutchings]

On Tue, 05 Apr 2016 00:02:46 +0100 Ben Hutchings  wrote:
> Package: kernel-wedge
> Version: 2.94
> Severity: normal
> 
> We will probably implement module signing using detached signatures
> which kmod will concatenate to the modules at load time (see #820010).
> mkinitramfs will need to copy the detached signatures along with all
> the modules it includes in each udeb.

This is copypasta from the initramfs-tools bug.

Since kernel-wedge runs as part of the kernel build process, before any
code is signed, it can't include signatures in module udebs unless we
revert to building udebs separately (which I really don't want to do).

> It might also be necessary to add special support for signed kernel
> images, although linux-signed may end up generating the udebs for
> that directly.

We could extend kernel-wedge to build one or more udebs containing only
the module signatures.  This makes a certain amount of sense because we
will otherwise end up including all detached signature files in the
installer images (bloat) or replicating some of kernel-wedge's logic
to work out which are needed (fragile).

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

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

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Mattia Rizzolo]

On Mon, Apr 04, 2016 at 08:09:31PM -0300, Tiago Ilieve wrote:
> Hi Mattia,
> 
> On 4 April 2016 at 18:25, Mattia Rizzolo  wrote:
> > I usually prefer using git to do my stuff, though here a simple clone is
> > not enough:
> >
> > mattia@chase ~/devel/RFS/python-path-and-address % git clone 
> > https://anonscm.debian.org/git/collab-maint/python-path-and-address.git
> > Cloning into 'python-path-and-address'...
> > remote: Counting objects: 119, done.
> > remote: Compressing objects: 100% (110/110), done.
> > remote: Total 119 (delta 44), reused 0 (delta 0)
> > Receiving objects: 100% (119/119), 27.69 KiB | 0 bytes/s, done.
> > Resolving deltas: 100% (44/44), done.
> > Checking connectivity... done.
> > warning: remote HEAD refers to nonexistent ref, unable to checkout.
> >
> > you seems to use debian/unstable as main packaging branch, so please set
> > HEAD in a way a simple 'git clone' just works.
> 
> This is related to some issues with collab-maint I've reported last
> weekend[1].

yep, saw the mail that day, but didn't pay much attention back then.

> In the other repositories that I've created in there, "git
> symbolic-ref HEAD refs/heads/debian/unstable" can be used update the
> default branch. The problem is that, as I'm not the owner (because I
> didn't created the the repository, adopted ITP) nor member of the
> group ("Debian" instead of "scm_collab-maint") of the folder
> "/git/collab-maint/python-path-and-address.git", it raises the
> following error:
> 
> error: Unable to open HEAD.lock for writing

This is basically a security feature, I think, not a bug.

Though you should be able to fix it more manually by directly editing
the HEAD file.

but this time I just run the command for you :)

This turned the HEAD file to be group Debian again and I can't have it
back to scm_collab-maint as I'm not in the collab-maint anymore.

Yeah, permissions on collab-maint (and alioth in general) are just a
mess
If you have troubles with file permissions on collab-maint feel free to
mail me if you don't have any nearby DD..

> If you know someone with sudo privileges on git.debian.org
> (moszumanska) to fix the folder permissions, please let me know so I
> can forward this issue to them. Maybe I should ask the DSA team
> directly?

DSA has nothing to do with alioth (sadly?), there is only one active
person with root on moszumanska (which is the guy that replied to you
last time, iirc), but he won't chgrp the directory (as afaik he made
them gid:Debian exactly because he wants to avoid external messing with
repositories (if the root directory was writable by you you would be
able to do anything with the config and the hooks, and that's a security
trouble on collab-maint where everybody has access).

> > Also, your git repository seems to lack a pristine-tar branch, which is
> > basically needed to get the same tarball that is in the archive.
> 
> There's the "upstream" branch in there, which serves this purpose. It
> is defined as "upstream-branch" in "debian/gbp.conf". Running "gbp
> buildpackage" will recreate
> "python-path-and-address_1.1.0.orig.tar.xz" from it:
> 
> gbp:info: python-path-and-address_1.1.0.orig.tar.xz does not exist,
> creating from 'upstream/1.1.0'
> 
> It uses the tag to do this, so there's even no need to checkout
> "origin/upstream" in a local branch.

Yep, even if I'm always wary of this.
I'm a guy who prefers using the tarballs as provided upstream.
I wrote this item before noticing that you used .xz, so a different
tarball than upstream.
Fine by me, I see how this is enough for this case.

> > * debian/patches:
> >   + empty, please remove the directory
> 
> Done[2].
> 
> > * debian/changelog:
> >   + be more precise: that's the Expat license
> 
> I do understand that some may say that the Expat License is the right
> name for MIT license, but the text in there is identical to the ones
> published by OSI[3] and GitHub's Choose a License[4] of the MIT
> License. In order to avoid any further confusion, I'd like to ask you
> to leave this as is. The name "MIT" is much more popular for the text.

ok, yes I know it's more popular.  To me it seems "Expat" is known only
within Debian, heh :)

> 
> > I'll look also at the rdep of this once through with this.
> 
> Thank you. Feel free to take the ownership of the other RFS too.

going to set myself as owner, will look at it somewhen tomorrow though.

> > Note: fixing on git is enough, I'm very much fine doing everything
> > with git.
> 
> I prefer to do that too. I've uploaded the package to mentors because
> it would be easier for anyone to take a look (using the web interface)
> at its state without even having to download it.
> 
> I'll ping you every time I make a change.

Well, I uploaded it :D

I also tagged the repository.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : 

Bug#820010: [PATCH v2] libkmod: Add support for detached module signatures

[Ben Hutchings]

Debian will not sign modules during the kernel package build, as this
conflicts with the goal of reproducible builds.  Instead, we will
generate detached signatures offline and include them in a second
package.

We could attach the signatures when building this second package or at
installation time, but that leads to duplication of all modules,
either in the archive or on users' systems.

To avoid this, add support to libkmod for concatenating modules with
detached signatures (files with the '.sig' extension) at load time.

Signed-off-by: Ben Hutchings 
---
v2: Fix syntax error in the xz case

Missed this because I didn't realise the Debian package disables gzip
and xz support.

Ben.

 libkmod/libkmod-file.c | 110 +
 1 file changed, 103 insertions(+), 7 deletions(-)

diff --git a/libkmod/libkmod-file.c b/libkmod/libkmod-file.c
index 5eeba6a912a2..cb1da3c9e2ae 100644
--- a/libkmod/libkmod-file.c
+++ b/libkmod/libkmod-file.c
@@ -52,6 +52,7 @@ struct kmod_file {
gzFile gzf;
 #endif
int fd;
+   int sig_fd;
bool direct;
off_t size;
void *memory;
@@ -60,6 +61,37 @@ struct kmod_file {
struct kmod_elf *elf;
 };
 
+static int append_detached_sig(struct kmod_file *file, size_t buf_size)
+{
+   struct stat st;
+   ssize_t read_size;
+
+   if (file->sig_fd < 0)
+   return 0;
+
+   if (fstat(file->sig_fd, ) < 0)
+   return -errno;
+
+   /* Grow the buffer if necessary */
+   if ((size_t)st.st_size > buf_size - file->size) {
+   void *tmp = realloc(file->memory, file->size + st.st_size);
+   if (tmp == NULL)
+   return -errno;
+   file->memory = tmp;
+   }
+
+   read_size = read(file->sig_fd, (char *)file->memory + file->size,
+st.st_size);
+   if (read_size < 0)
+   return -errno;
+   if (read_size != st.st_size)
+   return -EINVAL;
+
+   file->size += read_size;
+
+   return 0;
+}
+
 #ifdef ENABLE_XZ
 static void xz_uncompress_belch(struct kmod_file *file, lzma_ret ret)
 {
@@ -144,6 +176,7 @@ static int load_xz(struct kmod_file *file)
 {
lzma_stream strm = LZMA_STREAM_INIT;
lzma_ret lzret;
+   size_t buf_size;
int ret;
 
lzret = lzma_stream_decoder(, UINT64_MAX, LZMA_CONCATENATED);
@@ -155,7 +188,14 @@ static int load_xz(struct kmod_file *file)
return -EINVAL;
}
ret = xz_uncompress(, file);
+   buf_size = file->size + strm.avail_out;
lzma_end();
+
+   if (!ret) {
+   ret = append_detached_sig(file, buf_size);
+   if (ret)
+   free(file->memory);
+   }
return ret;
 }
 
@@ -214,6 +254,11 @@ static int load_zlib(struct kmod_file *file)
 
file->memory = p;
file->size = did;
+
+   err = append_detached_sig(file, total);
+   if (err)
+   goto error;
+
p = NULL;
return 0;
 
@@ -254,18 +299,50 @@ static int load_reg(struct kmod_file *file)
if (fstat(file->fd, ) < 0)
return -errno;
 
-   file->size = st.st_size;
-   file->memory = mmap(NULL, file->size, PROT_READ, MAP_PRIVATE,
-   file->fd, 0);
-   if (file->memory == MAP_FAILED)
-   return -errno;
-   file->direct = true;
+   if (file->sig_fd < 0) {
+   file->size = st.st_size;
+   file->memory = mmap(NULL, file->size, PROT_READ, MAP_PRIVATE,
+   file->fd, 0);
+   if (file->memory == MAP_FAILED)
+   return -errno;
+   file->direct = true;
+   } else {
+   size_t plain_size = st.st_size, sig_size;
+   _cleanup_free_ unsigned char *p = NULL;
+   ssize_t ret;
+
+   if (fstat(file->sig_fd, ) < 0)
+   return -errno;
+   sig_size = st.st_size;
+
+   p = malloc(plain_size + sig_size);
+   if (!p)
+   return -errno;
+
+   ret = read(file->fd, p, plain_size);
+   if (ret < 0)
+   return -errno;
+   if ((size_t)ret != plain_size)
+   return -EINVAL;
+   file->memory = p;
+   file->size = plain_size;
+
+   ret = append_detached_sig(file, plain_size + sig_size);
+   if (ret)
+   return ret;
+
+   p = NULL;
+   }
+
return 0;
 }
 
 static void unload_reg(struct kmod_file *file)
 {
-   munmap(file->memory, file->size);
+   if (file->direct)
+   munmap(file->memory, file->size);
+   else
+   free(file->memory);
 }
 
 static const struct file_ops reg_ops = {
@@ -285,6 +362,7 @@ struct kmod_file 

Bug#818308: openjdk-7-jre-headless: openjdk-7 uninstallable because tzdata-java removed

[Ben Caradoc-Davies]

openjdk-7 is still uninstallable on unstable because 7u95-2.6.4-3 is 
only available in experimental and has not yet been accepted into unstable.


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

Bug#820047: make exits with no output

[Richard Jasmin]

Package: make
Version: 4.0-8.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I have a weird repeatable issue with make.
Sometimes I make something and make exits cleanly and does nothing.
At said time, no call to make will actually do anything.

The workaround is to close the shell and re-open a new one to restore
functionality.

build a kpkg and youll see what I mean.This has happened with other QT projects
as well in the past, so its not kernel specific or code specific.

This shouldnt happen.If make is getting thrown to the wolves, then we need to
be able to see where and how to fix it.
(mebbe a double free, null pointer, or failure to free mem?)



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

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

Versions of packages make depends on:
ii  libc6  2.19-18+deb8u4

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information

Bug#820045: tiny-initramfs: support loading detached signatures and copying them into initramfs

[Ben Hutchings]

On Tue, 2016-04-05 at 02:08 +0200, Christian Seiler wrote:
> Package: src:tiny-initramfs
> Version: 0.1-2
> Severity: normal
> 
> (Filing this as maintainer of tiny-initramfs after seeing the the
> other bugs related to secure boot filed on debian-devel.)
> 
> As well as the other initramfs implementations in Debian (dracut,
> #820041 and initramfs-tools, #820037), tiny-initramfs should also
> support detached signatures for the kernel modules to support secure
> boot. Since it doesn't use kmod to load modules but the syscall
> directly, support for appending the signatures needs to be added to
> tiny-initramfs - in addition to the code required in the Debian
> packaging that generates the initramfs and copies the modules there.
> 
> I plan to work on this once I've familiarized myself with how the
> signature stuff works.

The signing process appends a signature and some metadata to the end of
the module.  I've implemented detached module signatures in such a way
that you can simply concatenate module and signature file, and you
might as well do that at initramfs build time.

> @Ben: I'll leave it up to you if you want to block #820036 with this
> bug, as tiny-initramfs is a very niche thing with low popcon.

It wouldn't be a blocker for announcing 'Debian now supports Secure
Boot' but it seems reasonable to add it to that tracking bug.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot


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

Bug#820010: [PATCH] libkmod: Add support for detached module signatures

[Ben Hutchings]

Debian will not sign modules during the kernel package build, as this
conflicts with the goal of reproducible builds.  Instead, we will
generate detached signatures offline and include them in a second
package.

We could attach the signatures when building this second package or at
installation time, but that leads to duplication of all modules,
either in the archive or on users' systems.

To avoid this, add support to libkmod for concatenating modules with
detached signatures (files with the '.sig' extension) at load time.

Signed-off-by: Ben Hutchings 
---
I should note that I have *not* tested this with gzip or xz
compressed modules.

Ben.

 libkmod/libkmod-file.c | 110 +
 1 file changed, 103 insertions(+), 7 deletions(-)

diff --git a/libkmod/libkmod-file.c b/libkmod/libkmod-file.c
index 5eeba6a912a2..c30a9b92a3ac 100644
--- a/libkmod/libkmod-file.c
+++ b/libkmod/libkmod-file.c
@@ -52,6 +52,7 @@ struct kmod_file {
gzFile gzf;
 #endif
int fd;
+   int sig_fd;
bool direct;
off_t size;
void *memory;
@@ -60,6 +61,37 @@ struct kmod_file {
struct kmod_elf *elf;
 };
 
+static int append_detached_sig(struct kmod_file *file, size_t buf_size)
+{
+   struct stat st;
+   ssize_t read_size;
+
+   if (file->sig_fd < 0)
+   return 0;
+
+   if (fstat(file->sig_fd, ) < 0)
+   return -errno;
+
+   /* Grow the buffer if necessary */
+   if ((size_t)st.st_size > buf_size - file->size) {
+   void *tmp = realloc(file->memory, file->size + st.st_size);
+   if (tmp == NULL)
+   return -errno;
+   file->memory = tmp;
+   }
+
+   read_size = read(file->sig_fd, (char *)file->memory + file->size,
+st.st_size);
+   if (read_size < 0)
+   return -errno;
+   if (read_size != st.st_size)
+   return -EINVAL;
+
+   file->size += read_size;
+
+   return 0;
+}
+
 #ifdef ENABLE_XZ
 static void xz_uncompress_belch(struct kmod_file *file, lzma_ret ret)
 {
@@ -144,6 +176,7 @@ static int load_xz(struct kmod_file *file)
 {
lzma_stream strm = LZMA_STREAM_INIT;
lzma_ret lzret;
+   size_t buf_size;
int ret;
 
lzret = lzma_stream_decoder(, UINT64_MAX, LZMA_CONCATENATED);
@@ -155,7 +188,14 @@ static int load_xz(struct kmod_file *file)
return -EINVAL;
}
ret = xz_uncompress(, file);
+   buf_size = file->size + strm->avail_out;
lzma_end();
+
+   if (!ret) {
+   ret = append_detached_sig(file, buf_size);
+   if (ret)
+   free(file->memory);
+   }
return ret;
 }
 
@@ -214,6 +254,11 @@ static int load_zlib(struct kmod_file *file)
 
file->memory = p;
file->size = did;
+
+   err = append_detached_sig(file, total);
+   if (err)
+   goto error;
+
p = NULL;
return 0;
 
@@ -254,18 +299,50 @@ static int load_reg(struct kmod_file *file)
if (fstat(file->fd, ) < 0)
return -errno;
 
-   file->size = st.st_size;
-   file->memory = mmap(NULL, file->size, PROT_READ, MAP_PRIVATE,
-   file->fd, 0);
-   if (file->memory == MAP_FAILED)
-   return -errno;
-   file->direct = true;
+   if (file->sig_fd < 0) {
+   file->size = st.st_size;
+   file->memory = mmap(NULL, file->size, PROT_READ, MAP_PRIVATE,
+   file->fd, 0);
+   if (file->memory == MAP_FAILED)
+   return -errno;
+   file->direct = true;
+   } else {
+   size_t plain_size = st.st_size, sig_size;
+   _cleanup_free_ unsigned char *p = NULL;
+   ssize_t ret;
+
+   if (fstat(file->sig_fd, ) < 0)
+   return -errno;
+   sig_size = st.st_size;
+
+   p = malloc(plain_size + sig_size);
+   if (!p)
+   return -errno;
+
+   ret = read(file->fd, p, plain_size);
+   if (ret < 0)
+   return -errno;
+   if ((size_t)ret != plain_size)
+   return -EINVAL;
+   file->memory = p;
+   file->size = plain_size;
+
+   ret = append_detached_sig(file, plain_size + sig_size);
+   if (ret)
+   return ret;
+
+   p = NULL;
+   }
+
return 0;
 }
 
 static void unload_reg(struct kmod_file *file)
 {
-   munmap(file->memory, file->size);
+   if (file->direct)
+   munmap(file->memory, file->size);
+   else
+   free(file->memory);
 }
 
 static const struct file_ops reg_ops = {
@@ -285,6 +362,7 @@ struct kmod_file *kmod_file_open(const struct kmod_ctx *ctx,

Bug#820046: guitarix: does not respect DEB_BUILD_OPTIONS=parallel max value

[Víctor Cuadrado Juan]

Package: guitarix
Version: 0.34.0-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When building with DEB_BUILD_OPTIONS=parallel (which uses -j JOBS),
it doesn't honor the specified job number.

For example, with DEB_BUILD_OPTIONS=parallel=3, it will use the
maximum job number possible, 4 in my 4 core machine, instead of
the specified 3.



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

Kernel: Linux 4.4.0-1-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)

Versions of packages guitarix depends on:
ii  gtk2-engines  1:2.20.2-3
ii  gtk2-engines-pixbuf   2.24.30-1.1
ii  guitarix-common   0.34.0-2
ii  guitarix-ladspa   0.34.0-2
ii  guitarix-lv2  0.34.0-2
ii  libatkmm-1.6-1v5  2.24.2-1
ii  libavahi-common3  0.6.32~rc+dfsg-1
ii  libavahi-gobject0 0.6.32~rc+dfsg-1
ii  libbluetooth3 5.36-1
ii  libboost-system1.58.0 1.58.0+dfsg-5+b1
ii  libc6 2.22-5
ii  libcairo2 1.14.6-1
ii  libcairomm-1.0-1v51.12.0-1
ii  libfftw3-single3  3.3.4-2+b1
ii  libgcc1   1:5.3.1-13
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.48.0-1
ii  libglibmm-2.4-1v5 2.46.3-1
ii  libgtk2.0-0   2.24.30-1.1
ii  libgtkmm-2.4-1v5  1:2.24.4-2+b1
ii  libgxw0   0.34.0-2
ii  libgxwmm0 0.34.0-2
ii  libjack0 [libjack-0.116]  1:0.124.1+20140122git5013bed0-3
ii  liblilv-0-0   0.22.0~dfsg0-1
ii  liblrdf0  0.4.0-7
ii  libpango-1.0-01.38.1-1
ii  libpangomm-1.4-1v52.38.1-1
ii  libsigc++-2.0-0v5 2.8.0-1
ii  libsndfile1   1.0.25-10
ii  libstdc++65.3.1-13
ii  libwebkitgtk-1.0-02.4.10-1
ii  libzita-convolver33.1.0-4
ii  libzita-resampler11.3.0-2

Versions of packages guitarix recommends:
pn  jack-capture  
ii  lame  3.99.5+repack1-9+b1
ii  vorbis-tools  1.4.0-8

guitarix suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXAwOnAAoJECI/Fcparw54xnUH/2XlHc8EWvpSntFl9enJygG7
7t57q7+YHXmJ3JutwTzAsyCa/K1cNbogEhx+Ye4oxvF30biOrr4n2oqHaIv84hyd
4spNRbxN6InXA5cZmsE9tGQCr4E+cuY4ACx1efWyf/ivWPWiX0Fvrpsszw7VRZL2
r0z8DMzel9q5OS3wn7HoGOm7rn/JDj+/yG2N7QZUk4EQE9Hpe/VUhA4HqfQGzos8
vKIJfNzOuB5bGULRtFZq3DYQCusPFjtbdKc6S+MKNdD7eFSHdOUlt6C50YS5FHYS
jcyiaH8MMA+JzFnW8iOOJUqsTmOY/fWKAedK50PANN7yytvWrxvqUr49NLTylaI=
=vPGh
-END PGP SIGNATURE-

Bug#819943: really should add an unforbid-version command

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 + wontfix


Hi,

2016-04-04 03:05 積丹尼 Dan Jacobson:

Package: aptitude
Version: 0.7.8-1

Today I will inspect the how hard it is to just simple reverse the action of
# aptitude forbid-version somepackage
so we are back to the state before we did it.

The man page says

  To revert the action, "aptitude install " will remove the
  ban. To remove the forbidden version without installing the
  candidate version, the current version should be appended: "install
  =".

Well I think you really should an unforbid-version command.


The documentation was improved after another recent request of yours
(duplicate, actually), #773023.

 forbid-version
 
 Forbid a package from being upgraded to a particular version, while

 allowing automatic upgrades to future versions. This is useful for
 example to avoid a known broken version of a package, without
 having to set and clear manual holds.

 By default, aptitude will select the forbidden version to be the
 one which the package would normally be upgraded (the candidate
 version). This may be overridden by appending “=” to the
 package name: for instance, “aptitude forbid-version
 vim=1.2.3.broken-4”.

 To revert the action, “aptitude install ” will remove the
 ban. To remove the forbidden version without installing the
 candidate version, the current version should be appended: “install
 =”.

I think that it will explains quite clearly how to achieve what you
want, if you really want to undo "forbids".



Also the man page should say if only one version can be forbidden or
more.


It only mentions a single version that can be forbidden throughout the 3
paragraphs, and implies that forbidding several version is a job for
"hold".

This seems to be sufficiently clear for mostly everybody, since there
are no duplicates about the issue in the last few years but yours.



Also one thinks I could just use forbid-version=0 to clear it, but that
is not a current version of that package.

And
# aptitude forbid-version package1 package2 package3 ... package20
will require an enormous amount of work to reverse, digging up each
version number...


forbid-version is to mark a specific version of a package that you are
quite sure that you don't want to install, e.g. with a RC bug or a
problem that affects your systems badly.

Whenever a new version is available, the system will happily upgrade to
new versions, e.g. with dist-upgrade.  So, as the doc explains quite
clearly, forbid-version is intended as a shortcut for "temporary holds"
on a specific version which self-destroy when a new version is available
and the sysadmin requires an upgrade of the system, a set of package or
a single package.

If you find that you're using forbid-version and need to revert it quite
often _without installing the new version of the packages already
available at the same time_, perhaps you would like to use only "hold"
(and its corresponding "unhold"), because the use that you are asking is
not what forbid-version is intended for and you are actually using it as
a "hold".

Blurring the lines even more between forbid-version and hold is IMO not
a very useful thing to do in general, and not cost-effective.

tl;dr: if you are not happy with the shorcut and semantics of "forbid",
just use the more general "hold".



OK, let's try
# aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1

We will very likely encounter some
"The following actions will resolve these dependencies:

 Remove the following packages:"
questions which we will very probably answer "n", never reaching the
point where supposedly the forbid-version will be erased without
installing the package before quitting!

And, when you think about it
# aptitude install xserver-xorg-video-cirrus=
means the same as
# aptitude install xserver-xorg-video-cirrus
so if one didn't want to install the package one would answer "n" when
asked so never reaching the step where ... anyway one big no-op and the
forbid-version stays.


It works exactly as intended... install will attempt to install a new
version.

If you don't want to install a new version after all, having a "forbid"
on a version that you don't want installed _yet_ is harmless; so you
don't need to remove the "forbid" until/unless you are sure that you
want to install that version.  Catch-22.


That there are conflicts when installing a version of a package, which
in turn cause the packages to be suggested to be removed or other
actions (a bunch of them upgraded at the same time, for example) is
completely orthogonal to the question at hand.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#820045: tiny-initramfs: support loading detached signatures and copying them into initramfs

[Christian Seiler]

Package: src:tiny-initramfs
Version: 0.1-2
Severity: normal

(Filing this as maintainer of tiny-initramfs after seeing the the
other bugs related to secure boot filed on debian-devel.)

As well as the other initramfs implementations in Debian (dracut,
#820041 and initramfs-tools, #820037), tiny-initramfs should also
support detached signatures for the kernel modules to support secure
boot. Since it doesn't use kmod to load modules but the syscall
directly, support for appending the signatures needs to be added to
tiny-initramfs - in addition to the code required in the Debian
packaging that generates the initramfs and copies the modules there.

I plan to work on this once I've familiarized myself with how the
signature stuff works.

@Ben: I'll leave it up to you if you want to block #820036 with this
bug, as tiny-initramfs is a very niche thing with low popcon.

Regards,
Christian

Bug#817915: Released

[Carlo Stemberger]

OpenBazaar has been released:

https://blog.openbazaar.org/openbazaar-is-open-for-business/

Best regards,
Carlo

Bug#819703: Political or Moral problem? I don't think so

[Jamil Said Jr .]

Santiago Vila wrote:

> The "only" problem is that the author does not want anybody to do that
(read the comments at the beginning of the function).

Santiago, thank you for your response. However, I believed that we were
passed this point already, no?

The author wishes, if granted, would be "the end" of usable, nagging-free
stable branches. Can you imagine if all of your packages in a stable
installation started to (rudely) complain and harass you about your "old
version". Helloo, stable branches deliberately keep older versions for
better stability! Stable branches are preferable in a myriad of cases; just
look at what NASA did in 2013, they chose Debian for the ISS astronaut's
laptops and went with Debian 6 instead of the current Debian 7 at the time,
for extra stability! Should we be nagging the astronauts to update the
screensaver? See:
http://www.zdnet.com/article/to-the-space-station-and-beyond-with-linux/

The author, out of his own volition, released the code under a free, open
source license. End of story. Take this aberration (warning) out and comply
with whatever needed legally (like change the name of the program, etc). I
have no qualms with that. If the author wish was reasonable, I would be more
than glad to comply - but his wish is not reasonable.

Cheers,
Jamil

 

Bug#820044: Cloning a blocking bug overwrites rather than appending to the blocked list

[Ben Hutchings]

Package: bugs.debian.org
Severity: important

See what happened to #820036 when I cloned blocking bug #820037 - the
new bug was added as a blocker of #820036 but all the other blockers
were removed.

Ben.

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

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

Bug#806004: cgmanager: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

On Mon, Apr 04, 2016 at 11:00:35PM +, Serge Hallyn wrote:

> Thanks, it looks good to me, and everything builds right with it.
> Would you like to do an NMU with this patch?

Hmm, I would rather sponsor a maintainer upload than NMU the package.

(But you can also look for a sponsor in debian-mentors).

Bug#819942: command line mode war against TERM=dumb

[Manuel A. Fernandez Montecelo]

Control: forcemerge 817276 -1


Hi,

2016-04-04 02:58 積丹尼 Dan Jacobson:

Package: aptitude
Version: 0.7.8-1

I am using a emacs shell-mode window.

# aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1
aptitude cannot run in ncurses mode with terminal type "dumb"

So must use:
# TERM=linux aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1
# TERM= aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1
# unset TERM; aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1

You don't allow TERM=dumb (bug) but allow no TERM at all (fine).

$ TERM= aptitude
Error opening terminal: unknown.

That is fine.

But that is ncurses mode, and what I was doing wasn't.


This looks like a duplicate of #817276, merging.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#820043: isc-dhcp-client-udeb uninstallable: transitively depends on libisc160

[Cyril Brulebois]

Package: isc-dhcp-client-udeb
Version: 4.3.3-9
Severity: grave
Justification: renders package unusable

(-boot & -bsd in cc.)

Hi,

Your package is no longer installable through the dependency chain
you'll find on e.g. the amd64 graph:
  https://d-i.debian.org/dose/graph-unstable-amd64.png

That also means netcfg is no longer installable on kfreebsd-*.


KiBi.

Bug#820042: RM: beecrypt -- RoQA; dead upstream, unused library package

[James Cowgill]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove beecrypt from unstable.

Beecrypt is an orphaned library package with no reverse-dependencies.
It's been dead upstream since 2009.

Thanks,
James

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

Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console

[Manuel A. Fernandez Montecelo]

Hi Axel,

2016-04-03 00:29 Axel Beckert:

Package: aptitude
Version: 0.7.8-1

Hi,

aptitude segfaults under the following circumstances:

1. Log in as root on a Linux virtual console, i.e. after pressing
  Ctrl-Alt-F1.

2. Start aptitude in TUI mode, i.e. without any options or parameters.

3. Press Ctrl-Z to suspend aptitude.

4. Enter "fg" on the commandline and press Enter to bring aptitude back
  to the foreground.

5. Segfault.

This does not happen, if

* if tried inside an xterm
* if just TERM is set to "linux", but the terminal is no virtual linux
 console, i.e. "env TERM=linux aptitude" does not exhibit the issue.


What's "TERM" in the vt console?

Mine is "linux", and as you noted, it works fine.  If I "unset TERM" or
set it to the empty string, aptitude refuses to start ("Error opening
terminal: unknown").  If I set it to "linux", "xterm" or
"xterm-256color" it works fine.  "vt100" works fine, but no colours.

In any case, I couldn't get it to crash by suspending and restoring.

I am no expert in TERM, so I'm not sure which other values are possible
and which ones are correct.



Unfortunately I was not able to reproduce the issue under gdb
directly. But this is the backtrace I got out of the core dump:

Reading symbols from /usr/bin/aptitude-curses...Reading symbols from 
/usr/lib/debug/.build-id/17/b0aa382e98a7c74b766fe389e4e2c494dd8cce.debug...done.
done.

warning: core file may not match specified executable file.
[New LWP 6201]
[New LWP 6202]
[New LWP 6203]
[New LWP 6204]
[New LWP 6219]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `aptitude'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fe2861e5973 in ?? ()
[Current thread is 1 (Thread 0x7fe28a8d1780 (LWP 6201))]
(gdb) bt
#0  0x7fe2861e5973 in ?? ()
#1  0x in ?? ()
#2  0x00011839 in ?? ()
#3  0x0800 in ?? ()
#4  0x7fe287fa8b0c in ___vsprintf_chk (s=0x7ffd08eb4380 "", flags=-1416311776, 
slen=140724753089664, format=0x564aab94cc10 "\260R\266\252JV",
   args=0x564aa764dc78, args@entry=0x7ffd08eb44c8) at vsprintf_chk.c:85
#5  0x7fe287fa8a5d in ___sprintf_chk (s=, flags=, 
slen=, format=) at sprintf_chk.c:31
#6  0x564aa764dc78 in ?? ()
#7  0x564aab94cc20 in ?? ()
#8  0x7fe289d335d4 in ?? () from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#9  0x0080 in ?? ()
#10 0x7ffd08eb4b20 in ?? ()
#11 0x564aab94cc10 in ?? ()
#12 0x000d in ?? ()
#13 0xfffc in ?? ()
#14 0x7fe288af204f in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
#15 0x in ?? ()
(gdb)


None of the functions which name appears are from aptitude, cwidget or
apt, unfortunately.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#820040: [Backport Fix?] Fontconfig confuses Demilight (350) with Regular (400)

[Mingye Wang (Arthur2e5)]

Package: fontconfig
Version: 2.11.0-6.4
Version: 2.11.0-6.3

Fontconfig <= 2.11.1 uses a segmented approach to map font weights. This
breaks on fonts like Noto Sans CJK, where Demilight (OS/2 weight=350)
and Regular (OS/2 weight=400) are both treated as Regular (FC
weight=80). So if you install the `noto-cjk` package, you will get Noto
Sans CJK SC Demilight in front of Regular when running `fc-match -a
'Noto Sans CJK SC:weight=regular`.

This bug is fixed upstream in Aug 2014 (FD.o #81453) but is only
available in >= 2.11.91, part of 2.12.x development snapshots.
Fortunately, it seems that the commits that fixes this particular issue
can be identified:

3cd573f -- Some FcRange things that the actual fix depends on
be6506c -- The fix
bf9df5a ^^
ffda7c0 ^^
01bb697 -- Fix for a bug introduced by ffda7c0
80edacc ^^

gunnarhj at Ubuntu (LP #1556457) has successfully cherry-picked the
commits to 2.11.1 and built a package in
, and
you should be able to see if it works in LP #1468027 soon (that's where
the issue got re-identified.) I am not sure if any extra cherry-picking
is needed for 2.11.0 though.

Just in case that some third-party APT source maintainers may be
curious, there is also a working 2.11.94 build at
. Arch
Linux's reaction to the same problem (Arch #48550), as usual, is to
upgrade to 2.11.94 after some days of observation in [extra-testing].
(Oh, fontconfig-infinality got upgraded following ArchLinux..)

Fedora has (not surprisingly) already been following the 2.12 snapshots
for a while; Gentoo has 2.11.9x in testing already, and I am having some
technical problems opening openSUSE's package info site -- it seems that
I have done as much of fix-forwarding for this bug as possible. (Or
perhaps I can tell my Gentoo-using friends who are using Noto CJK to
emerge the new version after this bug report...)

I only checked the debian/patches dir to make sure that Debian doesn't
have anything that looks like a fix for this bug in its fontconfig
packages. This bug still needs to be confirmed by someone else.

-- 
Regards,

Arthur2e5



signature.asc
Description: OpenPGP digital signature

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Tiago Ilieve]

Hi Mattia,

On 4 April 2016 at 18:25, Mattia Rizzolo  wrote:
> I usually prefer using git to do my stuff, though here a simple clone is
> not enough:
>
> mattia@chase ~/devel/RFS/python-path-and-address % git clone 
> https://anonscm.debian.org/git/collab-maint/python-path-and-address.git
> Cloning into 'python-path-and-address'...
> remote: Counting objects: 119, done.
> remote: Compressing objects: 100% (110/110), done.
> remote: Total 119 (delta 44), reused 0 (delta 0)
> Receiving objects: 100% (119/119), 27.69 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (44/44), done.
> Checking connectivity... done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> you seems to use debian/unstable as main packaging branch, so please set
> HEAD in a way a simple 'git clone' just works.

This is related to some issues with collab-maint I've reported last
weekend[1]. In the other repositories that I've created in there, "git
symbolic-ref HEAD refs/heads/debian/unstable" can be used update the
default branch. The problem is that, as I'm not the owner (because I
didn't created the the repository, adopted ITP) nor member of the
group ("Debian" instead of "scm_collab-maint") of the folder
"/git/collab-maint/python-path-and-address.git", it raises the
following error:

error: Unable to open HEAD.lock for writing

If you know someone with sudo privileges on git.debian.org
(moszumanska) to fix the folder permissions, please let me know so I
can forward this issue to them. Maybe I should ask the DSA team
directly?

> Also, your git repository seems to lack a pristine-tar branch, which is
> basically needed to get the same tarball that is in the archive.

There's the "upstream" branch in there, which serves this purpose. It
is defined as "upstream-branch" in "debian/gbp.conf". Running "gbp
buildpackage" will recreate
"python-path-and-address_1.1.0.orig.tar.xz" from it:

gbp:info: python-path-and-address_1.1.0.orig.tar.xz does not exist,
creating from 'upstream/1.1.0'

It uses the tag to do this, so there's even no need to checkout
"origin/upstream" in a local branch.

> * debian/patches:
>   + empty, please remove the directory

Done[2].

> * debian/changelog:
>   + be more precise: that's the Expat license

I do understand that some may say that the Expat License is the right
name for MIT license, but the text in there is identical to the ones
published by OSI[3] and GitHub's Choose a License[4] of the MIT
License. In order to avoid any further confusion, I'd like to ask you
to leave this as is. The name "MIT" is much more popular for the text.

> I'll look also at the rdep of this once through with this.

Thank you. Feel free to take the ownership of the other RFS too.

> Note: fixing on git is enough, I'm very much fine doing everything
> with git.

I prefer to do that too. I've uploaded the package to mentors because
it would be easier for anyone to take a look (using the web interface)
at its state without even having to download it.

I'll ping you every time I make a change.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2016/04/msg8.html
[2]: 
https://anonscm.debian.org/git/collab-maint/python-path-and-address.git/commit/?h=debian/unstable=f75e55228e6a94ee9c87ef7cae91e07c5b4997c5
[3]: https://opensource.org/licenses/MIT
[4]: http://choosealicense.com/licenses/mit/

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#533233: avahi-autoipd should not overwrite route when other interfaces are configured

[Keith Buck]

Package: avahi-autoipd
Version: 0.6.31-5
Followup-For: Bug #533233

I'm experiencing the same issue. A default route with metric 1002 is being
added that is overriding the real default route of my machine's actually-
connected wireless interface. Even if autoconfiguration on other interfaces is
desirable, a metric of 1002 is entirely too low for an auto-configuration
"we're not sure if it'll even work" route.

Here are the routes on my machine, as configured by the default configuration:
default dev eth0  scope link  metric 1002
default via 10.202.100.1 dev wlan0  proto static  metric 1024

Changing the default base metric in the script (like in message #26) fixed it
for me, but it took a while to track this issue down.



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

Kernel: Linux 3.16.0-4-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)

Versions of packages avahi-autoipd depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.19-18+deb8u4
ii  libdaemon0  0.14-6

Versions of packages avahi-autoipd recommends:
ii  iproute2 3.16.0-2
ii  isc-dhcp-client  4.3.1-6+deb8u2

avahi-autoipd suggests no packages.

-- Configuration Files:
/etc/avahi/avahi-autoipd.action changed:
set -e
PATH="$PATH:/usr/bin:/usr/sbin:/bin:/sbin"
METRIC=$((1100 + `cat "/sys/class/net/$2/ifindex" 2>/dev/null || echo 0`))
if [ -x /bin/ip -o -x /sbin/ip ] ; then
# We have the Linux ip tool from the iproute package
case "$1" in
BIND)
ip addr add "$3"/16 brd 169.254.255.255 label "$2:avahi" scope link 
dev "$2"
ip route add default dev "$2" metric "$METRIC" scope link ||:
;;
CONFLICT|UNBIND|STOP)
ip route del default dev "$2" metric "$METRIC" scope link ||:
ip addr del "$3"/16 brd 169.254.255.255 label "$2:avahi" scope link 
dev "$2"
;;
*)
echo "Unknown event $1" >&2
exit 1
;;
esac
elif [ -x /bin/ifconfig -o -x /sbin/ifconfig ] ; then
# We have the old ifconfig tool
case "$1" in
BIND)
ifconfig "$2:avahi" inet "$3" netmask 255.255.0.0 broadcast 
169.254.255.255 up
route add default dev "$2:avahi" metric "$METRIC" ||:
;;
CONFLICT|STOP|UNBIND)
route del default dev "$2:avahi" metric "$METRIC" ||:
ifconfig "$2:avahi" down
;;
*)
echo "Unknown event $1" >&2
exit 1
;;
esac
else
echo "No network configuration tool found." >&2
exit 1
fi
exit 0


-- no debconf information

Bug#820039: RM: ipmitool [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- ROM; FTBFS

[Jörg Frings-Fürst]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

please remove ipmotool from hurd-i386, kfreebsd-amd64 and kfreebsd-i386.

Build fails with "usb.c:43:21: fatal error: scsi/sg.h: No such file or
directory"

The file scsi/sg.h isn't available in the three architectures.

CU
Jörg




-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXAvPiAAoJEAn4nzyModJdhqYP/1GewBvAyHHAR/24DoUFyp3j
6sIMG1gJtd0oxg8zV7YkUzyERb7qOxnxWQ0y/e6CfuIaUnR/MCIdbjMezxvHVmeR
N9B1/V+hf+x6CmTiBtZ14c1t5CEnnsWSwYeVDNMUPp+pPbf0gqGPH7zSOvYctsLZ
62iMffBkKzynD4C7QZwLzY1UqPYn/JCr/9LUyTSn7uFkaO8/BRLNa6+6O0zN/2Gf
kjs1j+oo34e8gp5U1Pu4nBiUooyaOY9qY9p6pWdcN8/ncpl+Qdb+br6FXrZ6wB58
MZt2Tiu9xd9PPedJU8Uitp4YspzuP3dRdjxQMLmCvDIXTeeNZW8nCefkfYk6jAnV
SeAAaeNWrc8n1Fl8SVHDpRbSjEM+hK5hOdbxcSO6aIvp63YmS6JzCCA5Ybu5Haci
W/cF1Q8T2gXjRxKSzsKfaNNpeL3y5HV6ziyWaXBy0P0NO95xPcgEsaSWL12oEn85
1xkF4PDTZStTtATpDffcgPbWI7ppUjf9n7a/dkTwp/t8MeQTM/ItQZh5RkBUfXbr
nrSB0HYNf8l+f4wKNSy3WSzccI9hIZTP285wvkvakVboXhyr4L3EyTellxldmTcg
fC4Pag63DsD9f/ESwonu7w8OQyjIDQj7ePxMmVAZcv5jjntUWqHDVQOLB2WkFHuF
j3RyjJ83xIDTIqCDscns
=6x6M
-END PGP SIGNATURE-

Bug#820038: Copy signatures into udebs

[Ben Hutchings]

Package: kernel-wedge
Version: 2.94
Severity: normal

We will probably implement module signing using detached signatures
which kmod will concatenate to the modules at load time (see #820010).
mkinitramfs will need to copy the detached signatures along with all
the modules it includes in each udeb.

It might also be necessary to add special support for signed kernel
images, although linux-signed may end up generating the udebs for
that directly.

Ben.

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

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

Versions of packages kernel-wedge depends on:
ii  debhelper  9.20160313
ii  make   4.1-9

kernel-wedge recommends no packages.

kernel-wedge suggests no packages.

-- no debconf information

Bug#806004: cgmanager: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Serge Hallyn]

Quoting Santiago Vila (sanv...@unex.es):
> > cp: cannot create regular file 
> > '/<>/debian/libpam-cgm/usr/share/pam-configs/cgm': No such 
> > file or directory
> > debian/rules:25: recipe for target 'override_dh_install' failed
> 
> This happens because we are creating only arch-independent packages,
> so debian/libpam-cgm does not exist, as it belongs to libpam-cgm
> which is Arch: any.
> 
> 
> The attached patch might fix this problem, as it renames current
> override_dh_install to override_dh_auto_install (where file moving in
> debian/tmp is better placed), but moves commands for the libpam-cgm
> package to a new target called override_dh_install-arch, which will
> only work when creating arch-dependent packages.

Thanks, it looks good to me, and everything builds right with it.
Would you like to do an NMU with this patch?

> Thanks.

> --- a/debian/rules
> +++ b/debian/rules
> @@ -21,18 +21,21 @@ override_dh_auto_configure:
>  override_dh_makeshlibs:
>   dh_makeshlibs -- -c4
>  
> -override_dh_install:
> +override_dh_auto_install:
> + dh_auto_install
>   mkdir -p $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)
>   mv $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcgmanager.so.* 
> \
>   $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)/
> - cp $(CURDIR)/debian/pam-cgm.config \
> - $(CURDIR)/debian/libpam-cgm/usr/share/pam-configs/cgm
>   for i in 
> $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcgmanager.so ; do \
>   dest=$$(readlink $$i) ; \
>   rm -f $$i ; \
>   ln -s /lib/$(DEB_HOST_MULTIARCH)/$$dest $$i ; \
>   done
> +
> +override_dh_install-arch:
>   dh_install
> + cp $(CURDIR)/debian/pam-cgm.config \
> + $(CURDIR)/debian/libpam-cgm/usr/share/pam-configs/cgm
>  
>  override_dh_installinit:
>   dh_systemd_enable -pcgmanager --name=cgmanager

Bug#820037: Copy detached module signatures into the initramfs

[Ben Hutchings]

Package: src:initramfs-tools
Version: 0.123
Severity: normal

We will probably implement module signing using detached signatures
which kmod will concatenate to the modules at load time (see #820010).
mkinitramfs will need to copy the detached signatures along with all
the modules it includes in the initramfs.

Ben.

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

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

Bug#820036: Debian does not run on systems with Secure Boot enabled

[Ben Hutchings]

Package: general
Severity: important

Most new desktop/laptop PCs cannot run Debian without the firmware
being reconfigured to disable Secure Boot.  This is a known problem
that is being worked on, but it hasn't so far been properly recorded
in the BTS.

This is a tracking bug which will be marked as blocked by more
specific bugs in the packages that need changes.  Please don't try to
'tidy it up' by reassigning it - this issue requires changes in many
packages and by several teams.

Ben.

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

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

Bug#820035: RFP: nudoku -- nudoku is a ncurses based sudoku game

[Alf Gaida]

Package: wnpp
Severity: wishlist

* Package name: nudoku
  Version : 0.2.4
  Upstream Author : Michael Vetter 
* URL : http
* License : GPL3+
  Programming Lang: C
  Description : nudoku is a ncurses based sudoku game

nudoku is a ncurses based sudoku game. Perfect to relax a little or just
waste some time when you are on the console.

I plan to maintain nudoku.

Bug#819883: debootstrap: please make the build reproducible

[Reiner Herrmann]

Hi KiBi,

On Mon, Apr 04, 2016 at 11:11:26PM +0200, Cyril Brulebois wrote:
> I'm not sure it's reasonable to introduce a versioned build-dep on tar
> at this point: 1.28 is only available in sid and stretch, and we tend to
> backport debootstrap semi-regularly to stable.
> 
> Is there any chance we could detect which tar version/features we have,
> and only add --sort=name when it's fine to do so?

I attached a different patch, which isn't as nice, but works also with
older tar versions.

Regards,
  Reiner
diff --git a/Makefile b/Makefile
index 1020cbc..e317eb0 100644
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,7 @@ devices.tar.gz:
 	chown 0:0 dev
 	chmod 755 dev
 	(cd dev && $(MAKEDEV) std ptmx fd consoleonly)
-	tar --mtime="$(DATE)" -cf - dev | gzip -9n >devices.tar.gz
+	find dev -print0 | LC_ALL=C sort -z | tar --mtime="$(DATE)" --no-recursion --null -T - -cf - | gzip -9n >devices.tar.gz
 	@if [ "$$(tar tvf devices.tar.gz | wc -l)" -lt 2 ]; then \
 		echo " ** devices.tar.gz is empty!" >&2; \
 		exit 1; \


signature.asc
Description: PGP signature

Bug#818407: fixed in unixodbc 2.3.1-4.1

[Steve Langasek]

On Mon, Apr 04, 2016 at 10:24:28PM +, John Paul Adrian Glaubitz wrote:
> Source: unixodbc
> Source-Version: 2.3.1-4.1

> We believe that the bug you reported is fixed in the latest version of
> unixodbc, 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 818...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.

> Debian distribution maintenance software
> pp.
> John Paul Adrian Glaubitz  (supplier of updated 
> unixodbc package)


>  unixodbc (2.3.1-4.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Use AC_CONFIG_MACRO_DIR([libltdl/m4]) in configure.in
>  instead of ACLOCAL_AMFLAGS=-I libltdl/m4 in Makefile.am
>  to add libltdl/m4 macro directory. Closes: #818407.

Ummm what?  What do you think you're doing?  Where is the NMU patch for
this, which in all cases must be sent to the BTS *before* you upload?  And
since when is a 0-day NMU for a two-week-old FTBFS that doesn't previously
have a patch attached appropriate?

Cc:ing debian-devel, since you apparently think a short-term FTBFS bug in
this package rises to the level of a project-wide discussion.

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


signature.asc
Description: Digital signature

Bug#819950: [patch] Allow opera to access ~/.opera/ too

[Reiner Herrmann]

On Tue, Apr 05, 2016 at 12:00:24AM +0200, Petter Reinholdtsen wrote:
> Very good.  Btw, paste of URLs into the opera browser window seem to be
> broken when I run opera in firejail.  Any idea why?  What can I do to
> figure out what is being blocked?

You could try running firejail with --tracelog.
When the process tries to access a blacklisted file, this will be logged
to syslog.


signature.asc
Description: Digital signature

Bug#820034: nmu: nmh_1.6-9

[Andreas Beckmann]

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

nmu nmh_1.6-9 . amd64 . unstable . -m "Rebuild in a clean environment."

The maintainer uploaded binaries were built against an old version of
openssl.


Andreas

Bug#820033: libwine: Make libwine.so.1 public

[Javier Serrano Polo]

Package: libwine
Version: 1.8.1-2
Severity: normal
Control: block 763720 by -1

Please make libwine.so.1 available under /usr/lib/i386-linux-gnu again.
It is needed by an executable in lmms.


smime.p7s
Description: S/MIME cryptographic signature

Bug#807351: (no subject)

[Barry Warsaw]

I just ran across this bug too, but not until I worked out a different
patch. ;)

I'd be fine with Neil's patch, or deleting the test entirely.  In the
attached, I only assert that the SystemError is raised, but not what the
exception message is.

The other change is to close a small (possibly only theoretical) hole which
could leak the temporary file.  Ideally, this should probably use a
with-statement and tempfile.NamedTemporaryFile.
diff --git a/tests/test_deb822.py b/tests/test_deb822.py
index 698366b..33c569d 100755
--- a/tests/test_deb822.py
+++ b/tests/test_deb822.py
@@ -911,16 +911,17 @@ Description: python modules to work with Debian-related data formats
 
 See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750247#35
 """
-fd, filename = tempfile.mkstemp()
-fp = os.fdopen(fd, 'wb')
-fp.write(UNPARSED_PARAGRAPHS_WITH_COMMENTS.encode('utf-8'))
-fp.close()
-
 try:
+fd, filename = tempfile.mkstemp()
+fp = os.fdopen(fd, 'wb')
+fp.write(UNPARSED_PARAGRAPHS_WITH_COMMENTS.encode('utf-8'))
+fp.close()
+
 with open_utf8(filename) as fh:
-paragraphs = list(deb822.Deb822.iter_paragraphs(
-fh, use_apt_pkg=True))
-self.assertEqual(paragraphs[0]['Build-Depends'], 'debhelper,')
+self.assertRaises(SystemError,
+  list,
+  deb822.Deb822.iter_paragraphs(
+  fh, use_apt_pkg=True))
 finally:
 os.remove(filename)
 

Bug#819944: [patch] Backport firejail to Jessie

[Reiner Herrmann]

Hi Petter,

> Do you have any plans to provide firejail in the Debian backports repo?

thanks for the compatibility patch for the Jessie kernel and the
suggestion to provide firejail as a backport.
I will prepare a backport in the upcoming days.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#819950: [patch] Allow opera to access ~/.opera/ too

[Petter Reinholdtsen]

[Reiner Herrmann]
> Hi Petter,
>
> thanks for the report and the patch!

No worries.  I hope to provide more as I gain experience with firejail.

> I've adapted your patch to the profile in firejail trunk and submitted
> it upstream.  It will probably be included in the upcoming upstream
> release.

Very good.  Btw, paste of URLs into the opera browser window seem to be
broken when I run opera in firejail.  Any idea why?  What can I do to
figure out what is being blocked?

-- 
Happy hacking
Petter Reinholdtsen

Bug#820015: [Pkg-samba-maint] Bug#820015: Bug#820015: Samba breaks with talloc 2.1.6

[Jelmer Vernooij]

On Tue, Apr 05, 2016 at 09:45:15AM +1200, Andrew Bartlett wrote:
> On Tue, 2016-04-05 at 09:36 +1200, Andrew Bartlett wrote:
> > On Mon, 2016-04-04 at 21:15 +, Jelmer Vernooij wrote:
> > > On Tue, Apr 05, 2016 at 07:32:10AM +1200, Andrew Bartlett wrote:
> > > > Package: samba
> > > > Version: 2:4.3.6+dfsg-1
> > > > 
> > > > Samba will not provision if the new talloc 2.1.6 is packaged and
> > > > installed, due to a type mixup that is now checked for in the
> > > > improved
> > > > python-talloc bindings.
> > > > 
> > > > The patches for this are already upstream in Samba 4.4 and
> > > > accepted
> > > > for
> > > > Samba 4.3:
> > > > https://bugzilla.samba.org/show_bug.cgi?id=11789
> > > > 
> > > > The error, during provision or dbcheck is:
> > > > 
> > > > ERROR(runtime): uncaught exception - pytalloc_reference_ex()
> > > > called
> > > > for
> > > > object type not based on talloc
> > > > 
> > > > We need those patches, and a Breaks statement in talloc (both in
> > > > my
> > > > proposed packages).
> > > I uploaded talloc before I saw this bug. I don't see the addition
> > > of
> > > a
> > > "Breaks:" in your packaging. Can you add it?
> > 
> > Sorry, I only did that late last night:
> > 
> > https://git.samba.org/abartlet/talloc-debian.git/?p=abartlet/talloc-d
> > ebian.git;a=commitdiff;h=c234170a36f43f0ab20faae3506dde2e53b704ba
> 
> BTW, it means we need to release the new samba 4.3 package Mathieu did
> otherwise there won't be an installable combination in unstable.
Yes, I'm working on this at the moment. Note that it is perfectly
valid and somewhat common that people only run some packages (such as
talloc) out of experimental, but the rest out of unstable

> (I was going to keep this to experimental for the moment so as not to
> break existing Samba, but fixing Samba is just as good an option).
We should really add the Breaks and fix Samba at the same time,
otherwise people can inadvertently end up with a combination that is
broken (samba from unstable, talloc from experimental)

Jelmer



signature.asc
Description: PGP signature

Bug#820032: bibledit-gtk: please make the build reproducible (environment)

[Alexis Bienvenüe]

Source: bibledit-gtk
Version: 4.9-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that 'bibledit-gtk' could not be built reproducibly.

That comes from the inclusion of the Makefile's used for building into
the package. These files seem however not necessary: please consider
removing them from bibledit-gtk-data, for example  with the attached patch.

Regards,
Alexis Bienvenüe.

 [1]: https://wiki.debian.org/ReproducibleBuilds


diff -Nru bibledit-gtk-4.9/debian/rules bibledit-gtk-4.9/debian/rules
--- bibledit-gtk-4.9/debian/rules	2015-09-15 21:29:23.0 +0200
+++ bibledit-gtk-4.9/debian/rules	2016-04-04 23:18:27.0 +0200
@@ -2,4 +2,6 @@
 %:
 	dh $@ --with autoreconf
 
+override_dh_install:
+	dh_install -XMakefile
 

Bug#819804: RFS: opengm/2.3.6+20160131-2

[Ghislain Vaillant]

On 04/04/16 22:06, Mattia Rizzolo wrote:

control: tag -1 moreinfo
control: owner -1 !

On Sat, Apr 02, 2016 at 02:22:16PM +0100, Ghislain Vaillant wrote:

I am looking for a sponsor for my package "opengm"


sure thing :)


   https://anonscm.debian.org/git/debian-science/packages/opengm.git


this one's good.

A thing: you close no bugs with this uploads, though your changelog says
it'll fix FTBFS, and you have as much as 3 different FTBFS bug report
opens.  Of those, I think you could at least take the chance of closing
one manually because is not current anymore and another should probably
be closed with this upload.

Please clarify this situation.


#806381 *should* be closed as a result of the fix, but I did not
explicitly list it in the changelog because I can't be sure 100%.

Indeed, I should watch the state of the builders after the upload and
close the said bug manually if appropriate.

Ghis

Bug#820015: [Pkg-samba-maint] Bug#820015: Bug#820015: Samba breaks with talloc 2.1.6

[Jelmer Vernooij]

On Tue, Apr 05, 2016 at 09:36:39AM +1200, Andrew Bartlett wrote:
> On Mon, 2016-04-04 at 21:15 +, Jelmer Vernooij wrote:
> > On Tue, Apr 05, 2016 at 07:32:10AM +1200, Andrew Bartlett wrote:
> > > Package: samba
> > > Version: 2:4.3.6+dfsg-1
> > > 
> > > Samba will not provision if the new talloc 2.1.6 is packaged and
> > > installed, due to a type mixup that is now checked for in the
> > > improved
> > > python-talloc bindings.
> > > 
> > > The patches for this are already upstream in Samba 4.4 and accepted
> > > for
> > > Samba 4.3:
> > > https://bugzilla.samba.org/show_bug.cgi?id=11789
> > > 
> > > The error, during provision or dbcheck is:
> > > 
> > > ERROR(runtime): uncaught exception - pytalloc_reference_ex() called
> > > for
> > > object type not based on talloc
> > > 
> > > We need those patches, and a Breaks statement in talloc (both in my
> > > proposed packages).
> > I uploaded talloc before I saw this bug. I don't see the addition of
> > a
> > "Breaks:" in your packaging. Can you add it?
> 
> Sorry, I only did that late last night:
> 
> https://git.samba.org/abartlet/talloc-debian.git/?p=abartlet/talloc-debian.git;a=commitdiff;h=c234170a36f43f0ab20faae3506dde2e53b704ba
Doesn't this break python-samba rather than samba-common-bin?

Jelmer


signature.asc
Description: PGP signature

Bug#820015: [Pkg-samba-maint] Bug#820015: Bug#820015: Samba breaks with talloc 2.1.6

[Jelmer Vernooij]

On Tue, Apr 05, 2016 at 09:36:39AM +1200, Andrew Bartlett wrote:
> On Mon, 2016-04-04 at 21:15 +, Jelmer Vernooij wrote:
> > On Tue, Apr 05, 2016 at 07:32:10AM +1200, Andrew Bartlett wrote:
> > > Package: samba
> > > Version: 2:4.3.6+dfsg-1
> > > 
> > > Samba will not provision if the new talloc 2.1.6 is packaged and
> > > installed, due to a type mixup that is now checked for in the
> > > improved
> > > python-talloc bindings.
> > > 
> > > The patches for this are already upstream in Samba 4.4 and accepted
> > > for
> > > Samba 4.3:
> > > https://bugzilla.samba.org/show_bug.cgi?id=11789
> > > 
> > > The error, during provision or dbcheck is:
> > > 
> > > ERROR(runtime): uncaught exception - pytalloc_reference_ex() called
> > > for
> > > object type not based on talloc
> > > 
> > > We need those patches, and a Breaks statement in talloc (both in my
> > > proposed packages).
> > I uploaded talloc before I saw this bug. I don't see the addition of
> > a
> > "Breaks:" in your packaging. Can you add it?
> 
> Sorry, I only did that late last night:
> 
> https://git.samba.org/abartlet/talloc-debian.git/?p=abartlet/talloc-debian.git;a=commitdiff;h=c234170a36f43f0ab20faae3506dde2e53b704ba

Ahh, that commit is only in experimental - not master.

Jelmer


signature.asc
Description: PGP signature

Bug#819969: libjpeg9: CVE-2016-3616: null pointer dereference in cjpeg

[Bill Allombert]

On Mon, Apr 04, 2016 at 02:35:03PM +0200, Salvatore Bonaccorso wrote:
> Source: libjpeg9
> Version: 1:9b-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for libjpeg9. The issue
> is in the cjpeg utility.
> 
> CVE-2016-3616[0]:
> null pointer dereference in cjpeg
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

Hello Salvatore,

Upstream has confirmed that only cjpeg is affected, and so
only libjpeg-progs and not the binary package libjpeg9.

Thanks for your report!
-- 
Bill. 

Imagine a large red swirl here. 

Bug#820015: [Pkg-samba-maint] Bug#820015: Samba breaks with talloc 2.1.6

[Andrew Bartlett]

On Tue, 2016-04-05 at 09:36 +1200, Andrew Bartlett wrote:
> On Mon, 2016-04-04 at 21:15 +, Jelmer Vernooij wrote:
> > On Tue, Apr 05, 2016 at 07:32:10AM +1200, Andrew Bartlett wrote:
> > > Package: samba
> > > Version: 2:4.3.6+dfsg-1
> > > 
> > > Samba will not provision if the new talloc 2.1.6 is packaged and
> > > installed, due to a type mixup that is now checked for in the
> > > improved
> > > python-talloc bindings.
> > > 
> > > The patches for this are already upstream in Samba 4.4 and
> > > accepted
> > > for
> > > Samba 4.3:
> > > https://bugzilla.samba.org/show_bug.cgi?id=11789
> > > 
> > > The error, during provision or dbcheck is:
> > > 
> > > ERROR(runtime): uncaught exception - pytalloc_reference_ex()
> > > called
> > > for
> > > object type not based on talloc
> > > 
> > > We need those patches, and a Breaks statement in talloc (both in
> > > my
> > > proposed packages).
> > I uploaded talloc before I saw this bug. I don't see the addition
> > of
> > a
> > "Breaks:" in your packaging. Can you add it?
> 
> Sorry, I only did that late last night:
> 
> https://git.samba.org/abartlet/talloc-debian.git/?p=abartlet/talloc-d
> ebian.git;a=commitdiff;h=c234170a36f43f0ab20faae3506dde2e53b704ba

BTW, it means we need to release the new samba 4.3 package Mathieu did
otherwise there won't be an installable combination in unstable.

(I was going to keep this to experimental for the moment so as not to
break existing Samba, but fixing Samba is just as good an option).

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba

Bug#819950: [patch] Allow opera to access ~/.opera/ too

[Reiner Herrmann]

Control: tags -1 + upstream
Control: forwarded -1 https://github.com/netblue30/firejail/pull/409

Hi Petter,

thanks for the report and the patch!
I've adapted your patch to the profile in firejail trunk and
submitted it upstream.
It will probably be included in the upcoming upstream release.

King regards,
  Reiner


signature.asc
Description: PGP signature

Bug#816563: libjava-gmsh2: fails to upgrade from 'jessie' - trying to overwrite /usr/lib/i386-linux-gnu/libjava-gmsh.so

[Andreas Beckmann]

Followup-For: Bug #816563
Control: found -1 2.12.0+dfsg1-1

Hi,

>-Breaks: gmsh (<< 2.6.0.dfsg-3)
>-Replaces: gmsh (<< 2.6.0.dfsg-3)
>+Breaks: libgmsh-dev (<< 2.8.5)
>+Replaces: libgmsh-dev (<< 2.8.5)

That B+R version is insufficient, you'll need (<< 2.9.3) instead.


Andreas

Bug#819985: gap-dev: unusable headers (missing config.h)

[Julien Cristau]

On Mon, Apr  4, 2016 at 21:13:30 +0200, Bill Allombert wrote:

> On Mon, Apr 04, 2016 at 06:07:30PM +0200, Julien Cristau wrote:
> > On Mon, Apr  4, 2016 at 17:55:40 +0200, Bill Allombert wrote:
> > 
> > > On Mon, Apr 04, 2016 at 05:11:01PM +0200, Julien Cristau wrote:
> > > > Package: gap-dev
> > > > Version: 4r7p9-1
> > > > Severity: serious
> > > > 
> > > > $ echo '#include ' | cpp 
> > > > # 1 ""
> > > > # 1 ""
> > > > # 1 ""
> > > > # 1 "/usr/include/stdc-predef.h" 1 3 4
> > > > # 1 "" 2
> > > > # 1 ""
> > > > # 1 "/usr/include/gap/system.h" 1 3 4
> > > > In file included from :1:0:
> > > > /usr/include/gap/system.h:29:20: fatal error: config.h: No such file or 
> > > > directory
> > > > compilation terminated.
> > > > 
> > > > config.h seems to be shipped in /usr/include/x86_64-linux-gnu/gap, but
> > > > #include "config.h"
> > > > doesn't work...
> > > 
> > > Hello Julien,
> > > 
> > > I agree, but do you have actual code that include  ?
> > > 
> > I was trying to build 
> > http://git.sagemath.org/sage.git/tree/src/sage/libs/gap/gap_includes.pxd
> 
> Well I will fix this bug obviously, but I cannot promise that this will
> allow you to compile this, because gap is not a library and the header
> file are only provided for the gac compiler (which is not affected by
> this issue). In particular gap does not ship gap/libgap.h.
> 
Yeah, this was just the first part of my troubles.  The lack of libgap
is going to be more of a problem :)

Cheers,
Julien

Bug#819985: gap-dev: unusable headers (missing config.h)

[Bill Allombert]

On Mon, Apr 04, 2016 at 06:07:30PM +0200, Julien Cristau wrote:
> On Mon, Apr  4, 2016 at 17:55:40 +0200, Bill Allombert wrote:
> 
> > On Mon, Apr 04, 2016 at 05:11:01PM +0200, Julien Cristau wrote:
> > > Package: gap-dev
> > > Version: 4r7p9-1
> > > Severity: serious
> > > 
> > > $ echo '#include ' | cpp 
> > > # 1 ""
> > > # 1 ""
> > > # 1 ""
> > > # 1 "/usr/include/stdc-predef.h" 1 3 4
> > > # 1 "" 2
> > > # 1 ""
> > > # 1 "/usr/include/gap/system.h" 1 3 4
> > > In file included from :1:0:
> > > /usr/include/gap/system.h:29:20: fatal error: config.h: No such file or 
> > > directory
> > > compilation terminated.
> > > 
> > > config.h seems to be shipped in /usr/include/x86_64-linux-gnu/gap, but
> > > #include "config.h"
> > > doesn't work...
> > 
> > Hello Julien,
> > 
> > I agree, but do you have actual code that include  ?
> > 
> I was trying to build 
> http://git.sagemath.org/sage.git/tree/src/sage/libs/gap/gap_includes.pxd

Well I will fix this bug obviously, but I cannot promise that this will
allow you to compile this, because gap is not a library and the header
file are only provided for the gac compiler (which is not affected by
this issue). In particular gap does not ship gap/libgap.h.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#817548: [NMU/Patch] Re: Bug#817548: libromana-perligata-perl: Removal of debhelper compat 4

[Axel Beckert]

Control: tag -1 + patch pending

Hi Erinn,

ni...@thykier.net wrote:
> The package libromana-perligata-perl uses debhelper with a compat level of 4,
> which is deprecated and scheduled for removal.
> 
>  * Please bump the debhelper compat at your earliest convenience.
>on the 15th of June.
>- Compat 9 is recommended
>- Compat 5 is the bare minimum

Today I was sitting in the talk "Fun with Dead Languages" by the
upstream developer of this module. He mentioned it in the talk. While
looking for the according Debian package I noticed this bug report and
prepared an NMU while he still was giving the talk. :-)

Please see the following patch. I've just uploaded an NMU with that
patch to DELAYED/10. Feel free to tell me if I should fast-forward the
upload or delay it longer.

diff -u libromana-perligata-perl-0.55/debian/changelog 
libromana-perligata-perl-0.55/debian/changelog
--- libromana-perligata-perl-0.55/debian/changelog
+++ libromana-perligata-perl-0.55/debian/changelog
@@ -1,3 +1,16 @@
+libromana-perligata-perl (0.55-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload during Damian Conway's "Fun with Dead Languages"
+talk at FHNW -- which mentioned this Perl module. :-)
+  * Bump debhelper compatibility to 9. (Closes: #817548)
++ Update versioned debhelper build-dependency accordingly.
++ Replace "dh_clean -k" with "dh_prep".
++ Add dependency on ${misc:Depends}.
+  * Fix lintian warning debian-rules-missing-recommended-target to avoid a
+similar FTBFS in the future.
+
+ -- Axel Beckert   Mon, 04 Apr 2016 19:32:14 +0200
+
 libromana-perligata-perl (0.55-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libromana-perligata-perl-0.55/debian/compat 
libromana-perligata-perl-0.55/debian/compat
--- libromana-perligata-perl-0.55/debian/compat
+++ libromana-perligata-perl-0.55/debian/compat
@@ -1 +1 @@
-4
+9
diff -u libromana-perligata-perl-0.55/debian/control 
libromana-perligata-perl-0.55/debian/control
--- libromana-perligata-perl-0.55/debian/control
+++ libromana-perligata-perl-0.55/debian/control
@@ -1,14 +1,14 @@
 Source: libromana-perligata-perl 
 Section: perl
 Priority: extra 
-Build-Depends: debhelper (>= 4.0.2), perl (>= 5.8.0-7)
+Build-Depends: debhelper (>= 9), perl (>= 5.8.0-7)
 Maintainer: Erinn Clark  
 Standards-Version: 3.6.1
 
 Package: libromana-perligata-perl 
 Section: perl
 Architecture: all
-Depends: perl (>= 5.8.0-7), libfilter-perl
+Depends: perl (>= 5.8.0-7), libfilter-perl, ${misc:Depends}
 Description: perl module for writing in Latin
  Using Filters, the Lingua::Romana::Perligata module makes it 
  possible to write Perl programs in Latin. 
diff -u libromana-perligata-perl-0.55/debian/rules 
libromana-perligata-perl-0.55/debian/rules
--- libromana-perligata-perl-0.55/debian/rules
+++ libromana-perligata-perl-0.55/debian/rules
@@ -4,7 +4,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-build: build-stamp
+build: build-arch build-indep
+build-arch:
+build-indep: build-stamp
 build-stamp:
dh_testdir
 
@@ -24,7 +26,7 @@
 install: build
dh_testdir
dh_testroot
-   dh_clean -k
+   dh_prep
dh_installdirs
 
$(MAKE) install DESTDIR=$(CURDIR)/debian/libromana-perligata-perl
@@ -54 +56 @@
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build clean binary-indep binary-arch binary install build-arch 
build-indep

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


signature.asc
Description: Digital signature

Bug#820015: [Pkg-samba-maint] Bug#820015: Samba breaks with talloc 2.1.6

[Andrew Bartlett]

On Mon, 2016-04-04 at 21:15 +, Jelmer Vernooij wrote:
> On Tue, Apr 05, 2016 at 07:32:10AM +1200, Andrew Bartlett wrote:
> > Package: samba
> > Version: 2:4.3.6+dfsg-1
> > 
> > Samba will not provision if the new talloc 2.1.6 is packaged and
> > installed, due to a type mixup that is now checked for in the
> > improved
> > python-talloc bindings.
> > 
> > The patches for this are already upstream in Samba 4.4 and accepted
> > for
> > Samba 4.3:
> > https://bugzilla.samba.org/show_bug.cgi?id=11789
> > 
> > The error, during provision or dbcheck is:
> > 
> > ERROR(runtime): uncaught exception - pytalloc_reference_ex() called
> > for
> > object type not based on talloc
> > 
> > We need those patches, and a Breaks statement in talloc (both in my
> > proposed packages).
> I uploaded talloc before I saw this bug. I don't see the addition of
> a
> "Breaks:" in your packaging. Can you add it?

Sorry, I only did that late last night:

https://git.samba.org/abartlet/talloc-debian.git/?p=abartlet/talloc-debian.git;a=commitdiff;h=c234170a36f43f0ab20faae3506dde2e53b704ba

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sat, Apr 02, 2016 at 05:08:23AM -0300, Tiago Ilieve wrote:
> I've updated the package to the version "1.1.0" which the upstream
> kindly released after integrating my patch fixing some issues with
> tests under Python 3.
> 
> It was uploaded to mentors.d.n[1] as well.

I usually prefer using git to do my stuff, though here a simple clone is
not enough:

mattia@chase ~/devel/RFS/python-path-and-address % git clone 
https://anonscm.debian.org/git/collab-maint/python-path-and-address.git
Cloning into 'python-path-and-address'...
remote: Counting objects: 119, done.
remote: Compressing objects: 100% (110/110), done.
remote: Total 119 (delta 44), reused 0 (delta 0)
Receiving objects: 100% (119/119), 27.69 KiB | 0 bytes/s, done.
Resolving deltas: 100% (44/44), done.
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

you seems to use debian/unstable as main packaging branch, so please set
HEAD in a way a simple 'git clone' just works.

Also, your git repository seems to lack a pristine-tar branch, which is
basically needed to get the same tarball that is in the archive.

* debian/patches:
  + empty, please remove the directory
* debian/changelog:
  + be more precise: that's the Expat license


I'll look also at the rdep of this once through with this.
Note: fixing on git is enough, I'm very much fine doing everything
with git.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#819986: ITP: resolv-wrapper -- A wrapper for DNS name resolving or DNS faking

[Laszlo Boszormenyi (GCS)]

retitle 819986 ITP: resolv-wrapper -- A wrapper for DNS name resolving or DNS 
faking
owner 819986 !
thanks

Package is ready, uploading soon.

Bug#819831: [Pkg-rust-maintainers] Bug#819831: cargo: FTBFS: unable to satisfy build-depends

[Luca BRUNO]

On Saturday, April 02, 2016 11:05:05 PM Santiago Vila wrote:

> and in fact this may not be solved by hand, because:
> 
> * Installing libgit2-dev removes libcurl4-openssl-dev.
> * Installing libcurl4-openssl-dev removes libgit2-dev.

This seems to be due to libgit2-dev moving to gnutls, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798421

> Sorry not to have a fix, but certainly this is RC for stretch, as
> packages in testing should be buildable in testing.

I think we may align cargo on that and just build with libcurl4-gnutls-dev 
instead. Upstream prefers building with libcurl+openssl,
but I guess switching to gnutls shouldn't cause any issue here.

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG: 0xBB1A3A854F3BBEBF
  `- http://www.debian.org  | Debian GNU/Linux Developer


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

Bug#820015: [Pkg-samba-maint] Bug#820015: Samba breaks with talloc 2.1.6

[Jelmer Vernooij]

On Tue, Apr 05, 2016 at 07:32:10AM +1200, Andrew Bartlett wrote:
> Package: samba
> Version: 2:4.3.6+dfsg-1
> 
> Samba will not provision if the new talloc 2.1.6 is packaged and
> installed, due to a type mixup that is now checked for in the improved
> python-talloc bindings.
> 
> The patches for this are already upstream in Samba 4.4 and accepted for
> Samba 4.3:
> https://bugzilla.samba.org/show_bug.cgi?id=11789
> 
> The error, during provision or dbcheck is:
> 
> ERROR(runtime): uncaught exception - pytalloc_reference_ex() called for
> object type not based on talloc
> 
> We need those patches, and a Breaks statement in talloc (both in my
> proposed packages).
I uploaded talloc before I saw this bug. I don't see the addition of a
"Breaks:" in your packaging. Can you add it?

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#819883: debootstrap: please make the build reproducible

[Cyril Brulebois]

Hi,

Reiner Herrmann  (2016-04-03):
> Source: debootstrap
> Version: 1.0.80
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: fileordering
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi!
> 
> While working on the "reproducible builds" effort [1], we have noticed
> that debootstrap could not be built reproducibly.
> The devices.tar.gz tarball contains devices in unsorted (readdir) order.
> 
> The attached patch fixes this by telling tar to sort the archive
> members.
> 
> Regards,
>  Reiner
> 
> [1]: https://wiki.debian.org/ReproducibleBuilds

> diff --git a/Makefile b/Makefile
> index 1020cbc..07682bc 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -36,7 +36,7 @@ devices.tar.gz:
>   chown 0:0 dev
>   chmod 755 dev
>   (cd dev && $(MAKEDEV) std ptmx fd consoleonly)
> - tar --mtime="$(DATE)" -cf - dev | gzip -9n >devices.tar.gz
> + tar --sort=name --mtime="$(DATE)" -cf - dev | gzip -9n >devices.tar.gz
>   @if [ "$$(tar tvf devices.tar.gz | wc -l)" -lt 2 ]; then \
>   echo " ** devices.tar.gz is empty!" >&2; \
>   exit 1; \
> diff --git a/debian/control b/debian/control
> index 46e2b93..40cfbcd 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -3,7 +3,7 @@ Section: admin
>  Priority: extra
>  Maintainer: Debian Install System Team 
>  Uploaders: Junichi Uekawa , Colin Watson 
> , Christian Perrier , Steve McIntyre 
> <93...@debian.org>
> -Build-Depends: debhelper (>= 9), makedev (>= 2.3.1-69) [linux-any]
> +Build-Depends: debhelper (>= 9), makedev (>= 2.3.1-69) [linux-any], tar (>= 
> 1.28)
>  Standards-Version: 3.9.6
>  Vcs-Browser: https://anonscm.debian.org/cgit/d-i/debootstrap.git
>  Vcs-Git: https://anonscm.debian.org/git/d-i/debootstrap.git

Thanks for the patch.

I'm not sure it's reasonable to introduce a versioned build-dep on tar
at this point: 1.28 is only available in sid and stretch, and we tend to
backport debootstrap semi-regularly to stable.

Is there any chance we could detect which tar version/features we have,
and only add --sort=name when it's fine to do so?


KiBi.


signature.asc
Description: Digital signature

Bug#820031: kpartx: broken maintainer scripts prevent package removal

[Andreas Beckmann]

Package: kpartx
Version: 0.5.0+git1.656f8865-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + lava-server

Hi,

during a test with piuparts I noticed your package fails to remove.

>From the attached log (scroll to the bottom...):

  Removing kpartx (0.5.0+git1.656f8865-8) ...
  preinst called with unknown argument `remove'
  dpkg: error processing package kpartx (--remove):
   subprocess installed pre-removal script returned error exit status 1


cheers,

Andreas


lava-server_2016.3.post1-1.log.gz
Description: application/gzip

Bug#820030: Debian 8: Spanish accents doesn't work

[Javier Zzzz]

Package: language-pack-es




 Version: Debian GNU/Linux 8.3 (jessie). Linux version 3.16.0-4-amd64 
(debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) 
#1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17).

I have checked:

1)locale:
LANG=es_ES.utf8
LANGUAGE=es_ES.utf8
LC_CTYPE="es_ES.utf8"
LC_NUMERIC="es_ES.utf8"
LC_TIME="es_ES.utf8"
LC_COLLATE="es_ES.utf8"
LC_MONETARY="es_ES.utf8"
LC_MESSAGES="es_ES.utf8"
LC_PAPER="es_ES.utf8"
LC_NAME="es_ES.utf8"
LC_ADDRESS="es_ES.utf8"
LC_TELEPHONE="es_ES.utf8"
LC_MEASUREMENT="es_ES.utf8"
LC_IDENTIFICATION="es_ES.utf8"

2) ñ character works fine.

3)localectl:
System Locale: LANGUAGE=es_ES.utf8
        VC Keymap: n/a
      X11 Layout: es
        X11 Model: pc105

Everithing seeems Ok but accents still don't work. Example: ´a´e. I have 
this problems since I uninstalled debian 7.9 to install 8 version.

Any idea?

Regards
Xavi
Spain



   

  

Bug#819804: RFS: opengm/2.3.6+20160131-2

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sat, Apr 02, 2016 at 02:22:16PM +0100, Ghislain Vaillant wrote:
> I am looking for a sponsor for my package "opengm"

sure thing :)

>   https://anonscm.debian.org/git/debian-science/packages/opengm.git

this one's good.

A thing: you close no bugs with this uploads, though your changelog says
it'll fix FTBFS, and you have as much as 3 different FTBFS bug report
opens.  Of those, I think you could at least take the chance of closing
one manually because is not current anymore and another should probably
be closed with this upload.

Please clarify this situation.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#820010: Add support for detached module signatures (.sig extension)

[Marco d'Itri]

On Apr 04, Ben Hutchings  wrote:

> without sacrificing reproducibility or duplicating files.  It
> has *not* been submitted upstream, but I can do that if you
> prefer.  I have also not tested the gzip and xz cases.
Please do: it is intrusive enough that I do not really want to forward 
port it forever, and you can better argue about its value.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "grip"

* Package name: grip
  Version : 4.1.0-1
  Upstream Author : Joe Esposito 
* URL : https://github.com/joeyespo/grip
* License : MIT
  Section : utils

It builds those binary packages:

grip  - Preview GitHub Markdown files like Readme locally

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

http://mentors.debian.net/package/grip

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

dget -x http://mentors.debian.net/debian/pool/main/g/grip/grip_4.1.0-1.dsc

-

This package depends on "python-path-and-address" (RFS #819773[1]), which is
not on the archive yet. It would be awesome if the sponsor could help me with
both RFS bugs.

Tests are commented out in "debian/rules" because they depend on a newer
version of "python-responses". I've filled a bug (#820020[2]) which is now
pending (thanks Ondrej Novy!). This can be fixed as soon as the updated package
hits unstable.

Decisions made about packaging layout (Python application vs. Python library)
have been clarified on the "debian-python" mailing list[3].

I also would like to thanks Gustavo Panizzo, who gave me permission[4] to take
over his ITP.

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819773
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820020
[3]: https://lists.debian.org/debian-python/2016/04/msg00017.html
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611#17

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819703: Easiest patch?

[Santiago Vila]

On Mon, Apr 04, 2016 at 02:33:39PM -0700, Jamil Said Jr. wrote:
> I have not looked at the code, but this approach seems to me to have the
> smaller change possible and still completely solve the issue:
> 
> At some point the code will compare the date of the version with the value
> that it has stored (I believe 18 months), and complain if the version is
> older. Why don't just change the value store to compare from 18 months to
> 180 months or so?

Look at the code. Even if you are not a programmer, it's easy to understand:

http://sources.debian.net/src/xscreensaver/5.30-1/driver/prefs.c/?hl=1739#L1739

Instead of "months > 18" you can just put "0", which is always false.

This would be equivalent to using an infinite amount of time in your example.

But this is not even necessary because you can just put a "return 0;"
as the very first line in the senescent_p function.

So yes, you are right that this annoying warning may be removed by
changing or adding a single line, a very small change indeed.

The "only" problem is that the author does not want anybody to do that
(read the comments at the beginning of the function).

Thanks.