Bug#797348: ebook-speaker: Segfault if no epub in the directory

[Paul Gevers]

Control: tags -1 moreinfo unreproducible

On Sun, 30 Aug 2015 14:07:08 +0200 Samuel Thibault
 wrote:
> MENGUAL Jean-Philippe, le Sun 30 Aug 2015 03:31:20 +0200, a écrit :
> > Le 30/08/2015 03:06, Samuel Thibault a écrit :
> > >MENGUAL Jean-Philippe, le Sun 30 Aug 2015 02:37:46 +0200, a écrit :
> > >>Le 30/08/2015 02:23, Samuel Thibault a écrit :
> > >>>Jean-Philippe MENGUAL, le Sat 29 Aug 2015 21:43:29 +0200, a écrit :
> > >>>I can't reproduce this.  What do you *have* in the directory?
> > >>Various things: .txt, .doc, .pdf, .mp3, etc. There are subdirs too.
> > >Then you can try to make a copy of this directory (without the subdirs),
> > >check wheter it still fails there, and then try to remove files type by
> > >type, and then file by file, to know which one brings the crash.
> > Can you test putting in the dir a .doc file and with an accent in its name?
> 
> I tried, with no problem.
> 
> > It seems, although it's somewhat random, the crash happens with .doc files,
> > or if some filenames have accents (such as élément).
> 
> Perhaps you can send me that problematic file privately.

Did this ever happen? Without a way to reproduce, it is hard to fix.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#847647: RM: torque -- RoQA; security issues, cannot be updated to newer upstream versions

[Salvatore Bonaccorso]

Package: ftp.debian.org
Severity: normal

Hi

src:torque should be removed from unstable. Cf.
https://bugs.debian.org/767411

Torque can as well not be updated to newer upstream versions due to
license changes upstream for the new versions.

Regards,
Salvatore

Bug#847646: RM: pbs-drmaa -- RoQA; depends on torque which is outdates, recurring security issues, maintained bin NMUs

[Salvatore Bonaccorso]

Package: ftp.debian.org
Severity: normal

Hi

This is bascially so that src:torque can be removed from th archive
(will fill separate bugreport for it), cf.

https://bugs.debian.org/767411

For license reasons it is as well ont possible to update torque to a
newer upstream version.

Regards,
Salvatore

Bug#847542: libmozjs-24-0 24.2.0-4 breaks gnome-shell, preventing gdm3 from starting

[Andrea Zagli]

same here; downgraded to testing version and everything works again

Bug#847645: ITP: gap-factint -- advanced methods for factoring integers for GAP

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: gap-factint
  Version : 1.5.3
  Upstream Author : Stefan Kohl 
* URL : http://www.gap-system.org/Packages/factint.html
* License : GPL-2+
  Programming Lang: GAP
  Description : advanced methods for factoring integers for GAP

GAP is a system for computational discrete algebra with particular
emphasis on computational group theory, but which has already proved
useful also in other areas.

This package brings to GAP routines for factoring integers, in particular:
 - Pollard's p-1
 - Williams' p+1
 - Elliptic Curves Method (ECM)
 - Continued Fraction Algorithm (CFRAC)
 - Multiple Polynomial Quadratic Sieve (MPQS)

It also provides access to Richard P. Brent's tables of factors of integers
of the form b^k +/- 1.

Bug#846228: Random FTBFS failures of joblib and what about team maintenance

[Andreas Tille]

On Sat, Dec 10, 2016 at 12:09:55AM +0100, Bernd Zeimetz wrote:
> > I think python-joblib has several rdepends and thus it would IMHO be
> > better maintained in DPMT than in a private Github repository.  What
> > do you think?
> 
> On the other side, DPMT is nothing to drop packages one does not want to
> maintain anymore into
> DPMT makes various things easier, like mass migrations, but there are no
> random maintainers popping up to handle your package!

I can confirm that I would pop up in cases where I would feel able to
fix a bug in my rdepends if it is in a team maintained repository I have
easy access.  Using third party repositories has several other
disadvantages - for instance Debian maintainers dashboard can't verify
Vcs status.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#847321: Could you please check the autobuilder for opensurgsim

[Aurelien Jarno]

Hi,

On 2016-12-09 09:29, Andreas Tille wrote:
> Hi Mips porters,
> 
> I noticed that opensurgsim has not yet build on mips[1].  Since the
> build process for this package needs some more powerful machine and I
> learned in the past that there are different machines for mips available
> I wonder whether you can somehow dedicate one of the more powerful
> ones for this package and whether this might solve the issue.

The package has already been tried on the fastest build daemon with an
FPU, so it won't solve the issue. Anyway I have given-back the package
and it then built successfully. It was probably a transient issue.

Aurelien

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

Bug#847644: RFP: ELAN -- A professional tool for the creation of complex annotations on video and audio resources

[128]

Package: wnpp
Severity: wishlist

https://tla.mpi.nl/tools/tla-tools/elan/

With ELAN a user can add an unlimited number of annotations to audio and/or
video streams. An annotation can be a sentence, word or gloss, a comment,
translation or a description of any feature observed in the media. Annotations
can be created on multiple layers, called tiers. Tiers can be hierarchically
interconnected. An annotation can either be time-aligned to the media or it can
refer to other existing annotations. The textual content of annotations is
always in Unicode and the transcription is stored in an XML format.

ELAN provides several different views on the annotations, each view is connected
and synchronized to the media playhead. Up to 4 video files can be associated
with an annotation document. Each video can be integrated in the main document
window or displayed in its own resizable window. 

ELAN delegates media playback to an existing media framework, like Windows Media
Player, QuickTime or JMF (Java Media Framework). As a result a wide variety of
audio and video formats is supported and high performance media playback can be
achieved.

ELAN is written in the Java programming language and the sources are available
under a GPL 3 license. It runs on Windows, Mac OS X and Linux.

Bug#847643: node-uglify: help output does not usefully describe the command

[Ben Finney]

Package: node-uglify
Version: 2.7.4-1
Severity: normal

The ‘uglifyjs --help’ output is not helpful for learning to use the command:

$ uglifyjs --help
[object Object]

Conventionally that should produce a usage message that tells the
reader what the command does, and all the ways to invoke the program,
with descriptions of all possible arbuments and options.

$ uglifyjs --help
Usage: uglifyjs --foo --bar COLOR --baz INFILE OUTFILE
Obfuscate the infile to the outfile with a snargle snorgle.

INFILE
The input file to obfuscate.

OUTFILE
The obfuscated output.

Options:
--foo
Obfuscate upside down.
--bar COLOR
Turn the output to COLOR.
(default: green)
--baz
Hum gently while working.


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

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

Versions of packages node-uglify depends on:
ii  node-async  0.8.0-1
ii  node-yargs  6.4.0-2
ii  nodejs  4.6.1~dfsg-1

Versions of packages node-uglify recommends:
ii  node-source-map  0.5.6+dfsg-1

Versions of packages node-uglify suggests:
pn  node-uglify-to-browserify  

-- no debconf information

-- 
 \   “It's easy to play any musical instrument: all you have to do |
  `\   is touch the right key at the right time and the instrument |
_o__)will play itself.” —Johann Sebastian Bach |
Ben Finney 


signature.asc
Description: PGP signature

Bug#820892: bug

[Martin Monperrus]

It seems I also hit this blocking bug:

Failed to spawn script '/usr/share/vpnc-scripts/vpnc-script' for
connect: Interrupted system call
Send BYE packet: Aborted by caller
USer canceled (SIGINT); exiting;

Bug#839639: bug

[Martin Monperrus]

I confirm this critical bug.

upstream: https://rt.cpan.org/Public/Bug/Display.html?id=112442

Bug#828336: Building with OpenSSL 1.0.2 is sufficient for stretch

[Adrian Bunk]

On Sat, Dec 10, 2016 at 08:31:14AM +0200, Adrian Bunk wrote:
>...
> Sufficient for stretch (which might be the last Debian release with 
> sslscan)
>...

Please ignore the "which might be the last Debian release with sslscan",
this is a paste error.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#847642: node-uglify: manual page ‘uglifyjs(1)’ lacks important information for all document sections

[Ben Finney]

Package: node-uglify
Version: 2.7.4-1
Severity: normal

The command ‘uglifyjs’ has a manual page ‘uglifyjs(1)’ that does not
helpfully describe the command:

NAME
   uglify-js - manual page for uglify-js 2.7.5

DESCRIPTION
   [object Object]

The manual page should have the sections described ‘man-pages(7)’ §
“Sections within a manual page”, with the content as described in that
document.

-- 
 \   “Following fashion and the status quo is easy. Thinking about |
  `\your users' lives and creating something practical is much |
_o__)harder.” —Ryan Singer, 2008-07-09 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#828360: Fix for the jabberd2 FTBFS bugs

[Adrian Bunk]

Control: tags -1 patch

Not a perfect solution but sufficient for stretch is the patch below to 
use OpenSSL 1.0.2

The "| libssl-dev (<< 1.1.0~)" is added for backports.

--- debian/control.old  2016-12-10 06:48:51.0 +
+++ debian/control  2016-12-10 06:49:02.0 +
@@ -4,8 +4,8 @@
 Maintainer: Debian XMPP Maintainers 
 Uploaders: Willem van den Akker , Simon Josefsson 

 Build-Depends: debhelper (>= 9), dh-systemd (>= 1.5), dh-autoreconf,
- libssl-dev, libgsasl7-dev (>= 1.4.0), libdb-dev, libpam0g-dev,
- libmysqlclient-dev, libpq-dev, libldap2-dev, libsqlite3-dev,
+ libssl1.0-dev | libssl-dev (<< 1.1.0~), libgsasl7-dev (>= 1.4.0), libdb-dev, 
libpam0g-dev,
+ default-libmysqlclient-dev, libpq-dev, libldap2-dev, libsqlite3-dev,
  libidn11-dev, libexpat1-dev, libudns-dev, libhttp-parser-dev, check
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-xmpp/jabberd2.git


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#828336: Building with OpenSSL 1.0.2 is sufficient for stretch

[Adrian Bunk]

Control: tags -1 patch

Sufficient for stretch (which might be the last Debian release with 
sslscan)
is the patch below to use OpenSSL 1.0.2

The "| libssl-dev (<< 1.1.0~)" is added for backports.

--- debian/control.old  2016-12-10 06:29:33.0 +
+++ debian/control  2016-12-10 06:29:40.0 +
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: TANIGUCHI Takaki 
 Build-Depends: debhelper (>= 7.0.50~), autotools-dev,
-   libssl-dev,
+   libssl1.0-dev | libssl-dev (<< 1.1.0~),
dh-autoreconf,
info
 Standards-Version: 3.9.5


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#847641: obnam: FTBFS on all archs due to test failure

[Vincent Cheng]

Source: obnam
Version: 1.20.2-1
Justification: fails to build from source (but built successfully in the past)
Severity: serious

I checked the BTS but it doesn't look like this has been reported
before; sorry if this is a duplicate report.

obnam currently FTBFS on all archs in sid (for about a month now);
relevant part of build log is as follows:


ERROR: In scenario "encrypted backup and restore with a separate keyring"
step "WHEN user U backs up directory L to repository R" failed,
with exit code 1:
Standard output from shell command:

Standard error from shell command:
+ run_obnam U backup -r
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/R
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/L
+ local name=U
+ shift
+ local 
conf=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ add_to_config U weak-random yes
+ local client=U
+ local 
filename=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ local key=weak-random
+ local value=yes
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ printf %s = %s\n weak-random yes
+ add_to_config U lock-timeout 0
+ local client=U
+ local 
filename=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ local key=lock-timeout
+ local value=0
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ printf %s = %s\n lock-timeout 0
+ [ -n 6 ]
+ add_to_config U repository-format 6
+ local client=U
+ local 
filename=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ local key=repository-format
+ local value=6
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ printf %s = %s\n repository-format 6
+ [ -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.env
]
+ /«PKGBUILDDIR»/obnam --no-default-config --config
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
--quiet --log-level debug --log
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/obnam.log
--trace obnamlib --trace larch backup -r
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/R
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/L
ERROR: R0C79EX: gpg failed with exit code 2:
Command: gpg -q --batch --no-textmode -c --passphrase-fd 4
gpg: can't open '/usr/share/gnupg/dirmngr-conf.skel': No such file
or directory
gpg: new configuration file
'/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/HOME/.gnupg/gpg.conf'
created
gpg: can't connect to the agent: IPC connect call failed
gpg: problem with the agent: No agent running

Bug#847640: clamav-freshclam: apt-get remove clamav-freshclam leaves clamav-freshclam.service)

[Heinrich Schuchardt]

This is the list of all files clamav-freshclam leaves behind after being
uninstalled.

/etc/rc1.d/K01clamav-freshclam
/etc/rc3.d/K01clamav-freshclam
/etc/rc2.d/K01clamav-freshclam
/etc/network/if-up.d/clamav-freshclam-ifupdown
/etc/network/if-down.d/clamav-freshclam-ifupdown
/etc/rc0.d/K01clamav-freshclam
/etc/rc5.d/K01clamav-freshclam
/etc/clamav/freshclam.conf
/etc/logcheck/ignore.d.server/clamav-freshclam
/etc/logrotate.d/clamav-freshclam
/etc/rc4.d/K01clamav-freshclam
/etc/rc6.d/K01clamav-freshclam
/etc/ppp/ip-up.d/clamav-freshclam-ifupdown
/etc/ppp/ip-down.d/clamav-freshclam-ifupdown
/etc/systemd/system/clamav-freshclam.service
/etc/systemd/system/multi-user.target.wants/clamav-freshclam.service
/etc/init.d/clamav-freshclam
/etc/apparmor.d/local/usr.bin.freshclam
/etc/apparmor.d/usr.bin.freshclam

Best regards

Heinrich Schuchardt

Bug#847640: clamav-freshclam: apt-get remove clamav-freshclam leaves clamav-freshclam.service

[Heinrich Schuchardt]

Package: clamav-freshclam
Version: 0.99.2+dfsg-4
Severity: normal

Dear Maintainer,

I have uninstalled clamav-freshclam.

dmesg now shows the following error on boot:

systemd[1]: clamav-freshclam.service: Cannot add dependency job, ignoring: Unit 
clamav-freshclam.service is masked.

Uninstalling freshclam should remove the service definition.

