Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Tags: -1 + patch

Bug#749288: raspbian support patch provided is too complicated for me to port to libv8 3.28

[Peter Green]

i'm working on updating libv8 to 3.28 (see collab-maint), and unfortunately
this patch
isn't obvious at all to adapt to that new version.
Where exactly should I be looking? When I look at 
https://alioth.debian.org/scm/browser.php?group_id=30755 I see a tag for 
upstream 3.28 but no tags or heads for debian packaging of 3.28.

Bug#807239: lftp: can no longer connect with sftp (no matching host key type found)

[Vincent Lefevre]

On 2015-12-08 20:33:27 -0800, Russ Allbery wrote:
> I think Colin is still working on making sure this change is visible
> enough to everyone it affects, but see the changelog in openssh-client:
> 
> - Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by
>   default at run-time.  These may be re-enabled using the instructions
>   at http://www.openssh.com/legacy.html

I actually saw this page after googling the error message (not very
easy because with lftp, the error message disappears very quickly,
the part about ssh-dss isn't even visible with a 80-column terminal).

This should have been put at least in the NEWS.Debian file.

> It sounds like the remote host to which you're trying to connect only
> offers ssh-dss keys, which are no longer supported by default (following
> upstream) because they're not very secure.

This from is a SSH server for Android (and the user doesn't seem
to have a choice for the type of the host key).

> This is unrelated to host key checking or IP checking.  It's about the
> type of underlying crypto being used to secure the connection.

According to what is documented, this appears to be related to
host key checking: the error mesage is "no matching *host key*
type found" and the option name is HostKeyAlgorithms. In what
way it could be insecure in the case where the user doesn't have
the key in the ~/.ssh/known_hosts file?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#807473: Potential data loss and security breach when used with nfs server

[Nick Koretsky]

Package: r8168-dkms
Version: 8.040.00-1
Severity: critical


When this driver is used on the machine which acts as nfs server you can
mount shares, filesystem looks ok, but attempt to read any file produces
random garbage (i suspect parts of the server memory). Writing to files
works - this is a source for data loss, because a lot of programs will
attempt to override "incorrect" files. 
I am 100% sure this is caused by this driver: rmmod r8168 insmod r8169
corrects this, rmmod r8169 insmod r8168 brings it back.

Kernel 4.2.0-0.bpo.1-686-pae, libc6 2.19-18+deb8u1, gcc 4.9.2-10K
Hardware is Asustek M4A785TD motherboard's build in RTL8112L chip.


lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] RS780 Host Bridge
00:01.0 PCI bridge: ASUSTeK Computer Inc. AMD RS780/RS880 PCI to PCI bridge
(int gfx)
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI to
PCI bridge (PCIE port 0)
00:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI to
PCI bridge (PCIE port 5)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB
OHCI1 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB
OHCI1 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus
Controller (rev 3c)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 IDE Controller
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia
(Intel HDA)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 LPC host controller
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI
Bridge
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h
Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h
Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h
Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h
Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h
Processor Link Control
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RS780L [Radeon 3000]
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
03:00.0 RAID bus controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid
II Controller (rev 01)
04:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)

  


-- 
  Nick Koretsky (nick.koret...@gmail.com)
  

Bug#780706: Request for Arduino IDE 1.6.1 package

[Willem van den Akker]

Any progress on this.

Arduino-mk is already on 1.5.

Greetings.
Willem

Bug#807461: lintian: check years in debian/copyright are not in the future

[Jakub Wilk]

* Paul Wise , 2015-12-09, 11:45:
I found a git commit in one of the d-i packages that fixed the 
copyright year, changing it from 2103 to 2013. This wasn't in 
debian/copyright but it would be great if lintian could catch such 
typos in debian/copyright.


Heh, I found these:

https://sources.debian.net/src/jenkins-debian-glue/0.15.2/debian/copyright/?hl=19
https://sources.debian.net/src/ocaml-frei0r/0.1.0-3/debian/copyright/?hl=8

--
Jakub Wilk

Bug#749288: raspbian support patch provided is too complicated for me to port to libv8 3.28

[Jérémy Lal]

2015-12-09 10:02 GMT+01:00 Peter Green :

>
>> i'm working on updating libv8 to 3.28 (see collab-maint), and
>> unfortunately
>> this patch
>> isn't obvious at all to adapt to that new version.
>>
> Where exactly should I be looking? When I look at
> https://alioth.debian.org/scm/browser.php?group_id=30755 I see a tag for
> upstream 3.28 but no tags or heads for debian packaging of 3.28.
>

Hello !

I stopped updating v8 for a while, waiting to see which version was going
to be used
for nodejs Long Term Support (4.2.x) branch, which embeds v8 4.5.
Now i think the simplest thing to do is to take advantage of the LTS of
nodejs
to distribute that version of v8, to avoid a non-upstream-maintained
version in debian.

Is there something else raspbian need besides arm fpu/cpu config ?
If not, next nodejs (4.2 or even 5.2) upload should build and run fine.
(not the current one because of the wrong -mfpu=vfpv2 option), and
next month i'll upload libv8-4.5.

Regards,
Jérémy.

Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Tags: -1 patch

On Wed, Dec 09, 2015 at 09:17:52AM +0100, Hendrik Brueckner wrote:
> 
> Patch will provided separately.

Attached.
diff -Nru s390-tools-1.32.0/debian/changelog s390-tools-1.32.0/debian/changelog
--- s390-tools-1.32.0/debian/changelog  2015-10-25 17:12:02.0 +0100
+++ s390-tools-1.32.0/debian/changelog  2015-12-09 09:32:50.0 +0100
@@ -1,3 +1,12 @@
+s390-tools (1.32.0-2) UNRELEASED; urgency=medium
+
+  * Install the device-mapper helper for zipl and chreipl to boot from and
+prepare an underlying disk device of a mapped device for IPL.  This
+applies to linear mapped devices, for example, multipath devies or LVM.
+(Closes: #807470)
+
+ -- Hendrik Brueckner   Wed, 02 Dec 2015 
14:54:09 +0100
+
 s390-tools (1.32.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
s390-tools-1.32.0/debian/s390-tools.install
--- s390-tools-1.32.0/debian/s390-tools.install 2014-07-26 23:59:18.0 
+0200
+++ s390-tools-1.32.0/debian/s390-tools.install 2015-12-02 14:59:19.0 
+0100
@@ -19,6 +19,7 @@
 /usr/sbin/lsreipl
 /usr/sbin/chshut
 /usr/sbin/lsshut
+/lib/s390-tools/chreipl_helper.device-mapper
 /usr/share/man/man8/chreipl.8
 /usr/share/man/man8/lsreipl.8
 /usr/share/man/man8/chshut.8
@@ -88,6 +89,7 @@
 
 # zipl
 /sbin/zipl
+/lib/s390-tools/zipl_helper.device-mapper
 /usr/share/man/man5/zipl.conf.5
 /usr/share/man/man8/zipl.8
 

Bug#746511: sasl2-bin: saslauthd leaks memory using PAM

[Michael Stockenhuber]

Package: libpam-mysql
Version: 0.7~RC1-4+b3
Followup-For: Bug #746511

Dear Maintainer,
This bug has resurfaced. I have to restart saslauthd every week or so because 
authentication fails. extract from /var/log/auth.log

pam_mysql - pam_mysql_check_passwd() returning 6.
saslauthd[21211]: pam_mysql - pam_mysql_sql_log() called.
saslauthd[21211]: pam_mysql - pam_mysql_sql_log() returning 0.
saslauthd[21211]: pam_mysql - pam_sm_authenticate() returning 7.
legolas saslauthd[21211]: DEBUG: auth_pam: pam_authenticate failed: 
Authentication failure
saslauthd[21211]: pam_mysql - pam_mysql_release_ctx() called.
saslauthd[21211]: pam_mysql - pam_mysql_destroy_ctx() called.
legolas saslauthd[21211]: pam_mysql - pam_mysql_close_db() called.
saslauthd[21211]: do_auth : auth failure: [user=xxx] [service=imap] 
[realm=] [mech=pam] [reason=PAM auth error]


Tested with tessaslauthd:

testsaslauthd -s imap -u -p 

gives:

0: NO "authentication failed"


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

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

Versions of packages libpam-mysql depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u1
ii  libmysqlclient18   5.5.46-0+deb8u1
ii  libpam0g   1.1.8-3.1

libpam-mysql recommends no packages.

libpam-mysql suggests no packages.

-- Configuration Files:
/etc/pam-mysql.conf [Errno 13] Permission denied: u'/etc/pam-mysql.conf'

-- debconf information:
  pam-mysql/config_file_noread: true

Bug#807475: glance: please make the build reproducible

[Chris Lamb]

Source: glance
Version: 1:11.0.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that
glance could not be built reproducibly.

The attached patch prevents the build system from persisting the number
of CPUs that are present to the sample configuration. This doesn't
actually affect the default performance as the line is commented out, so
the *runtime* environment detects the number of CPUs anyway.

Once applied, glance can be built reproducibly using our reproducible
toolchain.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2015-12-09 11:22:38.015365966 +0200
--- b/debian/rules  2015-12-09 11:31:25.844854835 +0200
@@ -55,6 +55,7 @@
sed -i 's/^[ \t#]*auth_protocol[ \t]*=[ \t].*/auth_protocol = http/' 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-api.conf
sed -i 's|^[ \t#]*filesystem_store_datadir[ \t]*=[ 
\t].*|filesystem_store_datadir = /var/lib/glance/images|' 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-api.conf
sed -i 's|^[ \t#]*lock_path[ \t]*=[ \t].*|lock_path = 
/var/lock/glance|' 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-api.conf
+   sed -i 's|^[ \t#]*workers[ \t]*=[ \t].*|#workers = 2|' 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-api.conf
 
PYTHONPATH=. oslo-config-generator --output-file 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-registry.conf \
--namespace glance.registry \
@@ -68,6 +69,7 @@
--namespace oslo.log
sed -i 's/^[ \t#]*auth_protocol[ \t]*=[ \t].*/auth_protocol = http/' 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-registry.conf
sed -i 's|^[ \t#]*filesystem_store_datadir[ \t]*=[ 
\t].*|filesystem_store_datadir = /var/lib/glance/images|' 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-registry.conf
+   sed -i 's|^[ \t#]*workers[ \t]*=[ \t].*|#workers = 2|' 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-registry.conf
 
PYTHONPATH=. oslo-config-generator --output-file 
$(CURDIR)/debian/glance-common/usr/share/glance-common/glance-cache.conf \
--namespace glance.cache \

Bug#807476: snmpd: BTRFS support missing in hrFSTable

[Mathieu Parent (Debian)]

Package: snmpd
Version: 5.7.2.1+dfsg-1
Severity: normal

Dear Maintainer,

BTRFS mountpoints are not listed from snmpwalk.

The upstream patch for this is:
http://sourceforge.net/p/net-snmp/code/ci/2659c0f6bd86f0171869d34ff8a7d48194ea4b31/

I think this deserves a fix in jessie as this worked in wheezy.

I can work on this if you want.

Regards

Mathieu Parent

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

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

Versions of packages snmpd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u1
ii  libsnmp-base   5.7.2.1+dfsg-1
ii  libsnmp30  5.7.2.1+dfsg-1
ii  lsb-base   4.1+Debian13+nmu1

snmpd recommends no packages.

Versions of packages snmpd suggests:
pn  snmptrapd  

-- Configuration Files:
/etc/default/snmpd changed [not included]
/etc/snmp/snmpd.conf [Errno 13] Permission denied: u'/etc/snmp/snmpd.conf'
/etc/snmp/snmptrapd.conf a2ee110581a5a9a1e2252400cb176bcc [Errno 2] No
such file or directory: u'/etc/snmp/snmptrapd.conf
a2ee110581a5a9a1e2252400cb176bcc'

-- debconf information excluded

Bug#807437: maven: mvn dependency:tree fail with "Error injecting:"

[Emmanuel Bourg]

Hi Tomas,

Thank you for reporting this issue, I have been able to reproduce it.
This is caused by an incompatibility between the dependency plugin 2.7
and Maven 3.3. You can work around this issue by forcing the use of a
more recent version of the plugin (2.8 or later):

mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:tree

To fix this we have to cancel the modification of the super pom
downgrading the version of the dependency plugin from 2.8 to 2.7:

http://anonscm.debian.org/cgit/pkg-java/maven.git/tree/debian/patches/plugins_version.diff?h=debian/3.3.9-2#n233

Emmanuel Bourg

Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Package: s390-tools
Version: 1.32.0-1
Severity: normal
Tags:

Please include the chreipl and zipl device mapper helper to prepare and
boot from linear mapped devices, for example, LVM.

Patch will provided separately.


Kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen

Bug#807328: flashblock doesn't work with 38.4.0 iceweacel

[Michal Hocko]

On Mon, Dec 07, 2015 at 02:37:26PM +0100, Michal Hocko wrote:
> Package: xul-ext-flashblock
> Version: 1.5.19-1
> Severity: grave
> 
> Hi,
> the current version of the flashblock installed from the debian package
> doesn't work with the current version of Iceweasel installed from the
> security repository:
> iceweasel:amd64/stable 38.4.0esr-1~deb8u1 uptodate
> 
> No flash content is blocked but it is loaded automatically instead. I
> have checked the plugin upstream [1] and there is a remark about 38.4.0
> not being supported: "Not available for Firefox 38.4.0"
> 
> I have tried to reinstall the previous version [2] and this one still
> works fine. I have no idea why the newer version doesn't work but maybe
> the debian package should be reverted back to 1.5.18?
> 
> [1] https://addons.mozilla.org/en-US/firefox/addon/flashblock/
> [2]
> https://addons.mozilla.org/en-US/firefox/addon/flashblock/versions/?page=1#version-1.5.18.1-signed

https://addons.mozilla.org/en-US/firefox/addon/flashblock/versions/?page=1#version-1.5.20

JFYI works properly
-- 
Michal Hocko

Bug#807472: libboinc7: undefined symbol generate_signature(char*, char*, R_RSA_PRIVATE_KEY&)

[Thorsten Glaser]

Package: libboinc7
Version: 7.6.20+dfsg-2
Severity: normal
User: debian...@lists.debian.org
Usertags: adequate undefined-symbol

adequate reports:

libboinc7:x32: undefined-symbol /usr/lib/x86_64-linux-gnux32/libsched.so.7.6.20 
=> _Z18generate_signaturePcS_R17R_RSA_PRIVATE_KEY

The most likely cause is underlinking, i.e. you forget one -lfoo
when linking libboinc7.so.*


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

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

Versions of packages libboinc7 depends on:
ii  libc6 2.21-3
ii  libgcc1   1:5.3.1-3
ii  libmysqlclient18  5.6.27-2
ii  libssl1.0.2   1.0.2e-1
ii  libstdc++65.3.1-3
ii  zlib1g1:1.2.8.dfsg-2+b1

libboinc7 recommends no packages.

libboinc7 suggests no packages.

-- no debconf information

Bug#807478: razor: FTBFS with perl 5.22 in experimental (MakeMaker changes)

[Dominic Hargreaves]

Source: razor
Version: 1:2.85-4.1
Severity: serious
Justification: transition imminent
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition makemaker-prefix
Tags: sid stretch

This package FTBFS with perl 5.22.0-2, which removed support for a long-
obsolete way of overriding PREFIX when calling 'make install' with
ExtUtils::MakeMaker, as described in the lintian tag
debian-rules-makemaker-prefix-is-deprecated[1] and the Debian Perl
policy[2]:


ERROR: Can't create '/usr/bin'
Do not have write permissions on '/usr/bin'

 at -e line 1.
Makefile:945: recipe for target 'pure_vendor_install' failed

