Bug#840601: cron: document cron dom-dow bug

[Christian Pekeler]

Package: cron
Version: 3.0pl1-127+deb8u1
Severity: normal

Dear Maintainer,

Cron has a very old bug about the way it processes asterisks in dom and dow
fields. The bug is confimed by Paul Vixie and should not be fixed. However,
it needs to be documented in crontab (5). A patch is attached.

Details: https://treats.wdt.io/cron-bug.html


-- Package-specific info:
--- EDITOR:


--- /usr/bin/editor:
/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 36008 Jun 11  2015 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 Oct  5 15:17 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Jun 11  2015 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Oct  5 15:14 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Oct  5 15:18 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Oct  5 15:14 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Oct  5 15:14 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Oct  5 15:14 /etc/cron.weekly



*** /tmp/crontab.5.patch
--- crontab.5.orig  2016-10-12 23:15:33.0 -0600
+++ crontab.5   2016-10-12 23:20:06.0 -0600
@@ -200,7 +200,7 @@
 .PP
 Note: The day of a command's execution can be specified by two
 fields \(em day of month, and day of week.  If both fields are
-restricted (i.e., aren't *), the command will be run when
+restricted (i.e., don't start with *), the command will be run when
 .I either
 field matches the current time.  For example,
 .br
@@ -259,7 +259,9 @@
 # run at 10 pm on weekdays, annoy Joe
 0 22 * * 1-5mail \-s "It's 10pm" joe%Joe,%%Where are your kids?%
 23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
-5 4 * * sun echo "run at 5 after 4 every sunday"
+5 4 * * sun echo "run at 5 after 4 every Sunday"
+0 */4 1 * mon   echo "run every 4th hour on the 1st and on every Monday"
+0 0 */2 * sun   echo "run at midn on every Sunday that's an uneven date"
 # Run on every second Saturday of the month
 0 4 8-14 * *test $(date +\\%u) \-eq 6 && echo "2nd Saturday"
 .fi
@@ -320,6 +322,15 @@
 this will affect only the commands executed in the crontab, not the execution
 of the crontab tasks themselves.
 
+POSIX specifies that the day of month and the day of week fields both need to
+match the current time if either of them
+.I is
+a *. However, this implementation only checks if the
+.I first character
+is a *. This is why "0 0 */2 * sun" runs every Sunday that's an
+uneven date while the POSIX standard would have it run every Sunday and on
+every uneven date.
+
 The 
 .I crontab
 syntax does not make it possible to define all possible periods one could 
@@ -354,4 +365,5 @@
 Paul Vixie  is the author of 
 .I cron
 and original creator of this manual page. This page has also been modified for
-Debian by Steve Greenland, Javier Fernandez-Sanguino and Christian Kastner.
\ No newline at end of file
+Debian by Steve Greenland, Javier Fernandez-Sanguino, Christian Kastner and
+Christian Pekeler.
\ No newline at end of file


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=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 cron depends on:
ii  adduser  3.113+nmu3
ii  debianutils  4.4+b1
ii  dpkg 1.17.27
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u6
ii  libpam-runtime   1.1.8-3.1+deb8u1
ii  libpam0g 1.1.8-3.1+deb8u1+b1
ii  libselinux1  2.3-2
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages cron recommends:
ii  exim4  4.84.2-2+deb8u1
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u1

Versions of packages cron suggests:
pn  anacron
pn  checksecurity  
ii  logrotate  3.8.7-1+b1

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
pn  nscd  

-- no debconf information

Bug#840599: xfce4-notifyd: Noisy help for xfce4-notifyd-config in Spanish

[Manolo Díaz]

Package: xfce4-notifyd
Version: 0.3.3-1
Severity: minor
Tags: l10n

Dear Maintainer,

'xfce4-notifyd-config --help' shows some additional useless lines when
the Spanish language is used:

$ xfce4-notifyd-config --help
Uso:
  xfce4-notifyd-config [OPCIÓN…] Project-Id-Version: Xfce Apps
Report-Msgid-Bugs-To: 
POT-Creation-Date: 2016-06-30 00:31+0200
PO-Revision-Date: 2016-08-15 16:41+
Last-Translator: Pablo Roberto “Jristz” Lezaeta Reyes 
Language-Team: Spanish (http://www.transifex.com/xfce/xfce-apps/language/es/)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Language: es
Plural-Forms: nplurals=2; plural=(n != 1);


Opciones de ayuda:
  -h, --help Mostrar opciones de ayuda
  --help-all Muestra todas las opciones de ayuda
  --help-gtk Mostrar opciones GTK+

Opciones de la aplicación:
  -V, --version  Mostrar información de la versión
  -s, --socket-id=ID._DEL_SOCKET Socket del gestor de configuración
  --display=VISORVisor [display] X que usar


On the other hand the English output is OK.


Best Regards,
-- 
Manolo Díaz

Bug#840600: evolution: google calendar fails every morning

[Marcos Mobley]

Source: evolution
Severity: normal

Dear Maintainer,

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

start evolution with a google account and it fails. there's a fix for this 
upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1373737

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


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

Kernel: Linux 4.7.0-x86_64-linode72 (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)

Bug#836385: yubikey-personalization: Please announce supported hardware using appstream

[Petter Reinholdtsen]

Hi again Simon.

Any news on getting AppStream metadata in Debian for yubikey-personalization?
Anything more I can do to help make it happen?

Btw, are you aware that the plugdev udv access mechanism is being replaced by
a uaccess tag?  You might want to add it to the udev file.

-- 
Happy hacking
Petter Reinholdtsen

Bug#840598: RFS: poppassd/1.8.7-1 [QA]

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

Following up on the NMU (#839859) uploaded last week thanks to Adam
Borowski, I am looking for a sponsor for a QA upload of poppassd.

  git clone https://anonscm.debian.org/git/collab-maint/poppassd.git
  cd poppassd && pristine-tar checkout ../poppassd_1.8.7.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  10415d0de0a5daa3bb221afdf39f777ccc7a5734 refs/heads/master
  db27d6addd476baf420d49f362b79b373462063e refs/heads/pristine-tar
  79da3cf634ebe761d494fcbbcf36a4da71379383 refs/heads/upstream

Changes since the last upload:

poppassd (1.8.7-1) unstable; urgency=medium

  * New upstream release
  * Switch source format to 3.0 (quilt)
  * Use dh with autoreconf in debian/rules (Closes: #817626)
  * Build with hardening flags
  * Add machine-readable debian/copyright
  * Update Homepage field
  * Add Vcs-Git and Vcs-Browser fields
  * Update debian/watch
  * Run wrap-and-sort
  * Update Standards-Version to 3.9.8
  * Add debian/gbp.conf for pristine-tar
  * Add myself to Uploaders after consulting with MIA team (Closes: #836008)

 -- Peter Colberg   Thu, 13 Oct 2016 00:04:08 -0400

Please see #839859 and #836008 for background information. If you have
any further questions, please contact Ricardo Mones from the MIA team.

If you decide to sponsor this package, please upload the source only
so that buildd logs are available for all archs. I will push a release
tag to the git repository after the package has been uploaded.

I suggest uploading this version to DELAYED/7 to allow the NMU to
migrate to testing and give the maintainer another week to respond.

Regards,
Peter

Bug#840597: ITP: pyflame -- CPU profiler and flame graph tool for Python

[Evan Klitzke]

Package: wnpp
Severity: wishlist
Owner: Evan Klitzke 

* Package name: pyflame
  Version : 1.1.0
  Upstream Author : Evan Klitzke 
* URL : https://github.com/uber/pyflame
* License : Apache2
  Programming Lang: Python
  Description : CPU profiler and flame graph tool for Python

Pyflame is a tool that uses the ptrace system call to analyze running
Python processes and collect stack traces and generate flame graphs. It
can be used as an alternative to, or alongside, existing Python
profilers like cProfile.

I am also the upstream author of Pyflame, and Pyflame is something I
developed for my work at my job. It's already been packaged for Debian
for our internal use, but I'd like ot contribute it to Debian proper.
I'll have the time and resources to maintain this package because it
will be part of my work at my job.

This will be my first package in Debian and I may need some hand-holding
through the process. I would very much like to eventually become a DM,
and I hope this is the first package of many that I can help maintain.
Therefore I will need a sponsor.

One further note: Pyflame itself is written in C++, and can be built
against Python2 or Python3. I'm not sure what the best way to package
that is.

Bug#840596: gkrellm-thinkbat: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: gkrellm-thinkbat
Version: 0.2.2-1
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The gkrellm-thinkbat package is one of the packages in the Debian
archive that should be proposed for installation when a given hardware
dongle is inserted or available.  Thanks to the appstream system, this
can now be announced in a way other tools can use and act on.  I've
written the isenkram system to ask the current user if hardware specific
packages should be installed when a new dongle is installed or already
present on a machine, and isenkram now uses appstream as one source for
hardware to package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
gkrellm-thinkbat package, with content similar to this:

  
  
   [...]
   
dmi:*:pn*:pvrThinkPad*:rvn*
   
  

This will suggest it on all thinkpads.  I notice from the description
that the package will require the tp_smapi kernel module.  Perhaps it is
better to match on a kernel module using 'lkmodule:tp_smapi' instead of
the DMI information?

If there are other hardware ids or kernel modules also supported by the
package, please add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#840595: thinkfan: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: thinkfan
Version: 0.9.2-1
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The thinkfan package is one of the packages in the Debian archive that
should be proposed for installation when a given hardware device
present.  Thanks to the appstream system, this can now be announced in a
way other tools can use and act on.  I've written the isenkram system to
ask the current user if hardware specific packages should be installed
when a new dongle is installed or already present on a machine, and
isenkram now uses appstream as one source for hardware to package
mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
thinkfan package, with content similar to this:

  
  
   [...]
   
dmi:*:pn*:pvrThinkPad*:rvn*
   
  

This will suggest it on all thinkpads.  I notice from the description
that the package will work with any machine providing "the sysfs hwmon
interface".  Perhaps it is better to match on a kernel module using
'lkmodule:module' instead of the DMI information?

If there are other hardware ids or kernel modules also supported by the
package, please add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339

[Paul Wise]

On Wed, Oct 12, 2016 at 7:38 PM, Paul Fertser wrote:

> Cc: Oleksij Rempel 

Please use the X-Debbugs-CC pseudo-header when submitting bugs instead
of CC, so that the recipients get the bug number too. Put it just
after Severity in the mail body so those CCed can see it:

https://www.debian.org/Bugs/Reporting#xcc

> I am looking for a sponsor for my package "open-ath9k-htc-firmware"

Correct me if I'm wrong but IIRC either yourself or Oleksij have
commit/release access upstream?

The comments for the overrides for lintian tag source-is-missing
should indicate which file is the source for each prebuilt file. I
would have one comment per instance of the tag. Just one comment
saying they are removed at build time is enough for all of the
overrides for lintian tag source-contains-prebuilt-binary. Personally,
I would suggest removing all of these files from the upstream git
repository and always building them from source. If you need to keep
them, put them in tarballs in the github releases.

Personally, I would recommend the generated files docs/*.png be
removed from the upstream git repo and rendered at build time from
their source SVG files if they are needed.

I think you should also remove the prebuilt files before
dh_auto_configure so that they can never get used by a build, even a
manual one where `debian/rules clean` is not run.

What is the reason for removing the docs/ and sboot/ directories in
override_dh_clean? AFAICS both of these contain source files. IMO you
should just remove the generated files.

The cmake part of the build process does not print compiler
invocation. Debian requires full compiler flags/output in build logs.
For cmake usually debhelper automatically passes
-DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't seem to be working here?

The debian/watch file needs adjusting for the new source package name:
s/firmware-ath9k-htc/open-ath9k-htc-firmware/

Personally I would leave "debian uupdate" out of the watch file
because it can be annoying for people who just want to download.

I would use a debian/clean file instead of override_dh_clean.

Please get the FSF address corrected in the upstream copyright info.

debian/cross-toolchain.mk needs copyright/license info filled in,
preferably in both the header of it and in debian/control.

The Uploaders field is empty. I would have expected to your name there
if you intend to co-maintain it with Oleksij.

I would recommend running this command (from the devscripts package)
so that future diffs of the Debian packaging are easier to read:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma

The Vcs-* fields should point at the repository containing the Debian
packaging, not upstream:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields

The Conflicts/Suggests fields are empty, you can remove them from
debian/control.

For merged bugs, you only need to close one of them and the rest will
be closed too.

What is the reason for renaming the upstream firmware files? Does the
Linux kernel detect the new names?

What is the reason for debian/ath9k_htc.conf? Why is it
Debian-specific instead of being committed upstream?

I'd recommend either passing --parallel at the end of the args to dh,
or upgrading to debian/compat 10, which uses that by default.

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

I'd suggest signing all tarballs, tags and commits with OpenPGP and
having uscan verify the tarball sigs:

https://wiki.debian.org/Creating%20signed%20GitHub%20releases
https://mikegerwitz.com/papers/git-horror-story
https://wiki.debian.org/debian/watch#Cryptographic_signature_verification
https://help.riseup.net/en/security/message-security/openpgp/best-practices

Automatic checks:

build:

Various gcc and other warnings.

lintian:

P: open-ath9k-htc-firmware source: debian-watch-may-check-gpg-signature
P: firmware-ath9k-htc: no-upstream-changelog
I: firmware-ath9k-htc: extended-description-is-probably-too-short
P: firmware-ath9k-htc-dbgsym: no-upstream-changelog
I: firmware-ath9k-htc-dbgsym: extended-description-is-probably-too-short

check-all-the-things:

$ env PERL5OPT=-m-lib=. cme check dpkg
Warning in 'copyright Format' value
'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/':
Format uses insecure http protocol instead of https
you can try 'cme fix dpkg' to fix the warnings shown above

$ codespell --quiet-level=3


$ cppcheck -j1 --quiet -f .
[sboot/magpie_1_1/sboot/athos/src/xtos/xtos-internal.h:142]: (error)
syntax error
[sboot/utility/adjust_dep/adj_dep.c:63]: (error) Buffer overrun
possible for long command line arguments.
[sboot/utility/adjust_time/adj_time.c:57]: (error) Buffer overrun
possible for long command line arguments.
[sboot/utility/adjust_time/adj_time.c:58]: (error) Buffer overrun
possible for long command line arguments.
[sboot/utility/bin2hex/bin2hex.c:197]: (error) Buffer overrun possible
for long command 

Bug#833741: pepperflashplugin-nonfree: Feature request?: Download from Adobe instead of Google.

[SJ Zhu]

With the release of new google-chrome-stable(54.0.2840.59-1), there is
no libpepflashplayer.so in its deb pack.

```
$ dpkg -L google-chrome-stable|grep so
/opt/google/chrome/default_apps/external_extensions.json
/opt/google/chrome/resources.pak
/opt/google/chrome/libwidevinecdm.so
/opt/google/chrome/libwidevinecdmadapter.so
```

Please increase this bug's severity.

On Mon, 8 Aug 2016 16:48:06 + Bart Martens  wrote:
> On Mon, Aug 08, 2016 at 11:11:57PM +1200, James C wrote:
> > Package: pepperflashplugin-nonfree
> > Version: 1.8.1
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > Apparently Adobe now has Pepper Flash available for download from their 
> > site.
> > This is just Pepper Flash, not the whole Chrome browser.
> > Also, an update to the 32-bit version seems to be available.
> > See:
> > http://forum.mepiscommunity.org/viewtopic.php?t=40254
>
> Indeed.
>
> >
> > (This was mentioned in the discussion for #831058,
> > but I think it deserves a new bug report.)
>
> I agree, thanks.
>
> >
> > I'm not sure if this counts as a bug, so I've marked it wishlist,
>
> Perfect.
>
> > but if it was possible to switch to downloading from the Adobe site,
> > it would speed up the download, and make the 32-bit version available again.
>
> Yes, I'm considering that.
>
> Regards,
>
> Bart Martens
>
>

Bug#840594: outguess: Still you interested in maintain outguess?

[Joao Eriberto Mota Filho]

Package: outguess
Severity: normal

Dear Maintainer,

outguess has no uploads from you since 2009. blhc is a very important tool for
forensics investigations.

I have interest in maintain outguess in Forensics Team in Debian. Please, let
me to know what you think about it.

Regards,

Eriberto

Bug#817613: outguess: diff for NMU version 1:0.2-7.1

[Joao Eriberto Mota Filho]

Control: tags 817613 + patch
Control: tags 817613 + pending

Dear maintainer,

I've prepared an NMU for outguess (versioned as 1:0.2-7.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -u outguess-0.2/debian/compat outguess-0.2/debian/compat
--- outguess-0.2/debian/compat
+++ outguess-0.2/debian/compat
@@ -1 +1 @@
-4
+10
diff -u outguess-0.2/debian/control outguess-0.2/debian/control
--- outguess-0.2/debian/control
+++ outguess-0.2/debian/control
@@ -2,12 +2,12 @@
 Section: utils
 Priority: optional
 Maintainer: anthony Gasperin 
-Standards-Version: 3.8.0.1
-Build-Depends: debhelper (>= 4.0.0)
+Standards-Version: 3.9.8
+Build-Depends: debhelper (>= 10)
 
 Package: outguess
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Universal Steganographic tool
  OutGuess is a universal steganographic tool that allows the insertion of
  hidden information into the redundant bits of data sources. The nature of the
diff -u outguess-0.2/debian/changelog outguess-0.2/debian/changelog
--- outguess-0.2/debian/changelog
+++ outguess-0.2/debian/changelog
@@ -1,3 +1,13 @@
+outguess (1:0.2-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bumped DH level to 10. (Closes: #817613)
+  * debian/control:
+  - Added the ${misc:Depends} variable.
+  - Bumped Standards-Version to 3.9.8.
+
+ -- Joao Eriberto Mota Filho   Thu, 13 Oct 2016 00:00:36 
-0300
+
 outguess (1:0.2-7) unstable; urgency=low
 
   * New Maintainer (Closes: #424718) 

Bug#840593: outguess: Mirror for homepage available

[Joao Eriberto Mota Filho]

Package: outguess
Severity: normal

Dear Maintainer,

The official outguess homepage is offline. However, if needed, there is
a mirror here[1].

[1] http://cimarron.river.com/mirrors/www.outguess.org/

Regards,

Eriberto

Bug#840397: stretch should not ship with readline6: really ?

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Matthias,

I have noticed that the package libreadlin6-dev no more exist.
The migration time was really short, not to say vanishing.

It appears that one of my package, singular, emit a segfault when
it is built against readline7 but not against readline6 [1]: so, in
practise, there is certainly some incompatibility.

Please, can you consider to reintroduce libreadlin6-dev the time
necessary to fix transition issues ?


Thanks in advance,
Jerome


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840481
- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJX/vTBAAoJED+SGaZ/NsaLuxYf/RaJ4UJ0K11tEGar8BBYOeEe
eGtNYp+Jt2s9JLV3RyJm9xNEK7md4fmBR9qtc3vwiikNg98/A+9DJg4hZszT+GAx
gz/1i9vD1XogiCLHfgYZ+sYA5/WDRJvolweRyhwiOHKpOtEBpy2jVFwxsNzrIHrt
YUW9uKti5HGBr2tQsVdCqGEFhtFki0fnpZdoe+BAt9sNI+5cYH0r5w8oLypvqaKS
r0KGyXIpr7C2Q21Ls2FTcWxpYTyB1QyWLhu0nf65x2kqWWVGPhOFqdocX/IcCOoH
jNeEGHx+zCHuOVTZGsOMH93P362xeMfGtg/tTFuB0bTuPw1fq/5oD8NpFvpjTUHM
2gv8Mdj5YtIU+0OP7M0nc1Bsrbvp7uOZd4SCYgy6ZOz3l8L1LQGSOIirCwv8vKIZ
zSmQUrBCMYctALbRt2t6a9fZQcG0LNV7x5BUnN/bPd1+8PoKvBdFUbddmvEpLFtL
2+GSDsqLk3uwbjeH3gF6g5gOsXWrpkeViiUrTk1Y8wH62neH24V/GP4rUE/FLNG6
0tSf37hKoZbFrdr060sd/iph4OPnlo80Pan6mnFSnrxvPhSDuY5YQdVL3tZou9e1
eFXCSl1DIPBLYUgQkjDceXB6mXb6e7JZutal4iOEXIaiahO3eQh1499hKRHzUaIg
w/xNRH16yHG74YxEiny6NwpYr2b73cPloGJppf9736SVB2MR+btZBS9poefngKms
wPb24/eK035I9kSfZIpEORAh3nPCTx68vSCXP85r+QFlBoSq2mR48cME9jsxDEea
fNi332G7c2yAXVyeWQxAXdPw/DW3k0KjEVOkV/7UTCZzQtghY+XGg7Gqurlg66d2
n2BdBgABGIjWkkpFHHV7tGrUfXEhPMpUWgklcv0iXuk+OfSDc5zwpS1/ubiH0sxl
cbr5BDqJjOLmegIUDytO5NIWzFlfY4ls42qEhFAwp9xHOD+yQaIPcnqwjngDveMo
nxHImWvUvLXR6EISzdEKGhSLqjfb+mqkQU9RTkElpgbflryd5UXZPb035cm+2szd
G864zja3efg0C/m/7FHLv/dZStqVo+qp6Rz4wQy1MTnP4tI0w59nnKqf/mCTk8cQ
Ikb56UhPsIgqzYnu6R3lpc3pP5ySpE3gVncyD3QSgFmQkiRghFKbNWMHg0UwoFSx
gWlWTCXCd/scEpJi9orK8udCoL1igg/tn298+QWkuT/Z72VfvG5GceOuFecjbQUy
Cv5VAtPpDIgzVRDRogY0vEu6Zq3pxe1E4NgAYiz4AVpBntjTdKNJhlhMFZxHz1BO
9fsbe02xOe483PQnZU6lF1L/G3+O4eyfxvtdNwz8oNLsjRdSpHV4i5qzhpksxSk=
=N4Nl
-END PGP SIGNATURE-

Bug#817627: poster: diff for NMU version 1:20050907-1.1

[Joao Eriberto Mota Filho]

Control: tags 817627 + patch
Control: tags 817627 + pending

Dear maintainer,

I've prepared an NMU for poster (versioned as 1:20050907-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -u poster-20050907/debian/changelog poster-20050907/debian/changelog
--- poster-20050907/debian/changelog
+++ poster-20050907/debian/changelog
@@ -1,3 +1,16 @@
+poster (1:20050907-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bumped DH level to 10. (Closes: #817627)
+  * debian/compat: created.
+  * debian/control:
+  - Added the ${misc:Depends} variable.
+  - Added the Homepage field.
+  - Bumped Standards-Version to 3.9.8.
+  - Removed the Section and Priority fields from binary block.
+
+ -- Joao Eriberto Mota Filho   Wed, 12 Oct 2016 23:12:23 
-0300
+
 poster (1:20050907-1) unstable; urgency=low
 
   [ Daniel Hermann ]
diff -u poster-20050907/debian/control poster-20050907/debian/control
--- poster-20050907/debian/control
+++ poster-20050907/debian/control
@@ -2,14 +2,12 @@
 Maintainer: Peter S Galbraith 
 Section: text
 Priority: optional
-Build-Depends: debhelper (>> 4.0.0), libpaper-dev
-Standards-Version: 3.7.3
+Build-Depends: debhelper (>= 10), libpaper-dev
+Standards-Version: 3.9.8
 
 Package: poster
 Architecture: any
-Section: text
-Priority: optional
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Create large posters out of PostScript pages
  Poster takes a one-page PostScript file and scales it to a specified
  size.  It can tile the resulting image into multiple smaller pages
diff -u poster-20050907/debian/rules poster-20050907/debian/rules
--- poster-20050907/debian/rules
+++ poster-20050907/debian/rules
@@ -6,7 +6,7 @@
 #export DH_VERBOSE=1
 
 # This is the debhelper compatibility version to use.
-export DH_COMPAT=4
+#export DH_COMPAT=4
 
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
only in patch2:
unchanged:
--- poster-20050907.orig/debian/compat
+++ poster-20050907/debian/compat
@@ -0,0 +1 @@
+10

Bug#840592: vim: Setting in /etc/vim/vimrc no effect / not working

[johnw]

On 10/13/2016 10:12 AM, john wrote:
> Package: vim
> Version: 2:8.0.0022-1
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
>Setting in /etc/vim/vimrc or /etc/vim/vimrc.local no
>effect.
>
>Only setting in $HOME/.vimrc work.
>
>ls -l /usr/share/vimrc -> /etc/vim/vimrc
>ls -l /usr/share/vimfiles -> /etc/vim
>
>Please help, thank you.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- Package-specific info:
>
> --- real paths of main Vim binaries ---
> /usr/bin/vi is /usr/bin/vim.gtk3
> /usr/bin/vim is /usr/bin/vim.gtk3
> /usr/bin/gvim is /usr/bin/vim.gtk3
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.7.0-1-grsec-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages vim depends on:
> ii  libacl1  2.2.52-3
> ii  libc62.24-3
> ii  libgpm2  1.20.4-6.2
> ii  libselinux1  2.5-3
> ii  libtinfo56.0+20160917-1
> ii  vim-common   2:8.0.0022-1
> ii  vim-runtime  2:8.0.0022-1
>
> vim recommends no packages.
>
> Versions of packages vim suggests:
> pn  ctags
> pn  vim-doc  
> pn  vim-scripts  
>
> -- no debconf information

Sorry, forget to mention, I want set "syntax off" by default.

Thanks.




signature.asc
Description: OpenPGP digital signature

Bug#840592: vim: Setting in /etc/vim/vimrc no effect / not working

[john]

Package: vim
Version: 2:8.0.0022-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

   Setting in /etc/vim/vimrc or /etc/vim/vimrc.local no
   effect.

   Only setting in $HOME/.vimrc work.

   ls -l /usr/share/vimrc -> /etc/vim/vimrc
   ls -l /usr/share/vimfiles -> /etc/vim

   Please help, thank you.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk3
/usr/bin/vim is /usr/bin/vim.gtk3
/usr/bin/gvim is /usr/bin/vim.gtk3

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.52-3
ii  libc62.24-3
ii  libgpm2  1.20.4-6.2
ii  libselinux1  2.5-3
ii  libtinfo56.0+20160917-1
ii  vim-common   2:8.0.0022-1
ii  vim-runtime  2:8.0.0022-1

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#840591: fonts-symbola: new upstream version available (Symbola 9.00)

[Chris Lawrence]

Package: fonts-symbola
Version: 2.59-1
Severity: normal

An updated version of this font is available at
http://users.teilar.gr/~g1951d/ incorporating the characters from
Unicode 9.0.0.

(Also, it would probably make sense for the upstream version number of
this binary package to be aligned with the font version number to
avoid confusion.)

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

Kernel: Linux 4.8.1 (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)

-- no debconf information

Bug#817733: xkbset: diff for NMU version 0.5-5.2

[Joao Eriberto Mota Filho]

Control: tags 817733 + patch
Control: tags 817733 + pending

Dear maintainer,

I've prepared an NMU for xkbset (versioned as 0.5-5.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -u xkbset-0.5/debian/changelog xkbset-0.5/debian/changelog
--- xkbset-0.5/debian/changelog
+++ xkbset-0.5/debian/changelog
@@ -1,3 +1,15 @@
+xkbset (0.5-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bumped DH level to 10. (Closes: #817733)
+  * debian/control:
+  - Added the ${misc:Depends} variable.
+  - Added the Homepage field.
+  - Bumped Standards-Version to 3.9.8.
+  * debian/watch: created.
+
+ -- Joao Eriberto Mota Filho   Wed, 12 Oct 2016 22:44:24 
-0300
+
 xkbset (0.5-5.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -u xkbset-0.5/debian/compat xkbset-0.5/debian/compat
--- xkbset-0.5/debian/compat
+++ xkbset-0.5/debian/compat
@@ -1 +1 @@
-4
+10
diff -u xkbset-0.5/debian/control xkbset-0.5/debian/control
--- xkbset-0.5/debian/control
+++ xkbset-0.5/debian/control
@@ -2,12 +2,13 @@
 Section: x11
 Priority: extra
 Maintainer: Francois Gurin 
-Build-Depends: libx11-dev, debhelper (>> 4.0.0), dpatch
-Standards-Version: 3.6.1.0
+Build-Depends: libx11-dev, debhelper (>> 10), dpatch
+Standards-Version: 3.9.8
+Homepage: https://faculty.missouri.edu/~stephen/software
 
 Package: xkbset
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: perl-tk
 Description: Small utility to change the AccessX settings of XKEYBOARD
  AccessX is a set of features within the XKEYBOARD extension of the
only in patch2:
unchanged:
--- xkbset-0.5.orig/debian/watch
+++ xkbset-0.5/debian/watch
@@ -0,0 +1,2 @@
+version=4
+http://faculty.missouri.edu/~stephen/software/xkbset/xkbset-(\d\S+)\.tar\.(?:bz2|gz|xz)

Bug#840590: xserver-xorg-input-synaptics: three finger tag sends scroll event

[Norbert Preining]

Package: xserver-xorg-input-synaptics
Version: 1.8.3-2
Severity: normal

Dear all,

I cannot exactly specify since when, but currently I cannot use three finger tag
to paste text.

My synclient spits out the correct settings:
TapButton1  = 1
TapButton2  = 3
TapButton3  = 2
and two finger gives me right button (correct), but three finger gives me
a scroll event.

I can verify this with gpointing-device-settings up, switch to "Dry run"
mode, and start clicking around. The one finger taps shows "1", the
two finger tap shows "3" and the three finger tap shows "down arrow"
or "up arrow" (or "3", if I didn't manage it).

This wasn't the case in former times, as I often used to paste
text with three finger tap.

All the best

Norbert


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Mar 27  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Sep  6 22:09 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT 
Integrated Graphics Controller [8086:0a26] (rev 09)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.8.0 (norbert@wienerschnitzel) (gcc version 6.2.0 20160927 
(Debian 6.2.0-5) ) #197 SMP PREEMPT Mon Oct 3 20:37:10 JST 2016

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 24230 Jun 13 14:13 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 89124 Oct 13 10:20 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[174469.492] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[174469.492] X Protocol Version 11, Revision 0
[174469.492] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[174469.492] Current Operating System: Linux wienerschnitzel 4.8.0 #197 SMP 
PREEMPT Mon Oct 3 20:37:10 JST 2016 x86_64
[174469.492] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0 root=/dev/sda7 
ro libata.force=noncq
[174469.492] Build Date: 06 September 2016  01:32:44PM
[174469.492] xorg-server 2:1.18.4-2 (https://www.debian.org/support) 
[174469.492] Current version of pixman: 0.34.0
[174469.492]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[174469.492] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[174469.492] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 11 22:58:28 
2016
[174469.493] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[174469.494] (==) No Layout section.  Using the first Screen section.
[174469.494] (==) No screen section available. Using defaults.
[174469.494] (**) |-->Screen "Default Screen Section" (0)
[174469.494] (**) |   |-->Monitor ""
[174469.494] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[174469.494] (==) Automatically adding devices
[174469.494] (==) Automatically enabling devices
[174469.494] (==) Automatically adding GPU devices
[174469.494] (==) Max clients allowed: 256, resource mask: 0x1f
[174469.494] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[174469.494]Entry deleted from font path.
[174469.495] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[174469.495] (==) ModulePath set to "/usr/lib/xorg/modules"
[174469.495] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[174469.495] (II) Loader magic: 0x5572faa6fdc0
[174469.495] (II) Module ABI versions:
[174469.495]X.Org ANSI C Emulation: 0.4
[174469.495]X.Org Video Driver: 20.0
[174469.495]X.Org XInput driver : 22.1
[174469.495]X.Org Server Extension : 9.0
[174469.497] (++) using VT number 7

[174469.497] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[174469.499] (II) xfree86: Adding drm device (/dev/dri/card0)
[174469.511] (--) PCI:*(0:0:2:0) 8086:0a26:104d:90b6 rev 9, Mem @ 
0xdf40/4194304, 0xe000/268435456, I/O @ 0x1000/64, BIOS @ 
0x/131072
[174469.511] (II) LoadModule: "glx"
[174469.511] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[174469.514] (II) Module glx: vendor="X.Org Foundation"
[174469.514]compiled for 1.18.4, module version = 1.0.0

Bug#817742: yaret: Removal of debhelper compat 4

[Eriberto Mota]

Control: tags 817742 patch
Control: tags 817742 pending

Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

yaret (2.1.0-5.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Bumped DH level to 10. (Closes: #817742)
  * Used wrap-and-sort.
  * debian/control:
  - Added Homepage field.
  - Bumped Standards-Version to 3.9.8.
  - Removed the leading article from short description.

I attached a debdiff.

Regards,

Eriberto


yaret.debdiff
Description: Binary data

Bug#840589: skimage FTBFS on multiple architectures testsuite failures.

[peter green]

package: skimage
version: 0.12.3-1
severity: serious

skimage failed to build on the buildds for multiple architectures 
including release architectures where it has built before. The failures 
seem to split into two groups.


i386/armhf/hppa

skimage.morphology.tests.test_ccomp.TestConnectedComponents.test_random ... ok
skimage.morphology.tests.test_ccomp.TestConnectedComponents.test_return_num ... 
Segmentation fault
debian/rules:59: recipe for target 'python-test2' failed

mips/powerpc/s390x/hurd-i386/kfreebsd-i386/ppc64:

FAILED (SKIP=54, failures=1)
ram) = 0.0218803320738
delta (1 iteration) = 0.0270287245737
delta (1 iteration) = 0.0270287245737
delta (2 iterations) = 0.0232331483658
delta (2 iterations) = 0.0232331483658
delta (1 iteration, clip) = 0.0248932960634
delta (1 iteration, clip) = 0.0248932960634
delta (1 iteration, shifted sinogram) = 0.0293641116974
delta (1 iteration, shifted sinogram) = 0.0293641116974

argmax of circle: (16, 0)
argmax of square: (26, 0)
argmax of circle to square: (26, 0)
0.0540346850989 2.56600451074

argmax of circle: (18, 18)
argmax of square: (29, 18)
argmax of circle to square: (29, 18)
0.000383624098141 0.0956193976186
(61, 61)
(61, 61)
(61, 61)
(61, 61)
(79, 79)
(79, 79)
(97, 97)
(97, 97)
(61, 61)
(61, 61)
(61, 61)
(61, 61)
(79, 79)
(79, 79)
(97, 97)
(97, 97)
debian/rules:59: recipe for target 'python-test2' failed
make[1]: *** [python-test2] Error 1

Bug#840588: ITP: golang-github-lunny-log -- A compatible log extension

[Michael Lustfield]

Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: golang-github-lunny-log
  Version : 0.0~git20160921.0.7887c61-1
  Upstream Author : Lunny Xiao
* URL : https://github.com/lunny/log
* License : BSD-3-clause
  Programming Lang: Go
  Description : A compatible log extension

 log GoDoc (https://godoc.org/github.com/lunny/log)
 .
 简体中文 (https://github.com/lunny/log/blob/master/README_CN.md)
 Installation
 .
 go get github.com/lunny/log
 .
 Features• Add color support for unix console• Implemented dbwriter
 to save log to database• Implemented FileWriter to save log to file
 by date or time.• Location configurationExample For Single File: Go f,
 _ := os.Create("my.log") log.Std.SetOutput(f)
 .
 .
 For Multiple Writer: Go f, _ := os.Create("my.log")
 log.Std.SetOutput(io.MultiWriter(f, os.Stdout))
 .
 .
 For log files by date or time: Go w := log.NewFileWriter(log.FileOptions{
 ByType:log.ByDay, Dir:"./logs",
 }) log.Std.SetOutput(w)
 .
 About This repo is an extension of Golang log.  LICENSE BSD License
  http://creativecommons.org/licenses/BSD/
  (http://creativecommons.org/licenses/BSD/)

I am packaging this as part of an ITP for gogs. This is a dependency for one of
the gogs dependencies. (and far from the only one)

Bug#817354: aspell-br: Removal of debhelper compat 4

[Eriberto Mota]

Control: tags 817354 patch
Control: tags 817354 pending

Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

aspell-br (0.50-2-6.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Bumped DH level to 10. (Closes: #817354)
  * debian/control:
  - Added the ${misc:Depends} variable.
  - Added the Homepage field.
  - Bumped Standards-Version to 3.9.8.
  * debian/watch: created.

I attached a debdiff.

Regards,

Eriberto


aspell-br.debdiff
Description: Binary data

Bug#840587: alex: Please remove build dependency on jade

[Neil Roeth]

Package: alex
Severity: normal

The package alex build depends on the package jade which is obsolete and
will be removed from Debian.  Its replacement is openjade.  However,
alex build depends on docbook-utils which depends on openjade, so alex
does not need an explicit dependency on openjade; jade can just be
removed.

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

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

-- 
Neil Roeth

Bug#840586: more(1) may attempt to tcsetattr(3) despite lacking controlling terminal

[Jan Schaumann]

Package: util-linux
Version: 2.20.1-1ubuntu3.1

more(1) may attempt to call tsetattr(3) on stderr even if its process is
not in a process group with a controlling terminal.  As a result,
SIGTTOU will be generated, suspending the process.

The following example illustrates the issue:

$ /bin/sh -c "timeout 60 /bin/sh -c \"ls | more\""

This command will now hang until the timeout, since the shell, ls(1) and
more(1) commands invoked by timeout(1) will be suspended.

Note the difference to

$ timeout 60 /bin/sh -c "ls | more"

which behaves as expected, since here the entire shell command is in the
process group that has the controlling terminal.


The problem is in text-utils/more.c, where a call to tcsetattr(3) is
made on stderr.  The test for whether or not a tty is present is not
sufficient here, since a tty may be present but not be in the process
group of the controlling terminal.

A simplified PoC of the problematic code looks like this:

--- 8< - 8< - 8< -

#include 
#include 
#include 
#include 
#include 
#include 

int
main(int argc, char ** argv) {
struct termios otty;
int no_tty;

if (setpgid(0, 0) == -1) {
fprintf(stderr, "Unable to setpgid: %s\n", strerror(errno));
exit(1);
}

no_tty = tcgetattr(fileno(stdout), );

if (!no_tty) {
#ifdef FIX
if (tcgetpgrp(fileno(stderr)) == getpgrp()) {
#endif
if (tcsetattr(fileno(stderr), TCSANOW, ) == -1) {
fprintf(stderr, "Unable to tcsetattr: %s\n", 
strerror(errno));
exit(1);
}
#ifdef FIX
}
#endif
}
return 0;
}

--- 8< - 8< - 8< -

If compiled without '-DFIX', then we observe the following:

$ ./a.out
$ /bin/sh -c ./a.out
[hangs, can't ^C, need to suspend and kill]

If compiled with '-DFIX', we get the desired behaviour.

The fix to text-utils/more.c should then be:

--- 8< - 8< - 8< -

--- more.c  2016-10-12 18:19:00.858761448 -0400
+++ more.c.orig 2011-09-26 05:50:25.0 -0400
@@ -1769,16 +1769,6 @@
 retry:
 #endif /* do_SIGTTOU */
 no_tty = tcgetattr(fileno(stdout), );
-no_intty = tcgetattr(fileno(stdin), );
-
-/* If we are not in the process group with the controlling terminal,
- * then we have on business trying to interact with it, so let's
- * pretend there isn't a tty. */
-if (tcgetpgrp(fileno(stdout)) != getpgrp()) {
-   no_tty = 1;
-   no_intty = 1;
-}
-
 if (!no_tty) {
docrterase = (otty.c_cc[VERASE] != 255);
docrtkill =  (otty.c_cc[VKILL] != 255);
@@ -1880,7 +1870,7 @@
if ((shell = getenv("SHELL")) == NULL)
shell = "/bin/sh";
 }
-
+no_intty = tcgetattr(fileno(stdin), );
 tcgetattr(fileno(stderr), );
 savetty0 = otty;
 slow_tty = cfgetispeed() < B1200;

--- 8< - 8< - 8< -

That is, if the current process group is not the same as the process
group of the controlling terminal, then it's best to pretend that we
don't have a terminal and cause more(1) to merely copy the input rather
than attempt to paginate.

Bug#840585: Package: installation-reports

[Joel A. Zrolka]

Package: installation-reports

Boot method: 
Image version: 
Date: 

Machine: 
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [0]
Detect network card:[E]= No Wi-fi etho
Configure network:  [0]
Detect CD:  [0]
Load installer modules: [0]
Clock/timezone setup:   [0]
User/password setup:[0]
Detect hard drives: [0]
Partition hard drives:  [0]
Install base system:[0]
Install tasks:  [0]
Install boot loader:[0]
Overall install:[0]

Comments/Problems: ran "kill cvs" but no intelligible response. Started 
evo configuration but ran into a problem with ancient invite gmail, the 
setup manager keeps opening at startup and requesting password. I 
deleted all accounts but same cycle.


software packages at install and the [secret] documentation download>



--

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip. = No log file present.



--
Joel Anthony Zrolka

1201 Primrose Ave.
Apt.# 5
McAllen, Texas
78504

Bug#835177: [PKG-Openstack-devel] Bug#835177: Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Santiago Vila]

For the record, here is a tarball for the 38 unbuildable source
packages in testing I detected today related to OpenStack.

It could be that the intention was to avoid FTBFS, but this has been
the result.

We might better have FTBFS happen in buildd.debian.org in unstable,
as that's really the best way to ensure that packages are buildable.

Thanks.


build-logs.tar.gz
Description: application/gzip

Bug#840584: apt-key doesn't report the key id and fingerprint on systems with gnupg 2.1

[Diane Trout]

Package: apt
Version: 1.3.1
Severity: normal

Dear Maintainer,

I had run apt-key on a couple of machines to remove keys for a private
repository and I noticed one machine didn't report the key id or
fingerpint of keys.

On one machine the result of apt-key list or apt-key fingerprint
includes blocks like:

/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg
--
pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
uid   [ unknown] Debian Archive Automatic Signing Key
(8/jessie)


on another machine the result of apt-key list or apt-key fingerprint
includes blocks like:

/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg
--
pub   4096R/2B90D010 2014-11-21 [expires: 2022-11-19]
  Key fingerprint = 126C 0D24 BD8A 2942 CC7D  F8AC 7638 D044 2B90
D010
uid  Debian Archive Automatic Signing Key (8/jessie)


Both machines are running apt 1.3.1, but the first machine without the
fingerprint has gnupg 2.1, while the machine with the key id and
fingerprint has gnupg 1.4.20 installed.

So I'm guessing it has something to do with the change to gnupg modern.

The key id certainly makes it easier to remove manually added keys from
/etc/apt/trusted.gpg and including the fingerprint helps verifying
system integrity.

Diane Trout


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.7\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-
1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test
-S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --
dest org.freedesktop.PackageKit --object-path
/org/freedesktop/PackageKit --timeout 4 --method
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null;
/bin/echo > /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-
info -a -e /usr/bin/appstreamcli; then appstreamcli 

Bug#840583: ITP: es-module-loader-0.17.js -- Polyfill and low-level API for the WhatWG loader spec

[Potter, Tim (HPE Linux Support)]

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

* Package name: es-module-loader-0.17.js
 Version : 0.17
 Upstream Author : Guy Bedford
* URL : https://github.com/ModuleLoader/es-module-loader
* License : Expat
 Programming Lang: JavaScript
 Description : CustomElements polyfill from the webcomponentsjs project

This library provides a polyfill and low-level API for the WhatWG
loader spec to create custom module loaders. It supports the
System.register module fomat to provide identical module loading
semantics as ES modules in environments today.
.
This package contains the 0.17 branch of the library.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#835177: [PKG-Openstack-devel] Bug#835177: Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Santiago Vila]

On Thu, Oct 13, 2016 at 01:02:30AM +0200, Thomas Goirand wrote:

> The issue is inter-(build-)dependencies. Let's say we have package A
> that build-depends on B, which itself build-depends on C. We then have
> to do a source-only upload of C, wait for the next dak run, wait for it
> to be built, then installed in the master repository. Then it has to
> reach the mirrors of buildd machines (hint: packages propagate at
> different speed on each dak run, depending on the mirror configuration,
> Internet connectivity, and so on).

No. Please take a look at any recent build log, you will see something
like this:

Get:7 http://incoming.debian.org/debian-buildd buildd-unstable/contrib Sources 
[920 B]
Get:8 http://incoming.debian.org/debian-buildd buildd-unstable/non-free Sources 
[32 B]
Get:9 http://incoming.debian.org/debian-buildd buildd-unstable/main arm64 
Packages [213 kB]

I don't know the exact definition, but surely this "incoming" thing is
something you seem not to be taking in account at all.

> Then only, B can be built, which also
> takes so long. Then only A can be built.
> 
> All of this could take maybe 2 days.

No. If A "build-depends: B" and B "build-depends: C", that would be
three mirror pulses at most, and we have a mirror pulse every six
hours. Between the first and the third mirror pulse we would only have
12 hours of "breakage", but we are talking about unstable, so that's
normal and expected.

> [...]
> still much nicer than living unstable broken for days/weeks

No, 12 hours are not days or weeks, it's less than a single day.

Your theory is basically that "a little bit of cheating is ok".
Sorry, but that does not sound acceptable.

I didn't want to add to this discussion after the reply from Ondrej,
but since you insist, here is some data:

My autobuilder tried today to build in testing all the source packages
below, they were uploaded for unstable five days ago but they were
really unbuildable in unstable.

They are still unbuildable in testing and they will remain unbuildable
in testing for four additional days:

bandit
barbican
designate
glance
ironic-inspector
magnum
manila
python-cinderclient
python-congressclient
python-debtcollector
python-glance-store
python-heatclient
python-ironicclient
python-keystoneauth1
python-keystoneclient
python-keystonemiddleware
python-magnumclient
python-manilaclient
python-mistralclient
python-neutronclient
python-neutron-lib
python-novaclient
python-openstacksdk
python-osc-lib
python-oslo.concurrency
python-oslo.config
python-oslo.db
python-oslo.messaging
python-oslo.middleware
python-oslo.privsep
python-oslo.rootwrap
python-oslo.service
python-oslo.utils
python-oslo.vmware
python-pycadf
python-senlinclient
python-tooz
zaqar

If you really care about doing "nice" things, I can think of many
things a lot nicer than uploading 38 unbuildable source packages for
unstable and then letting them to propagate to testing.

IMHO, we should really have higher standards of quality.

The right thing is still to use a clean sid chroot or doing
source-only uploads.

Thanks.

Bug#840355: Failed to create spool file /var/spool/exim4//input//...-D: Permission denied

[積丹尼 Dan Jacobson]

Yes. Glad they found the bug.

Bug#100808: ::ACKNOWLEDGEMENT MAIL::

[Armstrong, Denise]

A special donation was made to you and your family. Contact {  
stocklasjam...@homefoundation.net
 }
for details

Please Note: This is the third time we have been trying to contact you.

Best Regards.

Bug#840582: gscan2pdf: Only scanning 1 page when set to "All"

[Jason Currie]

Sorry, nevermind. I cleared my configuration file and it works properly.

On Wed, Oct 12, 2016, 7:09 PM Jason Currie  wrote:

> Package: gscan2pdf
> Version: 1.5.3-0~ppa1trusty
> Severity: important
>
> Dear Maintainer,
>
> The latest stable update, 1.5.3, only scans one page at a time when set to
> "All". If I manually set a larger page number, it will scan that number of
> pages.
>
>
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers trusty-updates
>   APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
> 'trusty')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.19.0-32-generic (SMP w/2 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages gscan2pdf depends on:
> ii  imagemagick8:6.7.7.10-6ubuntu3.1
> ii  libconfig-general-perl 2.52-1
> ii  libfilesys-df-perl 0.92-4build2
> ii  libgoo-canvas-perl 0.06-1build3
> ii  libgtk2-ex-simple-list-perl0.50-2
> ii  libgtk2-imageview-perl 0.05-1build3
> ii  libhtml-parser-perl3.71-1build1
> ii  liblist-moreutils-perl 0.33-1build3
> ii  liblocale-gettext-perl 1.05-7build3
> ii  liblog-log4perl-perl   1.41-1.1ubuntu1
> ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.3ubuntu1
> ii  libpdf-api2-perl   2.020-2
> ii  libproc-processtable-perl  0.50-1
> ii  libreadonly-perl   1.04-1
> ii  librsvg2-common2.40.2-1
> ii  libsane-perl   0.05-2build1
> ii  libset-intspan-perl1.19-1
> ii  libtiff-tools  4.0.3-7ubuntu0.4
> ii  libtry-tiny-perl   0.19-1
> ii  perlmagick [libimage-magick-perl]  8:6.7.7.10-6ubuntu3.1
> ii  sane-utils 1.0.26-git20160712-trusty0
>
> Versions of packages gscan2pdf recommends:
> pn  djvulibre-bin 
> pn  libgtk2-ex-podviewer-perl 
> pn  sane  
> pn  tesseract-ocr | gocr | cuneiform  
> pn  unpaper   
> ii  xdg-utils 1.1.0~rc1-2ubuntu7-1linuxmint1
>
> gscan2pdf suggests no packages.
>
> -- no debconf information
>
-- 

Yours ,

Jason Currie
jcurri...@gmail.com

Bug#840582: gscan2pdf: Only scanning 1 page when set to "All"

[Jason Currie]

Package: gscan2pdf
Version: 1.5.3-0~ppa1trusty
Severity: important

Dear Maintainer,

The latest stable update, 1.5.3, only scans one page at a time when set to
"All". If I manually set a larger page number, it will scan that number of
pages.



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

Kernel: Linux 3.19.0-32-generic (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.7.7.10-6ubuntu3.1
ii  libconfig-general-perl 2.52-1
ii  libfilesys-df-perl 0.92-4build2
ii  libgoo-canvas-perl 0.06-1build3
ii  libgtk2-ex-simple-list-perl0.50-2
ii  libgtk2-imageview-perl 0.05-1build3
ii  libhtml-parser-perl3.71-1build1
ii  liblist-moreutils-perl 0.33-1build3
ii  liblocale-gettext-perl 1.05-7build3
ii  liblog-log4perl-perl   1.41-1.1ubuntu1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.3ubuntu1
ii  libpdf-api2-perl   2.020-2
ii  libproc-processtable-perl  0.50-1
ii  libreadonly-perl   1.04-1
ii  librsvg2-common2.40.2-1
ii  libsane-perl   0.05-2build1
ii  libset-intspan-perl1.19-1
ii  libtiff-tools  4.0.3-7ubuntu0.4
ii  libtry-tiny-perl   0.19-1
ii  perlmagick [libimage-magick-perl]  8:6.7.7.10-6ubuntu3.1
ii  sane-utils 1.0.26-git20160712-trusty0

Versions of packages gscan2pdf recommends:
pn  djvulibre-bin 
pn  libgtk2-ex-podviewer-perl 
pn  sane  
pn  tesseract-ocr | gocr | cuneiform  
pn  unpaper   
ii  xdg-utils 1.1.0~rc1-2ubuntu7-1linuxmint1

gscan2pdf suggests no packages.

-- no debconf information

Bug#835177: [PKG-Openstack-devel] Bug#835177: Bug#835177: aodh: FTBFS with eatmydata (build hangs)

[Thomas Goirand]

On 10/11/2016 08:13 PM, Ondrej Novy wrote:
> Hi,
> 
> 2016-10-11 18:58 GMT+02:00 Thomas Goirand  >:
> 
> It is impossible maintain 400+ interacting packages the way you would
> with your single pet package.
> 
> 
> I don't see any problem using source-only upload for all OS packages.
> buildd will wait for missed deps automatically and it's cross-check of
> your work.
> 
> The only way I see to fix this, is deploying the same kind of CI/CD we
> have designed in the OpenStack infrastructure, but using Sid, and
> 
> 
> this is not needed. We should use source-only upload, that's all. We
> already have something like CI/CD - buildd with source-only uploads +
> repro builds.

The issue is inter-(build-)dependencies. Let's say we have package A
that build-depends on B, which itself build-depends on C. We then have
to do a source-only upload of C, wait for the next dak run, wait for it
to be built, then installed in the master repository. Then it has to
reach the mirrors of buildd machines (hint: packages propagate at
different speed on each dak run, depending on the mirror configuration,
Internet connectivity, and so on). Then only, B can be built, which also
takes so long. Then only A can be built.

All of this could take maybe 2 days.

And that's not the only issue. In the OpenStack packages, there's cyclic
build-dependencies. We'd have to (temporarily) remove some unit tests
and build-dependencies for some packages to be buildable.

While you do all of this, as soon as package C is uploaded, maybe all of
OpenStack is broken (who knows? I wouldn't be surprised, I have seen
such things in the past...).

What I tried to achieve was uploading everything in a single Dak run, in
order to minimize the time when we're switching from Mitaka to Newton.
That's the best service I can do to both our users (so they get updates
at once if they run unstable), and to everyone that is contributing bug
reports, as it avoids FTBFS, runtime problems and such, just because we
don't have the correct working together set of packages.

So yeah, really, source-only uploads are nice, but it will never replace
a real CI, and it prevents mass-uploads. Yes, I did forget a
build-dependency, though that's still much nicer than living unstable
broken for days/weeks with the workflow you're both proposing.

If you still don't agree, let me know. I'd love to hear counter
arguments, or a solution if there's one.

Cheers,

Thomas Goirand (zigo)

Bug#840581: vim-conque: ConqueTerm doesn't appear to load into vim

[David Cantrell]

Package: vim-conque
Version: 2.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Having installed the vim-conque package, I start vim:

  $ vim

and then try to start bash within it:

  :ConqueTerm bash

and just get this error:

  E492: Not an editor command: ConqueTerm bash

It looks like a bunch of files got installed in /usr/share/vim-conque,
but they don't seem to get loaded when vim starts.

If having access to the machine would help with debugging then I can
arrange that, I'll just need an ssh public key from you.

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

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

Versions of packages vim-conque depends on:
ii  python2.7.9-1
ii  vim-nox [vim-python]  2:7.4.488-7

Versions of packages vim-conque recommends:
ii  vim-addon-manager  0.5.3

vim-conque suggests no packages.

-- no debconf information

Bug#820913: gnome-online-accounts: Facebook and Google credentials have expired, unable to sign in

[Sam Morris]

On Tue, 2016-10-11 at 13:31 +0200, Michael Biebl wrote:
> On Sun, 08 May 2016 10:56:58 +0100 Sam Morris 
> wrote:
> > I'm now seeing this again.
> 
> 
> Hi Sam, can you still reproduce the issue?
> 
> I think I ran into this as well some time ago but haven't seen it for
> a
> while.

Hey Michael, I've not seen this for a good few months now, on a couple
of different machines, so I think it's obsolete. Thanks,

-- 
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#840580: apache2-bin: crashes when issuing a restart while mod_cgid is enabled

[Brendon Baumgartner]

Package: apache2-bin
Version: 2.4.10-10+deb8u7
Severity: important

Hello.

We have a relatively busy webserver (about 1-2 million hits per day). Recently 
we experienced some downtime and tracked it to mod_cgid. Once we disabled this 
module, the crashes stopped.

To induce the crash (doesn't always work), enable mod_cgid let the server run 
for a bit. Then issue a restart. In the error log I would find the information 
below. After the crash would occur, apache would no longer restart or 
gracefully kill. I would have to kill -9 two remaining apache processes. Once 
they were gone, I could start the process like normal.


[Fri Oct 07 09:24:35.594582 2016] [core:error] [pid 25450] AH00546: no record 
of generation 1 of exiting child 8814
[Fri Oct 07 09:24:35.594659 2016] [core:error] [pid 25450] AH00546: no record 
of generation 1 of exiting child 8098
*** stack smashing detected ***: /usr/sbin/apache2 terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x731af)[0x7f6d8e1c11af]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f6d8e246aa7]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f6d8e246a70]
/usr/lib/apache2/modules/mod_mpm_prefork.so(+0x4c08)[0x7f6d8b462c08]
/usr/sbin/apache2(+0x29e450)[0x7f6d8f2a3450]
=== Memory map: 
7f6d7f673000-7f6d7f674000 ---p  00:00 0
7f6d7f674000-7f6d7fe74000 rw-p  00:00 0
7f6d867a8000-7f6d867ad000 r-xp  fe:00 127386 
/usr/lib/apache2/modules/mod_status.so
7f6d867ad000-7f6d869ac000 ---p 5000 fe:00 127386 
/usr/lib/apache2/modules/mod_status.so
7f6d869ac000-7f6d869ad000 r--p 4000 fe:00 127386 
/usr/lib/apache2/modules/mod_status.so
7f6d869ad000-7f6d869ae000 rw-p 5000 fe:00 127386 
/usr/lib/apache2/modules/mod_status.so
7f6d869ae000-7f6d869df000 r-xp  fe:00 127385 
/usr/lib/apache2/modules/mod_ssl.so
7f6d869df000-7f6d86bdf000 ---p 00031000 fe:00 127385 
/usr/lib/apache2/modules/mod_ssl.so
7f6d86bdf000-7f6d86be1000 r--p 00031000 fe:00 127385 
/usr/lib/apache2/modules/mod_ssl.so
7f6d86be1000-7f6d86be2000 rw-p 00033000 fe:00 127385 
/usr/lib/apache2/modules/mod_ssl.so
7f6d86be2000-7f6d86be4000 rw-p  00:00 0
7f6d86be4000-7f6d86c55000 rw-p  00:00 0
7f6d86c75000-7f6d86c87000 rw-s  00:04 230335829  
/dev/zero (deleted)
7f6d86c87000-7f6d86cbc000 r--s  fe:03 2051   
/var/cache/nscd/services
7f6d86e6-7f6d86e65000 r-xp  fe:00 127793 
/usr/lib/apache2/modules/mod_socache_shmcb.so
7f6d86e65000-7f6d87064000 ---p 5000 fe:00 127793 
/usr/lib/apache2/modules/mod_socache_shmcb.so
7f6d87064000-7f6d87066000 r--p 4000 fe:00 127793 
/usr/lib/apache2/modules/mod_socache_shmcb.so
7f6d87066000-7f6d87067000 rw-p 6000 fe:00 127793 
/usr/lib/apache2/modules/mod_socache_shmcb.so
7f6d87067000-7f6d8706a000 r-xp  fe:00 127658 
/usr/lib/apache2/modules/mod_setenvif.so
7f6d8706a000-7f6d87269000 ---p 3000 fe:00 127658 
/usr/lib/apache2/modules/mod_setenvif.so
7f6d87269000-7f6d8726a000 r--p 2000 fe:00 127658 
/usr/lib/apache2/modules/mod_setenvif.so
7f6d8726a000-7f6d8726b000 rw-p 3000 fe:00 127658 
/usr/lib/apache2/modules/mod_setenvif.so
7f6d8726b000-7f6d8727b000 r-xp  fe:00 127579 
/usr/lib/apache2/modules/mod_rewrite.so
7f6d8727b000-7f6d8747a000 ---p 0001 fe:00 127579 
/usr/lib/apache2/modules/mod_rewrite.so
7f6d8747a000-7f6d8747b000 r--p f000 fe:00 127579 
/usr/lib/apache2/modules/mod_rewrite.so
7f6d8747b000-7f6d8747c000 rw-p 0001 fe:00 127579 
/usr/lib/apache2/modules/mod_rewrite.so
7f6d8747c000-7f6d8747f000 r-xp  fe:00 121863 
/lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f6d8747f000-7f6d8767e000 ---p 3000 fe:00 121863 
/lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f6d8767e000-7f6d8767f000 r--p 2000 fe:00 121863 
/lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f6d8767f000-7f6d8768 rw-p 3000 fe:00 121863 
/lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f6d8768-7f6d8768b000 r-xp  fe:00 122014 
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f6d8768b000-7f6d8788a000 ---p b000 fe:00 122014 
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f6d8788a000-7f6d8788b000 r--p a000 fe:00 122014 
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f6d8788b000-7f6d8788c000 rw-p b000 fe:00 122014 
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f6d8788c000-7f6d878ae000 r-xp  fe:00 123865 

Bug#840355: Failed to create spool file /var/spool/exim4//input//...-D: Permission denied

[Adam D. Barratt]

On Tue, 2016-10-11 at 04:38 +0800, 積丹尼 Dan Jacobson wrote:
> Can't send mail, because:
> 2016-10-11 04:30:53 Failed to create spool file 
> /var/spool/exim4//input//1bthDp-0002gq-Fy-D: Permission denied

That looks awfully similar to
https://lists.exim.org/lurker/message/20161012.203414.c4c043d5.en.html
(which has just had a reply saying it will be fixed in RC3)

Regards,

Adam

Bug#840579: ifupdown: manpage should include a much simpler example

[Samuel Thibault]

Package: ifupdown
Version: 0.8.16
Severity: minor

Hello,

The example that interfaces(5) shows is very complex: it uses hotplug,
a non-debian map-scheme script, map, etc. While it's interesting to show
the amount of available advanced features, it'd be good to start with a
much simpler example, such as a mere:

auto eth0

iface eth0 inet dhcp

, and a mere:

auto eth0

iface eth0 inet static
address 192.168.1.2/24
gateway 192.168.1.1

which would cover a very large part of the actual usage, while not
confusing the user right from the start with a complex setup.

Samuel

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

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

Versions of packages ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.45
ii  iproute2 4.6.0-4
ii  libc62.24-3
ii  lsb-base 9.20160629

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.5~b1-1

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-1+3
ii  rdnssd  1.0.1-6

-- no debconf information

-- 
Samuel
Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for Linux...
(By cbbr...@io.org, Christopher Browne)

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Julien Cristau]

On Mon, Oct 10, 2016 at 15:27:02 +0530, Pirate Praveen wrote:

> package: release.debian.org
> 
> Dear Release Team,
> 
> As discussed with FTP masters[1], I'd like to request an RC exception
> for browserified javascript packages already in the archive.
> 
> Hopefully we'll be able to complete a proper browserification
> environment in debian for stretch+1 release.
> 
IMO, it may be ok to request exceptions for specific packages/bugs (and
then we may or may not grant that), but not such a broad "let's ignore
the DFSG" exception.

Cheers,
Julien

Bug#834685: python-reno: FTBFS in testing (failing tests)

[Santiago Vila]

found 834685 1.3.0-5
thanks

Still happening in this version. If you need a build log, just say so,
but this was already diagnosed in the past as indicated by the
changelog.

Now the changelog entry for 1.3.0-4 has disappeared (?), and the changelog
entry for 1.3.0-5 says again "Added gnupg as build-depends".

The debian/control file, however, still does not have gnupg anywhere.

Bug#822434: Fwd: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2

[Andreas Beckmann]

Subject: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2
Date: Wed, 12 Oct 2016 19:06:38 +0200
From: Graham Inggs 
To: Debian NVIDIA Maintainers 

On 12 October 2016 at 09:36, Graham Inggs  wrote:
> OK, let me see what I can do with that.

I found an internet connection that was slower than I had hoped for,
but I managed to download the tarballs using 'svn cat' and upload a
test package to my PPA.  I found that the Provides: libcuda-8.0-1 had
disappeared from Ubuntu's drivers between nvidia-361 and nvidia-367,
but we got that fixed.
Reverse dependencies eztrace-contrib, hwloc-contrib and
starcpu-contrib built successfully with no changes.
Pycuda needed one small change from upstream [1] and then passed its tests.

I'm going to see if I can do some testing on my own hardware now.

Were you intending that I upload to Ubuntu the packaging in its
current state, or am I waiting for you to add the new packages to
debian/control, or is there something I can help with?

For reference, the MD5SUMS of the tarballs I downloaded:
ba1afaa68562ed0b43366d0b1f78c3bc
*nvidia-cuda-toolkit_8.0.44.orig-ppc64el.tar.gz
ec17c5f3c91ca7c26e1951c37d6d42cf *nvidia-cuda-toolkit_8.0.44.orig.tar.gz

I did check that the filesizes matched and they extracted without errors.


[1]
https://git.tiker.net/pycuda.git/commit/255644ad802a20191e31bc15f4fd46e6c9d6e38a

___
pkg-nvidia-devel mailing list
pkg-nvidia-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-devel

Bug#840472: apt-listbugs: [INTL:de] Updated German debconf translation

[Francesco Poli]

On Wed, 12 Oct 2016 23:25:09 +0200 Chris Leick wrote:

> Francesco Poli wrote;
[...]
> > Could you please suggest a way to improve the consistency of the
> > translation, by using the same German word for the English "tags"?
> > If you tell me which string I should modify and how, I can apply the
> > fix to the .po file by myself.
> 
> Hi Francesco,
> 
> both words means the same, but for consistency, I think »Markierung« is 
> better. We have a German wordlist for such words:
> https://wiki.debian.org/Wortliste
> Plural form of »Markierung« is »Markierungen«.

Perfect, then please suggest how I can modify:

   #: ../lib/aptlistbugs/logic.rb:54
   msgid " -T : Filter bugs by tags you want to see.\n"
   msgstr " -T : filtert nach Kennzeichnungen, die Sie sehen 
wollen.\n"



P.S.: please keep the bug e-mail address and debian-l10n-german in the
loop...


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


pgpp0x76NzRRS.pgp
Description: PGP signature

Bug#822434: Fwd: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2

[Andreas Beckmann]

Subject: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2
Date: Wed, 12 Oct 2016 23:42:15 +0200
From: Andreas Beckmann 
To: Graham Inggs 

On 2016-10-12 19:06, Graham Inggs wrote:
> Were you intending that I upload to Ubuntu the packaging in its
> current state, or am I waiting for you to add the new packages to
> debian/control, or is there something I can help with?

I just committed the new packages, with just some description stubs. So
everything should be in and I would say: go ahead!

> For reference, the MD5SUMS of the tarballs I downloaded:
> ba1afaa68562ed0b43366d0b1f78c3bc 
> *nvidia-cuda-toolkit_8.0.44.orig-ppc64el.tar.gz
> ec17c5f3c91ca7c26e1951c37d6d42cf *nvidia-cuda-toolkit_8.0.44.orig.tar.gz

looks good


Andreas

Bug#822434: Fwd: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2

[Andreas Beckmann]

Subject: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2
Date: Wed, 12 Oct 2016 09:36:24 +0200
From: Graham Inggs 
To: Debian NVIDIA Maintainers 

On 12 October 2016 at 00:06, Andreas Beckmann  wrote:
> It's mainly the new packages missing from debian/control (I didn't want
> to commit the FIXME descriptions) and their .install files. Lintian
> overrides and symbols files are already in place, and you should be able
> to build packages for testing reverse dependencies even without having
> the new packages.

OK, let me see what I can do with that.

> Which compilers will be in yakkety? gcc-4.8/4.9/5?

I see 4.7, 4.8, 4.9, 5 and 6 in the archive for yakkety.
4-7, 4-8, 4-9 and 5 still have reverse build-dependencies.

> I just committed the ones we have now, to be sure we use the same ones.

Thanks, I see them.

___
pkg-nvidia-devel mailing list
pkg-nvidia-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-devel

Bug#822434: Fwd: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2

[Andreas Beckmann]

[ FTR: resending to the bug ]

Subject: Re: Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2
Date: Wed, 12 Oct 2016 00:06:19 +0200
From: Andreas Beckmann 
To: Debian NVIDIA Maintainers 

On 2016-10-11 21:56, Graham Inggs wrote:
> Hi lumin, Andreas
> 
> On 7 October 2016 at 17:24, lumin  wrote:
>> I downloaded the tarball, and I may hopefully finish the patchset
>> within a week or two. Is this acceptable for Ubuntu freeze exception?
> 
> I've managed to get a Feature Freeze Exception (LP: #1630162) [1], but
> Yakkety releases on Thursday [2], so that leaves us with very little
> time.  I think if we can get something into SVN within the next 24
> hours, I can upload that directly to Ubuntu as 8.0.44-0ubuntu1.

It's mainly the new packages missing from debian/control (I didn't want
to commit the FIXME descriptions) and their .install files. Lintian
overrides and symbols files are already in place, and you should be able
to build packages for testing reverse dependencies even without having
the new packages.

Which compilers will be in yakkety? gcc-4.8/4.9/5?

> I did the same for 7.5.18-0ubuntu1 for the Xenial release, but I was
> able to grab the orig.tar from SVN [4].
> I don't see the 8.0.44 tarball there yet, so I hope the tarball
> generation is deterministic, or else we just need to make sure we
> upload the same tarball to Debian as we do to Ubuntu.

Generation should be deterministic (unless nvidia changes something on
their download servers, updating timestamps will break determinism)
I just committed the ones we have now, to be sure we use the same ones.

I only tested building the packages on amd64 and ppc64el, but did not
test them (or the rdepends) at all.


Andreas

Bug#667616: brltty greedily grabs serial ports, ftdi_sio loses connection

[Samuel Thibault]

Mariusz Gronczewski, on Thu 13 Oct 2016 00:03:18 +0200, wrote:
> Hard to tell, server in question was installed from preseed file and
> it was only one having that package...

Ok, perhaps /var/log/dpkg.log or /var/log/installer/syslog would show
the circumstances where it got installed?

Samuel

Bug#840578: /lib/systemd/system/limba-cleanup.service: Unknown lvalue 'ConditionPathExists' in section 'Service'

[Laurent Bigonville]

Package: limba
Version: 0.5.6-2
Severity: normal

Hi,

I just saw that in the journal. ConditionPathExists should be defined in
the Unit section.

Regards,

Laurent Bigonville

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

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

Versions of packages limba depends on:
ii  libappstream4  0.10.2-1
ii  libarchive13   3.2.1-4
ii  libassuan0 2.4.3-1
ii  libc6  2.24-3
ii  libcurl3-gnutls7.50.1-1
ii  libglib2.0-0   2.50.1-1
ii  libgpg-error0  1.24-1
ii  libgpgme11 1.7.0-1
ii  liblimba0  0.5.6-2
ii  libpolkit-gobject-1-0  0.113-4
ii  libuuid1   2.28.2-1

Versions of packages limba recommends:
ii  systemd  231-9

limba suggests no packages.

-- no debconf information

Bug#835360: rkt: FTBFS on several architectures

[Dmitry Smirnov]

On Tuesday, 11 October 2016 8:03:28 PM AEDT Andreas Henriksson wrote:
> Excuse me for being very naive here, but this is my first encounter
> with (packaging) go.
> 
> The attached patch seems to make the appc-spec package build for me

Awesome. Thank you very much Andreas. On my own I could not see this obvious 
solution to the problem... I've just uploaded appc-spec v0.8.7 and rkt should 
be ready for upload by the time when appc-spec propagates to mirrors.

-- 
Regards,
 Dmitry Smirnov.

---

In questions of science, the authority of a thousand is not worth the
humble reasoning of a single individual.
-- Galileo Galilei


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

Bug#835360: rkt: FTBFS on several architectures

[Dmitry Smirnov]

On Tuesday, 11 October 2016 3:41:59 PM AEDT Jonathan Boulle wrote:
> Dmitry, could you point me towards the "golang-github-appc-spec" 0.8.7
> FTBFS?

Thank you for following our progress, Jonathan.
This problem happened on my dev box when I tried to prepare new upload of 
appc-spec:


src/github.com/appc/spec/schema/image.go:25:2: code in directory /build/
golang-github-appc-spec-0.8.7+dfsg/_build/src/github.com/appc/spec/Godeps/
_workspace/src/go4.org/errorutil expects import "go4.org/errorutil"


Apparently something changed in golang(?) that invalidated sub-vendoring of 
"go4.org/errorutil"... Luckily Andreas Henriksson provided a solution to 
this.

-- 
All the best,
 Dmitry Smirnov.

---

Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken


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

Bug#667616: brltty greedily grabs serial ports, ftdi_sio loses connection

[Mariusz Gronczewski]

2016-10-12 17:26 GMT+02:00 Samuel Thibault :
> Hello,

> That's still one of the things we'd need to determine.
>
> apt-cache rdepends brltty
>
> doesn't show anything that depends on or recommends brltty,
> except brltty-{espeak,flite,speechd}, which nobody depends on or
> recommends. When removing brltty, does it not uninstall anything?
>
> Samuel

Hard to tell, server in question was installed from preseed file and
it was only one having that package... but I've recently installed its
twin (same repos, same Puppet manifest, same purpose) and it didn't
had it

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64

Bug#840577: xinput: horizontal scroll doesn't work

[gpe92]

Package: xinput
Version: 1.6.2-1
Severity: normal

Dear Maintainer,

I'm using a Lenovo T420 with a touchpad with these properties:
xinput list-props 11
Device 'SynPS/2 Synaptics TouchPad':
Device Enabled (139):   1
Coordinate Transformation Matrix (141): 1.00, 0.00, 0.00, 
0.00, 1.00, 0.00, 0.00, 0.00, 1.00
libinput Tapping Enabled (278): 1
libinput Tapping Enabled Default (279): 0
libinput Tapping Drag Enabled (280):1
libinput Tapping Drag Enabled Default (281):1
libinput Tapping Drag Lock Enabled (282):   0
libinput Tapping Drag Lock Enabled Default (283):   0
libinput Tapping Button Mapping Enabled (284):  1, 0
libinput Tapping Button Mapping Default (285):  1, 0
libinput Accel Speed (286): 1.00
libinput Accel Speed Default (287): 0.00
libinput Natural Scrolling Enabled (288):   0
libinput Natural Scrolling Enabled Default (289):   0
libinput Send Events Modes Available (262): 1, 1
libinput Send Events Mode Enabled (263):0, 0
libinput Send Events Mode Enabled Default (264):0, 0
libinput Left Handed Enabled (290): 0
libinput Left Handed Enabled Default (291): 0
libinput Scroll Methods Available (292):1, 1, 0
libinput Scroll Method Enabled (293):   0, 1, 0
libinput Scroll Method Enabled Default (294):   1, 0, 0
libinput Disable While Typing Enabled (295):1
libinput Disable While Typing Enabled Default (296):1
Device Node (265):  "/dev/input/event1"
Device Product ID (266):2, 7
libinput Drag Lock Buttons (297):   
libinput Horizontal Scroll Enabled (267):   1

As you can see on the last line the horizontal scroll is enabled but 
this has no effect...

Regards.

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

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

Versions of packages xinput depends on:
ii  libc6 2.24-3
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.6-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxrandr22:1.5.0-1

xinput recommends no packages.

xinput suggests no packages.

-- no debconf information

Bug#840546: Stable Debdiff For CVE-2016-7966/kdepimlibs

[Scott Kitterman]

On Wednesday, October 12, 2016 09:36:13 PM Salvatore Bonaccorso wrote:
> Hi Scott,
> 
> On Wed, Oct 12, 2016 at 02:56:06PM -0400, Scott Kitterman wrote:
> > Proposed update attached.  It is the exact upstream commit that resolved
> > this issue upstream (relevant code is unchanged from stable) and I have
> > the fix running locally.  I do not have an example of the exploit to
> > verify the adequacy of the fix, but it does appear to be regression free.
> > 
> > I have an upload for jessie-security prepared.
> 
> Thanks, please do upload in this case. Remember to build with -sa,
> since it's the first upload dak on security-master seens for
> kdepimlibs.

Uploaded.

Scott K

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

Bug#840576: libcmrt-dev: missing dependency on libva-dev

[Rebecca N. Palmer]

Package: libcmrt-dev
Version: 1.0.6+dfsg1-1

libcmrt-dev does an "#include "
( 
http://sources.debian.net/src/libcmrt/1.0.6%2Bdfsg1-1/src/cm_rt_linux.h/?hl=35#L35
 ),
which is in libva-dev, but doesn't depend on it.

Bug#840575: sbuild bpo: uses non-available option gnupg --pinentry-mode

[Thomas Goirand]

Package: sbuild
Version: 0.71.0-2~bpo8+1
Severity: grave
Tags: patch

Dear backport maintainer,

Since the upload of sbuild 0.71.0-2~bpo8+1 to stable backport, running
sbuild-update --keygen leads to this error message:

gpg: Invalid option "--pinentry-mode"

Indeed, it looks like --pinentry-mode isn't available in gnupg 1.4.18-7 which
is in Jessie. Since there's no backport of gnupg 2.1.x, this makes sbuild from
jessie-bpo completely broken, considering one need to run sbuild-update --keygen
to start using sbuild.

This simple patch to ChrootSetup.pm line 277 fixes the issue:

--- ChrootSetup.pm.orig 2016-10-12 21:03:05.357702250 +
+++ ChrootSetup.pm  2016-10-12 21:03:26.929579131 +
@@ -274,7 +274,7 @@
return $?
 }
 
-my @command = ('gpg', '--no-options', '--pinentry-mode', 'loopback', 
'--passphrase-file', '/dev/null', '--no-default-keyring', '--batch', 
'--gen-key',
+my @command = ('gpg', '--no-options', '--passphrase-file', '/dev/null', 
'--no-default-keyring', '--batch', '--gen-key',
$tmpfilename);
 $host->run_command(
 { COMMAND => \@command,

Please apply this patch to sbuild 0.71.0-2~bpo8+1 and upload the fix.

Thanks for maintaining this sbuild backport: it is very useful, especially that
$clean_source = 0; isn't available in Jessie's version of sbuild (if you know a
workaround for this without jessie-bpo, please let me know).

Cheers,

Thomas Goirand (zigo)

Bug#840568: caja: Impossible to have speech feedback when items are set in icons

[Luke Yelavich]

You also want the commit after that, which fixes a GTK critical warning when 
opening the properties/emblems dialog. Here is a patch with both fixes combined.
diff --git a/eel/eel-accessibility.c b/eel/eel-accessibility.c
index 707756d..da586dd 100644
--- a/eel/eel-accessibility.c
+++ b/eel/eel-accessibility.c
@@ -63,6 +63,7 @@ eel_accessibility_set_up_label_widget_relation (GtkWidget *label, GtkWidget *wid
  *
  * Return value: the registered type, or 0 on failure.
  **/
+#if !GTK_CHECK_VERSION(3, 0, 0)
 GType
 eel_accessibility_create_derived_type (const char *type_name,
GType existing_gobject_with_proxy,
@@ -113,7 +114,7 @@ eel_accessibility_create_derived_type (const char *type_name,
 
 return type;
 }
-
+#endif
 
 static GQuark
 get_quark_accessible (void)
@@ -207,6 +208,7 @@ eel_accessibility_destroy (gpointer data,
  *
  * Return value: @atk_object.
  **/
+#if !GTK_CHECK_VERSION(3, 0, 0)
 AtkObject *
 eel_accessibility_set_atk_object_return (gpointer   object,
 AtkObject *atk_object)
@@ -224,6 +226,7 @@ eel_accessibility_set_atk_object_return (gpointer   object,
 
 return atk_object;
 }
+#endif
 
 static GailTextUtil *
 get_simple_text (gpointer object)
diff --git a/eel/eel-accessibility.h b/eel/eel-accessibility.h
index 45514c9..a1f68d5 100644
--- a/eel/eel-accessibility.h
+++ b/eel/eel-accessibility.h
@@ -38,11 +38,13 @@ typedef void (*EelAccessibilityClassInitFn)(AtkObjectClass *klass);
 AtkObject*eel_accessibility_get_atk_object(gpointer  object);
 AtkObject*eel_accessibility_for_object(gpointer  object);
 gpointer  eel_accessibility_get_gobject   (AtkObject*object);
+#if !GTK_CHECK_VERSION(3, 0, 0)
 AtkObject*eel_accessibility_set_atk_object_return (gpointer  object,
 AtkObject*atk_object);
 GType eel_accessibility_create_derived_type   (const char   *type_name,
 GType existing_gobject_with_proxy,
 EelAccessibilityClassInitFn class_init);
+#endif
 void  eel_accessibility_set_name  (gpointer  object,
 const char   *name);
 void  eel_accessibility_set_description   (gpointer  object,
diff --git a/eel/eel-canvas.c b/eel/eel-canvas.c
index ae4faaa..7413214 100644
--- a/eel/eel-canvas.c
+++ b/eel/eel-canvas.c
@@ -68,6 +68,9 @@
 #include 
 #include 
 #include 
+#if GTK_CHECK_VERSION(3,2,0)
+#include 
+#endif
 #include 
 #if GTK_CHECK_VERSION(3,0,0)
 # include 
@@ -2158,6 +2161,25 @@ eel_canvas_accessible_ref_child (AtkObject *obj,
 return atk_object;
 }
 
+#if GTK_CHECK_VERSION(3, 0, 0)
+G_DEFINE_TYPE (EelCanvasAccessible, eel_canvas_accessible, GTK_TYPE_CONTAINER_ACCESSIBLE)
+
+static void
+eel_canvas_accessible_class_init (EelCanvasAccessibleClass *klass)
+{
+AtkObjectClass *atk_class = ATK_OBJECT_CLASS (klass);
+accessible_parent_class = g_type_class_peek_parent (atk_class);
+
+atk_class->initialize = eel_canvas_accessible_initialize;
+atk_class->get_n_children = eel_canvas_accessible_get_n_children;
+atk_class->ref_child = eel_canvas_accessible_ref_child;
+}
+
+static void
+eel_canvas_accessible_init (EelCanvasAccessible *accessible)
+{
+}
+#else
 static void
 eel_canvas_accessible_class_init (AtkObjectClass *klass)
 {
@@ -2275,7 +2297,7 @@ eel_canvas_accessible_factory_get_type (void)
 
 return type;
 }
-
+#endif
 
 /* Class initialization function for EelCanvasClass */
 static void
@@ -2336,9 +2358,13 @@ eel_canvas_class_init (EelCanvasClass *klass)
   G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT);
 #endif
 
+#if GTK_CHECK_VERSION(3, 0, 0)
+gtk_widget_class_set_accessible_type (widget_class, eel_canvas_accessible_get_type ());
+#else
 atk_registry_set_factory_type (atk_get_default_registry (),
EEL_TYPE_CANVAS,
eel_canvas_accessible_factory_get_type ());
+#endif
 }
 
 /* Callback used when the root item of a canvas is destroyed.  The user should
@@ -3424,7 +3450,7 @@ idle_handler (gpointer data)
 {
 EelCanvas *canvas;
 
-#if !GTK_CHECK_VERSION (3, 0, 0)
+#if !GTK_CHECK_VERSION(3, 0, 0)
 GDK_THREADS_ENTER ();
 #endif
 
@@ -4270,6 +4296,43 @@ eel_canvas_item_accessible_ref_state_set (AtkObject *accessible)
 return state_set;
 }
 
+#if GTK_CHECK_VERSION(3, 0, 0)
+static GType eel_canvas_item_accessible_get_type (void);
+
+typedef struct _EelCanvasItemAccessible EelCanvasItemAccessible;
+typedef struct _EelCanvasItemAccessibleClass EelCanvasItemAccessibleClass;
+
+struct _EelCanvasItemAccessible
+{
+GtkAccessible parent;
+};
+
+struct _EelCanvasItemAccessibleClass
+{
+GtkAccessibleClass parent_class;
+};
+
+G_DEFINE_TYPE_WITH_CODE (EelCanvasItemAccessible,
+ eel_canvas_item_accessible,
+ 

Bug#840568: caja: Impossible to have speech feedback when items are set in icons

[Luke Yelavich]

You also want the commit after that, which slightly changes the way things work 
in eel/eel-labeled-image.c to fix a GTK critical warning when opening the 
properties/emblems dialog. Attached ia a diff with both patches combined.
diff --git a/eel/eel-accessibility.c b/eel/eel-accessibility.c
index 707756d..da586dd 100644
--- a/eel/eel-accessibility.c
+++ b/eel/eel-accessibility.c
@@ -63,6 +63,7 @@ eel_accessibility_set_up_label_widget_relation (GtkWidget *label, GtkWidget *wid
  *
  * Return value: the registered type, or 0 on failure.
  **/
+#if !GTK_CHECK_VERSION(3, 0, 0)
 GType
 eel_accessibility_create_derived_type (const char *type_name,
GType existing_gobject_with_proxy,
@@ -113,7 +114,7 @@ eel_accessibility_create_derived_type (const char *type_name,
 
 return type;
 }
-
+#endif
 
 static GQuark
 get_quark_accessible (void)
@@ -207,6 +208,7 @@ eel_accessibility_destroy (gpointer data,
  *
  * Return value: @atk_object.
  **/
+#if !GTK_CHECK_VERSION(3, 0, 0)
 AtkObject *
 eel_accessibility_set_atk_object_return (gpointer   object,
 AtkObject *atk_object)
@@ -224,6 +226,7 @@ eel_accessibility_set_atk_object_return (gpointer   object,
 
 return atk_object;
 }
+#endif
 
 static GailTextUtil *
 get_simple_text (gpointer object)
diff --git a/eel/eel-accessibility.h b/eel/eel-accessibility.h
index 45514c9..a1f68d5 100644
--- a/eel/eel-accessibility.h
+++ b/eel/eel-accessibility.h
@@ -38,11 +38,13 @@ typedef void (*EelAccessibilityClassInitFn)(AtkObjectClass *klass);
 AtkObject*eel_accessibility_get_atk_object(gpointer  object);
 AtkObject*eel_accessibility_for_object(gpointer  object);
 gpointer  eel_accessibility_get_gobject   (AtkObject*object);
+#if !GTK_CHECK_VERSION(3, 0, 0)
 AtkObject*eel_accessibility_set_atk_object_return (gpointer  object,
 AtkObject*atk_object);
 GType eel_accessibility_create_derived_type   (const char   *type_name,
 GType existing_gobject_with_proxy,
 EelAccessibilityClassInitFn class_init);
+#endif
 void  eel_accessibility_set_name  (gpointer  object,
 const char   *name);
 void  eel_accessibility_set_description   (gpointer  object,
diff --git a/eel/eel-canvas.c b/eel/eel-canvas.c
index ae4faaa..7413214 100644
--- a/eel/eel-canvas.c
+++ b/eel/eel-canvas.c
@@ -68,6 +68,9 @@
 #include 
 #include 
 #include 
+#if GTK_CHECK_VERSION(3,2,0)
+#include 
+#endif
 #include 
 #if GTK_CHECK_VERSION(3,0,0)
 # include 
@@ -2158,6 +2161,25 @@ eel_canvas_accessible_ref_child (AtkObject *obj,
 return atk_object;
 }
 
+#if GTK_CHECK_VERSION(3, 0, 0)
+G_DEFINE_TYPE (EelCanvasAccessible, eel_canvas_accessible, GTK_TYPE_CONTAINER_ACCESSIBLE)
+
+static void
+eel_canvas_accessible_class_init (EelCanvasAccessibleClass *klass)
+{
+AtkObjectClass *atk_class = ATK_OBJECT_CLASS (klass);
+accessible_parent_class = g_type_class_peek_parent (atk_class);
+
+atk_class->initialize = eel_canvas_accessible_initialize;
+atk_class->get_n_children = eel_canvas_accessible_get_n_children;
+atk_class->ref_child = eel_canvas_accessible_ref_child;
+}
+
+static void
+eel_canvas_accessible_init (EelCanvasAccessible *accessible)
+{
+}
+#else
 static void
 eel_canvas_accessible_class_init (AtkObjectClass *klass)
 {
@@ -2275,7 +2297,7 @@ eel_canvas_accessible_factory_get_type (void)
 
 return type;
 }
-
+#endif
 
 /* Class initialization function for EelCanvasClass */
 static void
@@ -2336,9 +2358,13 @@ eel_canvas_class_init (EelCanvasClass *klass)
   G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT);
 #endif
 
+#if GTK_CHECK_VERSION(3, 0, 0)
+gtk_widget_class_set_accessible_type (widget_class, eel_canvas_accessible_get_type ());
+#else
 atk_registry_set_factory_type (atk_get_default_registry (),
EEL_TYPE_CANVAS,
eel_canvas_accessible_factory_get_type ());
+#endif
 }
 
 /* Callback used when the root item of a canvas is destroyed.  The user should
@@ -3424,7 +3450,7 @@ idle_handler (gpointer data)
 {
 EelCanvas *canvas;
 
-#if !GTK_CHECK_VERSION (3, 0, 0)
+#if !GTK_CHECK_VERSION(3, 0, 0)
 GDK_THREADS_ENTER ();
 #endif
 
@@ -4270,6 +4296,43 @@ eel_canvas_item_accessible_ref_state_set (AtkObject *accessible)
 return state_set;
 }
 
+#if GTK_CHECK_VERSION(3, 0, 0)
+static GType eel_canvas_item_accessible_get_type (void);
+
+typedef struct _EelCanvasItemAccessible EelCanvasItemAccessible;
+typedef struct _EelCanvasItemAccessibleClass EelCanvasItemAccessibleClass;
+
+struct _EelCanvasItemAccessible
+{
+GtkAccessible parent;
+};
+
+struct _EelCanvasItemAccessibleClass
+{
+GtkAccessibleClass parent_class;
+};
+
+G_DEFINE_TYPE_WITH_CODE (EelCanvasItemAccessible,
+ 

Bug#840574: Please backport libgo fixes for sparc64

[James Clarke]

Source: gcc-6
Version: 6.2.0-6
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Tags: patch fixed-upstream

Hi,
Could you please backport the patches listed below so that we can have a
working gccgo? They fix the (minor) issue of using the wrong syscall
number for getrandom (if code uses it), add support for sparc64's
relocations, and also the following error when running go build:

/usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
/usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1

The patches are:

https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf
(not yet pulled into gofrontend's libgo)
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd

With all but the last patch (a minor fixup after my patches), I have
been able to successfully build and run go programs on sparc64.

Regards,
James


signature.asc
Description: PGP signature

Bug#840573: unicon: DFSG-incompatible license

[Joao Eriberto Mota Filho]

Source: unicon
Severity: serious
Tags: upstream
Justification: Policy 2.2.1

Dear Maintainer,

The file unicon/ImmModules/cxterm/utils/HZtable.h has the following license:

Copyright 1994,1995 by Yongguang Zhang.  All Rights Reserved

Permission to retain, use, modify, copy, and distribute CXTERM 5.0
in source or binary and its documentation (hereafter, the Software)
for non-commercial purpose is hereby granted to you without a fee,
provided that this entire copyright and permission notice appear in
all such copies, that no charge be associated with such copies,
that distribution of derivative works (including value-added
distributions such as with additional input dictionaries or fonts)
include clarification that such added or derived parts are not from
the original Software, and that the names of the author(s) not be
used to endorse or promote such works.

THE AUTHOR(S) DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
THE AUTHOR(S) BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

There is a restriction for commercial use.

Regards,

Eriberto

Bug#840569: [Pkg-mozext-maintainers] Bug#840569: xul-ext-nosquint is dead, long live nosquint

[David Prévot]

Control: severity -1 serious

Le 12/10/2016 à 10:35, shirish शिरीष a écrit :
> Source: nosquint
> Version: 2.1.9-4
> Severity: important
> 
> Dear Maintainer,
> 
> Nosquint is dead, please remove it

Then let’s use a proper RC-severity so it gets removed from Stretch. If
someone wants to follow up and package something equivalent instead,
please step up before the freeze (i.e., soon).

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#577737: [pinentry-qt4] Re: gpg command won't use agent if the agent is configured to use pinentry-qt4

[Daniel Kahn Gillmor]

On Wed 2016-10-12 13:02:56 -0400, OmegaPhil wrote:
> Since that point, I have uninstalled pinentry-qt4 and have happily been
> using pinentry-gtk-2.
>
> Installing pinentry-qt (0.9.7-5) and switching to it via alternatives
> results in the following error dialog coming up 4 times in succession
> from Enigmail:
>
> =
>
> GnuPG cannot query your passphrase via pinentry.
>
> This is a system setup or configuration error that prevents Enigmail
> from working properly and cannot be fixed automatically.
>
> We strongly recommend that you consult our support web site at
> https://enigmail.net/faq.
>
> =
>
> The real error comes out in ~/.xsession-errors:
>
> =
>
> gpg-agent[7019]: can't connect to the PIN entry module
> '/usr/bin/pinentry': End of file
> gpg-agent[7019]: failed to unprotect the secret key: No pinentry
> gpg-agent[7019]: failed to read the secret key
> gpg-agent[7019]: command 'PKDECRYPT' failed: No pinentry

I'm still baffled. i followed exactly the steps that you did and the QT
prompt shows up for me :(

What version of enigmail are you running?  where did you get it from?

can you turn on debug-pinentry in your dirmngr.conf and see what it says?

--dkg



signature.asc
Description: PGP signature

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Philip Hands]

Hi Praveen,

I see that you are again asking for a blanket ruling, and are still
hoping to rest that ruling on the poorly defined "browserified" term.

Since this approach seems to have resulted in the very slow progress
with this subject to date, might I suggest that you could speed things
up by answering the most obvious questions in advance  e.g.:

  Which specific packages are you requesting an exception for?

  For each package:

Does it have its full source available in Debian?

Are the tools to build the source into the output available in
Debian, and if not what's missing, and what's the prospect of those
things being packaged.

To what extent would you say that it would be possible for this to be
done using tools currently in Debian?

It seems quite likely that the Release managers will want to know at
least that information in order to make a decision, and I'd guess that
you already know most of that, so expecting them to either assemble it
themselves, or ask you for it, or guess at what you really meant, seems
like a waste of their time and effort.

It will also take longer that way (and time is getting short).

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#840572: ruby-benchmark-suite: FTBFS (failing tests)

[Santiago Vila]

Package: src:ruby-benchmark-suite
Version: 1.0.0+git.20130122.5bded6-2
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_testdir -i -O--buildsystem=ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   debian/rules override_dh_auto_build
make[1]: Entering directory 
'/<>/ruby-benchmark-suite-1.0.0+git.20130122.5bded6'
dh_auto_build
dh_ruby --build
   dh_ruby --build
# build documentation
rdoc --main=README.md lib

[... snipped ...]

/usr/bin/ruby2.3 /usr/bin/gem2deb-test-runner

┌──────────────────────────────────────────────────────────────────────────────┐
│ Run tests for ruby2.3 from debian/ruby-tests.rb 
 │
└──────────────────────────────────────────────────────────────────────────────┘

RUBYLIB=/<>/ruby-benchmark-suite-1.0.0+git.20130122.5bded6/debian/ruby-benchmark-suite/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 debian/ruby-tests.rb
Loaded suite debian/ruby-tests
Started
Calculating -
   sleep 1 i/100ms
-
   sleep3.7 (±27.1%) i/s -  4 in   1.110849s
F
===
Failure:
  <4.0> -/+ <0.2> expected to include
  <3.692020327852676>.
  
  Relation:
  <<3.692020327852676> < <4.0>-<0.2>[3.8] <= <4.0>+<0.2>[4.2]>
test_ips(TestBenchmarkSuite)
/<>/ruby-benchmark-suite-1.0.0+git.20130122.5bded6/test/test_benchmark_suite.rb:18:in
 `test_ips'
 15: 
 16: assert_equal "sleep", rep.label
 17: assert_equal 4, rep.iterations
  => 18: assert_in_delta 4.0, rep.ips, 0.2
 19:   end
 20: end
===


Finished in 2.12274063 seconds.
--
1 tests, 3 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 
notifications
0% passed
--
0.47 tests/s, 1.41 assertions/s
ERROR: Test "ruby2.3" failed. Exiting.
dh_auto_install: dh_ruby --install 
/<>/ruby-benchmark-suite-1.0.0+git.20130122.5bded6/debian/tmp 
returned exit code 1
debian/rules:27: recipe for target 'override_dh_auto_install' failed
make[1]: *** [override_dh_auto_install] Error 1
make[1]: Leaving directory 
'/<>/ruby-benchmark-suite-1.0.0+git.20130122.5bded6'
debian/rules:15: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


The relevant part of the build log is included above.

There is apparently a test which tries to ensure that a certain task is 
completed
in a certain amount of time (an interval, really). This is usually not a good
idea for a Debian source package, because there is not any guarantee anywhere
that the CPU performance will remain constant during the package build.
The same machine could be doing lots of other things in parallel.

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

Thanks.

Bug#840571: python-txaio: FTBFS (ValueError: Empty module name)

[Santiago Vila]

Package: src:python-txaio
Version: 2.5.1-2
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python2,python3,sphinxdoc
   dh_testdir -i -O--buildsystem=python_distutils
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
   dh_auto_build -i -O--buildsystem=python_distutils
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
python setup.py build --force
running build

[... snipped ...]

_reraise(*ex)  # noqa
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 264, in __init__
self.result = func()
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 596, in execute
res = hook_impl.function(*args)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 882, in 
pytest_cmdline_parse
self.parse(args)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 1032, in parse
self._preparse(args, addopts=addopts)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 1003, in 
_preparse
args=args, parser=self._parser)
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 724, in __call__
return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 338, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 333, in 
_MultiCall(methods, kwargs, hook.spec_opts).execute()
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 595, in execute
return _wrapped_call(hook_impl.function(*args), self.execute)
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 253, in _wrapped_call
return call_outcome.get_result()
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 279, in get_result
_reraise(*ex)  # noqa
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 264, in __init__
self.result = func()
  File "/usr/lib/python2.7/dist-packages/_pytest/vendored_packages/pluggy.py", 
line 596, in execute
res = hook_impl.function(*args)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 928, in 
pytest_load_initial_conftests
self.pluginmanager._set_initial_conftests(early_config.known_args_namespace)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 287, in 
_set_initial_conftests
self._try_load_conftest(current)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 295, in 
_try_load_conftest
self._getconftestmodules(x)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 315, in 
_getconftestmodules
mod = self._importconftest(conftestpath)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 351, in 
_importconftest
self.consider_conftest(mod)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 375, in 
consider_conftest
self.consider_module(conftestmodule)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 385, in 
consider_module
self._import_plugin_specs(plugins)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 392, in 
_import_plugin_specs
self.import_plugin(import_spec)
  File "/usr/lib/python2.7/dist-packages/_pytest/config.py", line 407, in 
import_plugin
__import__(importspec)
ValueError: Empty module name
debian/rules:14: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The relevant part of the build log is included above.

If you really need the full build log, just say so, and I'll attach it,
but a similar error may be found here in both testing and unstable:

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

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is 

Bug#629944: kvpnc: probably not using it the right way.

[Raúl Sánchez Siles]

  Hello:

  Regarding the bug you reported, I think that you used kvpnc the wrong way. 
It looks it needs root permissions, but just doing "su" and running it from a 
console will fail due to a number of reasons unless you are aware of the 
implications of doing so.

  In my humble opinion, you should stick to giving root password to kvpnc or 
using an alternative method for running it as root.

  Having said all this, I would say this is not really a bug. If you agree 
with me feel free to comment it out and eventually send an email to 
629...@bugs.debian.org in order to close this bug.

  Regards,
-- 
 Raúl Sánchez Siles
->Proud Debian user<-
Linux registered user #416098

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

Bug#818962: fix the php-script-but-no-phpX-cli-dep error

[Antonio Ospite]

On Wed, 12 Oct 2016 21:24:00 +0200
Mathieu Parent  wrote:

> Hello lintian maintainers,
> 
> Can you please review the attached patch?
>

Hi Mathieu,

first of all, thanks for working on that.

I am not a lintian developer, but I am the one of the first person to
have noticed the problem, I'll add some comments and questions below.

I think a variant of this should really go in before the next stable
debian release.

Thanks,
   Antonio


> From efa0b0d42840867152958227251c147917e21fec Mon Sep 17 00:00:00 2001
> From: Mathieu Parent 
> Date: Thu, 3 Mar 2016 10:50:36 +0100
> Subject: [PATCH] There is now a php-cli package

Describe better the issue in the short commit message, like for
instance:

"Error when a package has a php script but does not depend on php-cli"

This is what Ondřej Surý thinks lintian should do.

And maybe add some more details in the long commit message, something
like

"Furthermore, when adding the missing dependency packages must not
depend on phpX-cli but rather on php-cli"

And maybe add a link to this bug report number.

> 
> ---
>  checks/scripts.desc| 11 +--
>  data/scripts/versioned-interpreters|  2 +-
>  t/tests/legacy-scripts/debian/debian/rules |  4 ++--
>  t/tests/legacy-scripts/tags|  2 +-
>  4 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/checks/scripts.desc b/checks/scripts.desc
> index 12a642b..cd7dfb4 100644
> --- a/checks/scripts.desc
> +++ b/checks/scripts.desc
> @@ -220,13 +220,12 @@ Info: Packages that use mawk scripts must depend on the 
> mawk package.
>  Tag: php-script-but-no-phpX-cli-dep

Shouldn't this become "php-script-but-no-php-cli-dep" ?

>  Severity: important
>  Certainty: certain
> -Info: Packages with PHP scripts must depend on a phpX-cli package such as
> - php5-cli.  Note that a dependency on a php-cgi package (such as php5-cgi)
> - is needlessly strict and forces the user to install a package that isn't
> - needed.
> +Info: Packages with PHP scripts must depend on the php-cli package.
> + Note that a dependency on a php-cgi package (such as php7.0-cgi) is 
> needlessly
> + strict and forces the user to install a package that isn't needed.
>   .
> - In some cases a weaker relationship, such as Suggests or Recommends, will
> - be more appropriate.
> + In some cases a weaker relationship, such as Suggests or Recommends, will be
> + more appropriate.
>   .
>   Lintian can only recognize phpX-cli dependencies for values of X that it
>   knows are available in the archive.  You will get this warning if you
> diff --git a/data/scripts/versioned-interpreters 
> b/data/scripts/versioned-interpreters
> index fff44c2..3b2fa00 100644
> --- a/data/scripts/versioned-interpreters
> +++ b/data/scripts/versioned-interpreters
> @@ -73,7 +73,7 @@ guile   => /usr/bin, guile-([\d.]+), guile-$1, 1.6 1.8,
>  jruby   => /usr/bin, jruby([\d.]+), jruby$1, 1.0 1.1 1.2
>  lua => /usr/bin, lua([\d.]+), lua$1, 40 50 5.1 5.2
>  octave  => /usr/bin, octave([\d.]+), octave$1, 3.0 3.2
> -php => /usr/bin, php(\d+), php$1-cli, 5, @NO_DEFAULT_DEPS@
> +php => /usr/bin, php([\d.]+), php$1-cli, 7.0, php-cli

Does this actually _forbid_ php7.0-cli dependencies?
I am asking because I don't know the meaning of the fields in this file.

>  pike=> /usr/bin, pike([\d.]+), pike$1 | pike$1-core, 7.6 7.8, 
> @NO_DEFAULT_DEPS@
>  python  => /usr/bin, python([\d.]+), python$1:any | python$1-minimal:any, 
> 2.7, @SKIP_UNVERSIONED@
>  ruby=> /usr/bin, ruby([\d.]+), ruby$1, 1.8 1.9, @SKIP_UNVERSIONED@
> diff --git a/t/tests/legacy-scripts/debian/debian/rules 
> b/t/tests/legacy-scripts/debian/debian/rules
> index 25b6f9e..a615bd6 100755
> --- a/t/tests/legacy-scripts/debian/debian/rules
> +++ b/t/tests/legacy-scripts/debian/debian/rules
> @@ -63,8 +63,8 @@ binary-indep:
>   install -m 755 init-lsb-other $(tmp)/etc/init.d/lsb-other
>  
>   install -m 755 phpfoo $(tmp)/usr/share/scripts/
> - sed 's/php$$/php5/' phpfoo > $(tmp)/usr/share/scripts/php5foo
> - chmod 755 $(tmp)/usr/share/scripts/php5foo
> + sed 's/php$$/php7.0/' phpfoo > $(tmp)/usr/share/scripts/php7.0foo
> + chmod 755 $(tmp)/usr/share/scripts/php7.0foo
>

What does this test do? Can we skip it if we do not want to allow
phpX-cli dependencies?

>   echo "#!/usr/bin/perl" >> $(tmp)/usr/share/scripts/foobar.in
>   chmod 644 $(tmp)/usr/share/scripts/foobar.in
> diff --git a/t/tests/legacy-scripts/tags b/t/tests/legacy-scripts/tags
> index 0436902..d93069d 100644
> --- a/t/tests/legacy-scripts/tags
> +++ b/t/tests/legacy-scripts/tags
> @@ -14,7 +14,7 @@ E: scripts: init.d-script-needs-depends-on-lsb-base 
> etc/init.d/skeleton (line 40
>  E: scripts: missing-dep-for-interpreter jruby => jruby | jruby1.0 | jruby1.1 
> | jruby1.2 (usr/bin/jruby-broken)
>  E: scripts: missing-dep-for-interpreter lefty => graphviz (usr/bin/lefty-foo)
>  E: scripts: 

Bug#837281: manila-ui: FTBFS: compressor.exceptions.OfflineGenerationError: No template loaders defined. You must set TEMPLATE_LOADERS in your settings or set 'loaders' in your TEMPLATES dictionary.

[Santiago Vila]

found 837281 2.5.1-0
thanks

I can still reproduce the error reported by Lucas in this version.

I attach a build log for 2.5.1-0.

I think this could be a bug in openstack-dashboard, one of the
build-depends. If this is really the case, please use reassign and
affects so that we can see the bug in the page for src:manila-ui and
this way we avoid filing duplicate bugs.

Thanks.

manila-ui_2.5.1-0_amd64-20161012T200103Z.gz
Description: application/gzip

Bug#840524: sardana: ipython transition: Please help assess the situation

[PICCA Frederic-Emmanuel]

sardana 2.1.1-1~exp1 available into experimental is supporting python-qtconsole 
and ipython5
so this is not a problem for the transition.

Cheers

Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications

[Thomas Pircher]

On 2016-10-11 22:22, Gianfranco Costamagna wrote:

I see you forgot to probably run dh_clean
(I see debian/autoreconf.before and debian/autoreconf.after files)


D'oh. They were leftovers from a previous build and are gone now.


and I still see a libcgicc3-dev package (instead of libcgicc-dev)


Yes, that was my mistake; I misunderstood your suggestion and made 
libcgicc-dev a virtual package.
The last update on mentors now consists of libcgicc3, libcgicc-dev and 
libcgicc-doc.


Thanks,
Thomas

Bug#827061: transition: openssl

[Kurt Roeckx]

On Sun, Sep 18, 2016 at 09:33:43PM +0200, Kurt Roeckx wrote:
> On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote:
> > On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote:
> > > On 11/06/16 20:59, Kurt Roeckx wrote:
> > > > OpenSSL will soon release a new upstream version with a new
> > > > soname.  This new version will break various packages, see:
> > > > https://lists.debian.org/debian-devel/2016/06/msg00205.html
> > > > 
> > > > I'm currently not sure when the release will be ready.  I would
> > > > like to start this transition as soon as possible, but probably
> > > > after it's actually released.  I don't expect this to take long.
> > > 
> > > 405 packages failed to build during your test rebuild AFAICS. That's 
> > > going to
> > > take some time to sort out...
> > > 
> > > > If I'm ready to upload it to unstable, can I start this
> > > > transition?  Are there things you want me to do?
> > > 
> > > Please upload to experimental first and let us know when that's happened.
> > 
> > It's in experimental already.  The test suite only fails
> > on hurd, for some reason it's not finding the engine.  I still
> > need to look at that.
> > 
> > > We will also need bugs filed, with severity important for now.
> > 
> > Sure, I'll start on that if I find the time.
> > 
> > > Also it may be useful if you can get us the intersection between the 
> > > packages
> > > that failed to build and the key packages[1] (see "Final list of 3302 key 
> > > source
> > > packages" in that file).
> > 
> > That actually seem to be 3247 source package.  Anyway, the list is
> > below.
> 
> So OpenSSL 1.1.0 was released about 3 weeks ago.  Since then we've
> been working on the key packages, to get them to build with
> OpenSSL 1.1.0.  You can see that status of that at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org
> 
> Most of the packages are really trivial to fix, but some do
> require that you fix the same issues in many different places and
> it can take some time to fix it.
> 
> I would like to motivate more people to work on this by either
> marking those bugs as RC, or uploading it to unstable.

Ping.


Kurt

Bug#827953: maxima: Uses too much memory to build

[Camm Maguire]

Greetings!

Santiago Vila  writes:

> On Sun, 2 Oct 2016, Camm Maguire wrote:
>
>> Greetings!  I just wanted to keep you abreast of the latest upload.
>> I've put in an improvement which I hope will allow better use of the
>> ram available without running into the fork/exec faults we had seen in
>> some configurations.  This does not address the question of 'how much
>> memory should we attempt to make use of', but you may find this upload
>> more robust nonetheless.  GCL_MEM_MULTIPLE defaults back to 1.0 from
>> 0.85 without apparent issue.
>> 
>> Feedback appreciated.
>
> Hello.
>
> I finally tested maxima_5.38.1-2 today.
>

Thanks!

> On a machine with 6GB RAM and 4 GB swap, memory usage was about
> 7500 MB (1500 MB more than the available RAM).
>
> On a machine with 3GB RAM and 4 GB swap, memory usage was about
> 3700 MB (700 MB more than the available RAM).
>
> I'm still measuring memory usage with Committed_AS, by taking note of
> its value during the build and substracting the value before the build
> starts.
>
> In your previous email, you suggest that I don't use Committed_AS
> to measure memory usage, but something else.
>

Because the linux docs say this is an anticipated worst case guess, not
the amount of memory in use.

> I'm not sure what else I could use instead which is better than
> Committed_AS, and I fear that the more memory I have available, the
> more memory would maxima use as well, just as it happens with
> Committed_AS, so are you sure that using something else other
> than Committed_AS would really fix my problem?

If you use the variables I output in my post, I think you will find that
the build does not swap.

>
> Do you have a suggestion about which other parameter in /proc/meminfo
> would be more suitable than Committed_AS?

These were the variables I output in my sample build.

>
> Maybe this Committed_AS value being higher than the available RAM is
> "normal and expected", but the way I see it, it seems part of a
> general problem called "overcommit".
>

Indeed, all unices nowadays do this.

> The question would be: How much overcommit should we reasonably expect
> from a package when it's being built?
>

I think it is reasonable that a program make use of the available ram as
long as it stays out of swap.

Take care,

> [ I still have to read your previous email in detail, this is just a
>   first reply to tell my experience with maxima_5.38.1-2 ]
>
> Thanks.
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#840570: xfce4-power-manager: Attempts to suspend again after opening lid

[Martin Schwenke]

Package: xfce4-power-manager
Version: 1.4.4-4
Severity: important

Dear Maintainer,

I suspend my laptop by closing the lid.  When I resume, by opening the
lid, I then unlock the screen and I am greeted with a dialog saying:

  Authentication is required for suspending the system.

I can cancel this without any issues, except a notification saying:

  Power manager

  GDBus.Error.org.freedesktop.DBus.Error.NoReply: Method call timed out

This is slightly better than the situation before my last reboot,
where the laptop re-suspended as soon as it had resumed after opening
the lid.  I then had to press the Fn key to get it to resume again.

I can see that xfce4-power-manager has not been updated for over a
year on my system.  Therefore, I assume that xfce4-power-manager
hasn't been updated to deal with recent changes in systemd.  Or should
I file this bug against systemd?

Thanks...

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

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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.24-3
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.10-1
ii  libdbus-glib-1-2  0.108-1
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.0-2
ii  libgtk2.0-0   2.24.31-1
ii  libnotify40.7.6-2
ii  libpango-1.0-01.40.3-2
ii  libpangocairo-1.0-0   1.40.3-2
ii  libupower-glib3   0.99.4-4
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxfce4ui-1-04.12.1-2
ii  libxfce4util7 4.12.1-2
ii  libxfconf-0-2 4.12.0-3
ii  libxrandr22:1.5.0-1
ii  upower0.99.4-4
ii  xfce4-power-manager-data  1.4.4-4

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd   231-9
ii  xfce4-power-manager-plugins  1.4.4-4

xfce4-power-manager suggests no packages.

-- no debconf information

peace & happiness,
martin

Bug#840569: xul-ext-nosquint is dead, long live nosquint

[shirish शिरीष]

Source: nosquint
Version: 2.1.9-4
Severity: important

Dear Maintainer,

Nosquint is dead, please remove it and if a replacement is needed
please add no-squint plus - see https://urandom.ca/nosquint about the
death of nosquint and
https://addons.mozilla.org/en-US/firefox/addon/nosquint-plus/ to get
info. about nosquint-plus.

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

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


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#840561: pidgin-blinklight: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

[Joachim Breitner]
> Hi,
>
> JFTR: I am happy to apply patches here, but do not plan to work on this
> soonish.
>
> (I no longer have hardware supported by pidgin-blinklight, and am happy
> to share responsibilities.)

Right.  I'm not a candidate. :)

I'm trying to migrate the isenkram hardware to package mapping database
from a text file in the isenkram package to the appstream database, and
pidgin-blinklight is one of the many packages on my list. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#827395: get less on 49.0. at my end -

[shirish शिरीष]

Package: firefox
Version: 49.0-4
Severity: normal

Dear Maintainer,
I used wireshark to find out as can be seen at
http://unix.stackexchange.com/questions/315315/how-to-get-list-of-sites-domains-linked-to-in-wireshark

and in a new profile in firefox 49.0 the situation doesn't seem to be
so dire, although have no idea where the 2000+ packets get sent in the
moment I put a fresh profile and have no add-ons on the browser.

Still I got the following domains to which firefox talks at booting
up/starting up .

vassg142.ocsp.omniroot.com  2
 ocsp.digicert.com   13
 clients1.google.com 3
  /ocsp  3

The numbers are the count, guessing it's other cookies or whatever in
wireshark it means for count in requests.

-- Package-specific info:

-- Extensions information
Name: ColorfulTabs
Location: /usr/share/xul-ext/colorfultabs
Package: xul-ext-colorfultabs
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: DOM Inspector
Location: /usr/share/xul-ext/dom-inspector
Package: xul-ext-dom-inspector
Status: enabled

Name: Firefox OS 2.2 Simulator
Location: ${PROFILE_EXTENSIONS}/fxos_2_2_simula...@mozilla.org
Status: enabled

Name: Flash Video Downloader - YouTube HD Download [4K]
Location: ${PROFILE_EXTENSIONS}/artur.dubo...@gmail.com
Status: enabled

Name: fokus
Location: ${PROFILE_EXTENSIONS}/fo...@aaronraimist.com.xpi
Status: enabled

Name: HTTP/2 and SPDY indicator
Location: ${PROFILE_EXTENSIONS}/spdyindica...@chengsun.github.com.xpi
Status: enabled

Name: HTTPS Everywhere
Location: /usr/share/xul-ext/https-everywhere
Package: xul-ext-https-everywhere
Status: enabled

Name: Live HTTP headers(Fixed By Danyial.com)
Location: /usr/share/xul-ext/livehttpheaders
Package: xul-ext-livehttpheaders
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: NoSquint Plus
Location: ${PROFILE_EXTENSIONS}/zoomlevelp...@zoomlevelplus.net.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: RequestPolicy Continued
Location: /usr/share/xul-ext/requestpolicy
Package: xul-ext-requestpolicy
Status: enabled

Name: SSleuth
Location: ${PROFILE_EXTENSIONS}/ssle...@github.xpi
Status: enabled

Name: Tree Style Tab
Location: /usr/share/xul-ext/treestyletab
Package: xul-ext-treestyletab
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

Name: WOT
Location: /usr/share/xul-ext/wot
Package: xul-ext-wot
Status: enabled

-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled


-- Addons package information
ii  firefox49.0-4   amd64Mozilla Firefox web browser
ii  gnome-shell3.22.0-1+b1  amd64graphical shell for the GNOME des
ii  icedtea-8-plug 1.6.2-3  amd64web browser plugin based on OpenJ
ii  rhythmbox-plug 3.4.1-2  amd64plugins for rhythmbox music playe
ii  xul-ext-colorf 31.0.7+dfsg- all  Color tabs differently and make t
ii  xul-ext-dom-in 1:2.0.16-2   all  tool for inspecting the DOM of we
ii  xul-ext-https- 5.2.4-1  all  extension to force the use of HTT
ii  xul-ext-liveht 0.17.1-2 all  add information about HTTP header
ii  xul-ext-reques 1.0.0~beta12 all  improve your browsing: more priva
ii  xul-ext-treest 0.18.2016090 all  Show browser tabs like a tree
ii  xul-ext-wot20151208-2   all  show which websites are trustwort

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

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

Versions of packages firefox depends on:
ii  debianutils   4.8
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-3
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.10-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-11
ii  libgdk-pixbuf2.0-02.36.0-1

Bug#839731: jessie-pu: package mpg123/1.20.1-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-10-08 at 21:21 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-10-04 at 12:01 +0100, James Cowgill wrote:
> > A security issue was reported against mpg123 in bug #838960. Since it
> > was marked no-DSA by the security team, it needs a normal jessie-pu
> > update to fix it in jessie.
> > 
> > The debdiff is attached. I've tested it on jessie against the testcase
> > provided in the upstream bug report (https://mpg123.org/bugs/240).
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#840188: jessie-pu: package tevent/0.9.25-0+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2016-10-11 at 22:43 +, Jelmer Vernooij wrote:
> On Tue, Oct 11, 2016 at 09:15:22PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Sun, 2016-10-09 at 12:15 +, Jelmer Vernooij wrote:
> > > I would like to update tevent in jessie to 0.9.28. This is necessary,
> > > because the proposed version of Samba depends on new features
> > > (https://bugs.debian.org/836795).
> > 
> > With the changelog distribution finalised, please go ahead.
> > 
> > I assume that the samba update will have its libtevent-dev build-dep
> > version updated to ensure that 0.9.28 is used.
> Thanks, uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#839927: jessie-pu: package rawtherapee/4.2-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-10-08 at 21:11 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2016-10-07 at 00:26 +0200, Philip Rinn wrote:
> > Sorry, I didn't attach the debdiff, it was only a 'git diff ...' Now I 
> > attached
> > the real debdiff.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#840127: jessie-pu: package libio-socket-ssl-perl/2.002-2+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-10-09 at 07:29 +0200, Salvatore Bonaccorso wrote:
> Hi Adam,
> 
> On Sat, Oct 08, 2016 at 09:10:33PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Sat, 2016-10-08 at 17:37 +0200, Salvatore Bonaccorso wrote:
> > > We were asked if #839576 can be fixed in stable as well, it is already
> > > addressed in unstable back with the 2.017-1 upload, which caused
> > > problems for the user with ACL's set on the SSL_key_file.
> > > 
> > > Attached is the proposed debdiff. Would it be acceptable for an
> > > upcoming jessie point release?
> > 
> > Please go ahead.
> 
> Thanks! Uploaded.

Flagged for acceptance; thanks.

Regards,

Adam

Bug#839814: jessie-pu: package sympa/6.1.23~dfsg-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-10-09 at 07:22 +0200, Salvatore Bonaccorso wrote:
> Hi Adam,
> 
> On Sat, Oct 08, 2016 at 09:18:50PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2016-10-05 at 12:56 +0200, Salvatore Bonaccorso wrote:
> > > Sympa is affected by a nasty bug when used under systemd, that after
> > > logrotation with the original logrotate setup in jessie, sympa is in a
> > > confused state. This is tracked as #804066 and was fixed in unstable
> > > already with 6.2.16~dfsg-1.
> > > 
> > > I would like to propose that this is fixed as well for stable,
> > > attached is the proposed debidff, where I needed to use
> > > reload-or-try-reload (try-reload-or-restart in unstable).
> > > 
> > > Does this look acceptable for the upcoming jessie point release?
> > 
> > Please go ahead.
> 
> Thanks a lot, just uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#840472: apt-listbugs: [INTL:de] Updated German debconf translation

[Francesco Poli]

On Tue, 11 Oct 2016 22:56:31 +0200 Chris Leick wrote:

[...]
> Hi,
> 
> please find attached the updated german debconf translation of apt-listbugs.

Hello Chris,
thanks for the update!

I have a question:

  #: ../lib/aptlistbugs/logic.rb:854
  msgid "tags"
  msgstr "Markierungen"

but

  #: ../lib/aptlistbugs/logic.rb:54
  msgid " -T : Filter bugs by tags you want to see.\n"
  msgstr " -T : filtert nach Kennzeichnungen, die Sie sehen 
wollen.\n"

Could you please suggest a way to improve the consistency of the
translation, by using the same German word for the English "tags"?
If you tell me which string I should modify and how, I can apply the
fix to the .po file by myself.




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


pgpccFHjlN7ei.pgp
Description: PGP signature

Bug#840568: caja: Impossible to have speech feedback when items are set in icons

[Jean-Philippe MENGUAL]

Package: caja
Version: 1.16.0-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Switch from 1.12 to 1.14. Just fixed in 1.16. I use Orca 3.20, 3.22 as well.

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

1. Enable accessibility in Preferences.
2. Enable Orca in Universal Access
3. `est if it works: alt-f1, arrow keys should speak "Accessories" and other
items.
4. alt-ctrl-d
5. Press arrow keys.
The focus moves, but no feedback.
6. Open Home folder.
7. Try browsing files with icon view. No feedback.
8. Try browsing with list or compact view, Orca speaks.

   * What was the outcome of this action?

No sound on desktop or in file manager if icon view is active.

   * What outcome did you expect instead?

Should speak. Otherwise, MATE desktop is not accessible for disabled users with
assistive techno.

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

Here's a patch, accepted upstream, but I fixed a typo (inherritance) in Debian's
patch.

See bug 590 upstream for detailed explanation by Luke about how he fixed the
issue.

Thanks


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

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

Versions of packages caja depends on:
ii  caja-common   1.16.0-1
ii  desktop-file-utils0.23-1
ii  gvfs  1.30.0-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-3
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libcaja-extension11.16.0-1
ii  libexempi32.3.0-2
ii  libexif12 0.6.21-2
ii  libgail-3-0   3.22.1-1
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.0-2
ii  libglib2.0-data   2.50.0-2
ii  libgtk-3-03.22.1-1
ii  libice6   2:1.0.9-1+b1
ii  libmate-desktop-2-17  1.16.0-1
ii  libpango-1.0-01.40.3-2
ii  libpangocairo-1.0-0   1.40.3-2
ii  libselinux1   2.5-3
ii  libsm62:1.2.2-1+b1
ii  libstartup-notification0  0.12-4
ii  libunique-3.0-0   3.0.2-2
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.4+dfsg1-2
ii  libxrender1   1:0.9.9-2
ii  mate-desktop  1.16.0-1
ii  shared-mime-info  1.7-1

Versions of packages caja recommends:
ii  gvfs-backends  1.30.0-1

Versions of packages caja suggests:
ii  engrampa1.16.0-1
pn  gstreamer1.0-tools  
pn  meld

-- no debconf information
>From 076b8582e4c834db60070fe441d7977716637721 Mon Sep 17 00:00:00 2001
From: Luke Yelavich 
Date: Sat, 8 Oct 2016 12:22:45 +1100
Subject: [PATCH] Fix accessible object inheritance when used with GTK >= 3.2

Also disable eel accessibility code that is not needed.

Fixes https://github.com/mate-desktop/caja/issues/590
---
 eel/eel-accessibility.c   |  5 ++-
 eel/eel-accessibility.h   |  2 +
 eel/eel-canvas.c  | 84 +--
 eel/eel-canvas.h  | 20 +
 eel/eel-editable-label.c  | 55 ++-
 eel/eel-labeled-image.c   | 77 
 libcaja-private/caja-icon-container.c | 57 
 src/caja-zoom-control.c   | 48 
 8 files changed, 343 insertions(+), 5 deletions(-)

diff --git a/eel/eel-accessibility.c b/eel/eel-accessibility.c
index 707756d..a344bd8 100644
--- a/eel/eel-accessibility.c
+++ b/eel/eel-accessibility.c
@@ -63,6 +63,7 @@ eel_accessibility_set_up_label_widget_relation (GtkWidget *label, GtkWidget *wid
  *
  * Return value: the registered type, or 0 on failure.
  **/
+#if !GTK_CHECK_VERSION(3, 2, 0)
 GType
 eel_accessibility_create_derived_type (const char *type_name,
GType existing_gobject_with_proxy,
@@ -113,7 +114,7 @@ eel_accessibility_create_derived_type (const char *type_name,
 
 return type;
 }
-
+#endif
 
 static GQuark
 get_quark_accessible (void)
@@ -207,6 +208,7 @@ eel_accessibility_destroy (gpointer data,
  *
  * Return value: @atk_object.
  **/
+#if !GTK_CHECK_VERSION(3, 2, 0)
 AtkObject *
 eel_accessibility_set_atk_object_return (gpointer   object,
 AtkObject *atk_object)
@@ -224,6 +226,7 @@ eel_accessibility_set_atk_object_return (gpointer   object,
 
 return atk_object;
 }
+#endif
 
 static GailTextUtil *
 get_simple_text (gpointer object)
diff --git a/eel/eel-accessibility.h b/eel/eel-accessibility.h
index 45514c9..b4ca8cb 

Bug#840534: #Pages scan option always defaults to '1'

[martin f krafft]

also sprach Jeffrey Ratcliffe  [2016-10-12 21:43 
+0200]:
> The option in Preferences is called "Allow batch scanning from
> flatbed". Selecting it should prevent it always defaulting to
> #pages=1.

Aha. That's disabled for me… but as I said, I have an ADF anyway.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"it is dangerous to be right when the government is wrong."
 -- voltaire


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

Bug#840534: #Pages scan option always defaults to '1'

[Jeffrey Ratcliffe]

On 12 October 2016 at 21:29, martin f krafft  wrote:
> Actually, I'm not. Well, it's a flatbed with an ADF. I also don't
> see any such option in preferences, and "All" *is* an option in the
> scan dialog, it's just not selected by default, as it used to be.

The option in Preferences is called "Allow batch scanning from
flatbed". Selecting it should prevent it always defaulting to
#pages=1.

I take your point, however. If the default scan options use the ADF,
and the previous scan was with #pages=all, then that should be
selected the next time the program is started. I'll take a look.

Bug#840567: RM: statsmodels [arm64 armel armhf mips mipsel powerpc s390x hppa mips64el ppc64] -- ROM; dependency (pandas) is missing on those archs now

[Yaroslav Halchenko]

Package: ftp.debian.org
Severity: normal

pandas was removed in #825103 and now statsmodels is not buidlable/installable
on those platforms (although was available before)

Thank you in advance

Note: this was a request for a partial removal from testing, converted in one 
for unstable

Bug#840566: bash: Bash as root login shell ends with xmalloc error

[Rajko Albrecht]

Package: bash
Version: 4.4-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Tried to login on server or "su -" but got only 

-su: xmalloc: cannot allocate 80008 bytes (1626112 bytes allocated)

so login isn't possible as root anymore. When running just "su" eg. bash not as 
login shell it first works. 


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

1. Flushed .bash_history of user root - login works. But now no execution of 
any command is possible, ends with the xmalloc error.
2. run bash not as login-shell. Now all is working. 
3. tried as normal user. There is no problem.


   * What was the outcome of this action?

Root user may just use other shell like dash as login shell

   * What outcome did you expect instead?

Expect that root-user may use bash as login-shell


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bash depends on:
ii  base-files   9.6
ii  dash 0.5.8-2.3
ii  debianutils  4.8
ii  libc62.24-3
ii  libtinfo56.0+20160917-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#837232: statsmodels: FTBFS: Tests failures

[Yaroslav Halchenko]

On Tue, 11 Oct 2016, Ole Streicher wrote:

> DearYaroslav,

> could you ensure that the "statmodels" package migrate to testing, so
> that the dependent packages will not be removed?

help is always welcome -- I bless you Ole for any help you could give to
make that happen ;)

filed an RM for those platforms

> The package is uninstallable of a number of platforms in the new
> release, so they should probably removed from testing.

I will deal with fixing up pandas  now
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#840546: Stable Debdiff For CVE-2016-7966/kdepimlibs

[Moritz Muehlenhoff]

B0;115;0cOn Wed, Oct 12, 2016 at 02:56:06PM -0400, Scott Kitterman wrote:
> Proposed update attached.  It is the exact upstream commit that resolved this 
> issue upstream (relevant code is unchanged from stable) and I have the fix 
> running locally.  I do not have an example of the exploit to verify the 
> adequacy of the fix, but it does appear to be regression free.
> 
> I have an upload for jessie-security prepared.

Looks fine, please build with "-sa" and upload to security-master.

Cheers,
Moritz

Bug#840546: Stable Debdiff For CVE-2016-7966/kdepimlibs

[Salvatore Bonaccorso]

Hi Scott,

On Wed, Oct 12, 2016 at 02:56:06PM -0400, Scott Kitterman wrote:
> Proposed update attached.  It is the exact upstream commit that resolved this 
> issue upstream (relevant code is unchanged from stable) and I have the fix 
> running locally.  I do not have an example of the exploit to verify the 
> adequacy of the fix, but it does appear to be regression free.
> 
> I have an upload for jessie-security prepared.

Thanks, please do upload in this case. Remember to build with -sa,
since it's the first upload dak on security-master seens for
kdepimlibs.

Regards,
Salvatore

Bug#840564: engrampa doesn't need "--with-gtk=3.0" on debian rules

[ZenWalker]

Package: engrampa
Version: 1.16.0-1
Severity: normal

Dear Maintainer,

you can see the commit:

https://github.com/mate-
desktop/engrampa/commit/9bf273fb9b31f878fe597c605a8faa18d220c37a

engrampa was migrated to gtk3 and doesn't need "--with-gtk=3.0" on debian rules



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

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

Versions of packages engrampa depends on:
ii  bzip21.0.6-8
ii  caja-common  1.16.0-1
ii  engrampa-common  1.16.0-1
ii  gzip 1.6-5
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-3
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcaja-extension1   1.16.0-1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.0-2
ii  libgtk-3-0   3.22.1-1
ii  libjson-glib-1.0-0   1.2.2-1
ii  libmagic11:5.28-4
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  p7zip-full   16.02+dfsg-1
ii  tar  1.29b-1

Versions of packages engrampa recommends:
ii  gvfs 1.30.0-1
ii  mate-icon-theme  1.16.0-1
ii  unzip6.0-20
ii  xz-utils 5.1.1alpha+20120614-2.1
ii  zip  3.0-11

Versions of packages engrampa suggests:
pn  arj  
ii  binutils 2.27-8
ii  cpio 2.11+dfsg-5
ii  lhasa [lha]  0.3.1-1
pn  lzip 
pn  lzop 
pn  ncompress
pn  rar  
pn  rpm2cpio 
pn  rzip 
pn  sharutils
pn  unace
pn  unalz
ii  unar 1.10.1-1+b1
ii  xz-utils [lzma]  5.1.1alpha+20120614-2.1
pn  zoo  

-- no debconf information

Bug#840565: [Fwknop] wget not detected

[Franck Joncourt]

Package: fwknop
Version: 2.6.9-1
Severity: normal

Currently wget is not a build-dep, and thus when trying to resolve the
client IP address with -R an error occurs:

$ fwknop -R
[*] Use --wget-cmd  to specify path to the wget command.

To solve this, wget must be added as a BD to be found by autotool and as
a dependency.

Note: A reminder until I can access collab-maint and fix this.

--
Franck



signature.asc
Description: OpenPGP digital signature

Bug#840534: #Pages scan option always defaults to '1'

[martin f krafft]

also sprach Jeffrey Ratcliffe  [2016-10-12 20:28 
+0200]:
> I expect that you are using a flatbed scanner. It was requested that
> it should only be possible to scan 1 page from the flatbed. You can
> disable this in Edit/Preferences.

Actually, I'm not. Well, it's a flatbed with an ADF. I also don't
see any such option in preferences, and "All" *is* an option in the
scan dialog, it's just not selected by default, as it used to be.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
DISCLAIMER: this entire message is privileged communication, intended
for the sole use of its recipients only. If you read it even though
you know you aren't supposed to, you're a poopy-head.


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

Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps

[Matthew Gabeler-Lee]

Package: mtr
Version: 0.86-1+b1
Severity: wishlist

A new upstream release 0.87 has a fix (of sorts) for the problem where MTR
will not trace a successful path that has more than five non-responding
hops.  I say fix "of sorts" because the default limit for this has not been
changed, but it is now possible to override that default on the command
line.  FWIW the MTR git shows that an upcoming not-yet-released version also
increases the default to a more reasonable value.

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

Kernel: Linux 4.7.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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mtr depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-3
ii  libcairo21.14.6-1+b1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.0-2
ii  libgtk2.0-0  2.24.31-1
ii  libncurses5  6.0+20160917-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpangoft2-1.0-01.40.3-2
ii  libtinfo56.0+20160917-1

mtr recommends no packages.

mtr suggests no packages.

-- no debconf information

Bug#840561: pidgin-blinklight: Please announce supported hardware using AppStream

[Joachim Breitner]

Hi,

JFTR: I am happy to apply patches here, but do not plan to work on this
soonish.

(I no longer have hardware supported by pidgin-blinklight, and am happy
to share responsibilities.)

Greetings,
Joachim


Am Mittwoch, den 12.10.2016, 21:12 +0200 schrieb Petter Reinholdtsen:
> Package: pidgin-blinklight
> Version: 0.11.1-3
> Severity: wishlist
> User: p...@hungry.com
> Usertags: appstream-modalias
> 
> Hi.
> 
> The pidgin-blinklight package is one of the packages in the Debian
> archive that
> should be proposed for installation when a given hardware dongle is
> inserted or available.  Thanks to the appstream system, this can now
> be
> announced in a way other tools can use and act on.  I've written the
> isenkram system to ask the current user if hardware specific packages
> should be installed when a new dongle is installed or already present
> on
> a machine, and isenkram now uses appstream as one source for hardware
> to
> package mappings.
> 
> You can read more about this on my blog, 
> http://people.skolelinux.org/pere/blog/Using_appstream_with_ise
> nkram_to_install_hardware_related_packages_in_Debian.html >.
> 
> Instructions on how to create the metadata XML file can be found in
> https://wiki.debian.org/AppStream/Guidelines >.
> 
> It would be great if you could add an appstream metainfo file to the
> pidgin-blinklight package, with content similar to this:
> 
>   
>   
>    [...]
>    
>   dmi:*:pn*:pvrThinkPad*:rvn*
>    
>   
> 
> If there are other hardware ids or kernel modules also supported by
> the
> package, please add those too. :)
> 
> 
-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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

Bug#840562: libjs-jquery-treetable: Please update jquery-treetable to upstream release 3.2.0

[Jan-Pascal van Best]

Package: libjs-jquery-treetable
Severity: normal

Hi,

The version of jquery-treetable in Debian is quite old, and is missing several
features and bugfixes implemented in newer upstream releases. Please update the
package to the latest upstream release (currently 3.2.0).

Thank you!

Jan-Pascal


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (700, 'stable'), (300, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-906-amd64 (SMP w/4 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)

Bug#818962: fix the php-script-but-no-phpX-cli-dep error

[Mathieu Parent]

Hello lintian maintainers,

Can you please review the attached patch?

Thanks

-- 
Mathieu
From efa0b0d42840867152958227251c147917e21fec Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Thu, 3 Mar 2016 10:50:36 +0100
Subject: [PATCH] There is now a php-cli package

---
 checks/scripts.desc| 11 +--
 data/scripts/versioned-interpreters|  2 +-
 t/tests/legacy-scripts/debian/debian/rules |  4 ++--
 t/tests/legacy-scripts/tags|  2 +-
 4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/checks/scripts.desc b/checks/scripts.desc
index 12a642b..cd7dfb4 100644
--- a/checks/scripts.desc
+++ b/checks/scripts.desc
@@ -220,13 +220,12 @@ Info: Packages that use mawk scripts must depend on the mawk package.
 Tag: php-script-but-no-phpX-cli-dep
 Severity: important
 Certainty: certain
-Info: Packages with PHP scripts must depend on a phpX-cli package such as
- php5-cli.  Note that a dependency on a php-cgi package (such as php5-cgi)
- is needlessly strict and forces the user to install a package that isn't
- needed.
+Info: Packages with PHP scripts must depend on the php-cli package.
+ Note that a dependency on a php-cgi package (such as php7.0-cgi) is needlessly
+ strict and forces the user to install a package that isn't needed.
  .
- In some cases a weaker relationship, such as Suggests or Recommends, will
- be more appropriate.
+ In some cases a weaker relationship, such as Suggests or Recommends, will be
+ more appropriate.
  .
  Lintian can only recognize phpX-cli dependencies for values of X that it
  knows are available in the archive.  You will get this warning if you
diff --git a/data/scripts/versioned-interpreters b/data/scripts/versioned-interpreters
index fff44c2..3b2fa00 100644
--- a/data/scripts/versioned-interpreters
+++ b/data/scripts/versioned-interpreters
@@ -73,7 +73,7 @@ guile   => /usr/bin, guile-([\d.]+), guile-$1, 1.6 1.8,
 jruby   => /usr/bin, jruby([\d.]+), jruby$1, 1.0 1.1 1.2
 lua => /usr/bin, lua([\d.]+), lua$1, 40 50 5.1 5.2
 octave  => /usr/bin, octave([\d.]+), octave$1, 3.0 3.2
-php => /usr/bin, php(\d+), php$1-cli, 5, @NO_DEFAULT_DEPS@
+php => /usr/bin, php([\d.]+), php$1-cli, 7.0, php-cli
 pike=> /usr/bin, pike([\d.]+), pike$1 | pike$1-core, 7.6 7.8, @NO_DEFAULT_DEPS@
 python  => /usr/bin, python([\d.]+), python$1:any | python$1-minimal:any, 2.7, @SKIP_UNVERSIONED@
 ruby=> /usr/bin, ruby([\d.]+), ruby$1, 1.8 1.9, @SKIP_UNVERSIONED@
diff --git a/t/tests/legacy-scripts/debian/debian/rules b/t/tests/legacy-scripts/debian/debian/rules
index 25b6f9e..a615bd6 100755
--- a/t/tests/legacy-scripts/debian/debian/rules
+++ b/t/tests/legacy-scripts/debian/debian/rules
@@ -63,8 +63,8 @@ binary-indep:
 	install -m 755 init-lsb-other $(tmp)/etc/init.d/lsb-other
 
 	install -m 755 phpfoo $(tmp)/usr/share/scripts/
-	sed 's/php$$/php5/' phpfoo > $(tmp)/usr/share/scripts/php5foo
-	chmod 755 $(tmp)/usr/share/scripts/php5foo
+	sed 's/php$$/php7.0/' phpfoo > $(tmp)/usr/share/scripts/php7.0foo
+	chmod 755 $(tmp)/usr/share/scripts/php7.0foo
 
 	echo "#!/usr/bin/perl" >> $(tmp)/usr/share/scripts/foobar.in
 	chmod 644 $(tmp)/usr/share/scripts/foobar.in
diff --git a/t/tests/legacy-scripts/tags b/t/tests/legacy-scripts/tags
index 0436902..d93069d 100644
--- a/t/tests/legacy-scripts/tags
+++ b/t/tests/legacy-scripts/tags
@@ -14,7 +14,7 @@ E: scripts: init.d-script-needs-depends-on-lsb-base etc/init.d/skeleton (line 40
 E: scripts: missing-dep-for-interpreter jruby => jruby | jruby1.0 | jruby1.1 | jruby1.2 (usr/bin/jruby-broken)
 E: scripts: missing-dep-for-interpreter lefty => graphviz (usr/bin/lefty-foo)
 E: scripts: package-installs-python-bytecode usr/lib/python2.3/site-packages/test.pyc
-E: scripts: php-script-but-no-phpX-cli-dep usr/share/scripts/php5foo
+E: scripts: php-script-but-no-phpX-cli-dep usr/share/scripts/php7.0foo
 E: scripts: php-script-but-no-phpX-cli-dep usr/share/scripts/phpfoo
 E: scripts: python-script-but-no-python-dep usr/bin/py2foo
 E: scripts: python-script-but-no-python-dep usr/bin/pyfoo
-- 
2.9.3

Bug#840382: [Pkg-samba-maint] Bug#840382: samba (2:4.4.6+dfsg-2) still crashes with libtevent0-0.31

[Mathieu Parent]

(please keep the bug in CC).

Hi,

2016-10-12 16:29 GMT+02:00 Rene Hogendoorn :
[...]
> Thanks for the quick response.
> Please, find a backtrace below.

Thanks

> Note, that there are several backtraces in the file because the daemon kept
> being restarted and, subsequently, failing.

yes systemd is restarting the service. Too fast IMO.

> I hope this will help you locating the issue.

This is strange, I'm not able to reproduce it anymore (since
4.4.6+dbsg-2). Are you sure that you upgraded all the samba packages?

Does nmbd crash too?

Regards
-- 
Mathieu

Bug#809127: links to still-building package log broken

[Marc Haber]

Hi Stephan,

On Sun, Oct 09, 2016 at 11:32:34AM +0200, Stephan Sürken wrote:
> sorry for the late reply, but I basically always agreed here. However,
> I took the liberty to update this bug's title to what I guess your
> intention is :).

Having a live build log would be more than I'd want to. What really
annoys me is that I cannot look, for example, at a build log of a
failed amd64 build because the arm builder is still building.

> Another option would be to improve the packager to already show results
> before all build results have arrived.

That's what I'd want to have, yes.

>  That would change much more logic though, and would not give us live
>  build logs.

Live would be even better, yes. But seeing avilable results before
all other results have arrived is my real wish.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421