Best regards

Heinrich Schuchardt

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

Kernel: Linux 4.9.0-rc8-next-20161208-r003-arm64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#794438: Partition manager does not launch

[Herminio Hernandez Jr]

Package: partitionmanager
Version: 1.0.3-2.1
Followup-For: Bug #794438

Dear Maintainer,

I am also see that partionmanager is failing to launch.

   * What led up to the situation?

I upgraded from stretch to sid and then installed partitionmanager.

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

When I tried to launch partionmanger I did not even see it appear in either
krunner or app launcher. I then ran it in konsole as root and recieved the
following

root@KDE-Gazelle:/home/rican-linux# partitionmanager
partitionmanager(3762)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
KCrash: Application 'partitionmanager-bin' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=/root/.kde/socket-KDE-Gazelle/kdeinit4__0
Warning: connect() failed: : No such file or directory
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi directly
drkonqi(3765)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
Unable to start Dr. Konqi
Not forwarding the crash to Apport.

I then ran the command export $(dbus-launch). It ran the application but I
could not reformat my usb drive. I saw the following in konsole

root@KDE-Gazelle:/home/rican-linux# export $(dbus-launch)
root@KDE-Gazelle:/home/rican-linux# partitionmanager
partitionmanager(3801)/kdeui (kdelibs): Attempt to use QAction
"toggleDockDevices" with KXMLGUIFactory!
partitionmanager(3801)/kdeui (kdelibs): Attempt to use QAction
"toggleDockOperations" with KXMLGUIFactory!
partitionmanager(3801)/kdeui (kdelibs): Attempt to use QAction
"toggleDockInformation" with KXMLGUIFactory!
partitionmanager(3801)/kdeui (kdelibs): Attempt to use QAction "toggleDockLog"
with KXMLGUIFactory!
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
kbuildsycoca4 running...
"KConfigIni: In file /tmp/kde-root/kconf_updateHV3950.tmp, line 1: " Invalid
entry (missing '=')
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
partitionmanager(3801)/kdecore (KConfigSkeleton)
KCoreConfigSkeleton::writeConfig:
partitionmanager(3801)/kdecore (KConfigSkeleton)
KCoreConfigSkeleton::writeConfig:

   * What was the outcome of this action?

partionmanager failed to function properly

   * What outcome did you expect instead?

partionmanager to run properly




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

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

Versions of packages partitionmanager depends on:
ii  kde-runtime   4:16.08.3-1
ii  libblkid1 2.29-1
ii  libc6 2.24-8
ii  libgcc1   1:6.2.1-5
ii  libkdecore5   4:4.14.26-1
ii  libkdeui5 4:4.14.26-1
ii  libkio5   4:4.14.26-1
ii  libparted-fs-resize0  3.2-17
ii  libparted23.2-17
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libstdc++66.2.1-5
ii  libuuid1  2.29-1

partitionmanager recommends no packages.

Versions of packages partitionmanager suggests:
ii  dosfstools 4.0-2
pn  hfsplus
pn  hfsutils   
pn  jfsutils   
pn  ntfsprogs  
pn  reiser4progs   
pn  reiserfsprogs  
pn  xfsprogs   

-- no debconf information

Bug#755857: fail2ban: Exim Unrouteable address rule no longer fires.

[Alex King]

All the lines in /etc/fail2ban/filter.d/exim.conf start with "^%(pid)s "

Those characters are trying to match a PID at the start of log lines, I guess.

Actually in /etc/fail2ban/filter.d/exim-common.conf I see:

pid = ( \[\d+\])?

But the problem is that the lines in /var/log/exim4/mainlog contain no PIDs at 
the start of the line.


from http://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html:

"Exim does not include its process id in log lines by default, but you can 
request that it does so by specifying the pid log selector (see section 52.15). 
When this is set, the process id is output, in square brackets, immediately 
after the time and date. "


So that is an optional feature of exim, but it is not enabled by default.

So certainly the regexes in /etc/fail2ban/filter.d/exim.conf are broken and need 
to be fixed.


Thanks,
Alex

On Thu, 24 Jul 2014 09:09:32 +1000 Aaron Howell  wrote:

Package: fail2ban
Version: 0.9.0+git48-gabcab00-1
Severity: normal



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