The fix is to use DESTDIR instead of PREFIX; please see the lintian
`description for examples. Alternatively, newer versions of debhelper
can automatically call make install with the correct arguments when
using the dh7 style rules files.

The perl 5.22 is due to start this week, so apologies for the late
submission of this bug; for some reason my previous testing of this
issue overlooked this package.

Cheers,
Dominic.

[1] 

[2] 

Bug#807479: fpc: missing AArch64 patch in 3.0.0+dfsg-1

[Jonas Maebe]

Package: fpc
Version: 3.0.0+dfsg-1

Hi,

Upstream svn trunk r32102 (or the equivalent r32130 from  
branches/fixes_3_0_ios) should be included in add-arm64-support.patch.  
This fix was committed between the release of FPC 3.0.0rc1 and 3.0.0rc2.



Jonas
(FPC developer and author of that patch)

Bug#807471: [kde-config-telepathy-accounts] Jabber configuration unusable

[Luc Bégault]

Package: kde-config-telepathy-accounts
Version: 15.08.2-1
Severity: normal

--- Please enter the report below this line. ---
When configuring a jabber account in telepathy, I can't access to Server 
Settings, Connection Settings, Resource or Security Settings.

Regards,
Luc Begault.

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.3.0-trunk-amd64

Debian Release: stretch/sid
  500 unstableftp.fr.debian.org
  500 testing ftp.fr.debian.org
  500 sid linux.dropbox.com
1 experimentalftp.fr.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/09/2015 03:39 AM, Milan Kupcevic wrote:
> The module in question gets loaded and is used in D-I only. Pay 
> attention to the case you are pointing at: the graphics does not
> work on boot/reboot into an installed system. At this point this
> module plays no role because it is blacklisted in the main system.
> This user is having some other issues unrelated to this module.

Did you actually check that it is blacklisted after installation?

radeon KMS worked fine on every PPC Mac hardware that I tested. However,
I always ran into exactly this issue when radeonfb was loaded, even when
it was unloaded later. Apparently, radeonfb sets the GPU in a state from
which the radeon KMS module cannot recover it.

My Mac Mini G4 is currently packed up because I am moving soon. But I
will re-test this at some point because I am pretty sure this is again
radeonfb messing with the GPU as the symptoms are the same.

Adrian

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

iQIcBAEBCAAGBQJWZ/h2AAoJEHQmOzf1tfkTG5QP/3fIYZCRl+V3MbpWoXjivBU/
Njgwtsjh67Z/vouM9eT50U2Jc3Db/6a8rtWb3cwuYfES+36fxxK3HiExr5/aRwzo
19gBbkCweYGDErZLoc0OnY7UZT1Fk0FcNfU4FdC4edMtrb63dYsQAhxFbI8NVfba
tJTH1pJi5MqLx03rzcPKl97/4OKFTP4b1+54nojZaXYnQG7pmFsK1Amx4nM4xqAJ
5uxbJ/q/ViEGqgLE8xso9471mKyTYm3+FI8kcxq83XNEqf9WDilRBcQgPvIkwfvW
lB5ALaKpd3fjb2yOM2557W857hMuzD7+i0jW23P5ieKcb0hxc3HVOJKLCTNDrYDR
inknkx/ZoOGhzHQC1sr4e8AHsT6Tp1dQLK0fyuGKasa2FKHeqN4eueYZImO2QFpG
Ir/xoYYVXZPWyAS0xGH3sddn9WsP7tvOphChgPyi5VBMoaaJqq2CBupdUTLarc9/
cZeU4jPYZo7seRtCKcdTPibm0V+keInzUC5PNoVb2lDD20kWSlDpaeCHcVp+yp8s
Y1ZwFUtaPYjGljz6ei23+0v+VIei2fhGyzpLkQ8xJjQt2/XsGaWT0eD9CAsNPocC
C/nWxruTt8+RUg9Wg/fO9K8X1cNCh/HfU9wNtMid74ski9prxZNG+xxFgOOfzxo1
2UEz9Xkajsesb8+nZTaA
=21XG
-END PGP SIGNATURE-

Bug#807318: libmpich-dev: should add Depends: to match hard-wired gcc dependency in mpicxx.h

[peter green]

/usr/include/mpich/mpicxx.h has a hardwired dependency on the gcc used
to build mpich (gcc 5.2):

#ifdef __GNUC__
# if __GNUC__>= 5
#  if __GNUC_MINOR__>  2&&  2 == 2
#  error 'Please use the same version of GCC and g++ for compiling MPICH and 
user MPI programs'
#  endif
# endif
#endif

But the current gcc (on s390x) is 5.3.  So an error is thrown when
building client programs (cf. Bug#803477), making mpich mostly
unusable on this architecture.
   
I wonder if this logic needs to be changed since gcc changed it's 
version numbering. As I understand it with 5.x and up the second digit 
is being used in the way the third digit used to be used.

Bug#807442: patch

[Hendrik Brueckner]

Hi Dann,

On Tue, Dec 08, 2015 at 03:17:49PM -0700, dann frazier wrote:
> Attached.

> diff -Nru s390-tools-1.32.0/debian/changelog 
> s390-tools-1.32.0/debian/changelog
> --- s390-tools-1.32.0/debian/changelog2015-10-25 17:12:02.0 
> +0100
> +++ s390-tools-1.32.0/debian/changelog2015-12-08 23:14:52.0 
> +0100
> @@ -1,3 +1,9 @@
> +s390-tools (1.32.0-2) UNRELEASED; urgency=medium
> +
> +  * Add dbginfo.sh. (Closes: #807442)
> +
> + -- dann frazier   Tue, 08 Dec 2015 22:33:52 +0100
> +
>  s390-tools (1.32.0-1) unstable; urgency=medium
> 
>* New upstream release
> diff -Nru s390-tools-1.32.0/debian/s390-tools.install 
> s390-tools-1.32.0/debian/s390-tools.install
> --- s390-tools-1.32.0/debian/s390-tools.install   2014-07-26 
> 23:59:18.0 +0200
> +++ s390-tools-1.32.0/debian/s390-tools.install   2015-12-08 
> 23:08:30.0 +0100
> @@ -10,6 +10,10 @@
>  /sbin/dasdview
>  /usr/share/man/man8/dasdview.8
> 
> +# dbginfo.sh
> +/sbin/dbginfo.sh
> +/usr/share/man/man1/dbginfo.sh.1
> +
>  # fdasd
>  /sbin/fdasd
>  /usr/share/man/man8/fdasd.8

Thanks for submitting this patch and the lsluns patch as well.  I am about to
open another bug to include the device-mapper helper for zipl and chreipl as
well.  They are required for booting from device-mapper devices, for example,
LVM, multipath.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Bug#807474: libfile-rsyncp-perl: FTBFS with perl 5.22 in experimental (MakeMaker changes)

[Dominic Hargreaves]

Source: libfile-rsyncp-perl
Version: 0.74-2
Severity: serious
Justification: transition imminent
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition makemaker-prefix
Tags: sid stretch

This package FTBFS with perl 5.22.0-2, which removed support for a long-
obsolete way of overriding PREFIX when calling 'make install' with
ExtUtils::MakeMaker, as described in the lintian tag
debian-rules-makemaker-prefix-is-deprecated[1] and the Debian Perl
policy[2]:


ERROR: Can't create '/usr/lib/x86_64-linux-gnu/perl5/5.22/File'
mkdir /usr/lib/x86_64-linux-gnu/perl5/5.22/File: Permission denied at 
/usr/share/perl/5.22/ExtUtils/Install.pm line 477.


 at -e line 1.
make[1]: *** [pure_vendor_install] Error 13

The fix is to use DESTDIR instead of PREFIX; please see the lintian
`description for examples. Alternatively, newer versions of debhelper
can automatically call make install with the correct arguments when
using the dh7 style rules files.

The perl 5.22 is due to start this week, so apologies for the late
submission of this bug; for some reason my previous testing of this
issue overlooked this package.

Cheers,
Dominic.

[1] 

[2] 

Bug#799041: Updated rules for isc-dhcp-server.

[Thibaut Cheze]

Hi,

The same for /isc-dhcp-client/ (dhclient).

