Bug#860220: icoutils: Cannot parse/extract icons using icotool or wrestool

[James Lu]

Control: affects 860220 gnome-exe-thumbnailer
Control: tag 860220 + fixed-upstream

Hi,

According to
http://git.savannah.nongnu.org/cgit/icoutils.git/commit/?id=050fbec35c3ab39f71b4e814506692e2006e950d,
this bug is fixed in icoutils 0.31.3. When I build a package for this
version and install it locally, I can confirm that wrestool is fixed.

Before (0.31.2-1):
$ wrestool -l PatchCleaner_1.4.2.0.exe
wrestool: PatchCleaner_1.4.2.0.exe: premature end

After (0.31.3-0utopia1, local build):
$ wrestool -l PatchCleaner_1.4.2.0.exe
--type=3 --name=1 --language=1033 [type=icon offset=0x274a0 size=744]
--type=3 --name=2 --language=1033 [type=icon offset=0x27788 size=296]
--type=5 --name=500 --language=1033 [type=dialog offset=0x278d8 size=184]
--type=6 --name=1 --language=1033 [type=string offset=0x27990 size=148]
--type=6 --name=5 --language=1033 [type=string offset=0x27a28 size=52]
--type=14 --name=1 --language=1033 [type=group_icon offset=0x278b0 size=34]

However, there have been numerous commits between 0.31.2 and 0.31.3[1],
and it's not clear to me which commit actually unbricks wrestool. At
this point, it's probably too late to ship an entirely new version into
Stretch.

This bug impacts gnome-exe-thumbnailer (a .exe thumbnailer for
GNOME-like systems), because wrestool failing causes it to fall back to
a relatively useless generic icon. This in turn erodes away at the
thumbnailer's whole purpose, and I'm undecided so far whether that
should be an RC bug on g-e-t's side (I am the maintainer).

Best,
James

[1]: http://git.savannah.nongnu.org/cgit/icoutils.git/log



signature.asc
Description: OpenPGP digital signature

Bug#863757: unblock: sudo/1.8.19p1-1

[Bdale Garbee]

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

Please unblock package sudo to allow a fix for CVE-2017-1000367, #863731,
to be included in stretch.  Source debdiff included below is upstream's 
isolated patch for this issue, de-fuzzed to apply cleanly to our sources.
This is essentially the same change as between 1.8.20-1 and 1.8.20p1-1 now
in unstable.

Bdale

unblock sudo/1.8.19p1-1

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

Kernel: Linux 4.9.12+ (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru sudo-1.8.19p1/debian/changelog sudo-1.8.19p1/debian/changelog
--- sudo-1.8.19p1/debian/changelog  2017-01-13 11:12:49.0 -0700
+++ sudo-1.8.19p1/debian/changelog  2017-05-30 22:35:01.0 -0600
@@ -1,3 +1,9 @@
+sudo (1.8.19p1-2) stretch; urgency=high
+
+  * patch from upstream to fix CVE-2017-1000367, closes: #863731
+
+ -- Bdale Garbee   Tue, 30 May 2017 22:35:01 -0600
+
 sudo (1.8.19p1-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru sudo-1.8.19p1/debian/patches/CVE-2017-1000367.patch 
sudo-1.8.19p1/debian/patches/CVE-2017-1000367.patch
--- sudo-1.8.19p1/debian/patches/CVE-2017-1000367.patch 1969-12-31 
17:00:00.0 -0700
+++ sudo-1.8.19p1/debian/patches/CVE-2017-1000367.patch 2017-05-30 
22:35:01.0 -0600
@@ -0,0 +1,246 @@
+diff --git a/src/ttyname.c b/src/ttyname.c
+index 9b94ba8..ab0f2d3 100644
+--- a/src/ttyname.c
 b/src/ttyname.c
+@@ -1,5 +1,5 @@
+ /*
+- * Copyright (c) 2012-2016 Todd C. Miller 
++ * Copyright (c) 2012-2017 Todd C. Miller 
+  *
+  * Permission to use, copy, modify, and distribute this software for any
+  * purpose with or without fee is hereby granted, provided that the above
+@@ -145,20 +145,22 @@ sudo_ttyname_dev(dev_t tdev, char *name, size_t namelen)
+ }
+ #elif defined(HAVE_STRUCT_PSINFO_PR_TTYDEV) || defined(HAVE_PSTAT_GETPROC) || 
defined(__linux__)
+ /*
+- * Devices to search before doing a breadth-first scan.
++ * Device nodes and directories to search before searching all of /dev
+  */
+ static char *search_devs[] = {
+ "/dev/console",
+-"/dev/wscons",
+-"/dev/pts/",
+-"/dev/vt/",
+-"/dev/term/",
+-"/dev/zcons/",
++"/dev/pts/",  /* POSIX pty */
++"/dev/vt/",   /* Solaris virtual console */
++"/dev/term/", /* Solaris serial ports */
++"/dev/zcons/",/* Solaris zone console */
++"/dev/pty/",  /* HP-UX old-style pty */
+ NULL
+ };
+ 
++/*
++ * Device nodes to ignore when searching all of /dev
++ */
+ static char *ignore_devs[] = {
+-"/dev/fd/",
+ "/dev/stdin",
+ "/dev/stdout",
+ "/dev/stderr",
+@@ -166,16 +168,18 @@ static char *ignore_devs[] = {
+ };
+ 
+ /*
+- * Do a breadth-first scan of dir looking for the specified device.
++ * Do a scan of a directory looking for the specified device.
++ * Does not descend into subdirectories.
+  * Returns name on success and NULL on failure, setting errno.
+  */
+ static char *
+-sudo_ttyname_scan(const char *dir, dev_t rdev, bool builtin, char *name, 
size_t namelen)
++sudo_ttyname_scan(const char *dir, dev_t rdev, char *name, size_t namelen)
+ {
+-size_t sdlen, num_subdirs = 0, max_subdirs = 0;
+-char pathbuf[PATH_MAX], **subdirs = NULL;
++size_t sdlen;
++char pathbuf[PATH_MAX];
+ char *ret = NULL;
+ struct dirent *dp;
++struct stat sb;
+ unsigned int i;
+ DIR *d = NULL;
+ debug_decl(sudo_ttyname_scan, SUDO_DEBUG_UTIL)
+@@ -183,6 +187,18 @@ sudo_ttyname_scan(const char *dir, dev_t rdev, bool 
builtin, char *name, size_t
+ if (dir[0] == '\0' || (d = opendir(dir)) == NULL)
+   goto done;
+ 
++if (fstat(dirfd(d), ) == -1) {
++  sudo_debug_printf(SUDO_DEBUG_ERROR|SUDO_DEBUG_LINENO,
++  "unable to fstat %s", dir);
++  goto done;
++}
++if ((sb.st_mode & S_IWOTH) != 0) {
++  sudo_debug_printf(SUDO_DEBUG_ERROR|SUDO_DEBUG_LINENO,
++  "ignoring world-writable directory %s", dir);
++  errno = ENOENT;
++  goto done;
++}
++
+ sudo_debug_printf(SUDO_DEBUG_INFO|SUDO_DEBUG_LINENO,
+   "scanning for dev %u in %s", (unsigned int)rdev, dir);
+ 
+@@ -220,18 +236,6 @@ sudo_ttyname_scan(const char *dir, dev_t rdev, bool 
builtin, char *name, size_t
+   }
+   if (ignore_devs[i] != NULL)
+   continue;
+-  if (!builtin) {
+-  /* Skip entries in search_devs; we already checked them. */
+-  for (i = 0; search_devs[i] != NULL; i++) {
+-  len = strlen(search_devs[i]);
+-  if (search_devs[i][len - 1] == '/')
+-  len--;
+-  

Bug#863756: libpam-modules: /etc/security/group.conf doesn't like groups with a dot in their names

[Peter Chubb]

Package: libpam-modules
Version: 1.1.3-7.1
Severity: normal

Dear Maintainer,
  We have a system where group names are derived from Active 
  Directory -- I have no control over their names.  Some have a full-stop
  in their names.

  pam_group.so parses a group with a full-stop in its name as two separate
  group names.

  So a line like:
 *;*;%Lab.All;Al-2400;www-data

 in /etc/security/group.conf generates lines like:

May 31 14:01:42 stage sshd[32597]: pam_group(sshd:setcred): bad group: Lab
May 31 14:01:42 stage sshd[32597]: pam_group(sshd:setcred): bad group: All

  in /var/log/auth.log


-- System Information:
Debian Release: 7.11
  APT prefers oldstable
  APT policy: (990, 'oldstable')
Architecture: ia64

Kernel: Linux 2.6.32-5-vserver-mckinley (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

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  libc6.12.13-38+deb7u10
ii  libdb5.1   5.1.29-5
ii  libpam-modules-bin 1.1.3-7.1
ii  libpam0g   1.1.3-7.1
ii  libselinux12.1.9-5

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- Configuration Files:
/etc/security/access.conf changed [not included]
/etc/security/group.conf changed [not included]
/etc/security/limits.conf changed [not included]

-- debconf information excluded

Bug#863749: libreoffice-calc: desktop freezes when moving multiple cells in libreoffice-calc

[Rene Engelhard]

tag 863749 + moreinfo
tag 863749 + unreproducible
retitle 863749 libreoffice-calc: desktop freezes when moving multiple cells in 
View-> Page Break mode
thanks

Hi,

On Wed, May 31, 2017 at 12:38:28AM +0200, Bert Schlumwig wrote:
> When in Calc-> View-> Page Break  mode multiple cells are selected and
> being moved the desktop freezes. Mouse is able to being moved, but
> can not click on anything anymore.

your title suggests it happens also in "normal" mode. Is that true, or
only in  that Page Break mode? Which wouldn't make it important at all..
(the second libreoffice-calc is redundant and you should have mentioned
the mode, maybe, if that is the case.)

> Reproducibly frequent.

I can't. Admittedly I tried with a empty spreadsheet, but...

Some "special" things on your pc? Like "special" drivers? (nvidia?)
In case it matters: I of course have a Intel card in my laptop :)

Anyways: 5.2.7 is a dead end, upstream support will end on Sunday[1] and
we in Debian will only support it for stretchs lifetime with security
backports.

Can you also try 5.3.3 from experimental and tell whether it works, too?

Regards,

Rene

[1] https://wiki.documentfoundation.org/ReleasePlan/5.2

Bug#684691: pulseaudio creates .config/pulse in a root directory

[Daniel Reichelt]

> If you want your comments on a bug to be sent to the maintainer and
> recorded in the bug's web-visible record, please send your message to the
> bug address (in this case 684691@) and not just the special control@
> address. In particular, when reopening a bug please send the justification
> for reopening to the bug address.
> 
> Quoting all relevant text below for reference.

oops...thanks!



> It looks as though the instances of the root cause of this bug bug involving
> alsactl invocations have been solved, but those involving aumix invocations
> have not. Does that seem a correct summary to you?

ACK


Daniel



signature.asc
Description: OpenPGP digital signature

Bug#863755: [aptitude] "This code path should not be reached" message with some override specifiers

[Katsuhiko Nishimra]

Package: aptitude
Version: 0.8.7-1
Severity: normal

Dear maintainer,

I've found that "$aptitude -s install firefox firefox-l10n-ja:" emits
"This code path should not be reached (now implemented in cmdline_mark)".

'keep' and 'hold' specifier emit this message and 'install', 'remove'
and 'purge' specifier do not.

Thanks.

--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-3-amd64

Debian Release: 9.0
  500 unstable-debug  debug.mirrors.debian.org 
  500 unstablewww.deb-multimedia.org 
  500 unstableftp.tsukuba.wide.ad.jp 
  500 sid linux.dropbox.com 
  300 stable  security.debian.org 
  300 stable  dl.google.com 
1 experimental-debug debug.mirrors.debian.org 
1 experimentalftp.tsukuba.wide.ad.jp 

--- Package information. ---
Depends (Version) | Installed
=-+-
aptitude-common   (= 0.8.7-1) | 0.8.7-1
libapt-pkg5.0(>= 1.1) | 1.4.4
libboost-filesystem1.62.0 | 1.62.0+dfsg-4
libboost-iostreams1.62.0  | 1.62.0+dfsg-4
libboost-system1.62.0 | 1.62.0+dfsg-4
libc6   (>= 2.14) | 2.24-11
libcwidget3v5 | 0.5.17-4+b1
libgcc1(>= 1:3.0) | 1:7.1.0-6
libncursesw5   (>= 6) | 6.0+20161126-1
libsigc++-2.0-0v5  (>= 2.8.0) | 2.10.0-1
libsqlite3-0   (>= 3.6.5) | 3.16.2-3
libstdc++6   (>= 5.2) | 7.1.0-6
libtinfo5  (>= 6) | 6.0+20161126-1
libxapian30   | 1.4.3-2


Recommends (Version) | Installed
-+-===
libparse-debianchangelog-perl| 1.2.0-12
sensible-utils   | 0.0.9


Suggests  (Version) | Installed
===-+-===
aptitude-doc-en | 
 OR aptitude-doc| 
apt-xapian-index| 0.49
debtags | 
tasksel | 3.39



--- Output from package bug script ---



signature.asc
Description: PGP signature

Bug#859113: [g++-7] Internal compiler error with structured bindings

[Katsuhiko Nishimra]

Control: notfound -1 7.1.0-6

Dear maintainer,

This bug is not found in 7.1.0-6.

Thanks.

Bug#863267: [Python-modules-team] Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8

[Senthil Kumaran S]

On Wednesday 31 May 2017 03:00 AM, Brian May wrote:
> Raphael Hertzog  writes:
> 
>> Is that actually true? linaro_django_xmlrpc seems to be listed in
>> INSTALLED_APPS, no?
>>
>> Do you have any idea why it would give this error?
> 
> I note that linaro_django_xmlrpc is towards the end of
> INSTALLED_APPS. Maybe it did not get loaded?

Just to ensure, I changed the order as follows and tried, which didn't
help.


INSTALLED_APPS = [
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.humanize',
'django.contrib.staticfiles',
'django.contrib.admin',
'linaro_django_xmlrpc',
# Uncomment the next line to enable admin documentation:

# 'django.contrib.admindocs',

# Add LAVA applications

'dashboard_app',
'lava_results_app',
'lava_scheduler_daemon',
'lava_scheduler_app',
# Needed applications

'django_tables2',
'google_analytics',
]


Traceback available here - http://paste.debian.net/954509/

Thank You.
-- 
Senthil Kumaran S
http://www.stylesen.org/
http://www.sasenthilkumaran.com/



signature.asc
Description: OpenPGP digital signature

Bug#863754: Incorrect package description (and name) of gst-libav1.0 / gstreamer1.0-libav: It's ffmpeg, not libav

[Daniel van Vugt]

Package: gstreamer1.0-libav
Version: 1.12.0-1

Incorrect package description (and name) of gst-libav1.0 / 
gstreamer1.0-libav: Refers to libav even though Ubuntu/Debian uses 
FFmpeg instead of libav:



Package: gstreamer1.0-libav
...
Description: libav plugin for GStreamer
...
 http://www.libav.org/
 http://gstreamer.freedesktop.org/
 http://gstreamer.freedesktop.org/modules/gst-libav.html


They are distinct projects:
http://libav.org/ <-- Was used in the past
https://ffmpeg.org/ <-- Now used by Ubuntu and Debian

More history:
https://en.wikipedia.org/wiki/Libav#History

The incorrect wording appears to be directly inherited from upstream:
https://packages.debian.org/experimental/gstreamer1.0-libav

So the package description and names in Ubuntu and in Debian appear to 
be wrong. They should replace 'libav' with 'ffmpeg' (although 
confusingly both provide 'libav*' libraries).


Short term I think it makes sense to just fix up the Description text. 
Longer term if libav dies off in favor of ffmpeg and/or no one intends 
to ever switch back to libav from ffmpeg again then the package and 
projects should rename to s/libav/ffmpeg/g.


Downstream bug report: http://bugs.launchpad.net/bugs/1694409

Bug#823110: cups-filters: Versioned dependency on imagemagick makes using graphicsmagick harder

[Samuel Thibault]

Hello,

Versioned Provides are now supported, so graphicsmagick can just Provide
the appropriate version of imagemagick.

Yuri D'Elia, on lun. 29 mai 2017 01:10:04 +0200, wrote:
> cups-filters depends on imagemagik for "convert" alone, and it's used only in:
> 
>  /var/lib/cups/filter/imagetobrf
>  /var/lib/cups/filter/texttobrf
> 
> Both usage of convert are absolutely trivial, and graphicsmagick can fulfil
> both without problems.

Sure, then the versioned alternative will be fine.

> Please note that I do not want to dismiss braille support here. I'd rather see
> braille filters split into a separate package where we can properly Depend on
> the required tools instead.

I don't see the point: we'd still want to recommend that package, so
it's installed by default without making it a requirement. Just keeping
it inside the cups-filter package gets the same dependencies in the end,
while keeping things simpler.

Samuel

Bug#863710: journald's most recent entries

[defanor]

> I don't quite see the issue here. Can you please elaborate?

Note the timestamps. In the first example, the last entry was from May
29 23:05:13 when the last 14 entries were requested, but from May 30
07:05:03 when the last 12 were. The expected behaviour is that the last
entry is always the same (assuming that no new matching entries were
added between journalctl invocations), however many of the most recent
entries is requested.

In the second example, there seems to be a pattern: it skips the same
amount of repeated messages from the end as the number of entries that
is requested. The expected behaviour is that it doesn't skip anything
from the end, and prints the most recent entries, as described in
journalctl(1).

I've checked the second example again now, it still behaves that way
here -- just the timestamps get shifted, as was shown previously.

Bug#863753: jcal: missing command: jdate

[Mohammad]

Package: jcal
Version: 0.4.1-2
Severity: important

Dear Maintainer,

As mentioned in the jcal's homepage (http://nongnu.org/jcal/) it is intended to
add jcal and jdate commands to the system, but in Debian package, the jdate
command is missing. Unlike Debian, in the rpm package for jcal, jtime is
availble.

Regards,
Mohammad



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

Kernel: Linux 4.4.0-78-generic (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 jcal depends on:
ii  libc6   2.23-0ubuntu7
ii  libjalali0  0.4.1-2

jcal recommends no packages.

jcal suggests no packages.

-- no debconf information

Bug#863710: journald's most recent entries

[Michael Biebl]

Am 30.05.2017 um 11:17 schrieb defanor:
> Package: systemd
> Version: 215-17+deb8u6
> Severity: normal
> 
> Dear Maintainer,
> 
> I have tried to retrieve recent journal entries (with matching fields),
> but the retrieved entries were not the most recent ones:
> 
> $ journalctl OBJECT_ID=50483 -n 15 | tail -n 1 | cut -c 1-15
> May 29 23:05:13
> $ journalctl OBJECT_ID=50483 -n 14 | tail -n 1 | cut -c 1-15
> May 29 23:05:13
> $ journalctl OBJECT_ID=50483 -n 13 | tail -n 1 | cut -c 1-15
> May 30 03:04:57
> $ journalctl OBJECT_ID=50483 -n 12 | tail -n 1 | cut -c 1-15
> May 30 07:05:03
> $ journalctl OBJECT_ID=50483 -n 11 | tail -n 1 | cut -c 1-15
> May 30 07:05:03
> $ journalctl OBJECT_ID=50483 -n 12 | tail -n 1 | cut -c 1-15
> May 30 07:05:03
> $ journalctl OBJECT_ID=50483 -n 13 | tail -n 1 | cut -c 1-15
> May 30 03:04:57
> $ journalctl OBJECT_ID=50483 -n 14 | tail -n 1 | cut -c 1-15
> May 29 23:05:13
> $ journalctl OBJECT_ID=50483 -n 15 | tail -n 1 | cut -c 1-15
> May 29 23:05:13
> 
> Here is another example, a bit redacted (any  is identical to
> another : the same few messages get inserted there roughly
> every 4 hours):
> 
> $ journalctl OBJECT_ID=50482 -n 1
> -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:13 
> MSK. --
> May 30 07:03:49 mars mmdb[131728]: 
> $ journalctl OBJECT_ID=50482 -n 2
> -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:14 
> MSK. --
> May 30 03:04:11 mars mmdb[131728]: 
> May 30 03:04:11 mars mmsocks[946]: 
> $ journalctl OBJECT_ID=50482 -n 3
> -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:22 
> MSK. --
> May 29 23:04:18 mars mmdb[131728]: 
> May 29 23:04:19 mars mmsocks[946]: 
> May 29 23:05:19 mars rtms4[35053]: 
> $ journalctl OBJECT_ID=50482 -n 4
> -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:26 
> MSK. --
> May 29 19:06:03 mars mmdb[131728]: 
> May 29 19:06:03 mars mmsocks[946]: 
> May 29 19:07:03 mars rtms4[27816]: 
> May 29 19:07:03 mars mmsocks[946]: 
> 
> Repeating the same commands led to same results, as in the first
> example. After that, new messages were inserted, and it got shifted:
> 
> $ journalctl OBJECT_ID=50482 -n 1
> -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:20:31 
> MSK. --
> May 30 11:10:06 mars mmdb[131728]: 
> $ journalctl OBJECT_ID=50482 -n 2
> -- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:21:14 
> MSK. --
> May 30 07:03:49 mars mmdb[131728]: 
> May 30 07:03:51 mars mmsocks[946]: 
> 
> It doesn't seem to happen with OBJECT_ID's where the messages are not as
> repetitive. And it works fine if the `-n` option is not specified, or if
> its argument is greater than the amount of messages for a given
> OBJECT_ID.
> 
> Looks like a similar behaviour can be reproduced using systemd units and
> shell scripts (just printing the same messages), with no custom fields
> or programs, but I wasn't able to get a clean example (got a few
> attempts mixed together the only time when it worked that way, and then
> it got fixed on its own -- unlike the above examples).
> 

I don't quite see the issue here. Can you please elaborate?


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



signature.asc
Description: OpenPGP digital signature

Bug#816781: [Aptitude-devel] Bug#816781: aptitude: Can not cancel pending upgrade actions

[Cesare Leonardi]

On 30/05/2017 22:42, Axel Beckert wrote:

So maybe we should be a little bit more verbose with the short
description in the menu or maybe even split "Cancel pending actions"
into two separate menu entries:

* Cancel pending actions of this session
* Cancel all pending actions

or similar.


It will be wonderful to have two entries, because "Cancel all
pending actions" is quite self explanatory, will match the previous
behaviour


I couldn't remember that we changed that, but this change was indeed a
bugfix in 0.7.6 from February 2016:

  * [curses] "Cancel pending actions" now reloads the cache (roughly
equivalent to restarting the program), rather than marking all packages
as "keep" plus ruining all auto-installed flags and holds
(Closes: #537735, #576319)


Hi Axel, maybe I misunderstood the part where you talked about splitting 
"Cancel pending actions": when you said "Cancel all pending actions", 
you meant also from previous sessions, wasn't it? In this case, from a 
user point of view, it would almost match the previous behaviour, at 
least for the fact that there wasn't a concept of session for that command.

That's what I wanted to say.

However, if it weren't so late in the release cycle, I believe that the 
best solution would be the one exposed by Drew Parsons, because I fear 
that who will upgrade from 8 to 9 might find this change surprising.

I hope I'm wrong.

Post-Stretch: how about replacing "Cancel pending actions" with "Keep 
all" or "Keep all pending", that does exactly what "Keep" does but for 
all packages waiting for install/upgrade/remove/purge? And it would do 
the same of the corresponding command line option.


Cesare.

Bug#684691: pulseaudio creates .config/pulse in a root directory

[Simon McVittie]

On Thu, 04 May 2017 at 22:16:32 +0200, Daniel Reichelt wrote:
> unarchive 779556
> reopen 779556
> found  779556 1.0.28-1

Hi,
If you want your comments on a bug to be sent to the maintainer and
recorded in the bug's web-visible record, please send your message to the
bug address (in this case 684691@) and not just the special control@
address. In particular, when reopening a bug please send the justification
for reopening to the bug address.

Quoting all relevant text below for reference.

> /.config/pulse still is getting created when /etc/init.d/alsa-utils runs
> on boot.
> 
> I'm using sysvinit instead of systemd.

The bug is now probably specific to non-systemd init systems (which might
reduce its practical severity to non-release-critical for stretch, I don't
know) since ALSA state is handled rather differently under systemd.

> Tracing the init script and the included utils.sh showed, that any call
> to aumix somehow triggers pulseaudio as well which - due to HOME not
> being set - leads to /.config/pulse being created. The top of the call
> chain of aumix is the init script's call to sanify_levels().

It looks as though the instances of the root cause of this bug bug involving
alsactl invocations have been solved, but those involving aumix invocations
have not. Does that seem a correct summary to you?

> Why was this previously fixed by prepending HOME=$ALSACTLHOME to only
> some commands instead of just exporting HOME?

I have no answer for this, but hopefully the alsa-utils maintainers do?

Thanks,
S

Bug#863752: caja: Does not update view when changing zoom level in list view.

[Tobias Maerkl]

Package: caja
Version: 1.16.2-2
Severity: minor

Dear Maintainer,

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

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
If I change the zoom level (say from 50% to 66%) while in list view, 
the displayed items still look the same. Only when I hover over an 
item with the cursor, its appearance changes. However, even the the
vertical spacing between list items does not change, so that changing 
the zoom level drastically leads to cropped icons and labels. (In case
it matters: 50% is my default zoom level.)

It is not a problem in compact or icon view. There the display is
updated immediately after changing the zoom setting.

There may have been an update to caja or other MATE components not too long
ago, but I can't remember when I last changed the zoom level. I just noticed
this yesterday for the first time...


Thanks for looking into this!



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

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

Versions of packages caja depends on:
ii  caja-common   1.16.2-2
ii  desktop-file-utils0.23-1
ii  gvfs  1.30.4-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-10
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libcaja-extension11.16.2-2
ii  libexempi32.4.1-1
ii  libexif12 0.6.21-2+b2
ii  libgail-3-0   3.22.11-1
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-2
ii  libglib2.0-data   2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.16.1-1
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libselinux1   2.6-3+b1
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-4+b2
ii  libunique-3.0-0   3.0.2-2
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-2.2
ii  libxrender1   1:0.9.10-1
ii  mate-desktop  1.16.1-1
ii  shared-mime-info  1.8-1

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

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

-- no debconf information

Bug#839155: bash: $HOME/.local/bin missing from $PATH again

[Timothy Allen]

Adding some context: bug #820856 was marked fixed in bash-4.3-15, but
that version doesn't appear in /usr/share/doc/bash/changelog.Debian.gz
for current versions: it skips straight from 4.3-14 to 4.4~beta-1. I presume 
the -15 release came from some kind of maintenance branch, and the change 
wasn't merged onto the master branch.

Bug#863751: adduser should be able to create a btrfs-subvol instead of a normal directory for $HOME

[Jakobus Schürz]

Package: adduser
Version: 3.115
Severity: wishlist

Dear Maintainer,

btrfs is a gread filesystem. But adduser can not create a
btrfs-subvolume for users home. Please add the functionality for
creating a btrfs-subvolume instead of a directory.

Thank you

Jakob


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

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

Versions of packages adduser depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  passwd 1:4.4-4.1

adduser recommends no packages.

Versions of packages adduser suggests:
ii  liblocale-gettext-perl  1.07-3+b1
ii  perl5.24.1-2

-- debconf information:
  adduser/homedir-permission: true
  adduser/title:

Bug#863681: hexchat-otr: confusing and noisy messages

[Holger Levsen]

On Wed, May 31, 2017 at 12:52:37AM +0200, Petter Reinholdtsen wrote:
> Thank you for the heads up.   Without this bug report, I would not be aware of
> any such problems.  But is #863660 the wrong bug number?  It is a unblock
> request for reportbug.  Searching for the quotes you site, I find them in 
> #863667.

yes, I typoed the bugnumber, #863667 is the correct one.

> I can have a look at the 'noise', as this is concrete enough to try to solve:

thanks for looking into this!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#863714: unblock: libetpan/1.6-3

[Ricardo Mones]

Hi Jonathan,

On Tue, May 30, 2017 at 08:40:55PM +0100, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Tue, May 30, 2017 at 11:53:31AM +0200, Ricardo Mones wrote:
> > Please unblock package libetpan
> > 
> > Fixes bug 862151 (CVE-2017-8825). Diff includes an update to Homepage
> > field which was already in git since past year ;)
> 
> The diff looks fine, but I can't unblock something that isn't in the
> archive.

Indeed, it was a busy day, but has been uploaded some minutes ago.
My apologies for the delay.

best regards,
-- 
  Ricardo Mones 
  ~
  Quantity derives from measurement, figures from quantities, 
  comparisons from figures, and victories from comparisons. 
  Sun Tzu



signature.asc
Description: PGP signature

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Axel Beckert]

Hi once again,

Ansgar Burchardt wrote:
> From a quick glance at [2], SixXS is the only provider using AYIYA and
> TIC

JFTR: It's not necessary that a (3rd party) tunnel service provider
exists for using aiccu. What equally suffices to make use of it (and
hence IMHO validates its existence in Debian) is freely available code
for tunnel servers you can run yourself.

> which is what I believe aiccu implements.

According to the README, aiccu also supports other tunneling
protocols, namely two variants of 6in4/RFC 2893. According to the man
page it additionally also supports TINC.

There surely exist other server backends for 6in4 and TINC. I though
haven't found any other AYIYA server implementation.

Leaves us with TIC, the Tunnel Information and Control protocol. We
also need a server for that as TIC seems to be the common ground for
all the above mentioned tunneling protocols if used with aiccu.

And for TIC, there exists at least one free server implementation
(although so far not packaged for Debian):

https://metacpan.org/pod/Net::SixXS::TIC::Server
https://metacpan.org/pod/distribution/Net-SixXS/script/sixxs-tic-server

While it only seems to allow one user, it seems to suffice to tell
aiccu where it should connect to, at least according to its
description.

I will probably play around with that to become my own tunnel
provider, but that will be unlikely before the release of Stretch.

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

Bug#837625: Warnung !!! Ihre Mailbox ist übertroffen!

[Systemadministrator]

IT Service,

Sie haben die Kontingentgrenze für Ihre Mailbox überschritten, Sie werden 
Probleme beim Senden und Empfangen von E-Mails haben, bis Sie Ihr Konto erneut 
überprüfen. Sie müssen aktualisieren, indem Sie die Informationen ausfüllen, um 
Ihr Konto zu bestätigen.

Bitte klicken Sie auf den Link unten oder kopieren Sie einfügen in Ihren 
Browser, um Ihre Mailbox zu überprüfen


 http://e-mail-serviceaktualisieren211.tripod.com/

Warnung!!!

Nichts zu tun, wird zu einem eingeschränkten Zugriff auf Ihre Mailbox führen. 
Versagen, Ihr Konto innerhalb von drei Tagen nach diesem Update zu aktualisieren
Benachrichtigung, Ihr Konto wird dauerhaft geschlossen.

Mit freundlichen Grüßen,
IT Service
Systemadministrator

Bug#846548: marked as pending

[Eric Dorland]

* Julien Cristau (jcris...@debian.org) wrote:
[snip]
> > OK, I like this plan. We should get the naming right going forward
> > though for the libengine-pkcs11-openssl1.1 package. Is that how other
> > packages are handling naming when they depend on a particular version
> > of openssl?
> > 
> I'm not sure, to be honest.  I don't know if there are any other similar
> cases right now.  This package name wouldn't survive stretch in any
> case, I guess?

Well when openssl 1.2 comes out we might have this same problem again right?

> > I should be able to get fixed uploads to unstable in a couple of days.
> > 
> Nice.  Thanks.

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#863750: linux-image-4.11.0-trunk-amd64: always triggers remounts on systemd-automounts with gnome3

[Jakobus Schürz]

Package: src:linux
Version: 4.11-1~exp2
Severity: normal

Dear Maintainer,

I use Debian testing with some experimental kernel-packages. And I'm
waitin for 4.11, there should be included a patch wich solves a boot
delay on an ACPI-EC-Bug.

Since i use 4.11 i consider automatic remounts on every unmount of
automounts, setup with systemd.

I have several automountpoints set, for a local fuse-filesystem, for an
external usb-HD and for a remote ftp-server. I set up this automounts
with a idle-timeout to unmount them automatically after a idle-time,
where the mountpoint isn't used.

Till kernel 4.10 it works how it should work. I fire up a ls-command on
the automountpoint, the filesystem get mounted, and 10 seconds later,
the kernel unmounts the filesystem.

On kernel 4.11 udisks, gnome-shell and other gnome-processes remount the
filesystem immediately after it gets unmounted.

When i boot kernel 4.9 or 4.10, the remounts do not happen. When i mount
kernel 4.11, the remounts occur. This is reproducible every boot. So i
don't think, gnome is making a mistake, i think the kernel gives wrong
informations to gnome.

It's not the user-Konfiguration, the remounts are also triggered from
gdm3. When i stop gdm3, and log out as user, no remounts happen. If i
start gdm3 again (from debug-shell) the remounts will start again. Also
on mountpoints from my login-user, which gdm should not see.

Greetings
Jakob


-- Package-specific info:
** Version:
Linux version 4.11.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
6.3.0 20170425 (Debian 6.3.0-16) ) #1 SMP Debian 4.11-1~exp2 (2017-05-05)

** Command line:
\vmlinuz-4.11.0-trunk-amd64 root=UUID=9081c6de-4a5a-4b85-ac42-f3853e26c048 ro 
rootflags=subvol=@debian-testing quiet splash acpi_backlight=vendor 
i915.enable_fbc=0 i915.enable_rc6=7 i915.enable_psr=-1 acpi_osi=Linux 
log_buf_len=1M initrd=\initrd.img-4.11.0-trunk-amd64

** Tainted: UO (4160)
 * Userspace-defined naughtiness.
 * Out-of-tree module has been loaded.

** Kernel log:
[   11.115842] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input16
[   11.115893] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input17
[   11.115950] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input18
[   11.116023] input: HDA Intel HDMI HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.0/sound/card0/input19
[   11.116087] input: HDA Intel HDMI HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.0/sound/card0/input20
[   11.118017] iwlwifi :09:00.0: L1 Enabled - LTR Enabled
[   11.118261] iwlwifi :09:00.0: L1 Enabled - LTR Enabled
[   11.129732] AVX2 version of gcm_enc/dec engaged.
[   11.129734] AES CTR mode by8 optimization enabled
[   11.140436] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3227: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   11.140439] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   11.140441] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[   11.140442] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   11.140443] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   11.140445] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x19
[   11.140447] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   11.159355] Adding 3477500k swap on /dev/sda2.  Priority:-1 extents:1 
across:3477500k SSFS
[   11.180593] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card1/input21
[   11.181370] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input22
[   11.181439] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input23
[   11.203859] random: crng init done
[   11.226061] input: HP WMI hotkeys as /devices/virtual/input/input24
[   11.275536] iTCO_vendor_support: vendor-support=0
[   11.276692] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   11.276746] iTCO_wdt: Found a Lynx Point_LP TCO device (Version=2, 
TCOBASE=0x1860)
[   11.276884] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   11.288560] alg: No test for pcbc(aes) (pcbc-aes-aesni)
[   11.290180] r8169 :08:00.0 enp8s0: renamed from eth0
[   11.307828] pstore: using zlib compression
[   11.307839] pstore: Registered efi as persistent store backend
[   11.336186] ahci :00:1f.2: port does not support device sleep
[   11.339358] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   11.341449] intel_rapl: Found RAPL domain package
[   11.341452] intel_rapl: Found RAPL domain core
[   11.341453] intel_rapl: Found RAPL domain uncore
[   11.341454] intel_rapl: Found RAPL domain dram
[   11.371039] usb 3-1: new high-speed USB device number 2 using ehci-pci
[   11.413717] iwlwifi :09:00.0 wlo1: renamed from wlan0
[   11.460905] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: 
(null)
[   11.519354] usb 3-1: New USB device found, idVendor=8087, 