Kernel: Linux 3.15.0-6-generic (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages fail2ban depends on:
ii  init-system-helpers  1.19
ii  lsb-base 4.1+Debian11ubuntu8
ii  python   2.7.8-1

Versions of packages fail2ban recommends:
ii  iptables  1.4.21-2ubuntu1
ii  python-pyinotify  0.9.4-1build1
ii  whois 5.1.4

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20131005cvs-1
pn  python-gamin 
pn  python-systemd   
ii  rsyslog [system-log-daemon]  7.4.4-1ubuntu5

-- no debconf information

I have enabled the exim filter within fail2ban, and added a 
logfile=/var/log/exim4/mainlog entry.
I can see that the log file is opened by fail2ban, and it correctly detects 
when the log file is rotated, however, no lines are matched, meaning nothing 
gets banned.
Here are some log entries which should match:

2014-07-24 07:05:51 H=host28-145-static.87-94-b.business.telecomitalia.it (ElintecGPRS) 
[94.87.145.28] F= rejected RCPT : 
Unrouteable address
2014-07-24 07:05:52 H=host28-145-static.87-94-b.business.telecomitalia.it (ElintecGPRS) 
[94.87.145.28] F= rejected RCPT : 
Unrouteable address
2014-07-24 07:19:06 H=(Takaste.unknown.creeperhost.net) [82.145.53.119] 
F= rejected RCPT 
: Unrouteable address
2014-07-24 07:22:17 H=dl123149.arvixevps.com [23.91.115.19] F= 
rejected RCPT : Unrouteable address
2014-07-24 07:24:55 H=dl123149.arvixevps.com [23.91.115.19] 
F= rejected RCPT <3gforffree@kitten.net.au>: 
Unrouteable address
2014-07-24 07:40:11 H=(Moodle) [31.222.138.20] F= rejected RCPT 
: Unrouteable address
2014-07-24 07:41:41 H=dl123149.arvixevps.com [23.91.115.19] 
F= rejected RCPT 
: Unrouteable address
2014-07-24 07:48:31 H=dl123149.arvixevps.com [23.91.115.19] F= 
rejected RCPT : Unrouteable address
2014-07-24 08:00:12 H=(Moodle) [31.222.138.20] F= rejected 
RCPT : Unrouteable address
2014-07-24 08:06:47 H=dl123149.arvixevps.com [23.91.115.19] F= 
rejected RCPT : Unrouteable address
2014-07-24 08:18:32 H=aventure.arvixevps.com [108.175.147.241] 
F= rejected RCPT : Unrouteable address
2014-07-24 08:23:28 H=(Moodle) [31.222.138.20] F= rejected RCPT 
: Unrouteable address
2014-07-24 08:37:29 H=dl123149.arvixevps.com [23.91.115.19] 
F= rejected RCPT 
<19991007103020.a16...@meow.kitten.net.au>: Unrouteable address
2014-07-24 08:47:07 H=dl123149.arvixevps.com [23.91.115.19] F= 
rejected RCPT : Unrouteable address

In particular the avixevps ones should have generated a ban.
I have not made any changes to the regex for the exim filter, only changed the 
logfile so that it matches where Debian actually stores the exim logs.
Sshd log processing and banning is working correctly, so fail2ban is actually 
running correctly.
Using exim packages 4.83rc3-1.

Bug#847639: unblock node-grunt-contrib-concat 1.0.1-2

[Pirate Praveen]

package: release.debian.org

Fixes RC bug #846007



signature.asc
Description: OpenPGP digital signature

Bug#845106: x11vnc: configure does not find libssl, builds without OpenSSL support

[Vagrant Cascadian]

On 2016-12-01, Fathi Boudra wrote:
> On Thu, Dec 1, 2016 at 11:50 AM, Danny Edel  wrote:
>> On Sun, 20 Nov 2016 13:37:46 +0100 Hilko Bengen  wrote:
>>> after searching for "AC_CHECK_LIB(ssl, SSL_library_init" using
>>> codesearch.debian.net and rebuilding with OpenSSL 1.1, I found that the
>>> OpenSSL is no longer detected and thus no longer used when building the
>>> package.
>>
>> Hello,
>>
>> is anyone already working on this?  If not, I would try resolving this
>> myself, since I use x11vnc a lot and would very much like to see it in
>> stretch.  The autoremoval because of this bug is currently scheduled for
>> January 3.
>
> yes but I'm waiting for my key replacement to do the upload.
> I haven't heard from RT yet. I may ask a sponsored upload if RT
> doesn't react faster.

I don't see any Vcs for the package; Do you have a working patch?

I maintain epoptes, which depends on x11vnc, and would really like to
make sure it makes it into stretch. I'd be available to sponsor an
upload if needed.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#847638: O: global -- Source code search and browse tools

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of global has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/global


Package: global
Binary: global
Version: 5.7.1-4
Maintainer: Debian QA Group 
Build-Depends: debhelper (>= 6.0.7), texinfo
Architecture: any
Standards-Version: 3.9.8.0
Format: 1.0
Files:
 3d5a99026be1387becac341e3d1d0371 1737 global_5.7.1-4.dsc
 7537de776fb41ef3208838657dda0475 742677 global_5.7.1.orig.tar.gz
 1f5e9e1a4c40ed4e60baf164449d5826 18429 global_5.7.1-4.diff.gz
Vcs-Browser: http://git.debian.org/?p=users/ron/global.git
Vcs-Git: git://git.debian.org/users/ron/global.git
Checksums-Sha256:
 9ae9f830744d4d2b0f3bff0c91d8ffd8608dd943a6cd8fb7e2cdf64520388df4 1737 
global_5.7.1-4.dsc
 15c72f3579254d0860cb4833fb8f1e9bf80868f2720348c599628d63d7356c58 742677 
global_5.7.1.orig.tar.gz
 1ffda822efead67beeb8af327f776fa12924aba19e0da59bb8735d11f93b991b 18429 
global_5.7.1-4.diff.gz
Package-List: 
 global deb devel optional arch=any
Directory: pool/main/g/global
Priority: source
Section: devel

Package: global
Version: 5.7.1-4
Installed-Size: 1183
Maintainer: Debian QA Group 
Architecture: amd64
Depends: dpkg (>= 1.15.4) | install-info, emacsen-common (>= 2.0.8), libc6 (>= 
2.14)
Suggests: lynx | www-browser, doxygen (>= 1.4.3), apache | httpd, id-utils
Description-en: Source code search and browse tools
 GNU GLOBAL is a source code tag system that works the same way across
 diverse environments. Currently, it supports the following:
 .
   o command line, and the 'globash' query subshell.
   o vim plugin, and support for other vi clones.
   o less
   o emacs
   o web browser
 .
 Supported languages are C, C++, yacc and Java.
 You can locate a specified function in the source files and move
 there easily. It is especially useful for hacking large projects
 containing many subdirectories, many '#ifdef' and many main()
 functions, like X or kernel source.
 .
 This package include the htmake(1) extension which allows GLOBAL's
 hypertext search function to be implemented from a single central
 cgi script.
 .
 Doxygen now supports using global as its source browser, with the
 USE_HTAGS option.
Description-md5: 5692ae4f6ecc435bd0544646bcd63301
Tag: devel::lang:c, devel::lang:c++, devel::lang:java,
 interface::commandline, role::program, scope::utility, suite::gnu,
 use::searching, works-with::software:source
Section: devel
Priority: optional
Filename: pool/main/g/global/global_5.7.1-4_amd64.deb
Size: 292844
MD5sum: 7e506d9321a519202a9c0be89d253f5d
SHA256: 56fa252a5fa894a28c847baa737d037839192cd5ce591903fefd57c721485292

Bug#846356: [Pkg-libvirt-maintainers] Bug#846356: virt-manager: unsupported configuration: unknown input device type 'virtio1.0-input'

[Laurent Bigonville]

Le 09/12/16 à 17:33, Guido Günther a écrit :

Hi Laurent,

Hi,


On Wed, Nov 30, 2016 at 04:42:11PM +0100, Laurent Bigonville wrote:

[...]

According to that bug, it's already fixed upstream:

commit 1d2cd306773064258f5d02c980b09a683ae77798
Author: Cole Robinson 
Date:   Fri Jul 29 13:17:36 2016 -0400

 osdict: Fix incorrect usage of virtio input

Did you check if the patch fixes the problem for you?
Didn't had the time to check that yet, I just choose an other "version" 
when I had to install that VM

Bug#847417: depends on gstreamer-plugins-bad, which is an ongoing source of security holes

[Laurent Bigonville]

Le 09/12/16 à 23:08, Michael Biebl a écrit :

Hi Joey

Hi,


Am 08.12.2016 um 03:01 schrieb Joey Hess:

Package: gnome-video-effects
Version: 0.4.1-3
Severity: normal

gstreamer-plugins-bad has been in the news at least twice recently for
security holes.

http://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html
https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html

It seems likely that it will continue to be a source of such security
holes.

This doesn't immediately address your concern, but I just uploaded
tracker including this change:

"tracker-extract: Sandbox extractor threads. Filesystem and network
  access are limited to being read and local only."



I wanted to remove gstreamer-plugins-bad from my system, but this would
remove gnome-video-effects, which would remove cheese. I don't know why
cheese needs a ton of insecurely implemented codecs for playing Nintendo
games etc in order to take snapshots and record videos. Probably it doesn't?

gnome-video-effects is just one of many others depending on
gstreamer-plugins-bad, and I guess we have to check each and every one
of them.

Laurent, this dependency was originally added by you. Do you remember
the details and why this needs to be a hard dependency? The only real
dependency of gnome-video-effects is cheese, would some of the cheese
features not work if gstreamer-plugins-bad was not installed?


I think cheese was not starting at all if there were no effects 
installed. I quickly tested again now and cheese seems to be OK if the 
gnome-video-effects package is not installed. So we could lower the 
dependency to a recommends.


BUT that will not solve the problem at all as cheese itself needs the 
camerabin plugin from gstreamer1.0-plugins-bad (libcheese8 depends on 
it). libcheese8 is used by cheese but also gnome-control-center, 
gnome-contacts, gnome-initial-setup (and also indirectly by empathy). I 
personally don't want to disable cheese support in all these components.


gstreamer1.0-plugins-bad is actually containing other plugins that looks 
useful to me (or might be useful in the future like the waylandsink) and 
not only "codecs for playing Nintendo games".


In ubuntu they are splitting more the package (same for the 
gnome-video-effects package actually) and are also moving at build time 
some of the plugins to gstreamer1.0-plugins-good. Following what ubuntu 
is doing might be an idea but it will require more work from the 
gstreamer maintainer I guess (I'm adding them in the loop) and we might 
be a bit late in the development cycle to do that now.


my 2¢

Bug#847636: unblock node-cpr

[Pirate Praveen]

package: release-debian.org

Fixes serious bug #846010 and #847614



signature.asc
Description: OpenPGP digital signature

Bug#847637: RFS: gap-sonata/2.8+ds-1 [ITP]

[Jerome Benoit]

Package: sponsorship-requests
Severity: wishlist

Dear Sponsor,

I am looking for sponsorship for the Debian GAP package gap-sonata [1,2]
which brings to Debian the GAP package SONATA; SONATA stands for 
Systems Of
Nearrings And Their Applications. This GAP package is preloaded by the 
GAP
interface of Sage[Math].

Thanks in advance,
Jerome

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847547
[2] https://anonscm.debian.org/cgit/debian-science/packages/gap-sonata.git


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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (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: sysvinit (via /sbin/init)

Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

On Fri, Dec 9, 2016 at 1:46 PM, Paul Gevers  wrote:
> I am trying to understand you shell script

You may find it easier to just run it and inspect the resulting
`.deb`s, then refer to the script only when you want to see where a
specific path/package is handled.

> Just to make sure I am not completely
> misunderstanding, you are trying to use binutils- package
> on the arch of that triplet, right? But e.g. binutils-aarch64-linux-gnu
> doesn't exist on amd64.

Er, yes it does:
https://packages.debian.org/search?keywords=binutils-aarch64-linux-gnu

The *only* packages that are "missing" (actually just outdated and
with wrong headers) are the two x86 arches that are still from
src:cross-binutils rather than src:binutils, for which I filed bug
#846628.

>> Note that the
>> new /etc/fpc/debian.cfg must be installed from the *unversioned*
>> package - which will require a "backwards" dependency
>> (fp-compiler-config-3.0.0 depends on fp-compiler-config-common).
>
> Can you explain where this requirement comes from? If really required,
> then we'll have to figure out an other solution, because circular
> dependencies are a problem.

Background: managing /etc/fpc.cfg via update-alternatives is
fundamentally wrong, because it is the file read by *all* installed
versions of fpc. In order for each FPC to use its *own* fpc.cfg, they
all need to be conditionally included from a *single* fpc.cfg. Since
jessie shipped with packages that manage /etc/fpc.cfg via
update-alternatives, the symlink must still be managed by it for the
stretch upgrade (for the stretch -> buster upgrade this will no longer
be the case).

Fix: Regardless of version, make /etc/fpc.cfg a symlink to
/etc/fpc/debian.cfg file, which then includes the files specific to
the arch and version.

So the hard dependencies will be:

fp-compiler:$a -> fp-compiler-$v:$a
fp-compiler-$v:$a -> fp-compiler-config-$v:all,
fp-compiler-driver-$v(:$a, but Multi-Arch:foreign)
fp-compiler-config-$v:all -> fp-compiler-config-common:all

(Additionally, fp-compiler-driver-$v should have a backwards
Recommends: fp-compiler-$v:$a and a Description to match, so that
people finding it via `apt-file` (including `command-not-found`) will
get the right thing.)

There is no circular dependency - only the -common package has a
versioned -> nonversioned dependency. And the contents will be:

fp-compiler:$a : empty
fp-compiler-$v:$a : executable /usr/lib/fpc/$v/ppc$a
fp-compiler-driver-$v:$a : executable /usr/lib/fpc/$v/fpc, symlink
/usr/bin/fpc-$v and sometimes (via update-alternatives) /usr/bin/fpc
fp-compiler-config-$v:all : /etc/fpc/$v/{mkcfg,local}.cfg
fp-compiler-config-common:all : /etc/fpc/{debian,local}.cfg, *all*
/etc/fpc/$a/{target,local}.cfg and (via update-alternatives)
/etc/fpc.cfg

It would be possible to put the /etc/fpc/$a/{target,local}.cfg files
in yet *another* package, but IMO there's no value in it. (They are
unversioned so that can't go in fp-compiler:$a which might not be
installed if just fp-compiler-$v:$a is).

While it would *currently* be possible to make fp-compiler-config-$v
architecture-specific (since multi-arch allows overwriting files as
long as they are identical), that would prove to be a mistake once
"real" cross-compiler packages are added. By avoiding relying on this,
it becomes easier to transition from *:$a to *-$a packages in future.

All `Architecture: all` packages should be `Multi-Arch: foreign`.
All `Architecture: $a` packages should be `Multi-Arch: same` *except*
`fp-compiler-driver{,-$v}`, `fp-utils{,-$v}`, and `fp-ide{,-$v}` which
should be `Multi-Arch: foreign` since they only make sense on the
host. (The future fp-compiler{,-$v}-$a packages will also be
`Multi-Arch: foreign`).

-Ben

Bug#847635: AST-2016-009: SIP header whitespace with proxy

[Dara Adib]

Package: asterisk
Version: 1:11.13.1~dfsg-2+deb8u1
Severity: important
Tags: security patch

https://security-tracker.debian.org/tracker/TEMP-000-5567B0
http://downloads.asterisk.org/pub/security/AST-2016-009.html

I believe this is the patch:
https://gerrit.asterisk.org/4587

Thanks!

Bug#847634: There is a LIBDIR variable you can use

[Diederik de Haas]

Just found https://github.com/phhusson/quassel-irssi/commit/
cfbd67f8576e2f5e30ec769866e68326a3466adf from 2016-04-12 
which explicitly allows setting the LIBDIR variable for downstream 
maintainers, so that looks like a way to solve this bug :)

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

Bug#847634: irssi-plugin-quassel: libquassel_core.so not in expected location

[Diederik de Haas]

Package: irssi-plugin-quassel
Version: 0~git20160612-1
Severity: grave
Justification: renders package unusable

I followed the instructions from the README.md on github, but when I got
to the '/load quassel' part I got the following error:
Irssi: Error loading module quassel/core:
/usr/lib/x86_64-linux-gnu/irssi/modules/libquassel_core.so: cannot open
shared object file: No such file or directory

And that is because libquassel_core.so is stored at
/usr/lib/irssi/modules/libquassel_core.so

For completeness sake I also tried '/connect ' and got:
Irssi: Unknown chat protocol: Quassel

Therefor I set the severity to grave as I can't connect to my quassel
core and would be surprised if others could.

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

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

Versions of packages irssi-plugin-quassel depends on:
ii  irssi 0.8.20-2
ii  libc6 2.24-8
ii  libquasselc0  0~git20150406-1
ii  zlib1g1:1.2.8.dfsg-4

irssi-plugin-quassel recommends no packages.

Versions of packages irssi-plugin-quassel suggests:
pn  quassel-core  

-- no debconf information

Bug#847554: clang: Clang should produce position independent code by default

[Sylvestre Ledru]

Hello,

Le 09/12/2016 à 00:45, Gregor Jasny a écrit :

Package: clang
Version: 1:3.8-34
Severity: normal

Dear Maintainer,

gcc nowadys seems to be built with --enable-default-pie config option.
That flag results in generation of position independent code and
executables by default:

$ gcc -dM -E - < /dev/null|egrep -i '(pie|pic)'
#define __pie__ 2
#define __PIE__ 2
#define __pic__ 2
#define __PIC__ 2

$ g++ -o main main.cpp && readelf -h ./main | grep Type
   Type: DYN (Shared object file)

>From a useability and security perspective it would be nice if clang
could follow the GCC behaviour.

Yes but probably not for the next release of Debian...

S

Bug#847633: autogen: output files have truncated mtimes, may appear older than their inputs

[Mike Miller]

Package: autogen
Version: 1:5.18.12-3
Severity: normal
Tags: upstream

Dear Maintainer,

AutoGen appears to truncate the mtimes of its output files, so the
generated .c and .h files appear to be older than they actually are.

This can be a serious problem in timestamp-based build systems, in
particular if the input file to AutoGen is itself generated by the build
system.

I'll give a trivial example that demonstrates the effect I have run
into:

$ cat args.def
autogen definitions options;
prog-name = test;
prog-title= "Test Program";

flag = {
  name = debug;
  value = d;
};
$ rm -f args.c args.h
$ touch args.def && sleep 0.2 && autogen args.def
$ stat -c "%y %n" args.* | sort -n
2016-12-09 19:21:52.0 -0800 args.c
2016-12-09 19:21:52.0 -0800 args.h
2016-12-09 19:21:52.530084232 -0800 args.def

As you can see, the AutoGen input file args.def has an actual timestamp,
while args.[ch] have timestamps that are truncated and artificially
older than that of args.def. The --source-time option doesn't matter
here, unless of course the "sleep 0.2" is turned into "sleep 2". The
sleep here is just to emulate other build steps or wait states, and to
emphasize that the args.def file is in fact up to date when it is read
by AutoGen.

If this sequence of commands were part of a make-based build system, and
args.def were in turn generated from args.def.in, make would be left
with files that it thinks are out of date.

I don't know why AutoGen is intentionally truncating the mtime of its
outputs. The only reference to manipulating mtime that I've seen is the
--source-time option, which does (close to) what it describes, but also
truncates the mtime so that it is again always older than the mtime of
the source file.

So it basically seems like AutoGen always munges the output file time
stamps, and knows nothing about subsecond resolution.

I do believe this can lead to, and has led to actual build system bugs,
especially as we embrace more parallelism, see for example #816148 and
#844882.

Thanks!

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

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

Versions of packages autogen depends on:
ii  guile-2.0-libs  2.0.13+1-2
ii  libc6   2.24-7
ii  libopts25   1:5.18.12-3
ii  libopts25-dev   1:5.18.12-3
ii  libxml2 2.9.4+dfsg1-2.1
pn  perl:any

Versions of packages autogen recommends:
pn  autogen-doc  

autogen suggests no packages.

-- no debconf information

Bug#843464: jmol: diff for NMU version 12.2.32+dfsg2-1.1

[tony mancill]

On Sun, 4 Dec 2016 11:32:43 -0800 tony mancill  wrote:
> Control: tags 843464 + patch
> Control: tags 843464 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for jmol (versioned as 12.2.32+dfsg2-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer or cancel it.
>
> The upload contains a patch to address the FTBFS introduced by the
> upload of libnaga-java 3.0 to Debian.  I have tested locally that
> jmol starts correctly, but am not a jmol user and so cannot speak
> to all of the functionality.  (However, the patch is a simple
> interface change, so I am reasonably confident that it does not
> introduce regressions.)
>
> Regards,
> tony

This upload was rejected due to a lintian error that existed in the
source package before I added the patch.  Since NMUs are supposed to
be very targeted, the rejection puts us in an odd place.  Will the
upload to experimental [1] find its way into unstable before the
freeze, or should I try again with 12.2.32?

Thanks,
tony

[1] https://tracker.debian.org/news/821446

Bug#847632: ITP: Scripts to automate and optimize the configuration of a Linux in an AD domain

[Eduardo Moraes]

Package: cid
Severity: wishlist

* Package name: cid, cid-gtk, cid-plugins
  Version :
  Upstream Author : Eduardo Moraes 
* URL : https://c-i-d.sourceforge.net
* License : GPL-3
  Programming Lang: Bash
  Description : Set of bash scripts to automate and optimize the
configuration of a Linux station in an AD domain

 - The CID (Closed In Directory) project is a set of bash scripts
 to automate and optimize the configuration of a Linux station
 in an Active Directory domain through the samba(7) suite.
 - I am the developer of the program and would like to take it to
 the Debian repositories, any help is appreciated.

cheers,
--
Eduardo Moraes



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-586
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#847631: RM: openjade1.3 -- ROM: obsolete, replaced by openjade

[Neil Roeth]

Package: ftp.debian.org
Severity: normal

Please remove the openjade1.3 source package from which the openjade1.3
binary package is built.  Its replacement is the newer openjade package.
It has already been automatically removed from testing.

-- 
Neil Roeth

Bug#775744: libapp-stacktrace-perl: FTBFS: Failed 1/4 test programs. 1/6 subtests failed.

[Axel Beckert]

Control: tag -1 - pending

Hi again,

Axel Beckert wrote:
> Axel Beckert wrote:
> > Niko Tyni wrote:
> > > The attached patch makes the test suite pass again for me on amd64.
> > 
> > Thanks. The patch works fine for me, too, at least on amd64 and armhf.
> > But it now FTBFS on arm64 (where it built before):

Actually it FTBFS on amd64, too, but only inside pbuilder. That smells
like a missing build-dependency to me. Will dig into that direction
for the moment…

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

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Wookey]

On 2016-12-10 06:54 +1030, Ron wrote:

> So I've now orphaned this package, and he has my blessing and sympathy
> for being responsible for whatever happens with it from here.  I haven't
> filed a WNPP bug for that as we don't need to offer it to someone random.

OK. Cheers. Warm potato accepted :-)
 
> Wookey: if you want the complete git history, right back to the very first
> package in 1999, you can grab it from the Vcs-Git URL in the sid package.
> I'm not going to go Full Bruce and rage delete it, but eventually I should
> decruft alioth and remove it from there, so if you want it you should
> probably clone it somewhere that works for you.

OK. I don't use git unless I have to, so I'll let Punit worry about that.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#775744: libapp-stacktrace-perl: FTBFS: Failed 1/4 test programs. 1/6 subtests failed.

[Axel Beckert]

Hi,

Axel Beckert wrote:
> Niko Tyni wrote:
> > The attached patch makes the test suite pass again for me on amd64.
> 
> Thanks. The patch works fine for me, too, at least on amd64 and armhf.
> But it now FTBFS on arm64 (where it built before):
> 
> […]
> t/release-pod-syntax.t  skipped: these tests are for release candidate 
> testing
> # [Thread debugging using libthread_db enabled]
> # Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
> # 0x007f993c2448 in select () from /lib/aarch64-linux-gnu/libc.so.6
> # /tmp/iDQWSbZWdw.gdb:1761: Error in sourced command file:
> # Cannot access memory at address 0x8d7da768
> 
> #   Failed test at t/unthreaded.t line 55.
> #   '[Thread debugging using libthread_db enabled]
> # Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
> # 0x007f993c2448 in select () from /lib/aarch64-linux-gnu/libc.so.6
> # /tmp/iDQWSbZWdw.gdb:1761: Error in sourced command file:
> # Cannot access memory at address 0x8d7da768