Regards,
--- logcheck-1.3.17/rulefiles/linux/ignore.d.server/dhclient	2014-10-24 23:59:23.0 +0200
+++ logcheck-1.3.17-patched/rulefiles/linux/ignore.d.server/dhclient	2015-12-09 00:09:49.479146665 +0100
@@ -1,26 +1,26 @@
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: Internet (Software|Systems) Consortium DHCP Client [.[:alnum:]-]+$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: Copyright [-0-9]+ Internet Systems Consortium\.$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: All rights reserved\.$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: For info, please visit http(://www\.isc\.org/(products/DHCP|sw/dhcp/)|s://www\.isc\.org/software/dhcp/)$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: There is already a pid file /var/run/dhclient\.[[:alnum:]]+\.pid with pid [[:digit:]]+$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: killed old client process, removed PID file$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?:$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: Listening on [^[:space:].]+$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: Sending on[[:space:]]+[^[:space:]]+$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: DHCPDISCOVER on [[:alnum:].-]+ to [.0-9]{7,15} port 67 interval [0-9]+$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: DHCP(NAK|ACK|OFFER) (of [.0-9]{7,15} )?from [.0-9]{7,15}$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: DHCP(REQUEST|RELEASE) (of [.0-9]{7,15} )?on [[:alnum:].-]+ to [.0-9]{7,15} port 67$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: bound(:| to [.0-9]{7,15} --) renewal in [0-9]+ seconds\.$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: [[:lower:]]+[0-9]: unknown hardware address type [0-9]+$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: Trying recorded lease [.0-9]{7,15}$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: No working leases in persistent database( - sleeping)?\.$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: send_packet: Network is unreachable$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: send_packet: please consult README file regarding broadcast address\.$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: Internet (Software|Systems) Consortium DHCP Client [.[:alnum:]-]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: Copyright [-0-9]+ Internet Systems Consortium\.$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: All rights reserved\.$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: For info, please visit http(://www\.isc\.org/(products/DHCP|sw/dhcp/)|s://www\.isc\.org/software/dhcp/)$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: There is already a pid file /var/run/dhclient\.[[:alnum:]]+\.pid with pid [[:digit:]]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: killed old client process, removed PID file$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?:$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: Listening on [^[:space:].]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: Sending on[[:space:]]+[^[:space:]]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: DHCPDISCOVER on [[:alnum:].-]+ to [.0-9]{7,15} port 67 interval [0-9]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: DHCP(NAK|ACK|OFFER) (of [.0-9]{7,15} )?from [.0-9]{7,15}$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: DHCP(REQUEST|RELEASE) (of [.0-9]{7,15} )?on [[:alnum:].-]+ to [.0-9]{7,15} port 67$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: bound(:| to [.0-9]{7,15} --) renewal in [0-9]+ seconds\.$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: [[:lower:]]+[0-9]: unknown hardware address type [0-9]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: Trying recorded lease [.0-9]{7,15}$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: No working leases in persistent database( - sleeping)?\.$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: send_packet: Network is unreachable$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x|\[[[:digit:]]+\])?: send_packet: please consult README file regarding broadcast address\.$
 # dhcp-client 2.0
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: Copyright (199[5-9],? ){5}(The )?Internet Software Consortium\.$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: Please contribute if you find this software useful\.$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: For info, please visit http://www.isc.org/dhcp-contrib.html$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient(-2.2.x)?: No DHCPOFFERS received\.$
-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ 

Bug#798005: Allow disabling Add-on signing in IceWeasel 44+

[Alexander Schlarb]

Mozilla has postponed this change to Firefox 44+. Will IceWeasel follow 
enforce strict add-on signing??? Can the "developer edition"-style enforcement 
(using the "xpinstall.signatures.required" preference) be retained?

Yours,
Alexander Schlarb

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

Bug#807477: apt: autoclean depends on /var/cache/apt/archives/partial existing

[Michał Klichowicz]

Package: apt
Version: 1.1.4
Severity: normal

Dear Maintainer,

On a system with /var/cache/apt/archives mounted as tmpfs, after 1.0.10.2 -> 
1.1.3
update (but persisting in 1.1.4), `apt-get autoclean` fails with:

E: Unable to read /var/cache/apt/archives/partial/ - opendir (2: No such file
or directory)

This causes aptitude with "Remove obsolete package files after downloading
new package lists" option enabled to throw an error after package list
update, until manual creation of said directory.

I found two past, resolved bugs which may be similar to the issue: #523920
#762898

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/6 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 apt depends on:
ii  adduser 3.113+nmu3
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.19-6
ii  gnupg2  2.0.28-3
ii  gpgv1.4.19-6
ii  libapt-pkg5.0   1.1.4
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-23
ii  libstdc++6  5.2.1-23

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.7.4-2
ii  dpkg-dev1.18.3
ii  python-apt  1.1.0~beta1

-- no debconf information

Bug#643997: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict resolution

[Manuel A. Fernandez Montecelo]

2015-12-07 16:50 ydir...@free.fr:



Are you using R and A to accept or reject individual package
solutions?  That should help in this case, to avoid repeatedly
getting
suggestions that you don't want to accept.


Yes I do.  But I still have to individually refuse all "upgrade" and
"keep" suggestions, which all come with higher priority than the very
downgrade I had requested.  The typical case is that of a machine running
on "testing" (or even on "stable"), with sources.list entries for "unstable",
"experimental", (or "backports", "security" etc for "stable" boxes), etc to
facilitate targeted installation of newer versions when they are needed.


[...]
There are already some bugs/requests already complaining that users
actions can lead to downgrades or installing versions in experimental
"almost inadvertently" even when the user also requested those
actions
and insisting that they should have a high severity... so by making
the feature more accessible in aptitude I can only foresee more of
those reports.


Sure, but that may need to be balanced with the occasional need to
downgrade to avoid a blocking bug that inadvertently entered testing,
or just to check which package upgrade causes a bug to submit a
useful bugreport.

And I must say, I don't remember having been bitten by any downgrade,
at least recently.  Possibly because the bulk of what I downgrade is
libs, which are probably much less subject to downgrade problems
(although that's just a side-effect of how functionality is implemented
in various software)


As you say above, it is a matter of trade-offs and balances.

In hundreds of bugs still open in aptitude, only a couple of them that I
just fixed (the ones about "not downgrading even when pinning > 1000")
and this one are about *wanting* to downgrade.  There are a few other
bugs complaining about downgrades even being suggested as a solution,
after tweaking the default costs of the resolver [1] -- and suggestions
that are clearly advertised as downgrades and that one can reject
anyway.

There are no mentions about downgrades in the change log of aptitude
between 2007 and 2015, and then in 2007 is only to forbid them in
safe-upgrade and making them more visible, then in 2005 and
2004... etc... always in the direction of making the downgrades more
noticeable and less likely to happen, never to facilitate them.


Downgrading is possible, even if laborious sometimes.  They are
laborious among other reasons because rev-depends always keep increasing
the version required of their dependencies, so downgrading will always
involve the same or more changes in other packages than upgrades, and
the resolver will always be happier to suggest other actions rather than
downgrades -- as it should be.

The recently added fix of 0.7.5 should help in the cases when there are
many packages wanting to be downgraded to the same suite (e.g. testing
from unstable, or unstable from external repositories).  Maybe you can
try to see if it helps when it becomes too laborious to pick solutions
one by one.


The simple fact is that for the moment I am quite scared of changing the
current behaviour of the resolver of aptitude, and maybe creating a
bigger mess of it than what it currently is.

I don't believe that helping to do downgrades is a powerful reason worth
risking further breakage by tweaking the resolver -- not at this point
or in the near future anyway.


[1] That's another thing that some people use to improve suggestions of
   the resolver, I never use them by default and very rarely played
   with them though:

   http://aptitude.alioth.debian.org/doc/en/ch02s03s04.html


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#807270: mk-origtargz: create reproducible tarballs and --mtime option

[Osamu Aoki]

Hi,

On Mon, Dec 07, 2015 at 08:07:53PM +0100, Hans-Christoph Steiner wrote:
> 
> 
> Osamu Aoki:
> > Hi,
> > 
> > Second thought ...
> > 
> > uscan/mk-origtargz/uupdate is not run during the binary package building
> > process.  Does the reproducible build aims to create source package in
> > reproducible way?
> > 
> > If reproducible build is aiming for binary build reproducibility,
> > changing behavior of uscan/mk-origtargz/uupdate has no impact.
> 
> We want to have the whole process able to be inspected, including the
> process of making the source tarballs.  But yes, binary reproducibility
> is more important.  In this case, it is pretty easy to make reproducible
> source tarballs, so I think its worth doing.

Please also remember that reproducing upstream content including the
file time stamp is important factor.

> > On Mon, Dec 07, 2015 at 10:30:10PM +0900, Osamu Aoki wrote:
> > 
> >> On Sun, Dec 06, 2015 at 10:21:04PM +0100, Hans-Christoph Steiner wrote:
> > ...
> >>> Whenever mk-origtargz is repacking a zipball, it should zero out the
> >>> timestamps in the tar format so that the process produces the same
> >>> tarball every time it runs.
> > 
> > Why you need this?  unzip preserves file timestamps inside of zip
> > archive.  Am I right?  Is this something we need to do for repacking of
> > tar.gz?
> 
> I believe unzip will preserve the timestamps.

So why you wish to overwrite mtime?  Does the upstream release zipball
with different time stamp everytime user request to download?

Please be concrete on the needs with actual example package so we are
not expanding on fantasy.
 
> >>> This can be done using tar's --mtime= flag.
> > 
> > Yah, if it is needed.
> > 
> >>> Additionally, it would be very useful if mk-origtargz also had a --mtime
> >>> option which forced the tarball to be repacked using the date given to
> >>> the --mtime="Wed Oct 28 10:12:27 2015 -0700" flag.  Here's an example of
> >>> how to do that in perl:
> >>>
> >>> https://stackoverflow.com/a/16728218
> > 
> > Well ... it is simpler than this as long as we know what date to set.
> > Just run tar with --mtime option in the code with the reference file or
> > date string.
> 
> As long as mk-origtargz has an --mtime option, then we can use the most
> appropriate date.  For example, with Android SDK packages, we can get
> the git commit date of the release, since upstream does not post release
> tarballs, only git tags.  It is this use case that made me want
> mk-origtargz to support --mtime.

If we add features, we need to add infinite number of them unless there
is a strong case which makes addition useful.  Does android SDK zip ball
has rondom timestamp inside zipball?

Regards,

Osamu


> .hc

Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

[Aurelien Jarno]

On 2015-12-08 22:30, Jelle Haandrikman wrote:
> Hi Andreas,
> 
> On 2015-12-08 19:25, Andreas Beckmann wrote:
> >Hi Aurelien,
> >
> >... buggy software (#807244), which is only exposed by running on
> >hardware with working TSX-NI.
> >That could also explain the fact that the bug was introduced in 352+.
> >
> >Jelle, I didn't dig through the nvidia forums, but if this info isn't
> >mentioned there already, maybe you could post it:
> >
> >>According to the backtrace the problem is typical of a call to
> >>mutex_unlock() on a mutex which hasn't been locked with mutex_lock()
> >>before.
> >(or was already unlocked.)
> I'm not a member of any of any Nvidia forum. I'm more of an advanced
> Debian user, with a technical background as a tester. All the searches that
> I
> just did regarding mutex_unlock() and the driver point back to this post.
> 
> You really are doing the best anaylysis I had found. Unfortunately it's also
> the only one I can find.

As often this can be also found on the archlinux bug tracking system:

https://bugs.archlinux.org/task/46064?project=1

There is even a link to an ugly patch showing that the issue has been
understood. Finally according to the last post in this bug entry it
seems that nvidia is about to release fix.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#772943: [pkg-cryptsetup-devel] Bug#772943: Bug#772943: Bug#772943: cryptsetup: please soften cryptroot messages

[Jonas Meurer]

Hi Holger, hi debian-desktop,

Am 19.01.2015 um 14:27 schrieb Holger Levsen:
> On Montag, 19. Januar 2015, Jonas Meurer wrote:
>> Any progress on that bugreport in the meantime? 
> 
> nope, too busy with other stuff :/
> 
>> It seems like cryptsetup
>> will need another upload to jessie anyway. So if we've something ready
>> to enhance the cryptoroot message then we could try to push that into
>> jessie as well (after discussing with RMs).
> 
> sadly not, thanks for thinking about this issue..!

Now that Jessie is released, I ping you again regarding this issue. I'd
love to soften the disk unlocking prompt displayed by cryptsetup during
boot process. So did you (or the debian-desktop team) come up with an
alternative suggestion for the prompt yet?

At the moment, the prompt is as follows:

> cryptkey="Please unlock disk $diskname: "

where $diskname is:

> if [ ${cryptsource#/dev/disk/by-uuid/} != $cryptsource ]; then
> # UUIDs are not very helpful
> diskname="$crypttarget"
> else
> diskname="$cryptsource ($crypttarget)"
> fi

In other words, if $cryptsource starts with '/dev/disk/by-uuid/', then
$diskname contains only $crypttarget, otherwise it contains both
$cryptsource and $crypttarget.

$cryptsource is the source device name (e.g. /dev/sda1 or
/dev/debian-vg/root or
/dev/disk/by-uuid/b2629cd2-3565-48f6-910e-3ef091268491) and $crypttarget
is the target device name as specified in /etc/crypttab (usually
something like sda1_crypt).

Problem is, that both seem rather arbitrary to users who used the
automatic partitioning by debian-installer. My suggestion is to drop
$cryptsource completely and just display $crypttarget in the prompt.

Probably then we could improve the naming of $crypttarget in
partman(-crypto) code from debian-installer and use more descriptive
names like "system-disk"?

Any suggestions?

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#690701: Provide OS major/full version string

[Benjamin Drung]

On Tue, 16 Oct 2012 18:19:22 +0200 martin f krafft 
wrote:
> Would it be possible to provide a grain osversion and
> osversion_major, the second of which can be used for numeric
> comparisons?

salt 2015.8 provides these grains:

os:
Debian
os_family:
Debian
osarch:
amd64
oscodename:
Debian GNU/Linux 8 (jessie)
osfullname:
Debian GNU/Linux
osrelease:
8
osrelease_info:
- 8

Is that osrelease/osrelease_info enough or what do you expect?

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.

Bug#807344: gnome-panel: Wrong synopsis in man page

[Dmitry Shachnev]

Control: tags -1 fixed-upstream

Hi Tim,

On Mon, Dec 07, 2015 at 08:13:27PM +0100, Tim Dengel wrote:
> Package: gnome-panel
> Version: 3.18.1-1
> Severity: minor
>
> Dear Maintainer,
>
> I was reading the man page of the package when I noticed the synopsis says
> 'gnome-about [--replace]' instead of 'gnome-panel [--replace]'.
>
> That is all :)

Thanks for your report, we have now fixed this upstream [1]. The fix will land
in Debian when a new upstream release is out.

[1]: https://git.gnome.org/browse/gnome-panel/commit/?id=a0447c5e6cc54ac1

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#807484: uscan: Add example for archlinux site

[Osamu Aoki]

Package: devscripts
Version: 2.15.9
Severity: wishlist
User: devscri...@packages.debian.org
Usertags: uscan

If people wish to write watch file for archlinux upstream package, what
to do is non-trivial:

https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/archlinux-xdg-menu

  https://wiki.archlinux.org/index.php/Arch_User_Repository
  https://wiki.archlinux.org/index.php/Arch_Build_System
  https://projects.archlinux.org/svntogit/packages.git/
  https://projects.archlinux.org/svntogit/community.git/

Its cgit and seem to have snapshot tar available.  Complicated.

Anyway, I found URL:
https://www.archlinux.org/packages/community/any/archlinux-xdg-menu/

If we arart from here
 archlinux-xdg-menu 0.7.6.2-2

This gave me a hint how to write watch file

Let's start from the following page.

https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/archlinux-xdg-menu

This is a nice page to find out recent versions and if the latest version
is the one you know.  If newer version is identified to available, let's
download using the following URL

upgpkg:
 archlinux-xdg-menu 0.7.6.2-2

Hmmm.. either way, pagemangle is needed to pick version.  Then only the
latest version can be downloaded from

https://www.archlinux.org/packages/community/any/archlinux-xdg-menu/download/

Then rename tarball.

With downloadurlmangle and filenamemangle this is doable  along

version=4
opts="pagemangle=...,downloadurlmangle=...,filenamemangle=..." \
https://www.archlinux.org/packages/community/any/archlinux-xdg-menu/ \
archlinux-xdg-menu\s+([\-\d\.])

Ugly but OK.  If there is an easier URL to use for download for each
version, this can be made better.

Osamu

Bug#793187: arb: FTBFS with gcc 4.9.2+

[Andreas Beckmann]

Followup-For: Bug #793187

Hi Andreas,

do you plan to fix this issue for jessie, too? The next point release is
probably in January. Attached is a suggested backport to jessie.


Andreas
diff -Nru arb-6.0.2/debian/changelog arb-6.0.2/debian/changelog
--- arb-6.0.2/debian/changelog	2014-09-09 09:12:14.0 +0200
+++ arb-6.0.2/debian/changelog	2015-12-09 07:32:10.0 +0100
@@ -1,3 +1,14 @@
+arb (6.0.2-1+deb8u1) jessie; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+
+  [ Andreas Tille ]
+  * Skip compiler version check at all
+Closes: #793187
+
+ -- Andreas Beckmann   Wed, 09 Dec 2015 07:30:47 +0100
+
 arb (6.0.2-1) unstable; urgency=medium
 
   [ Andreas Tille ]
diff -Nru arb-6.0.2/debian/patches/70_skip_compler_version_check.patch arb-6.0.2/debian/patches/70_skip_compler_version_check.patch
--- arb-6.0.2/debian/patches/70_skip_compler_version_check.patch	1970-01-01 01:00:00.0 +0100
+++ arb-6.0.2/debian/patches/70_skip_compler_version_check.patch	2015-12-09 07:30:36.0 +0100
@@ -0,0 +1,32 @@
+Description: Skip compiler version check at all
+Author: Andreas Tille 
+Bug-Debian: http://bugs.debian.org/793187
+Last-Update: Wed, 22 Jul 2015 22:45:32 +0200
+
+--- a/Makefile
 b/Makefile
+@@ -736,23 +736,7 @@ check_same_GCC_VERSION:
+ 		$(ARBHOME)/SOURCE_TOOLS/check_same_compiler_version.pl $(COMPILER_NAME) $(COMPILER_VERSION_ALLOWED)
+ 
+ check_GCC_VERSION:
+-		@echo 'Compiler version check:'
+-ifeq ('$(COMPILER_VERSION_ALLOWED)', '')
+-		@echo "  - Your compiler is '$(COMPILER_NAME)' version '$(COMPILER_VERSION)'"
+-		@echo 'This version is not in the list of supported $(COMPILER_NAME)-versions:'
+-		@$(foreach version,$(ALLOWED_COMPILER_VERSIONS),echo '* $(version)';)
+-		@echo '  - You may either ..'
+-		@echo '- add your version to ALLOWED_$(COMPILER_NAME)_VERSIONS in the Makefile and try it out or'
+-		@echo '- switch to one of the allowed versions (see arb_README_gcc.txt for installing'
+-		@echo '  a different version of gcc)'
+-		@echo ''
+-		@false
+-else
+-		@echo "  - Supported $(COMPILER_NAME) version '$(COMPILER_VERSION_ALLOWED)' detected - fine!"
+-		@echo ''
+-		$(MAKE) check_same_GCC_VERSION
+-
+-endif
++		@echo 'Skip compiler version check in Debian - we need to fix the code if it does not work'
+ 
+ #-- check ARBHOME
+ 
diff -Nru arb-6.0.2/debian/patches/series arb-6.0.2/debian/patches/series
--- arb-6.0.2/debian/patches/series	2014-09-07 22:38:14.0 +0200
+++ arb-6.0.2/debian/patches/series	2015-12-09 07:30:36.0 +0100
@@ -4,3 +4,4 @@
 40_upstream_r12815__lintian_spelling
 50_private_nameservers
 60_use_packaged_phyml
+70_skip_compler_version_check.patch

Bug#807487: pbuilder update in sid breaks pbuilder on (old)stable

[Holger Levsen]

package: pbuilder
version: 0.221.2
severity: grave

Hi Mattia,

from #debian-qa:

 | anybody knows why sid is broken as in 
https://reproducible.debian.net/rbuild/unstable/armhf/pianobar_2015.11.22-1.rbuild.log
 ?
 | tail: cannot open 'debian/changelog' for reading: No such file or 
directory
 | dpkg-buildpackage: error: tail of debian/changelog gave error exit 
status 1
 That's bizarre.
 | jwilk: yup. and we only see it for sid, not for testing, so it has 
to be some change in sid…
 Is it only armhf?
 | no. also amd64
 cd /build/*/ # you sure there's nothing else in there?
 I do so a mention of /build/.gnupg a few lines up which, of course, 
should not expand by default..
 | its created by pbuilder… as this happens inside the chroot created 
by it 
 | but 
 | only pbuilder in sid has been updated
 | not on the host
 | but we had such a bug before
 | pbuilder-0.221.2/pbuilder-buildpackage:DPKG_COMMANDLINE="cd 
${BUILDDIR}/*/ && $DPKG_COMMANDLINE"
 | lamby: so thats from pbuilder indeed
 | i dont grok how pbuilder in sid effects building using pbuilder in 
stable, but i think the pbuilder upgrade is the cause 
 | and fwiw, i can reproduce it here, using pbuilder 0.213 on wheezy ;-p

IOW: when trying to build packages for sid on this oldstable system using
pbuilder 0.213 I see the exact same behaviour as in 
https://reproducible.debian.net/rbuild/unstable/armhf/pianobar_2015.11.22-1.rbuild.log
which is:

I: Building the package
I: Running cd tmp/buildd/*/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" 
dpkg-buildpacka
tail: cannot open 'debian/changelog' for reading: No such file or directory
dpkg-buildpackage: error: tail of debian/changelog gave error exit status 1
E: Failed autobuilding of package

As shown on reproducible.debian.net this doesn't effect building for testing.


cheers,
Holger


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

Bug#807486: ITP: INDELible -- A powerful and flexible simulator of biological evolution

[Fabian Klötzl]

Package: wnpp
Severity: wishlist
Owner: "Debian Med Team" 

* Package name: INDELible
  Version : 1.03
  Upstream Author : William Fletcher
* URL : http://abacus.gene.ucl.ac.uk/software/indelible/
* License : GPL
  Programming Lang: C++
  Description : A powerful and flexible simulator of biological evolution

INDELible is a new, portable, and flexible application for biological
sequence simulation that combines many features in the same place for
the first time. Using a length-dependent model of indel formation it
can simulate evolution of multi-partitioned nucleotide, amino-acid,
or codon data sets through the processes of insertion, deletion, and
substitution in continuous time.
..
Nucleotide simulations may use the general unrestricted model or the
general time reversible model and its derivatives, and amino-acid
simulations can be conducted using fifteen different empirical rate
matrices. Substitution rate heterogeneity can be modelled via the
continuous and discrete gamma distributions, with or without a proportion
of invariant sites. INDELible can also simulate under non-homogenous
and non-stationary conditions where evolutionary models are permitted
to change across a phylogeny.
..
Unique among indel simulation programs, INDELible offers the ability to
simulate using codon models that exhibit nonsynonymous/synonymous rate
ratio heterogeneity among sites and/or lineages.


This package will be maintained as part of the Debian Med packaging team.

Bug#807488: sbuild-update: please run -d with --no-install-recommends

[Adam Borowski]

Package: sbuild
Version: 0.66.0-5
Severity: wishlist

Hi!
As per apt's defaults, whenever a package that's a part of the sbuild chroot
gains a new Recommends:, that recommendation will be installed.  This
default makes sense for regular apt uses outside of sbuild, but in sbuild's
context, it goes against the aim of a minimal chroot.  It'll allow missing
build-dependencies to sneak through unnoticed, and makes fresh chroots
differ from updated ones.

Thus, please make sbuild-update pass --no-install-recommends to apt.

Bug#803887: Downstream issue

[Gabriel Scherer]

For the record, we checked upstream (with Luc Maranget, who wrote the
latex->info converter used by the OCaml manual) and production of info
files still reliable works upstream. I didn't follow all the details
but apparently the build process produced a temporary file
(ocaml.info.body) that might have confused Debian packagers, and Luc
removed it from trunk:
  https://github.com/ocaml/ocaml/commit/533e0cdd29cc70773703f47acede8ee45aea5591

Bug#807482: spice_session_set_shared_dir: assertion 'dir != NULL' failed

[wim]

Package: virt-viewer
Version: 1.0-1
Severity: normal

Hallo,

As root:
using virsh to start a domain,
and then using virt-viewer to connect to the domain:
i always get this message (several times) 
"GSpice-CRITICAL **: spice_session_set_shared_dir: assertion 'dir != NULL' 
failed"
eg:
$virsh start debian-vm
$virt-viewer debian-vm

Another, possibly unrelated bug, but i mention it here as i didn't find any 
other hints in logs or online:
the keyboard sometimes is not shareable/(automatically switchable) between host 
and domain(vm);
the only solution then is to explicitely use the mouse and (de)select the usb 
device (ie the keyboard)

hth,
Wim


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

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

Versions of packages virt-viewer depends on:
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u1
ii  libcairo-gobject2   1.14.0-2.1
ii  libcairo2   1.14.0-2.1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u3
ii  libglib2.0-02.42.1-1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libgtk-vnc-2.0-00.5.3-1.3
ii  libgvnc-1.0-0   0.5.3-1.3
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libspice-client-glib-2.0-8  0.25-1+b1
ii  libspice-client-gtk-3.0-4   0.25-1+b1
ii  libvirt01.2.9-9+deb8u1
ii  libxml2 2.9.1+dfsg1-5

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.105-7
ii  netcat-traditional [netcat]  1.10-41

-- no debconf information

Bug#738962: Bug#738962: python-csb: More issues with the tests

[Andreas Tille]

Ping?

Please join or advent calendar effort

http://debian-med.alteholz.de/advent/

Kind regards

 Andreas.

On Tue, May 13, 2014 at 09:34:44AM +0200, Andreas Tille wrote:
> Hi Tomas,
> 
> any news about this?
> 
> Kind regards
> 
>Andreas.
> 
> On Mon, Feb 17, 2014 at 01:31:36PM +0100, Tomas Di Domenico wrote:
> > Hi Dmitry,
> > 
> > On 15/02/14 10:13, Dmitry Shachnev wrote:
> > > Hi Tomas,
> > > 
> > > Alternatively, you can make binary packages suggest/recommend
> > > them, but then you will need to add those packages as dependencies
> > > in debian/tests/control.
> > 
> > I understand, thank you for the explanation.
> > 
> > > The Git looks out of date (it does not even include the latest
> > > release), where did you update the code?
> > 
> > I'm sorry, I was working locally while trying to understand what's
> > going on. I've now updated the sources.
> > 
> > > Note: this failure seems to only happen on i386 and not amd64.
> > 
> > I'll contact upstream and see if they can take care of the i386 failure
> > 
> > > For running the tests, I personally use just adt-virt-null runner 
> > > in a clean environment, but probably using something like 
> > > adt-virt-schroot will be an easier solution. See this message for
> > > some instructions:
> > > 
> > > https://lists.debian.org/debian-devel/2014/01/msg00507.html
> > 
> > I've successfully set up the schroot. When running the command as follows
> > 
> > adt-run python-csb_1.2.3+dfsg-1_all.deb --- adt-virt-schroot csb-amd64
> > 
> > I get a very short output from adt-run saying that the build and the
> > tests are done. I have my doubts about it though, because it returns
> > almost immediately.
> > 
> > > I am attaching a patch that addresses 1), 2) and 5), and also adds 
> > > a dependency on python3-all to ensure that tests are run for all 
> > > supported Python 3 versions. That patch will make the tests green 
> > > on ci.debian.net, but will not fix the real failure (3).
> > 
> > Thank you for the patch, I've applied it to the sources. I didn't know
> > about ci.debian.net, that's a great resource to have handy.
> > 
> > Cheers,
> > Tomás
> > 
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> > 
> 
> -- 
> http://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#801498: Using rakudo-star tarball ...

[Dominique Dumont]

Hello Patrick

Sorry for the very late reply

On Friday 23 October 2015 12:05:34 Patrick R. Michaud wrote:
> I think I can answer this to some extent.  "Perl 6" is a language, 
> much like "C", "Java", or "JavaScript".  Just as we would not confuse 
> "gcc" with the C programming language, or V8 with JavaScript, one 
> should not treat "rakudo" and "Perl 6" as being equivalent.  
> [...]

Many thanks for the clarification.

> To return to the question of "What should be the basis for (Debian's)
> packaging of Perl 6?"... well, the answers just given in this thread
> are reasonable.  It's completely reasonable to say "We'll just package
> up Rakudo Star, and let the upstream folks decide what makes for a 
> good Perl 6 environment."  It's also reasonable to do things similar 
> to the way Perl 5 is packaged in Debian, where installing "Perl" 
> (Perl 5) generally ends up loading multiple .deb packages ranging 
> from "perl-base" and "perl-modules" to others with "-perl" in the
> name that encapsulate popular CPAN modules.

Given the work already done on moar and nqp, I'll try to just switch the 
upstream source of debian-rakudo from vanilla-rakudo to rakudo-star.

Thus our rakudo package will contain rakudo, panda and the modules selected by 
rakudo star team

> I hope this helps clarify things a bit.  

Yes, thanks a bunch

All the best

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

Bug#806955: icedove: fails to start with "Failed to read the config file"

[Meik Hellmund]

Hello Carsten,

Everything works fine with the .cfg file 
in /usr/lib/icedove . 
So there is no time pressure. 
Perhaps move this bug to status: wishlist, 
"allow system-wide cfg files outside /usr/lib/icedove"  
Anyway, it's only a small point about a seldom used feature.  

best wishes,
Meik


-- 
Meik Hellmund
Mathematisches Institut, Uni Leipzig
e-mail: meik.hellm...@math.uni-leipzig.de
http://www.math.uni-leipzig.de/~hellmund

Bug#798167: camitk: depends on vtk 5

[Nicolas SAUBAT]

Hi Andreas,

Thank you for your email.

Indeed, we have noticed this bug reported in Debian.
We are working on another new version in CamiTK with VTK6 support.
Unfortunately this new version will take some time to be released (we will also 
have to migrate to Qt 5.x version).

Thank you,
Nicolas.

On 12/06/2015 08:11 AM, Andreas Tille wrote:
> Hi Emmanuel and Nicolas,
> 
> I hope you realised the bug reported in Debian saying:
> 
>> your package depends on vtk 5.x, which should not be in stretch.  Please
>> switch to vtk 6.x or drop the dependency.
> 
> It would be great if you could adapt camitk and release a new version.
> 
> Kind regards
> 
>  Andreas.
> 

-- 
Nicolas SAUBAT
Ingénieur Recherche et Développement
Equipe GMCAO - Laboratoire TIMC-IMAG
Pavillon Taillefer
Allée des Alpes - Domaine de la Merci
38706 La Tronche
Tel : (33)04 56 52 00 10

Bug#807483: RM: kicad [arm64 s390x] -- ROM; needs boost_context

[Graham Inggs]

Package: ftp.debian.org
Severity: normal

Please remove kicad for the arm64 and s390x architectures.

Since version 4, kicad requires boost_context which is not available in boost 
1.58 for those architectures.
Support for boost_context was added for arm64 in version 1.59 [1], s390x stills 
seems unsupported.


Regards
Graham


[1] 
https://github.com/boostorg/context/commit/8481d3ccfc8e9cd3b689c43418e27ccfe722fcb2

Bug#807461: lintian: check years in debian/copyright are not in the future

[Jakub Wilk]

* Jakub Wilk , 2015-12-09, 11:17:
I found a git commit in one of the d-i packages that fixed the 
copyright year, changing it from 2103 to 2013. This wasn't in 
debian/copyright but it would be great if lintian could catch such 
typos in debian/copyright.


Heh, I found these:

https://sources.debian.net/src/jenkins-debian-glue/0.15.2/debian/copyright/?hl=19
https://sources.debian.net/src/ocaml-frei0r/0.1.0-3/debian/copyright/?hl=8


Also:
https://sources.debian.net/src/haskell-dual-tree/0.2.0.6-2/debian/copyright/?hl=11#L11

(Though checking for dates from the deep past might be error-prone.)

--
Jakub Wilk

Bug#807258: Fixed

[BERTRAND Joël]

I have downgraded sendmail to 8.14.4 (built from debian/stable sources) 
and sendmail runs as expected. Please remove faulty package or apply 
last sendmail patches that fix this known issue.


Best regards,

JKB

Bug#807485: gnome-keyring: pinentry-gnome3 should also be recommended and (hard) dependency should fallback on pinentry-gtk2

[Jonas Smedegaard]

Package: gnome-keyring
Version: 3.18.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I understand from bug#787786 that GNOME should ensure that most
possible of its features is getting used.

As already pointed out in bug#787786#18, there are other sensible of
gnome-keyring other than in concert with the GNOME desktop.

I agree that favoring pinentry-gtk2 over pinentry-gnome is wrong, but
_only_ hard depending on pinentry-gnome makes it impossible¹ to use
gnome-keyring without also pulling in pinentry-gnome and its (for some
non-GNOME uses) too excessive dependencies.

Please consider the following, which I believe satisfies both the need
for ensuring best GNOME experience and supporting lighter alternatives:

  * Have dependency on pinentry-gnome fallback to pinentry-gtk2
  * Recommend pinentry-gnome

Thanks for considering,

 - Jonas

¹ Impossible while using pure Debian.  Custom tricks like creating a
fake package by same name is possible - resulting in a _derivative_ of
Debian.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWaCfMAAoJECx8MUbBoAEhCfsP/AwpWR+Z2DloBjZ5yhvP3Q9t
tHKDFV8FkQtmPvdvorz/Ku5hxJ+dEfyGoJzTB1Iw0GIh/xfw+fIe4FS1qNq3hU7e
VFbzr51Aco+28CUH97z6sKvM2s6XfDHaX5EznlVM1C42efIc+u68z2HuW9Q4NPJl
a3ZmkUcR18TE+bahNwDisriZLELw3hQ6eX9Nq8qt485fC49ndN0RvqNLU7gwx7qB
6+xoamOPhNqD7NwTTR7hdnUa4NfDsXOyPt1Ci4XNQhlvMVyFVXu+/iwxCy0xTUZW
+bB4UmsuQT9dOgCZmMdQmrEGPSUfi/8O/g/FllVunSboMAZu+m/4oaqFXwB77hG3
AnwEEJG8fNmyEp9jRlNyy2HMpSneDz1u1Gi/zLNtlIWf2w5dcPcjAfk3tyMvpQWD
Yn1sd/kjH9PzMWF9WAPTLUavBb2dzozjgQaIROHVnYlgzFQvFituNDXKL+sEkI2w
2G+8Od9GaaVQOreIg/K/4c8v6Yc0vb7g7eFOqUaKhUHuTxHtvrsq7blNksvPGJPR
unS/KM9A41s9jMCsdSPeIN1CiOzd8TK/6UCrJuy7zhASMZOtzLudv/VLKywUCWIK
Few93XOjUmaDUL1s6QUrWF2kYFI2aR4tjU9m8IzPNj7ZKikSoTSx6S2fduYp9UeN
atOSQ3ghsc2Qqg4lDZiV
=S+3s
-END PGP SIGNATURE-

Bug#803644: fixed in julia 0.4.2-1

[Emilio Pozuelo Monfort]

On 08/12/15 16:54, Peter Colberg wrote:
> Hi Emilio,
> 
> On Tue, Dec 08, 2015 at 11:52:54AM +0100, Emilio Pozuelo Monfort wrote:
>> Your package now build-depends on llvm-3.8 (as the first alternative). That 
>> is
>> built from src:llvm-toolchain-snapshot, which means it won't migrate to 
>> testing,
>> and thus your package won't either.
> 
> I was fully aware that LLVM 3.8 has not been released yet. However, I
> neglected to consider whether llvm-toolchain-snapshot is in testing.
> 
>> Please drop that, or at least make llvm-3.7 the first alternative.
> 
> Julia 0.4 requires LLVM == 3.3 or >= 3.8 to perform adequately.
> 
> LLVM 3.4 to 3.7 exhibit significant to grave performance issues
> depending on the architecture [1], which the upstream maintainers
> are aware off.
> 
> [1] https://github.com/JuliaLang/julia/issues/14191
> 
> As an alternative to not having Julia 0.4 in Debian at all, would you
> agree to the Julia team reuploading the LLVM 3.3 package to unstable
> under our maintainership?

Sorry but that isn't an option.

What you can do is keep julia in unstable using llvm 3.8, and that will migrate
to testing once 3.8 is officially released and migrates to testing.

Cheers,
Emilio

> We would transition to LLVM 3.8 once Julia 0.5 is released next year.
> 
> 
> On the topic of LLVM, I have suggested [2] to promote selected LLVM
> versions to long-term supported (LTS) releases that are maintained
> by downstream users.
> 
> [2] https://github.com/JuliaLang/julia/issues/14191#issuecomment-160730008
> 
> Cheers,
> Peter
> 

Bug#807481: ITP: hamara-themes -- A GTK2/3, metacity and xwfm4 theme and an icon theme used by Hamara Linux.

[Raju]

package: hamara-themes
Severity: wishlist
Owner: 'Raju Vindane' 

*Package Name : hamara-themes
 Version : 6.0
 Upstream Author : Kumar Shantanu, Hamara Linux team.
*URL :  hamaralinux.org
*License : GPL
*Description : It contains the two main components.
1. hamara-gtk-theme
 A GTK2/3, metacity and xfwm4 theme used by default in Hamara Linux.
2. hamara-icon-theme
 An icon theme based on gnome-brave-icon-theme used in Hamara Linux.

Bug#643997: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict resolution

[Manuel A. Fernandez Montecelo]

2015-12-07 21:40 ydir...@free.fr:

2011-10-01 15:59 Yann Dirson:
>Package: aptitude
>Version: 0.6.3-4
>Severity: normal
>
>The "downgrade" use-case surely needs some love those days thanks to
>the moz foundation: I rapidly had a test of iceweasel 7 in unstable
>(eager to get better ram usage ;), just to conclude that so many
>extensions are not compatible.
>
>So let's try to get back to v6... iceweasel-dbg has a scrict dep,
>what
>are the first suggestions from aptitude ?  Each of them summarized
>below, one per paragraph.
>
>I originally thought it was just a problem of "downgrade" being
>rated
>too bad - and incidentally, when asked to explicitely downgrade,
>aptitude should surely not inflict a downgrade-penalty to packages
>that are broken by the downgrade.  But even then, how to explain
>that
>version from squeeze is elected first, then version from
>moz.d.n/wheezy, and that just downgrading -dbg to wheezy itself is
>not
>even ever considerered, whereas the priority of those packages is
>highest ?

From apt_preferences man page:

   APT then applies the following rules, listed in order of
   precedence, to determine which version of a package to
   install.

   · Never downgrade unless the priority of an available version
 exceeds 1000. ("Downgrading" is installing a less recent
 version of a package in place of a more recent version. Note
 that none of APT's default priorities exceeds 1000; such
 high
 priorities can only be set in the preferences file. Note
 also
 that downgrading a package can be risky.)

So even if pin priority is higher, since none of them is higher than
1000, it's not supposed to facilitate downgrades in any way.


More in general, downgrades are not supported, so I don't think that
it
should be a goal of aptitude or any other tool making this action
very
easy / convenient / appear risk-free by working as seamlessly as new
installs or upgrades.


Just seen a situation which would not have astonished me, were it not for
this clarification about pinning: on a mostly-testing machine, where upgrading
tulip to new 4.8.0 from unstable (I had a pre-upload locally-built version of
that package installed, with same version string, but I'm not sure that makes
any difference) pulls binutils from unstable, breaking a couple of 
binutils-related versionned deps:

* the first suggestion is to remove tulip (the same kind of choice which puzzles
 me with downgrade: it has been marked for upgrade, why on earth is the *first*
 suggestion to do anything else than what was asked)
* then after I refused this choice for tulip, the next suggestion is to keep the
 currently installed version (same remark)


This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359171 ,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574132 and many
others.

Very often, the first suggested solution is outright bad, one of the
next few ones if often good.



* then the next one is to upgrade binutils (and -dev and -multiarch), which is
 what I would have expected at first, BUT at the same time to DOWNGRADE
 binutils-arm-linux-gnueabi to the version in "stable"
* refusing that downgrade it finally proposes to upgrade the latter to unstable
 as well

That's the kind of situation to which I am routinely subject, and to which
unfortunately I usually don't pay that much attention any more.  But your
remark about pinning being the mechanism getting in the way of voluntary
downgrades, which perfectly made sense at the time, now confuses me, as I
don't see how it could cause a downgrade to be prefered to an upgrade.

Maybe the reason is linked to the identical score of 500 reported
by apt-cache policy ?


I am not sure about the root cause of this, neither the general problem
nor the specific suggestion to downgrade.

In general, I think that it's a good idea to have different priorities
for different suites (testing, unstable, etc), and not several of them
at the same level, because otherwise it makes the resolution more
difficult, and if two package versions have the same priority it can
recommend them randomly instead of prefering the solution of one suite.


The fact that the general problem was not successfully solved by the
original developer of aptitude, even after several refurbishments of the
resolver, and that probably he is the only person in the world who knows
in depth the aptitude resolver, doesn't seem like a good omen to resolve
it soon.

But in any case, as I explained in the previous messages, that's the
main reason why I don't want to tackle the problem of the downgrades in
particular: if things related with resolver are to be changed, it should
be to make the experience with everyday actions consistently good, not
to facilitate downgrades.  If as a side effect downgrades are made less
painful, fine (or maybe not fine and we have to restrict them
artificially to avoid people shooting themselves in the foot).  But the
modifications 

Bug#748474: clean-orig-sorce target (custom download scripts)

[Osamu Aoki]

Hi,

On Mon, Dec 07, 2015 at 02:29:29PM +, Nicholas Bamber wrote:
> Osamu,
>   with the get-orig-source I think I really messed up my explanation of 
> how I
> see things.
> 
>   Once a maintainer has dtermined  that the upstream download method is 
> too
> whacky to expect uscan to cope, and has to resort to a get-orig-source
> target in the debian/rules file, then yes uscan is out of the picture for
> downloading the tarball.
> 
>   However uscan is also used in say the DDPO reports to identify when a 
> new
> version is available. That function of uscan cannot be handled by
> debian/rules but uscan could offer a wrapper around the get-orig-source
> target to make that infomration available via the debian/watch interface.
> 
>   Does that make my point clearer?


Watch file to identify if there is new version or not
get-orig-source to download etc.

H, that's easy addition.  Question is is it valuable. Probably.

Let me think a bit more.

(clean-orig-source idea may not be too far as this report)

Some download script run after --report barrier ...  interesting
thought.

Osamu

Bug#759657: console-setup w/ systemd forgets font setting

[Anton Zinoviev]

On Tue, Dec 08, 2015 at 03:54:01PM +0100, Francesco Poli wrote:
> 
> Dear console-setup maintainers, this bug has been reported quite some
> time ago: is there any progress on this?

In order to be honest, I must admit that I don't use systemd in my 
systems.  I find the behaviour of systemd too complex and so far I 
haven't have enough time to learn how exactly it works.  Therefore, for 
the time being I am not qualified to work on this bug.

However console-setup has many contributors.  Hopefully one of them 
will be able to fix this bug.

Anton Zinoviev

Bug#807485: gnome-keyring: pinentry-gnome3 should also be recommended and (hard) dependency should fallback on pinentry-gtk2

[Michael Biebl]

Am 09.12.2015 um 15:44 schrieb Jonas Smedegaard:
> Quoting Michael Biebl (2015-12-09 19:27:37)
>> Am 09.12.2015 um 14:08 schrieb Jonas Smedegaard:
>> Which excessive dependencies?
>> Which of those aren't already pulled in by gnome-keyring?
> 
> Oh - please ignore the remark about excessive dependencies (I was 
> looking at an older suite).
> 

Ok. It seemed like you were exaggerating trying to make a point.


> Currenly pinentry-gnome cannot be removed from a system which uses 
> gnome-keyring

Given the size of pinentry-gnome3, I'm not really worried about that.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#807490: wheezy-pu: package nvidia-graphics-modules/304.131+3.2.0+1

[Andreas Beckmann]

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

This is just a rebuild of nvidia-graphics-modules against the new
nvidia-graphics-drivers 304.131-1 in wheezy-pu.


Andreas
diff -Nru nvidia-graphics-modules-304.128+3.2.0+1/debian/changelog nvidia-graphics-modules-304.131+3.2.0+1/debian/changelog
--- nvidia-graphics-modules-304.128+3.2.0+1/debian/changelog	2015-11-07 21:03:42.0 +0100
+++ nvidia-graphics-modules-304.131+3.2.0+1/debian/changelog	2015-12-09 14:28:34.0 +0100
@@ -1,3 +1,10 @@
+nvidia-graphics-modules (304.131+3.2.0+1) wheezy; urgency=medium
+
+  * Use nvidia-kernel-source 304.131.
+  * Upload to wheezy.
+
+ -- Andreas Beckmann   Wed, 09 Dec 2015 14:27:11 +0100
+
 nvidia-graphics-modules (304.128+3.2.0+1) wheezy; urgency=medium
 
   * Use nvidia-kernel-source 304.128.
diff -Nru nvidia-graphics-modules-304.128+3.2.0+1/debian/control nvidia-graphics-modules-304.131+3.2.0+1/debian/control
--- nvidia-graphics-modules-304.128+3.2.0+1/debian/control	2015-11-07 21:03:42.0 +0100
+++ nvidia-graphics-modules-304.131+3.2.0+1/debian/control	2015-12-09 14:28:34.0 +0100
@@ -7,7 +7,7 @@
  Andreas Beckmann ,
 Build-Depends: debhelper (>= 8),
  linux-headers-3.2.0-4-amd64 [i386 amd64], linux-headers-3.2.0-4-486 [i386], linux-headers-3.2.0-4-686-pae [i386],
- nvidia-kernel-source (>= 304.128), nvidia-kernel-source (<< 304.128.~),
+ nvidia-kernel-source (>= 304.131), nvidia-kernel-source (<< 304.131.~),
 Standards-Version: 3.9.3
 Homepage: http://www.nvidia.com/
 Vcs-Git: git://anonscm.debian.org/pkg-nvidia/nvidia-graphics-modules.git -b wheezy
@@ -16,7 +16,7 @@
 
 Package: nvidia-kernel-amd64
 Architecture: i386 amd64
-Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-amd64 (>= 304.128)
+Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-amd64 (>= 304.131)
 Breaks: nvidia-kernel-2.6-amd64 (<< 295)
 Replaces: nvidia-kernel-2.6-amd64 (<< 295)
 Description: NVIDIA kernel module for Linux (amd64 flavor)
@@ -44,7 +44,7 @@
 
 Package: nvidia-kernel-486
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-486 (>= 304.128)
+Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-486 (>= 304.131)
 Breaks: nvidia-kernel-2.6-486 (<< 295)
 Replaces: nvidia-kernel-2.6-486 (<< 295)
 Description: NVIDIA kernel module for Linux (486 flavor)
@@ -72,7 +72,7 @@
 
 Package: nvidia-kernel-686-pae
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-686-pae (>= 304.128)
+Depends: ${misc:Depends}, nvidia-kernel-3.2.0-4-686-pae (>= 304.131)
 Breaks: nvidia-kernel-2.6-686-pae (<< 295)
 Replaces: nvidia-kernel-2.6-686-pae (<< 295)
 Description: NVIDIA kernel module for Linux (686-pae flavor)
diff -Nru nvidia-graphics-modules-304.128+3.2.0+1/debian/control.md5sum nvidia-graphics-modules-304.131+3.2.0+1/debian/control.md5sum
--- nvidia-graphics-modules-304.128+3.2.0+1/debian/control.md5sum	2015-11-07 21:03:42.0 +0100
+++ nvidia-graphics-modules-304.131+3.2.0+1/debian/control.md5sum	2015-12-09 14:28:34.0 +0100
@@ -1,6 +1,6 @@
-9f8b1d85933ef6bc98e8c8ad3de09ef7  debian/control
+0d0c94a69a4e659d3fe49e548c140540  debian/control
 604424135c845d2bafd91b15e03670f7  debian/control.source
 8dce140a73e725f1cd59a7aef8ecc83d  debian/control.flavor
 6015281d47a4a606e6e430597d75c27d  debian/rules
 94561696e96a4338bb92f811f1058ec6  debian/rules.defs
-#UPSTREAM_VERSION=304.128#
+#UPSTREAM_VERSION=304.131#

Bug#807492: libmath-bigint-gmp-perl: FTBFS on 32 bit platforms

[Dominic Hargreaves]

Source: libmath-bigint-gmp-perl
Version: 1.46-1
Severity: serious
Justification: FTBFS on platforms where it built before
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=103517

The new release, 1.46, introduced a regression on 32 bit platforms
where perl is compiled with 64 bit support. You can see that it has
failed to build on armel, armhf, i386, mips, mipsel, hppa, kfreebsd-i386
as a result:

https://buildd.debian.org/status/package.php?p=libmath-bigint-gmp-perl=unstable

There is discussion about this problem at the CPAN bug above.
Since this collides with the impending perl 5.22 transition, I
checked and it appears that the impact of removing this would not be
huge; so although I will add it as a blocker of the transition, if it
isn't fixed in the next few days it'll probably get removed.

Cheers,
Dominic.

Bug#807488: [buildd-tools-devel] Bug#807488: sbuild-update: please run -d with --no-install-recommends

[Johannes Schauer]

Hi,

Quoting Adam Borowski (2015-12-09 14:31:10)
> As per apt's defaults, whenever a package that's a part of the sbuild chroot
> gains a new Recommends:, that recommendation will be installed.  This
> default makes sense for regular apt uses outside of sbuild, but in sbuild's
> context, it goes against the aim of a minimal chroot.  It'll allow missing
> build-dependencies to sneak through unnoticed, and makes fresh chroots
> differ from updated ones.
> 
> Thus, please make sbuild-update pass --no-install-recommends to apt.

This is entirely reasonable and should be done that way but can you give me a
way how to reproduce this problem?

I never experienced the problem myself and looking at the code in
ResolverBase.pm it seems that sbuild already calls apt with a custom
configuration file /var/lib/sbuild/apt.conf which contains

APT::Install-Recommends false;

So I don't understand how you got apt as used by sbuild installing Recommends.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#807045: winetricks output: wineserver not found!

[Joseph Bisch]

Hi,

It looks like libwine or libwine-development should be a dependency of
winetricks, since winetricks doesn't appear to run without wineserver,
and wineserver is part of libwine. See this page for the package info:
[0].

It looks like you can trace the dependency chain from wine to libwine
on Wheezy and earlier releases, but starting with Jessie, libwine is
no longer part of the recursive dependencies of wine.

For now, installing libwine should fix the issue.

[0] - 
https://packages.debian.org/search?suite=stretch=any=path=contents=wineserver

Cheers,
Joseph

Bug#807485: gnome-keyring: pinentry-gnome3 should also be recommended and (hard) dependency should fallback on pinentry-gtk2

[Jonas Smedegaard]

Quoting Michael Biebl (2015-12-09 19:27:37)
> Am 09.12.2015 um 14:08 schrieb Jonas Smedegaard:
>> I understand from bug#787786 that GNOME should ensure that most
>> possible of its features is getting used.
>> 
>> As already pointed out in bug#787786#18, there are other sensible of
>> gnome-keyring other than in concert with the GNOME desktop.
>> 
>> I agree that favoring pinentry-gtk2 over pinentry-gnome is wrong, but
>> _only_ hard depending on pinentry-gnome makes it impossible¹ to use
>> gnome-keyring without also pulling in pinentry-gnome and its (for some
>> non-GNOME uses) too excessive dependencies.
>
> Which excessive dependencies?
> Which of those aren't already pulled in by gnome-keyring?

Oh - please ignore the remark about excessive dependencies (I was 
looking at an older suite).

Issue remains that gnome-keyring declares a strict dependency for a 
situation where in unusual cases alternatives works - which is the 
purpose of the "Recommends:" hint.

Currenly pinentry-gnome cannot be removed from a system which uses 
gnome-keyring, even though gnome-keyring can work with other 
implementations of the pinentry-x11 ABI than pinentry-gnome.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#807491: gdc: -fmake-deps misses transitive dependencies

[Celelibi]

Package: gdc
Version: 4:5.2.1-8
Severity: normal

Dear maintainer,

It appears that the option of gdc -fmake-deps doesn't include the
indirect dependencies that can occur when a module uses "public import".

Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gdc depends on:
ii  gdc-5  5.2.1-23
ii  libphobos-dev  5.2.1-8

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with altivec keyword bool

[Fernando Seiti Furusato]

J Price  wrote on 08/12/2015 19:14:00:

> From: J Price 
> To: Fernando Seiti Furusato/Brazil/IBM@IBMBR
> Cc: Andreas Beckmann , 806...@bugs.debian.org, Breno 
Henrique
> Leitao/Brazil/IBM@IBMBR
> Date: 08/12/2015 19:14
> Subject: Re: Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with 
altivec 
> keyword bool
> 
> You're right - this needs to be done in common.h for this to work
> (since common.h uses the bool keyword), but common.h is installed by
> the -dev package, so this goes against the idea of not messing with
> macros in public headers.

Oh, I should have noticed that.

> 
> Reading some other bug reports (e.g. [1]) suggests that compiling with
> `-std=gnu++11` instead of `-std=c++11` also fixes the problem. Is this
> a viable workaround? This would be a simple patch to CMakeLists.txt.

In case this question was directed to me -- it is viable in the sense that 
it
works. Just tested it here and it built.

Thanks and regards.

Fernando

Bug#807406: pbuilder: drop all the 'xenial' hardcoding in debian/rules and make the selection of the distro dynamic

[Gianfranco Costamagna]

Hi,

pbuilder-dist is actually using some python-distro-info magic

python
from distro_info import DebianDistroInfo, UbuntuDistroInfo
debian_info = DebianDistroInfo()
debian_info.devel()
ubuntu_info = UbuntuDistroInfo()
ubuntu_info.devel()

or directly:
from distro_info import DebianDistroInfo, UbuntuDistroInfo
DebianDistroInfo().devel()
'sid'
UbuntuDistroInfo().devel()
'xenial'

HTH,

Gianfranco

Bug#807489: jessie-pu: package nvidia-graphics-modules/340.96+3.16.0+1

[Andreas Beckmann]

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

This is just a rebuild of nvidia-graphics-modules against the new
nvidia-graphics-drivers 340.96-1.


Andreas
diff -Nru nvidia-graphics-modules-340.93+3.16.0+1/debian/changelog nvidia-graphics-modules-340.96+3.16.0+1/debian/changelog
--- nvidia-graphics-modules-340.93+3.16.0+1/debian/changelog	2015-11-07 21:19:17.0 +0100
+++ nvidia-graphics-modules-340.96+3.16.0+1/debian/changelog	2015-12-09 14:23:39.0 +0100
@@ -1,3 +1,10 @@
+nvidia-graphics-modules (340.96+3.16.0+1) jessie; urgency=medium
+
+  * Use nvidia-kernel-source 340.96.
+  * Upload to jessie.
+
+ -- Andreas Beckmann   Wed, 09 Dec 2015 14:22:48 +0100
+
 nvidia-graphics-modules (340.93+3.16.0+1) jessie; urgency=medium
 
   * Use nvidia-kernel-source 340.93.
diff -Nru nvidia-graphics-modules-340.93+3.16.0+1/debian/control nvidia-graphics-modules-340.96+3.16.0+1/debian/control
--- nvidia-graphics-modules-340.93+3.16.0+1/debian/control	2015-11-07 21:19:17.0 +0100
+++ nvidia-graphics-modules-340.96+3.16.0+1/debian/control	2015-12-09 14:23:39.0 +0100
@@ -8,7 +8,7 @@
  Vincent Cheng 
 Build-Depends: debhelper (>= 9),
  linux-headers-3.16.0-4-amd64 [i386 amd64], linux-headers-3.16.0-4-586 [i386], linux-headers-3.16.0-4-686-pae [i386],
- nvidia-kernel-source (>= 340.93), nvidia-kernel-source (<< 340.93.~),
+ nvidia-kernel-source (>= 340.96), nvidia-kernel-source (<< 340.96.~),
 Standards-Version: 3.9.6
 Homepage: http://www.nvidia.com/
 Vcs-Git: git://anonscm.debian.org/pkg-nvidia/nvidia-graphics-modules.git -b jessie
@@ -18,7 +18,7 @@
 Package: nvidia-kernel-dummy
 Architecture: amd64
 Priority: extra
-Depends: nvidia-kernel-source (>= 340.93), ${misc:Depends}
+Depends: nvidia-kernel-source (>= 340.96), ${misc:Depends}
 Description: NVIDIA kernel module for Linux (dummy package)
  This dummy package exists solely to ensure that the prebuilt modules do not
  migrate to testing before the corresponding driver is available. Nothing is
@@ -39,7 +39,7 @@
 
 Package: nvidia-kernel-amd64
 Architecture: i386 amd64
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-amd64 (>= 340.93)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-amd64 (>= 340.96)
 Conflicts: nvidia-kernel-2.6-amd64
 Replaces: nvidia-kernel-2.6-amd64
 Description: NVIDIA kernel module for Linux (amd64 flavor)
@@ -57,7 +57,7 @@
 
 Package: nvidia-kernel-586
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-586 (>= 340.93)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-586 (>= 340.96)
 Conflicts: nvidia-kernel-2.6-586
 Replaces: nvidia-kernel-2.6-586
 Description: NVIDIA kernel module for Linux (586 flavor)
@@ -75,7 +75,7 @@
 
 Package: nvidia-kernel-686-pae
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-686-pae (>= 340.93)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-686-pae (>= 340.96)
 Conflicts: nvidia-kernel-2.6-686-pae
 Replaces: nvidia-kernel-2.6-686-pae
 Description: NVIDIA kernel module for Linux (686-pae flavor)
diff -Nru nvidia-graphics-modules-340.93+3.16.0+1/debian/control.md5sum nvidia-graphics-modules-340.96+3.16.0+1/debian/control.md5sum
--- nvidia-graphics-modules-340.93+3.16.0+1/debian/control.md5sum	2015-11-07 21:19:17.0 +0100
+++ nvidia-graphics-modules-340.96+3.16.0+1/debian/control.md5sum	2015-12-09 14:23:39.0 +0100
@@ -1,7 +1,7 @@
-6cd7d7bfdcb70e9bce467762de30ba92  debian/control
+c1e0284ab90035ad346ff9ae821183b4  debian/control
 cebaad312eecf5eb135ccc2acc8525aa  debian/control.source
 fffd77960b50d626b720a23ee441a9ed  debian/control.flavor
 3fb001417b44d7fcc3af963390d49a9f  debian/rules
 11f3f9885d447eb0c3968882ecd33c68  debian/rules.defs
-#UPSTREAM_VERSION=340.93#
+#UPSTREAM_VERSION=340.96#
 #KERNEL_VERSION=3.16.0-4#

Bug#755981: evolution-data-server: this seems to have to do with ipv6 DNS issues

[Dario Pellegrini]

> 1.  When this happens, almost all the network activity consists of
bombarding the
> DNS server with requests

Confirmed, I got 459488 DNS queries to apidata.googleusercontent.com in the
last three hours.
I am running Gnome 3.18 on an ArchLinux box.

Bug#807019: tracking bin-num - broken unison due to binnmu upload

[Jakub Wilk]

* Stéphane Glondu , 2015-12-07, 16:23:

* is there a way to track down who uploaded -3+b1?

For "who", I don't know.


BinNMU are usually scheduled by the Release Team.
This package was part of the ncurses transition:
https://release.debian.org/transitions/html/ncurses.html

But for "why", cf 
/usr/share/doc/unison2.40.102/changelog.Debian.amd64.gz:

unison2.40.102 (2.40.102-3+b1) sid; urgency=low, binary-only=yes

 * Binary-only non-maintainer upload for amd64; no source changes.
 * Rebuild against ncurses 6.0.

-- amd64 / i386 Build Daemon (babin)   Fri, 31 
Jul 2015 09:50:21 +0200


...which is strange, because unison doesn't use ncurses AFAICT.


Not on amd64, but it does link to ncurses on some other architectures. 
This is probably unintentional. For example, I see this in the mips 
build log[0]:


dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/unison2.32.52/usr/bin/unison-2.32.52 was not linked against 
libncurses.so.5 (it uses none of the library's symbols)

Also, the date is misleading; it corresponds to the last sourceful 
upload, not the binNMU.


Looks like a fallout after #620112.
This change in sbuild should be reverted. It didn't fix binNMU 
co-installability, and made binMNU changelog entries less helpful.



[0] 
https://buildd.debian.org/status/fetch.php?pkg=unison2.32.52=mips=2.32.52-7%2Bb1=1449193180

--
Jakub Wilk

Bug#806481: [pkg-go] Bug#806481: Backport etcd to Jessie

[Paul Tagliamonte]

> I don't have any uploads anywhere, as I was just trying to do a build from
> the
> git repos of each repository.  I did read a bit over the steps to make
> things
> ready for backports, but I didn't try any of that yet.  Is it just a
> matter of
> changing the version number with an appropriate Changelog message?  If so,
> I
> can try starting with one to get the hang of it.  Is there any easy howtos
> for
>

Basically, yeah! Give one a shot and send it to me, and I can help make sure
everything looks great!


> beginners?  Most documentation I've seen is more reference material
> orientated, which I find a little hard to parse to get started.
>

Yeah, it's not great. Give it a best-whack and i'll provide some feedback,
it sounds like you're already doing it!


>
> If you want, I can stick my other files somewhere to download.  I don't
> know
> if they will be useful.
> --
> Matthew


Cheers,
  Paul



-- 
:wq

Bug#807485: gnome-keyring: pinentry-gnome3 should also be recommended and (hard) dependency should fallback on pinentry-gtk2

[Michael Biebl]

control: severity -1 wishlist
control: tags -1 moreinfo

Am 09.12.2015 um 14:08 schrieb Jonas Smedegaard:
> Package: gnome-keyring
> Version: 3.18.2-1
> Severity: normal
> 
> Hi,
> 
> I understand from bug#787786 that GNOME should ensure that most
> possible of its features is getting used.
> 
> As already pointed out in bug#787786#18, there are other sensible of
> gnome-keyring other than in concert with the GNOME desktop.
> 
> I agree that favoring pinentry-gtk2 over pinentry-gnome is wrong, but
> _only_ hard depending on pinentry-gnome makes it impossible¹ to use
> gnome-keyring without also pulling in pinentry-gnome and its (for some
> non-GNOME uses) too excessive dependencies.

Which excessive dependencies?
Which of those aren't already pulled in by gnome-keyring?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#807165: [php-maint] Bug#807165: Bug#807165: php7.0-fpm: make php7.0-fpm co-installable with php5-fpm

[Ondřej Surý]

I would be happy to accept patches to src:php5 and src:php7.0 that would
finish the missing bits.

Cheers,
Ondrej

On Tue, Dec 8, 2015, at 20:26, Danyi Dávid wrote:
> Hi,
> 
> I actually built the packages for myself, removing the "conflicts"
> definitions from the controls file, after checking the package contents
> for collisions, and for the most part it seemed to be fine, except for a
> few missing alternatives definitions in the php5 packages (phar for
> example), and a conflict in the LSB headers in the classic style init
> scripts.
> 
> After fixing those I could install both php5 and php7 and they work
> without any problems side-by-side for now in my test environment.
> 
> Looking at the php7 packages, the folder structure did look a bit more
> logically structured than the php5 ones, so I was hoping that php5 will
> be changed to match the same pattern.
> 
> Thanks for looking into it.
> 
> regards,
> David
> 
> On 2015-12-07 10:16, Ondřej Surý wrote:
> > Hi Danyi,
> > 
> > there's a src:php5.6 waiting in the NEW queue built on same/similar
> > debian/ packaging as src:php7.0 that will provide a way how to
> > seamlessly run 5.6 and 7.0.
> > 
> > But I look into src:php7.0 and src:php5 coinstallability - it might be
> > easier to do that I originally thought it would be.
> > 
> > Cheers,
> > Ondrej
> > 
> > On Sun, Dec 6, 2015, at 12:27, Danyi Dávid wrote:
> >> Package: php7.0-fpm
> >> Version: 7.0.0-1
> >> Severity: wishlist
> >>
> >> Dear Maintainer,
> >>
> >> Please make php7.0-fpm co-installable with php5-fpm, as that would help
> >> quite a
> >> lot with migrating to the new version if operators could run both at the
> >> same
> >> time.
> >>
> >> regards,
> >> David
> >>
> >>
> >>
> >> -- System Information:
> >> Debian Release: stretch/sid
> >>   APT prefers testing-updates
> >>   APT policy: (500, 'testing-updates'), (500, 'testing')
> >> Architecture: amd64 (x86_64)
> >> Foreign Architectures: i386
> >>
> >> Kernel: Linux 4.2.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 php7.0-fpm depends on:
> >> ii  init-system-helpers  1.24
> >> ii  libapparmor1 2.10-2+b1
> >> ii  libc62.19-22
> >> ii  libdb5.3 5.3.28-11
> >> ii  libedit2 3.1-20150325-1
> >> ii  libenchant1c2a   1.6.0-10.1
> >> ii  libgmp10 2:6.1.0+dfsg-2
> >> ii  libltdl7 2.4.2-1.11
> >> ii  libmagic11:5.25-2
> >> ii  libmcrypt4   2.5.8-3.3
> >> ii  libqdbm141.8.78-6+b1
> >> ii  libssl1.0.2  1.0.2d-3
> >> ii  libsystemd0  228-2
> >> ii  libtinfo56.0+20151024-2
> >> ii  libxml2  2.9.2+zdfsg1-4
> >> ii  libxslt1.1   1.1.28-2.1
> >> ii  mime-support 3.59
> >> ii  php7.0-cli   7.0.0-1
> >> ii  php7.0-common7.0.0-1
> >> ii  php7.0-json  7.0.0-1
> >> ii  php7.0-opcache   7.0.0-1
> >> ii  tzdata   2015g-1
> >> ii  ucf  3.0031
> >> ii  zlib1g   1:1.2.8.dfsg-2+b1
> >>
> >> php7.0-fpm recommends no packages.
> >>
> >> Versions of packages php7.0-fpm suggests:
> >> ii  php-pear  5.6.15+dfsg-1
> >>
> >> Versions of packages php7.0-common depends on:
> >> ii  php-common  15
> >>
> >> Versions of packages php7.0-common suggests:
> >> pn  php-user-cache  
> >>
> >> -- Configuration Files:
> >> /etc/php/7.0/fpm/pool.d/www.conf changed [not included]
> >>
> >> -- no debconf information
> >>
> >> ___
> >> pkg-php-maint mailing list
> >> pkg-php-ma...@lists.alioth.debian.org
> >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint
> > 
> > 
> 
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint


-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Bug#444831: aptitude: weirdness with lincity-ng

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi again Sam,

2007-10-01 11:20 Sam Morris:

Package: aptitude
Version: 0.4.6.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Aptitude didn't consider that upgrading lincity-ng would fix the
following problem:

$ sudo aptitude install -t unstable sun-java6-plugin
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
The following packages are BROKEN:
 lincity-ng
The following packages are unused and will be REMOVED:
 lincity-ng-data
The following packages have been automatically kept back:
 cpp-4.2 ecj ecj-gcj g++-4.2 gcc-4.2 liballegro4.2
 liballegro4.2-plugin-jack libart2-ruby libatk1-ruby libc6-dev libc6-i686
 libcairo-ruby libcairo-ruby1.8 libdb4.5 libecj-java libecj-java-gcj
 libgconf2-ruby libgdk-pixbuf2-ruby libglade2-ruby libglib2-ruby
 libglib2.0-0 libglib2.0-0-dbg libglib2.0-dev libgnome2-ruby
 libgnomecanvas2-ruby libgnomekbd-dev libgnomeprint2-ruby
 libgnomeprintui2-ruby libgnomevfs2-ruby libgomp1 libgtk-mozembed-ruby
 libgtk2-ruby libgtkglext1-ruby libgtkhtml2-ruby libgtksourceview1-ruby
 liblog4j1.2-java liblog4j1.2-java-gcj libmudflap0 libmudflap0-4.2-dev
 libpanel-applet2-ruby libpango1-ruby libpulse0 libpurple-bin libpurple0
 librsvg2-ruby libsnmp-base libstdc++6-4.2-dev libtorrent10
 libversion-perl libxine1-console libxine1-doc libxine1-ffmpeg
 libxine1-gnome linux-libc-dev lp-solve mail-notification neverball-common
 neverball-data source-highlight vim-addon-manager
The following packages have been kept back:
 acpid agave apache2 apache2-doc apache2-mpm-worker apache2-utils
 apache2.2-common beast blktrace bsdmainutils bsdutils cdd-doc cdrdao
 console-data console-setup console-terminus contacts coreutils cpio
 cryptsetup curl darcs darcs-buildpackage dash debhelper debianutils
 devhelp devhelp-common dhcp3-client dhcp3-common docbook docbook-xml
 docbook-xsl dosbox dwww edos-debcheck ekiga elinks
 evolution-data-server-dev exif fast-user-switch-applet fftw2 flac
 freetalk frozen-bubble frozen-bubble-data g-wrap gcalctool gcc-4.2-base
 gconf-editor glibc-doc gnome-doc-utils gnome-games-extra-data
 gnome-keyring gnome-keyring-manager gnome-mount gnome-nettool
 gnome-power-manager gnome-randr-applet gnome-system-monitor
 gnome-terminal-data gnome-utils gnucash-docs gnupg-doc gnutls-bin
 gnutls-doc googleearth-package gossip gossip-common gparted gpgsm
 graphviz grub-disk grub-doc gstreamer-tools gstreamer0.10-doc
 gstreamer0.10-esd gstreamer0.10-ffmpeg gstreamer0.10-plugins-good
 gstreamer0.10-plugins-good-dbg gstreamer0.10-plugins-good-doc
 gstreamer0.10-tools gthumb gtk2-engines gucharmap guile-1.8-libs
 guile-g-wrap guile-library hal hal-device-manager hal-doc hardinfo haxe
 iceweasel iceweasel-dom-inspector iceweasel-gnome-support
 iceweasel-l10n-en-gb imagemagick initramfs-tools kghostview kid3
 klibc-utils koffice-data koffice-libs krita krita-data laptop-detect
 ledit lesstif2 libatspi-dbg libatspi1.0-0 libbluetooth-dev libbluetooth2
 libbonoboui2-0 libbonoboui2-common libbonoboui2-dev
 libboost-date-time-dev libboost-dev libboost-filesystem-dev
 libboost-regex-dev libboost-serialization-dev libboost-thread-dev libc6
 libc6-dbg libclass-accessor-perl libcompress-zlib-perl libcurl3
 libcurl3-gnutls libcurl4-gnutls-dev libdb4.3 libdb4.4 libdb4.4-dev
 libdbd-sqlite3-perl libdevhelp-1-0 libdevil-dev libdevil1c2 libeel2-data
 libeel2-dev libextlib-ocaml-dev libffi4 libffi4-dev libflac++6
 libflac-dev libflac8 libgcc1 libglib2.0-doc libglu1-xorg-dev
 libgnome-desktop-2 libgnome-desktop-dev libgnome-keyring-dev
 libgnome-keyring0 libgnome-window-settings-dev libgnome2-0
 libgnome2-common libgnome2-dev libgnome2-doc libgnomecanvas2-0
 libgnomecanvas2-common libgnomecanvas2-dev libgnomekbd-common
 libgnomekbd1 libgnomekbdui-dev libgnomekbdui1 libgnomeprint2.2-0
 libgnomeprint2.2-data libgnomeprint2.2-dev libgnomeprint2.2-doc
 libgnomeprintui2.2-0 libgnomeprintui2.2-common libgnomeprintui2.2-dev
 libgnomeprintui2.2-doc libgnomeui-0 libgnomeui-0-dbg libgnomeui-common
 libgnomeui-dev libgnomeui-doc libgnutls-dev libgnutls13 libgnutlsxx13
 libgpgme11 libgpgme11-dev libgphoto2-2 libgphoto2-port0
 libgraphicsmagick1 libgstreamer0.10-0 libgstreamer0.10-0-dbg
 libgstreamer0.10-dev libgtk2.0-bin libgtk2.0-doc libgucharmap6 libhal-dev
 libhal-storage-dev libhal-storage1 libhal1 libjline-java libklibc
 libltdl3 libltdl3-dev libmagick9 libmetacity-dev libmetacity0
 libmono-cairo1.0-cil libmono-corlib1.0-cil libmono-corlib2.0-cil
 libmono-data-tds1.0-cil libmono-data-tds2.0-cil libmono-dev
 libmono-peapi1.0-cil libmono-relaxng1.0-cil libmono-security1.0-cil
 libmono-security2.0-cil libmono-sharpzip0.84-cil libmono-sharpzip2.84-cil
 libmono-system-data1.0-cil libmono-system-data2.0-cil
 libmono-system-runtime1.0-cil libmono-system-web1.0-cil
 libmono-system-web2.0-cil 

Bug#628183: Any changes wrt this?

[Lisandro Damián Nicanor Pérez Meyer]

Hi! Has there been any change wrt this ITP? Thanks!

-- 
Geek Inside!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#690701: Provide OS major/full version string

[martin f krafft]

also sprach Benjamin Drung  [2015-12-09 13:51 
+0100]:
> osrelease:
> 8

This is what I was looking for.

> osrelease_info:
> - 8

Will this be a list, e.g.

  - 8
  - 1
  - r2

For 8.1r2?

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"women, when they are not in love,
 have all the cold blood of an experienced attorney."
   -- honoré de balzac


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#807493: altree: Produces empty binary package

[Dominic Hargreaves]

Source: altree
Version: 1.3.1-3
Severity: grave
Justification: package not usable
Tags: sid
X-Debbugs-Cc: debian-p...@lists.debian.org

The last upload, fixing #807423, unfortunately started creating empty
binary packages on most (but not all) architectures. See for example

https://packages.debian.org/sid/amd64/altree/filelist
https://packages.debian.org/sid/armel/altree/filelist
https://packages.debian.org/sid/armhf/altree/filelist
https://packages.debian.org/sid/i386/altree/filelist

I can't see from a quick glance what is going on here; CC-ing
debian-perl in case anyone can help.

Cheers,
Dominic.

Bug#807150: gubbins: FTBFS on i386: Invalid ALN file for multiple lines per seq

[Andrew Page]

Hi,
I have pushed a fix for the build error on i386 as version 1.4.4
Details are here:
https://github.com/sanger-pathogens/gubbins/pull/158 


I replicated the bug on i386 and fixed it. The tests also pass on amd64 & OSX 
10.10

Regards,
Andrew


> On 6 Dec 2015, at 06:40, Andreas Tille  wrote:
> 
> Hi Andrew,
> 
> I hereby forward a build issue on i386 architecture.
> 
> Kind regards
> 
>   Andreas.
> 
> On Sat, Dec 05, 2015 at 10:30:32PM -0500, Aaron M. Ucko wrote:
>> Source: gubbins
>> Version: 1.4.3-1
>> Severity: important
>> Justification: fails to build from source
>> 
>> The i386 build of gubbins failed:
>> 
>>  FAIL: run_all_tests
>>  
>>  Testsuite summary for gubbins 1.4.3
>>  
>>  # TOTAL: 1
>>  # PASS:  0
>>  # SKIP:  0
>>  # XFAIL: 0
>>  # FAIL:  1
>>  # XPASS: 0
>>  # ERROR: 0
>>  
>>  See src/test-suite.log
>> 
>> I was able to reproduce the error in an i386 chroot, yielding the following
>> details:
>> 
>>  FAIL: run_all_tests
>>  ===
>> 
>>  Running suite(s): Creating_SNP_Sites
>>   Parsing a phylip file
>>   Parsing a vcf file
>>   checking branch sequences
>>   Checking the gubbins functionality
>>   snp_searching
>>  94%: Checks: 39, Failures: 2, Errors: 0
>>  
>> ../tests/check_snp_sites.c:73:F:snp_sites:valid_alignment_with_multiple_lines_per_sequence:0:
>>  Invalid ALN file for multiple lines per seq
>>  ../tests/check_snp_sites.c:85:F:snp_sites:two_sequences:0: Invalid ALN file 
>> for multiple lines per seq
>>  FAIL run_all_tests (exit status: 1)
>> 
>> Could you please take a look?
>> 
>> Thanks!
>> 
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>> 
> 
> -- 
> http://fam-tille.de




-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Bug#795833: initramfs-tools: add mountroot failure support to allow meaningful messages and recovery attempts

[Ben Hutchings]

On Mon, 17 Aug 2015 10:52:14 +0100 Andy Whitcroft  wrote:
> Package: initramfs-tools
> Version: 0.120
> Severity: normal
> 
> Allow hooks to supply specific root mount failure handlers.  These can
> both report more specific failure reasons, and in some cases may even be
> able to attempt recovery.  This is useful for more complex scenarios
> such as LVM and mdadm setups.
> 
> We use this in Ubuntu to allow augmented lvm2 and mdadm hooks to recover
> failed raids and the like.
> 
> NOTE: that the splash handling here may well be Ubuntu specific.

Thanks for your patch.

Can you explain why this was implemented by extending existing scripts
rather than by adding a new phase (possibly with stamp files to control
what they do)?

[...]
> --- a/scripts/functions
> +++ b/scripts/functions
[...]
> +# Run failure hooks.
> +# When a failure hook exits "1", it has not done anything to correct the
> +# system.  Exiting "0" means that something has been attempted to resolve
> +# the lack of a root filesystem.
> +# Hooks are run in lexigraphical order, and are responsible for removing
> +# themselves if they should not re-run in a later cycle.  When one exits
> +# "0", the stack is stopped, so the caller can return to the main rootfs
> +# wait loop.

'Hook' is reserved for build-time scripts, so use 'script' here.

> +try_failure_hooks()
> +{
> + local hook
> +
> + # Disable usplash so text from hooks can be seen
> + if [ -x /sbin/usplash_write ]; then
> + /sbin/usplash_write "QUIT"
> + fi
> + chvt 1
> + if [ -x /bin/plymouth ] && plymouth --ping; then
> + /bin/plymouth hide-splash > /dev/null 2>&1
> + fi
[...]

This bit can be handled by 'panic' scripts once #602331 is fixed
(currently pending).

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

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

Bug#807485: gnome-keyring: pinentry-gnome3 should also be recommended and (hard) dependency should fallback on pinentry-gtk2

[Michael Biebl]

Am 09.12.2015 um 17:01 schrieb Jonas Smedegaard:
> Quoting Michael Biebl (2015-12-09 20:31:42)
>> Am 09.12.2015 um 15:44 schrieb Jonas Smedegaard:
>>> Currenly pinentry-gnome cannot be removed from a system which uses 
>>> gnome-keyring
>>
>> Given the size of pinentry-gnome3, I'm not really worried about that.
> 
> My concern is not the size but functionality.
> 
> pinentry has multiple implementations, each with different features and 
> drawbacks (look'n'feel, security deisgn etc).  Current package hints of 
> gnome-keyring makes it needlessly difficult for non-GNOME users to favor 
> a different implementation of pinentry than the one GNOME favors.
> 

That's a separate issue.Something that needs to be fixed not via package
dependencies but rather a more flexible mechanism how to choose the
default pinentry program:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791441
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#807493: altree: Produces empty binary package

[Dominic Hargreaves]

On Wed, Dec 09, 2015 at 04:56:11PM +0100, Vincent Danjean wrote:
>   Hi,
> 
> Le 09/12/2015 16:31, Dominic Hargreaves a écrit :
> > Source: altree
> > Version: 1.3.1-3
> > Severity: grave
> > Justification: package not usable
> > Tags: sid
> > X-Debbugs-Cc: debian-p...@lists.debian.org
> > 
> > The last upload, fixing #807423, unfortunately started creating empty
> > binary packages on most (but not all) architectures. See for example
> > 
> > https://packages.debian.org/sid/amd64/altree/filelist
> > https://packages.debian.org/sid/armel/altree/filelist
> > https://packages.debian.org/sid/armhf/altree/filelist
> > https://packages.debian.org/sid/i386/altree/filelist
> > 
> > I can't see from a quick glance what is going on here; CC-ing
> > debian-perl in case anyone can help.
> 
>   It is an error from me. altree files are now installed in debian/tmp
> instead of directly debian/altree by debian/rules, so a debian/altree.install
> file is required.
>   I will fix this in a few hours if nobody do it before. And I will
> reincorporate Andreas modifications that were all good.

Great, thanks for the swift response!

Cheers,
Dominic.

Bug#807496: python-systemd: Please provide Python 2 version of python-systemd

[Benjamin Drung]

Package: python-systemd
Version: 231-1
Severity: normal
Tags: patch

Hi,

salt 2015.8.3+ds-1 requires python-systemd since it does not yet support
Python 3. So please provide python-systemd. A patch for that is
attached.

PS: The patch also includes a run of wrap-and-sort.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
diff -Nru python-systemd-231/debian/changelog python-systemd-231/debian/changelog
--- python-systemd-231/debian/changelog	2015-10-29 01:55:04.0 +0100
+++ python-systemd-231/debian/changelog	2015-12-09 17:11:19.0 +0100
@@ -1,3 +1,10 @@
+python-systemd (231-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Introduce python-systemd (Python 2 version).
+
+ -- Benjamin Drung   Wed, 09 Dec 2015 17:10:51 +0100
+
 python-systemd (231-1) unstable; urgency=medium
 
   [ Martin Pitt ]
diff -Nru python-systemd-231/debian/control python-systemd-231/debian/control
--- python-systemd-231/debian/control	2015-10-29 01:55:04.0 +0100
+++ python-systemd-231/debian/control	2015-12-09 17:12:11.0 +0100
@@ -2,25 +2,43 @@
 Section: python
 Priority: optional
 Maintainer: Debian systemd Maintainers 
-Uploaders: Michael Biebl ,
-   Martin Pitt 
+Uploaders: Michael Biebl , Martin Pitt 
 Standards-Version: 3.9.6
 Vcs-Git: git://anonscm.debian.org/pkg-systemd/python-systemd.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-systemd/python-systemd.git
 Homepage: http://www.freedesktop.org/wiki/Software/systemd
 X-Python3-Version: >=3.1
 Build-Depends: debhelper (>= 9),
+   dh-python,
libsystemd-dev,
-   python3-all-dev,
-   pkg-config
+   pkg-config,
+   python-all-dev,
+   python3-all-dev
+
+Package: python-systemd
+Section: python
+Priority: optional
+Architecture: linux-any
+Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
+Description: Python 2 bindings for systemd
+ This package contains Python 2 bindings for native access to the
+ systemd facilities.
+ .
+ Functionality is separated into a number of modules:
+  * systemd.journal supports sending of structured messages to the
+journal and reading journal files
+  * systemd.daemon wraps parts of libsystemd useful for writing daemons
+and socket activation
+  * systemd.id128 provides functions for querying machine and boot
+identifiers and a list of message identifiers provided by systemd
+  * systemd.login wraps parts of libsystemd used to query logged in
+users and available seats and machines
 
 Package: python3-systemd
 Section: python
 Priority: optional
 Architecture: linux-any
-Depends: ${shlibs:Depends},
- ${misc:Depends},
- ${python3:Depends}
+Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Description: Python 3 bindings for systemd
  This package contains Python 3 bindings for native access to the
  systemd facilities.
diff -Nru python-systemd-231/debian/rules python-systemd-231/debian/rules
--- python-systemd-231/debian/rules	2015-10-29 01:55:04.0 +0100
+++ python-systemd-231/debian/rules	2015-12-09 17:11:36.0 +0100
@@ -2,8 +2,9 @@
 
 #export DH_VERBOSE=1
 #export DEB_BUILD_OPTIONS="nostrip"
+export PYBUILD_NAME=systemd
 
 # Explicitly tell dh to use pybuild, otherwise it will pick the
 # makefile build system.
 %:
-	dh $@ --with python3 --buildsystem=pybuild --parallel
+	dh $@ --with python2,python3 --buildsystem=pybuild --parallel

Bug#807488: [buildd-tools-devel] Bug#807488: sbuild-update: please run -d with --no-install-recommends

[Adam Borowski]

On Wed, Dec 09, 2015 at 04:04:59PM +0100, Johannes Schauer wrote:
> Quoting Adam Borowski (2015-12-09 14:31:10)
> > As per apt's defaults, whenever a package that's a part of the sbuild chroot
> > gains a new Recommends:, that recommendation will be installed.  This
> > default makes sense for regular apt uses outside of sbuild, but in sbuild's
> > context, it goes against the aim of a minimal chroot.  It'll allow missing
> > build-dependencies to sneak through unnoticed, and makes fresh chroots
> > differ from updated ones.
> > 
> > Thus, please make sbuild-update pass --no-install-recommends to apt.
> 
> This is entirely reasonable and should be done that way but can you give me a
> way how to reproduce this problem?
> 
> I never experienced the problem myself and looking at the code in
> ResolverBase.pm it seems that sbuild already calls apt with a custom
> configuration file /var/lib/sbuild/apt.conf which contains
> 
> APT::Install-Recommends false;
> 
> So I don't understand how you got apt as used by sbuild installing Recommends.

There's such a file inside the chroot, yet on a rarely used box of mine I
got (from the scrollback):

[~]# sbuild-update -udcar jessie unstable

unstable: Performing update.
Get:1 http://apt.angband.pl:3142/ftp.pl.debian.org/debian unstable InRelease 
[263 kB]
Get:2 http://apt.angband.pl:3142/ftp.pl.debian.org/debian unstable/main 
Sources.diff/Index [9095 B]
Get:3 http://apt.angband.pl:3142/ftp.pl.debian.org/debian unstable/main armhf 
Packages.diff/Index [9095 B]
Get:4 http://apt.angband.pl:3142/ftp.pl.debian.org/debian unstable/main 
Translation-en.diff/Index [8385 B]
Get:5 http://apt.angband.pl:3142/ftp.pl.debian.org/debian unstable/main Sources 
[8549 kB]
Get:6 http://apt.angband.pl:3142/ftp.pl.debian.org/debian unstable/main armhf 
Packages [7776 kB]
Get:7 http://apt.angband.pl:3142/ftp.pl.debian.org/debian unstable/main 
Translation-en [5225 kB]
Fetched 21.8 MB in 9s (2372 kB/s)   

Reading package lists... Done
unstable: Performing dist-upgrade.
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  manpages
The following packages will be upgraded:
  apt bash binutils bsdmainutils cpp cpp-5 g++ g++-5 gcc gcc-5 gcc-5-base 
libapt-pkg5.0
  libarchive-zip-perl libasan2 libatomic1 libc-bin libc-dev-bin libc6 libc6-dev 
libcc1-0
  libdebconfclient0 libgcc-5-dev libgcc1 libgomp1 libreadline6 libstdc++-5-dev 
libstdc++6 libubsan0
  linux-libc-dev multiarch-support
30 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

I don't do backups for the filesystem with chroots, so I copied over my
jessie chroot over unstable, sed -i s/jessie/unstable/ and did:
[~]# sbuild-update -udcar unstable
<...>
Calculating upgrade... The following package was automatically installed and is 
no longer required:
  libasprintf0c2
Use 'apt-get autoremove' to remove it.
Done
The following NEW packages will be installed:
  cpp-5 dh-strip-nondeterminism g++-5 gcc-5 gcc-5-base libapt-pkg5.0 
libarchive-zip-perl libasan2
  libcc1-0 libfdisk1 libfile-stripnondeterminism-perl libgcc-5-dev libicu55 
libisl15 libprocps4
  libstdc++-5-dev manpages
The following packages will be upgraded:
  apt base-files base-passwd bash binutils bsdmainutils bsdutils 
build-essential bzip2 cpp cpp-4.9
  debconf debconf-i18n debhelper debianutils diffutils dpkg dpkg-dev e2fslibs 
e2fsprogs eatmydata file
  findutils g++ g++-4.9 gcc gcc-4.8-base gcc-4.9 gcc-4.9-base gettext 
gettext-base gnupg gpgv grep
  groff-base hostname init initscripts intltool-debian libasan1 libatomic1 
libaudit-common libaudit1
  libblkid1 libbz2-1.0 libc-bin libc-dev-bin libc6 libc6-dev libcap2 
libcap2-bin libcloog-isl4
  libcomerr2 libcroco3 libdb5.3 libdebconfclient0 libdpkg-perl libeatmydata1 
libffi6 libgc1c2
  libgcc-4.9-dev libgcc1 libgcrypt20 libglib2.0-0 libgmp10 libgomp1 
libgpg-error0 libkmod2
  liblocale-gettext-perl liblzma5 libmagic1 libmount1 libmpc3 libmpfr4 
libncurses5 libncursesw5
  libpcre3 libpipeline1 libreadline6 libselinux1 libsemanage-common 
libsemanage1 libsepol1 libslang2
  libsmartcols1 libss2 libstdc++-4.9-dev libstdc++6 libsystemd0 
libtext-wrapi18n-perl libtinfo5
  libubsan0 libudev1 libusb-0.1-4 libustr-1.0-1 libuuid1 libxml2 linux-libc-dev 
login lsb-base make
  man-db mount multiarch-support ncurses-base ncurses-bin passwd perl perl-base 
perl-modules po-debconf
  procps sed sysv-rc sysvinit-core sysvinit-utils tar tzdata udev util-linux 
xz-utils
121 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.

So it tries to install manpages again.


-- 
A tit a day keeps the vet away.

Bug#795832: [PATCH initramfs-tools] initramfs-tools: Support multiple break points using a comma delimiter

[Ben Hutchings]

Thanks for your patch, but I would prefer to avoid adding more sub-
shells.  Also, this change needs to be documented.  What do you t
hink of this patch?

Ben.
---
Closes: #795832
Signed-off-by: Ben Hutchings 
---
 initramfs-tools.8 | 3 ++-
 scripts/functions | 6 --
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/initramfs-tools.8 b/initramfs-tools.8
index ea8c098..a276be3 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -110,7 +110,8 @@ Use for example "debug=vc".
 spawns a shell in the initramfs image at the chosen phase
 (top, modules, premount, mount, mountroot, bottom, init)
 before actually executing the corresponding scripts
-(see the "Boot scripts" section) or action.
+(see the "Boot scripts" section) or action.  Multiple
+phases may be specified, delimited by commas.
 The default, if no phase is specified, is "premount".
 Beware that if both "panic" and "break" are present,
 initramfs will not spawn any shells but reboot instead.
diff --git a/scripts/functions b/scripts/functions
index 33fddcf..91d3407 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -61,9 +61,11 @@ panic()
 
 maybe_break()
 {
-   if [ "${break:-}" = "$1" ]; then
+   case ",$break," in
+   *,$1,*)
    panic "Spawning shell within the initramfs"
-   fi
+   ;;
+   esac
 }
 
 render()
-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

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

Bug#807494: ITP: ruby-omniauth-crowd -- OmniAuth provider for Atlassian Crowd REST API

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

package: wnpp
severity: wishlist
owner: Pirate Praveen 

rubygems.org/gems/omniauth_crowd
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWaEohAAoJEM4fnGdFEsIqiBwQAKp+KhxibCYvRS9cb1ESZaPp
bClN6IqWw2WW4kf+j6h8Cb1pZhybJeIjHaqpu1skjg6pI4++SZ+eenoydSCbXLjr
w//1oV2nuYsrqCyuhbaaoMDYpzH7Ub5W2f+nBv5kvt+qVKUqgB/y3bL4w3L0lveq
qD/7nBStv1JX+BIfgVwbfNdJjJY1KARll64yyzHhJ1ptC9at8oqPMH/CwbrSrTAc
P+6V3i4TVe0h+b6PCFRb/3F8G0GA4uic1WR9Iqa33GtlXlMS25tNFqHT7gyOZqbD
qdKpcBvqGnXpKc5Ovk/4u8de9+amrBb9lmDoNC56UlVKAgBHKi7yvwIOzj53p2lN
8hw0KKZGoByGSwL40QPI3a1g2VWUCKlJWfKt66oIBwxkaoYjx7zSrPEi+bIHW1DX
VnBd1C9qN8EaOXP08Mj0xcghXZu/6SRc2zLc0NxO9+2ZyFDROT6OHR05cVXddITm
yHrVVM4Z13vTE3P3SRfC7ip+hUfe3UyQxejrCIgP0Yuz3yH/XIv4l+TStD2Xg2PV
9GzboJnhG3RBf5lB/8GDgFpZRwS34NBp7WQt3cb5ZnASvN4nv+gqD4xWiTDEMyOJ
kpD3T9m4SEaPSSAUZtCLg7MSxr+tUKpLYpXx3wuAFsHgbWfwp8NxQdFZm+lGoM0I
au8r847JO5kSp2kJ6LVL
=UcHk
-END PGP SIGNATURE-

Bug#690701: Provide OS major/full version string

[Benjamin Drung]

Am Mittwoch, den 09.12.2015, 16:29 +0100 schrieb martin f krafft:
> also sprach Benjamin Drung  [2015-12
> -09 13:51 +0100]:
> > osrelease:
> > 8
> 
> This is what I was looking for.
> 
> > osrelease_info:
> > - 8
> 
> Will this be a list, e.g.
> 
>   - 8
>   - 1
>   - r2
> 
> For 8.1r2?

Yes, this is a list. 

On Debian, if you do not have lsb-release installed, VERSION_ID from
/etc/os-release will be used as source and this file omits the point
releases. So it only reports "8" instead of "8.2".

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.

Bug#807239: lftp: can no longer connect with sftp (no matching host key type found)

[Vincent Lefevre]

On 2015-12-09 15:18:44 +, Colin Watson wrote:
> On Wed, Dec 09, 2015 at 10:06:32AM +0100, Vincent Lefevre wrote:
> > This from is a SSH server for Android (and the user doesn't seem
> > to have a choice for the type of the host key).
> 
> Please report this to the maintainers of that server.  In the meantime
> you'll have to use legacy options.

I've just sent them a mail.

> > > This is unrelated to host key checking or IP checking.  It's about the
> > > type of underlying crypto being used to secure the connection.
> > 
> > According to what is documented, this appears to be related to
> > host key checking: the error mesage is "no matching *host key*
> > type found" and the option name is HostKeyAlgorithms. In what
> > way it could be insecure in the case where the user doesn't have
> > the key in the ~/.ssh/known_hosts file?
> 
> Weak host keys make it easier to conduct man-in-the-middle attacks.

My point is that with StrictHostKeyChecking = no and no keys for
the host in ~/.ssh/known_hosts, there is no host authentication,
so that a man-in-the-middle attack is already possible, even if
the server provides a strong key. Thus whether a weak host key
is provided by the server or not in this case shouldn't matter.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#746164: Conflicting declarations of function ks_init

[Andreas Tille]

On Fri, Oct 03, 2014 at 03:20:49PM -0400, Dominique Belhachemi wrote:
> 
> Hi Michael,
> 
> Does this still happen with htslib 1.1 ?
> How can we reproduce this? Which compiler did you use? Which architecture?

Ping?

Please note that we will close this bug in our advent bug squashing party if
there will be no response after more than one year.

Kind regards

   Andreas.


-- 
http://fam-tille.de

Bug#774109: htslib: FTBFS on hppa

[Andreas Tille]

Hi,

could you please verify whether this issue remains also for version 1.2.1?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#807485: gnome-keyring: pinentry-gnome3 should also be recommended and (hard) dependency should fallback on pinentry-gtk2

[Jonas Smedegaard]

Quoting Michael Biebl (2015-12-09 20:31:42)
> Am 09.12.2015 um 15:44 schrieb Jonas Smedegaard:
>> Currenly pinentry-gnome cannot be removed from a system which uses 
>> gnome-keyring
>
> Given the size of pinentry-gnome3, I'm not really worried about that.

My concern is not the size but functionality.

pinentry has multiple implementations, each with different features and 
drawbacks (look'n'feel, security deisgn etc).  Current package hints of 
gnome-keyring makes it needlessly difficult for non-GNOME users to favor 
a different implementation of pinentry than the one GNOME favors.

Relaxing to recommend permits non-GNOME users to simply avoid installing 
unwanted implementations of pinentry.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#807493: altree: Produces empty binary package

[Vincent Danjean]

  Hi,

Le 09/12/2015 16:31, Dominic Hargreaves a écrit :
> Source: altree
> Version: 1.3.1-3
> Severity: grave
> Justification: package not usable
> Tags: sid
> X-Debbugs-Cc: debian-p...@lists.debian.org
> 
> The last upload, fixing #807423, unfortunately started creating empty
> binary packages on most (but not all) architectures. See for example
> 
> https://packages.debian.org/sid/amd64/altree/filelist
> https://packages.debian.org/sid/armel/altree/filelist
> https://packages.debian.org/sid/armhf/altree/filelist
> https://packages.debian.org/sid/i386/altree/filelist
> 
> I can't see from a quick glance what is going on here; CC-ing
> debian-perl in case anyone can help.

  It is an error from me. altree files are now installed in debian/tmp
instead of directly debian/altree by debian/rules, so a debian/altree.install
file is required.
  I will fix this in a few hours if nobody do it before. And I will
reincorporate Andreas modifications that were all good.

  Regards,
Vincent

> Cheers,
> Dominic.
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#807496: python-systemd: Please provide Python 2 version of python-systemd

[Michael Biebl]

Hi

Am 09.12.2015 um 17:18 schrieb Benjamin Drung:
> Package: python-systemd
> Version: 231-1
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> salt 2015.8.3+ds-1 requires python-systemd since it does not yet support
> Python 3.

Is that process tracked somewhere?
We deliberately dropped python-systemd a while ago [1] since it had no
reverse dependencies and we didn't want new packages picking up a
python2 dep.


> PS: The patch also includes a run of wrap-and-sort.

Please use wrap-and-sort -a to avoid needless churn.


[1]
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=44bbbcf93da59db1e60d3049348e605122fffb7a
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#540978: aptitude: Aptitude makes the wrong choice when resolving conflict with alternative package

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Josh,

2009-08-11 04:02 Josh Triplett:

Package: aptitude
Version: 0.4.11.11-1+b2
Severity: normal

I have a metapackage josh-gui, which among other things depends on
totem-xine and conflicts with totem-gstreamer.  Various packages depend
on totem-gstreamer | totem-xine, such as gnome-desktop-environment and
totem-plugins.  Whenever a new version of totem comes out, and I attempt
to upgrade to it (usually by hitting + on the "video" section including
totem-common, totem-xine, and totem-plugins), aptitude gets confused: it
attempts to pull in totem-gstreamer (despite not needing it to satisfy
any dependencies, with totem-xine already installed), and it then
correctly concludes that it has broken josh-gui.  Furthermore, to fix
this brokenness, it initially proposes removing josh-gui; its *second*
solution does the right thing by choosing *not* to install
totem-gstreamer in the first place.


Have you seen this behaviour recently, with this package of yours or
others?

The resolution system changed a lot in the years after this bug report,
specially with 0.6.  I could attempt to reproduce a similar case with
other packages (totem-xine and -gstreamer are not in unstable now), but
if you continue to have a similar set-up it would be quicker / more
reliable to confirm if the behaviour it's still happening as you saw it
in the past.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#807495: python-pygments: add -g parameter to pygmentize man page

[Stéphane Blondon]

Package: python-pygments
Version: 2.0.1+dfsg-1.1
Severity: minor
Tags: patch

Hello,

`pygmentize -h` documents the -g parameter but the manual page doesn't
provide information about it.

(-g can be used instead of the -l parameter).

I think the ma, page should provide this information so I copied-pasted
the documentation from `pygmentize -h` output into pygmentize.1 (see
pygmentize.1.diff in attachment).

In the attached diff, I updated the date too.


Stéphane

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

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

Versions of packages python-pygments depends on:
ii  python  2.7.9-1
pn  python:any  

Versions of packages python-pygments recommends:
ii  python-chardet2.3.0-1
ii  python-pkg-resources  18.4-2

Versions of packages python-pygments suggests:
pn  ttf-bitstream-vera  

-- no debconf information
--- pygmentize.1.orig	2015-12-09 16:35:21.0 +0100
+++ pygmentize.1	2015-12-09 16:38:47.0 +0100
@@ -1,11 +1,11 @@
-.TH PYGMENTIZE 1 "February 15, 2007"
+.TH PYGMENTIZE 1 "December 9, 2015"
 
 .SH NAME
 pygmentize \- highlights the input file
 
 .SH SYNOPSIS
 .B \fBpygmentize\fP
-.RI  [-l\ \fI\fP]\ [-F\ \fI\fP[:\fI\fP]]\ [-f\ \fI\fP]
+.RI  [-l\ \fI\fP\ |\ -g]\ [-F\ \fI\fP[:\fI\fP]]\ [-f\ \fI\fP]
 .RI  [-O\ \fI\fP]\ [-P\ 

Bug#795839: initramfs-tools: When adding i8042 also add psmouse as some keyboards are behind the mouse

[Ben Hutchings]

Control: tag -1 pending

On Mon, 17 Aug 2015 11:36:29 +0100 Andy Whitcroft  wrote:
> Package: initramfs-tools
> Version: 0.120
> Severity: normal
> 
> hook-functions/auto_add_modules: include psmouse as some keyboards are
> connected to the "pass-thru" port on the PS2 mouse port (because that is
> such a good idea).

Applied, thanks.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

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

Bug#807493: altree: Produces empty binary package

[Sebastiaan Couwenberg]

On 09-12-15 16:31, Dominic Hargreaves wrote:
> The last upload, fixing #807423, unfortunately started creating empty
> binary packages on most (but not all) architectures. See for example
> 
> https://packages.debian.org/sid/amd64/altree/filelist
> https://packages.debian.org/sid/armel/altree/filelist
> https://packages.debian.org/sid/armhf/altree/filelist
> https://packages.debian.org/sid/i386/altree/filelist
> 
> I can't see from a quick glance what is going on here; CC-ing
> debian-perl in case anyone can help.

This change seems to be the cause:

-override_dh_auto_install:
-   $(MAKE) PREFIX=debian/altree/usr install
-

Because there is no install file, the files in debian/tmp are not
installed in any package, only the documentation gets installed via the
docs files.

Adding an altree.install file to install the files in debian/tmp/usr is
probably sufficient.

Kind Regards,

Bas

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

Bug#807045: winetricks output: wineserver not found!

[Jens Reyer]

On 12/09/2015 03:17 PM, Joseph Bisch wrote:
> Hi,
> 
> It looks like libwine or libwine-development should be a dependency of
> winetricks, since winetricks doesn't appear to run without wineserver,
> and wineserver is part of libwine. See this page for the package info:
> [0].
> 
> It looks like you can trace the dependency chain from wine to libwine
> on Wheezy and earlier releases, but starting with Jessie, libwine is
> no longer part of the recursive dependencies of wine.

No, not exactly. Even in Jessie/Stretch libwine is always installed if
you install wine, because:
- wine depends on wine32 OR wine64
- wine32 depends on libwine:i386 [1]
- wine64 depends on libwine:amd64

So you'll always end up with a libwine (or several), the question is
only from which architectures they are.
What I suspected is that only wine64 and libwine:amd64 are installed,
and winetricks can't cope with that. And I verified that - indeed this
results in the mentioned problem.

So you either install wine32 additionally to the already installed
wine64 (recommended), or you do the following (with only wine64 installed:
  export WINESERVER=/usr/lib/x86_64-linux-gnu/wine/wineserver
  export WINEPREFIX="$HOME/.wine64"
  winetricks

The same/similar is true for the -development packages.

I'd suggest to maybe add the wine64-only workaround to the README and
change the depends to the following:

  wine32|wine32-development|wine64|wine64-development

This removes unnecessary duplicates and expresses that 32-bit is
preferred to 64-bit and stable to -development.

However IMO it is NOT feasible to only depend on 32-bit packages,
because they are not available in every setup.

Greets
jre


[1]: simplifying with "i386" and "amd64" here, but this matches exactly
the system the bug was reported from: e.g. wine32 is available on /some/
32-bit architectures and depends on libwine of the same architecture.

Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with altivec keyword bool

[J Price]

On 9 December 2015 at 13:17, Fernando Seiti Furusato
 wrote:
>
>> Reading some other bug reports (e.g. [1]) suggests that compiling with
>> `-std=gnu++11` instead of `-std=c++11` also fixes the problem. Is this
>> a viable workaround? This would be a simple patch to CMakeLists.txt.
>
> In case this question was directed to me -- it is viable in the sense that
> it
> works. Just tested it here and it built.

OK, if Andreas is happy with this fix I'll commit this instead.

James

Bug#650132: hint: binary to source mapping has unhelpful side-effects

[Julien Cristau]

On Fri, Dec  4, 2015 at 19:09:47 +, Adam D. Barratt wrote:

> diff --git a/scripts/hint b/scripts/hint
> index 9d38274..3b3b1ee 100755
> --- a/scripts/hint
> +++ b/scripts/hint
> @@ -513,9 +513,11 @@ class Hint(object):
>  
>  ##
>  
> -def __init__(self, hintname, *args):
> +def __init__(self, hintname, *args, **kwargs):

I'd prefer an explicit 'update' kwarg, defaulting to True.  That'd not
give the impression that we're going to do anything with arbitrary
kwargs, be more self-documenting, and avoid a 'noupdate=False' confusing
double negation.

Thanks,
Julien


signature.asc
Description: PGP signature

Bug#807391: libcommons-openpgp-java: FTBFS: BouncyCastleOpenPgpStreamingSignatureVerifier.java:92: error: cannot find symbol [..] sig.initVerify( key, "BC" );

[Markus Koschany]

Am 09.12.2015 um 05:32 schrieb tony mancill:
> On 12/08/2015 04:14 AM, Chris Lamb wrote:
>> Source: libcommons-openpgp-java
>> Version: 0+svn533492-5
>> Severity: serious
>> Justification: fails to build from source
>> User: reproducible-bui...@lists.alioth.debian.org
>> Usertags: ftbfs
>> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> I can't find any reverse dependencies for this package.  Any objections
> to requesting its removal?

It seems I missed this build failure during my bouncycastle tests. Last
updaet was in 2013 and in my opinion a crypto library should be better
maintained than that, especially if it depends on such a fragile library
like bouncycastle. No objections from me.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#807470: s3t/install: please incude zipl/chreipl dm helper

[Hendrik Brueckner]

Control: tags: -1 + patch

Bug#807150: gubbins: FTBFS on i386: Invalid ALN file for multiple lines per seq

[Andreas Tille]

Hi Andrew,

I just uploaded the new version to Debian unstable.  Please note that you 
somehow
missed to add -lsubunit to src/Makefile.am.  I adapted the Debian patch for the
new version:

   
https://anonscm.debian.org/cgit/debian-med/gubbins.git/tree/debian/patches/add_missing_lib_for_check.patch

Thanks for your support

  Andreas.

On Wed, Dec 09, 2015 at 03:57:41PM +, Andrew Page wrote:
> Hi,
> I have pushed a fix for the build error on i386 as version 1.4.4
> Details are here:
> https://github.com/sanger-pathogens/gubbins/pull/158 
> 
> 
> I replicated the bug on i386 and fixed it. The tests also pass on amd64 & OSX 
> 10.10
> 
> Regards,
> Andrew
> 
> 
> > On 6 Dec 2015, at 06:40, Andreas Tille  wrote:
> > 
> > Hi Andrew,
> > 
> > I hereby forward a build issue on i386 architecture.
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > On Sat, Dec 05, 2015 at 10:30:32PM -0500, Aaron M. Ucko wrote:
> >> Source: gubbins
> >> Version: 1.4.3-1
> >> Severity: important
> >> Justification: fails to build from source
> >> 
> >> The i386 build of gubbins failed:
> >> 
> >>  FAIL: run_all_tests
> >>  
> >> 
> >>  Testsuite summary for gubbins 1.4.3
> >>  
> >> 
> >>  # TOTAL: 1
> >>  # PASS:  0
> >>  # SKIP:  0
> >>  # XFAIL: 0
> >>  # FAIL:  1
> >>  # XPASS: 0
> >>  # ERROR: 0
> >>  
> >> 
> >>  See src/test-suite.log
> >> 
> >> I was able to reproduce the error in an i386 chroot, yielding the following
> >> details:
> >> 
> >>  FAIL: run_all_tests
> >>  ===
> >> 
> >>  Running suite(s): Creating_SNP_Sites
> >>   Parsing a phylip file
> >>   Parsing a vcf file
> >>   checking branch sequences
> >>   Checking the gubbins functionality
> >>   snp_searching
> >>  94%: Checks: 39, Failures: 2, Errors: 0
> >>  
> >> ../tests/check_snp_sites.c:73:F:snp_sites:valid_alignment_with_multiple_lines_per_sequence:0:
> >>  Invalid ALN file for multiple lines per seq
> >>  ../tests/check_snp_sites.c:85:F:snp_sites:two_sequences:0: Invalid ALN 
> >> file for multiple lines per seq
> >>  FAIL run_all_tests (exit status: 1)
> >> 
> >> Could you please take a look?
> >> 
> >> Thanks!
> >> 
> >> ___
> >> Debian-med-packaging mailing list
> >> debian-med-packag...@lists.alioth.debian.org
> >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> >> 
> > 
> > -- 
> > http://fam-tille.de
> 
> 
> 
> 
> -- 
>  The Wellcome Trust Sanger Institute is operated by Genome Research 
>  Limited, a charity registered in England with number 1021457 and a 
>  company registered in England with number 2742969, whose registered 
>  office is 215 Euston Road, London, NW1 2BE. 
> 
> 

-- 
http://fam-tille.de

Bug#807499: postgis: Build with Maven 3

[Emmanuel Bourg]

Source: postgis
Version: 2.1.8
Severity: normal

Hi,

The maven2 package is going to be removed and postgis is the last package
depending on it. Could you please switch to the maven package instead?

Thank you,

Emmanuel Bourg

Bug#805847: libnet-mac-vendor-perl: Apache/mod_perl silently does not start if Net::MAC::Vendor 1.25-1 is used (regression from 1.23-1)

[Niko Tyni]

On Mon, Nov 23, 2015 at 04:35:07PM -0800, Ivan Kohler wrote:
> On Mon, Nov 23, 2015 at 08:52:34PM +0200, Niko Tyni wrote:
> > FWIW I can't reproduce this
> > [...]
> > So you'll need to provide more information so the Apache problem
> > can be reproduced.
> 
> I was able to reproduce with this configuration:
> 
>   PerlRequire "/home/ivan/apache2/handler.pl"
> 
> and handler.pl is:
> 
>   #!/usr/bin/perl
>   use Net::MAC::Vendor;
>   1;
> 
> I'm not completely sure what's different internally that's triggering 
> the failure.  PerlRequire is preloaded during server startup, but 
> PerlHandler isn't called until the child process is handling the 
> request?

Thanks for the recipe. I looked into this a bit, and replacing 'use
Net::MAC::Vendor' with 'use EV' triggers it too. Apache dies with SIGSEGV,
backtrace below. It goes away if libev-perl is built with EV_NO_ATFORK
defined, so it's the __register_atfork() call in EV.xs:541 or so that
causes it somehow. Presumably the event loop hooking into fork() breaks
when it's mod_perl2 doing the forking.

Seeing the upstream response in [rt.cpan.org #110019], I don't plan to
do any further work on this issue. Sorry. Hope this helps a bit anyway.


Core was generated by `apache2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f76efa2ef80 in ?? ()
(gdb) bt full
#0  0x7f76efa2ef80 in ?? ()
No symbol table info available.
#1  0x7f76f433f90f in __libc_fork () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:188
self = 
now = 
pid = 0
allp = 0x7ffcdb0b7bd0
runp = 
ppid = 
parentpid = 
__PRETTY_FUNCTION__ = "__libc_fork"
#2  0x7f76f4875585 in apr_proc_detach () from 
/usr/lib/x86_64-linux-gnu/libapr-1.so.0
No symbol table info available.
#3  0x7f76f15b0c1b in prefork_pre_config (p=0x7f76f512f028, plog=, ptemp=)
at prefork.c:1376
no_detach = 0
debug = 
foreground = 
rv = 
userdata_key = 0x7f76f15b21fc "mpm_prefork_module"
#4  0x560f94b449be in ap_run_pre_config (pconf=0x7f76f512f028, 
plog=0x7f76f50fd028, ptemp=0x7f76f50ff028)
at config.c:89
pHook = 
n = 3
rv = 0
#5  0x560f94b22f4b in main (argc=1, argv=0x7ffcdb0b7e28) at main.c:733
c = 0 '\000'
showcompile = 0
showdirectives = 0
confname = 0x560f94b66cc2 "apache2.conf"
def_server_root = 0x560f94b66cb5 "/etc/apache2"
temp_error_log = 0x0
error = 
process = 0x7f76f5131118
pconf = 0x7f76f512f028
plog = 0x7f76f50fd028
ptemp = 0x7f76f50ff028
pcommands = 0x7f76f510d028
opt = 0x7f76f510d118
rv = 
mod = 0x560f94d89160 
opt_arg = 0x7f76f5131028 "(P\023\365v\177"
signal_server = 

-- 
Niko Tyni   nt...@debian.org

Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 09 Dec 2015 16:40:21 + Bart Martens
 wrote:
> Package udfclient has been removed from mentors.
> 
> 
Hi Pali, did you forget to update the package?

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWaF9ZAAoJEPNPCXROn13ZzAsP+wUPI+2gpA/qhbsx5SC9hkZE
WGqdUrcB84lt4DeL/xXK3ipEQEjJ1x4sXuW0yI9RuG4uapcIK8+53+0981v0We3E
+06ySBn8vhVIrvBREgTvWogc51nQ9NDFmQSwWfYePnerRe5Y17lUEWvZoj7tEmgT
z0yr83v8r7vt7IrmDMW8wTSkMun3QRlTCk/xWERvo3JpMnyJ1FJXuiDz9s1H7W3u
eucSephtxydV9wAEUEfW0FItFLN4BvB9YY4tVGqYkauBW/ul3yQdgUi+O3iKnPEh
nQMHl6v5seKH4zumNRjPcfKR/MtMB0xbjvKurpY+Rh0kquqO2r3qipcYXloA7+uO
JcHeVvq51ACS8BtfsZouokP1wvMHkxpV5Lc5cmhhnCZgd0nsjWMCzBEOANEJtgvC
HkHE2fz9V3m1f+xp6/FKyHY7zDN0naPOCn55h/RxXDcK/FWFFOJOQ0lKtHXfS9vl
GjZghN+uxU5hCCtudgtFTrQ/H3oCQCqm1cvMbh3do3Eg9wQKxJo0nP2IcUnR8ioO
vB7mzO8NHZ5C0/7PUAmyarV2BfyHMfpnkmTM5KtjEZx/bS3b23ftdq8AvDBH8qZR
GI447v8xZzEkKRhPHr+KJhVpyYXNg4ih/RgSgXBT/cjrPZCEU+QIhxHQi6xiei/v
Opau3f/lC6nJZOqc+sYu
=yxMb
-END PGP SIGNATURE-

Bug#807502: gcc-avr: Missing support for atxmega384d3 since last upload

[Lisandro Damián Nicanor Pérez Meyer]

Package: gcc-avr
Version: 1:4.9.2+Atmel3.5.0-1
Severity: serious
Justification: Makes package unusable

Hi Hakan! After the latests update my AtXmega384d3-based project started to 
FTBFS:

avr-gcc -Isrc  -std=gnu99 -mmcu=atxmega384d3 -Wall -gdwarf-2 -O1 
-funsigned-char -MD -MP -MT settings_asm.o -MF dep/settings_asm.o.d -x 
assembler-with-cpp -Wa,-gdwarf2 -c src/settings_asm.S -o src/settings_asm.o
avr-gcc -mmcu=atxmega384d3 -Wl,--section-start=.BOOT=0x06 src/source1.o 
src/source2.o src/source3.o src/core.o src/source4.o [...] src/main.o src -o 
project.elf
/usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find crtatxmega384d3.o: No 
such file or directory
/usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find -latxmega384d3
collect2: error: ld returned 1 exit status
Makefile:91: recipe for target 'project.elf' failed
make: *** [project.elf] Error 1

Thanks for your work!

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

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

Versions of packages gcc-avr depends on:
ii  binutils-avr  2.25+Atmel3.5.0-1
ii  libc6 2.21-3
ii  libgmp10  2:6.1.0+dfsg-2
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-1
ii  zlib1g1:1.2.8.dfsg-2+b1

gcc-avr recommends no packages.

Versions of packages gcc-avr suggests:
ii  avr-libc  1:1.8.0+Atmel3.4.5-1
ii  gcc   4:5.2.1-8
pn  gcc-doc   
pn  task-c-devel  

-- no debconf information

Bug#807499: postgis: Build with Maven 3

[Emmanuel Bourg]

Le 9/12/2015 18:30, Sebastiaan Couwenberg a écrit :

> If you want to remove the maven2 package we can move postgis &
> postgis-java from experimental and do a mini transition twice, only
> spatialite is affected so it's not much of a problem. I'm getting tired
> of waiting for PostGIS 2.2.1, so this issue could be sufficient reason
> to not wait any longer.

Thank you for the info Sebastiaan. There is no urgency to remove maven2
and we can wait for postgis-java. There is plenty of time before the
next freeze.

Emmanuel