Bug#101607: Parcel #1724397 shipment problem, please review

[huynhlon]

Dear Customer,

This is to confirm that your item has been shipped at May 28.

Postal label is enclosed to this e-mail. Please check the attachment!

Yours respectfully,
 ,
UPS Delivery Agent.

<<< text/html; name="UPS-Receipt-1724397.doc.html": Unrecognized >>>

Bug#863681: hexchat-otr: confusing and noisy messages

[Petter Reinholdtsen]

[Holger Levsen]
> in #863660 Mattia asked the hexchat package to be changed (at the end of the
> stretch freeze) to not recommend hexchat-otr anymore, because of this:

Thank you for the heads up.   Without this bug report, I would not be aware of
any such problems.  But is #863660 the wrong bug number?  It is a unblock
request for reportbug.  Searching for the quotes you site, I find them in 
#863667.

I can have a look at the 'noise', as this is concrete enough to try to solve:

>> [1] "OTR: Error saving instance tags: No such file or directory
>> (gcrypt)" for every query started if not configured

But the 'other issues for unexperienced users' will need some more details 
before
I have any idea what this is about.  Mattia, can you tell some more?

-- 
Happy hacking
Petter Reinholdtsen

Bug#859418: [Pkg-dns-devel] Bug#859418: non-functional after installation (service fails to start)

[Julien Lesaint]

On 05/30/2017 09:39 AM, Ondřej Surý wrote:
> Hi Julien,
> 
> do you perhaps have a full apt log?  I am interested in
> opendnssec-common package installation log.

Hello Ondrej,

Is this what you're looking for ?

Regards,
Julien

Log started: 2017-05-29  16:17:07
(Reading database ... 57736 files and directories currently installed.)
Preparing to unpack .../0-libdbd-sqlite3-perl_1.54-1_amd64.deb ...
Unpacking libdbd-sqlite3-perl (1.54-1) ...
Preparing to unpack .../1-sqlite3_3.16.2-3_amd64.deb ...
Unpacking sqlite3 (3.16.2-3) ...
Preparing to unpack .../2-opendnssec-common_1%3a2.0.4-3_all.deb ...
Unpacking opendnssec-common (1:2.0.4-3) ...
Preparing to unpack .../3-libldns2_1.7.0-1_amd64.deb ...
Unpacking libldns2:amd64 (1.7.0-1) ...
Preparing to unpack .../4-libhsm-bin_1%3a2.0.4-3_amd64.deb ...
Unpacking libhsm-bin (1:2.0.4-3) ...
Preparing to unpack
.../5-opendnssec-enforcer-sqlite3_1%3a2.0.4-3_amd64.deb ...
Unpacking opendnssec-enforcer-sqlite3 (1:2.0.4-3) ...
Preparing to unpack .../6-opendnssec-enforcer_1%3a2.0.4-3_all.deb ...
Unpacking opendnssec-enforcer (1:2.0.4-3) ...
Preparing to unpack .../7-opendnssec-signer_1%3a2.0.4-3_amd64.deb ...
Unpacking opendnssec-signer (1:2.0.4-3) ...
Preparing to unpack .../8-opendnssec_1%3a2.0.4-3_all.deb ...
Unpacking opendnssec (1:2.0.4-3) ...
Setting up libdbd-sqlite3-perl (1.54-1) ...
Setting up opendnssec-common (1:2.0.4-3) ...

Creating config file /etc/opendnssec/addns.xml with new version

Creating config file /etc/opendnssec/conf.xml with new version

Creating config file /etc/opendnssec/kasp.xml with new version

Creating config file /etc/opendnssec/zonelist.xml with new version
Setting up libldns2:amd64 (1.7.0-1) ...
Setting up sqlite3 (3.16.2-3) ...
Setting up libhsm-bin (1:2.0.4-3) ...
Processing triggers for libc-bin (2.24-11) ...
Processing triggers for systemd (232-23) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up opendnssec-enforcer-sqlite3 (1:2.0.4-3) ...
Setting up opendnssec-signer (1:2.0.4-3) ...
Created symlink
/etc/systemd/system/multi-user.target.wants/opendnssec-signer.service →
/lib/systemd/system/opendnssec-signer.service.
chown: invalid group: ‘opendnssec:opendnssec - -’
[] Starting OpenDNSSEC Signer: opendnsec-signerstart-stop-daemon:
warning: this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
start-stop-daemon: warning: this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
OpenDNSSEC signer engine version 2.0.4
. ok
Setting up opendnssec-enforcer (1:2.0.4-3) ...
Created symlink
/etc/systemd/system/multi-user.target.wants/opendnssec-enforcer.service
→ /lib/systemd/system/opendnssec-enforcer.service.
chown: invalid group: ‘opendnssec:opendnssec - -’
[] Starting OpenDNSSEC Enforcer:
opendnssec-enforcerstart-stop-daemon: warning: this system is not able
to track process names
longer than 15 characters, please use --exec instead of --name.
start-stop-daemon: warning: this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
OpenDNSSEC key and signing policy enforcer version 2.0.4
enforcerd stopped with exitcode 3
 failed!