Meh, I pasted the wrong output. That was without the patch. With the
patch it still FTBFS on arm64, though:

# [Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
# 0x007fadfd2448 in select () from /lib/aarch64-linux-gnu/libc.so.6
# /tmp/S0cICGJg6x.gdb:1761: Error in sourced command file:
# Cannot access memory at address 0x59702768

#   Failed test at t/unthreaded.t line 55.
#   '[Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
# 0x007fadfd2448 in select () from /lib/aarch64-linux-gnu/libc.so.6
# /tmp/S0cICGJg6x.gdb:1761: Error in sourced command file:
# Cannot access memory at address 0x59702768
[…]
$ quilt applied
debian/patches/0001-Pointers-should-be-long-not-int.patch


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

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sat, Dec 10, 2016 at 02:25:08AM +0100, Mattia Rizzolo wrote:
> On Fri, Dec 09, 2016 at 08:11:54PM -0500, Bill Blough wrote:
> > > >Or does anyone have other suggestions?
> 
> I have one: please try to CC people (and/or MLs) sooner.  I now noticed
> that you asked for help more than one month ago, but I wasn't aware of
> that at all.  And now the freeze is hovering upon us.

Yes, fair enough.  That's my mistake.

> 
> > In the mean time, would it be possible to get a
> > stack trace showing the exception thrown by any one of the test
> > programs?
> 
> I got a build in the s390x porterbox, and reproduced the failure; at
> least, near enough, mine says
> diff test-results.log ./scripts/sanityTest_ExpectedResult.log
> Binary files test-results.log and ./scripts/sanityTest_ExpectedResult.log 
> differ
> Makefile:950: recipe for target 'check' failed
> Instead of actually showing the diff.
> 
> I'm happy to provide stacktraces and/or core dumps if you can tell me
> how to get them without me needed to figure things out.

After the build completes, from the build root, run

  libtool --mode=execute gdb --args samples/SAXCount samples/data/personal.xml

At the GDB prompt, type

  catch throw

then

  run

It will stop, saying exception thrown. To generate the stack trace, type

  bt full

There will likely be several screens of data.  If you could please
copy/paste them all. Once you're back at the gdb prompt, that's the end of
that trace.

Because there may be multiple exceptions thrown (including as part of
normal operation), I'd appreciate a stack trace of all of them.
Unfortunately, I don't know how many there will be.  On my (working) system
there's only one before successful completion.  Hopefully there won't be
much more than two on the failing system, but depending on the failure
there could be several.

>From the gdb prompt, typing

 continue

will continue execution until the next exception, at which point you can
repeat from the "bt full" step above.

Once you get a message saying the process exited, it's done, and you can
exit by typing

  quit


This will hopefully help me to isolate this issue.

Thanks for your help.

Bill

Bug#775744: libapp-stacktrace-perl: FTBFS: Failed 1/4 test programs. 1/6 subtests failed.

[Axel Beckert]

Control: tag -1 + pending

Hi Niko,

Niko Tyni wrote:
> The attached patch makes the test suite pass again for me on amd64.

Thanks. The patch works fine for me, too, at least on amd64 and armhf.
But it now FTBFS on arm64 (where it built before):

[…]
t/release-pod-syntax.t  skipped: these tests are for release candidate 
testing
# [Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
# 0x007f993c2448 in select () from /lib/aarch64-linux-gnu/libc.so.6
# /tmp/iDQWSbZWdw.gdb:1761: Error in sourced command file:
# Cannot access memory at address 0x8d7da768

#   Failed test at t/unthreaded.t line 55.
#   '[Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
# 0x007f993c2448 in select () from /lib/aarch64-linux-gnu/libc.so.6
# /tmp/iDQWSbZWdw.gdb:1761: Error in sourced command file:
# Cannot access memory at address 0x8d7da768
# '
# doesn't match '(?^mx:
# (?:
# ^t/unthreaded\.t:\d+\n
# ){10}
# )'
# Looks like you failed 1 test of 5.
t/unthreaded.t  
1..5
not ok 1
ok 2 - Reaped pstack
ok 3 - exit(0)
ok 4 - No signals
ok 5 - No core dump
# Alive top 1481337347: 1 middle: 1
# Alive top 1481337348: 1 middle: 0
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/5 subtests 

Test Summary Report
---
t/unthreaded.t  (Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=4, Tests=6,  2 wallclock secs ( 0.09 usr  0.02 sys +  1.35 cusr  0.12 
csys =  1.58 CPU)
Result: FAIL
Failed 1/4 test programs. 1/6 subtests failed.
Makefile:1009: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 1
make[1]: Leaving directory '/home/abe/libapp-stacktrace-perl'
dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
[…]

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

Bug#847630: RM: openmw [armel] -- RoQA; B-D libopenscenegraph-3.4-dev unavailable on armel

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

openscenegraph-3.4 is no longer built on armel


Andreas

Bug#847629: git-build-recipe: FTBFS in sid: tests fail, lintian is missing

[Andreas Beckmann]

Package: git-build-recipe
Version: 0.3.4
Severity: serious
Justification: fails to build from source

Hi,

git-build-recipe didn't build on the autobuilder:

https://buildd.debian.org/status/fetch.php?pkg=git-build-recipe&arch=all&ver=0.3.4&stamp=1480435477

[...]
   debian/rules override_dh_auto_test
make[1]: Entering directory '/«PKGBUILDDIR»'
LC_ALL=C.UTF-8 dh_auto_test
I: pybuild base:184: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build; python3.5 
-m nose 
.FF..FF.F.FFF...
==
FAIL: gitbuildrecipe.tests.test_blackbox.BlackboxBuilderTests.test_cmd_dailydeb
--
testtools.testresult.real._StringException: stderr: {{{
debuild: fatal error at line 1100:
dpkg-buildpackage -rfakeroot -us -uc --hook-check=cd ..;  -i -I -S 
--check-command=lintian failed
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/gitbuildrecipe/main.py", 
line 185, in 
sys.exit(main())
  File "/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/gitbuildrecipe/main.py", 
line 175, in main
working_directory, tgz_check=not args.allow_fallback_to_native)
  File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/gitbuildrecipe/deb_util.py", line 
175, in build_source_package
subprocess.check_call(command, cwd=basedir)
  File "/usr/lib/python3.5/subprocess.py", line 271, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/debuild', '--tgz-check', 
'-i', '-I', '-S', '-uc', '-us']' returned non-zero exit status 29
}}}

stdout: {{{
dpkg-buildpackage -rfakeroot -us -uc --hook-check=cd ..;  -i -I -S 
--check-command=lintian
dpkg-buildpackage: error: check-commmand 'lintian' not found
}}}

Traceback (most recent call last):
  File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/gitbuildrecipe/tests/test_blackbox.py",
 line 140, in test_cmd_dailydeb
out, err = self.run_recipe("--manifest manifest test.recipe working")
  File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build/gitbuildrecipe/tests/test_blackbox.py",
 line 122, in run_recipe
self.assertEqual(retcode, process.returncode)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 350, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 435, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 0 != 1


[...]

Bug#847628: ITP: libpod-pom-view-restructured-perl -- View for Pod::POM that outputs reStructuredText

[Alex Muntada]

Package: wnpp
Severity: wishlist
Owner: Alex Muntada 

* Package name: libpod-pom-view-restructured-perl
  Version : 0.02
  Upstream Author : Don Owens 
* URL : https://metacpan.org/pod/Pod::POM::View::Restructured
* License : Artistic
  Programming Lang: Perl
  Description : View for Pod::POM that outputs reStructuredText

This module outputs reStructuredText that is expected to be used with
Sphinx. Verbatim sections (indented paragraphs) in the POD will be output
with syntax hilighting for Perl code by default.

This module will be used to build the Debian Perl Group manual on
.

The package will be maintained under the umbrella of the Debian Perl Group.



signature.asc
Description: Digital signature

Bug#846898: Fixed in 3.22.2-2

[Michael Biebl]

Am 10.12.2016 um 01:23 schrieb David Weinehall:
> On Fri, 9 Dec 2016 09:24:15 +0200 David Weinehall
> mailto:david.weineh...@gmail.com>> wrote:
>> On Tue, 6 Dec 2016 18:01:02 +0100 Raphael Hertzog  >
>> wrote:
>> > Version: 3.22.2-2
>> >
>> > I just uploaded a new version of mutter with the fix for that
>> > bug. I was not aware of this bug so I forgot mention it in the
>> > changelog.
>>
>> I'm seeing this issue (segfault in gnome-session) even with 3.22.2-2.
> 
> Seems that the observed segfault is a different one; downgrading
> libmozjs-24-0 to 24.2.0-3.1
> fixes the issue for me.

At least the timing of the bug report makes it look suspiciously like a
duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847542



-- 
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#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Mattia Rizzolo]

On Fri, Dec 09, 2016 at 08:11:54PM -0500, Bill Blough wrote:
> > >Or does anyone have other suggestions?

I have one: please try to CC people (and/or MLs) sooner.  I now noticed
that you asked for help more than one month ago, but I wasn't aware of
that at all.  And now the freeze is hovering upon us.

> In the mean time, would it be possible to get a
> stack trace showing the exception thrown by any one of the test
> programs?

I got a build in the s390x porterbox, and reproduced the failure; at
least, near enough, mine says
diff test-results.log ./scripts/sanityTest_ExpectedResult.log
Binary files test-results.log and ./scripts/sanityTest_ExpectedResult.log 
differ
Makefile:950: recipe for target 'check' failed
Instead of actually showing the diff.

I'm happy to provide stacktraces and/or core dumps if you can tell me
how to get them without me needed to figure things out.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Fri, Dec 09, 2016 at 11:07:54PM +, Gianfranco Costamagna wrote:
> >Can anyone comment on the use of -Bsymbolic_functions in Ubuntu?  If I
> >understand it correctly, it shouldn't have any effect on this, but I
> >have no way to test it other than another upload.
> 
> 
> I still prefer the default -Ofoo different as root cause
> 

According to the build logs, both are being compiled with -O2.  The only
difference I see in the build flags is the symbolic-functions link flag
I referenced earlier.  But as I said, I don't see how that would affect
it.


> >Assuming that's not it, would someone be willing to sponsor access to the 
> >s390x
> >porter box so I can get this sorted out?
> 
> 
> not so easy :/ are you a dm?

Unfortunately, not yet.  I hope to change that soon.


> 
> >Or does anyone have other suggestions?
> 
> 
> https://ufile.io/f0872
> 
> I did a build, and uploaded the whole build directory on that file, including
> 
> a complete build log (in the root directory), let me know if it sounds good 
> to you to debug
> building after export C{,PP,XX}FLAGS=-O3 didn't help either

Thanks, I really appreciate that. I'll look through it and see if I can
find any new leads.  In the mean time, would it be possible to get a
stack trace showing the exception thrown by any one of the test
programs?

Thanks,
Bill

Bug#440057: memory leaks in apt-transport-https - unanswered since 9 years

[Holger Levsen]

Hi David,

On Fri, Dec 09, 2016 at 02:14:56PM +0100, David Kalnischkies wrote:
> Honestly, I had some problem replying to this mail as in my head it
> sounds like an attack which my gut tells me I should pay back in the
> same coin… so that's like the 4th try in overpowering my gut, which
> might or might not have worked in the end.

I'm sorry to have disturbed you that much, it was definitly not ment as
an attack at all. Thanks for writing your reply the way you wrote it.

And many more thanks for taking care of apt so well, I can barely
imagine how it is to deal with the flood of incoming bugs…

> Control: tags -1 moreinfo

I'm not sure which info you want…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844882: ocserv: FTBFS: ./ocserv-args.h:1:1: error: unterminated comment

[Mike Miller]

