Bug#850083: libgl1-mesa-glx: Driver radeonsi_dri not in expected directory /usr/lib32/dri/tls/

[Michel Dänzer]

On 04/01/17 08:00 AM, Andy Johnstone wrote:
> Package: libgl1-mesa-glx
> Version: 13.0.2-3
> Severity: important
> Tags: d-i
> 
> Dear Maintainer,
> 
> After installing all required dependencies for 3D graphics (Radeon RX480) on 
> debian stretch amd64, no applications requiring 3D would start.
> 
> I am struggling to determine where/to whom this bug should be reported, 
> please forward as necessary.
> 
> Running LIBGL_DEBUG=verbose glxinfo
> Revealed the following:
> 
> name of display: :0
> libGL: Can't open configuration file /home/tux/.drirc: No such file or 
> directory.
> libGL: pci id for fd 4: 1002:67df, driver radeonsi
> libGL: OpenDriver: trying /usr/lib32/dri/tls/radeonsi_dri.so
> libGL: OpenDriver: trying /usr/lib32/dri/radeonsi_dri.so
> libGL: dlopen /usr/lib32/dri/radeonsi_dri.so failed 
> (/usr/lib32/dri/radeonsi_dri.so: cannot open shared object file: No such file 
> or directory)
> 
> The driver is installed, but at location:
> /usr/lib/x86_64-linux-gnu/dri/
> 
> Creating a symlink at /usr/lib32/dri/tls/ allows all 3D applications to run 
> normally:
> ln -s /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so radeonsi_dri.so

What does

 env | grep PATH

say in a shell which is affected by the problem?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#850213: vmdebootstrap: fix for hangs with custom packages

[Antoine Beaupré]

Control: tags -1 +patch

Here's a patch to fix this.

>From 1ddf84046d314e8fafec4266d701be17c08b458f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Thu, 5 Jan 2017 02:23:24 -0500
Subject: [PATCH] install custom packages non-interactively (Closes: #850213)

this was happening because some of the prompts were hidden during
debootstrap, and would show up during the apt-get install -y run that
is triggered after dpkg -i when installing custom packages.
---
 bin/vmdebootstrap | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/bin/vmdebootstrap b/bin/vmdebootstrap
index d9a697d..9f0c7fd 100755
--- a/bin/vmdebootstrap
+++ b/bin/vmdebootstrap
@@ -467,6 +467,17 @@ class VmDebootstrap(cliapp.Application):  # pylint: disable=too-many-public-meth
 # return to doing swap setup
 base.make_swap(extent)
 
+def _non_interactive_env(self):
+'''set a noninteractive debconf environment'''
+env = {
+"DEBIAN_FRONTEND": "noninteractive",
+"DEBCONF_NONINTERACTIVE_SEEN": "true",
+"LC_ALL": "C"
+}
+# merge with complete environment
+env.update(os.environ)
+return env
+
 def _bootstrap_packages(self):
 base = self.handlers[Base.name]
 uefi = self.handlers[Uefi.name]
@@ -483,14 +494,6 @@ class VmDebootstrap(cliapp.Application):  # pylint: disable=too-many-public-meth
 
 def _debootstrap_second_stage(self, rootdir):
 base = self.handlers[Base.name]
-# set a noninteractive debconf environment for secondstage
-env = {
-"DEBIAN_FRONTEND": "noninteractive",
-"DEBCONF_NONINTERACTIVE_SEEN": "true",
-"LC_ALL": "C"
-}
-# add the mapping to the complete environment.
-env.update(os.environ)
 # First copy the binfmt handler over
 base.message('Setting up binfmt handler')
 shutil.copy(self.settings['foreign'], '%s/usr/bin/' % rootdir)
@@ -498,7 +501,7 @@ class VmDebootstrap(cliapp.Application):  # pylint: disable=too-many-public-meth
 base.message('Running debootstrap second stage')
 runcmd(['chroot', rootdir,
 '/debootstrap/debootstrap', '--second-stage'],
-   env=env)
+   env=self._non_interactive_env())
 
 def debootstrap(self, rootdir):
 base = self.handlers[Base.name]
@@ -541,7 +544,8 @@ class VmDebootstrap(cliapp.Application):  # pylint: disable=too-many-public-meth
 logging.debug('stdout:\n%s', out)
 logging.debug('stderr:\n%s', err)
 out = runcmd(['chroot', rootdir,
-  'apt-get', '-y', '-f', '--no-remove', 'install'])
+  'apt-get', '-y', '-f', '--no-remove', 'install'],
+ env=self._non_interactive_env())
 logging.debug('stdout:\n%s', out)
 shutil.rmtree(tmp)
 
-- 
2.11.0


Can also be reviewed or pulled directly from:

https://gitlab.com/anarcat/vmdebootstrap/commit/1ddf84046d314e8fafec4266d701be17c08b458f

or the git repo at:

https://gitlab.com/anarcat/vmdebootstrap/

850213-non-interactive branch.

A.

-- 
If builders built houses the way programmers built programs,
The first woodpecker to come along would destroy civilization.
- Gerald Weinberg

Bug#850205: automatic serial console configuration for jessie and above

[Antoine Beaupré]

Package: vmdebootstrap
Followup-For: Bug #850205

I may be mistaken: during my tests, it seems that the serial console
is enabled, regardless of the --serial-console setting, in stretch.

That being said: the flag should still be removed if it has no
effect, or at least deprecated and then removed in the future.

Documentation (in particular the manpage) should also be updated to
reflect the new policy.

Bug#850222: ITP: node-plur -- Pluralize a word

[Lars Wirzenius]

On Thu, Jan 05, 2017 at 01:05:09PM +0530, Abhishek Lolage wrote:
> * URL : https://github.com/sindresorhus/plur
>   Description : Pluralize a word

The package description should make it clear this code only works for
English.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#814030: Security flaw fixed in version 6.2.0

[David Prévot]

Hi,

I just add maintainer and uploader to the loop. Hopefully, they should
know something about the package/code/issue.

Le 04/01/2017 à 21:42, Salvatore Bonaccorso a écrit :

> On Sun, Mar 27, 2016 at 01:33:01PM +0200, Moritz Mühlenhoff wrote:
>> On Sun, Feb 07, 2016 at 02:28:04PM -0400, David Prévot wrote:
>>> Package: php-tcpdf
>>> Version: 6.0.093+dfsg-1
>>> Severity: serious
>>> Tags: security upstream
>>>
>>> According to their changelog [1], upstream fixed a security issue over a
>>> year ago:
>>>
>>> 6.2.0 (2014-12-10)
>>> - Bug #1005 "Security Report, LFI posting internal files externally 
>>> abusing default parameter" was fixed.
>>>
>>> 1: https://sourceforge.net/p/tcpdf/code/ci/master/tree/CHANGELOG.TXT
>>>
>>> The upstream bug report [2] is not public, so I don’t have much
>>> information about the issue, the fix, nor it’s actual severity.
>>>
>>> 2: https://sourceforge.net/p/tcpdf/bugs/1005/
>>
>> Can you contact upstream for information on this security bug? I have
>> no idea what that could possibly mean.
> 
> Did you got any information on that from upstream? The bug is stil
> closed, so does not really help.
> 
> Regards,
> Salvatore




signature.asc
Description: OpenPGP digital signature

Bug#850225: libcatmandu-importer-getjson-perl: warnings when libjson-xs-perl is not installed

[Niko Tyni]

Package: libcatmandu-importer-getjson-perl
Version: 0.50-1
Severity: minor
User: debian-p...@lists.debian.org
Usertags: autopkgtest

As noticed by the autopkgtest checks on ci.debian.net
 
http://ci.debian.net/packages/libc/libcatmandu-importer-getjson-perl/unstable/amd64/