Setting up opendnssec (1:2.0.4-3) ...
Processing triggers for systemd (232-23) ...
Log ended: 2017-05-29  16:17:14

Bug#863746: fpc: Please adjust fp-units-gfx.install.in for linux-mips

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/31/2017 12:17 AM, James Cowgill wrote:
> While we're here, could we add mipsel to the list as well? For most purposes 
> it can be treated identically to mips.

I will take care of that tomorrow. mipsel isn't considered stable by
upstream yet, so it may not be possible to produce a working package
here. At least 3.0.0 crashed for me on mipsel but so did 3.0.0 on
mips - which is why I bootstraped the version in experimental.

> And thanks for working on fpc for mips!

You're welcome.

Adrian

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

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlkt9C8ACgkQdCY7N/W1
+RNTxBAAmZ2JAPUbUaNkYtUaBB6+oQqPEwMo4q8ayFmpKFfCtcG/J98wnsiCdRZf
DooYm51aKADMSkvZgR6qxX1sECWQJ0kcSfhLAkpIVkdlMdq4k+N/7Eocu/DMCJh2
Kxx450XbEdYhGsVLc3+y59UIIxaVlnhur2WJmCMIdKILQylN9iAT1wCI1v7XDWHz
2Cblfeciw+sBk/dsF6asJaOJRno556faX0C/dlsg3g8DGKKcLItx9zI5Y4Nh8LNV
rZ7IDalfaIIyd3VUWB6sNuAuvnqtFoJKemQWeJ8rGImV2rS6DUcIUdiL0K2xXKqr
mqs/6Tp1x9jlqAyPGTuEZvnfY0AzLXZSZFenU7tJf5HmhcgpBiV/4TmIEkEBtFvM
fVlxxr6vZTS9Ql+MiFKYJGXfQbFADUG9xnU1N6zqyHW/FJ/6CkwNsWcxgTbZLWct
rzPBZI9mui5GlsPcFl/XwARaXKpe8+wLhCvyLGVbKYEea8E9O3xErRo36WaiFCZ+
TZNLULna3zMf2WOIclu+633nGjuOgnCKhkpFoJbhgepEFs36WiIF8DMQzT48dLDG
6wLIf0AY6wd6B8GRV6CqOxWP9UR8UxCImN/eh7nt77wRQlSN6lHhKF++ZavQZ3KN
0ZQJQF8YPu0svBiuy9DEaH+42IjQYR6iJBrSZxQsq1hB1VVobIg=
=Mtj6
-END PGP SIGNATURE-

Bug#863749: libreoffice-calc: desktop freezes when moving multiple cells in libreoffice-calc

[Bert Schlumwig]

Package: libreoffice-calc
Version: 1:5.2.7-1
Severity: important

When in Calc-> View-> Page Break  mode multiple cells are selected and
being moved the desktop freezes. Mouse is able to being moved, but
can not click on anything anymore.

Reproducibly frequent.

In that case switching to alternate display is still possible
and the process termination.

Causes loss of data, since some of the progress may not be 
reliably restored.

Thanks!


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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3   2.8.12-1+b2
ii  coinor-libcoinmp1v5  1.7.6+dfsg1-2
ii  coinor-libcoinutils3v5   2.9.15-4
ii  dpkg 1.18.24
ii  libblas3 [libblas.so.3]  3.7.0-2
ii  libboost-filesystem1.62.01.62.0+dfsg-4
ii  libboost-iostreams1.62.0 1.62.0+dfsg-4
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-10
ii  libetonyek-0.1-1 0.1.6-5
ii  libgcc1  1:6.3.0-18
ii  libicu57 57.1-6
ii  liblapack3 [liblapack.so.3]  3.7.0-2
ii  liblcms2-2   2.8-4
ii  libmwaw-0.3-30.3.9-1
ii  libodfgen-0.1-1  0.1.6-2
ii  liborcus-0.11-0  0.11.2-3+b1
ii  libreoffice-base-core1:5.2.7-1
ii  libreoffice-core 1:5.2.7-1
ii  librevenge-0.0-0 0.0.4-6
ii  libstdc++6   6.3.0-18
ii  libwps-0.4-4 0.4.5-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  lp-solve 5.5.0.15-4+b1
ii  uno-libs35.2.7-1
ii  ure  5.2.7-1
ii  zlib1g   1:1.2.8.dfsg-5

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.2.11-1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.7+b1
ii  fonts-opensymbol  2:102.7+LibO5.2.7-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libc6 2.24-10
ii  libcairo2 1.14.8-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.1-8
ii  libcurl3-gnutls   7.52.1-5
ii  libdbus-1-3   1.10.18-1
ii  libdbus-glib-1-2  0.108-2
ii  libdconf1 0.26.0-2+b1
ii  libeot0   0.01-4+b1
ii  libexpat1 2.2.0-2
ii  libexttextcat-2.0-0   3.4.4-2+b1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglew2.02.0.0-3+b1
ii  libglib2.0-0  2.50.3-2
ii  libgltf-0.0-0v5   0.0.2-5
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.10-1
ii  libharfbuzz-icu0  1.4.2-1
ii  libharfbuzz0b 1.4.2-1
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu57  57.1-6
ii  libjpeg62-turbo   1:1.5.1-2
ii  liblangtag1   0.6.2-1
ii  liblcms2-22.8-4
ii  libldap-2.4-2 2.4.44+dfsg-4+b1
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libodfgen-0.1-1   0.1.6-2
ii  libpcre3  2:8.39-3
ii  libpng16-16   1.6.28-1
ii  librdf0   1.0.17-1.1
ii  libreoffice-common1:5.2.7-1
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.2-1+b3
ii  libstdc++66.3.0-18
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-2.2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-2.1
ii  uno-libs3 5.2.7-1
ii  ure   5.2.7-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages libreoffice-core recommends:
pn  libpaper-utils  

-- no debconf information

Bug#846219: Why wasn't the same change made to fusionforge-plugin-extsubproj?

[Nish Aravamudan]

While they are still broken, shouldn't the same changes be made to
$subject binary package:

diff -Nru fusionforge-6.0.4+20160504/debian/control 
fusionforge-6.0.4+20160504/debian/control
--- fusionforge-6.0.4+20160504/debian/control   2017-01-01 07:59:40.0 
-0800
+++ fusionforge-6.0.4+20160504/debian/control   2017-05-30 15:28:05.0 
-0700
@@ -449,7 +449,7 @@
  with content-negotiation (application/rdf+xml).
 
 Package: fusionforge-plugin-extsubproj
-Depends: fusionforge-web (=${source:Version}), libarc-php, 
fusionforge-plugin-compactpreview, ${misc:Depends}
+Depends: fusionforge-web (=${source:Version}), 
fusionforge-plugin-compactpreview, ${misc:Depends}
 Architecture: all
 Description: FusionForge plugin - External SubProjects
  FusionForge provides many tools to aid collaboration in a
diff -Nru fusionforge-6.0.4+20160504/debian/plugins 
fusionforge-6.0.4+20160504/debian/plugins
--- fusionforge-6.0.4+20160504/debian/plugins   2017-01-01 07:59:40.0 
-0800
+++ fusionforge-6.0.4+20160504/debian/plugins   2017-05-30 15:27:59.0 
-0700
@@ -46,7 +46,7 @@
 Depends: 
 
 Package: fusionforge-plugin-extsubproj
-Depends: libarc-php, fusionforge-plugin-compactpreview
+Depends: fusionforge-plugin-compactpreview
 
 Package: fusionforge-plugin-foafprofiles
 Depends:

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#863667: unblock: hexchat (pre-approval)

[Mattia Rizzolo]

Control: tag -1 - moreinfo

On Tue, May 30, 2017 at 08:13:10PM +0100, Jonathan Wiltshire wrote:
> Agree. Please go ahead and remove the moreinfo tag when it is ready to
> unblock.

That's good to go now.
Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Pim van Pelt]

On Tue, May 30, 2017 at 11:05 PM, Axel Beckert  wrote:
> Control: severity -1 important
> Control: tag -1 confirmed
>
> Hi Ansgar,
>
> Ansgar Burchardt wrote:
>> Severity: serious
>
> I disagree with severity.
>
>> SixXS will shutdown on 2017-06-06[1].
>
> Yes, well-known and already discussed (on IRC IIRC) by us package
> maintainers.
>
>> Unless there are other tunnel providers used with aiccu, it seems
>> useless to include in stretch.
>
> Yes, but before we decide to pull the line I want to wait until _at
> least_ that date (which is next week and not today) and _not_ pull the
> line _before_ this date.
Agreed, although the install base won't change between now and the
sunset, so I'm not too fussed about in-or-out at this point. See below
though.
> Pim van Pelt wrote:
>> It may be in our future to opensource the server implementation
>
> Any reason why you can't publish it as is?
https://sixxs.net/sunset describes this, here's the pertinent language:

| Will you open source SixXS code?
|
| We do not currently have plans to open source any code that is not
already publicly available.
| Although our provisioning servers and routing daemon (sixxsd) are
very well thought out, they
| do have some intricate dependencies on how we built SixXS. As such,
offering the code base
| will not be necessarily useful for others. Over time, given effort
on Jeroen’s part, this may
| change. We cannot make any promises at this point.

Additional thought -- I do not look forward to explaining to several
integrators how to use the server code, although it's reasonably
standalone, the SixXS server works in conjunction with our automation
bits on the provisioning server side. Also worth pointing out, if
you're interested, is this piece:

| Will you hand over the project to other folks?
|
| We are fairly protective of our brand and position in the community.
Due to the nature of SixXS,
| which rests on an open source client (aiccu) with a closed source
server (sixxsd), we are not
| willing to hand over the project. However, that aside, the main
justification for our decision as
| outlined in this document, is that we are of the belief that IPv6
Tunnel Brokers are no longer
| facilitating access providers moving to IPv6, and as such do not
wish for the project to be
| continued. Handing it over to other folks will not allow us to
satisfy our concerns.

If my mission is to stop tunnelbrokers, opensourcing the code is not
productive. However, we may change our mind after a certain cool-down
period. Time will tell, which is why I was opting for a resubmission
iff we decide to go that route.


>> but at that point we can stand up a repo for ourselves.
>
> This comment by Pim makes me even think that we should keeping it in
> Stretch. Because why else should upstream keep a Debian package
> maintained in an external repo if a suitable server will be available
> soon-ish?
>
>> Would you be open to resubmitting in such a scenario?
>
> Sure.
Thanks!

-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/

Bug#863705: [Aptitude-devel] Bug#863705: aptitude: symbol lookup error: aptitude: undefined symbol:

[Olly Betts]

So if I understand the issue correctly, it's that libxapian30 in
unstable is built with the new C++ ABI while libxapian30 in backports
was built with the old C++ ABI, so really should have been libxapian30v4
or something (not sure if there's a reverse convention to the v5
suffix)?

Sorry for not spotting that when I did the backport.  It worked fine in
my testing in a jessie environment - I guess you only see problems if
you try to run a mixed jessie/stretch environment.  Or perhaps if you
try to do the upgrade to stretch using aptitude.

On Tue, May 30, 2017 at 10:51:19PM +0200, Axel Beckert wrote:
> Hi Sven,
> 
> Sven Joachim wrote:
> > Control: reassign -1 libxapian30 1.4.1-1~bpo8+1
> 
> I wouldn't be so quick with reassigning.
> 
> > > aptitude: symbol lookup error: aptitude: undefined symbol: 
> > > _ZNK6Xapian8Database14postlist_beginERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
> > 
> > This happens because libxapian30 from jessie-backports is not compatible
> > with libstdc++6 from unstable
> 
> Hrm, this sounds to me as if aptitude's dependency on libxapian30
> should be more tight.

That addresses this for aptitude, but not other rdeps.  It's perhaps a
worse issue for aptitude, as you don't want your package management tool
broken while trying to upgrade packages.

> Or maybe even better: libstdc++6 should break with this version of
> libxapian30 from backports.

This seems to address the wider problem, but rather feels like it's
addressing it in the wrong place.

I can try to fix the xapian-core version in backports, but that only
helps people with 1.4.1-1~bpo8+1 installed if they upgrade from
backports before trying to mix in packages from stretch.

Not sure quite how much work that would be - it'll require coordinating
uploads of the rdeps using the backported xapian-core, but I don't know
of the top of my head how to get a list of those.  I know there's
xapian-omega; I thought notmuch was too, but that still seems to be on
libxapian22.

Cheers,
Olly

Bug#863746: fpc: Please adjust fp-units-gfx.install.in for linux-mips

[James Cowgill]

Hi Adrian,

On 30/05/17 22:46, John Paul Adrian Glaubitz wrote:
> Source: fpc
> Version: 3.0.0+dfsg-11
> Severity: normal
> Tags: patch
> User: debian-m...@lists.debian.org
> Usertags: mips
> 
> Hello!
> 
> I just bootstrapped fpc for mips. In order for the build to work the next
> time the buildds are building it, the debian/fp-units-gfx.install.in
> needs to be adjusted so that usr/lib/fpc/*/*/*/graph* and
> usr/lib/fpc/*/*/*/opencl* aren't missing during dh_install.
> 
> Thus:
> 
> diff -Nru old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in 
> new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in
> --- old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-04-09 
> 11:44:58.0 +0200
> +++ new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-05-30 
> 23:44:24.519488161 +0200
> @@ -1,11 +1,11 @@
>  #! /usr/bin/dh-exec
>  usr/lib/fpc/*/*/*/ggi*
> -usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
> !linux-ppc64]
> +usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
> !linux-mips !linux-ppc64]

While we're here, could we add mipsel to the list as well? For most
purposes it can be treated identically to mips.

And thanks for working on fpc for mips!

James



signature.asc
Description: OpenPGP digital signature

Bug#863519: unblock blockdiag/1.5.3+dfsg-2

[Kouhei Maeda]

2017-05-31 5:38 GMT+09:00 Jonathan Wiltshire :
> On Sun, May 28, 2017 at 08:51:27AM +0900, Kouhei Maeda wrote:
>> +export PYBUILD_BEFORE_BUILD=cp -a $(CURDIR)/src/blockdiag.egg-info
>> {build_dir};cp -f $(CURDIR)/debian/circle.* /tmp/
>
> Apologies for not spotting it sooner, but there's a symlink vulnerability
> here (imagine if /tmp/circle.* was a symlink to something important),
> and I'm not sure that you should hardcode /tmp either ($TMPDIR?).
>
> I'm a bit concerned there's more going on here than just the bug fixes.
> What would the minimum required changes to fix #860689 and #847930 look
> like?

Thanks,

This change is temporarily copied for use in unit test.
It is coping with PYBUILD_BEFORE_BUILD, but I should use PYBUILD_BEFORE_TEST.
And, I had deleted the necessary deletion processing of temporary
files with PYBUILD_AFTER_TEST.

I will fix these.

Regards,

--
Kouhei Maeda 
 KeyID 4096R/7E37CE41

Bug#863734: unblock: gnupg2/2.1.18-8

[Daniel Kahn Gillmor]