On Sat, Nov 19, 2016 at 07:47:50 +0100, Lucas Nussbaum wrote:
> > In file included from sup-config/file.c:29:0:
> > ./ocserv-args.h:1:1: error: unterminated comment
> >  /*   -*- buffer-read-only: t -*- vi: set ro:
> >  ^

I can semi-reliably reproduce this and similar errors with sbuild -j32.

It seems to be a parallel build race condition in the build between
autogen and other source files that include the autogen-generated header
file.

The following procedure also reproduces (maybe 3 out of 4 times) from
upstream git (ocserv_0_11_4 tag):

  autoreconf -fi
  ./configure
  rm src/version.inc
  make -j32 all

Same on upstream git master, so the latest upstream 0.11.6 will hit the
same error.

The key ingredient is deleting src/version.inc *after* running
configure, which I think is causing autogen to run later than it should,
in turn causing a race with the compiler.

I'll take a look at the generated sources and see what we can change to
ensure everything is built in the right order. I'll also report upstream
and see if we can get a more robust build to prevent these kinds of
races in a future version.

-- 
mike

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Sat, 10 Dec 2016 06:54:17 +1030 Ron  wrote:
> You then had the gall to angrily insist that while you thought he might
> be a better maintainer than me, it was still my responsibility to do the
> work to fix all the obvious things that others had missed in their fork
> (which he hadn't contributed anything to either).  I'm afraid that's not
> how encouraging volunteers to contribute their time for you works ...
> sorry if this is news to you.

It was perfectly reasonable to ask that if you have any pretense at all
of actually doing the work expected of your maintainer position, you'd
contribute to creating packaging for the new upstream version, instead
of only attacking the people working on it.


> things.  But because the increasingly ill-named technical committee has once
> again refused to stick its collective necks out to actually offer technical
> advice when explicitly asked to.  We chopped some heads off the hydra, but

> Explaining things in careful detail has had every appearance of being a
> complete waste of my time whichever way this might have ended up.  The only

The fundamental problem with most of your technical arguments was that
they were arguments about upstream development, not about packaging.
Even if they were 100% true, they still would not justify how you have
handled the Debian package. If you disagree with upstream that way, you
should try to convince them, and if that fails and you care enough,
create a new upstream fork.

Instead, you turned the Debian packaging into a practical fork. That's
not the right place for hosting a new fork. You also obviously did a
bad job of maintaining your fork (given the complete lack of
development). Your attitude seems to have been that you insist on
keeping the original GLOBAL out of Debian, do no development at all
yourself, and if anyone has problems with your fork you insist that
they do the work of developing it. That's not reasonable at all.

Bug#847627: libpt: please add dependency “Suggests: libpt-doc”

[Ben Finney]

Source: ptlib
Version: 2.10.11~dfsg-2.1
Severity: minor

Dear Maintainer,

Working with the ‘ptlib’ packages requires understanding how it works
and what it does.

Please set a “Suggests: libpt-doc” dependency to the binary package
‘libpt*’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “Give a man a fish, and you'll feed him for a day; give him a |
  `\religion, and he'll starve to death while praying for a fish.” |
_o__)   —Anonymous |
Ben Finney 


signature.asc
Description: PGP signature

Bug#847626: dpdk: please add dependency “Suggests: dpdk-doc”

[Ben Finney]

Source: dpdk
Version: 16.07-3
Severity: minor

Dear Maintainer,

Working with the ‘dpdk’ packages requires understanding how it works
and what it does.

Please set a “Suggests: dpdk-doc” dependency to the binary package
‘dpdk’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \ “We live in capitalism. Its power seems inescapable. So did the |
  `\   divine right of kings.” —Ursula K. LeGuin, National Book Awards |
_o__)acceptance speech, 2014-11-19 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#847625: libpt: please add dependency “Suggests: libpt-doc”

[Ben Finney]

Source: libpt
Version: 2.10.11~dfsg-2.1
Severity: minor

Dear Maintainer,

Working with the ‘libpt’ packages requires understanding how it works
and what it does.

Please set a “Suggests: libpt-doc” dependency to the binary package
‘libpt’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “Give a man a fish, and you'll feed him for a day; give him a |
  `\religion, and he'll starve to death while praying for a fish.” |
_o__)   —Anonymous |
Ben Finney 


signature.asc
Description: PGP signature

Bug#847624: ufo-filters: please add dependency “Suggests: ufo-filters-doc”

[Ben Finney]

Package: ufo-filters
Version: 0.12.0+dfsg1-1
Severity: minor

Dear Maintainer,

Working with the ‘ufo-filters’ packages requires understanding how it
works and what it does.

Please set a “Suggests: ufo-filters-doc” dependency to the binary
package ‘ufo-filters’, or other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \  “I used to be a proofreader for a skywriting company.” —Steven |
  `\Wright |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#847623: ufo-core: please add dependency “Suggests: ufo-core-doc”

[Ben Finney]

Package: ufo-core
Version: 0.12.0+dfsg1-1
Severity: minor

Dear Maintainer,

Working with the ‘ufo-core’ packages requires understanding how it
works and what it does.

Please set a “Suggests: ufo-core-doc” dependency to the binary package
‘ufo-core’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “If we listen only to those who are like us, we will squander |
  `\   the great opportunity before us: To live together peacefully in |
_o__)a world of unresolved differences.” —David Weinberger |
Ben Finney 


signature.asc
Description: PGP signature

Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

[Jens Reyer]

On 09.12.2016 17:24, Vincent Lefevre wrote:
> On 2016-12-09 16:44:52 +0100, Jens Reyer wrote:
> This is bad. I think that the main problem is that Wine creates files
> that will take precedence without the user's consents. But even if
> the user wants Wine's desktop files, they should still have less
> precedence than the ones from the native system. The spec should
> provide a way to do this.

Unfortunately I haven't found a way to assign a *lower* priority so far.

So I think I have to further investigate what winemenubuilder exactly
does, and if we can prevent creation of these .desktop files without
breaking anything else.


>> When did you first observe this behavior? Just now or for a longer time?
> 
> I do not use xdg-open very much, so I don't know.
> 
> Well... I think I had already removed the .wine directory in the past
> for some reason. This could explain why the files were created at
> some point. Not sure.

Good, so I assume nothing related changed recently. Instead we are
working on an issue that exists since years (I observed it once or
twice, but could never reproduce till now).

These common mime types might also be affected:
application/pdf
application/rtf
application/xml
image/gif
image/jpeg
image/png
text/html
text/plain


>> Can you please also try with a fresh user with an empty /home?
> 
> I'll try later, perhaps on Monday if I cannot to this remotely.
> But see my remark above.

Thanks in advance. Since this is a new topic for me, I'd hope to see my
assumptions confirmed. I expect it to break for you after "wineboot &&
winecfg" (or whatever is necessary to trigger the creation of the
.desktop files). All above mentioned types should be affected, unless
you have them in your mimeapps.list.

Greets
jre

Bug#846898: Fixed in 3.22.2-2

[David Weinehall]

On Fri, 9 Dec 2016 09:24:15 +0200 David Weinehall 
wrote:
> On Tue, 6 Dec 2016 18:01:02 +0100 Raphael Hertzog 
> wrote:
> > Version: 3.22.2-2
> >
> > I just uploaded a new version of mutter with the fix for that
> > bug. I was not aware of this bug so I forgot mention it in the
> > changelog.
>
> I'm seeing this issue (segfault in gnome-session) even with 3.22.2-2.

Seems that the observed segfault is a different one; downgrading
libmozjs-24-0 to 24.2.0-3.1
fixes the issue for me.

Bug#847595: diffoscope: test_icc.py test failures

[HW42]

Ximin Luo:
> Hello liblcms2-2 maintainer, just reassigning the bug described below.
> You can reproduce it with $ cd-iccdump  
> 
> e.g. from the diffoscope source tree:
> 
> $ cd-iccdump tests/data/test1.icc  | grep 'en_US\|ne_SU'
>   ne_SU:  sRGB [24 bytes]
> [.. etc ..]
> 
> Seems endian-related.
> 
> Reiner Herrmann:
>> On Fri, Dec 09, 2016 at 06:36:53PM +0100, Chris Lamb wrote:
>>> E -ne_SU:   sRGB [24 bytes]
>>> E ? -  -
>>> E +en_US:   sRGB [24 bytes]
>>> E ?+  +
>>
>> Just found out that it is caused by liblcms2-2 (2.8-2).
>> After downgrading it to the version in stretch (2.7-1), everything is
>> printed normally.

I think I found the cause. cmsMLUtranslationsCodes() now uses the new
strFrom16() function. The problem is that strFrom16() does not work
under little-endian systems.

  static
  cmsUInt16Number strTo16(const char str[3])
  {
  cmsUInt16Number n = ((cmsUInt16Number) str[0] << 8) | str[1];
  
  return n;  // Always big endian in this case
  }

  static
  void strFrom16(char str[3], cmsUInt16Number n)
  {
  // Assiming this would be aligned
  union {
  
 cmsUInt16Number n;
 char str[2];
 
  } c;
  
  c.n = n;  // Always big endian in this case
  
  str[0] = c.str[0]; str[1] = c.str[1]; str[2] = 0;
  
  }

On a little-endian system strFrom16() wrongly swaps the byte order (even
though the comment says something different). You can easily test this
with the attached minimal test case (see test.c).

I think the easiest solution is the use a machine byte order independent
calculation like in strTo16(). See attached patch.
diff -u a/src/cmsnamed.c b/src/cmsnamed.c
--- a/src/cmsnamed.c
+++ b/src/cmsnamed.c
@@ -192,18 +192,10 @@
 static
 void strFrom16(char str[3], cmsUInt16Number n)
 {
-// Assiming this would be aligned
-union {
-
-   cmsUInt16Number n;
-   char str[2];
-   
-} c;
-
-c.n = n;  // Always big endian in this case
-
-str[0] = c.str[0]; str[1] = c.str[1]; str[2] = 0;
-
+// n is always big endian, see strTo16.
+str[0] = (n >> 8) & 0xff;
+str[1] = n & 0xff;
+str[2] = 0;
 }
 
 // Add an ASCII entry. Do not add any \0 termination (ICC1v43_2010-12.pdf page 61)
#include 
#include 

int main() {
char s[] = "ab";
union {
uint16_t n;
char s[2];
} u;
u.n = s[0] << 8 | s[1];
printf("%c%c\n", u.s[0], u.s[1]);
}


signature.asc
Description: OpenPGP digital signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Philip Hands]

Ole Streicher  writes:

> On 09.12.2016 08:37, Philip Hands wrote:
>>> On Wed, 07 Dec 2016, Philip Hands wrote:
 It could be much improved by making it more obvious that the heading is
 a heading.  Even if we're unable to stop headings having a checkbox, we
 could change the text and the hierarchy slightly to be something like
 this:

[ ]  === Debian Desktop Environments:
[x]  ... Gnome
>>> [...]
 Would that cheer people up without needing a major rewrite of tasksel?
>
> This improves the situation, and could probably done quite simple at the
> same place where the ellipsis (...) is introduced:
>
> https://sources.debian.net/src/tasksel/3.38/tasksel.pl/#L360-L366
>
> One just needs to find out here that it is actually a heading.
>
>> I think that should be a select, rather than a multi-select:
>> 
>>  -->  standard desktop (will install $DESKTOP)  <--
>>   standard server  (includes ssh)
>>   other use cases
>> 
>> (or however the UI presents it)
>> 
>> The reason for the extra bits in brackets is that I've always thought
>> the tasksel menu was hiding just a little too much of what was meant by
>> the options.
>
> I would vote for that, however we would need
>
> 1. someone willing *and* competent (the latter excludes myself) to
> implement this in tasksel,

Just to test things out, if one adds:

  url=hands.com/d-i/bug/846002/preseed.cfg

to the kernel command line (so, hitting TAB as the installer's boot menu)
it will tweaks d-i to have such a menu.

I suspect that the way it works could be improved (it could probably be
plumbed into tasksel itself) but it seems to do the trick, and should
let people have a play and give feedback without needing to create new
.iso images.

I've tried it interactively, but not yet with preseeding, which will
need either this to be changed to chain into your preseed, or vice versa
(if you can work out how, feel free to give that a try and see if you
can find what it breaks :-) ).

The files that do the trick are here:  http://hands.com/d-i/bug/846002/

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#847622: nmu: kodi-pvr-hdhomerun_2.4.2+git20160820-1

[Andreas Beckmann]

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

nmu kodi-pvr-hdhomerun_2.4.2+git20160820-1 . ANY . unstable . -m "Rebuild 
against libhdhomerun3."

libhdhomerun recently had a soname bump. Luckily there is only one
dependency :-)


Andreas

Bug#847621: mpi4py: FTBFS on !linux: tests fail in MPI_INIT

[Andreas Beckmann]

Package: mpi4py
Version: 2.0.0-2
Severity: important

Hi,

mpi4py FTBFS on hurd and kfreebsd, blocking building of
several packages dependent packages.

https://buildd.debian.org/status/fetch.php?pkg=mpi4py&arch=hurd-i386&ver=2.0.0-2%2Bb1&stamp=1473623691
https://buildd.debian.org/status/fetch.php?pkg=mpi4py&arch=kfreebsd-i386&ver=2.0.0-2&stamp=1473761554
https://buildd.debian.org/status/fetch.php?pkg=mpi4py&arch=kfreebsd-amd64&ver=2.0.0-2&stamp=1473761937

[...]
   debian/rules override_dh_auto_test
make[1]: Entering directory '/«PKGBUILDDIR»'
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
set -e; for v in 2.7 3.5; do \
 echo "I: testing using python$v"; \
 PYTHONPATH=`/bin/ls -d /«PKGBUILDDIR»/build/lib.*-$v` \
  /usr/bin/python$v /usr/bin/nosetests -v --exclude='testPackUnpackExternal' -A 
"not network" ; \
done
I: testing using python2.7
[fano:75254] PMIX ERROR: UNREACHABLE in file src/client/pmix_client.c at line 
983
[fano:75255] PMIX ERROR: NOT-SUPPORTED in file 
src/server/pmix_server_listener.c at line 540
[fano:75254] PMIX ERROR: UNREACHABLE in file src/client/pmix_client.c at line 
199
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  init pmix failed
  --> Returned value Unreachable (-12) instead of ORTE_SUCCESS
--
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  orte_ess_init failed
  --> Returned value Unreachable (-12) instead of ORTE_SUCCESS
--
--
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):

  ompi_mpi_init: ompi_rte_init failed
  --> Returned "Unreachable" (-12) instead of "Success" (0)
--
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)
[fano:75254] Local abort before MPI_INIT completed completed successfully, but 
am not able to aggregate error messages, and not able to guarantee that all 
other processes were killed!
debian/rules:89: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:22: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2


Andreas

Bug#847620: Drop obsolete update-rc.d parameters which cause warnings during upgrade

[Michael Biebl]

Source: cryptsetup
Version: 2:1.7.3-3
Severity: normal
Tags: patch

Specifying start/stop priorities has been deprecated a long time (at
least since wheezy after the switch to dependency based boot).

Upgrading cryptsetup atm produces this warning message

update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults

Please consider applying the attach patch with your next upload.

Regards,
Michael


-- Package-specific info:

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

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

-- debconf information excluded
>From 70f5cd6e4aed3185d799bd24301f6f8f4aa1ccce Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Sat, 10 Dec 2016 00:23:00 +0100
Subject: [PATCH] Drop obsolete update-rc.d parameters

This fixes:
update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 4dba608..2b0c2e5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -176,9 +176,9 @@ binary-arch: build install
 	dh_installchangelogs -a
 	dh_installdocs -a
 	dh_installexamples -a debian/scripts/gen-ssl-key
-	dh_installinit -a --no-start --name=cryptdisks-early --update-rcd-params="start 26 S . start 59 0 6 ."
+	dh_installinit -a --no-start --name=cryptdisks-early
 	dh_installinit -a --no-start --name=cryptdisks-udev
-	dh_installinit -a --no-start --name=cryptdisks --update-rcd-params="start 28 S . start 48 0 6 ."
+	dh_installinit -a --no-start --name=cryptdisks
 	dh_installman -a debian/doc/crypttab.5 debian/doc/cryptdisks_start.8 debian/doc/cryptdisks_stop.8
 	dh_installman -p cryptsetup-bin debian/luksformat.8
 	# Copy relevant parts to cryptsetup-udeb package
-- 
2.11.0

Bug#847539: Update for new programming language sections

[Josh Triplett]

On Fri, Dec 09, 2016 at 05:31:56PM -0500, James McCoy wrote:
> On Thu, Dec 08, 2016 at 08:41:06PM -0800, Josh Triplett wrote:
> > The attached patch provides an update with new archive sections for 
> > programming
> > language packages.  See https://bugs.debian.org/753480 and
> > https://bugs.debian.org/845576 for more on the new sections.  ftpmaster has
> > approved adding the two new sections, conditional on support for them in the
> > various packages with lists of archive section names.
> 
> Thanks.  I'll include it in the next upload.

Thank you!

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Gianfranco Costamagna]

Hi Bill,


>I'd really like to get this resolved before the freeze.
>
>Can anyone comment on the use of -Bsymbolic_functions in Ubuntu?  If I
>understand it correctly, it shouldn't have any effect on this, but I
>have no way to test it other than another upload.


I still prefer the default -Ofoo different as root cause

>Assuming that's not it, would someone be willing to sponsor access to the s390x
>porter box so I can get this sorted out?


not so easy :/ are you a dm?

>Or does anyone have other suggestions?


https://ufile.io/f0872

I did a build, and uploaded the whole build directory on that file, including

a complete build log (in the root directory), let me know if it sounds good to 
you to debug
building after export C{,PP,XX}FLAGS=-O3 didn't help either

G.

Bug#846228: Random FTBFS failures of joblib and what about team maintenance

[Bernd Zeimetz]

On 12/07/2016 12:09 PM, Andreas Tille wrote:
> Hi Yaroslav,
> 
> I just want to make some noise amongst Python experts about bug #846228.
> I admit I have no idea - but since there was no response for 10 days now
> several packages git a testing removal notice.
> 
> I think python-joblib has several rdepends and thus it would IMHO be
> better maintained in DPMT than in a private Github repository.  What
> do you think?

On the other side, DPMT is nothing to drop packages one does not want to
maintain anymore into
DPMT makes various things easier, like mass migrations, but there are no
random maintainers popping up to handle your package!


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#847619: ITP: libnet-whois-ip-perl -- Lookup whois entries of IP addresses with Perl

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libnet-whois-ip-perl
  Version : 1.19
  Upstream Author : Ben Schmitz 
* URL : https://metacpan.org/release/Net-Whois-IP
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Lookup whois entries of IP addresses with Perl

Net::Whois::IP is a module to do whois lookup of IP addresses. It
should recursively query the various whois providers until it gets
the more detailed information including either TechPhone or
OrgTechPhone by default; however, this is overrideable.

There are already several perl-based whois interfaces in Perl, but this
one is a dependency of Net::Abuse::Utils aka libnet-abuse-utils-perl
which I'm primarily interested in.

The license itself is unfortunately still not documented inside the
upstream tar ball, but in the upstream bug tracking system, see
https://rt.cpan.org/Public/Bug/Display.html?id=19058#txn-192324

The package will be maintained under the umbrella of the Debian Perl
Group.

Bug#847618: ITP: libnet-abuse-utils-perl -- Routines useful for processing network abuse

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libnet-abuse-utils-perl
  Version : 0.25
  Upstream Author : Mike Greb , Wes Young 

* URL : https://metacpan.org/release/Net-Abuse-Utils
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Routines useful for processing network abuse

Net::Abuse::Utils provides several functions useful for determining
information about an IP address including contact/reporting addresses,
ASN/network info, reverse dns, and DNSBL listing status. Functions which take
an IP accept either IPv6 or IPv4 IPs unless indicated otherwise.

The package will be maintained under the umbrella of the Debian Perl Group.

Bug#847487: RM: libqpid-proton2-dev-examples [mips mipsel armel] -- ROM; Doesn't build on these arch

[Andreas Beckmann]

On Thu, 08 Dec 2016 17:50:23 +0100 Thomas Goirand  wrote:
> This is a follow-up on bugs.debian.org/846824
> The package isn't migrating to testing because these binary are still
> there. Please get them removed to uncruft.

That architecture specification looks a bit spurious - it's an arch:all
package. There is also an old -doc package.

Wouldn't this subject be more appropriate:

RM: libqpid-proton2-dev-doc libqpid-proton2-dev-examples [all] -- RoM; NBS; 
superseded by libqpid-proton8-*


anbe@coccia:~$ dak rm -Rn -b libqpid-proton2-dev-examples 
libqpid-proton2-dev-doc
Will remove the following packages from unstable:

libqpid-proton2-dev-doc | 0.10-2 | all
libqpid-proton2-dev-examples | 0.10-2 | all

Maintainer: Debian Middleware Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Andreas

Bug#847617: RFS: ekg/1:1.9~pre+r2855-4 [QA, RC]

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: important

  Dear mentors,

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

 * Package name: ekg
   Version : 1:1.9~pre+r2855-4
   Upstream Author : Wojtek Kaniewski 
 * URL : http://ekg.chmurka.net
 * License : GPL-2+
   Section : net

  It builds those binary packages:

ekg   - console Gadu-Gadu client for UNIX systems - ncurses UI
 ekg-gtk- Gadu-Gadu client for UNIX systems - GTK+ UI

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


  https://mentors.debian.net/package/ekg


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

dget -x 
https://mentors.debian.net/debian/pool/main/e/ekg/ekg_1.9~pre+r2855-4.dsc


  Changes since the last upload:
  * QA upload.
  * Use OpenSSL 1.0 to fix FTBFS with version 1.1. (Closes: #828291)
  * debian/control:
- Bump Standards-Version to 3.9.8.
- Bump dh version to 10.
- Fix short description.
- Use secured links for VCS.
  * Drop menu files.
  * Enable hardening.

  Regards,
   Mateusz Łukasik

Bug#847195: Kdevelop: please package newer version

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 6 de diciembre de 2016 15:16:13 ART Roman Lebedev wrote:
> Package: kdevelop
> Version: 4:5.0.1-2
> Severity: normal
> 
> Dear maintainer, kdevelop 5.0.3 is avaliable.
> It would be nice to upgrade

There is currently no direct maintainer looking at it, we are keeping it under 
the team's umbrella as muuch as we can.

In my case my time is limited and I won't be able to do it in time for Strech, 
so if anyone is willing to help here help would be apreciated.


-- 
Sea estricto cuando envíe y tolerante cuando reciba. En otras palabras, solo
envíe paquetes que cumplan rigurosamente con lo estándares, pero espere
paquetes que tal vez no cumplan del todo y trate de lidiar con ellos.
  Andrew S. Tanenbaum, de su libro "Computer Networks"

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


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

Bug#704289: vpnc: When vpnc-disconnect lost the default route

[Mike Miller]

Control: tags -1 + moreinfo

On Sun, Mar 31, 2013 at 16:50:13 +0800, leiqin wrote:
> Package: vpnc
> Version: 0.5.3r512-2
> Severity: normal
> 
> Dear Maintainer,
> 
> When disconnect the vpnc with vpnc-disconnect ,
> I lost the default gateway .

This bug has been recently reassigned to the vpnc-scripts package, which
has seen several changes since the affected version of vpnc.

Can you please retest with the current vpnc-scripts package (version
0.1~git20160829-1) and report back if this issue is resolved or still
exists?

If it does still exist, is it precisely because your gateway provides a
vpn with a netmask of 0.0.0.0?

-- 
mike

Bug#846410: kdevelop crahses when starting (5.0.1)

[Lisandro Damián Nicanor Pérez Meyer]

tag 846410 unreproducible moreinfo
severity 846410 important
thanks

Hi! I've tried to reproduce this bug in an up-to-date sid environment without 
luck.

Please try again with an up to date system. If it still crashed please try 
with a clean environment (a new user). In case you can not reproduce it with a 
new user please keep your user's config so we can track the issue if 
necessary.

Thanks, Lisandro.

-- 
Los errores ortográficos y de redacción fueron insertados con la única
intención de testear sus conocimientos de la lengua castellana.

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


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

Bug#845597: shorewall: Shorewall doesn't start at the system boot

[Nathan Stratton Treadway]

On Fri, Dec 09, 2016 at 14:41:27 -0500, Nathan Stratton Treadway wrote:
> I have only worked with this under Ubuntu (not Debian per se), but I
> believe the issue you are seeing is that the Shorewall documentation has
> not been updated to reflect the use of systemd instead of the old-style
> /etc/init.d/shorewall script.
[...]> 
> To turn on automatic startup of shorewall under systemd, you need to
> "enable" the service:
>   # systemctl enable shorewall

Actually, I found in the Debian changelog:
  
http://metadata.ftp-master.debian.org/changelogs/main/s/shorewall/shorewall_5.0.14.1-1_changelog
that (assuming you are in fact using v5.0.14.1-1 as specified in the bug
report) the package should now already be enabling itself upon
installation:

shorewall (5.0.7-1) unstable; urgency=low

  * New Upstream Version
  * Enable systemd service on package installation and disable on removal


(Ubuntu Xenial has v5.0.4-1, so it doesn't get enabled automatically on
installation there.)

So, I'm not sure if "systemctl enable shorewall" will fix your problem,
but in any case running "systemctl status shorewall" immediately after a
reboot may give some indication as to what is going wrong.

Nathan

Bug#847345: libx11-6: the locale is not supported by Xlib, continuing without locale support

[Kepi]

I have same problem. IMHO serverity of this bug should be raised as this
is making system unusable for people with czech locales.

There are related tickets in freedesktop's bugzilla:

  - https://bugs.freedesktop.org/show_bug.cgi?id=98219
  - https://bugs.freedesktop.org/show_bug.cgi?id=81875

There is patch which probably solves the problem in the first ticket.

locales for my system

  $ locale
  LANG=cs_CZ.UTF-8
  LANGUAGE=
  LC_CTYPE="cs_CZ.UTF-8"
  LC_NUMERIC="cs_CZ.UTF-8"
  LC_TIME="cs_CZ.UTF-8"
  LC_COLLATE="cs_CZ.UTF-8"
  LC_MONETARY="cs_CZ.UTF-8"
  LC_MESSAGES="cs_CZ.UTF-8"
  LC_PAPER="cs_CZ.UTF-8"
  LC_NAME="cs_CZ.UTF-8"
  LC_ADDRESS="cs_CZ.UTF-8"
  LC_TELEPHONE="cs_CZ.UTF-8"
  LC_MEASUREMENT="cs_CZ.UTF-8"
  LC_IDENTIFICATION="cs_CZ.UTF-8"
  LC_ALL=

all locales:

  $ locale -a
  C
  cs_CZ.utf8
  C.UTF-8
  en_US.utf8
  POSIX

default lang:

  $ cat /etc/default/locale 
  #  File generated by update-locale
  LANG=cs_CZ.UTF-8

-- 
Kepi

Bug#847135: openconnect: vpn connection mtu too big

[Mike Miller]

Control: tags -1 + fixed-upstream

On Tue, Dec 06, 2016 at 21:38:50 -, Martin wrote:
> Please would you consider packaging the newer version as I doubt I'll be
> the only person to hit this and the new version does make it all simply
> work.
> 
> The current packaged version seems to drop packets with it's MTU, I see
> missed sequences in the packet trace and retransmissions but I never get
> the missed packets back. The connections either drop or sit there
> waiting...
> 
> 
> Though the new version seems to ignore the interface mtu setting when
> choosing the MTU, it does seems to work which makes me very happy.

So you believe git master fixes this issue for you and if/when 7.08
becomes available you would consider this resolved?

Thanks,

-- 
mike

Bug#807032: alsa-utils: /sys/ path is still invalid

[Elimar Riesebieter]

* ael  [2016-12-09 21:17 +]:

> On Fri, Dec 09, 2016 at 07:54:47PM +0100, Elimar Riesebieter wrote:
> > Control: tags -1 moreinfo
> > 
> > * ael  [2016-12-09 14:47 +]:
> > 
> > > Package: alsa-utils
> > > Version: 1.1.2-1
> > > Followup-For: Bug #807032
> > > 
> > > This bug is still present 1 year later. Has maintenance lapsed?
> > 
> > What happens if you install sysfsutils?
> > 
> > Elimar
> 
> Thanks for the reply. No change if I install sysfsutils, although I have
> not looked at that package in any detail.

How did you create "ekiga_headset_only"?

Elimar
-- 
  Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)

Bug#847541: Update for new programming language sections

[James McCoy]

On Thu, Dec 08, 2016 at 08:51:39PM -0800, Josh Triplett wrote:
> The attached patch provides an update with new archive sections for 
> programming
> language packages.  See https://bugs.debian.org/753480 and
> https://bugs.debian.org/845576 for more on the new sections.  ftpmaster has
> approved adding the two new sections, conditional on support for them in the
> various packages with lists of archive section names.

Vim's runtime files are routinely merged into neovim.  I'll see if we
can catch up upstream before the freeze, but I don't see this being
significant enough to bother patching Debian's packaging.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#847539: Update for new programming language sections

[James McCoy]

On Thu, Dec 08, 2016 at 08:41:06PM -0800, Josh Triplett wrote:
> The attached patch provides an update with new archive sections for 
> programming
> language packages.  See https://bugs.debian.org/753480 and
> https://bugs.debian.org/845576 for more on the new sections.  ftpmaster has
> approved adding the two new sections, conditional on support for them in the
> various packages with lists of archive section names.

Thanks.  I'll include it in the next upload.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#847068: vim-command-t: too strict dependency on libruby2.3

[Sam Morris]

On Tue, 2016-12-06 at 00:14 +0100, Christian Hofstaedtler wrote:
> * Sam Morris  [161205 20:16]:
> > Upstream introduced the strict ruby version check to reduce the number
> > of crashes experienced by users. See the issue above for the details.
> 
> The discussions upstream has linked are from dire times - 1.8 and
> 1.9, which indeed broke binary compat in minor releases. But these
> times are long gone.

I've raised this with upstream and they agree that it should be safe to
disable the version check.

> > Although I agree that the strict dependency is not ideal, I don't want
> > to go against their decision in this case.
> 
> Please understand you're causing extra issues not just for your
> package, but also for librubyX.Y.

Sorry about that--I didn't realise it would cause any work except for
me uploading a new version of the package whenever it became
uninstallable in unstable!

-- 
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9


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

Bug#847542: libmozjs-24-0 24.2.0-4 breaks gnome-shell, preventing gdm3 from starting

[rastersoft]

I suffered this same bug and also downgrading to 24.2.0-3.1, from
testing, worked fine.

-- 

Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

Bug#847417: depends on gstreamer-plugins-bad, which is an ongoing source of security holes

[Michael Biebl]

Hi Joey

Am 08.12.2016 um 03:01 schrieb Joey Hess:
> Package: gnome-video-effects
> Version: 0.4.1-3
> Severity: normal
> 
> gstreamer-plugins-bad has been in the news at least twice recently for
> security holes. 
> 
> http://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html
> https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html
> 
> It seems likely that it will continue to be a source of such security
> holes.

This doesn't immediately address your concern, but I just uploaded
tracker including this change:

"tracker-extract: Sandbox extractor threads. Filesystem and network
 access are limited to being read and local only."


> I wanted to remove gstreamer-plugins-bad from my system, but this would
> remove gnome-video-effects, which would remove cheese. I don't know why
> cheese needs a ton of insecurely implemented codecs for playing Nintendo
> games etc in order to take snapshots and record videos. Probably it doesn't?

gnome-video-effects is just one of many others depending on
gstreamer-plugins-bad, and I guess we have to check each and every one
of them.

Laurent, this dependency was originally added by you. Do you remember
the details and why this needs to be a hard dependency? The only real
dependency of gnome-video-effects is cheese, would some of the cheese
features not work if gstreamer-plugins-bad was not installed?

Michael

[1]
https://anonscm.debian.org/cgit/collab-maint/tracker.git/commit/?id=0ac99d4d549e35d87f23534d52bcba6d23893ffa
-- 
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#706322: wishlist: gui to configure joystick

[Stephen Kitt]

Hi,

On Sun, Apr 28, 2013 at 01:00:17PM +0200, yellow wrote:
> could it be possible to have a menu similarly as ZSNES
> the user press a given key compbination that works
> on us, sp, de, fr, ... keyboards to get a menu; 
> and select input gamepad1 to redefine the keys
> 
> a nice key would be :
>alt + H for instance
> 
> to get home configuratino of mednafen

Mednaffe is now available in Debian testing, and provides a GUI for
shortcut configuration; is that good enough?

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#847505: retitle 847505 ITA: dsniff -- Various tools to sniff network traffic for cleartext insecurities

[Marcos Fouces]

retitle 847505 ITA: dsniff -- Various tools to sniff network traffic for 
cleartext insecurities

Second try... Hope that works...

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Ron]

On Fri, Dec 09, 2016 at 04:00:04PM -0500, Sam Hartman wrote:
> 
> First, upgrading to new upstream is presumed good, not always good.
> My concern with Ron's position is mostly that  he wants the people
> requesting a new upstream to justify that rather than wanting the htags
> users to justify not breaking htags.

You understand the testability difference between those two though
right?  And that proving a negative is a logical impossibility?

It's relatively easy for someone to report "I have this problem"
and to assess whether that can reasonably be fixed with a backport
or not.  We do that for stable and security updates all the time.

But the only practical way to "ask" htags users to do what you ask
is to first break it anyway, and then hope you still have the
ability to backpedal once they realise you have.

Which is exactly what I was proposing the time was finally ripe
for us to do in an orderly way.  And it was further changes that
happened in only the most recent upstream releases of global
which really made that look convincing.  That still wasn't the
case with the source Punit originally proposed.

Bug#836691: Note#836690: tammy

[Tammy Childs]

On Sep 4, 2016 3:21 PM, "#WalPromos" > wrote:

CongratsThis __is your__1,OOO.OO_Walmart___GiftCard





-- 
null

Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Paul Gevers]

Hi Ben

On 03-12-16 03:39, Ben Longbons wrote:
> I got it completely working now! I did have to repack
> binutils-{i586,x86-64}-linux-gnu though.
>
> Tested that I can generate both i386 and aarch64 binaries, solely by
> specifying `-P`. Still haven't actually tested linking with libc, for
> that we'll need to do something nasty about /lib32/ (probably just
> some ifdefs based on the *host* platform - need to extend the arch
> tables for that)

I am trying to understand you shell script but it contains lots and lots
of overhead which doesn't make reading it easy (the interesting stuff
only starts at line 725). Just to make sure I am not completely
misunderstanding, you are trying to use binutils- package
on the arch of that triplet, right? But e.g. binutils-aarch64-linux-gnu
doesn't exist on amd64. So am I not reading the script correctly or how
is that supposed to work?

> Note that the
> new /etc/fpc/debian.cfg must be installed from the *unversioned*
> package - which will require a "backwards" dependency
> (fp-compiler-config-3.0.0 depends on fp-compiler-config-common).

Can you explain where this requirement comes from? If really required,
then we'll have to figure out an other solution, because circular
dependencies are a problem.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#847616: icedove: SIGSEGV in vtable for nsDisplayBackgroundImage () from /usr/lib/icedove/libxul.so

[Paul Gevers]

Package: icedove
Version: 1:45.4.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since some time icedove crashes on me at seemingly random moments. Most of
those crashes happen after hitting Ctrl-Enter to send a message. I followed the
instructions on the wiki to capture a backtrace which you can find attached.

Please let me know if you need more info.

Paul

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

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

Versions of packages icedove depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-7
ii  libcairo2 1.14.6-1.1
ii  libdbus-1-3   1.10.14-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2.1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.1-5
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libpangoft2-1.0-0 1.40.3-3
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.15.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.1-5
ii  libvpx4   1.6.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.4.0-1

Versions of packages icedove suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.15~beta1-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlhLJRgACgkQnFyZ6wW9
dQq0HAgAi/G2RmEhBXns2ONpHv129koOXWaDrTTZE/TFguQBj/GFncg5pQ7SIlkV
MYh4/1axU08DLaSMzDEAajAuvjY5pJ+v+483UW3DLgPJ3LoulD8IWLuOcz3rt4m4
N4vDe7lffvgQPtBdMVDlBFU9FJL6MD1tVNLkmtSMGsXwjKgQr68tau/GZMEPHJji
2rkSgr9nDP0BcmZANSBK3RzReRDWNMarFjS/J/jVRyyNaF7XHBgOUXSbuFiDk8sv
HG4kFqmOzJW9p7eefjs6010UXJwKRO/7sPdCZfZEB7qDjaOVWLIQEogN8rqoV5bs
ygk9YkGvKuzfJ5MEkrpMtyovF9Xt9Q==
=jbPL
-END PGP SIGNATURE-
MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin --safe-mode
GNU gdb (Debian 7.11.1-2+b1) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from 
/usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) handle SIGPIPE nostop
SignalStop  Print   Pass to program Description
SIGPIPE   NoYes Yes Broken pipe
(gdb) handle SIG38 nostop
SignalStop  Print   Pass to program Description
SIG38 NoYes Yes Real-time event 38
(gdb) run
Starting program: /usr/lib/icedove/icedove-bin --safe-mode
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe55dd700 (LWP 956)]
[Thread 0x7fffe55dd700 (LWP 956) exited]
[New Thread 0x7fffe55dd700 (LWP 961)]
[New Thread 0x7ff

Bug#839796: Ability to specify size for --skip-errors

[Anthony DeRobertis]

I lost track of this email, sorry for the very late response.

On Thu, Oct 20, 2016 at 09:47:52PM +0100, Andrew Wood wrote:
> I agree that this sounds like a good idea but there are some complications. 
> What if we get an error while half-way through a block, because the disk is
> failing but not wholly failed?

BTW: If -E is given the actual disk sector size, that can't happen. Also,
unless using O_DIRECT, I believe it can't happen on Linux if it's given
the page size (even if disk sectors are smaller).

> Do we skip a whole block, to half-way
> through the next block, or only skip to the start of the next block?  How do
> we know where the next block is?  Can we safely assume that all files on all
> filesystems always start at the beginning of a block?

On almost every filesystem, yes. At least for files of non-trivial size.
The performance of partial-sector writes is bad (forces an extra read
first), so filesystems avoid that. The only exceptions you're likely to
see are filesystems designed for tiny flash (embedded) and FUSE stuff
(e.g., read-only access to archives).

> 
> So perhaps if -E took an argument, we would explicitly state in the
> documentation that on error, PV would skip to the start of the next block,
> and would assume that the file starts at the beginning of a block.  So with
> "-E 4k", an error at 2k would skip to 4k, an error at 4k would skip to 8k,
> and so on.
> 
> Does this seem reasonable?

That sounds reasonable. Sensible, even.

-- 
A committee is a life form with six or more legs and no brain.
-- Lazarus Long, "Time Enough For Love"

Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

control: forwarded -1 https://github.com/ImageMagick/ImageMagick/issues/320

Dear realease team,

What is the next step?

Thank you

On Tue, Dec 6, 2016 at 8:23 PM, Simon McVittie  wrote:
> Control: reopen 846385
> Control: severity 846385 serious
>
> tl;dr: yes, this is clearly an ABI break.
>
> On Thu, 01 Dec 2016 at 15:55:02 +0100, roucaries bastien wrote:
>> * struct _DrawInfo (1) is not a problem from a C point of view because
>> it should be set and destry by API function. It is a opaque object. So
>> no need to so bump for this
>> *  _ElementReference (1) is part of _Drawinfo so not a problem
>> * _GradientInfo (3) is the same
>> * For _image is an opaque type so it is the same
>
> Unfortunately this is not true: none of these types are opaque. I think
> you have misunderstood what it means to say a struct type is opaque.
> For example, DrawInfo (aka struct _DrawInfo) has its layout visible to
> library users in the installed header  (in
> libmagickcore-6-headers), so any change to its size is an ABI break, and
> so is any semantic change to its contents.
>
> You are right to think that if library users were expected to allocate
> a DrawInfo on the stack, it would certainly be an ABI break to change
> its size. However, even if a structure is only ever allocated by
> library code, reading its fields directly is part of the library ABI too.
>
> For DrawInfo to be an opaque object, its layout would have to be
> in a .c or .h file used only internally by ImageMagick (and not installed
> in libmagickcore-6-headers), and library users would have to access its
> fields via accessor functions like DrawInfoGetGravity() and
> DrawInfoSetGravity(). For example, GRegex in GLib's glib/gregex.[ch]
> is a good example of an opaque object:
> https://sources.debian.net/src/glib2.0/2.50.2-2/glib/gregex.h/
> https://sources.debian.net/src/glib2.0/2.50.2-2/glib/gregex.c/
>
> The definition of an ABI break is that previously-correct code, compiled
> against version A, no longer works correctly when linked at runtime with
> version B. Consider what would happen if some program that uses ImageMagick
> is compiled against ImageMagick 6.9.1-10, and it wants to set the stroke
> opacity (which happens to be the last field in the struct):
>
> DrawInfo *draw_info = AcquireDrawInfo();
>
> draw_info->stroke_opacity = 0.5;
>
> In ImageMagick 6.9.1-10 on x86_64, according to the ABI Compliance Checker,
> the DrawInfo is a 720 byte struct. A double is 8 bytes, and stroke_opacity
> is the last thing in the struct, so that assignment results in an 8-byte
> write 712 bytes after the draw_info pointer, overwriting the bytes from
> 712 to 719 bytes after the pointer. In other words, on x86_64, it's the
> same machine code that you would get by compiling this:
>
> DrawInfo *draw_info = AcquireDrawInfo();
>
> *((double *) (((char *) draw_info) + 712)) = 0.5;
>
> Now suppose we install that program on a machine that has ImageMagick
> 6.9.2-10, in which DrawInfo has grown by 32 bytes. The program still
> writes at an offset of 712 bytes into the struct (remember that
> machine code doesn't know anything about structs or names, only
> pointers and offsets), but now the larger GradientInfo and
> ElementReference have pushed all the later struct fields further
> away from offset 0. If my arithmetic is correct, the field 712 bytes
> into the data structure is now draw_info->interword_spacing, which is
> not what was intended.
>
> Conversely, if you compile against 6.9.2-10 but use 6.9.1-10 at runtime,
> it's worse: the program writes at an offset of 724 bytes (overwriting
> bytes 724 to 731 inclusive); but since ImageMagick 6.9.1-10 only allocated
> a 720 byte struct, that write is outside the struct, and could be anything
> (in particular, it could be corrupting glibc malloc data structures).
>
> Regards,
> S

Bug#847542: libmozjs-24-0 24.2.0-4 breaks gnome-shell, preventing gdm3 from starting

[Zoltán-Csaba Nyiró]

Hi László,

I have run into the same issue today and also can confirm that
downgrading to 24.2.0-3.1 fixed it for me too.

Bests,
Csaba

Dec  9 21:25:50 csaba-pc gnome-shell[641]: JS ERROR: TypeError:
imports.ui is undefined
Dec  9 21:25:50 csaba-pc gnome-shell[641]: Execution of main.js threw
exception: JS_EvaluateScript() failed
Dec  9 21:25:50 csaba-pc gnome-session-binary[633]: Unrecoverable
failure in required component org.gnome.Shell.desktop
Dec  9 21:25:51 csaba-pc gnome-shell[849]: JS ERROR: TypeError:
imports.ui is undefined
Dec  9 21:25:51 csaba-pc gnome-shell[849]: Execution of main.js threw
exception: JS_EvaluateScript() failed
Dec  9 21:25:51 csaba-pc gnome-session-binary[841]: Unrecoverable
failure in required component org.gnome.Shell.desktop
Dec  9 21:25:52 csaba-pc NetworkManager[518]:   [1481311552.3922]
manager: startup complete
Dec  9 21:25:52 csaba-pc at-spi2-registr[891]: Could not open X display
Dec  9 21:25:52 csaba-pc at-spi2-registr[891]: AT-SPI: Cannot open
default display
Dec  9 21:25:53 csaba-pc at-spi2-registr[906]: Could not open X display
Dec  9 21:25:53 csaba-pc at-spi2-registr[906]: AT-SPI: Cannot open
default display
Dec  9 21:25:53 csaba-pc gnome-shell[897]: JS ERROR: TypeError:
imports.ui is undefined
Dec  9 21:25:53 csaba-pc gnome-shell[897]: Execution of main.js threw
exception: JS_EvaluateScript() failed
Dec  9 21:25:53 csaba-pc at-spi2-registr[918]: Could not open X display
Dec  9 21:25:53 csaba-pc at-spi2-registr[918]: AT-SPI: Cannot open
default display
Dec  9 21:25:53 csaba-pc gnome-shell[910]: JS ERROR: TypeError:
imports.ui is undefined
Dec  9 21:25:53 csaba-pc gnome-shell[910]: Execution of main.js threw
exception: JS_EvaluateScript() failed
Dec  9 21:25:53 csaba-pc gnome-session-binary[885]: Unrecoverable
failure in required component org.gnome.Shell.desktop
Dec  9 21:25:53 csaba-pc kernel: [   13.247606] gnome-session-f[922]:
segfault at 0 ip 7f64da59ba29 sp 7fffeb2132f0 error 4 in libgt
k-3.so.0.2200.4[7f64da2b9000+6f7000]


On Fri, 9 Dec 2016 11:36:56 +0100 Aiko Barz  wrote:
> On Fri, 9 Dec 2016 10:06:46 +0100 =?UTF-
8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
> > On Fri, Dec 9, 2016 at 9:15 AM, Michał Milanowski  wrote:
> > > It also breaks Cinnamon:
> > [...]
> > > After downgrading libmozjs-24  all is ok again. Please take a
look at it.
> >  Sorry for the trouble. I'm going to look into it as soon as I
arrive
> > home in the afternoon.
> 
> Downgrading libmozjs-24 did it. Text adventure successfully passed.
> 
> MfG,
> Aiko
> -- 
> Heise Medien GmbH & Co. KG
> Karl-Wiechert-Allee 10
> 30625 Hannover
> Tel.: +49 [0] 511 5352-635
> Fax: +49 [0] 511 5352-479
> E-Mail: Aiko Barz 
> 
> Registergericht: Amtsgericht Hannover HRA 26709
> 
> Persönlich haftende Gesellschafterin:
> Heise Medien Geschäftsführung GmbH
> Registergericht: Amtsgericht Hannover, HRB 60405
> Geschäftsführer: Ansgar Heise, Dr. Alfons Schräder
> 
> 

Bug#847615: a7xpg: FTBFS: /usr/bin/ld: /tmp/ccJGfpQx.o: relocation R_X86_64_PC32 against symbol `[..]' can not be used when making a shared object; recompile with -fPIC

[Chris Lamb]

Source: a7xpg
Version: 0.11.dfsg1-9
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

a7xpg fails to build from source in unstable/amd64:

  […]

  dh build
 dh_testdir
 dh_update_autotools_config
 dh_auto_configure
 debian/rules override_dh_auto_build
  make[1]: Entering directory '«BUILDDIR»'
  dh_auto_build -- DFLAGS="-frelease"
make -j1 DFLAGS=-frelease
  make[2]: Entering directory '«BUILDDIR»'
  gdc -o a7xpg -Iimport -Isrc -Wno-deprecated -frelease -g -O2 
-fdebug-prefix-map=«BUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro 
import/SDL.d import/SDL_active.d import/SDL_audio.d import/SDL_byteorder.d 
import/SDL_cdrom.d import/SDL_copying.d import/SDL_endian.d import/SDL_error.d 
import/SDL_events.d import/SDL_getenv.d import/SDL_joystick.d 
import/SDL_keyboard.d import/SDL_keysym.d import/SDL_keysym_.d 
import/SDL_mixer.d import/SDL_mouse.d import/SDL_mutex.d import/SDL_quit.d 
import/SDL_rwops.d import/SDL_syswm.d import/SDL_thread.d import/SDL_timer.d 
import/SDL_types.d import/SDL_version_.d import/SDL_video.d import/opengl.d 
import/openglu.d src/abagames/a7xpg/A7xBoot.d 
src/abagames/a7xpg/A7xGameManager.d src/abagames/a7xpg/A7xPrefManager.d 
src/abagames/a7xpg/A7xScreen.d src/abagames/a7xpg/Bonus.d 
src/abagames/a7xpg/Enemy.d src/abagames/a7xpg/Field.d src/abagames/a7xpg/Gold.d 
src/abagames/a7xpg/LetterRender.d src/abagames/a7xpg/LuminousActor.d 
src/abagames/a7xpg/LuminousActorPool.d src/abagames/a7xpg/Particle.d 
src/abagames/a7xpg/Ship.d src/abagames/util/Actor.d 
src/abagames/util/ActorInitializer.d src/abagames/util/ActorPool.d 
src/abagames/util/GameManager.d src/abagames/util/Logger.d 
src/abagames/util/PrefManager.d src/abagames/util/Rand.d 
src/abagames/util/Vector.d src/abagames/util/sdl/Input.d 
src/abagames/util/sdl/MainLoop.d src/abagames/util/sdl/SDLInitFailedException.d 
src/abagames/util/sdl/Screen.d src/abagames/util/sdl/Screen3D.d 
src/abagames/util/sdl/Sound.d src/abagames/util/sdl/Texture.d -lSDL -lGL 
-lSDL_mixer
  cc1d: warning: command line option '-Wformat=1' is valid for 
C/C++/ObjC/ObjC++ but not for D
  cc1d: warning: command line option '-Wdate-time' is valid for 
C/C++/Fortran/ObjC/ObjC++ but not for D
  /usr/bin/ld: /tmp/ccJGfpQx.o: relocation R_X86_64_PC32 against symbol 
`_D3std6random109__T21MersenneTwisterEngineTkVmi32Vmi624Vmi397Vmi31Vki2567483615Vmi11Vmi7Vki2636928640Vmi15Vki4022730752Vmi18Z21MersenneTwisterEngine9__T4seedZ4seedMFNaNbNfkZv'
 can not be used when making a shared object; recompile with -fPIC
  /usr/bin/ld: final link failed: Bad value
  collect2: error: ld returned 1 exit status
  Makefile:8: recipe for target 'a7xpg' failed
  make[2]: *** [a7xpg] Error 1
  make[2]: Leaving directory '«BUILDDIR»'
  dh_auto_build: make -j1 DFLAGS=-frelease returned exit code 2
  debian/rules:14: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 2
  make[1]: Leaving directory '«BUILDDIR»'
  debian/rules:11: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  […]

The full build log is attached.


Regards,

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


a7xpg.0.11.dfsg1-9.unstable.amd64.log.txt.gz
Description: Binary data

Bug#807032: [Pkg-alsa-devel] Bug#807032: alsa-utils: /sys/ path is still invalid

[ael]

On Fri, Dec 09, 2016 at 07:54:47PM +0100, Elimar Riesebieter wrote:
> Control: tags -1 moreinfo
> 
> * ael  [2016-12-09 14:47 +]:
> 
> > Package: alsa-utils
> > Version: 1.1.2-1
> > Followup-For: Bug #807032
> > 
> > This bug is still present 1 year later. Has maintenance lapsed?
> 
> What happens if you install sysfsutils?
> 
> Elimar

Thanks for the reply. No change if I install sysfsutils, although I have
not looked at that package in any detail.

ael

Bug#843863: libvirt-clients: Can't use gpg-agent's ssh-agent implementation with a console-based pinentry

[Guilhem Moulin]

Control: reopen -1

Hi,

Sorry, I'm reopening because while gpg-agent's ssh-agent implementation
requires $GPG_TTY to know where to prompt for the passphrase,
curses-based prompt require $TERM (just like graphical prompts require
$DISPLAY).

My bad for not providing the proper patch; new patch enclosed.

Cheers,
-- 
Guilhem.
From 5e75c353a2f2f3432eeb355940d6a1349a2c5c1d Mon Sep 17 00:00:00 2001
From: Guilhem Moulin 
Date: Fri, 9 Dec 2016 22:06:12 +0100
Subject: [PATCH] Pass GPG_TTY env var to the ssh binary
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

gpg-agent(1) can emulate the OpenSSH Agent protocol (which provides
pubkey-authentication using an authentication-capable OpenPGP key, in
addition to the usual identity files).  However for a console-based
password prompt to work, the ‘GPG_TTY’ environment variable needs to be
set to the current TTY.  Furthermore, curses-based password prompts also
require the ‘TERM’ environment variable to be set to the terminal type.
---
 src/rpc/virnetsocket.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
index 405f5ba30..98b7a3b86 100644
--- a/src/rpc/virnetsocket.c
+++ b/src/rpc/virnetsocket.c
@@ -839,6 +839,8 @@ int virNetSocketNewConnectSSH(const char *nodename,
 virCommandAddEnvPassBlockSUID(cmd, "KRB5CCNAME", NULL);
 virCommandAddEnvPassBlockSUID(cmd, "SSH_AUTH_SOCK", NULL);
 virCommandAddEnvPassBlockSUID(cmd, "SSH_ASKPASS", NULL);
+virCommandAddEnvPassBlockSUID(cmd, "GPG_TTY", NULL);
+virCommandAddEnvPassBlockSUID(cmd, "TERM", NULL);
 virCommandAddEnvPassBlockSUID(cmd, "DISPLAY", NULL);
 virCommandAddEnvPassBlockSUID(cmd, "XAUTHORITY", NULL);
 virCommandClearCaps(cmd);
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#839122: Old GTK+ 3 Debian/Ubuntu patch causes Critical Warning every time a GtkComboBox is opened

[D. B.]

On Fri, Dec 9, 2016 at 8:40 PM, Michael Biebl  wrote:

> Hi Daniel
>
>
> I see that you've been working with upstream, trying to resolve this.
> Thanks a lot for that.
> The latest stable release 3.22.5, contains your patches.
>
> What's unclear to me is whether your patches replace the above two
> patches and we can drop them now, or if we still need them (for
> Ubuntu/Unity).
> I've CCed William, from the Ubuntu side. Maybe you can confirm, that
> those patches are safe to drop now or if they are still needed.
>
> Regards,
> Michael
>
>
Hi Michael,

It took a while, but we got there in the end. :) I'm glad to have done my
bit to help, and to get William's fix into 3.22.

William's and my patches only resolve assertion failures, which were in
part revealed by the Debian patches to prevent offscreen grabs:

William's patch fixed an oversight in GtkCellRendererCombo, where the
trigger event was not passed and failed an upstream assertion. This was
forgotten for cherry-picking to 3.22, so I did that as part of merging my
patch from master. My patch was for a parallel issue: some dodgy ordering
of menu grab vs realise in GtkComboBox (with particular sets of properties)
- which caused an assertion in Debian patch 016 to fail.

So, if you want to prevent offscreen grabs, currently patches 016 and 017
seem to be still required. Near or identical patches are submitted
upstream, and reviewed quite positively, but they don't seem to have gone
any further than that. Maybe you'd like to request an update there?

https://bugzilla.gnome.org/show_bug.cgi?id=658563

That's the thread with a reviewed patch against offscreen grabs for both
widgets and devices, which AFAICT would cover both patches 016 and 017. It
might be worth asking for an update, now that it wouldn't generate errors
on Debian et al if merged.

Cheers!
Daniel

Bug#847614: node-yargs FTBFS in stretch due to missing node-cpr

[Adrian Bunk]

Source: node-yargs
Version: 6.4.0-2
Severity: serious
Tags: stretch sid
Control: block -1 by 846010

node-yargs build-depends on node-cpr,
which is not in stretch due to #846010

Bug#847613: TAG: nextcloud-client -- desktop client for nextcloud

[Louis-Philippe Véronneau]

Package: wnpp
Severity: RFP

Nextcloud is the recent ownCloud fork. While I don't think it's probable
Nextcloud itself will be packaged in Debian, having the desktop client
would be very nice.

At the moment the differences between Nextcloud and ownCloud are minor
so the owncloud-client package still works. That will eventually change
as the differences betweent the two grow

Source: https://github.com/nextcloud/client_theming

-- 
pollo



signature.asc
Description: OpenPGP digital signature

Bug#847590: gnome-session crash

[Rostislav Pehlivanov]

Can confirm that this is not nvidia-only, this happens on Intel cards too
without any nvidia packages installed.
Directions on which packages to downgrade for the moment would be useful.

Thanks

Bug#847612: monitoring-plugins-basic lost OpenSSL support

[Adrian Bunk]

Package: monitoring-plugins-basic
Version: 2.2-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=monitoring-plugins&arch=amd64&ver=2.2-1&stamp=1481212864

...

checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no
checking openssl/x509.h usability... no
checking openssl/x509.h presence... no
checking for openssl/x509.h... no
checking openssl/rsa.h usability... no
checking openssl/rsa.h presence... no
checking for openssl/rsa.h... no
checking openssl/pem.h usability... no
checking openssl/pem.h presence... no
checking for openssl/pem.h... no
checking openssl/crypto.h usability... no
checking openssl/crypto.h presence... no
checking for openssl/crypto.h... no
checking openssl/err.h usability... no
checking openssl/err.h presence... no
checking for openssl/err.h... no
checking ssl.h usability... no
checking ssl.h presence... no
checking for ssl.h... no
checking x509.h usability... no
checking x509.h presence... no
checking for x509.h... no
checking rsa.h usability... no
checking rsa.h presence... no
checking for rsa.h... no
checking pem.h usability... no
checking pem.h presence... no
checking for pem.h... no
checking crypto.h usability... no
checking crypto.h presence... no
checking for crypto.h... no
checking err.h usability... yes
checking err.h presence... yes
checking for err.h... yes
checking for CRYPTO_new_ex_data in -lcrypto... no
configure: WARNING: OpenSSL or GnuTLS libs could not be found or were disabled
...



The package must again build-depend on either libssl1.0-dev or libssl-dev
for getting OpenSSL support back.

Bug#795701: ITP: trojita -- Fast Qt IMAP e-mail client.

[Alf Gaida]

  sounds like you have a working Debian source package (.dsc and 
.debian.tar.xz) for trojita.
Where can I find it?
One could try 
https://anonscm.debian.org/git/pkg-lxqt/trojita.git/log/?h=lxqt-snapshots/latest 
(source/format 1.0) - the gpg-build-dependencies need an overhaul. The 
current packaging should compile against sid - but the copyright need 
some love. Any feedback is appreciated.

Bug#835800: transmission: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-09-05 23:27:57 [+0100], Sandro Tosi wrote:
> On Mon, Sep 5, 2016 at 10:59 PM, Sebastian Andrzej Siewior
>  wrote:
> > control: tags -1 patch
> 
> thanks for the patch, against which version is this based on? 2.92
> reached unstable after this bug was filed

This bug reached serious and has a patch available which is merged
upstream. Is there something I can help you with?

Sebastian