this package recently started to warn when used:

 % perl -we 'use Catmandu::Importer::getJSON'
 Subroutine JSON::PP::Boolean::(++ redefined at 
/usr/share/perl/5.24/overload.pm line 50.
 Subroutine JSON::PP::Boolean::(-- redefined at 
/usr/share/perl/5.24/overload.pm line 50.
 Subroutine JSON::PP::Boolean::(0+ redefined at 
/usr/share/perl/5.24/overload.pm line 50.

This only happens when libjson-xs-perl is not installed, which can happen
for instance when installing with 'apt --no-install-recommends'.

The change was probably triggered by libcatmandu-perl_1.034-[12] adding
a dependency on libcpanel-json-xs-perl. This seems to be an issue between
Cpanel::JSON::XS and JSON::PP, see
 https://github.com/rurban/Cpanel-JSON-XS/issues/65

Not sure what to do about it, this all seems a mess. #842464 is similar.
-- 
Niko Tyni   nt...@debian.org

Bug#850226: no longer advertises route

[Steinar H. Gunderson]

Package: quagga-bgpd
Version: 1.1.0-3
Severity: grave

Hi,

I lost all of my IPv6 connectivity this morning; a bit of searching shows that
it is due to an automated upgrade of:

  2017-01-05 07:36:26 upgrade quagga:amd64 1.0.20160315-2 1.1.0-3

None of the neighbors see my IPv6 route anymore; it is not in the table,
and the peers (over various GRE tunnels, using link-local addresses) say:

  altersex# show bgp neighbors fe80::5ccc:2ed1 routes 
  altersex# 

Similarly for another Quagga peer:

  pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes 
  pannekake.samfundet.no# 

My side claims it's advertising the network to one of them, though:

  morgental# show bgp neighbors fe80::c30b:9a61 advertised-routes 
  BGP table version is 0, local router ID is 80.218.216.227
  Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
  Origin codes: i - IGP, e - EGP, ? - incomplete
  
 Network  Next HopMetric LocPrf Weight Path
  *> 2001:67c:29f4::/48
  fe80::5ccc:2ed1600  0 58302 i

But somehow not to the other one:

  morgental# show bgp neighbors fe80::6bbf:a185 advertised-routes 
  morgental# 

Restart of the daemon does not work, but downgrading Quagga back to
the previous version (1.0.20160315-3) immediately fixes the issue:

  pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes 
  BGP table version is 0, local router ID is 129.241.93.35
  Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
  Origin codes: i - IGP, e - EGP, ? - incomplete
  
 Network  Next HopMetric LocPrf Weight Path
  *> 2001:67c:a4::/48 :: 600 0 48908 i
  
  Total number of prefixes 1
  pannekake.samfundet.no# 

Here's the entire Quagga config, for reference:

morgental# show run
Building configuration...

Current configuration:
!
hostname morgental
log file /var/log/quagga/quagga.log
log file /var/log/quagga/ospf6d.log
hostname fugl
log file /var/log/quagga/bgpd.log
bgp multiple-instance
!
service advanced-vty
!
debug ospf6 lsa unknown
debug bgp
!
password 
enable password 
!
interface bablefisk
 no link-detect
!
interface br0
 no link-detect
!
interface elfkin
 no link-detect
!
interface eno1
 no link-detect
!
interface enp2s0
 no link-detect
!
interface enp2s0.2
 no link-detect
!
interface enp2s0.3
 no link-detect
!
interface enp2s0.10
 no link-detect
!
interface enp2s0.11
 no link-detect
!
interface eth0
 no link-detect
!
interface eth0.2
 no link-detect
!
interface eth0.3
 no link-detect
!
interface eth0.4
 no link-detect
!
interface eth0.5
 no link-detect
!
interface eth0.10
 no link-detect
!
interface eth0.11
 no link-detect
!
interface eth0.2000
 no link-detect
!
interface eth2
 no link-detect
!
interface fnismc
 no link-detect
!
interface foo
 no link-detect
!
interface gre0
 no link-detect
!
interface gretap0
 no link-detect
!
interface he-ipv6
 no link-detect
!
interface ifb0
 no link-detect
!
interface ifb1
 no link-detect
!
interface ip6gre0
 no link-detect
!
interface ip6tnl0
 no link-detect
!
interface k_adamcik
 no link-detect
!
interface k_altersex
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_berge
 no link-detect
!
interface k_jodal
 no link-detect
!
interface k_klette
 no link-detect
!
interface k_kletteoslo
 no link-detect
!
interface k_magne
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_molven
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_molvenfinnoy
 no link-detect
!
interface k_pannekake
 no link-detect
!
interface k_sandsmark
 no link-detect
!
interface k_sesse
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_torvaldl
 no link-detect
!
interface k_trygve
 no link-detect
!
interface k_underworld
 no link-detect
!
interface k_wikene
 no link-detect
!
interface k_xml
 no link-detect
!
interface l2tpeth0
 no link-detect
!
interface lo
 no link-detect
!
interface merete
 no link-detect
!
interface nat64
 no link-detect
!
interface pan0
 no link-detect
!
interface pimreg
 no link-detect
!
interface renater
 no link-detect
!
interface sit0
 no link-detect
!
interface test
 no link-detect
!
interface tungre
 no link-detect
!
interface wlan0
 no link-detect
!
interface wlp3s0
 no link-detect
!
interface wmaster0
 no link-detect
!
router bgp 48908
 bgp router-id 80.218.216.227
 bgp always-compare-med
 bgp bestpath med missing-as-worst
 neighbor kvadratsky peer-group
 neighbor kvadratsky next-hop-self
 neighbor kvadratsky soft-reconfiguration inbound
 neighbor kvadratsky prefix-list kvadratsky in
 neighbor 2001:470:12:84::1 remote-as 6939
 neighbor 2001:470:12:84::1 update-source 2001:470:12:84::2
 neighbor 2001:470:12:84::1 next-hop-self
 neighbor 2001:470:12:84::1 soft-reconfigurati

Bug#850227: singularity-container: homepage URL link is broken

[Afif Elghraoui]

Package: src:singularity-container
Version: 2.2-1
Severity: minor

Hello,

The homepage URL is a dead link. I believe you want 
.

I haven't checked the source URL or d/watch, but that might be bad as well.
The source is at .
You're good on the latest upstream release according to that, though.

Thanks and regards
Afif

Bug#692754: how to get the username in the plugin?

[Johannes Berg]

On Thu, 2017-01-05 at 08:34 +1100, martin f krafft wrote:
> also sprach Johannes Berg  [2017-01-05
> 01:11 +1100]:
> > I'm not even sure how to get the username? Is it even generally
> > possible, if e.g. the plugin is running out of a process that's not
> > invoked through the imapd?
> 
> Well, the plugin certainly does seem to be run as the target user,
> or else how could it be used for user-specific training?

Well, it doesn't necessarily run as the target user - it just runs with
the target user's mailbox :)

Dovecot (virtual) users aren't necessary system users, after all.

johannes

Bug#692754: how to get the username in the plugin?

[Johannes Berg]

On Thu, 2017-01-05 at 13:21 +1030, Ron wrote:

> > Or worst case, we could make one, and let people do something like:
> > 
> >  antispam_log_prefix = %u

Interesting, yes, that would probably be easiest.

> > Martin, what _actual_ problem did you have to make you want this?
> > That might be something we can (also?) fix better and simpler?
> 
> Just to be clear, there's a lot of permutations here about what
> backend might be run (and you didn't say which you are using),
> and usually the only case where the user might actually matter,
> we're passing that user to an external program (and don't have
> any control over what it outputs) ...
> 
> So in most of what -antispam might log, any failure isn't going
> to be due to something "user specific" - which means it would be
> good to know exactly what problem you hit that (you thought?) was.
> 
> Otherwise, this could just turn into lots of intrusive busywork
> that doesn't actually solve it, if we don't know what "it" was.

Well, it's not going to be a lot of work, especially if we make it a
configuration and restrict it to the debug code, but I agree - knowing
what the use case is/was would be useful.

johannes

PS: Ron, did you see the other email about the 2.2.27 breaking
antispam? This has hit the archive, and I've had to recompile the
antispam plugin with the latest fix I added to the git tree.

Bug#786566: this is affecting us

[Brian May]

Peter Palfrader  writes:

> It's a serious bug that makes it break in many cases, requiring the
> sysadmin to clean up and/or reboot the system.  Whether or not it's RC
> in the end is the decision of the release team, but this severity was
> set after discussing this on #debian-release.

Is anything being done to fix this? What is the hold up? Apparently
there is a patch for this RC bug and the other RC bug #817236.

It is kind of looking like stretch will get released without schroot
support, or any packages that depend on it. Maybe time to forgot schroot
and look for alternatives???
-- 
Brian May 

Bug#848365: jessie-pu: package coquelicot/0.9.2-4+deb8u1

[Jérémy Bobbio]

Adam D. Barratt:
> Control: tags -1 + moreinfo
> 
> On Fri, 2016-12-16 at 18:31 +0100, Jérémy Bobbio wrote:
> > I would like to important issues affecting coquelicot in jessie:
> > 
> > #809351: properly run coquelicot under the 'coquelicot' user and not
> > as root. It was always intended that way, that's why the cron is running
> > under the coquelicot user already. The issue has been fixed a while ago
> > for stretch (in 0.9.4-1, uploaded September 2015). This backports the
> > changes from the unstable branch which switched to using
> > init-d-script(5).
> > 
> > #808018: silence deprecation warnings coming from cron. While the
> > warnings actually come from ruby-fast-gettext, they make the garbage
> > collection cron send an email on every run.
> 
> + sysvinit-utils (>= 2.88dsf-50),
> 
> What's that for? sysvinit-utils is Essential:yes.
> 
> Hmmm, so the answer appears to be "because that's when init-d-script(5)
> was added". That doesn't really seem like a minimal change for fixing
> the user that the daemon is running as.

You are right. I agree it's not a minimal change but the initscript
using init-d-script has been in Stretch for more than a year. I thought
it would be safer to use a version that has received more testing than
to patch the older one. I could still do that if you'd prefer.

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


signature.asc
Description: Digital signature

Bug#850215: [pkg-php-pear] Bug#850215: zendframework: CVE-2016-10034

[Markus Frosch]

On 05.01.2017 07:01, Salvatore Bonaccorso wrote:
> Source: zendframework
> Version: 1.12.9+dfsg-1
> Severity: grave
> Tags: upstream security
> Justification: user security hole
> 
> Hi,
> 
> the following vulnerability was published for zendframework.
> 
> CVE-2016-10034[0]:
> | The setFrom function in the Sendmail adapter in the zend-mail
> | component before 2.4.11, 2.5.x, 2.6.x, and 2.7.x before 2.7.2, and
> | Zend Framework before 2.4.11 might allow remote attackers to pass
> | extra parameters to the mail command and consequently execute
> | arbitrary code via a \" (backslash double quote) in a crafted e-mail
> | address.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-10034
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10034
> 
> Please adjust the affected versions in the BTS as needed.

Hi Salvatore,
thanks for bringing that up.

I actually don't think this CVE is valid for ZendFramework 1 (Version < 2).

Not only there are big differences in class structure between ZF1 and ZF >= 2.0,
but many features have been introduced first in ZF > 2.

I see no specific handling for a From header in Zend_Mail_Transport_Sendmail.

https://github.com/zendframework/zf1/blob/master/library/Zend/Mail/Transport/Sendmail.php#L128

A user of the library would be able to insert additional parameters, and pass 
whatever
argument to sendmail. But the user would have to care about securing / escaping 
then.

As we currently don't have a package for Zend-Mail, and zendframework is < 2, 
this bug
wouldn't affect Debian.

Would love if someone could approve or object my analysis.

Cheers
Markus Frosch
-- 
mar...@lazyfrosch.de / lazyfro...@debian.org
http://www.lazyfrosch.de



signature.asc
Description: OpenPGP digital signature

Bug#850228: libconfig-model-systemd-perl: ConditionHost not working right

[Joerg Jaspert]

Package: libconfig-model-systemd-perl
Version: 0.232.3-1
Severity: normal

Dear Maintainer,

[Unit]
Description=Something something
PartOf=whatever.target
ConditionHost=|hostname1
ConditionHost=|anotherhost
Requires=whatever

[Service]
[...]

cme only lists the second value and also displays a pod error in its
description window.

POD ERRORS

Hey! The above document had some coding errors, which are explained below:

Around line 12:
Non-ASCII character seen before =encoding in '…'. Assuming CP1252


(There is no non-ascii character anywhere in the unit file)

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

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

Versions of packages libconfig-model-systemd-perl depends on:
ii  libconfig-model-perl  2.097-1
ii  liblog-log4perl-perl  1.47-2
ii  libmouse-perl 2.4.5-2+b1
ii  libpath-tiny-perl 0.098-1
ii  perl  5.24.1~rc4-1

Versions of packages libconfig-model-systemd-perl recommends:
ii  cme1.016-1
ii  libconfig-model-tkui-perl  1.359-1

Versions of packages libconfig-model-systemd-perl suggests:
pn  libconfig-model-cursesui-perl  

-- no debconf information

-- 
bye, Joerg

Bug#850215: [pkg-php-pear] Bug#850215: zendframework: CVE-2016-10034

[Salvatore Bonaccorso]

Hi

On Thu, Jan 05, 2017 at 10:34:29AM +0100, Markus Frosch wrote:
> On 05.01.2017 07:01, Salvatore Bonaccorso wrote:
> > Source: zendframework
> > Version: 1.12.9+dfsg-1
> > Severity: grave
> > Tags: upstream security
> > Justification: user security hole
> > 
> > Hi,
> > 
> > the following vulnerability was published for zendframework.
> > 
> > CVE-2016-10034[0]:
> > | The setFrom function in the Sendmail adapter in the zend-mail
> > | component before 2.4.11, 2.5.x, 2.6.x, and 2.7.x before 2.7.2, and
> > | Zend Framework before 2.4.11 might allow remote attackers to pass
> > | extra parameters to the mail command and consequently execute
> > | arbitrary code via a \" (backslash double quote) in a crafted e-mail
> > | address.
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2016-10034
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10034
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> Hi Salvatore,
> thanks for bringing that up.
> 
> I actually don't think this CVE is valid for ZendFramework 1 (Version < 2).
> 
> Not only there are big differences in class structure between ZF1 and ZF >= 
> 2.0,
> but many features have been introduced first in ZF > 2.
> 
> I see no specific handling for a From header in Zend_Mail_Transport_Sendmail.
> 
> https://github.com/zendframework/zf1/blob/master/library/Zend/Mail/Transport/Sendmail.php#L128
> 
> A user of the library would be able to insert additional parameters, and pass 
> whatever
> argument to sendmail. But the user would have to care about securing / 
> escaping then.
> 
> As we currently don't have a package for Zend-Mail, and zendframework is < 2, 
> this bug
> wouldn't affect Debian.
> 
> Would love if someone could approve or object my analysis.

Adding Thijs to the loop, who did some additional research, which
triggered us to change the status from  to  in
the security-tracker.

Regards,
Salvatore

Bug#838704: gnustep-dl2-postgresql-adaptor: fails to upgrade on a long grown system

[Gert Wollny]

Hello, 

in 

  d/gnustep-dl2-postgresql-adaptor.maintscript

the first link uses "Current" which is already a symlink. When one
replaces this with "0" the upgrade works fine. (I tested this with
-9+nmu build on sid upgrading to the patched -15 which also failed here
for the unpatched version. 

I would prepare an NMU but:  

The packaging git does not contain the latest version (i.e. -15) but  
only -14, so I don't know whether you have already any  updates
privately queued up. 

The package has two lintian errors that should either be suppressed  
or corrected: 

E: gnustep-dl2-sqlite-adaptor: arch-dependent-file-in-usr-share
usr/share/GNUstep/Frameworks/SQLite3EOAdaptor/Versions/0/LoginPanel.bun
dle/LoginPanel
E: gnustep-dl2-postgresql-adaptor: arch-dependent-file-in-usr-share
usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0/LoginPanel.
bundle/LoginPanel

I guess the *plist file is considered to be arch-dependent, although I
don't see why given its content.  

I've attached the according patch to fix this bug. 

Best, 
Gert 
 



--- gnustep-dl2-0.12.0/debian/gnustep-dl2-postgresql-adaptor.maintscript	2016-07-13 09:56:56.0 +
+++ gnustep-dl2-0.12.0.new/debian/gnustep-dl2-postgresql-adaptor.maintscript	2017-01-05 09:28:36.346876308 +
@@ -1,4 +1,4 @@
-symlink_to_dir	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/Current/Resources	0.12.0-15~
+symlink_to_dir	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources	0.12.0-15~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Headers	/usr/include/GNUstep/PostgreSQLEOAdaptor	0.12.0-14~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources	/usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/LoginPanel.bundle	0.12.0-14~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources	/usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0	0.12.0-14~

Bug#814218: lua-ldap: Add support for Lua 5.2

[Avinash Sultanpur]

On Wed, Jan 04, 2017 at 11:04:32PM +0100, Luca Capello wrote:
> tags 814218  + moreinfo
> thanks
> 
> Hi there,
> 
> sorry for the delay, mostly due to real life and the fact that the
> servers (with Prosody + lua-ldap) I administer are still on wheezy.
> 
> On Tue, 09 Feb 2016 14:33:53 +0530, Avinash Sultanpur wrote:
> > The pdns-recursor is compiled with liblua5.2-0 and this package does
> > not have support for Lua 5.2 which makes it unusable with Power DNS.
> > 
> > There are a couple of open pull requests on Github which add support
> > for Lua 5.2. Please merge them in order to support Lua 5.2.
> > 
> > https://github.com/luaforge/lualdap/pulls
> 
> I am sorry, but after having tried for 2 weeks now I have given up
> trying to understand where the lualdap sources reside, here some
> comments:


Since reporting this bug, I've been using the pdns-recursor package
from Fedora 23 running under Docker and it has worked well with
lua-ldap which ships with the distribution along with Lua 5.3. Would
this link be of any help?

http://pkgs.fedoraproject.org/cgit/rpms/lua-ldap.git

Bug#850218: Worthless node-* package descriptions in ITPs

[Philip Hands]

Hi Roshan,

Please don't take this personally, you just happen to be the one
touching the most recent remarkably meaninglessly described ITP for a
node-* package -- I could easily have picked on one of the many other
examples.

I've Bcc:ed the bug to ensure that replies about this stay on -devel.

Roshan  writes:

...
> * Package name: node-pinkie
...
> * URL : https://github.com/floatdrop/pinkie
...
>   Description : Itty bitty little widdle twinkie pinkie ES2015 Promise 
> implementation

Can we stop the worthless descriptions in node-* ITPs please?

What meaning is contained in the descriptions, is generally
JavaScript/Node specific jargon that is pretty much meaningless to
anyone else.  This is because it is being lifted directly from the git
repository description, where it is reasonable for the upstream to
expect people to already know something about node, so that's the
audience that is being addressed.  That is not a reasonable assumption
when applied to Debian users in general.

To All Node.js packagers:

  Please proof-read and correct the short descriptions before filing
  ITPs.

  Also please fix the script that is generating these ITPs to add a long
  description that at the very least mentions that this is something to
  do with node.js, and what that means (such that people that are not
  interested in node.js can quickly determine that fact and move on).

At present you are forcing that vast majority of our users, that have no
interest in this software, to individually learn that they need to look
out for the node- prefix, and ignore such packages.

You are also giving the impression that all these packages are sloppily
packaged, which makes one wonder if they are going to have any ongoing
maintenance effort available for them (since it seems that too little
effort was devoted to the initial packaging), which in turn makes one
concerned about whether they are going to be fit for a stable release.

Cheers, Phil.

-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#850231: heat: FTBFS (TypeError: unsupported operand type(s) for +=: 'int' and 'str')

[Santiago Vila]

Package: src:heat
Version: 1:7.0.0-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python2,sphinxdoc,systemd
   dh_testdir -i -O--buildsystem=python_distutils
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions

[... snipped ...]

  File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 291, in 
build
self.builder.build_all()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 
211, in build_all
self.build(None, summary='all source files', method='all')
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 
322, in build
self.write(docnames, list(updated_docnames), method)
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 
360, in write
self._write_serial(sorted(docnames), warnings)
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 
368, in _write_serial
self.write_doc(docname, doctree)
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py", line 448, in 
write_doc
self.docwriter.write(doctree, destination)
  File "/usr/lib/python2.7/dist-packages/docutils/writers/__init__.py", line 
80, in write
self.translate()
  File "/usr/lib/python2.7/dist-packages/sphinx/writers/html.py", line 48, in 
translate
self.document.walkabout(visitor)
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 166, in 
walkabout
visitor.dispatch_visit(self)
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1882, in 
dispatch_visit
return method(node)
  File 
"/usr/lib/python2.7/dist-packages/docutils/writers/html4css1/__init__.py", line 
778, in visit_thead
self.write_colspecs()
  File 
"/usr/lib/python2.7/dist-packages/docutils/writers/html4css1/__init__.py", line 
289, in write_colspecs
width += node['colwidth']
TypeError: unsupported operand type(s) for +=: 'int' and 'str'
debian/rules:76: recipe for target 'override_dh_sphinxdoc' failed
make[1]: *** [override_dh_sphinxdoc] Error 1
make[1]: Leaving directory '/<>'
debian/rules:10: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


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

I've put several build logs here:

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

Seems like a problem with sphinx.

Thanks.

Bug#850230: fabric: FTBFS (sbuild hangs)

[Santiago Vila]

Package: src:fabric
Version: 1.13.1-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,sphinxdoc --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/pythonX.Y_2.7/build/fabric

[... snipped ...]

copying fabric/exceptions.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/fabric
copying fabric/colors.py -> /<>/.pybuild/pythonX.Y_2.7/build/fabric
copying fabric/job_queue.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/fabric
creating /<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/django.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/console.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/__init__.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/files.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/project.py -> 
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
   dh_auto_test -i -O--buildsystem=pybuild
I: pybuild base:184: cd /<>/.pybuild/pythonX.Y_2.7/build; 
python2.7 -m nose tests
.Traceback
 (most recent call last):
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py", 
line 561, in process_request_thread
self.finish_request(request, client_address)
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py", 
line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py", 
line 631, in __init__
self.handle()
  File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line 
361, in handle
if self.sudo_prompt and not self.sudo_password():
  File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line 
426, in sudo_password
self.channel.send(env.sudo_prompt)
  File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 715, in send
return self._send(s, m)
  File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 1075, in 
_send
raise socket.error('Socket is closed')
error: Socket is closed
..Traceback (most recent call last):
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py", 
line 561, in process_request_thread
self.finish_request(request, client_address)
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py", 
line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
  File 
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py", 
line 631, in __init__
self.handle()
  File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line 
361, in handle
if self.sudo_prompt and not self.sudo_password():
  File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line 
426, in sudo_password
self.channel.send(env.sudo_prompt)
  File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 715, in send
return self._send(s, m)
  File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 1075, in 
_send
raise socket.error('Socket is closed')
error: Socket is closed
.
E: Build killed with signal TERM after 60 minutes of inactivity


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

I've put several build logs here:

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

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

The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders), and
it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fabric.html

Thanks.

Bug#850237: ITP: node-private -- Utility for associating truly private state with any JavaScript object

[Ameya Apte]

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

* Package name: node-private
  Version : 0.1.6
  Upstream Author : Ben Newman 
* URL : http://github.com/benjamn/private
* License : Expat
  Programming Lang: JavaScript
  Description : Utility for associating truly private state with any
JavaScript object

Bug#849718: Can not reproduce from fresh git checkout

[Michael Vogt]

Hi,

I tried this from a fresh git build and can not reproduce it.  Could you
please double check that
"Settings/Preferences/Marking Changes/Ask to confirm changes that also
affect other packages"
is set?

Cheers,
 Michael

Bug#850233: mavibot: FTBFS randomly (sbuild hangs)

[Santiago Vila]

Package: src:mavibot
Version: 1.0.0~M1-2
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': No 
such file or directory
mh_patchpoms -plibmavibot-java --debian-build --keep-pom-version 
--maven-repo=/<>/mavibot-1.0.0\~M1/debian/maven-repo
   dh_auto_build -i
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<>/mavibot-1.0.0\~M1 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/<>/mavibot-1.0.0\~M1/debian/maven.properties
 org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml 
-Ddebian.dir=/<>/mavibot-1.0.0\~M1/debian 
-Dmaven.repo.local=/<>/mavibot-1.0.0\~M1/debian/maven-repo package 
-DskipTests -Dnotimestamp=true -Dlocale=en_US
[INFO] Scanning for projects...

[... snipped ...]

Written 6 elements in : 1018ms
Written 7 elements in : 1057ms
Written 8 elements in : 1068ms
Written 9 elements in : ms
Delta : 11530, nbError = 0, Nb insertion per second : 8000
6MB
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.88 sec - in 
org.apache.directory.mavibot.btree.RecordManagerFreePageTest
Running org.apache.directory.mavibot.btree.BTreeConfigurationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec - in 
org.apache.directory.mavibot.btree.BTreeConfigurationTest
Running org.apache.directory.mavibot.btree.comparator.ByteArrayComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in 
org.apache.directory.mavibot.btree.comparator.ByteArrayComparatorTest
Running org.apache.directory.mavibot.btree.comparator.ShortArrayComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in 
org.apache.directory.mavibot.btree.comparator.ShortArrayComparatorTest
Running org.apache.directory.mavibot.btree.comparator.BooleanComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in 
org.apache.directory.mavibot.btree.comparator.BooleanComparatorTest
Running org.apache.directory.mavibot.btree.comparator.CharArrayComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec - in 
org.apache.directory.mavibot.btree.comparator.CharArrayComparatorTest
Running org.apache.directory.mavibot.btree.comparator.ShortComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in 
org.apache.directory.mavibot.btree.comparator.ShortComparatorTest
Running org.apache.directory.mavibot.btree.comparator.LongComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in 
org.apache.directory.mavibot.btree.comparator.LongComparatorTest
Running org.apache.directory.mavibot.btree.comparator.BooleanArrayComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in 
org.apache.directory.mavibot.btree.comparator.BooleanArrayComparatorTest
Running org.apache.directory.mavibot.btree.comparator.ByteComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - in 
org.apache.directory.mavibot.btree.comparator.ByteComparatorTest
Running org.apache.directory.mavibot.btree.comparator.RevisionNameComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in 
org.apache.directory.mavibot.btree.comparator.RevisionNameComparatorTest
Running org.apache.directory.mavibot.btree.comparator.LongArrayComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in 
org.apache.directory.mavibot.btree.comparator.LongArrayComparatorTest
Running org.apache.directory.mavibot.btree.comparator.StringComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in 
org.apache.directory.mavibot.btree.comparator.StringComparatorTest
Running org.apache.directory.mavibot.btree.comparator.CharComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
org.apache.directory.mavibot.btree.comparator.CharComparatorTest
Running org.apache.directory.mavibot.btree.comparator.IntComparatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
org.apache.directory.mavibot.btree.compar

Bug#850232: installation-guide: FTBFS randomly (ERROR: xref linking to appendix-gpl has no generated link text.)

[Santiago Vila]

Package: src:installation-guide
Version: 20161031
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
rm -f build-stamp
rm -rf /<>/debian/manual
set -e && cd build && \
MAKEFLAGS="-j1" \
official_build=1 manual_release=wheezy \
architectures="i386 amd64 arm64 armel armhf mips mips64el mipsel 
ppc64el s390x" languages="en cs da de el es fr it ja ko pt ru sv vi zh_CN" \
destination=/<>/debian/manual/'${arch}' noarchdir=1 \
./build.sh
Generating integrated XML files and POT files
Building list of entities...
Converting XML files to UTF-8...
Merging XML files per 'chapter'...

[... snipped ...]

Writing build.out.da.i386/html/apas01.html for sect1(howto-preliminaries)
Writing build.out.da.i386/html/apas02.html for sect1(howto-getting-images)
Writing build.out.da.i386/html/apas03.html for sect1(howto-installation)
Writing build.out.da.i386/html/apas04.html for sect1(howto-installation-report)
Writing build.out.da.i386/html/apas05.html for sect1(howto-installation-finally)
Writing build.out.da.i386/html/apa.html for appendix(installation-howto)
Writing build.out.da.i386/html/apbs01.html for sect1(preseed-intro)
Writing build.out.da.i386/html/apbs02.html for sect1(preseed-using)
Writing build.out.da.i386/html/apbs03.html for sect1(preseed-creating)
Writing build.out.da.i386/html/apbs04.html for sect1(preseed-contents)
Writing build.out.da.i386/html/apbs05.html for sect1(preseed-advanced)
Writing build.out.da.i386/html/apb.html for appendix(appendix-preseed)
Writing build.out.da.i386/html/apcs01.html for sect1(partition-sizing)
Writing build.out.da.i386/html/apcs02.html for sect1(directory-tree)
Writing build.out.da.i386/html/apcs03.html for sect1
Writing build.out.da.i386/html/apcs04.html for sect1(device-names)
Writing build.out.da.i386/html/apcs05.html for sect1(partition-programs)
Writing build.out.da.i386/html/apc.html for appendix(partitioning)
Writing build.out.da.i386/html/apds01.html for sect1(linuxdevices)
Writing build.out.da.i386/html/apds02.html for sect1(tasksel-size-list)
Writing build.out.da.i386/html/apds03.html for sect1(linux-upgrade)
Writing build.out.da.i386/html/apds04.html for sect1(plip)
Writing build.out.da.i386/html/apds05.html for sect1(pppoe)
Writing build.out.da.i386/html/apd.html for appendix(random-bits)
Writing build.out.da.i386/html/apes01.html for sect1(about)
Writing build.out.da.i386/html/apes02.html for sect1(contributing)
Writing build.out.da.i386/html/apes03.html for sect1(contributors)
Writing build.out.da.i386/html/apes04.html for sect1(trademarks)
Writing build.out.da.i386/html/ape.html for appendix(administrivia)
Writing build.out.da.i386/html/index.html for book
Info: creating temporary .tex file...
openjade:build.tmp.da.i386/install.da.profiled.xml:32:178:X: reference to 
non-existent ID "appendix-gpl"
openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dblink.dsl:200:1:E:
 XRef LinkEnd to missing ID 'appendix-gpl'
Error: build of pdf failed with error code 1
Info: creating temporary .html file...
ERROR: xref linking to appendix-gpl has no generated link text.
Error: no ID for constraint linkend: "appendix-gpl".
Info: creating .txt file...
Warning: The following formats failed to build: pdf
Makefile:8: recipe for target 'da.i386' failed
make[1]: *** [da.i386] Error 2
make[1]: Leaving directory '/<>/build'
debian/rules:60: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


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

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/installation-guide/

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

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

Thanks.

Bug#850234: mercurial: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:mercurial
Version: 4.0-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,bash-completion
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
/usr/bin/make all
make[2]: Entering directory '/<>'
python setup.py  build 
running build
running build_mo
creating mercurial/locale

[... snipped ...]

Skipped test-convert-cvs-branch.t: missing feature: cvs client/server
Skipped test-convert-hg-svn.t: missing feature: subversion python bindings
Skipped test-convert-svn-branches.t: missing feature: subversion python bindings
Skipped test-subrepo-git.t: missing feature: git command line client
Skipped test-convert-git.t: missing feature: git command line client
Skipped test-check-config.t: missing feature: running tests from repository
Skipped test-convert-p4-filetypes.t: missing feature: Perforce server and client
Skipped test-convert-svn-startrev.t: missing feature: subversion python bindings
Skipped test-mq-subrepo-svn.t: missing feature: subversion client and admin 
tools >= 1.3
Skipped test-convert-mtn.t: missing feature: monotone client (>= 1.0)
Skipped test-convert-svn-tags.t: missing feature: subversion python bindings
Skipped test-casecollision-merge.t: missing feature: case insensitive file 
system
Skipped test-convert-bzr.t: missing feature: Canonical's Bazaar client
Skipped test-convert-baz.t: missing feature: GNU Arch baz client
Skipped test-casefolding.t: missing feature: case insensitive file system
Skipped test-convert-bzr-directories.t: missing feature: Canonical's Bazaar 
client
Skipped test-convert-p4.t: missing feature: Perforce server and client
Skipped test-convert-tla.t: missing feature: GNU Arch tla client
Skipped test-convert-darcs.t: missing feature: darcs client
Skipped test-convert-tagsbranch-topology.t: missing feature: git command line 
client
Skipped test-mac-packages.t: missing feature: OS X packaging tools
Skipped test-chg.t: missing feature: running with chg
Skipped test-verify-repo-operations.py: missing feature: allow slow tests
Skipped test-convert-bzr-merges.t: missing feature: Canonical's Bazaar client
Skipped test-no-symlinks.t: system supports symbolic links
Skipped test-gpg.t: missing feature: gpg client
Skipped test-docker-packaging.t: missing feature: docker support
Skipped test-convert-bzr-ghosts.t: missing feature: Canonical's Bazaar client
Skipped test-convert-bzr-114.t: missing feature: Canonical's Bazaar client >= 
1.14
Skipped test-convert-bzr-treeroot.t: missing feature: Canonical's Bazaar client
Skipped test-debian-packages.t: missing feature: debian packaging tools
Failed test-largefiles-update.t: output changed
# Ran 474 tests, 51 skipped, 0 warned, 1 failed.
python hash seed: 605604232
# Cleaning up HGTMP /tmp/hgtests.whcbiY 
Makefile:110: recipe for target 'tests' failed
make[2]: *** [tests] Error 1
make[2]: Leaving directory '/<>'
dh_auto_test: make -j1 check TESTFLAGS=--verbose --timeout 1440 --jobs 1 
--blacklist /<>/debian/mercurial.test_blacklist returned exit code 
2
debian/rules:42: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
debian/rules:8: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


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

I've put several build logs here:

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

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

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

Apparently test-largefiles-update.t has a tendency to fail.

Thanks.

Bug#786566: this is affecting us

[Roger Leigh]

On 05/01/17 09:23, Brian May wrote:

Peter Palfrader  writes:


It's a serious bug that makes it break in many cases, requiring the
sysadmin to clean up and/or reboot the system.  Whether or not it's RC
in the end is the decision of the release team, but this severity was
set after discussing this on #debian-release.


Is anything being done to fix this? What is the hold up? Apparently
there is a patch for this RC bug and the other RC bug #817236.


I'm not personally working on any fix in schroot, since it's not an 
schroot bug.



It is kind of looking like stretch will get released without schroot
support, or any packages that depend on it. Maybe time to forgot schroot
and look for alternatives???


schroot is not responsible for setting up device nodes in a 
debootstrapped chroot.  We expect them to be set up correctly.  This 
isn't a Debian-specific constraint; we expect all chroots of any sort to 
be in a sane and directly usable state.


schroot's requirements are not any different here from that of the basic 
chroot(8).  Is chroot(8) equally broken here?  The mounts and other 
features schroot offers on top of that are entirely optional, and 
implementation wise is nothing more than a wrapper around chroot(2) to 
perform exactly the same job as chroot(8) with some sudo-like PAM 
authentication and authorisation.


While we could add additional mounts to the schroot fstab templates, 
it's important to understand that this is optional functionality, and 
has always been optional.  It's not a mechanism for working around 
external breakage.


Looking for alternatives to schroot is entirely your choice, but 
breaking basic system-level functionality which has been working for 
over two decades, and used for over 11 years by schroot, is I think 
something which needs careful consideration.  I'm prepared to do some 
work to ensure that schroot interoperates with contemporary systems, but 
working around breakage like this is perhaps a step too far.



Regards,
Roger

Bug#850236: python-django: FTBFS (AssertionError)

[Santiago Vila]

Package: src:python-django
Version: 1:1.10.3-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


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

[... snipped ...]

test_options (generic_views.test_base.ViewTest) ... ok
test_options_for_get_and_post_view (generic_views.test_base.ViewTest) ... ok
test_options_for_get_view (generic_views.test_base.ViewTest) ... ok
test_options_for_post_view (generic_views.test_base.ViewTest) ... ok
test_pathological_http_method (generic_views.test_base.ViewTest) ... ok
test_response_without_messages (messages_tests.test_middleware.MiddlewareTest) 
... ok
test_script_prefix_set_in_commands (user_commands.tests.CommandRunTests) ... ok

==
FAIL: test_timesince07 
(template_tests.filter_tests.test_timesince.TimesinceTests)
--
Traceback (most recent call last):
  File "/<>/django/test/utils.py", line 205, in inner
return func(*args, **kwargs)
  File "/<>/tests/template_tests/utils.py", line 61, in inner
func(self)
  File "/<>/tests/template_tests/filter_tests/test_timesince.py", 
line 67, in test_timesince07
self.assertEqual(output, '1\xa0week')
AssertionError: u'6\xa0days' != u'1\xa0week'

==
FAIL: test_timesince08 
(template_tests.filter_tests.test_timesince.TimesinceTests)
--
Traceback (most recent call last):
  File "/<>/django/test/utils.py", line 205, in inner
return func(*args, **kwargs)
  File "/<>/tests/template_tests/utils.py", line 61, in inner
func(self)
  File "/<>/tests/template_tests/filter_tests/test_timesince.py", 
line 74, in test_timesince08
self.assertEqual(output, '1\xa0week')
AssertionError: u'6\xa0days' != u'1\xa0week'

--
Ran 11263 tests in 245.226s

FAILED (failures=2, skipped=1064, expected failures=5)
 OK
Destroying test database for alias 'default' (':memory:')...
Destroying test database for alias 'other' (':memory:')...
debian/rules:24: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:12: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


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

I've put several build logs here:

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

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

The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders), and it
also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django.html

Thanks.

Bug#850229: dune-grid: FTBFS (not enough slots available)

[Santiago Vila]

Package: src:dune-grid
Version: 2.5.0-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --builddirectory=build
   dh_testdir -i -O--parallel -O--builddirectory=build
   dh_update_autotools_config -i -O--parallel -O--builddirectory=build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DBUILD_SHARED_LIBS=1
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DBUILD_SHARED_LIBS=1
-- The C compiler identification is GNU 6.2.1
-- The CXX compiler identification is GNU 6.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info

[... snipped ...]

Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 test-yaspgrid-yaspfactory-1d
   
   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--

==
Name:  test-yaspgrid-yaspfactory-2d-mpi-2
FullName:  ./dune/grid/test/yasp/test-yaspgrid-yaspfactory-2d-mpi-2
Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 test-yaspgrid-yaspfactory-2d
   
   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--

==
Name:  test-yaspgrid-yaspfactory-3d-mpi-2
FullName:  ./dune/grid/test/yasp/test-yaspgrid-yaspfactory-3d-mpi-2
Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 test-yaspgrid-yaspfactory-3d
   
   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--

/usr/share/dune/dune-debian.mk:16: recipe for target 'override_dh_auto_test' 
failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:6: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


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

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/dune-grid/

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

The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders).

Thanks.

Bug#850235: nuitka: FTBFS (SyntaxError: duplicate argument 'a' in function definition)

[Santiago Vila]

Package: src:nuitka
Version: 0.5.24.4+ds-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/nuitka-0.5.24.4+ds'
rst2pdf README.rst
rst2pdf Developer_Manual.rst
cp Changelog.rst changelog
cp Developer_Manual.rst Developer_Manual.txt
make[1]: Leaving directory '/<>/nuitka-0.5.24.4+ds'
   debian/rules override_dh_auto_test

[... snipped ...]

Comparing output of 'PrintFuture.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'Recursion.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'Referencing.py' using 'python3.5-dbg' with flags silent, 
expect_success, remove_output, recurse_all, original_file, python_debug, 
recurse_not:test_common ...
Comparing output of 'Referencing32.py' using 'python3.5-dbg' with flags silent, 
expect_success, remove_output, recurse_all, original_file, python_debug, 
recurse_not:test_common ...
Comparing output of 'Referencing33.py' using 'python3.5-dbg' with flags silent, 
expect_success, remove_output, recurse_all, original_file, python_debug, 
recurse_not:test_common ...
Comparing output of 'Referencing35.py' using 'python3.5-dbg' with flags silent, 
expect_success, remove_output, recurse_all, original_file, python_debug, 
recurse_not:test_common ...
Comparing output of 'Slots.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'ThreadedGenerators.py' using 'python3.5' with flags 
silent, expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'TrickAssignments32.py' using 'python3.5' with flags 
silent, expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'TryContinueFinally.py' using 'python3.5' with flags 
silent, expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'TryExceptContinue.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'TryExceptFinally.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'TryExceptFrames.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'TryReturnFinally.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'TryYieldFinally.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'Unicode.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'Unpacking35.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'Varargs.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'WithStatements.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file ...
Comparing output of 'YieldFrom33.py' using 'python3.5' with flags silent, 
expect_success, remove_output, recurse_all, original_file, ignore_stderr ...
Running the syntax tests with options '' with python3.5:
Run './tests/syntax/run_all.py search' in '/<>/nuitka-0.5.24.4+ds'.
Using concrete python 3.5.2 on x86_64
Comparing output of 'BreakWithoutLoop.py' using 'python3.5' with flags silent, 
expect_failure, remove_output ...
Comparing output of 'ClassReturn.py' using 'python3.5' with flags silent, 
expect_failure, remove_output ...
Comparing output of 'ContinueWithoutLoop.py' using 'python3.5' with flags 
silent, expect_failure, remove_output ...
Comparing output of 'DuplicateArgument.py' using 'python3.5' with flags silent, 
expect_failure, remove_output ...
--- python3.5 (stderr)
+++ nuitka (stderr)

@@ -1,5 +1,4 @@

   File "/<>/nuitka-0.5.24.4+ds/tests/syntax/DuplicateArgument.py", 
line 18
 def f(a, a):
-^
 SyntaxError: duplicate argument 'a' in function definition
 
Error, outputs differed.
Error exit! 1
debian/rules:16: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>/nuitka-0.5.24.4+ds'
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
-

Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

Hi all,

On 04.01.2017 20:57, Santiago Vila wrote:
> I still want to build all packages and have 0 or 1 failures,
> so in this case the probability should be 1/50/2, i.e. 1%.
> 
> I think this is still feasible.

My experience is that the buildds that are currently in use provide more
build problems than the packages themself. BTW, why don't you count this
as RC?

[statistical]
>> The "fix" for such cases is the increasing of the threshold or disabling
>> the test completely. Because you can do nothing with it due to the
>> nature of numerical simulations.

Just disabling would be bad, since the test still can point to some
problem in the implementation, like optimization problems or such.

IMO the correct solution here would be to remove the randomness and to
seed with a fixed value (which is known to give a result within the
expectations).

> But as far as there are people in this project who consider that a
> package which FTBFS on single-CPU machines more than 50% of the time
> is ok "because it does not usually fail in buildd.debian.org",
> we are doomed.

We have 10 archs, and with a 50% chance of failure you will not get any
version built. Even when the buildds try it two or three times.

> The problem I see with this threshold thing is that every maintainer
> seems to have his own threshold, different from the others.
> 
> In case we decide about RC-ness depending on probability of failure:
> What threshold do you think we should use for a single package and why?
> 
> [ I say that 1% of failure is the maximum we should allow, and I've
>   explained why, but I would love to hear your opinion on this ].

I would not put any direct number here, but be pragmatic: We need to
build the package from source, and this has to be done on all supported
architectures, and on the buildds. As long as this is done, I see no
reason for an RC bug. If a package fails on a supported arch on the
buildds, this is RC, independent of whether this came from an
architectural difference or from a random build failure. Your tests with
repeated builds help the maintainer to find the cause in that case, and
for this they are helpful. But not release critical by themself.

Cheers

Ole

Bug#814030: Security flaw fixed in version 6.2.0

[Raphael Hertzog]

Hi,

CCing upstream author for confirmation. Nicola we are trying to understand
what security fix went into tcpdf 6.2.0. The bug is private on
sourceforge, could you make it public now?

For more details see: https://bugs.debian.org/814030

On Wed, 04 Jan 2017, David Prévot wrote:
> >> Can you contact upstream for information on this security bug? I have
> >> no idea what that could possibly mean.
> > 
> > Did you got any information on that from upstream? The bug is stil
> > closed, so does not really help.

I did not contact upstream but looking at the changes in that version:
https://sourceforge.net/p/tcpdf/code/ci/40662daa766bd3a6b5eafa44dfde680ee6661716/tree/tcpdf.php?diff=3d5921442e7adde1ce225104118bc246a1933c65
https://sourceforge.net/p/tcpdf/code/ci/40662daa766bd3a6b5eafa44dfde680ee6661716/tree/include/tcpdf_fonts.php?diff=3d5921442e7adde1ce225104118bc246a1933c65
https://sourceforge.net/p/tcpdf/code/ci/40662daa766bd3a6b5eafa44dfde680ee6661716/tree/include/tcpdf_static.php?diff=3d5921442e7adde1ce225104118bc246a1933c65

I see calls to fopen() being replaced by TCPDF_STATIC::fopenLocal() which
does ensure that we pass only "file://" URL or which add this prefix
if there's no "://" in the string.

So I guess that this issue is related to this. All the fopen() calls are
for files to which we write so I guess that we can possibly inject
"ftp://"; URL in some parameters and get some local files sent to a remote
location.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#850239: ITP: node-lodash -- Lodash modular utilities.

[Sumedh Pendurkar]

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

* Package name: node-lodash
  Version : 4.17.4
  Upstream Author : John-David Dalton  
(http://allyoucanleet.com/)

* URL : https://lodash.com/
* License : Expat
  Programming Lang: JavaScript
  Description : Lodash modular utilities.

Bug#850238: ITP: node-hoek -- General purpose node utilities

[Akash Sarda]

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

* Package name: node-hoek
  Version : 4.1.0
  Upstream Author : FIX_ME upstream author
* URL : https://github.com/hapijs/hoek#readme
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : General purpose node utilities

 Utility methods for the hapi ecosystem. This module is not intended to
solve every problem for everyone, but rather as a central place to store
hapi-specific methods. If you're looking for a general purpose utility
module, check out lodash  or underscore
.

Bug#850240: ITP: node-slash -- Convert Windows backslash paths to slash paths

[Vivek Bhave]

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

* Package name: node-slash
  Version : 1.0.0
  Upstream Author : Sindre Sorhus 
(http://sindresorhus.com)
* URL : https://github.com/sindresorhus/slash
* License : Expat
  Programming Lang: JavaScript
  Description : Convert Windows backslash paths to slash paths

Bug#850160: Incomplete fix (was: Re: Bug#850160 closed by Reiner Herrmann (Bug#850160: fixed in firejail 0.9.44.2-2))

[Reiner Herrmann]

Control: reopen -1

Hi Salvatore,

On Thu, Jan 05, 2017 at 07:54:24AM +0100, Salvatore Bonaccorso wrote:
> On Wed, Jan 04, 2017 at 11:21:05PM +, Debian Bug Tracking System wrote:
> >* Add upstream fix for CVE-2017-5180 (Closes: #850160).
> 
> Thanks. The fix had a followup which does not seem to be applied, cf.
> https://github.com/netblue30/firejail/issues/1020#issuecomment-270514760

Thanks for the information. I will later upload this followup fix.

Regards,
  Reiner


signature.asc
Description: Digital signature

Bug#850241: grub2-common: EFI Boot Manager entry is lowercase "debian", which does not look nice

[Moritz Schlarb]

Package: grub2-common
Version: 2.02~beta2-22+deb8u1
Severity: minor

The label for the EFI Boot Manager entry in util/grub-install.c,
efi_distributor is taken from bootloader_id, which is taken from
config.grub_distributor, which is apparently lowercased somewhere along the
way, since in /etc/default/grub, it is normally written properly cased.

There's probably a plausible rationale for using the lowercased version within
the code, but for the "user-facing" EFI Boot Manager entry, using the properly
cased string would look much nicer, IMHO.



-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda2 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=utf8,shortname=mixed,errors
=remount-ro 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-
efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  17de9a68-83e4-4f50-b493-803321cd1a1a
else
  search --no-floppy --fs-uuid --set=root 17de9a68-83e4-4f50-b493-803321cd1a1a
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-
efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  17de9a68-83e4-4f50-b493-803321cd1a1a
else
  search --no-floppy --fs-uuid --set=root 17de9a68-83e4-4f50-b493-803321cd1a1a
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option 'gnulinux-simple-
17de9a68-83e4-4f50-b493-803321cd1a1a' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-
efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  17de9a68-83e4-4f50-b493-803321cd1a1a
else
  search --no-floppy --fs-uuid --set=root
17de9a68-83e4-4f50-b493-803321cd1a1a
fi
echo'Loading Linux 3.16.0-4-amd64 ...'
linux   /boot/vmlinuz-3.16.0-4-amd64
root=UUID=17de9a68-83e4-4f50-b493-803321cd1a1a ro  quiet splash
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-3.16.0-4-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 'gnulinux-
advanced-17de9a68-83e4-4f50-b493-803321cd1a1a' {
menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-3.16.0-4-amd64-advanced-17de9a68-83e4-4f50-b493-803321cd1a1a' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; 

Bug#850238: ITP: node-hoek -- General purpose node utilities

[Philip Hands]

Akash Sarda  writes:

> Package: wnpp
> Severity: wishlist
> Owner: akash 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-hoek
>   Version : 4.1.0
>   Upstream Author : FIX_ME upstream author
  ^^

Please try to concentrate.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#850242: ITP: diamond-aligner -- accelerated BLAST compatible local sequence aligner

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: diamond-aligner
  Version : 0.8.31
  Upstream Author : Benjamin Buchfink 
* URL : https://github.com/bbuchfink/diamond
* License : BSD
  Programming Lang: C++
  Description : accelerated BLAST compatible local sequence aligner
 DIAMOND is a sequence aligner for protein and translated DNA searches
 and functions as a drop-in replacement for the NCBI BLAST software
 tools. It is suitable for protein-protein search as well as DNA-protein
 search on short reads and longer sequences including contigs and
 assemblies, providing a speedup of BLAST ranging up to x20,000.


Remark: The original upstream name 'diamond' was changed since
there is a package in Debian with this name.  The package will be
maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/diamond-aligner.git

Bug#850238: ITP: node-hoek -- General purpose node utilities

[Holger Levsen]

On Thu, Jan 05, 2017 at 03:39:31PM +0530, Akash Sarda wrote:
>   Description : General purpose node utilities
> 
>  Utility methods for the hapi ecosystem. This module is not intended to
> solve every problem for everyone, but rather as a central place to store
> hapi-specific methods. If you're looking for a general purpose utility
> module, …

please make the short description match the long one…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Antony Vaillant]

Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].

[1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2

Ghis


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

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

Bug#848859: FTBFS randomly (failing tests)

[Santiago Vila]

On Thu, Jan 05, 2017 at 11:06:50AM +0100, Ole Streicher wrote:
> Hi all,
> 
> On 04.01.2017 20:57, Santiago Vila wrote:
> > I still want to build all packages and have 0 or 1 failures,
> > so in this case the probability should be 1/50/2, i.e. 1%.
> > 
> > I think this is still feasible.
> 
> My experience is that the buildds that are currently in use provide more
> build problems than the packages themself. BTW, why don't you count this
> as RC?

Can you clarify the question? I don't understand what you refer exactly.

> [statistical]
> >> The "fix" for such cases is the increasing of the threshold or disabling
> >> the test completely. Because you can do nothing with it due to the
> >> nature of numerical simulations.
> 
> Just disabling would be bad, since the test still can point to some
> problem in the implementation, like optimization problems or such.
> 
> IMO the correct solution here would be to remove the randomness and to
> seed with a fixed value (which is known to give a result within the
> expectations).

Indeed. Sometimes I've asked that in my bug reports: "I would love to
provide a way to reproduce it, but you are using a different seed each
time..."

Removing randomness is certainly the right path to achieve both builds
that always work and also reproducible builds.

> > But as far as there are people in this project who consider that a
> > package which FTBFS on single-CPU machines more than 50% of the time
> > is ok "because it does not usually fail in buildd.debian.org",
> > we are doomed.
> 
> We have 10 archs, and with a 50% chance of failure you will not get any
> version built. Even when the buildds try it two or three times.

It's actually more subtle than that.

The package may be ready to be built on multi-core machines, but not on
single-core machines. So, the probability that I measure (greater than 50%),
might not be the same as the probability on official autobuilders.

This is one of the reasons I insist so much that the rule "If it does
not fail on official autobuilders, it's not RC" is wrong.

We pride ourselves to be the Universal Operating System. We can't make
multi-core a requirement to build. That's also mathematically
and logically wrong, because in an abstract sense, building a package
is like following an algorithm. It may be slower or faster, but
it should always succeed regardless of the number of CPU cores.


Then there is the other subtle thing: The package may be Arch:all, in
which case a 50% of probability (this time independent on the number
of CPUs) may go unnoticed very easily, either because the maintainer
uploaded the .deb him/herself, or, if the maintainer uploaded
in source-only form, we can just be lucky for that time.

> > The problem I see with this threshold thing is that every maintainer
> > seems to have his own threshold, different from the others.
> > 
> > In case we decide about RC-ness depending on probability of failure:
> > What threshold do you think we should use for a single package and why?
> > 
> > [ I say that 1% of failure is the maximum we should allow, and I've
> >   explained why, but I would love to hear your opinion on this ].
> 
> I would not put any direct number here, but be pragmatic: We need to
> build the package from source, and this has to be done on all supported
> architectures, and on the buildds. As long as this is done, I see no
> reason for an RC bug. [...]

My objection to consider the official buildds the "standard" by which
RC-ness is measured is that it makes packages to have an implicit
"build-depends: buildd.debian.org".

We provide software which is free to be modified. If people is going
to modify it and then it fails because the package only builds ok in
buildd.debian.org, then we are removing one of the essential freedoms,
the freedom to modify it, and the package becomes de-facto non-free,
even if we still distribute it in main.

That's why I think that packages must build ok on any autobuilder which
is not misconfigured, not just on buildd.debian.org.

Thanks.

Bug#850240: ITP: node-slash -- Convert Windows backslash paths to slash paths

[Philip Hands]

Vivek Bhave  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Vivek 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-slash
>   Version : 1.0.0
>   Upstream Author : Sindre Sorhus 
> (http://sindresorhus.com)
> * URL : https://github.com/sindresorhus/slash
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Convert Windows backslash paths to slash paths

Is this not already packaged?

  https://packages.debian.org/source/testing/node-slash

[Cc-ing Pirate Praveen as it seems that's his upload]

BTW in the software where this is used, does it guard the call with a
test for whether one is on Windows before calling slash()?

If not, how well does it handle a path like:

  /tmp/hello\there

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

debian-bugs-dist@lists.debian.org

[Emilio Pozuelo Monfort]

Package: reconserver
Version: 0.13.0-1
Severity: serious

Your package failed to build on ppc64el (twice), blocking the resiprocate 
transition.

reConServer.cxx: In member function 'virtual int 
recon::ReConServerProcess::main(int, char**)':
reConServer.cxx:941:164: error: no matching function for call to 
'resip::HEPSipMessageLoggingHandler::HEPSipMessageLoggingHandler(resip::Data&, 
int&, int&)'
   
profile->setTransportSipMessageLoggingHandler(SharedPtr(new
 HEPSipMessageLoggingHandler(captureHost, capturePort, captureAgentID)));

Full logs at:

https://buildd.debian.org/status/package.php?p=reconserver&suite=unstable

Emilio

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

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

Bug#850025: python-crypto: regression: 2.6-4+deb7u4 breaks python-paramiko

[Chris Lamb]

tags 850025 + pending
tags 850077 + pending
thanks

Thomas wrote:

> I just installed the newly updated 2.6-4+deb7u5 version of python-crypto.
> Unfortunately, the problem persists.

Fix pending upload…


Regards,

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

Bug#850240: ITP: node-slash -- Convert Windows backslash paths to slash paths

[Vivek Bhave]

Yes this is already packaged. I also sent the close bug report. I have
also got the confirmation.

Sorry for the mistake.



On Thu, Jan 5, 2017 at 4:08 PM, Philip Hands  wrote:
> Vivek Bhave  writes:
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Vivek 
>> X-Debbugs-CC: debian-de...@lists.debian.org
>>
>> * Package name: node-slash
>>   Version : 1.0.0
>>   Upstream Author : Sindre Sorhus 
>> (http://sindresorhus.com)
>> * URL : https://github.com/sindresorhus/slash
>> * License : Expat
>>   Programming Lang: JavaScript
>>   Description : Convert Windows backslash paths to slash paths
>
> Is this not already packaged?
>
>   https://packages.debian.org/source/testing/node-slash
>
> [Cc-ing Pirate Praveen as it seems that's his upload]
>
> BTW in the software where this is used, does it guard the call with a
> test for whether one is on Windows before calling slash()?
>
> If not, how well does it handle a path like:
>
>   /tmp/hello\there
>
> Cheers, Phil.
> --
> |)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
> |-|  http://www.hands.com/http://ftp.uk.debian.org/
> |(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#850245: lqa: please ship examples and README

[Andrew Shadura]

Package: lqa
Version: 20161215.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Right now, when lqa is installed the user is helpless and doesn't know
how to proceed, as there's no manpage, no documentation, no
configuration examples. Please ship at least the bits upstream provides,
potentially also provide a manpage if possible.

Thanks.

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQExBAEBCAAbBQJYbiLqFBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEJ1bI/kYT6UU
W2MH/A+nQp5ZHDoafEzv7OjO/+yJyS9GlTqilrObfvqExvYDCIhsNTmgXCJwsQ0x
hM0m/D25N50fLJr1wy1tW2xhqT5avA0BB39gTti3pDD+o6kbdT0v+vN8HuKyQhyF
WN8KluuUIpje9GVsv1m2pXRU4nkIESWajVRbwIl6aqnQ4iQ8a4/L3nCsWPoMSh/H
bfuP+7Ae/RE0HrWG9AXTIoyByb/teV5z52SAUqRIVf+U5xBI1tIXh+OqRVHsj9nU
B4nZIz5O59EiCdHUEzbQVzOutDMWL1OCt5KKY4i/NbfNKsz9xn+LfL6KrEhOzEez
sDeF2Uc31vLONWEAYKHEE8LtQ0E=
=rBWm
-END PGP SIGNATURE-

Bug#850246: missing dependencies, does not work

[Michal Čihař]

Package: python-social-auth
Version: 0.3.0-1
Severity: grave

Hi

The library is now completely unusable as it requires at least
social_core, which is not yet packaged. All files are currently stub
which should map old social auth API to new modularized code and
without the dependencies this is just completely unusable.

I think best approach would be to revert to 0.2.x for now as there is
no chance new packages 0.3.x requires will get in (due to soft freeze
starting today).

-- 
Michal Čihař | https://cihar.com/ | https://weblate.org/


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

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

Versions of packages python-social-auth depends on:
pn  python:any  

python-social-auth recommends no packages.

Versions of packages python-social-auth suggests:
pn  python-social-auth-doc  

-- no debconf information


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

Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

CC'd to the src:glm maintainer,

On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant 
 wrote:

Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].

[1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2

Ghis


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

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


Hi Guus, could you have a look at this please?

It looks like it is due to a regression in glm introduced in 0.9.8.3 
compared to 0.9.8.1. The CMake detection works correctly for amd64 but 
not i386.


The bug only shows up now because src:forge used to silently download a 
copy of glm if a system version were not found. I have corrected this 
behaviour and pushed a new version of the packaging, which now triggers 
the CMake detection problem.


Ghis

Bug#850247: RM: lambda-align [arm64 armhf mips mips64el mipsel ppc64el s390x] -- ROM; build dependency has been removed

[Sascha Steinbiss]

Package: ftp.debian.org
Severity: normal

Dear ftpmaster team,

as the maintainer of the lambda-align package in unstable, I would like
to kindly ask for the removal of  the lambda-align binaries for 1.0.0-3. 
Its build dependency seqan2 has been restricted to a limited set of
architectures in the meantime, so lambda-aligner won't be built on arm64,
armhf, mips, mips64el, mipsel, ppc64el and s390x anymore.
This is blocking a testing transition at the moment.

If there are any more questions, please let me know.

Best regards
Sascha

Bug#850248: New upstream version available

[Ian Jackson]

Package: vtwm
Version: 5.4.7-3

Upstream git appears to have what git-describe calls
`5.5.0-rc8-15-g0b1705e' from 2013.  That would probably be nice.  (But
not for stretch.)

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'

[latinovic]

Control: tag -1 + patch

The same issue is noticed on mips64el:
https://buildd.debian.org/status/fetch.php?pkg=libowfat&arch=mips64el&ver=0.30-2&stamp=1483522524

Both archs (s390x and mips64el) do not supportwaitpid, wait4 is used instead.
(https://github.com/ensc/dietlibc/blob/master/s390x/__waitpid.c)
As there is no waitpid system call for these archs,undefined reference to 
`__libc_waitpid' appears.

In order to fix this it is needed to use wait4 syscall instead in 
syscalls.s/waitpid.S.

The patch that solves this is attached.



diff -uNr dietlibc-0.34~cvs20160606.orig/syscalls.s/waitpid.S dietlibc-0.34~cvs20160606/syscalls.s/waitpid.S
--- dietlibc-0.34~cvs20160606.orig/syscalls.s/waitpid.S	2016-06-06 15:30:00.0 +
+++ dietlibc-0.34~cvs20160606/syscalls.s/waitpid.S	2017-01-04 15:16:09.0 +
@@ -2,4 +2,6 @@
 
 #ifdef __NR_waitpid
 syscall_weak(waitpid,waitpid,__libc_waitpid)
+#else
+syscall_weak(wait4,waitpid,__libc_waitpid)
 #endif

Bug#850249: ITP: node-speedometer -- simple speed measurement in javascript

[Himanshu Chopra]

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

* Package name: node-speedometer
  Version : 1.0.0
  Upstream Author : Mathias Buus Madsen 
* URL : https://github.com/mafintosh/speedometer
* License : Expat
  Programming Lang: JavaScript
  Description : simple speed measurement in javascript

Bug#840750: RFS: picocoin/0.1-2.gbp43047g

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

The package has lots of lintian warnings, please fix them first.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#850229: dune-grid: FTBFS (not enough slots available)

[Graham Inggs]

Hi

On 05/01/2017 12:05, Santiago Vila wrote:

Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 test-yaspgrid-yaspfactory-1d

   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--


I started seeing similar errors in other MPI applications since the 
upload of openmpi 2.0.2~ to unstable.


The solution was to add --oversubscribe to the mpirun command line, e.g. 
[1].



The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders).


If I understand correctly, --oversubscribe should be needed in your case 
where you have fewer CPUs than the number of processes requested, but I 
was seeing the errors even when there were more than enough CPUs available.


Regards
Graham


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/lammps.git/commit/?id=64c465da9036114cec9220ebe58bd264b974b694

Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

On 05.01.2017 11:36, Santiago Vila wrote:
> On Thu, Jan 05, 2017 at 11:06:50AM +0100, Ole Streicher wrote:
>> Hi all,
>>
>> On 04.01.2017 20:57, Santiago Vila wrote:
>>> I still want to build all packages and have 0 or 1 failures,
>>> so in this case the probability should be 1/50/2, i.e. 1%.
>>>
>>> I think this is still feasible.
>>
>> My experience is that the buildds that are currently in use provide more
>> build problems than the packages themself. BTW, why don't you count this
>> as RC?
> 
> Can you clarify the question? I don't understand what you refer exactly.

It does not make sense to have 100% reliability on the package itself to
build but only 95% on the buildds. If we want to have reliability, then
every chain member counts -- and the weakest one in the moment for me
does not seem to be the packages themselves, but the buildd setups we
currently have. So, if you consider unreliable package builds as an RC
problem, you should also consider the unreliable buildd setup as an RC
problem.

>>> But as far as there are people in this project who consider that a
>>> package which FTBFS on single-CPU machines more than 50% of the time
>>> is ok "because it does not usually fail in buildd.debian.org",
>>> we are doomed.
>>
>> We have 10 archs, and with a 50% chance of failure you will not get any
>> version built. Even when the buildds try it two or three times.
> 
> It's actually more subtle than that.
> 
> The package may be ready to be built on multi-core machines, but not on
> single-core machines. So, the probability that I measure (greater than 50%),
> might not be the same as the probability on official autobuilders.

Ususally it is the other way around: packages build fine
single-threaded, but don't do so on many threads (or CPUs). At the end
it it also depends on how many CPUs you actually get for the build -- if
there are some packages built in parallel, the result may be as for a
single CPU.

> Then there is the other subtle thing: The package may be Arch:all, in
> which case a 50% of probability (this time independent on the number
> of CPUs) may go unnoticed very easily, either because the maintainer
> uploaded the .deb him/herself, or, if the maintainer uploaded
> in source-only form, we can just be lucky for that time.

I would favour much to ignore any prebuilt binaries and to re-build
everything anyway.

> We provide software which is free to be modified. If people is going
> to modify it and then it fails because the package only builds ok in
> buildd.debian.org, then we are removing one of the essential freedoms,
> the freedom to modify it, and the package becomes de-facto non-free,
> even if we still distribute it in main.

First, the multi-CPU buildd setup is free (as in speech), isn't it? So,
depending on this does not make anything non-free. I don't see why the
dependency on a specific build environment would change the DFSG
freeness at all (as long as the build environment itself is DFSG free).

Then, we are speaking about random failures. If you use a single-core
and see a build failure, you can just pragmatically repeat it.

Sorry, I don't see why this would restrict DFSG freedom here.

Best regards

Ole

Bug#842041: RFS: highlighterpdf/0.7-1 [ ITP]

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

The source tarball contains just .jar. It needs to contain the sources and
tools to build those sources into the .jar.

Packaging problems:
You shouldn't put random numbers into Closes: in the changelog entry, you
need to open the ITP bug and use its number there.
The current recommended debhelper compat level is 10.
The Homepage field should point to the project page where the project
source can be obtained.
The manpage section 6 is for games.
.desktop should't have extra blank lines. And why StartupNotify=false?
The icon should be installed in the standard icon path.
You can't install a .jar into /usr/bin, that won't work.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#845499: Clarification...

[Samuel Thibault]

Hello,

Alec Leamas, on Thu 05 Jan 2017 01:06:03 +0100, wrote:
> Anyway, a new -7 update is already under way, this time With Patch Included
> (tm)

Cool, now it went fine :)

Thanks,
Samuel

Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'

[Thorsten Glaser]

latinovic dixit:

> The patch that solves this is attached.

I think the patch is broken, wait4() requires an additional
argument which must be zero for waitpid() emulation, not some
random stack (or register, depending on the architecture) garbage.

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#850250: FTBFS on sparc with DEB_BUILD_OPTIONS=nolang=biarch

[James Clarke]

Source: gcc-6
Version: 6.3.0-2
Tags: patch
User: debian-sp...@lists.debian.org
Usertag: sparc
X-Debbugs-Cc: helm...@debian.org, debian-sp...@lists.debian.org

Thanks to the recent changes to get gcc to target ultrasparc by default,
the biarch build is now successful. However, it still fails in exactly
the same way when biarch is disabled; I believe the following patch
should fix this. Is there a good reason why this wasn't done before,
other than an oversight?

Regards,
James

> --- debian/rules2.orig  2017-01-05 11:06:00.846518693 +
> +++ debian/rules2   2017-01-05 11:08:24.644346025 +
> @@ -543,9 +543,9 @@
>  endif
>
>  ifneq (,$(findstring sparc-linux,$(DEB_TARGET_GNU_TYPE)))
> +  CONFARGS += --with-cpu-32=ultrasparc
>ifeq ($(biarch64),yes)
>  CONFARGS += --enable-targets=all
> -CONFARGS += --with-cpu-32=ultrasparc
>endif
>  endif
>

Bug#850182: Please disable TSX in stretch and backport to jessie

[Henrique de Moraes Holschuh]

On Wed, Jan 4, 2017, at 17:04, Ian Jackson wrote:
> amd64 with TSX is for the purposes of pthreads like a new
> architecture: the locking primitives behave differently and expose
> extra bugs.

Also valid for S/390x, POWER, and anything else where glibc 2.24
supports hardware lock elision.

> These extra bugs will be discovered only by chance (as we see in that
> bug report and in the earlier bugs #843324 and maybe #842796).  As
> more TSX-capable hardware becomes available, we will discover more of
> them, during the life of stretch, when they are hard to fix.
> 
> Also, we don't have the capability to debug them.  I don't think we
> can have a release architecture for stretch that has no porterboxes.

All it takes is an extra "if(unlikely(lock-is-unlocked))
raise(SIGSEGV);" line on the libpthread unlock path for
no-lock-elision).  Or you could generate a warning instead.

That said, I am not speaking against disabling hardware lock elision
acceleration for Debian Stretch.  We might be better off disabling it.

-- 
  Henrique de Moraes Holschuh 

Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'

[Christian Seiler]

Control: retitle -1 dietlibc: waitpid broken w/ -lpthread on s390, s390x, 
mips64, ia64
Control: tags -1 + confirmed
Control: tags -1 - patch

Thanks for reassigning this.

On 01/05/2017 11:48 AM, latinovic wrote:
> Both archs (s390x and mips64el) do not support waitpid, wait4 is used instead.
> (https://github.com/ensc/dietlibc/blob/master/s390x/__waitpid.c)
> As there is no waitpid system call for these archs, undefined reference to 
> `__libc_waitpid' appears.
> 
> In order to fix this it is needed to use wait4 syscall instead in 
> syscalls.s/waitpid.S.

Unfortunately, this is wrong, because then the flags parameter for
wait4 would be undefined and depend on the previous state of
program execution.

Also, dietlibc would then contain two copies of waitpid() on these
platforms, because that doesn't remove __waitpid.c from there.

Furthermore, ia64 is also affected because that contains a carbon
copy of s390's __waitpid.c. (Don't know which one was first.)

The correct solution is to change the name of the function to
__libc_waitpid in __waitpid.c and to define a weak alias for
waitpid there. I'm already working on this (saw your initial email
where you reassigned this), and will do an upload soon together
with regression tests for this. (The unit tests for dietlibc
do already do check for a working waitpid(), but unfortunately they
don't link against -lpthread.)

Regards,
Christian

Bug#821333: snapshot.debian.org: should advertise source-specific [check-valid-until=false] in preference to system-wide flag

[Peter Palfrader]

On Wed, 04 Jan 2017, Jochen Sprickerhof wrote:

> Package: snapshot.debian.org
> Followup-For: Bug #821333
> 
> Please find a patch attached.
> Thanks for the really useful service.

> +deb [check-valid-until=no]  href="/archive/debian/20091004T111800Z/">http://snapshot.debian.org/archive/debian/20091004T111800Z/
>  lenny main
> +deb-src [check-valid-until=no]  href="/archive/debian/20091004T111800Z/">http://snapshot.debian.org/archive/debian/20091004T111800Z/
>  lenny main

Which version of apt started supporting this flag?

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#850251: ITP: node-is-npm -- Check if your code is running as an npm script

[Ameya Apte]

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

* Package name: node-is-npm
  Version : 1.0.0
  Upstream Author : Sindre Sorhus  (
http://sindresorhus.com)
* URL : https://github.com/sindresorhus/is-npm
* License : Expat
  Programming Lang: JavaScript
  Description : Check if your code is running as an npm script

Bug#849913: dpkg-shlibdeps: searches wrong architecture libraries

[Raphael Hertzog]

Hi Helmut,

On Tue, 03 Jan 2017, Helmut Grohne wrote:
> No, because using binutils-multiarch is broken. Whenever a new
> architecture is brought up, binutils-multiarch lacks support for it.

Ok, that makes sense.

> > That would let us use objdump to inspect any library and let
> > dpkg-shlibdeps figure out whether it's a library of the correct
> > architecture or not.
> 
> Inspecting those objects is a bug in the first place. You are trying to
> work around it again rather than fixing it properly. I admit that it is
> non-trivial to fix as it is deeply rooted in glibc. dpkg-shlibdeps
> inherits it by parsing /etc/ld.so.conf.d.

I don't think it's wrong... we are trying to behave like ld.so and I guess
that ld.so does check whether the library is built for the same
architecture.

It's just that the way dpkg-shlibdeps uses to make the same test is not
reliable as you witnessed with the failure. So we should likely find a
better way to do this test.

Maybe by allowing failures on "objdump -a" or by using something else.

I just made a test and noticed that while objdump fails on binaries of
other architectures, readelf does work... but its output is human readable
and not really suitable for machine parsing.

> We could also stop working around problems and start fixing the mess
> instead.

That's what I'm doing too...

> I say let's go back to what worked and fix this properly. Why are you
> backing off now? You did agree on reverting it on regressions earlier.
> Now there is a regression. How much more crystal clear could it be?

Why do you need to be so agressive?

I'm fine with a revert if we can't find a better fix as I don't want
to affect your work negatively. But it's also crystal clear to me that
a revert is not a "proper fix".

The thing worked before because it stopped at the first library found
and it was always one for the correct architecture. Unfortunately it was
not always found in the correct path.

Ne we will always find it in the correct path but we also find libraries
for non-matching architectures and "objdump -a" unhelpfully barfs at those.

/bin/file also knows how to identify the ELF file format of any
architecture but again it's not something really suitable for machine
consumption.

I am thus suggesting the attached patch to ignore objdump failures when
we try to identify the file format but to warn about it so that we can
still have hints about the ignored library if anything goes
wrong later on.

Can you retry your cross-compiler build with this patch?

I would like to note that while the "objdump -a" failure does not happen
in all cases, I can inspect armhf binaries in my amd64 machine but not
the opposite.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
>From 86f59e1cc7b94ff8010117d42f87772b39a4b881 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Thu, 5 Jan 2017 12:16:11 +0100
Subject: [PATCH] Dpkg::Shlibs: ignore "objdump -a" failures in find_library()

On some architectures, "objdump -a" fails when trying to process
a foreign library with a message like this one:
objdump: /usr/lib/x86_64-linux-gnu/libc.so: File format not recognized

Since a927295c93fb7a17742441aa863aaffcf4a351b5 we are now analyzing all
libraries found and not only the first one found, so we can't afford to
fail just because objdump -a failed, instead we just issue a warning.

If the failure is not due to this problem, dpkg-shlibdeps will barf
a bit later because it was not able to find the library so I did not
add an error in case we issued a warning but did not find any other
instance of the same library.

Closes: #849913
---
 scripts/Dpkg/Shlibs.pm | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/scripts/Dpkg/Shlibs.pm b/scripts/Dpkg/Shlibs.pm
index 3bb3c7baf..24ffc81c9 100644
--- a/scripts/Dpkg/Shlibs.pm
+++ b/scripts/Dpkg/Shlibs.pm
@@ -156,9 +156,14 @@ sub find_library {
 foreach my $dir (@librarypaths) {
 	my $checkdir = "$root$dir";
 	if (-e "$checkdir/$lib") {
-	my $libformat = Dpkg::Shlibs::Objdump::get_format("$checkdir/$lib");
-	if ($format eq $libformat) {
-		push @libs, canonpath("$checkdir/$lib");
+	eval {
+		my $libformat = Dpkg::Shlibs::Objdump::get_format("$checkdir/$lib");
+		if ($format eq $libformat) {
+		push @libs, canonpath("$checkdir/$lib");
+		}
+	};
+	if ($@) {
+		warning("could not identify ELF format of %s", "$checkdir/$lib");
 	}
 	}
 }
-- 
2.11.0

Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1

[Henrique de Moraes Holschuh]

On Thu, 05 Jan 2017, Adam D. Barratt wrote:
> On Fri, 2016-12-16 at 10:17 -0200, Henrique de Moraes Holschuh wrote:
> > I would like to update the intel-microcode packages in stable to address
> > several critical errata in newer Intel processors.
> > 
> > The updated packages being proposed in this bug report are identical to
> > the ones in unstable/testing and jessie-backports, other than
> > debian/changelog and version numbering.
> > 
> > These changes have been tested in unstable since 2016-11-09, in testing
> > since 2016-11-15, and in jessie-backports since 2016-11-17, without any
> > issues being reported.
> 
> Please go ahead.

Uploaded.

Thank you!

-- 
  Henrique Holschuh

Bug#842244: congress: still FTBFS randomly

[Santiago Vila]

found 842244 4.0.0+dfsg1-3
severity 842244 important
thanks

Hi.

Sorry for the reopening, but this is still failing for me.

Quite often indeed. I built this 100 times yesterday and it failed 86 times.

Downgrading to "important" only to be on par with every other
FTBFS-randomly bug I've detected (as RM are planning to consider
RC-ness based on failure probability), but with a failure rate
of 86% this one is certainly to worry about.

Build logs available here:

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

Thanks.

Bug#850253: retty doesn't work anymore

[Christoph Berg]

Package: retty
Version: 1.0-2
Severity: grave

Hi,

while looking at fixing #817652 I tried to use retty but couldn't get
it to work. In the second terminal, nothing happens:

$ retty 3733
codesize: 138 codeaddr: ff99840c
stack: ff9983fc eip: ff998414 sub:48
^C
^\Verlassen

^C doesn't quit retty; on hitting ^\ the to-be-attached-to process
segfaults.

Kernel: amd64 4.7.6-1, in a i386 chroot (with linux32 personality).

Maybe it's time to RM retty?

(The packaging repo is now at
ssh://git.debian.org/git/collab-maint/pkg-retty.git if someone manages
to fix it.)

Christoph


signature.asc
Description: PGP signature

Bug#850229: dune-grid: FTBFS (not enough slots available)

[Ansgar Burchardt]

On Thu, 2017-01-05 at 12:59 +0200, Graham Inggs wrote:
> On 05/01/2017 12:05, Santiago Vila wrote:
> > Status:FAILED
> > Output:
> >    --
> > 
> >    There are not enough slots available in the system to
> > satisfy the 2 slots
> >    that were requested by the application:
> >  test-yaspgrid-yaspfactory-1d
> > 
> >    Either request fewer slots for your application, or make
> > more slots available
> >    for use.
> >    --
> > 
> 
> I started seeing similar errors in other MPI applications since the 
> upload of openmpi 2.0.2~ to unstable.
> 
> The solution was to add --oversubscribe to the mpirun command line, 

Yes, it looks like OpenMPI changed the default :-/

> The bug should be reproducible with sbuild on a single CPU virtual
> > machine.
> > It always fail for me (I tried 10 times in different autobuilders).
> 
> If I understand correctly, --oversubscribe should be needed in your
> case where you have fewer CPUs than the number of processes
> requested, but I was seeing the errors even when there were more than
> enough CPUs available.

On my laptop with 4 cores + HT (so 8 threads), I see `mpirun` complain
once I start more than 4 processes, i.e. more processes than real
cores.  Did you count threads or cores when you tried?

Ansgar

Bug#850254: ITP: node-extract-zip -- unzip a zip file into a directory using 100% pure gluten-free organic javascript

[Sumedh Pendurkar]

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

* Package name: node-extract-zip
  Version : 1.6.0
  Upstream Author : max ogden
* URL : https://github.com/maxogden/extract-zip
* License : BSD-2-Clause
  Programming Lang: JavaScript
  Description : unzip a zip file into a directory using 100% pure 
gluten-free organic javascript

Bug#850256: ITP: node-pkg-conf -- Get namespaced config from the closest package.json

[akshay kemekar]

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

* Package name: node-pkg-conf
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/pkg-conf#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Get namespaced config from the closest package.json

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[saurabhagrawal]

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

* Package name: node-is-retry-allowed
  Version : 1.1.0
  Upstream Author : Vsevolod Strukchinsky  
(github.com/floatdrop)
* URL : https://github.com/floatdrop/is-retry-allowed#readme
* License : Expat
  Programming Lang: JavaScript
  Description : My prime module

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

Hi there,

Let me nitpick a bit: ;-)

On 01/05/2017 12:52 PM, saurabhagra...@disroot.org wrote:
> * URL : https://github.com/floatdrop/is-retry-allowed#readme
>   Description : My prime module

The official package description appears to be:

"Is retry allowed for Error?"

And while that is still a bit vague, it does at least give an
indication what the module does, while I have no idea what
"my prime module" is supposed to mean?

I would urge you to use upstream's description when packaging
this module.

Regards,
Christian

Bug#846244: [php-maint] Bug#846244: php5-phpdbg: lacks /usr/bin/phpdbg alternative

[Antoine Musso]

Le 30/11/2016 à 10:44, Ondřej Surý a écrit :
> Control: severity -1 wishlist
> Control: tags -1 +wontfix
> 
> Hi Antoine,
> 
> this would change the behavior of stable system (imagine somebody
> already has a symlink
> or different copy of phpdbg), so this is not a material for updating
> stable release.
> 
> php7.0-phpdbg already registers phpdbg using alternatives system in
> Debian.

Hello,

That kind of make sense. I am glad to know that the package is using the
alternatives system with v 7.0.  Thank you!

-- 
Antoine "hashar" Musso

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

On Thu, Jan 5, 2017 at 12:32 AM, Tobias Frost  wrote:

> Control: tags -1 moreinfo
>
> BTW, you're using the tar.gz .. Can you use the tar.bz2 for the
> packaging as it compresses better? This is also the one that is picked
> up by uscan... (Just use uscan --force-download to get a copy and then
> delete the other one)
>

Done.


> - d/clean: You can use wildcards, eg. it is less fragile if your clean
> games/bin/* instead of the individual files.
>

Done.


> - you do not need to d/clean condig.(log|status)
>

Done.


> About the install:
> - there are a few files with *.conf that are going to /usr/share/...
> Are they conf-files that should actually go to /etc/ as a kind of
> system-wide configuration?
>

They would be game-specific -- the name of the game, ports used, The
tinymux-install script doesn't support it directly, but someone could run
that script multiple time, and rename the resulting tinymux directory to
the um-teen different games they want to run. Each one would need to have
it's own configuration.


>
> >  - There's no obvious override for the duplicate changelog warning.
>
> The problem is that dh_installchangelogs will pick it up, but you've
> got it also specified in d/docs.


Just removed CHANGES from d/docs.

>
>
You shouldn't install the doc INSTALL, as this is not relevant for
> Debian binary packages -- it talks mostly about how to compile etc.
> (README.Debian takes it job appearantly already)
>

Did not see that one in the d/docs file. There are references to it in
other readme files, but that file itself is not being installed.

>
> While this explains the why very well (and is too extensive on the what
> (this is will be in the diff) Convention is just to write:
>* New maintainer. (Closes: #YourITABugNumber)
>

Let's be fashionable. Changed to reference the bug.


> One thing I noted: NOTES mentions there is a default password. (I guess
> it it a kind of admin password) This is a bad idea, securitywise and
> should be changed.


It is a kind of admin password, the password to the ''god' account within
the game. A bit of tradition buried there (
https://en.wikipedia.org/wiki/Potrzebie). These mud games were once hosted
in hidden fashion on University boxes, hidden in plain sight. You had to be
smart enough to find the party or deserve an invitation. It's not like that
now.

OK, back to business. I agree that it is a bad idea. A fix would require
that the following lines in netmux.db be changed at install time:

>5
"$SHA1$X0PG0reTn66s$FxO7KKs/CJ+an2rDWgGO4zpo1co="

Or, a command-line option to netmux added that went through the steps of
loading the game's database but immediately changing the password to
something else before accepting connections. Both options would need
upstream work. I prefer the second option, but any option would require
upstream work.

None of the game accounts are given any control over the shell account. The
worst #1 should be able to do is delete the database from the inside or
change a configuration option which takes the game down by causing a
divide-by-zero. What worries me more than the initial, default #1 password.
is the UTF-8 state machine that parses input for all users and the fact all
users have access to PCRE globs. I still remember the old telnet bugs, and
PCRE globs are mini-programs, and it isn't hard to tie the game up for an
hour with a carefully chosen ones. We've added CPU limits within the inner
loops in the PCRE code to forestall this, and that's the only reasons why I
use the PCRE statically instead of using it as a library.

Bug#850257: xdotool fails to type: There are no windows on the stack

[Paride Legovini]

Package: xdotool
Version: 1:3.20160805.1-2
Severity: important

Dear Daniel,

Starting from 3.20160805.1-2 "xdotool type" doesn't work anymore:

$ xdotool type 'test'
There are no windows on the stack, Can't continue.

Downgrading to 3.20160512.1-1 solves the issue:

~ $ xdotool type 'test'
~ $ test

Let me know if the need further information and thank you for
maintaining this packge.

Paride

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[saurabh agrawal]

Thanks!
I'll fix it in the control file.

On 05-Jan-2017 5:39 PM, "Christian Seiler"  wrote:

Hi there,

Let me nitpick a bit: ;-)

On 01/05/2017 12:52 PM, saurabhagra...@disroot.org wrote:
> * URL : https://github.com/floatdrop/is-retry-allowed#readme
>   Description : My prime module

The official package description appears to be:

"Is retry allowed for Error?"

And while that is still a bit vague, it does at least give an
indication what the module does, while I have no idea what
"my prime module" is supposed to mean?

I would urge you to use upstream's description when packaging
this module.

Regards,
Christian

Bug#850238: ITP: node-hoek -- General purpose node utilities

[Akash Sarda]

Oh. Impatience is not good😑

On Jan 5, 2017 4:03 PM, "Holger Levsen"  wrote:

> On Thu, Jan 05, 2017 at 03:39:31PM +0530, Akash Sarda wrote:
> >   Description : General purpose node utilities
> >
> >  Utility methods for the hapi ecosystem. This module is not intended to
> > solve every problem for everyone, but rather as a central place to store
> > hapi-specific methods. If you're looking for a general purpose utility
> > module, …
>
> please make the short description match the long one…
>
>
> --
> cheers,
> Holger
>

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

On 01/05/2017 01:18 PM, Martin Bagge / brother wrote:
> On 2017-01-05 13:04, Christian Seiler wrote:
>> The official package description appears to be:
> 
>> "Is retry allowed for Error?"
> 
>> And while that is still a bit vague, it does at least give an 
>> indication what the module does, while I have no idea what "my
>> prime module" is supposed to mean?
> 
>> I would urge you to use upstream's description when packaging this
>> module.
> 
> Well. They did.
> 
> https://github.com/floatdrop/is-retry-allowed/blob/8ca0d01b/package.json
> #L4
> reads
> 
> "description": "My prime module",

Yikes. My apologies, then at least now I get where that comes
from.

Still, the description on the github link appears to be the
one that's preferable to "my prime module". So thanks for
intending to fix this.

Regards,
Christian

Bug#850142: mariadb_config garbage output

[Andreas Beckmann]

Control: severity -1 serious

On 2017-01-04 16:51, Georg Richter wrote:
> Hi Andreas,
> 
> I just merged a mariadb_config bug from master into 2.3 - can you please
> try latest git version?
> 
> Thanks!
> 
> /Georg

That's unlikely to fix this issue.

I did a bit more debugging - adding a
  puts("DONE");
right before the exit(0)/exit(1) calls results in

(sid_mips64el-dchroot)anbe@eller:~/rmysql/mariadb-connector-c-2.3.1/obj-mips64el-linux-gnuabi64$
 ./mariadb_config/mariadb_config --socket
/var/run/mysqld/mysqld.sock
DONE
DONE
run/mysqld/mysqld.sock
�
 

so this may not be directly mariadb_config's fault, but perhaps a libc or 
compiler problem on that platform.
Please contact the mips64el porters to help with debugging.


Andreas

Bug#850258: glances: calling home?

[Cristian Ionescu-Idbohrn]

Package: glances
Version: 2.7.1.1-2
Severity: normal

This is what I see after:

# /etc/init.d/glances restart

Jan  5 11:23:21 debian tcpspy[30804]: connect: user glances, local 
10.11.12.13:58480, remote 45.79.77.20:http
Jan  5 11:23:21 debian tcpspy[30804]: connect: user glances, local 
10.11.12.13:58314, remote 54.235.135.158:https
Jan  5 11:23:21 debian tcpspy[30804]: connect: user glances, local 
10.11.12.13:50750, remote 79.98.145.42:http
Jan  5 11:23:22 debian tcpspy[30804]: disconnect: user glances, local 
10.11.12.13:58480, remote 45.79.77.20:http
Jan  5 11:23:22 debian tcpspy[30804]: disconnect: user glances, local 
10.11.12.13:58314, remote 54.235.135.158:https
Jan  5 11:23:22 debian tcpspy[30804]: disconnect: user glances, local 
10.11.12.13:50750, remote 79.98.145.42:http
Jan  5 11:46:38 debian tcpspy[30804]: connect: user glances, local 
10.11.12.13:51712, remote 79.98.145.42:http
Jan  5 11:46:39 debian tcpspy[30804]: disconnect: user glances, local 
10.11.12.13:51712, remote 79.98.145.42:http

And the reverse lookup shows:

$ host 45.79.77.20
20.77.79.45.in-addr.arpa domain name pointer li1176-20.members.linode.com.
$ host 54.235.135.158
158.135.235.54.in-addr.arpa domain name pointer 
ec2-54-235-135-158.compute-1.amazonaws.com.
$ host 79.98.145.42
42.145.98.79.in-addr.arpa is an alias for 42.32/27.145.98.79.in-addr.arpa.
42.32/27.145.98.79.in-addr.arpa domain name pointer 42.pl.

`whois' says:

45.79.77.20- OrgTechName:   Linode Network Operations
54.235.135.158 - OrgTechName:   Amazon EC2 Network Operations
79.98.145.42   - 42.pl, Nitronet Sp. z o.o.

I naturally wonder what's going on?

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages glances depends on:
ii  adduser3.115
ii  libjs-angularjs1.5.10-1
ii  libjs-lodash   4.16.6+dfsg-2
ii  lsb-base   9.20161125
ii  python3-pkg-resources  32.0.0-1
ii  python3-psutil 5.0.0-1
pn  python3:any

Versions of packages glances recommends:
ii  hddtemp 0.3-beta15-52
ii  lm-sensors  1:3.4.0-3
pn  python3-bottle  
pn  python3-docker  
pn  python3-influxdb
pn  python3-matplotlib  
pn  python3-netifaces   
pn  python3-pysnmp4 
pn  python3-pystache

glances suggests no packages.

-- Configuration Files:
/etc/default/glances changed:
RUN="true"


-- no debconf information


Cheers,

-- 
Cristian

Bug#850259: ITP: node-single-line-log -- Keep writing to the same line in the terminal. Very useful when you write progress bars, or a status message during longer operations

[Nupur Malpani]

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

* Package name: node-single-line-log
  Version : 1.1.2
  Upstream Author : Tobias Baunbæk 
* URL : https://github.com/freeall/single-line-log#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Keep writing to the same line in the terminal. Very
useful when you write progress bars, or a status message during longer
operations

Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

CC'd  the Debian CMake Team, who might be able to help.

On 05/01/17 10:48, Ghislain Vaillant wrote:

CC'd to the src:glm maintainer,

On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant
 wrote:

Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in
the past)

Dear Maintainer,

Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].

[1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2

Ghis


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

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


Hi Guus, could you have a look at this please?

It looks like it is due to a regression in glm introduced in 0.9.8.3
compared to 0.9.8.1. The CMake detection works correctly for amd64 but
not i386.

The bug only shows up now because src:forge used to silently download a
copy of glm if a system version were not found. I have corrected this
behaviour and pushed a new version of the packaging, which now triggers
the CMake detection problem.

Ghis


Alright, this one is a bit tricky. Looking at the diff between 0.9.8.1 
and 0.9.8.3:


```
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b7df09f..253eee5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -164,7 +164,7 @@ set(GLM_INSTALL_CONFIGDIR 
"${CMAKE_INSTALL_LIBDIR}/cmake/glm")

 install(DIRECTORY glm DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})

 write_basic_package_version_file(
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 VERSION ${GLM_VERSION}
 COMPATIBILITY AnyNewerVersion
 )
@@ -188,7 +188,7 @@ configure_package_config_file(
 install(
 FILES

"${CMAKE_CURRENT_BINARY_DIR}/${GLM_INSTALL_CONFIGDIR}/glmConfig.cmake"
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 DESTINATION ${GLM_INSTALL_CONFIGDIR}
 )
```

It looks like the glm version lookup did not work before (because the 
version file was wrongly named) and has been fixed in the most recent 
release.


Now if we inspect the content of glmConfigVersion.cmake, we find the 
following code, which I believe to be our culprit:


```
# check that the installed version has the same 32/64bit-ness as the one 
which is currently searching:

if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
   math(EXPR installedBits "8 * 8")
   set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
   set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
```

Hence the following outcome during the build in src:forge for any 32-bit 
architecture:


```
CMake Error at src/backend/opengl/CMakeLists.txt:17 (FIND_PACKAGE):
  Could not find a configuration file for package "glm" that is compatible
  with requested version "".

  The following configuration files were considered but not accepted:

/usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
```

So the question is how to instruct CMake to produce a ConfigVersion file 
without the above bit-ness check?


Ghis

Bug#849020: jessie-pu: package systemd/215-17+deb8u6

[Michael Biebl]

Am 05.01.2017 um 07:18 schrieb Adam D. Barratt:
> Michael, please feel free to upload. 

Thanks. done

(I'm assuming that the resulting
> package has had at least some testing on a jessie system already.)

I did test the invididual fixes in a jessie VM and lxc container, which
included installing and running the final version of systemd_215-17+deb8u6.

Michael
-- 
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#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

Now CC'd to the Debian CMake Team

On 05/01/17 12:26, Ghislain Vaillant wrote:

CC'd  the Debian CMake Team, who might be able to help.

On 05/01/17 10:48, Ghislain Vaillant wrote:

CC'd to the src:glm maintainer,

On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant
 wrote:

Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in
the past)

Dear Maintainer,

Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].

[1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2

Ghis


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

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


Hi Guus, could you have a look at this please?

It looks like it is due to a regression in glm introduced in 0.9.8.3
compared to 0.9.8.1. The CMake detection works correctly for amd64 but
not i386.

The bug only shows up now because src:forge used to silently download a
copy of glm if a system version were not found. I have corrected this
behaviour and pushed a new version of the packaging, which now triggers
the CMake detection problem.

Ghis


Alright, this one is a bit tricky. Looking at the diff between 0.9.8.1
and 0.9.8.3:

```
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b7df09f..253eee5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -164,7 +164,7 @@ set(GLM_INSTALL_CONFIGDIR
"${CMAKE_INSTALL_LIBDIR}/cmake/glm")
 install(DIRECTORY glm DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})

 write_basic_package_version_file(
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 VERSION ${GLM_VERSION}
 COMPATIBILITY AnyNewerVersion
 )
@@ -188,7 +188,7 @@ configure_package_config_file(
 install(
 FILES

"${CMAKE_CURRENT_BINARY_DIR}/${GLM_INSTALL_CONFIGDIR}/glmConfig.cmake"
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 DESTINATION ${GLM_INSTALL_CONFIGDIR}
 )
```

It looks like the glm version lookup did not work before (because the
version file was wrongly named) and has been fixed in the most recent
release.

Now if we inspect the content of glmConfigVersion.cmake, we find the
following code, which I believe to be our culprit:

```
# check that the installed version has the same 32/64bit-ness as the one
which is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
   math(EXPR installedBits "8 * 8")
   set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
   set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
```

Hence the following outcome during the build in src:forge for any 32-bit
architecture:

```
CMake Error at src/backend/opengl/CMakeLists.txt:17 (FIND_PACKAGE):
  Could not find a configuration file for package "glm" that is compatible
  with requested version "".

  The following configuration files were considered but not accepted:

/usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
```

So the question is how to instruct CMake to produce a ConfigVersion file
without the above bit-ness check?

Ghis

Bug#850260: ITP: node-ansi-align -- align-text with ANSI support for CLIs

[Yashashree Kolhe]

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

* Package name: node-ansi-align
  Version : 1.1.0
  Upstream Author : nexdrew
* URL : https://github.com/nexdrew/ansi-align#readme
* License : ISC
  Programming Lang: JavaScript
  Description : align-text with ANSI support for CLIs

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2017-01-05 13:04, Christian Seiler wrote:
> The official package description appears to be:
> 
> "Is retry allowed for Error?"
> 
> And while that is still a bit vague, it does at least give an 
> indication what the module does, while I have no idea what "my
> prime module" is supposed to mean?
> 
> I would urge you to use upstream's description when packaging this
> module.

Well. They did.

https://github.com/floatdrop/is-retry-allowed/blob/8ca0d01b/package.json
#L4
reads

"description": "My prime module",

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlhuOZkACgkQOIRDexPY
/4uYvQ/7BiyOh0+4ubzf6VRuoUnQjhMX9NlnhjuTTGmS4BnYK6rKALuZ5FXtEmnd
Ht6Hh7a3FQh6c9G7a4PvEyJBdnJdPlc/2vk7szYKJC73ke+O1JFAsXBomF1IUeC9
LEcWV8oLYFcLO30qGfSfI08TsTx8yzlaG7gr9/5QV5jDTzDyNV7FEN1JZtrmvDS7
etLipBLxxoNFEyBlar8xO/fq+qzhrTWnlJ/YWilpLOZI9t/vsBxHGOicRwHuNbM9
6NCbMzIPrTE/rRus1GhjUGuPAgCYblV/BwXAqCxuBd4lesUsPQMB2+tQK0fJ6P2g
5Rk2HxN+FtUaWZD9G3g577cYkl1KDYZ0RJW4sSMX6A2zoWYWV2Ne6q/VH1/M/Qju
qD4yfdI4wfhg/Q87MZZtghZJNNfqHoC71BLjBP5uD/oduHsOclewyTu8er0oXp1k
odwKSuYUCnpPplNiUcjtZaNnrto8vor8Em3BOovEA8Cl4WGWjkv7Wg5iPsYa7uoB
NZYSSON6GGjVwIh6NmDE78urBfpHX5gg8aWKyPVYOJKofpCb6a1t6xomsv0h9Y/m
EkGN+labdO8tF+efa0Wh6WcgL7ZP8ITiHuUeQ4z6gdWy+qLFqoRBz8LsCxG+OtoP
E3BkxPfbIyYN+hjBnsa/PidT8vbc+oTQcSTluTEkBshyr2Mvh6Y=
=V2QQ
-END PGP SIGNATURE-

Bug#724229: squid-deb-proxy and httpredir.debian.org

[Alexandre Rossi]

Hi,

There are two issues regarding httpredir.debian.org.

1) It redirects to various mirrors which must be allowed in
squid-deb-proxy ACLs. I can see the following solutions to this:
- feeding squid-deb-proxy with an explicit list of mirrors domains
(for instance parsed from the official list[1] or a better textual
source, or a subset of this list (geographic?)
- the same but using mirror urls (better than domains because mirrors
may host other material)
- allow mirror files only (mostly .deb, .gz, .xz, .bz2, .udeb, etc.)
- allow everything

The answer depends on the use case and on what is the problem if
allowing too much through squid-deb-proxy. As this tool is, I think,
only used on private networks, squid-deb-proxy using the same Internet
connection as its clients, the only problem I can see is caching
unwanted files.

2) Files downloaded on one mirror are cached independently of the same
files downloaded from another mirror. squid has a nice feature to
address this: Store ID [2]. The idea is to map each mirror URL to a
generic storing URL: a package downloaded on any mirror gets the same
cache identifier and thus gets cached as the same file. But this
requires generating some rules from mirror list[1], again.

I have a working implementation and a small python3 script that can
generate mirror-dstdomain.acl and storeid rules for the 443 (as of
today) mirrors. However, my concern is that this seems a bit overkill
as httpredir.debian.org redirects my squid-deb-proxy to only 3 or 4
mirrors. Restricting this to my country would make sense. Also, this
installation is for my home, so performance degradation from using
many regex ACLs may never be an issue, but it might if deployed for
numerous clients.

I attached my draft patch including the helper script (which would
have to be manually triggered by the admin, cron or init integration
does not feel right) but any feedback would be valuable before
submitting, especially regarding what the default configuration should
be or whether to ask things in debconf (e.g. downloading full list of
mirrors and making storeid the default).

Thanks for reading,

Alex

[1] https://www.debian.org/mirror/list-full
[2] http://wiki.squid-cache.org/Features/StoreID


squid-deb-proxy-724229-draft.patch
Description: Binary data

Bug#849813: zfs-zed.service can't start

[Stefan Bühler]

On Sat, 31 Dec 2016 12:24:20 + Rho YounJae  wrote:
> Package: zfs-zed
> Version: 0.6.5.8-2~bpo8+1
> Severity: minor
> 
> Dear Maintainer,
> 
> zfs-zed.service can't start since there is no /sbin/zed

This bug is also present in testing, and a package with the only 
purpose of running a daemon is unusable if it cannot run the daemon...

The systemd file is generated, and needs to be patched somehow. Or 
moving zed to /usr/sbin needs to be reverted.

Also see:
https://anonscm.debian.org/cgit/pkg-zfsonlinux/zfs.git/tree/etc/systemd/system/zfs-zed.service.in?h=debian/0.6.5.8-2

Bug#848414: systemfixtures: still FTBFS randomly

[Santiago Vila]

found 848414 0.6.1-1
severity 848414 important
thanks

Hi.

Sorry for the reopening but this is still (randomly) failing for me.
The following test failed for me:

ERROR: test_listen (systemfixtures.tests.test_executable.FakeExecutableTest)

at least three times.

Build logs available here:

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

Thanks.

Bug#850070: Processed: reassign 850070 to pylint

[Oleksandr Gavenko]

On Thu, Jan 5, 2017 at 1:07 AM, Sandro Tosi  wrote:

> I'm not convinced we should change anything in pylint to support
> emacs21, which has been removed from debian since 2009
>
> I like keeping Emacs 21 in order to test features instead of scanning
through  NEWS files.

And you are wrong in assumption that the only way to install package is
from official Debian repository.

The right way to write install file is to check supported feature and not
to reject unsupported feature.

So in some way you are right that adding case for Emacs 21 is wrong thing.
But most of /usr/lib/emacsen-common/packages/install/* written in a broken
way for my second point.  They SHOULD check for emacs24/emacs25 $FLAVOR
instead of rejecting xemacs, emacs22 etc.

Bug#848137: problem with the upgrade of tango-db

[Andreas Beckmann]

On 2017-01-04 21:55, Paul Gevers wrote:
> Hi Frederic-Emmanuel, Andreas,
> 
> @Andreas, am I correct in the assumption that jessie to stretch with
> tango-db was fine until MariaDB became the default? Or was this
> migration with tango-db just never tested before? Have you seen other
> dbconfig-common dependent packages fail since MariaDB became default (or
> maybe since dbconfig-common 2.0.5 (26-08-2016)?

I can't remember the details right now, but it is possible that this
started to fail after the mariadb switch (which is a non-trivial thing
to test with piuparts). I could try to find some older logs ...
And I don't remember any other package having a similar issue.

I needed, I could do further checks (or log lookup) next week.


Andreas

Bug#847108: ginger-base source updated

[Lucio Correia]

I've uploaded a new package fixing DTD warning.

dget -x 
https://mentors.debian.net/debian/pool/main/g/ginger-base/ginger-base_2.2.2-1.dsc


Regards,
--
Lucio Correia

Bug#850262: libtheschwartz-perl: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:libtheschwartz-perl
Version: 1.12-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
perl -I. Build.PL --installdirs vendor --config "optimize=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config 
"ld=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'TheSchwartz' version '1.12'
   dh_auto_build -i
perl Build
Building TheSchwartz
   dh_auto_test -i
perl Build test --verbose 1

[... snipped ...]

ok 6 - got server time
ok
t/unique.t . 
1..18
ok 1 # skip MySQL not accessible as root on localhost
ok 2 # skip MySQL not accessible as root on localhost
ok 3 # skip MySQL not accessible as root on localhost
ok 4 # skip MySQL not accessible as root on localhost
ok 5 # skip MySQL not accessible as root on localhost
ok 6 # skip MySQL not accessible as root on localhost
ok 7 # skip PgSQL not accessible as root on localhost
ok 8 # skip PgSQL not accessible as root on localhost
ok 9 # skip PgSQL not accessible as root on localhost
ok 10 # skip PgSQL not accessible as root on localhost
ok 11 # skip PgSQL not accessible as root on localhost
ok 12 # skip PgSQL not accessible as root on localhost
ok 13 - made first feed major job
ok 14 - An object of class 'TheSchwartz::JobHandle' isa 'TheSchwartz::JobHandle'
ok 15 - made scratch major job
ok 16 - An object of class 'TheSchwartz::JobHandle' isa 'TheSchwartz::JobHandle'
ok 17 - made another feed major job
ok 18 - no handle
ok
t/work-before-funcids-exist.t .. 
1..6
ok 1 # skip MySQL not accessible as root on localhost
ok 2 # skip MySQL not accessible as root on localhost
ok 3 # skip PgSQL not accessible as root on localhost
ok 4 # skip PgSQL not accessible as root on localhost
ok 5 - inserted job
ok 6 - job is done
ok

Test Summary Report
---
t/declined.t (Wstat: 768 Tests: 78 Failed: 3)
  Failed tests:  68, 77-78
  Non-zero exit status: 3
Files=24, Tests=833, 123 wallclock secs ( 0.15 usr  0.03 sys +  3.08 cusr  0.65 
csys =  3.91 CPU)
Result: FAIL
Failed 1/24 test programs. 3/833 subtests failed.
dh_auto_test: perl Build test --verbose 1 returned exit code 255
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


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

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/libtheschwartz-perl/

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

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

Thanks.

Bug#850261: libmodule-starter-perl: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:libmodule-starter-perl
Version: 1.710+dfsg-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
perl -I. Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-fdebug-prefix-map=/<>/libmodule-starter-perl-1.710+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 
-fdebug-prefix-map=/<>/libmodule-starter-perl-1.710+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Module::Starter
Writing MYMETA.yml and MYMETA.json
   dh_auto_build -i
make -j1

[... snipped ...]

# Subtest: ignores_type = 1000
1..0 # SKIP Only testing a 1% sample
ok 9 # skip Only testing a 1% sample
# Subtest: ignores_type = 1001
1..0 # SKIP Only testing a 1% sample
ok 10 # skip Only testing a 1% sample
# Subtest: ignores_type = 1010
1..0 # SKIP Only testing a 1% sample
ok 11 # skip Only testing a 1% sample
# Subtest: ignores_type = 1011
1..0 # SKIP Only testing a 1% sample
ok 12 # skip Only testing a 1% sample
# Subtest: ignores_type = 1100
1..0 # SKIP Only testing a 1% sample
ok 13 # skip Only testing a 1% sample
# Subtest: ignores_type = 1101
1..0 # SKIP Only testing a 1% sample
ok 14 # skip Only testing a 1% sample
# Subtest: ignores_type = 1110
1..0 # SKIP Only testing a 1% sample
ok 15 # skip Only testing a 1% sample
# Subtest: ignores_type = 
1..0 # SKIP Only testing a 1% sample
ok 16 # skip Only testing a 1% sample
ok 5 - minperl = v5.24.1
ok 16 - license = lgpl3
ok 5 - builder = Module::Install
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/5 subtests 

Test Summary Report
---
t/test-dist.t (Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
Files=6, Tests=26, 24 wallclock secs ( 4.66 usr  0.67 sys + 13.54 cusr  1.30 
csys = 20.17 CPU)
Result: FAIL
Failed 1/6 test programs. 1/26 subtests failed.
Makefile:902: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 1
make[1]: Leaving directory '/<>/libmodule-starter-perl-1.710+dfsg'
dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


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

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/libmodule-starter-perl/

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

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

Thanks.

Bug#850263: emacs25-common: incorrect font selection breaks box drawing (regression)

[Vincent Lefevre]

Package: emacs25-common
Version: 25.1+1-3
Severity: important

Font selection in Emacs 25 is incorrect and breaks box drawing.

See attached box-drawing.txt file (excerpt from
),
and PNG screenshots of what I obtain with Emacs 24 (correct) and
Emacs 25 (incorrect). This makes various files unreadable or look
ugly.

This is reproducible with "emacs25 -q", but not "emacs25 -Q" (but
the latter doesn't honor X resources).

FYI, I have in my X resources:

Emacs*font: 6x13

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, 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 emacs25-common depends on:
ii  dpkg1.18.18
ii  emacsen-common  2.0.8
ii  install-info6.3.0.dfsg.1-1+b1

Versions of packages emacs25-common recommends:
ii  emacs25-el  25.1+1-3

Versions of packages emacs25-common suggests:
ii  emacs25-common-non-dfsg  25.1+1-1
ii  ncurses-term 6.0+20161126-1

-- no debconf information
Box drawing alignment tests:  █
  ▉
  ╔══╦══╗  ┌──┬──┐  ╭──┬──╮  ╭──┬──╮  ┏━━┳━━┓  ┎┒┏┑   ╷  ╻ ┏┯┓ ┌┰┐▊ ╱╲╱╲╳╳╳
  ║┌─╨─┐║  │╔═╧═╗│  │╒═╪═╕│  │╓─╁─╖│  ┃┌─╂─┐┃  ┗╃╄┙  ╶┼╴╺╋╸┠┼┨ ┝╋┥▋ ╲╱╲╱╳╳╳
  ║│╲ ╱│║  │║   ║│  ││ │ ││  │║ ┃ ║│  ┃│ ╿ │┃  ┍╅╆┓   ╵  ╹ ┗┷┛ └┸┘▌ ╱╲╱╲╳╳╳
  ╠╡ ╳ ╞╣  ├╢   ╟┤  ├┼─┼─┼┤  ├╫─╂─╫┤  ┣┿╾┼╼┿┫  ┕┛┖┚ ┌┄┄┐ ╎ ┏┅┅┓ ┋ ▍ ╲╱╲╱╳╳╳
  ║│╱ ╲│║  │║   ║│  ││ │ ││  │║ ┃ ║│  ┃│ ╽ │┃  ░░▒▒▓▓██ ┊  ┆ ╎ ╏  ┇ ┋ ▎
  ║└─╥─┘║  │╚═╤═╝│  │╘═╪═╛│  │╙─╀─╜│  ┃└─╂─┘┃  ░░▒▒▓▓██ ┊  ┆ ╎ ╏  ┇ ┋ ▏
  ╚══╩══╝  └──┴──┘  ╰──┴──╯  ╰──┴──╯  ┗━━┻━━┛  ▗▄▖▛▀▜   └╌╌┘ ╎ ┗╍╍┛ ┋  ▁▂▃▄▅▆▇█
   ▝▀▘▙▄▟

Bug#850264: ITP: node-unzip-response -- Unzip a HTTP response if needed

[Himanshu Chopra]

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

* Package name: node-unzip-response
  Version : 2.0.1
  Upstream Author : Sindre Sorhus 
* URL : https://github.com/sindresorhus/unzip-response#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Unzip a HTTP response if needed

Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory

[Gaudenz Steinlin]

Hi

Aurelien Jarno  writes:

> On 2016-12-30 10:06, Emilio Pozuelo Monfort wrote:
>> On 29/12/16 20:56, Gaudenz Steinlin wrote:
>
> The problem is indeed a memory issue, not that the buildd doesn't have
> enough memory, but just that you can allocate only 2GB per process on a
> 32-bit MIPS machine. As Emilio said, the above GCC flag should help to
> reduce the memory usage by running the garbage collector more often.
>
> However gcc 6.3 seems to have improved the situation a bit, so I given
> back the packages, I hope they will build now. Otherwise I have a patch
> ready to change the GCC defaults. That said GCC upstream consider it's a
> bug in the garbage collector [1], so that should be fixed instead and the
> patch should be considered as a temporary workaround.
>

Aurelien thanks for taking care and resheduling the build. Unfortunately
this did not solve the problem. But setting the following variables
solves the virtual memory issue for me on the mipsel porterbox (eller):

export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1
export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1
export DEB_CFLAGS_MAINT_STRIP= -O2
export DEB_CXXFLAGS_MAINT_STRIP= -O2

But unfortunately the build fails at another point. See the log below.
I'm not sure how to fix this. If I understand it right these atomic
operations are just not supported on mipsel[1]. Or is there a way to make
them work?

Gaudenz

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296

libtool: link: g++ -I/usr/include/nss -I/usr/include/nspr -Wall -Wtype-limits 
-Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
-fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 
-Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall 
-Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
--param=ssp-buffer-size=4 -fPIE -fstack-protector-strong -Wstrict-null-sentinel 
-I../src/gmock/include -I../src/gmock/include -I../src/gmock/gtest/include 
-I../src/gmock/gtest/include -g -fdebug-prefix-map=/home/gaudenz/ceph=. 
-fstack-protector-strong -Wformat -Werror=format-security --param 
ggc-min-expand=10 -O1 -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -o .libs/ceph_test_cls_rgw 
test/cls_rgw/ceph_test_cls_rgw-test_cls_rgw.o  
/usr/lib/mipsel-linux-gnu/libatomic_ops.a -Wl,--as-needed ./.libs/librados.so 
./.libs/libcls_rgw_client.a ../src/gmock/lib/.libs/libgmock_main.a 
../src/gmock/lib/.libs/libgmock.a ../src/gmock/gtest/lib/.libs/libgtest.a 
./.libs/libglobal.a -lpthread -lm ./.libs/libradostest.a ./.libs/libcommon.a 
-ldl -lboost_thread -lboost_random -lrt -lblkid -luuid -lnss3 -lnssutil3 
-lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -lboost_iostreams -lboost_system -pthread
rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::load(std::memory_order) const':
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
rocksdb/librocksdb.a(memtable.o):/usr/include/c++/6/bits/atomic_base.h:396: 
more undefined references to `__atomic_load_8' follow
rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)':
/usr/include/c++/6/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
/usr/include/c++/6/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::load(std::memory_order) const':
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)':
/usr/include/c++/6/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
/usr/include/c++/6/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)':
/usr/include/c++/6/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
/usr/include/c++/6/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::load(std::memory_order) const':
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/6/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)':
/usr/include/c++/6/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'

Bug#849858: splt systemd tmpfile configuration files into respective packages

[Michael Biebl]

Am 01.01.2017 um 16:35 schrieb Michael Biebl:
> Am 01.01.2017 um 16:14 schrieb cgzones:
>> I meant the x11-common Debian package.
>> The SELinux file contexts are defined in the xserver module:
>> https://github.com/TresysTechnology/refpolicy/blob/master/policy/modules/services/xserver.fc
>>
>> 2017-01-01 16:04 GMT+01:00 Michael Biebl :
>>> Am 01.01.2017 um 16:00 schrieb cgzones:
 Oops,
 I am sorry.
 Seems I forgot to check the file affiliations beside the x11 one.

 So my question breaks down to whether the x11.conf file can be
 distributed by the x11-common (or similar) package.
>>>
>>> Why exactly? I don't find x11 specific selinux policy files.
> 
> I still don't understand why we would need to move the tmpfiles config
> file from systemd to x11-common. Mind you that I don't have any selinux
> knowledge.
> Afaics, in Debian we have selinux-policy-default which should contain
> the selinux policy for the X11 tmp directories.

On second thought, it might be worthwile moving the x11.conf into the
xorg package (considering headless servers and a future with Wayland
only). This should happen upstream though and would need involvement and
coordination between both systemd and xorg upstream.

You can file an issue for systemd at
https://github.com/systemd/systemd/issues/new


-- 
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#850263: emacs25-common: incorrect font selection breaks box drawing (regression)

[Vincent Lefevre]

On 2017-01-05 13:57:22 +0100, Vincent Lefevre wrote:
> Font selection in Emacs 25 is incorrect and breaks box drawing.
> 
> See attached box-drawing.txt file (excerpt from
> ),
> and PNG screenshots of what I obtain with Emacs 24 (correct) and
> Emacs 25 (incorrect). This makes various files unreadable or look
> ugly.
> 
> This is reproducible with "emacs25 -q", but not "emacs25 -Q" (but
> the latter doesn't honor X resources).
> 
> FYI, I have in my X resources:
> 
> Emacs*font: 6x13

M-x describe-fontset gives me for #x2542 (╂):

* Emacs 24 (correct):

-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1
[-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1]

* Emacs 25 (incorrect):

-*-fixed-medium-*-*-*-*-*-*-*-*-*-iso10646-1
-*-FreeMono-*-*-*-*-*-*-*-*-*-*-*-*
[-unknown-FreeMono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1]
-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1

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

Bug#802706: slepc: FTBFS: Unable to link with PETSc

[Santiago Vila]

found 802706 3.7.3+dfsg1-3
thanks

Hi.

Sorry for the reopening but this is happening again in stretch.
(I built this package 200 times, and it failed 200 times).

Build logs available here:

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

Thanks.