On Tue 2017-05-30 22:48:20 +0200, Cyril Brulebois wrote:
> Jonathan Wiltshire  (2017-05-30):
>> Control: tag -1 moreinfo
>> 
>> On Tue, May 30, 2017 at 12:41:48PM -0400, Daniel Kahn Gillmor wrote:
>> > Please unblock package gnupg2
>> > 
>> > The gnupg2 source package 2.1.18-8 contains a significant number of
>> > useful fixes from 2.1.18-6, and should be propagated into testing.
>> 
>> Cc-ing the d-i RM for an ack.
>
> TBF I'm not thrilled by the amount of patches and the limited time before
> the release. :(

I'm also not thrilled by the amount of patches, but these are clear
bugfixes from upstream. They've been in unstable for several weeks now,
and i've avoided an unblock specifically because i wanted to hear from
people that they solve their problems and don't introduce new ones.
that seems to be the case.  :/

> ISTR we mainly use gpgv from src:gnupg2, through the gpgv-udeb package.
> Any chance you could pinpoint changesets affecting it, so that I can
> concentrate on those only?

sure thing.  Most of these don't affect gpgv.  The most relevant patches
for gpgv are these two patches from upstream which have an effect on the
use of specific file descriptors (the first catches errors in
mis-configured invocations, and the second ensures that gpgv works
cross-platform on windows):

0032-gpg-common-Make-sure-that-all-fd-given-are-valid.patch
debian/patches/0040-gpgv-w32-Fix-status-fd.patch

however, the following other patches since 2.1.18-6 all touch some
source file that contributes to the build of gpgv, though i think none
of them are relevant for gpgv generally, let alone for d-i's specific
use of gpgv -- the gpgv source is just mixed together with
GnuPG's other functionality:

0044-gpg-Make-export-options-work-with-export-secret-keys.patch
0048-gpg-Fix-attempt-to-double-free-an-UID-structure.patch
0050-gpg-Flush-stdout-before-printing-stats-with-check-si.patch
0059-gpg-Handle-critical-marked-Reason-for-Revocation.patch
0065-gpg-Fix-printing-of-offline-taken-subkey.patch
0072-g10-Minor-fixes.patch
0074-g10-invalidate-the-fd-cache-for-keyring.patch
avoid-spurious-warnings/0078-gpg-Avoid-spurious-warnings-about-trust-packets.patch
skel-file-removal/0077-g10-remove-skeleton-options-files.patch
skip-missing-signing-keys/0076-g10-Skip-signing-keys-where-no-secret-key-is-availab.patch

(for example, gpgv doesn't do export-secret-keys at all, but it does
include g10/main.h, which that 0044-*.patch does have to modify.
similarly, gpgv doesn't read config files at all, but
skel-file-removal/0077*.patch touches g10/openfile.c.)

Let me know if you have any more questions,

--dkg


signature.asc
Description: PGP signature

Bug#863748: fpc: Please add manpage for ppcmips command

[John Paul Adrian Glaubitz]

Source: fpc
Version: 3.0.0+dfsg-11
Severity: normal
Tags: patch

Hi!

Since building src:fpc successfully requires a manpage for the native
ppc$CPU binary, we need to add one for ppcmips as well since the package
source is currently not shipping one.

I have just created a copy of the corresponding patch for arm64 to add
a manpage (add_arm64_manpage.patch) and reg-replaced all occurrences
of "ppca64" with "ppcmips".

Please include the patch with the next upload. With the changes from
#863746 [1] and #863747 [2], fpc can be built on the buildds for mips
without any problems, provided that at least version 3.0.2 is used.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863746
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863747
Description: In order to add support for arm64, we need a man-page
Source: upstream

Index: fpc/install/man/man1/ppcmips.1
===
--- /dev/null
+++ fpc/install/man/man1/ppcmips.1
@@ -0,0 +1,33 @@
+.TH ppcmips 1 "30 may 1999" "Free Pascal" "Free Pascal Compiler"
+.SH NAME
+ppcmips \- Free Pascal Compiler (FPC) binary, name derived 
+from Portable Pascal Compiler
+
+.SH SYNOPSIS
+
+.B "ppcmips [options] [sourcefile]"
+.BR
+
+.SH DESCRIPTION
+This binary is the back-end binary of the
+.I Free Pascal Compiler (FPC)
+which is a
+.I Turbo Pascal
+and
+.I Delphi (7.0) 
+compatible standalone (non GCC frontend) multitarget Pascal compiler.
+
+This binary should not be called directly, instead the 
+.B fpc
+program should be used instead. 
+It will choose the right back-end for compiling units for the requested 
platforms.
+
+.SH OPTIONS
+
+For a complete list of all supported command-line options, see the
+.BR fpc (1)
+manual page.
+
+.SH SEE ALSO
+.BR  fpc (1)
+

Bug#863453: unblock: acmetool/0.0.59-1

[Jonathan Wiltshire]

Hi,

On Tue, May 30, 2017 at 08:45:26AM -0400, Peter Colberg wrote:
> Control: tag -1 - moreinfo
> 
> On Mon, May 29, 2017 at 01:11:47PM +0100, Jonathan Wiltshire wrote:
> > None of these issues seem to have corresponding BTS bugs. If they did,
> > which severity would you choose? (hint: if they're not at least
> > 'serious'...)
> 
> I would assign the following severities:
> 
>   * Validate hostnames in 'acmetool want' [1]
> 
> Severity: normal
> 
> This improves the error handling when the user passes an invalid host 
> name.
> 
> https://github.com/hlandau/acme/issues/204
> 
>   * Allow environment variables to be passed to challenge hooks [2]
> 
> Severity: normal
> 
> https://github.com/hlandau/acme/issues/166 

These would be nice in the long term, but I don't really think they're
critical right now.

>   * Allow acmeapi to obtain new nonces if nonce pool is depleted [3]
> 
> Severity: important
> 
> This fixes a potential failure to acquire certificates.
> 
> https://github.com/hlandau/acme/issues/214

Let's assume that if the Let's Encrypt responder is giving you 503s, it's
game over anyway.

>   * Don't attempt fdb permission tests on non-cgo builds [4]
> 
> Severity: serious
> 
> This fixes an FTBFS on architectures using gcc-go.

Does this actually affect stretch builds, or just architectures outside
those?

> https://github.com/hlandau/acme/issues/219
> 
>   * Add read/write timeouts to redirector server [5]
> 
> Severity: serious
> 
> This fixes a denial-of-service in the HTTP-to-HTTPS redirector.

Is this likely, given there is only really one set of (proabably
well-behaved) clients in the real world? Possibly I've misunderstood the
purpose of this redirector.

>   * Allow hidden files within the state directory [6]
> 
> Severity: important
> 
> This ignores dot files in /var/lib/acme, e.g., .git/.
> 
> https://github.com/hlandau/acme/issues/153

This might be a bit noisy, but it's not a show-stopper is it?

I'm erring on the side of deferring all of these and cherry-picking them if
real-world issues get reported for stable. It's an awful lot of changes for
this late in the process and not really suitable.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863747: fpc: Please add mips as CPU_TARGET in debian/rules

[John Paul Adrian Glaubitz]

Source: fpc
Version: 3.0.0+dfsg-11
Severity: normal
Tags: patch
User: debian-m...@lists.debian.org
Usertags: mips

Hello!

In order for src:fpc to build on mips, the architecture needs to be added
to the list of CPU targets in debian/rules. This is necessary because the
resulting binary for the portable Pascal compiler is ppc$CPU and without
adding mips to the list, the rules file will search for "ppc" instead of
"ppcmips".

The change itself is trivial:

diff -Nru old/fpc-3.0.2+dfsg/debian/rules new/fpc-3.0.2+dfsg/debian/rules
--- old/fpc-3.0.2+dfsg/debian/rules 2017-04-09 11:44:58.0 +0200
+++ new/fpc-3.0.2+dfsg/debian/rules 2017-05-30 23:52:09.875391597 +0200
@@ -57,6 +57,9 @@
 ifeq ($(CPU_TARGET),sparc)
 PPSUF=sparc
 endif
+ifeq ($(CPU_TARGET),mips)
+PPSUF=mips
+endif
 
 ifneq ($(CPU_SOURCE),$(CPU_TARGET))
 PPPRE=ppcross

Could you apply this change for the next upload?

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/fpc-3.0.2+dfsg/debian/rules new/fpc-3.0.2+dfsg/debian/rules
--- old/fpc-3.0.2+dfsg/debian/rules 2017-04-09 11:44:58.0 +0200
+++ new/fpc-3.0.2+dfsg/debian/rules 2017-05-30 23:52:09.875391597 +0200
@@ -57,6 +57,9 @@
 ifeq ($(CPU_TARGET),sparc)
 PPSUF=sparc
 endif
+ifeq ($(CPU_TARGET),mips)
+PPSUF=mips
+endif
 
 ifneq ($(CPU_SOURCE),$(CPU_TARGET))
 PPPRE=ppcross

Bug#863671: (no subject)

[W. Martin Borgert]

Hi Matt, hi all,

does somebody have a test case for the vulnerability?

After trying fruitlessly to adapt the code from version 2.2 to
our 1.7, I managed to bring the old code change to our even
older version. But I have no idea, whether it is any good, other
that it compiles. But without test case, the patch is not valid.

Also, I'm happy about any critical review of the patch.

TIA!
Description: fix CVE-2015-9059 (command injection vulnerability)
Origin: upstream
Bug-Vendor: https://bugs.debian.org/863671
Applied-Upstream: 
https://github.com/npat-efault/picocom/commit/1ebc60b20fbe9a02436d5cbbf8951714e749ddb1
Last-Update: 2017-05-30
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/picocom.c
+++ b/picocom.c
@@ -41,6 +41,7 @@
 #define _GNU_SOURCE
 #include 
 
+#include "split.h"
 #include "term.h"
 
 /**/
@@ -549,6 +550,9 @@
 {
 }
 
+#define RUNCMD_ARGS_MAX 32
+#define RUNCMD_EXEC_FAIL 126
+
 void
 establish_child_signal_handlers (void)
 {
@@ -564,7 +568,7 @@
 }
 
 int
-run_cmd(int fd, ...)
+run_cmd(int fd, const char *cmd, const char *args_extra)
 {
pid_t pid;
sigset_t sigm, sigm_old;
@@ -602,7 +606,9 @@
/* child: external program */
int r;
long fl;
-   char cmd[512];
+
+   int argc;
+   char *argv[RUNCMD_ARGS_MAX + 1];
 
establish_child_signal_handlers();
sigprocmask(SIG_SETMASK, _old, NULL);
@@ -619,30 +625,31 @@
close(STO);
dup2(fd, STI);
dup2(fd, STO);
-   {
-   /* build command-line */
-   char *c, *ce;
-   const char *s;
-   int n;
-   va_list vls;
-   
-   c = cmd;
-   ce = cmd + sizeof(cmd) - 1;
-   va_start(vls, fd);
-   while ( (s = va_arg(vls, const char *)) ) {
-   n = strlen(s);
-   if ( c + n + 1 >= ce ) break;
-   memcpy(c, s, n); c += n;
-   *c++ = ' ';
-   }
-   va_end(vls);
-   *c = '\0';
+
+   /* build command arguments vector */
+   argc = 0;
+   r = split_quoted(cmd, , argv, RUNCMD_ARGS_MAX);
+   if ( r < 0 ) {
+   fd_printf(STDERR_FILENO, "Cannot parse command\n");
+   exit(RUNCMD_EXEC_FAIL);
}
-   /* run extenral command */
-   fd_printf(STDERR_FILENO, "%s\n", cmd);
-   r = system(cmd);
-   if ( WIFEXITED(r) ) exit(WEXITSTATUS(r));
-   else exit(128);
+   r = split_quoted(args_extra, , argv, RUNCMD_ARGS_MAX);
+   if ( r < 0 ) {
+   fd_printf(STDERR_FILENO, "Cannot parse extra args\n");
+   exit(RUNCMD_EXEC_FAIL);
+   }
+   if ( argc < 1 ) {
+   fd_printf(STDERR_FILENO, "No command given\n");
+   exit(RUNCMD_EXEC_FAIL);
+   }   
+   argv[argc] = NULL;
+
+   /* run external command */
+   fd_printf(STDERR_FILENO, "$ %s %s\n", cmd, args_extra);
+   execvp(argv[0], argv);
+
+   fd_printf(STDERR_FILENO, "exec: %s\n", strerror(errno));
+   exit(RUNCMD_EXEC_FAIL);
}
 }
 
@@ -807,7 +814,7 @@
if ( r < -1 && errno == EINTR ) break;
if ( r <= -1 )
fatal("cannot read filename: 
%s", strerror(errno));
-   run_cmd(tty_fd, opts.send_cmd, fname, 
NULL);
+   run_cmd(tty_fd, opts.send_cmd, fname);
break;
case KEY_RECEIVE:
fd_printf(STO, "*** file: ");
@@ -817,7 +824,7 @@
if ( r <= -1 )
fatal("cannot read filename: 
%s", strerror(errno));
if ( fname[0] )
-   run_cmd(tty_fd, 
opts.receive_cmd, fname, NULL);
+   run_cmd(tty_fd, 
opts.receive_cmd, fname);
else
run_cmd(tty_fd, 
opts.receive_cmd, NULL);
break;
--- a/Makefile
+++ b/Makefile
@@ -13,11 +13,12 @@
 LDFLAGS = -g
 LDLIBS =
 
-picocom : picocom.o term.o
+picocom : picocom.o 

Bug#863179: File trusted.gpg could be the culprit.

[OddN]

Package: apt
Version: 1.4.4
Followup-For: Bug #863179

Hi Pete and Julian,

On my system - details below - similar behavior was coused by the file
/etc/apt/trusted.gpg, once I moved it out of the way all is well.

Pete please try:
# mv /etc/apt/trusted.gpg /etc/apt/untrusted
# apt-get update
Did that help?

Julian, sorry I destroid the evidence, after an:
# apt-key --keyring /etc/apt/untrusted  list
returned nothing...
# rm /etc/apt/no-trust

I Should open a new report for that, but while at it the search got me here and
it seemed relevant... anyway:
the file /etc/apt/trusted.gpg was mod 0600, which only gave a warning and went
along with that for a while.
It realy got in the way only once I chmoded it 0644.

I don't know where the file came from, it seemed to be a valid empty gpg key
file. Could be DI leftovers, I used RC-3.
dpkg is no help here:
root@delight:~# dpkg -S /etc/apt/trusted.gpg
dpkg-query: no path found matching pattern /etc/apt/trusted.gpg

root@delight:~# dpkg -S trusted.gpg
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-jessie-
automatic.gpg
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-wheezy-
automatic.gpg
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-jessie-security-
automatic.gpg
apt, debian-archive-keyring: /etc/apt/trusted.gpg.d
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-stretch-security-
automatic.gpg
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-stretch-
automatic.gpg
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-stretch-
stable.gpg
debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg

So long, odd.



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
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\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-3-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::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::MaxAge "30";
APT::Periodic::MinAge "2";
APT::Periodic::MaxSize "500";

Bug#816435: TestStartProjectSettings fails on DebCI

[Chris Lamb]

Hi,

> TestStartProjectSettings fails on DebCI

I've sent a patch upstream:

  https://code.djangoproject.com/ticket/26755#comment:2


Regards,

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

Bug#863731: fixed in sudo 1.8.20p1-1

[Moritz Muehlenhoff]

On Tue, May 30, 2017 at 09:18:39PM +, Bdale Garbee wrote:
> Source: sudo
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Tue, 30 May 2017 14:41:58 -0600
> Source: sudo
> Binary: sudo sudo-ldap
> Architecture: source amd64
> Version: 1.8.20p1-1
> Distribution: unstable
> Urgency: high
> Maintainer: Bdale Garbee 
> Changed-By: Bdale Garbee 
> Description:
>  sudo   - Provide limited super user privileges to specific users
>  sudo-ldap  - Provide limited super user privileges to specific users
> Closes: 863731
> Changes:
>  sudo (1.8.20p1-1) unstable; urgency=high

Testing still has 1.8.19, what's the plan for stretch?

Cheers,
Moritz

Bug#863746: fpc: Please adjust fp-units-gfx.install.in for linux-mips

[John Paul Adrian Glaubitz]

Source: fpc
Version: 3.0.0+dfsg-11
Severity: normal
Tags: patch
User: debian-m...@lists.debian.org
Usertags: mips


Hello!

I just bootstrapped fpc for mips. In order for the build to work the next
time the buildds are building it, the debian/fp-units-gfx.install.in
needs to be adjusted so that usr/lib/fpc/*/*/*/graph* and
usr/lib/fpc/*/*/*/opencl* aren't missing during dh_install.

Thus:

diff -Nru old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in 
new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in
--- old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-04-09 
11:44:58.0 +0200
+++ new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-05-30 
23:44:24.519488161 +0200
@@ -1,11 +1,11 @@
 #! /usr/bin/dh-exec
 usr/lib/fpc/*/*/*/ggi*
-usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-ppc64]
+usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-mips !linux-ppc64]
 usr/lib/fpc/*/*/*/hermes*
 usr/lib/fpc/*/*/*/imagemagick*
 usr/lib/fpc/*/*/*/libgd*
 usr/lib/fpc/*/*/*/libpng*
-usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-powerpc !linux-ppc64]
+usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-mips !linux-powerpc !linux-ppc64]
 usr/lib/fpc/*/*/*/opengl*
 usr/lib/fpc/*/*/*/opengles*
 usr/lib/fpc/*/*/*/ptc*  [!freebsd-any]

Could you apply this change for the next upload?

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in 
new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in
--- old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-04-09 
11:44:58.0 +0200
+++ new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-05-30 
23:44:24.519488161 +0200
@@ -1,11 +1,11 @@
 #! /usr/bin/dh-exec
 usr/lib/fpc/*/*/*/ggi*
-usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-ppc64]
+usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
!linux-mips !linux-ppc64]
 usr/lib/fpc/*/*/*/hermes*
 usr/lib/fpc/*/*/*/imagemagick*
 usr/lib/fpc/*/*/*/libgd*
 usr/lib/fpc/*/*/*/libpng*
-usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-powerpc !linux-ppc64]
+usr/lib/fpc/*/*/*/opencl*   [!freebsd-any !linux-arm64 !linux-armel 
!linux-armhf !linux-mips !linux-powerpc !linux-ppc64]
 usr/lib/fpc/*/*/*/opengl*
 usr/lib/fpc/*/*/*/opengles*
 usr/lib/fpc/*/*/*/ptc*  [!freebsd-any]

Bug#863689: unblock: cracklib2/2.9.2-5

[Cyril Brulebois]

Niels Thykier  (2017-05-30):
> Hi KiBi (X-CC'ed),
> 
> I would like to unblock cracklib2 as it fixes #854554.  To my knowlegde, it
> has no changes that affects its udeb, the diff being:
> 
> """
> diff -Nru cracklib2-2.9.2/debian/changelog cracklib2-2.9.2/debian/changelog
> --- cracklib2-2.9.2/debian/changelog2017-04-08 11:25:28.0 +
> +++ cracklib2-2.9.2/debian/changelog2017-05-27 09:41:18.0 +
> @@ -1,3 +1,10 @@
> +cracklib2 (2.9.2-5) unstable; urgency=medium
> +
> +  * Add Breaks: cracklib-runtime (<< 2.9.2-4) to libcrack2 to configure
> +cracklib-runtime in the correct order (Closes: #854554)
> +
> + -- Jan Dittberner   Sat, 27 May 2017 11:41:18 +0200
> +
>  cracklib2 (2.9.2-4) unstable; urgency=medium
>  
>* Migrate triggers to interest-noawait to avoid trigger-cycles (Closes:
> diff -Nru cracklib2-2.9.2/debian/control cracklib2-2.9.2/debian/control
> --- cracklib2-2.9.2/debian/control  2017-04-08 11:25:28.0 +
> +++ cracklib2-2.9.2/debian/control  2017-05-27 09:06:18.0 +
> @@ -28,6 +28,7 @@
>  Pre-Depends: ${misc:Pre-Depends}
>  Depends: ${misc:Depends}, ${shlibs:Depends}
>  Recommends: cracklib-runtime
> +Breaks: cracklib-runtime (<< 2.9.2-4)
>  Description: pro-active password checker library
>   Shared library for cracklib2 which contains a C function which may be
>   used in a passwd like program. The idea is simple: try to prevent
> """
> 
> unblock cracklib2/2.9.2-5
> 
> I would age it so it migrates before this weekend.

No objections, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#863267: [Python-modules-team] Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8

[Brian May]

Raphael Hertzog  writes:

> Is that actually true? linaro_django_xmlrpc seems to be listed in
> INSTALLED_APPS, no?
>
> Do you have any idea why it would give this error?

I note that linaro_django_xmlrpc is towards the end of
INSTALLED_APPS. Maybe it did not get loaded?

Maybe it stopped loading apps the moment it detects a bad dependancy?

After looking at the code, this doesn't exactly make sense, but maybe
something here might help regardless.
-- 
Brian May 

Bug#863705: aptitude: symbol lookup error: aptitude: undefined symbol:

[Axel Beckert]

Control: clone -1 -2
Control: reassign -2 libstdc++6 6.3.0-18
Control: retitle -2 libstdc++6: Add versioned Breaks against 
libxapian30/1.4.1-1~bpo8+1
Control: severity -2 serious

Hi,

Sven Joachim wrote:
> >> > aptitude: symbol lookup error: aptitude: undefined symbol:
> >> _ZNK6Xapian8Database14postlist_beginERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
> >> 
> >> This happens because libxapian30 from jessie-backports is not compatible
> >> with libstdc++6 from unstable
[...]
> > Or maybe even better: libstdc++6 should break with this version of
> > libxapian30 from backports.
> 
> That's probably the most realistic way considering the proximity of the
> stretch release.

Cloning this bug report accordingly against libstdc++6.

Debian Release Team: Feel free to downgrade the severity of the cloned
bug report. For now, I leave it at RC.

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

Bug#863744: ITP: breezy -- easy to use distributed version control system

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: breezy
  Version : 3.0.0
  Upstream Author : Martin 
Jelmer Vernooij 
Bazaar Developers 
* URL : https://launchpad.net/brz
* License : GPL
  Programming Lang: Python
  Description : easy to use distributed version control system

 Breezy is a distributed version control system designed to be easy to
 use and intuitive, able to adapt to many workflows, reliable, and
 easily extendable.
 .
 Breezy is a fork of the Bazaar version control system, aimed to run
 with Python 3 and bundle most core plugins.

Bug#863705: aptitude: symbol lookup error: aptitude: undefined symbol:

[Sven Joachim]

On 2017-05-30 22:51 +0200, Axel Beckert wrote:

> Sven Joachim wrote:
>> Control: reassign -1 libxapian30 1.4.1-1~bpo8+1
>
> I wouldn't be so quick with reassigning.
>
>> > aptitude: symbol lookup error: aptitude: undefined symbol:
>> _ZNK6Xapian8Database14postlist_beginERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
>> 
>> This happens because libxapian30 from jessie-backports is not compatible
>> with libstdc++6 from unstable
>
> Hrm, this sounds to me as if aptitude's dependency on libxapian30
> should be more tight.

True, but this is not aptitude's call.  The way to achieve it is to bump
shlibs in libxapian30 and rebuild its reverse dependencies.

> Or maybe even better: libstdc++6 should break with this version of
> libxapian30 from backports.

That's probably the most realistic way considering the proximity of the
stretch release.

Cheers,
   Sven

Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

[Axel Beckert]

Control: severity -1 important
Control: tag -1 confirmed

Hi Ansgar,

Ansgar Burchardt wrote:
> Severity: serious

I disagree with severity.

> SixXS will shutdown on 2017-06-06[1].

Yes, well-known and already discussed (on IRC IIRC) by us package
maintainers.

> Unless there are other tunnel providers used with aiccu, it seems
> useless to include in stretch.

Yes, but before we decide to pull the line I want to wait until _at
least_ that date (which is next week and not today) and _not_ pull the
line _before_ this date.

Pim van Pelt wrote:
> It may be in our future to opensource the server implementation

Any reason why you can't publish it as is?

> but at that point we can stand up a repo for ourselves.

This comment by Pim makes me even think that we should keeping it in
Stretch. Because why else should upstream keep a Debian package
maintained in an external repo if a suitable server will be available
soon-ish?

> Would you be open to resubmitting in such a scenario?

Sure.

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

Bug#863705: [Aptitude-devel] Bug#863705: aptitude: symbol lookup error: aptitude: undefined symbol:

[Axel Beckert]

Hi Sven,

Sven Joachim wrote:
> Control: reassign -1 libxapian30 1.4.1-1~bpo8+1

I wouldn't be so quick with reassigning.

> > aptitude: symbol lookup error: aptitude: undefined symbol: 
> > _ZNK6Xapian8Database14postlist_beginERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
> 
> This happens because libxapian30 from jessie-backports is not compatible
> with libstdc++6 from unstable

Hrm, this sounds to me as if aptitude's dependency on libxapian30
should be more tight.

Or maybe even better: libstdc++6 should break with this version of
libxapian30 from backports.

> (and should not have been uploaded to jessie-backports in the first
> place, or under a different package name).

Ok, yes, but that doesn't really help to solve this issue. :-/

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

Bug#862258: add an user for mlmmj

[Geert Stappers]

Control: reopen -1
Stop

Ticket reopened so the BTS accepts further updates.

Bug#863734: unblock: gnupg2/2.1.18-8

[Cyril Brulebois]

Jonathan Wiltshire  (2017-05-30):
> Control: tag -1 moreinfo
> 
> On Tue, May 30, 2017 at 12:41:48PM -0400, Daniel Kahn Gillmor wrote:
> > Please unblock package gnupg2
> > 
> > The gnupg2 source package 2.1.18-8 contains a significant number of
> > useful fixes from 2.1.18-6, and should be propagated into testing.
> 
> Cc-ing the d-i RM for an ack.

TBF I'm not thrilled by the amount of patches and the limited time before
the release. :(

ISTR we mainly use gpgv from src:gnupg2, through the gpgv-udeb package.
Any chance you could pinpoint changesets affecting it, so that I can
concentrate on those only?

Thanks already.


KiBi.


signature.asc
Description: Digital signature

Bug#863640: retext: I install retext, try to run it, it segfault, please see output below

[Benoit Barthelet]

no worries, I got it running from git :) works fine now thanks a lot

On Tue, May 30, 2017 at 9:39 PM, Dmitry Shachnev  wrote:

> On Tue, May 30, 2017 at 03:00:25PM +0200, Benoit Barthelet wrote:
> > here it is
> >
> > ➜  ~ python3 -X faulthandler /usr/bin/retext
> > Using configuration file: /home/lotso/.config/ReText project/ReText.conf
> > Fatal Python error: Segmentation fault
> >
> > Current thread 0x7f7f0a0b9700 (most recent call first):
> >   File "/usr/share/retext/ReText/xsettings.py", line 132 in
> get_raw_xsettings
> >   File "/usr/share/retext/ReText/xsettings.py", line 187 in
> get_xsettings
> >   File "/usr/share/retext/ReText/icontheme.py", line 20 in
> get_from_xsettings
> >   File "/usr/share/retext/ReText/icontheme.py", line 49 in
> get_icon_theme
> >   File "/usr/share/retext/ReText/window.py", line 68 in __init__
> >   File "/usr/bin/retext", line 74 in main
> >   File "/usr/bin/retext", line 102 in 
> > [1]19648 segmentation fault  python3 -X faulthandler /usr/bin/retext
> > ➜  ~
>
> Thank you!
>
> Fixed upstream in [1], will be in the next upload. Probably too late for
> Stretch release though.
>
> A workaround would be creating a configuration file with contents like
> this:
>
> [General]
> iconTheme=Adwaita
>
> (Replace Adwaita with your favourite icon theme.)
>
> [1]: https://github.com/retext-project/retext/commit/fb5c5b8aae2ce904
>
> --
> Dmitry Shachnev
>



-- 
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get=0xF150E01A72F6D2EE

Bug#816781: [Aptitude-devel] Bug#816781: aptitude: Can not cancel pending upgrade actions

[Axel Beckert]

Hi Cesare,

Cesare Leonardi wrote:
> On 29/05/2017 11:31, Axel Beckert wrote:
> >Before you press the corresponding menu entry, but after already
> >having selected it, aptitude will show the following long description
> >in the status line:
> >
> >  Cancel all pending actions from this session
>
> >So this menu entry only cancels actions which weren't scheduled in
> >previous sessions on purpose.
> 
> Thank you Axel for the detailed and clear explanation.
> I admit i've never noted the string in the status bar...
> 
> >So maybe we should be a little bit more verbose with the short
> >description in the menu or maybe even split "Cancel pending actions"
> >into two separate menu entries:
> >
> >* Cancel pending actions of this session
> >* Cancel all pending actions
> >
> >or similar.
> 
> It will be wonderful to have two entries, because "Cancel all
> pending actions" is quite self explanatory, will match the previous
> behaviour

I couldn't remember that we changed that, but this change was indeed a
bugfix in 0.7.6 from February 2016:

  * [curses] "Cancel pending actions" now reloads the cache (roughly
equivalent to restarting the program), rather than marking all packages
as "keep" plus ruining all auto-installed flags and holds
(Closes: #537735, #576319)

> and users should not be surprised upgrading from Debian 8 to 9.
> 
> But isn't it too late for Stretch?

For a change of behaviour: Yes, it's too late.

> Anyway, I think that making a note at least in NEWS.Debian could be helpful.

That mmight be possible, but I can't promise it.

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

Bug#863519: unblock blockdiag/1.5.3+dfsg-2

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Sun, May 28, 2017 at 08:51:27AM +0900, Kouhei Maeda wrote:
> +export PYBUILD_BEFORE_BUILD=cp -a $(CURDIR)/src/blockdiag.egg-info
> {build_dir};cp -f $(CURDIR)/debian/circle.* /tmp/

Apologies for not spotting it sooner, but there's a symlink vulnerability
here (imagine if /tmp/circle.* was a symlink to something important),
and I'm not sure that you should hardcode /tmp either ($TMPDIR?).

I'm a bit concerned there's more going on here than just the bug fixes.
What would the minimum required changes to fix #860689 and #847930 look
like?

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863734: unblock: gnupg2/2.1.18-8

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Tue, May 30, 2017 at 12:41:48PM -0400, Daniel Kahn Gillmor wrote:
> Please unblock package gnupg2
> 
> The gnupg2 source package 2.1.18-8 contains a significant number of
> useful fixes from 2.1.18-6, and should be propagated into testing.

Cc-ing the d-i RM for an ack.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863730: unblock: gnome-calendar/3.22.4-2

[Michael Biebl]

Am 30.05.2017 um 22:03 schrieb Jonathan Wiltshire:
> Control: tag -1 moreinfo
> 
> Hi,
> 
> On Tue, May 30, 2017 at 04:53:41PM +0200, Michael Biebl wrote:
>> Please unblock package gnome-calendar
>>
>> It's a targetted two-line fix for a crasher bug:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858924
>>
>> The patch is from upstream, the package has already been uploaded and
>> was successfully built everywhere.
> 
> Unfortunately it's stuck behind a new upstream from March. Is this worth
> trying to revert or do through t-p-u, or better abandoned?

Hm,...
Given the tiny diff between 3.22.3 and 3.22.4 and the fact that 3.22.4
has been in unstable for 2 months without new bug reports, maybe
unblocking 3.22.4-1 would be the best option.

Other then that, I'd be willing to prepare a tpu upload.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/NEWS b/NEWS
index 801c6ec..8e490ac 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+Major changes in 3.22.4:
+* Fix outstanding performance issue in Year view
+
 Major changes in 3.22.3:
 * Only decrease search counter when something is removed (Georges Basile Stavracas Neto)
 * Focus entry after calendar selection in quick popover (Mohammed Sadiq)
diff --git a/configure.ac b/configure.ac
index 9741b40..7f304f8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
 dnl -*- mode: m4 -*-
 AC_PREREQ([2.69])
-AC_INIT([gnome-calendar],[3.22.3],[http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-calendar],[gnome-calendar],[https://wiki.gnome.org/Apps/Calendar])
+AC_INIT([gnome-calendar],[3.22.4],[http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-calendar],[gnome-calendar],[https://wiki.gnome.org/Apps/Calendar])
 
 AX_IS_RELEASE([minor-version])
 
diff --git a/data/appdata/org.gnome.Calendar.appdata.xml.in b/data/appdata/org.gnome.Calendar.appdata.xml.in
index e69de4b..3f9851f 100644
--- a/data/appdata/org.gnome.Calendar.appdata.xml.in
+++ b/data/appdata/org.gnome.Calendar.appdata.xml.in
@@ -42,6 +42,16 @@
   GNOME
 
   
+
+  
+
+  This is the fifth stable release for GNOME Calendar 3.22, and fixes
+  an outstanding performance issue in Year view.
+
+Thanks to all the contributors that worked on GNOME Calendar!
+  
+
+
 
   
 
diff --git a/src/gcal-window.c b/src/gcal-window.c
index f4a4945..85c799f 100644
--- a/src/gcal-window.c
+++ b/src/gcal-window.c
@@ -702,7 +702,7 @@ set_new_event_mode (GcalWindow *window,
   /* for now we relaunch the new-event widget */
   if (!enabled && gtk_widget_is_visible (window->quick_add_popover))
 {
-  gtk_widget_set_visible (window->quick_add_popover, FALSE);
+  gtk_popover_popdown (GTK_POPOVER (window->quick_add_popover));
 }
 }
 
@@ -750,7 +750,7 @@ show_new_event_widget (GcalView   *view,
   rect.height = 1;
 
   gtk_popover_set_pointing_to (GTK_POPOVER (window->quick_add_popover), );
-  gtk_widget_show (window->quick_add_popover);
+  gtk_popover_popup (GTK_POPOVER (window->quick_add_popover));
 }
 
 static void
diff --git a/src/gcal-year-view.c b/src/gcal-year-view.c
index e1c5d4c..79612be 100644
--- a/src/gcal-year-view.c
+++ b/src/gcal-year-view.c
@@ -108,6 +108,13 @@ struct _GcalYearView
 
   /* date property */
   icaltimetype *date;
+
+  /*
+   * Array with the events at every month. Events
+   * that span multiple months are added multiple
+   * times to the array.
+   */
+  GPtrArray*events[12];
 };
 
 enum {
@@ -650,6 +657,45 @@ calculate_day_month_for_coord (GcalYearView *year_view,
   *out_day = day;
   return TRUE;
 }
+static guint
+count_events_at_day (GcalYearView *self,
+ icaltimetype *today)
+{
+  g_autoptr (GDateTime) today_start, today_end;
+  GPtrArray *events;
+  guint i, n_events;
+
+  events = self->events[today->month - 1];
+  n_events = 0;
+  today_start = icaltime_to_datetime (today);
+  today_end = g_date_time_add_days (today_start, 1);
+
+  for (i = 0; i < events->len; i++)
+{
+  g_autoptr (GDateTime) event_start, event_end;
+  GcalEvent *event;
+
+  event = g_ptr_array_index (events, i);
+
+  event_start = g_date_time_ref (gcal_event_get_date_start (event));
+
+  if (gcal_event_get_all_day (event))
+  event_end = g_date_time_add_days (gcal_event_get_date_end (event), -1);
+  else
+  event_end = g_date_time_ref (gcal_event_get_date_end (event));
+
+
+  if (datetime_compare_date (event_start, today_end) >= 0 ||
+  datetime_compare_date (event_end, today_start) < 0)
+{
+  continue;
+}
+
+  n_events++;
+}
+
+  return n_events;
+}
 
 static void
 draw_month_grid (GcalYearView *year_view,
@@ -671,8 +717,7 @@ draw_month_grid (GcalYearView *year_view,
   gint days_delay, days, shown_rows, sunday_idx;
   gchar *str, *nr_day, *nr_week;
   gboolean selected_day;
-  GList *events;
-  icaltimetype start_date, 

Bug#863742: libllvm-5.0-ocaml-dev and libllvm-4.0-ocaml-dev: error when trying to install together

[Ralf Treinen]

Package: libllvm-4.0-ocaml-dev,libllvm-5.0-ocaml-dev
Version: libllvm-4.0-ocaml-dev/1:4.0.1~+rc1-1
Version: libllvm-5.0-ocaml-dev/1:5.0~svn301421-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2017-05-30
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:



Extracting templates from packages: 46%
Extracting templates from packages: 92%
Extracting templates from packages: 100%
Selecting previously unselected package liblz4-1:amd64.
(Reading database ... 11003 files and directories currently installed.)
Preparing to unpack .../liblz4-1_0.0~r131-2+b1_amd64.deb ...
Unpacking liblz4-1:amd64 (0.0~r131-2+b1) ...
Processing triggers for libc-bin (2.24-11) ...
Setting up liblz4-1:amd64 (0.0~r131-2+b1) ...
Processing triggers for libc-bin (2.24-11) ...
Selecting previously unselected package gcc-6-base:amd64.
(Reading database ... 11009 files and directories currently installed.)
Preparing to unpack .../gcc-6-base_6.3.0-18_amd64.deb ...
Unpacking gcc-6-base:amd64 (6.3.0-18) ...
Setting up gcc-6-base:amd64 (6.3.0-18) ...
(Reading database ... 11016 files and directories currently installed.)
Preparing to unpack .../aptitude_0.8.7-1_amd64.deb ...
Unpacking aptitude (0.8.7-1) over (0.6.10-1) ...
Preparing to unpack .../aptitude-common_0.8.7-1_all.deb ...
Unpacking aptitude-common (0.8.7-1) over (0.6.10-1) ...
Preparing to unpack .../libgcc1_1%3a6.3.0-18_amd64.deb ...
Unpacking libgcc1:amd64 (1:6.3.0-18) over (1:4.8.2-19) ...
Processing triggers for man-db (2.7.6.1-2) ...
Processing triggers for libc-bin (2.24-11) ...
Setting up libgcc1:amd64 (1:6.3.0-18) ...
Processing triggers for libc-bin (2.24-11) ...
Selecting previously unselected package libboost-system1.62.0:amd64.
(Reading database ... 11013 files and directories currently installed.)
Preparing to unpack .../libboost-system1.62.0_1.62.0+dfsg-4_amd64.deb ...
Unpacking libboost-system1.62.0:amd64 (1.62.0+dfsg-4) ...
Selecting previously unselected package libboost-filesystem1.62.0:amd64.
Preparing to unpack .../libboost-filesystem1.62.0_1.62.0+dfsg-4_amd64.deb ...
Unpacking libboost-filesystem1.62.0:amd64 (1.62.0+dfsg-4) ...
Selecting previously unselected package libboost-iostreams1.62.0:amd64.
Preparing to unpack .../libboost-iostreams1.62.0_1.62.0+dfsg-4_amd64.deb ...
Unpacking libboost-iostreams1.62.0:amd64 (1.62.0+dfsg-4) ...
Processing triggers for libc-bin (2.24-11) ...
(Reading database ... 11028 files and directories currently installed.)
Removing libcwidget3:amd64 (0.5.17-1) ...
Removing libsigc++-2.0-0c2a:amd64 (2.4.1-1) ...
Selecting previously unselected package libsigc++-2.0-0v5:amd64.
(Reading database ... 10975 files and directories currently installed.)
Preparing to unpack .../libsigc++-2.0-0v5_2.10.0-1_amd64.deb ...
Unpacking libsigc++-2.0-0v5:amd64 (2.10.0-1) ...
Selecting previously unselected package libcwidget3v5:amd64.
Preparing to unpack .../libcwidget3v5_0.5.17-4+b1_amd64.deb ...
Unpacking libcwidget3v5:amd64 (0.5.17-4+b1) ...
Selecting previously unselected package libxapian30:amd64.
Preparing to unpack .../libxapian30_1.4.3-2_amd64.deb ...
Unpacking libxapian30:amd64 (1.4.3-2) ...
Preparing to unpack .../libstdc++6_6.3.0-18_amd64.deb ...
Unpacking libstdc++6:amd64 (6.3.0-18) over (4.8.2-19) ...
Processing triggers for libc-bin (2.24-11) ...
Setting up libstdc++6:amd64 (6.3.0-18) ...
Processing triggers for libc-bin (2.24-11) ...
Selecting previously unselected package libapt-inst2.0:amd64.
(Reading database ... 11050 files and directories currently installed.)
Preparing to unpack .../libapt-inst2.0_1.4.4_amd64.deb ...
Unpacking libapt-inst2.0:amd64 (1.4.4) ...
Selecting previously unselected package libdb5.3:amd64.
Preparing to unpack .../libdb5.3_5.3.28-12+b1_amd64.deb ...
Unpacking libdb5.3:amd64 (5.3.28-12+b1) ...
Preparing to unpack .../apt-utils_1.4.4_amd64.deb ...
Unpacking apt-utils (1.4.4) over (0.9.15.5) ...
Preparing to unpack .../archives/apt_1.4.4_amd64.deb ...
Unpacking apt (1.4.4) over (1.0.4) ...
Selecting previously unselected package libapt-pkg5.0:amd64.
Preparing to unpack .../libapt-pkg5.0_1.4.4_amd64.deb ...
Unpacking libapt-pkg5.0:amd64 (1.4.4) ...
Processing triggers for libc-bin (2.24-11) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libapt-pkg5.0:amd64 (1.4.4) ...
Processing triggers for libc-bin (2.24-11) ...
Selecting previously unselected package libbsd0:amd64.
(Reading database ... 11169 files and directories currently installed.)
Preparing to unpack .../libbsd0_0.8.3-1_amd64.deb ...
Unpacking libbsd0:amd64 (0.8.3-1) ...
Selecting previously unselected package libedit2:amd64.
Preparing to unpack .../libedit2_3.1-20160903-3_amd64.deb ...
Unpacking libedit2:amd64 (3.1-20160903-3) ...
Selecting previously unselected package binfmt-support.
Preparing to unpack .../binfmt-support_2.1.6-2_amd64.deb 

Bug#863730: unblock: gnome-calendar/3.22.4-2

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Tue, May 30, 2017 at 04:53:41PM +0200, Michael Biebl wrote:
> Please unblock package gnome-calendar
> 
> It's a targetted two-line fix for a crasher bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858924
> 
> The patch is from upstream, the package has already been uploaded and
> was successfully built everywhere.

Unfortunately it's stuck behind a new upstream from March. Is this worth
trying to revert or do through t-p-u, or better abandoned?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Emmanuel Kasper]

Le 30/05/2017 à 21:46, Branko Majic a écrit :
> On Tue, 30 May 2017 21:23:58 +0200
> Emmanuel Kasper  wrote:
> 
>> Than you for the detailed bug report.
>>
>> I understand the unstable network card ordering can perturbate the
>> network config if the NIC is assigned the name eth1 instead of eth0.
>> But I am wondering why is that changing the type of the second NIC
>> make the device ordering stable.
>> Are you sure this fixes the issue ?
> 
> I've been thinking about it a bit. It could be a "race" between which
> kernel module gets initialised first? This is highly hypothetical from
> my side, mind you, just one thing that pops to my mind. I would need to
> read up quite a bit on the topic to be sure.

Comparing the output of
dmesg | grep
between multiple boots it might very well be that, I was able to
reproduce the bug.

I have to think about the best way to solve this.

In theory udev persistent device naming should be here for this kind of
issues, but I don't use it since I build via qemu, and the devices on
Virtualbox get another position in the pci bus.

I will have a thought on using udev rules or setting all NICS to the
same hardware type.

Bug#863741: simple-scan: Gets confused when reordering pages while scanning

[Martin Bürgmann]

Package: simple-scan
Version: 3.14.0-1
Severity: important

Dear Maintainer,

when scanning a document, I noticed that I had scanned the 2nd page first.
So I right-clicked and selected something that would be "move to right".
So first:
- The logical 2nd page is the first in simple-scan while the first page is
being scanned to the 2nd on simple-scan.
- I clicked "Move to right" which swapped the two pages.
- Now the logical 2nd page is the 2nd in simple-scan while the half-scanned
first is the first.
The problem:
The new image data is still sent to the 2nd page and is overwriting my already
scanned document.
So I have a half-scanned first page and a combination of the 2nd and the other
half as the second page.
I'd expect that the rest of the scan is the also shifted with the page it was
originally scanned to.

Thank you,
Martin



-- Package-specific info:

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

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

Versions of packages simple-scan depends on:
ii  adwaita-icon-theme   3.14.0-2
ii  dbus-x11 1.8.22-0+deb8u1
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u9
ii  libcairo-gobject21.14.0-2.1+deb8u2
ii  libcairo21.14.0-2.1+deb8u2
ii  libcolord2   1.2.1-1+b2
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.48.0-1~bpo8+1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libgudev-1.0-0   215-17+deb8u7
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libsane  1.0.24-8+deb8u2
ii  xdg-utils1.1.0~rc1+git20111210-7.4
ii  zlib1g   1:1.2.8.dfsg-2+b1

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information


logfile.user
Description: inode/empty

Bug#863725: unblock: autodep8/0.9

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Tue, May 30, 2017 at 11:01:40AM -0300, Antonio Terceiro wrote:
> This release adds support for Go packages, but otherwise contains no
> changes to the existing functionality. I know this is not exactly the
> kind of thing we want during the freeze, but autodep8 is part of the CI
> infrastructure, and it will be really useful to have this version in
> stretch (as well as in jessie-backports).

I'm quite reluctant this late in the process (a couple of weeks ago I
wouldn't have minded so much). Is this not a good candidate for
stretch-backports when it opens?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863740: pagekite: Fail to connect to pagekite, claim invalid ssl cert

[Petter Reinholdtsen]

Package: pagekite
Version: 0.5.9.0-1

My pagekite instance on my Debian Stretch based Freedombox fail to
connect to the pagekite service.  This is the log messages I get, notice
the 'certificate verify failed' part:

root@freedombox:~# tail -20 /var/log/pagekite/pagekite.log
ts=592dc614; t=2017-05-30T19:20:52; ll=4d; debug=TunnelManager: problem=2, 
connecting=2
ts=592dc62a; t=2017-05-30T19:21:14; ll=4e; debug=Pinged 180.235.133.100:443: 
0.426222 [win=3, uuid=012343e74daca97d7ae1eed90ddd65afe78cbda6]
ts=592dc62a; t=2017-05-30T19:21:14; ll=4f; debug=Pinged 180.235.133.100:443: 
0.429669 [win=3, uuid=012343e74daca97d7ae1eed90ddd65afe78cbda6]
ts=592dc62a; t=2017-05-30T19:21:14; ll=50; debug=Pinged 180.235.133.100:443: 
0.439536 [win=3, uuid=012343e74daca97d7ae1eed90ddd65afe78cbda6]
ts=592dc62a; t=2017-05-30T19:21:14; ll=51; debug=Pinged 88.198.106.222:443: 
1.093084 [win=3, uuid=d77a1308f7feac3a16af832d527c81bb2c456d33]
ts=592dc62a; t=2017-05-30T19:21:14; ll=52; debug=Pinged 52.58.49.54:443: 
0.176134 [win=3, uuid=cb7deaf9bb554a389053dee2e10b0bcd2c6dee6d]
ts=592dc62a; t=2017-05-30T19:21:14; ll=53; debug=Pinged 54.84.55.54:443: 
0.313137 [win=3, uuid=89a1cca99ea351eb6ee95462663935db2b3f196c]
ts=592dc62a; t=2017-05-30T19:21:14; ll=54; debug=Pinged 54.183.178.65:443: 
0.396083 [win=3, uuid=fd864320481f56b934b221839c7f56f8940dd4e4]
ts=592dc62a; t=2017-05-30T19:21:14; ll=55; debug=Pinged 13.54.10.122:443: 
0.654999 [win=3, uuid=e47cbe5a922cc80a16868616f0eb43fa85924e6e]
ts=592dc62a; t=2017-05-30T19:21:14; ll=56; debug=Pinged 139.162.5.63:443: 
0.752239 [win=3, uuid=6dfce8e23ed66554ab59a190471a2c0e0e3718b8]
ts=592dc62a; t=2017-05-30T19:21:14; ll=57; debug=Preferred: 52.58.49.54:443
ts=592dc62a; t=2017-05-30T19:21:14; ll=58; debug=Connecting to 52.58.49.54:443; 
id=s4
ts=592dc62a; t=2017-05-30T19:21:14; ll=59; debug=Connecting to 
180.235.133.100:443; id=s5
ts=592dc62b; t=2017-05-30T19:21:15; ll=5a; err=Error in connect: Traceback 
(most recent call last):   File 
"/usr/lib/python2.7/dist-packages/pagekite/proto/conns.py", line 471, in 
_BackEnd data, parse = self._Connect(server, conns)   File 
"/usr/lib/python2.7/dist-packages/pagekite/proto/conns.py", line 331, in 
_Connect self.fd.connect((sspec[0], int(sspec[1])))   File 
"/usr/lib/python2.7/dist-packages/sockschain/__init__.py", line 1017, in 
connect anonymous=(proxy[P_TYPE] == PROXY_TYPE_SSL_ANON))   File 
"/usr/lib/python2.7/dist-packages/sockschain/__init__.py", line 929, in 
__negotiatessl connected=True, verify_names=want_hosts)   File 
"/usr/lib/python2.7/dist-packages/sockschain/__init__.py", line 118, in 
SSL_Connect if verify_names: nsock.do_handshake()   File 
"/usr/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 1426, in do_handshake   
  self._raise_ssl_error(self._ssl, result)   File 
"/usr/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 1174, in 
_raise_ssl_error _raise_current_error()   File 
"/usr/lib/python2.7/dist-packages/OpenSSL/_util.py", line 48, in 
exception_from_error_queue raise exception_type(errors) Error: [('SSL 
routines', 'tls_process_server_certificate', 'certificate verify failed')]
ts=592dc62b; t=2017-05-30T19:21:15; ll=5b; err=Server response parsing failed: 
[('SSL routines', 'tls_process_server_certificate', 'certificate verify 
failed')]; id=s4
ts=592dc62b; t=2017-05-30T19:21:15; ll=5c; eof=1; id=s4
ts=592dc62b; t=2017-05-30T19:21:15; ll=5d; err=Error in connect: Traceback 
(most recent call last):   File 
"/usr/lib/python2.7/dist-packages/pagekite/proto/conns.py", line 471, in 
_BackEnd data, parse = self._Connect(server, conns)   File 
"/usr/lib/python2.7/dist-packages/pagekite/proto/conns.py", line 331, in 
_Connect self.fd.connect((sspec[0], int(sspec[1])))   File 
"/usr/lib/python2.7/dist-packages/sockschain/__init__.py", line 1017, in 
connect anonymous=(proxy[P_TYPE] == PROXY_TYPE_SSL_ANON))   File 
"/usr/lib/python2.7/dist-packages/sockschain/__init__.py", line 929, in 
__negotiatessl connected=True, verify_names=want_hosts)   File 
"/usr/lib/python2.7/dist-packages/sockschain/__init__.py", line 118, in 
SSL_Connect if verify_names: nsock.do_handshake()   File 
"/usr/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 1426, in do_handshake   
  self._raise_ssl_error(self._ssl, result)   File 
"/usr/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 1174, in 
_raise_ssl_error _raise_current_error()   File 
"/usr/lib/python2.7/dist-packages/OpenSSL/_util.py", line 48, in 
exception_from_error_queue raise exception_type(errors) Error: [('SSL 
routines', 'tls_process_server_certificate', 'certificate verify failed')]
ts=592dc62b; t=2017-05-30T19:21:15; ll=5e; err=Server response parsing failed: 
[('SSL routines', 'tls_process_server_certificate', 'certificate verify 
failed')]; id=s5
ts=592dc62b; t=2017-05-30T19:21:15; ll=5f; eof=1; id=s5
ts=592dc62b; t=2017-05-30T19:21:15; ll=60; debug=TunnelManager: problem=2, 
connecting=2
root@freedombox:~#

I found a 

Bug#863739: python-clang-5.0 and python-clang-4.0: error when trying to install together

[Ralf Treinen]

Package: python-clang-4.0,python-clang-5.0
Version: python-clang-4.0/1:4.0.1~+rc1-1
Version: python-clang-5.0/1:5.0~svn301421-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2017-05-30
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Preconfiguring packages ...
Selecting previously unselected package libpython2.7-minimal:amd64.
(Reading database ... 11003 files and directories currently installed.)
Preparing to unpack .../libpython2.7-minimal_2.7.13-2_amd64.deb ...
Unpacking libpython2.7-minimal:amd64 (2.7.13-2) ...
Selecting previously unselected package python2.7-minimal.
Preparing to unpack .../python2.7-minimal_2.7.13-2_amd64.deb ...
Unpacking python2.7-minimal (2.7.13-2) ...
Selecting previously unselected package python-minimal.
Preparing to unpack .../python-minimal_2.7.13-2_amd64.deb ...
Unpacking python-minimal (2.7.13-2) ...
Selecting previously unselected package mime-support.
Preparing to unpack .../mime-support_3.60_all.deb ...
Unpacking mime-support (3.60) ...
Selecting previously unselected package libdb5.3:amd64.
Preparing to unpack .../libdb5.3_5.3.28-12+b1_amd64.deb ...
Unpacking libdb5.3:amd64 (5.3.28-12+b1) ...
Selecting previously unselected package libexpat1:amd64.
Preparing to unpack .../libexpat1_2.2.0-2_amd64.deb ...
Unpacking libexpat1:amd64 (2.2.0-2) ...
Selecting previously unselected package libffi6:amd64.
Preparing to unpack .../libffi6_3.2.1-6_amd64.deb ...
Unpacking libffi6:amd64 (3.2.1-6) ...
Selecting previously unselected package libreadline7:amd64.
Preparing to unpack .../libreadline7_7.0-3_amd64.deb ...
Unpacking libreadline7:amd64 (7.0-3) ...
Selecting previously unselected package libssl1.1:amd64.
Preparing to unpack .../libssl1.1_1.1.0f-1_amd64.deb ...
Unpacking libssl1.1:amd64 (1.1.0f-1) ...
Selecting previously unselected package libpython2.7-stdlib:amd64.
Preparing to unpack .../libpython2.7-stdlib_2.7.13-2_amd64.deb ...
Unpacking libpython2.7-stdlib:amd64 (2.7.13-2) ...
Selecting previously unselected package python2.7.
Preparing to unpack .../python2.7_2.7.13-2_amd64.deb ...
Unpacking python2.7 (2.7.13-2) ...
Selecting previously unselected package libpython-stdlib:amd64.
Preparing to unpack .../libpython-stdlib_2.7.13-2_amd64.deb ...
Unpacking libpython-stdlib:amd64 (2.7.13-2) ...
Processing triggers for man-db (2.7.6.1-2) ...
Processing triggers for libc-bin (2.24-11) ...
Setting up libpython2.7-minimal:amd64 (2.7.13-2) ...
Setting up python2.7-minimal (2.7.13-2) ...
Setting up python-minimal (2.7.13-2) ...
Selecting previously unselected package python.
(Reading database ... 11816 files and directories currently installed.)
Preparing to unpack .../python_2.7.13-2_amd64.deb ...
Unpacking python (2.7.13-2) ...
Selecting previously unselected package python-clang-4.0.
Preparing to unpack .../python-clang-4.0_1%3a4.0.1~+rc1-1_amd64.deb ...
Unpacking python-clang-4.0 (1:4.0.1~+rc1-1) ...
Selecting previously unselected package python-clang-5.0.
Preparing to unpack .../python-clang-5.0_1%3a5.0~svn301421-1_amd64.deb ...
Unpacking python-clang-5.0 (1:5.0~svn301421-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/python-clang-5.0_1%3a5.0~svn301421-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/python2.7/dist-packages/clang/__init__.py', 
which is also in package python-clang-4.0 1:4.0.1~+rc1-1
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
 /var/cache/apt/archives/python-clang-5.0_1%3a5.0~svn301421-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/python2.7/dist-packages/clang/__init__.py
  /usr/lib/python2.7/dist-packages/clang/cindex.py
  /usr/lib/python2.7/dist-packages/clang/enumerations.py

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more 

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Branko Majic]

On Tue, 30 May 2017 21:23:58 +0200
Emmanuel Kasper  wrote:

> Than you for the detailed bug report.
> 
> I understand the unstable network card ordering can perturbate the
> network config if the NIC is assigned the name eth1 instead of eth0.
> But I am wondering why is that changing the type of the second NIC
> make the device ordering stable.
> Are you sure this fixes the issue ?

I've been thinking about it a bit. It could be a "race" between which
kernel module gets initialised first? This is highly hypothetical from
my side, mind you, just one thing that pops to my mind. I would need to
read up quite a bit on the topic to be sure.

So, if you use same network adapter type everywhere, same module gets
used, and possibly the OS/kernel will always have the same ordering of
network cards. Or... It could be dependant on network module
implementation itself as well :)

As for the fix, I have been bringing machines up and down a bunch of
times since applying workaround in the Vagrantfile, and it has worked
flawlessly. The moment I remove the configuration, I start getting
failures. Practically no two consecutive "vagrant up" runs will
bring-up the network interfaces correctly in a batch of about 6-7
machines that get set-up.

Best regards

-- 
Branko Majic
XMPP: bra...@majic.rs
Please use only Free formats when sending attachments to me.

Бранко Мајић
XMPP: bra...@majic.rs
Молим вас да додатке шаљете искључиво у слободним форматима.

Bug#863714: unblock: libetpan/1.6-3

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Tue, May 30, 2017 at 11:53:31AM +0200, Ricardo Mones wrote:
> Please unblock package libetpan
> 
> Fixes bug 862151 (CVE-2017-8825). Diff includes an update to Homepage
> field which was already in git since past year ;)

The diff looks fine, but I can't unblock something that isn't in the
archive.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863640: retext: I install retext, try to run it, it segfault, please see output below

[Dmitry Shachnev]

On Tue, May 30, 2017 at 03:00:25PM +0200, Benoit Barthelet wrote:
> here it is
>
> ➜  ~ python3 -X faulthandler /usr/bin/retext
> Using configuration file: /home/lotso/.config/ReText project/ReText.conf
> Fatal Python error: Segmentation fault
>
> Current thread 0x7f7f0a0b9700 (most recent call first):
>   File "/usr/share/retext/ReText/xsettings.py", line 132 in get_raw_xsettings
>   File "/usr/share/retext/ReText/xsettings.py", line 187 in get_xsettings
>   File "/usr/share/retext/ReText/icontheme.py", line 20 in get_from_xsettings
>   File "/usr/share/retext/ReText/icontheme.py", line 49 in get_icon_theme
>   File "/usr/share/retext/ReText/window.py", line 68 in __init__
>   File "/usr/bin/retext", line 74 in main
>   File "/usr/bin/retext", line 102 in 
> [1]19648 segmentation fault  python3 -X faulthandler /usr/bin/retext
> ➜  ~

Thank you!

Fixed upstream in [1], will be in the next upload. Probably too late for
Stretch release though.

A workaround would be creating a configuration file with contents like
this:

[General]
iconTheme=Adwaita

(Replace Adwaita with your favourite icon theme.)

[1]: https://github.com/retext-project/retext/commit/fb5c5b8aae2ce904

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#863738: mirror listing update for debian.utalca.cl

[Fabio Duran Verdugo]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.utalca.cl
Aliases: debian.utalca.cl
Aliases: kernel.utalca.cl
Type: leaf
Archive-architecture: amd64
Archive-http: /debian/
Archive-rsync: debian/
Archive-upstream: ftp.cl.debian.org
Updates: four
Maintainer: Fabio Duran Verdugo 
Country: CL Chile
Location: Talca, Chile
Sponsor: Escuela de Ingeniería Civil en Bioinformática, Universidad de Talca 
http://icb.utalca.cl
Comment: At next days I will be configured for sync x86 architecture




Trace Url: http://debian.utalca.cl/debian/project/trace/
Trace Url: http://debian.utalca.cl/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.utalca.cl/debian/project/trace/debian.utalca.cl

Bug#863545: CVE-2016-8728

[Salvatore Bonaccorso]

Hi

On Wed, May 31, 2017 at 12:52:42AM +0800, Kan-Ru Chen wrote:
> Package: src:mupdf
> Followup-For: Bug #863545
> 
> I believe CVE-2016-8728 does not affect all versions of mupdf in
> Debian as the vulnerable code was introduced in version 1.10

Looks right, since there is no forceapha, and thus setting of nf = n +
forcealpha causing the problem in the [4] and [5] part of the
https://www.talosintelligence.com/vulnerability_reports/TALOS-2016-0242
report.

@Moritz, does that look correct to you as well? If so we can close
this bug since no version would be affected.

Salvatore

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Emmanuel Kasper]

> After comparing the files in two boxes, turned out that
> debian/contrib-jessie64 defines different network adapter type for
> first network adapter and remaining ones (82540EM vs Am79C973). This
> probably results in somewhat random ordering in the VM itself when
> adapters are being named. Relevant file where this is defined is
> "box.ovf".

> One could work around this issue with private network definition as:
> 
> machine.vm.network "private_network", ip: "10.64.128.10", nic_type: "82540EM"

Than you for the detailed bug report.

I understand the unstable network card ordering can perturbate the
network config if the NIC is assigned the name eth1 instead of eth0.
But I am wondering why is that changing the type of the second NIC
make the device ordering stable.
Are you sure this fixes the issue ?

Bug#848430: cqrlog: Should Depends/Recommends the metapackage default-mysql-*

[Federico Pietro Briata]

Sure,
follow the log. Thank you!

iz1glg@laptop:~$ cqrlog --debug=1

 DEBUG LEVEL 1 

Loading libssl: /usr/lib/x86_64-linux-gnu/libssl.so
Loading libcrypto: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
Loading libmysqlclient: /usr/lib/x86_64-linux-gnu/libmysqlclient.so
**
MySQL version: 10.
**
**
MySQL version assigned: 5.6
**

Ctyfiles dir: /usr/share/cqrlog/ctyfiles/
Local ctyfiles dir: /home/iz1glg/.config/cqrlog/ctyfiles/
Loaded 93636 LoTW users
Loaded 98114 eQSL users
Loaded 48268 SCP calls
*
User home directory:/home/iz1glg/
Program home directory: /home/iz1glg/.config/cqrlog/
Data directory: /home/iz1glg/.config/cqrlog/database/
Memebers directory: /usr/share/cqrlog/members/
ZIP code directory: /usr/share/cqrlog/zipcodes/
Binary dir: /usr/bin/
Share dir:  /usr/share/cqrlog/
TConnection to MySQL:   5.6
*
56 us states loaded
WARNING: obsolete call to RecreateWnd for TfrmDBConnect
Warning: TWinControl.DestroyHandle frmDBConnect:TfrmDBConnect Handle
not Allocated
/usr/sbin/mysqld
--defaults-file=/home/iz1glg/.config/cqrlog/database/mysql.cnf
--datadir=/home/iz1glg/.config/cqrlog/database/
--socket=/home/iz1glg/.config/cqrlog/database/sock --port=64000
2017-05-30 21:13:43 140664095195712 [Note] /usr/sbin/mysqld (mysqld
10.1.23-MariaDB-8) starting as process 22555 ...
select * from tables where table_schema = 'cqrlog_common'

CREATE DATABASE cqrlog_common DEFAULT CHARACTER SET = utf8  DEFAULT
COLLATE = utf8_bin;

USE cqrlog_common;

CREATE TABLE bands (
   id_bands INT AUTO_INCREMENT PRIMARY KEY,
   band VARCHAR(10) DEFAULT '',
   b_begin NUMERIC(10,4),
   b_end NUMERIC(10,4),
   cw NUMERIC(10,4),
   rtty NUMERIC(10,4),
   ssb NUMERIC(10,4),
   rx_offset numeric(10,4) default 0,
   tx_offset numeric(10,4) default 0
);
CREATE INDEX band ON bands(band);

CREATE TABLE dxclusters (
  id_dxclusters INT AUTO_INCREMENT PRIMARY KEY,
  description VARCHAR(100) DEFAULT '',
  address VARCHAR(100) DEFAULT '',
  port VARCHAR(10) DEFAULT '',
  dxcuser VARCHAR(12) DEFAULT '',
  dxcpass VARCHAR(20) DEFAULT ''
);
CREATE INDEX description ON dxclusters(description);

CREATE TABLE iota_list (
  id_iota_list INT AUTO_INCREMENT PRIMARY KEY,
  iota_nr VARCHAR(6) DEFAULT '',
  island_name VARCHAR(250) DEFAULT '',
  dxcc_ref VARCHAR(15) DEFAULT '',
  pref VARCHAR(15) DEFAULT ''
);
CREATE INDEX iota_nr ON iota_list(iota_nr);
CREATE INDEX pref ON iota_list(pref);


CREATE TABLE dxcc_ref (
id_dxcc_ref INT AUTO_INCREMENT PRIMARY KEY,
pref VARCHAR(20) NOT NULL,
name VARCHAR(100) NOT NULL,
cont VARCHAR(6) NOT NULL,
utc VARCHAR(12)NOT NULL,
lat VARCHAR(10) NOT NULL,
longit VARCHAR(10) NOT NULL,
itu VARCHAR(20) NOT NULL,
waz VARCHAR(20) NOT NULL,
adif SMALLINT NOT NULL DEFAULT 0,
deleted SMALLINT NOT NULL DEFAULT 0
);
CREATE INDEX pref ON dxcc_ref(pref);
CREATE INDEX adif ON dxcc_ref(adif);

CREATE TABLE qslmgr (
id_qslmgr INT AUTO_INCREMENT PRIMARY KEY,
callsign VARCHAR(20),
qsl_via VARCHAR(20),
fromdate DATE
);
CREATE INDEX callsign ON qslmgr(callsign);
CREATE INDEX fromdate ON qslmgr(fromdate);

CREATE TABLE log_list (
id_log_list INT AUTO_INCREMENT PRIMARY KEY,
log_nr SMALLINT NOT NULL,
log_name VARCHAR(50) DEFAULT '',
auto_open SMALLINT NOT NULL DEFAULT 0
);
CREATE INDEX log_nr ON log_list(log_nr);

CREATE TABLE db_version
(
  nr SMALLINT NOT NULL
);

TApplication.HandleException TMySQL56Connection : Error executing
query: Can't create database 'cqrlog_common' (errno: 2 "No such file
or directory")
  Stack trace:
  $008CDA9F
  $008CF178
  $0074271A
  $00742F63
  $00599A05
  $007B8C29
  $007AA6F3
  $7FE8F1DD4123
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Closing dData
Closing ini file ...

2017-05-30 18:15 GMT+02:00 Petr Hlozek :
> Could you run cqrlog with --debug=1 parameter? There will be more info. 
> Thanks!
>
>
> 2017-05-30 10:39 GMT+02:00 Federico Pietro Briata :
>> Hi all
>> with 2.0.2 with default-libmysqlclient-dev and even with cqrlog 2.0.5,
>> on on Stretch it's still failing during startup. :(
>> follow the error i get
>>
>> 73 de Iz1glg
>>
>> $ cqrlog
>>
>> ** DEBUG LEVEL 0 **
>> ** CHANGE WITH --debug=1 PARAMETER **
>>
>> WARNING: obsolete call to RecreateWnd for TfrmDBConnect
>> Warning: TWinControl.DestroyHandle frmDBConnect:TfrmDBConnect Handle
>> not Allocated
>> 2017-05-30  8:06:37 140150651388480 [Note] /usr/sbin/mysqld (mysqld
>> 10.1.23-MariaDB-8) starting as process 30994 ...
>> 

Bug#863702: unblock: compiz/0.9.13.0+16.10.20160818.2-5.1 (pre-approval)

[Jonathan Wiltshire]

Control: tag -1 confirmed moreinfo

On Tue, May 30, 2017 at 09:48:28AM +0200, Andreas Beckmann wrote:
> I want to upload a NMU of compiz to unstable fixing an upgrade issue
> from squeeze (there was no compiz in wheezy or jessie) by adding missing
> Breaks+Replaces, proposed patch attached.

Please go ahead and remove the moreinfo tag when it's ready to unblock.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863667: unblock: hexchat (pre-approval)

[Jonathan Wiltshire]

Control: tag -1 confirmed moreinfo

On Mon, May 29, 2017 at 10:49:46PM +0200, Mattia Rizzolo wrote:
> All considered probably such barely maintained plugin shouldn't be
> instaled by default indeed, therefore I'm asking for permission to
> upload the following debdiff and having it in stretch.

Agree. Please go ahead and remove the moreinfo tag when it is ready to
unblock.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#863657: debian-edu-config: fails to configure the exim4 environment after installation of the main server

[Wolfgang Schweer]

On Mon, May 29, 2017 at 10:14:05PM +, Holger Levsen wrote:
> On Mon, May 29, 2017 at 09:51:41PM +0200, Wolfgang Schweer wrote:
> > Reason: The cfengine exim4-create-environment shellscript is executed
> > too early, the Kerberos SMTP keytab isn't yet available, copying the
> > file fails. If the fifth pass of the cfengine run is used instead of the
> > first one, the file should be available.
>  
> *why* is it more likely to be available in the 5th run?

IIRC the Kerberos setup is done during the first pass (and the 
/etc/krb5.conf file is chmoded during secondpass) of the 
cfengine-debian-edu run when finish-install is executed at the end of 
the installation process. So even secondpass should be ok; I've chosen 
fifthpass to be on the safe side. Petter will definitly know if this 
would be working…

Wolfgang


signature.asc
Description: PGP signature

Bug#863657: tested once again the proposed fix for cf/cf.exim

[Wolfgang Schweer]

On Tue, May 30, 2017 at 03:21:27PM +0200, Petter Reinholdtsen wrote:
> [Wolfgang Schweer]
> > IIRC the Kerberos setup is done during the first pass (and the 
> > /etc/krb5.conf file is chmoded during secondpass) of the 
> > cfengine-debian-edu run when finish-install is executed at the end of 
> > the installation process. So even secondpass should be ok; I've chosen 
> > fifthpass to be on the safe side. Petter will definitly know if this 
> > would be working…
> 
> Sound like it should work, but I have not followed the issue and not not
> have time to investigate now.

I've just tested the changed cf.exim file once again on a recent main 
server: 
Works like expected when running 'cfengine-debian-edu -D installation'. 
I expect it to work if called by finish-install. So even if against all 
expectations it fails to configure exim4 correctly, it isn't supposed to 
break the installation.

Wolfgang


signature.asc
Description: PGP signature

Bug#688336:

[Mike Mestnik]

Forget about all of this, I'm going to simplify the design.  I have in
mind to make the following changes.
1. Don't just change $1 from being the path of a block device to being
a reserved word.
a. Instead append an additional parameter.
2. Use subvolume id, instead of names.

Bug#863737: fpc: Please add manpage for ppc68k command

[John Paul Adrian Glaubitz]

Source: fpc
Version: 3.0.0+dfsg-11
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

Since building src:fpc successfully requires a manpage for the native
ppc$CPU binary, we need to add one for ppc68k as well since the package
source is currently not shipping one.

I have just created a copy of the corresponding patch for arm64 to add
a manpage (add_arm64_manpage.patch) and reg-replaced all occurrences
of "ppca64" with "ppc68k".

Please include the patch with the next upload. With the changes from
#863589 [1], fpc can be built on the buildds for m68k without any
problems.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863589

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: In order to add support for m68k, we need a man-page
Source: Debian

--- /dev/null
+++ fpc-3.0.2+dfsg/install/man/man1/ppc68k.1
@@ -0,0 +1,33 @@
+.TH ppc68k 1 "30 may 1999" "Free Pascal" "Free Pascal Compiler"
+.SH NAME
+ppc68k \- Free Pascal Compiler (FPC) binary, name derived 
+from Portable Pascal Compiler
+
+.SH SYNOPSIS
+
+.B "ppc68k [options] [sourcefile]"
+.BR
+
+.SH DESCRIPTION
+This binary is the back-end binary of the
+.I Free Pascal Compiler (FPC)
+which is a
+.I Turbo Pascal
+and
+.I Delphi (7.0) 
+compatible standalone (non GCC frontend) multitarget Pascal compiler.
+
+This binary should not be called directly, instead the 
+.B fpc
+program should be used instead. 
+It will choose the right back-end for compiling units for the requested platforms.
+
+.SH OPTIONS
+
+For a complete list of all supported command-line options, see the
+.BR fpc (1)
+manual page.
+
+.SH SEE ALSO
+.BR  fpc (1)
+

Bug#688336:

[Mike Mestnik]

The patches have changes that have nothing to do with btrfs, I'll
attempt to isolate these.

Bug#863686: freemat: fails to start with llvm error

[Anton Gladky]

Hi Stuart,

thank you for this bugreport and catching this serious problem!
It is really necessary to add some simple tests into this package
to catch such kind of failures. I should really orphan it, as I do
not use it at all now...

Anton

Bug#688336:

[Mike Mestnik]

The patches introduce a bug.
/usr/lib/os-probes/50mounted-tests
calls fs_type on "btrfs"

I'll look into this some more.

Bug#725392: findutils: please add xargs -o parameter (MirBSD compatible) to help interactive applications

[Thorsten Glaser]

Package: findutils
Version: 4.6.0+git+20161106-2
Followup-For: Bug #725392
Control: retitle -1 findutils: please add xargs -o parameter (MirBSD 
compatible) to help interactive applications
Control: tags -1 + upstream

Hi,

maybe a slightly better formatted wishlist report helps.

The manual page of GNU xargs mentions this:

   xargs sh -c 'emacs "$@" < /dev/tty' emacs

   Launches  the  minimum  number of copies of Emacs needed, one after the
   other, to edit the files listed on xargs' standard input.  This example
   achieves the same effect as BSD's -o option, but in a more flexible and
   portable way.

BSD’s ‘-o’ option is documented thus:

 -o  Reopen stdin as /dev/tty in the child process before executing
 the command. This is useful if you want xargs to run an interac-
 tive application.

IMHO, the -o option is much less cumbersome to type/remember, and for
the sake of reverse portability (support applications that _already_
use the BSD variant), and especially given that the GNU maintainers
already know of it, the -o option ought to be added to GNU xargs as
well.

Side effect: avoids launching another shell, and, more importantly
to some, avoids quoting hell.

(That being said, /bin/sh on FreeBSD and derivates thereof has
slightly broken (for hysterical raisins) behaviour when sh -c cmd
is followed by “--” so the portability the GNU maintainers assert
for the sh variant is not exactly true either.)

So please persuade the upstream developers to add it; if necessary
I can likely cook up a debdiff.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages findutils depends on:
ii  libc62.24-11
ii  libselinux1  2.6-3+b1

findutils recommends no packages.

Versions of packages findutils suggests:
ii  mlocate  0.26-2

-- no debconf information

Bug#863729: marked as done (debian-policy: please use the cgit link in Vcs-Browser)

[Russ Allbery]

ow...@bugs.debian.org (Debian Bug Tracking System) writes:

> The (Browse) link on https://tracker.debian.org/pkg/debian-policy.  Now
> I notice it isn't the one in the control file.  I assumed that was the
> result of some redirection, but that's not the case.  You indeed fixed
> this in the experimental version (commit 670b8419), it's just the
> package tracker still carrying the old link from the unstable control
> file.

Oh!  Yes.  It will probably be fixed once the package is uploaded to
unstable after the stretch release.  I suspect tracker.debian.org
(rightfully) prefers unstable to experimental.

> Sorry for the noise,

No problem at all!  Thank you for the report -- definitely want to know
about things like this, since I personally tend to never test or notice
them since my workflow always involves a local checkout.

-- 
Russ Allbery (r...@debian.org)   

Bug#863736: reproducible: Update README to reflect switch to PostgreSQL

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal
Tags: patch

The README still includes references to sqlite, but the reproducible
builds portions have been switched to PostgreSQL.

Patch available in "readme-sql-update" branch at:

  https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git

Patch included below for reference:

commit 7c25ffae8ac893a3c2c82a2843b6fa3e69132ab5
Author: Vagrant Cascadian 
Date:   Tue May 30 10:01:35 2017 -0700

reproducible builds: Update to reflect switch to PostgreSQL.

diff --git a/README b/README
index 7c6f01cf..523b393f 100644
--- a/README
+++ b/README
@@ -131,7 +131,7 @@ Installation tests inside chroot environments.
 
 * See https://wiki.debian.org/ReproducibleBuilds to learn more about 
"Reproducible Builds" in Debian and beyond.
 
-* Several jobs are being used to assemble the website 
https://tests.reproducible-builds.org which is actually a collection of static 
html and log files (and very few images) being served from this host. Besides 
the logfiles data is stored in an SQLite database which can be downloaded from 
https://tests.reproducible-builds.org/reproducible.db. (That copy is updated 
every four hours.)
+* Several jobs are being used to assemble the website 
https://tests.reproducible-builds.org which is actually a collection of static 
html and log files (and very few images) being served from this host. Besides 
the logfiles data is stored in a database which can be downloaded from 
https://tests.reproducible-builds.org/reproducible.sql.xz. (That copy is 
updated daily.)
 
 * The (current) purpose of https://tests.reproducible-builds.org is to show 
the potential of reproducible builds for Debian - and six other projects 
currently. This is research, showing what could (and should) be done... check 
https://wiki.debian.org/ReproducibleBuilds for the real status of the project 
for Debian!
 
@@ -150,7 +150,7 @@ Installation tests inside chroot environments.
 *** three dual-cores (bpi0, hb0 and wbd0) with 1gb ram, each. 
 * We would love to have more or more powerful ARM hardware in the future, if 
you can help, please talk to us!
 
-* Packages to be build are scheduled in the SQLite database via a scheduler 
job, which runs every hour and if the queue is below a certain threshold 
schedules four types of packages:
+* Packages to be build are scheduled in the database via a scheduler job, 
which runs every hour and if the queue is below a certain threshold schedules 
four types of packages:
 ** new untested packages (either uploaded to 'unstable' or 'experimental' or 
migrated to 'testing'),
 ** new versions of existing packages, which were already tested - these are 
always scheduled, no matter how full the queue is
 ** old versions, already tested (at least two weeks ago)


signature.asc
Description: PGP signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Daniel Kahn Gillmor]

On Sun 2017-05-28 15:14:24 -0400, Daniel Kahn Gillmor wrote:
> On Sun 2017-05-28 19:54:33 +0200, Ivo De Decker wrote:
>> If this bug can be fixed by removing runit-init, the removal of the other
>> packages isn't necessary, but please note that this would need to happen very
>> soon.
>
> fwiw, i'm willing to provide such an NMU, because i consider runit to be
> a useful package.

I've now done this NMU, and filed #863732 to unblock the upload.

I've pushed the changes in a git branch to
https://anonscm.debian.org/git/collab-maint/runit.git, which is forked
from of https://anonscm.debian.org/git/users/kaction-guest/runit.git and
should probably be re-merged at some point.

fwiw, the practice of keeping just the debian/ directory in git seems
odd to me and makes it more difficult for me to contribute to the
NMU-maintenance of the package.  if i was going to do more work on the
package, i'd certainly prefer it to be converted to a standard
git-buildpackage-style "ladder" repo.

Regards,

 --dkg


signature.asc
Description: PGP signature

Bug#863545: CVE-2016-8728

[陳侃如]

Package: src:mupdf
Followup-For: Bug #863545

I believe CVE-2016-8728 does not affect all versions of mupdf in
Debian as the vulnerable code was introduced in version 1.10

Kanru

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

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

Bug#863735: unblock: freeradius/3.0.12+dfsg-5

[Michael Stapelberg]

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

Please unblock package freeradius

The new upload addresses a security issue: CVE-2017-9148, #863673

% debdiff freeradius_3.0.12+dfsg-4.dsc freeradius_3.0.12+dfsg-5.dsc 
dpkg-source: warning: extracting unsigned source package 
(/home/michael/d/out/freeradius/freeradius_3.0.12+dfsg-4.dsc)
diff -Nru freeradius-3.0.12+dfsg/debian/changelog 
freeradius-3.0.12+dfsg/debian/changelog
--- freeradius-3.0.12+dfsg/debian/changelog 2016-11-17 22:29:04.0 
+0100
+++ freeradius-3.0.12+dfsg/debian/changelog 2017-05-30 17:18:34.0 
+0200
@@ -1,3 +1,9 @@
+freeradius (3.0.12+dfsg-5) unstable; urgency=high
+
+  * disable session cache to address CVE-2017-9148 (closes: #863673)
+
+ -- Michael Stapelberg   Tue, 30 May 2017 17:18:34 +0200
+
 freeradius (3.0.12+dfsg-4) unstable; urgency=medium
 
   * fix openssl-1.1.diff: initialize ctx_out
diff -Nru 
freeradius-3.0.12+dfsg/debian/patches/disable-session-cache-CVE-2017-9148.patch 
freeradius-3.0.12+dfsg/debian/patches/disable-session-cache-CVE-2017-9148.patch
--- 
freeradius-3.0.12+dfsg/debian/patches/disable-session-cache-CVE-2017-9148.patch 
1970-01-01 01:00:00.0 +0100
+++ 
freeradius-3.0.12+dfsg/debian/patches/disable-session-cache-CVE-2017-9148.patch 
2017-05-30 17:18:34.0 +0200
@@ -0,0 +1,49 @@
+Description: disable session caching in the server (as opposed to in the
+ config, which would be way harder to get right) to address
+ https://security-tracker.debian.org/tracker/CVE-2017-9148
+Author: Michael Stapelberg 
+Forwarded: not-needed
+Last-Update: 2017-05-30
+
+---
+
+Index: freeradius/src/main/tls.c
+===
+--- freeradius.orig/src/main/tls.c
 freeradius/src/main/tls.c
+@@ -579,7 +579,7 @@ tls_session_t *tls_new_session(TALLOC_CT
+*
+*  FIXME: Also do it every N sessions?
+*/
+-  if (conf->session_cache_enable &&
++  if (/*conf->session_cache_enable*/0 &&
+   ((conf->session_last_flushed + ((int)conf->session_timeout * 1800)) 
<= request->timestamp)){
+   RDEBUG2("Flushing SSL sessions (of #%ld)", 
SSL_CTX_sess_number(conf->ctx));
+ 
+@@ -674,7 +674,7 @@ tls_session_t *tls_new_session(TALLOC_CT
+   state->mtu = vp->vp_integer;
+   }
+ 
+-  if (conf->session_cache_enable) state->allow_session_resumption = true; 
/* otherwise it's false */
++  if (/*conf->session_cache_enable*/0) state->allow_session_resumption = 
true; /* otherwise it's false */
+ 
+   return state;
+ }
+@@ -2848,7 +2848,7 @@ post_ca:
+   /*
+*  Callbacks, etc. for session resumption.
+*/
+-  if (conf->session_cache_enable) {
++  if (/*conf->session_cache_enable*/0) {
+   /*
+*  Cache sessions on disk if requested.
+*/
+@@ -2916,7 +2916,7 @@ post_ca:
+   /*
+*  Setup session caching
+*/
+-  if (conf->session_cache_enable) {
++  if (/*conf->session_cache_enable*/0) {
+   /*
+*  Create a unique context Id per EAP-TLS configuration.
+*/
diff -Nru freeradius-3.0.12+dfsg/debian/patches/series 
freeradius-3.0.12+dfsg/debian/patches/series
--- freeradius-3.0.12+dfsg/debian/patches/series2016-11-17 
22:29:04.0 +0100
+++ freeradius-3.0.12+dfsg/debian/patches/series2017-05-30 
17:18:34.0 +0200
@@ -1,3 +1,4 @@
+disable-session-cache-CVE-2017-9148.patch
 debian-local/0001-Rename-radius-to-freeradius.patch
 0002-gitignore.diff.patch
 0006-jradius.diff.patch

unblock freeradius/3.0.12+dfsg-5

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

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

Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Ian Jackson]

David Kalnischkies writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
build-deps with mk-build-deps"):
> I would recommend not to recommend it because apt follows the general
> recommendation of not recommending the installation of recommendations
> of build-dependencies by default for all recommended Debian releases.

When you install the build-depends for unfamiliar programs, you are
trying to debug, do you install recommends ?  I have found that it is
usually wiser not to.

Installing the recommends of build-depends typically shovels in
massive piles of junk, which is (a) a big download (b) often contains
daemons and other weirdness that is obviously not needed.

Ian.

Bug#863733: unattended-upgrades: no option to select priority updates

[Benoît]

Package: unattended-upgrades
Version: 0.93.1+nmu1
Severity: wishlist

Dear Maintainer,

I'm trying to use this package to keep my unstable patched for security issues.
But there's no filter to match the priority of an upgrade.

So unattended-upgrades ignores updates like this:

ignoring ver 'vlc=2.2.6-1' with priority < 0

How can I make it select this for install instead of ignoring it ?

-- System Information:
Debian Release: 9.0
  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.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages unattended-upgrades depends on:
ii  apt1.4.4
ii  apt-utils  1.4.4
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  lsb-base   9.20161125
ii  lsb-release9.20161125
ii  python33.5.3-1
ii  python3-apt1.4.0~beta3
ii  ucf3.0036
ii  xz-utils   5.2.2-1.2+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-23
ii  cron [cron-daemon]  3.0pl1-128+b1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20160123cvs-4
ii  exim4-daemon-light [mail-transport-agent]  4.89-2
pn  needrestart

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component (eg, "main", "contrib", "non-free")
//   l,label (eg, "Debian", "Debian-Security")
//   o,origin(eg, "Debian", "Unofficial Multimedia Packages")
//   n,codename  (eg, "jessie", "jessie-updates")
// site  (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}Installed origin.
//   ${distro_codename}  Installed codename (eg, "jessie")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
//  "o=Debian,n=jessie";
//  "o=Debian,n=jessie-updates";
//  "o=Debian,n=jessie-proposed-updates";
//  "o=Debian,n=jessie,l=Debian-Security";
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
//  "o=Debian,a=stable";
//  "o=Debian,a=stable-updates";
//  "o=Debian,a=proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,a=unstable,label=Debian-Security";
};
// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
//  "vim";
//  "libc6";
//  "libc6-dev";
//  "libc6-i686";
};
// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run 
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";
// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";
// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";
// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "u...@example.com"
//Unattended-Upgrade::Mail "root";
// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set

Bug#856164: linux-image-4.9.0-1-amd64: system doesn't resume from suspend

[Federico Beffa]

On Tue, May 30, 2017 at 11:44 AM, Martin Michlmayr  wrote:
> * Fede  [2017-02-25 20:31]:
>> I have a Dell XPS 15 9550.  I first installed Debian Stretch mid
>> January and after installation I could suspend and resume my laptop
>> by closing the lid.  Since the recent kernel update the laptop
>> doesn't resume from suspend.  Instead it just reboots.
>
> Do you still see this problem?
>
> I saw something similar yesterday with linux-image-4.9.0-3-amd64
> (4.9.25-1) on a Dell XPS 13 9350.  Instant reboot after opening the
> lid.  I booted into Debian, suspended, opened the lid and got a reboot
> again.  This happened about 2-3 times and then suspend starting
> working and is still working so far.
>
> So while I was able to trigger it reliable 2-3 times, it's working
> again (and I never had any problems during the last 2 months).

With kernel versions 4.9.0-2-amd64 and 4.9.0-3-amd64 the laptop (not
connected to a docking station) resumes as expected. Unfortunately I
still have many problems, but all related to the use of a docking
station, a Dell WD15.

With kernel 4.9.0-2-amd64 hot-plugging or disconnecting the docking
station most of the time results in a kernel freeze. Suspend and
resume kind of works, but only if the monitor input is always
listening for the port where the docking station is connected. If the
monitor switches port (automatic signal lookup) I end up with a blank
screen and need to use the power button.

With kernel 4.9.0-3-amd64 the use of the docking station is totally
impractical as half of the times I try to suspend and resume I get a
blank screen and have to use the power button. In fact I reverted to
4.9.0-2-amd64 for the time being.

To try to find out if the problems are caused by the kernel or by the
docking station firmware (latest available version with BIOS 1.2.25),
I tested an Ubuntu 17.04 live image which has a newer kernel of the
line 4.10. With it everything works as expected: suspend, resume,
hot-plugging and disconnecting (both while active as well as while in
suspend mode) and I can switch monitor input without fear. My
conclusion is that the problems are caused by the current kernel used
in Debian testing.

Regards,
Fede

Bug#863603: bluez: a2dp not working

[gregory . bahde]

Finally solved, 


It is indeed a gdm3 bug, the #805414 seems a good candidate, 

I modified /usr/bin/start-pulseaudio-x11 attached ( needed only if using gdm3) 
and modified /etc/pulse/default.pa (same) 


I also prevented pulseaudio to load under gdm3 according to this: 
https://wiki.debia n.org/BluetoothUser/a2dp 

The odd thing is that without all of this my other headphones where connecting 
a2dp straight. 



However 

Grégory Bahde 

- Mail original -

De: "gregory bahde"  
À: "gregory bahde" , 863...@bugs.debian.org 
Cc: "Debian Bug Tracking System"  
Envoyé: Mardi 30 Mai 2017 16:43:49 
Objet: Re: Bug#863603: bluez: a2dp not working 

Hello, 

Here I attached logs regarding an attempt(s) to use A2dp. 
there are also pulseaudio log attached as I am investigating it too. 
I switched harddrives from machines, it worked for a bit then refused to switch 
to a2dp again :/ 


Continuing to investigate, 

Grégory Bahde 

Doctorant en Géographie UJM / ENSSIB 
Financé par la Région RA dans le cadre de l'ARC 5 
Enseignant UE5 Edition Numérique @ ENSSIB 

0619157341 



- Mail original -

De: "gregory bahde"  
À: "Debian Bug Tracking System"  
Envoyé: Lundi 29 Mai 2017 09:46:51 
Objet: Bug#863603: bluez: a2dp not working 

Package: bluez 
Version: 5.43-2 
Severity: normal 
Tags: upstream 

Dear Maintainer, 

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

* What led up to the situation? 
I acquired a JBL Go bluetooth speaker. 
It works only in headsetmode on one of my computers (both running stetch, the 
other one is running this speaker wih a2dp fine) 

I tried different dongles (different chips) and they all don't allow me to use 
a2dp, only HSP with this speaker. 

I own another bluetooth device and it connects with a2dp fine. 


journalctl gives me this: 

mai 29 09:42:11 GoonieB gnome-settings-[1856]: Unable to get default sink 
mai 29 09:42:11 GoonieB gnome-settings-[1856]: gvc_mixer_card_get_index: 
assertion 'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:11 GoonieB gnome-settings-[1856]: gvc_mixer_card_get_index: 
assertion 'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:11 GoonieB gnome-shell[1727]: gvc_mixer_card_get_index: assertion 
'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:11 GoonieB gnome-shell[1727]: gvc_mixer_card_get_index: assertion 
'GVC_IS_MIXER_CARD (card)' failed 



AND THEN 

kernel: Bluetooth: hci0 SCO packet for unknown connection handle 71 
mai 29 09:42:16 GoonieB gnome-control-c[6529]: Device did not have an 
appropriate card 
mai 29 09:42:16 GoonieB gnome-control-c[6529]: gvc_mixer_card_get_index: 
assertion 'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:21 GoonieB pulseaudio[2950]: [pulseaudio] module-bluez5-device.c: 
Refused to switch profile to a2dp_sink: Not connected 



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

Tried all the fix for such bug shown on the internet 

* What was the outcome of this action? 

unsuccessful 



-- System Information: 
Debian Release: 9.0 
APT prefers testing 
APT policy: (502, 'testing'), (500, 'testing-proposed-updates'), (500, 
'stable'), (10, 'experimental'), (10, 'unstable') 
Architecture: amd64 
(x86_64) 
Foreign Architectures: i386 

Kernel: Linux 4.9.0-3-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 bluez depends on: 
ii dbus 1.10.18-1 
ii init-system-helpers 1.48 
ii kmod 23-2 
ii libc6 2.24-10 
ii libdbus-1-3 1.10.18-1 
ii libglib2.0-0 2.50.3-2 
ii libreadline7 7.0-3 
ii libudev1 232-23 
ii lsb-base 9.20161125 
ii udev 232-23 

bluez recommends no packages. 

Versions of packages bluez suggests: 
ii pulseaudio-module-bluetooth 10.0-1 

-- debconf-show failed 




default.pa
Description: Binary data


start-pulseaudio-x11
Description: application/shellscript

Bug#848430: cqrlog: Should Depends/Recommends the metapackage default-mysql-*

[Petr Hlozek]

Could you run cqrlog with --debug=1 parameter? There will be more info. Thanks!


2017-05-30 10:39 GMT+02:00 Federico Pietro Briata :
> Hi all
> with 2.0.2 with default-libmysqlclient-dev and even with cqrlog 2.0.5,
> on on Stretch it's still failing during startup. :(
> follow the error i get
>
> 73 de Iz1glg
>
> $ cqrlog
>
> ** DEBUG LEVEL 0 **
> ** CHANGE WITH --debug=1 PARAMETER **
>
> WARNING: obsolete call to RecreateWnd for TfrmDBConnect
> Warning: TWinControl.DestroyHandle frmDBConnect:TfrmDBConnect Handle
> not Allocated
> 2017-05-30  8:06:37 140150651388480 [Note] /usr/sbin/mysqld (mysqld
> 10.1.23-MariaDB-8) starting as process 30994 ...
> TApplication.HandleException TMySQL56Connection : Error executing
> query: Can't create database 'cqrlog_common' (errno: 2 "No such file
> or directory")
>   Stack trace:
>   $008CDA9F
>   $008CF178
>   $0074271A
>   $00742F63
>   $00599A05
>   $007B8C29
>   $007AA6F3
>   $7FEF936AB123
>



-- 
ex OK2CQR
https://hamqth.com/ok7an
https://ok7an.com
https://www.cqrlog.com/

Bug#863690: python-dkim: dkim line over-length

[Scott Kitterman]

Fixed upstream for the next release [1].

Scott K

[1] http://bazaar.launchpad.net/~dkimpy-hackers/dkimpy/trunk/revision/139

Bug#863267: [Python-modules-team] Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8

[Senthil Kumaran S]

On Tuesday 30 May 2017 08:39 PM, Raphael Hertzog wrote:
> On Tue, 30 May 2017, Senthil Kumaran S wrote:
>> I tested the new version ie., test2 and got a traceback as shown here -
>>   File "/usr/lib/python2.7/dist-packages/django/db/migrations/state.py",
>> line 249, in __init__
>> raise ValueError("\n".join(error.msg for error in errors))
>> ValueError: The field lava_scheduler_app.TestJob.submit_token was
>> declared with a lazy reference to 'linaro_django_xmlrpc.authtoken', but
>> app 'linaro_django_xmlrpc' isn't installed.
> 
> Is that actually true? linaro_django_xmlrpc seems to be listed in
> INSTALLED_APPS, no?

Yes it is listed in INSTALLED_APPS. From the code:


INSTALLED_APPS = [
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.humanize',
'django.contrib.staticfiles',
'django.contrib.admin',
# Uncomment the next line to enable admin documentation:

# 'django.contrib.admindocs',

# Add LAVA applications

'lava_server',
'dashboard_app',
'lava_results_app',
'lava_scheduler_daemon',
'lava_scheduler_app',
# Needed applications

'django_tables2',
'linaro_django_xmlrpc',
'google_analytics',
]


> Do you have any idea why it would give this error?

Since I am not very proficient with django core / migration code, I do
not know the exact reason. But following is what I understand.

linaro_django_xmlrpc is listed as a dependency in lava_scheduler_app's
initial migration. But it is not honored by the dependency graph that is
generated, where lava_scheduler_app will already be marked as migrated.
linaro_django_xmlrpc should be faked during this migration which we are
unable to do due to the check introduced in 1.10.

To give more background. The migration for linaro_django_xmlrpc was
introduced in November 2015 -
https://git.linaro.org/lava/lava-server.git/commit/?id=02a7c3508c01b89c7efb5d59e79b6880a229ff14

linaro_django_xmlrpc will already be available in the database, but it
was not recorded in the migrations table which should be faked now,
since this migration was introduced after creating the necessary tables
in the database.

> Your patch is a work-around and it works without my patch, so it's
> expected that it would also work with mine... but I would like a Django
> fix that would not require any further change in lava.

I agree.

Thank You.
-- 
Senthil Kumaran
http://www.stylesen.org/
http://www.sasenthilkumaran.com/



signature.asc
Description: OpenPGP digital signature

Bug#836205: is not yet fixed after all

[Paolo Greppi]

While I have been lazy in not closing this one with a Closes: line in 
debian/changes with 2.5.1-1, it turns out it was right to do so after all.

The issue has been reopened from upstream, and seems to be not really fixed in 
ms 0.7.2 as stated in the original advisory: https://github.com/zeit/ms/pull/89

I think we should:

1. create a node-ms 2.0.0 package
2. update node-debug to 2.6.8 and remove the embedded ms module

Paolo

Bug#863732: unblock: runit/2.1.2-9.1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 runit

Please unblock package runit

I've just uploaded 2.1.2-9.1 as an NMU, removing the runit-init
package to resolve #861536 as discussed on that bug report.  Please
unblock this upload so that we can keep the runit binary package in
stretch.

unblock runit/2.1.2-9.1

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru runit-2.1.2/debian/changelog runit-2.1.2/debian/changelog
--- runit-2.1.2/debian/changelog2016-10-09 06:21:59.0 -0400
+++ runit-2.1.2/debian/changelog2017-05-30 11:46:28.0 -0400
@@ -1,3 +1,10 @@
+runit (2.1.2-9.1) unstable; urgency=medium
+
+  * non-maintainer upload
+  * drop runit-init package (Closes: #861536)
+
+ -- Daniel Kahn Gillmor   Tue, 30 May 2017 11:46:28 
-0400
+
 runit (2.1.2-9) unstable; urgency=medium
 
   * Make runit-init depends getty-run, otherwise user can end up with
diff -Nru runit-2.1.2/debian/control runit-2.1.2/debian/control
--- runit-2.1.2/debian/control  2016-10-09 02:47:44.0 -0400
+++ runit-2.1.2/debian/control  2017-05-28 15:07:36.0 -0400
@@ -26,8 +26,8 @@
  and a log facility with automatic log file rotation and disk space limits.
  .
  runit service supervision can run under sysv init or replace the init
- system completely.  Complete init replacement provided by 'runit-init'
- package.
+ system completely.  Complete init replacement needs to be done by hand
+ (see https://bugs.debian.org/861536)
 
 Package: runit-systemd
 Architecture: all
@@ -71,19 +71,3 @@
  .
  This package provides scripts to supervise getty processes, allowing
  local login.
-
-Package: runit-init
-Architecture: any
-Depends: runit (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}, 
getty-run
-Replaces: systemd-sysv, sysvinit (<< 2.88dsf-44~), sysvinit-core, upstart
-Conflicts: systemd-sysv, sysvinit (<< 2.88dsf-44~), sysvinit-core, upstart
-Priority: extra
-Description: system-wide service supervision (as init system)
- runit is a collection of tools to provide system-wide service supervision
- and to manage services.  Contrary to sysv init, it not only cares about
- starting and stopping services, but also supervises the service daemons
- while they are running.  Amongst other things, it provides a reliable
- interface to send signals to service daemons without the need for pid-files,
- and a log facility with automatic log file rotation and disk space limits.
- .
- This package provides /sbin/init, that boots your system and starts runit.
diff -Nru runit-2.1.2/debian/rules runit-2.1.2/debian/rules
--- runit-2.1.2/debian/rules2016-10-09 02:46:35.0 -0400
+++ runit-2.1.2/debian/rules2017-05-28 15:08:57.0 -0400
@@ -11,8 +11,6 @@
 
 override_dh_installman-arch:
dh_installman
-   mv debian/runit-init/usr/share/man/man8/runit-init.8 \
-   debian/runit-init/usr/share/man/man8/init.8
 
 override_dh_runit: runscripts/getty
dh_runit
@@ -32,7 +30,7 @@
dh_clean
 override_dh_installchangelogs:
dh_installchangelogs
-   dh_installchangelogs -p runit -p runit-init \
+   dh_installchangelogs -p runit \
runit-$(DEB_VERSION_UPSTREAM)/package/CHANGES
 
 .PHONY: runscripts/getty
diff -Nru runit-2.1.2/debian/runit-init.install 
runit-2.1.2/debian/runit-init.install
--- runit-2.1.2/debian/runit-init.install   2016-10-09 02:58:07.0 
-0400
+++ runit-2.1.2/debian/runit-init.install   1969-12-31 19:00:00.0 
-0500
@@ -1,6 +0,0 @@
-#!/usr/bin/dh-exec
-runit-2.1.2/src/runit-init => /sbin/init
-runit-2.1.2/src/runit  /sbin
-debian/contrib/shutdown /sbin
-debian/contrib/reboot   /sbin
-debian/contrib/runlevel /sbin
diff -Nru runit-2.1.2/debian/runit-init.links 
runit-2.1.2/debian/runit-init.links
--- runit-2.1.2/debian/runit-init.links 2016-10-09 06:17:37.0 -0400
+++ runit-2.1.2/debian/runit-init.links 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/share/man/man8/shutdown.8.gz /usr/share/man/man8/reboot.8.gz
diff -Nru runit-2.1.2/debian/runit-init.manpages 
runit-2.1.2/debian/runit-init.manpages
--- runit-2.1.2/debian/runit-init.manpages  2016-10-09 06:19:28.0 
-0400
+++ runit-2.1.2/debian/runit-init.manpages  1969-12-31 19:00:00.0 
-0500
@@ -1,4 +0,0 @@
-runit-*/man/runit.8
-runit-*/man/runit-init.8
-debian/contrib/shutdown.8
-debian/contrib/runlevel.8

Bug#863673: [Pkg-freeradius-maintainers] Bug#863673: CVE-2017-9148: FreeRADIUS TLS resumption authentication bypass

[Michael Stapelberg]

Upstream confirmed that my patch fixes the issue, so I uploaded it to
unstable.

See also
https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/commit/?id=8d681449aa95ee4388b5e3c266bdb070a264f563

security-team, can you take care of applying the patch to stable and
oldstable please? Thank you.

On Tue, May 30, 2017 at 8:29 AM, Michael Stapelberg 
wrote:

> control: owner -1 !
>
> I prepared a patch for this issue and emailed the FreeRADIUS security team
> asking for review. I’ll upload the patch once they confirm its
> effectiveness.
>
> On Mon, May 29, 2017 at 11:16 PM, Guido Günther  wrote:
>
>> Package: freeradius
>> Version: 3.0.12+dfsg-4
>> severity: grave
>>
>> Hi,
>>
>> the following vulnerability was published for freeradius.
>>
>> CVE-2017-9148[0]: FreeRADIUS TLS resumption authentication bypass
>>
>> If you fix the vulnerability please also make sure to include the
>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>>
>> For further information see:
>>
>> [0] https://security-tracker.debian.org/tracker/CVE-2017-9148
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9148
>>
>> Please adjust the affected versions in the BTS as needed.
>> Cheers,
>>  -- Guido
>>
>> ___
>> Pkg-freeradius-maintainers mailing list
>> pkg-freeradius-maintain...@lists.alioth.debian.org
>> https://lists.alioth.debian.org/mailman/listinfo/pkg-freerad
>> ius-maintainers
>>
>
>
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael

Bug#863729: debian-policy: please use the cgit link in Vcs-Browser

[Russ Allbery]

Ferenc Wágner  writes:

> Package: debian-policy
> Severity: minor

> Your control file specifies
> https://anonscm.debian.org/git/dbnpolicy/policy.git
> as Vcs-Browser, but the gitweb interface gives "Bad object id:" messages
> when clicking into the shortlog section.  Please switch to
> https://anonscm.debian.org/cgit/dbnpolicy/policy.git
> if possible.

We were specifically asked by the anonscm maintainers to use the URL that
we're currently using.  It's supposed to work  And it does seem to
work fine for me?  I clicked around a bunch through the interface and
couldn't reproduce that.

-- 
Russ Allbery (r...@debian.org)   

Bug#863731: sudo: CVE-2017-1000367: Potential overwrite of arbitrary files

[Salvatore Bonaccorso]

Source: sudo
Version: 1.8.10p3-1
Severity: grave
Tags: security upstream patch fixed-upstream
Justification: user security hole

Hi,

the following vulnerability was published for sudo.

CVE-2017-1000367[0]:
Potential overwrite of arbitrary files

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-1000367
[1] http://www.openwall.com/lists/oss-security/2017/05/30/16
[2] https://www.sudo.ws/alerts/linux_tty.html
[3] https://www.sudo.ws/repos/sudo/raw-rev/b5460cbbb11b

Regards,
Salvatore

Bug#862481: jessie-pu: package xfce4-weather-plugin/0.8.3-2

[Yves-Alexis Perez]

On Sat, 2017-05-13 at 13:51 +0200, Yves-Alexis Perez wrote:
> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
> 
> xfce4-weather-plugin uses met.no as source for weather information.
> There was multiple changes in API in recent years, and they disabled
> legacy API in the last few days, meaning weather plugin in Jessie
> doesn't work anymore.

Hi,

I assume you're more focused on stretch these days, but would it be possible
to move forward on this? weather plugin is completely unusable in Jessie right
now.

Regards,
-- 
Yves-Alexis

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