Bug#826616: selektor: UI starts on login

[Paul Wise]

Package: selektor
Version: 3.13.66-1
Severity: normal

The SelekTOR UI starts on login, even though I didn't set it to auto-
start. This seems like something recently introduced.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages selektor depends on:
ii  default-jre 2:1.8-57
ii  libglib2.0-bin  2.48.1-1
ii  libnotify-bin   0.7.6-2
ii  libtrove-java   2.1.0-2
ii  tor 0.2.7.6-1
ii  tor-geoipdb 0.2.7.6-1

selektor recommends no packages.

selektor suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#826617: initramfs-tools: intel microcode: 149 EOF on update

[Real Name]

Package: initramfs-tools
Version: 0.120+deb8u2
Severity: grave
Justification: renders package unusable

Dear Maintainer,


   * What led up to the situation?
   > Update of initramfs-tools

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   > initramfs-tools: 149 intel mircocode EOF

   * What was the outcome of this action?
   > 2nd update of initramfs-tools

   * What outcome did you expect instead?
   > Update completion

Best regards



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 27M Apr 14 07:33 /boot/initrd.img-3.16.0-4-586
-rw-r--r-- 1 root root 28M Jun  7 05:56 /boot/initrd.img-3.16.0-4-686-pae
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae 
root=UUID=13af198f-627a-4e3c-9124-d2e3403b22f9 ro initrd=/install/gtk/initrd.gz 
quiet

-- resume
RESUME=UUID=b1bb-1380-4fd5-9b8b-5312476e4eb8
-- /proc/filesystems
btrfs
ext3
ext2
ext4
fuseblk

-- lsmod
Module  Size  Used by
binfmt_misc12733  1 
bnep   17184  2 
pci_stub   12397  1 
ip6table_filter12492  1 
vboxpci22738  0 
ip6_tables 16987  1 ip6table_filter
vboxnetadp 25431  0 
iptable_filter 12488  1 
ip_tables  16975  1 iptable_filter
x_tables   17978  4 
ip6table_filter,ip_tables,iptable_filter,ip6_tables
vboxnetflt 27266  0 
vboxdrv   249280  3 vboxnetadp,vboxnetflt,vboxpci
i8k12913  0 
nfsd  236959  2 
auth_rpcgss45765  1 nfsd
oid_registry   12387  1 auth_rpcgss
nfs_acl12463  1 nfsd
nfs   168022  0 
lockd  73443  2 nfs,nfsd
fscache44782  1 nfs
sunrpc211341  6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
wl   6087369  0 
iTCO_wdt   12727  0 
iTCO_vendor_support12585  1 iTCO_wdt
dell_laptop16941  0 
dell_wmi   12437  0 
sparse_keymap  12730  1 dell_wmi
dcdbas 13087  1 dell_laptop
ecb12649  1 
coretemp   12708  0 
btusb  25417  0 
kvm_intel 133491  0 
bluetooth 340064  21 bnep,btusb
kvm   330411  1 kvm_intel
pcspkr 12531  0 
joydev 16847  0 
serio_raw  12737  0 
6lowpan_iphc   16548  1 bluetooth
lpc_ich16616  0 
mfd_core   12537  1 lpc_ich
evdev  17136  20 
pcmcia 44245  0 
cfg80211  350041  1 wl
i2c_i801   16845  0 
rng_core   12645  0 
yenta_socket   38561  0 
pcmcia_rsrc17292  1 yenta_socket
pcmcia_core18024  3 pcmcia,pcmcia_rsrc,yenta_socket
snd_hda_codec_idt  48266  1 
snd_hda_codec_generic58021  2 snd_hda_codec_idt
rfkill 18387  5 cfg80211,bluetooth,dell_laptop
snd_hda_intel  26023  6 
snd_hda_controller 26262  1 snd_hda_intel
snd_hda_codec  93797  4 
snd_hda_codec_idt,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
snd_hwdep  12906  1 snd_hda_codec
tpm_tis17063  0 
shpchp 30673  0 
tpm26879  1 tpm_tis
irda   90261  0 
crc_ccitt  12331  1 irda
ac 12627  0 
snd_pcm78128  3 snd_hda_codec,snd_hda_intel,snd_hda_controller
snd_timer  26105  1 snd_pcm
snd55101  19 
snd_hwdep,snd_timer,snd_hda_codec_idt,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
soundcore  12890  2 snd,snd_hda_codec
battery13164  0 
acpi_cpufreq   17050  0 
processor  27590  3 acpi_cpufreq
vmhgfs 59630  0 
vmw_vmci   54356  1 vmhgfs
fuse   77496  3 
parport_pc 26004  0 
ppdev  16686  0 
lp 12766  0 
parport35213  3 lp,ppdev,parport_pc
autofs434865  2 
ext4  438464  2 
crc16  12327  2 ext4,bluetooth
mbcache17027  1 ext4
jbd2   72964  1 ext4
crc32c_generic 12576  1 
btrfs 854794  0 
xor25716  1 btrfs
raid6_pq   95207  1 btrfs
dm_mod 83026  0 
sg 25573  0 
sd_mod 43684  4 
crc_t10dif 12399  1 sd_mod
sr_mod 21568  0 
crct10dif_generic  12517  1 
cdrom  46828  1 sr_mod
crct10dif_common   12340  2 crct10dif_generic,crc_t10dif
ata_generic12450  0 
usb_storage43391  3 
ata_piix   29371  0 
psmouse93505  0 
libata161908  2 ata_generic,ata_piix
scsi_mod  164132  5 

Bug#822783: eztrace-contrib: FTBFS with libc 2.23: 'memcpy' was not declared in this scope

[Graham Inggs]

On 31 May 2016 at 11:35, Samuel Thibault  wrote:
> So reassigning to cuda, perhaps a proper fix can be done in the .h files
> there without having to ask upstream :)

I'll have to check if Nvidia's license allows us to fix bugs in their
headers. ;)

Here we have a minimal reproducer from the Ubuntu bug [1]:

$ echo '#include ' > dummy.cpp
$ g++ -c -O2 dummy.cpp
$ cp dummy.cpp dummy.cu
$ nvcc -c -O2 dummy.cu
/usr/include/string.h: In function ‘void* __mempcpy_inline(void*,
const void*, size_t)’:
/usr/include/string.h:652:42: error: ‘memcpy’ was not declared in this scope
   return (char *) memcpy (__dest, __src, __n) + __n;

Again, defining _FORCE_INLINES works around the problem:
$ nvcc -c -O2 -D_FORCE_INLINES dummy.cu


[1] https://bugs.launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/+bug/1589751

Bug#826615: iverilog: Please package version 10.1 of iverilog

[Ruben Undheim]

Package: iverilog
Version: 0.9.7-1+b1
Severity: wishlist

Dear Maintainer,

There is a newer version of iverilog - 10.1. It is required by the test suite
of yosys since it contains some bug fixes and other improvements.

It would be helpful if it gets packaged such that the test suite of yosys can
be run when building the package.

Additionally, it seems like the watch URL is wrong since it says the newest
version is 10.0, while on Github, there's a 10.1 version.


Cheers,
Ruben

Bug#826607: [Pkg-clamav-devel] Bug#826607: jessie-pu: package clamav/0.99.2+dfsg-0+deb8u2

[Scott Kitterman]

On Tuesday, June 07, 2016 12:13:36 AM Sebastian Andrzej Siewior wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: jessie
> Severity: normal
> 
> The last version (0.99.2+dfsg-0+deb8u1) removed AllowSupplementaryGroups
> and hit stable over the weekend. Now Hans van Kranenburg had an
> unattended upgrade and the config file was not fixed up (i.e. the option
> removed as suggested during the upgrade process). clamav did not start,
> he fixed it manually and reported #826406.
> This update will ignore the AllowSupplementaryGroups option whether set
> or not and the behaviour will remain unchanged. All binaries will behave
> the same except they won't complain about the AllowSupplementaryGroups
> option. The plan is not to push this change into unstable so people
> upgrading Jessie -> Stretch have to have this option removed at this
> point.
> 
> I am not sure if this update makes sense at this point since most people
> got probably bitten by this, cursed my name and moved on. So if you
> think that this update makes sense here it is - otherwise...

I think we should fix this.  People will still hit it on upgrades to jessie 
otherwise.  Also, I'm planning on pushing 0.99.2 to wheezy-lts soon and 
inflicting this same pain on LTS users doesn't make sense, so I'd like to 
include it there (and as a result, I think it's very important to get it into 
Jessie to avoid regressions on upgrade).

Scott K

Bug#826614: CONFIG_MAC_SCSI and CONFIG_MAC8390 are set to 'y'

[Finn Thain]

Source: linux
Version: 4.4

In Linux v3.19, CONFIG_MAC_SCSI became a tristate option (instead of 
bool). In Linux v4.4, CONFIG_MAC8390 became a tristate option (it too was 
previously bool).

Please set CONFIG_MAC_SCSI=m and CONFIG_MAC8390=m for m68k kernel builds 
to reduce the size of the kernel binary. The former is a SCSI host adapter 
driver and the latter is an Ethernet NIC driver. Both drivers are only 
relevant to the Mac sub-architecture and are not used on Amiga, Atari etc.

-- 

Bug#825974: [Pkg-mc-devel] Bug#825974: mc: subshell no longer sees correct terminal size

[Michael Gold]

On Wed, Jun 01, 2016 at 14:07:01 +0200, Yury V. Zaytsev wrote:
> On Tue, 31 May 2016, Michael Gold wrote:
> 
> > When I press CTRL-O in mc to use the subshell, and resize the terminal,
> > applications no longer see the new size (as they used to)--they always
> > see the original size.
> 
> Hi Michael,
> 
> I think that this might be a regression caused by this fix:
> 
>http://www.midnight-commander.org/ticket/3639#comment:13
> 
> It would be great if you could confirm that the proposed solution fixes your
> problem... Sorry about that!

Thank you.  Reverting the linked changeset and applying that diff fixed
the problem.  I've attached an automated regression test.  (If running
without installing, prepend the build directory to $PATH.)

-- Michael
// Verify that mc's subshell sees the correct terminal size
// after it's changed.  See https://bugs.debian.org/825974#.

/*
This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to 
*/

#define _POSIX_C_SOURCE 200809L
#define _XOPEN_SOURCE 700
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void
die_perror(const char *str)
{
	perror(str);
	exit(1);
}

static void
die_usage(const char *name)
{
	fprintf(stderr, "Usage: %s\n", name);
	exit(2);
}

static void*
drainer(void *arg)
{
	char buf[1024];
	int *p_fd = arg;
	ssize_t rv;

	do {
		rv = read(*p_fd, [0], sizeof buf);
	} while (rv > 0);

	return (rv == 0) ? NULL : (void*)(intptr_t)errno;
}

static void
close_fd(int fd)
{
	do {} while (close(fd) < 0 && errno == EINTR);
}

static void
write_str_or_die(int fd, const char *str)
{
	size_t offset = 0, len = strlen(str);
	while (offset < len) {
		ssize_t rv = write(fd, [offset], len);
		if (rv < 0) {
			if (errno == EINTR) continue;
			die_perror("write");
		}
		offset += (size_t)rv;
	}
}

static size_t
read_to_eof_or_die(int fd, char *buf, size_t bufsz)
{
	size_t offset = 0;
	while (offset < bufsz) {
		ssize_t rv = read(fd, [offset], bufsz-offset);
		if (rv < 0) {
			if (errno == EINTR) continue;
			die_perror("read");
		} else if (rv == 0) {
			break;
		}
		offset += (size_t)rv;
	}
	return offset;
}

int
main(int argc, char **argv)
{
	int opt;
	int pty_master, pty_slave;
	int pipefd[2];
	int child_pid;
	const char *slave_path;
	char buf[256];
	pthread_t drainer_tid;
	struct winsize winsz = { .ws_row = 25, .ws_col = 55 };

	while ((opt = getopt(argc, argv, "")) != -1) {
		switch (opt) {
		default:
		case '?':
			die_usage(argv[0]);
		}
	}
	if (optind > argc) {
		die_usage(argv[0]);
	}

	// Set up a pseudoterminal
	pty_master = posix_openpt(O_RDWR | O_NOCTTY | O_CLOEXEC);
	if (pty_master < 0) {
		die_perror("posix_openpt");
	}
	if (grantpt(pty_master) < 0) {
		die_perror("grantpt");
	}
	if (unlockpt(pty_master) < 0) {
		die_perror("unlockpt");
	}
	slave_path = ptsname(pty_master);
	if (!slave_path) {
		die_perror("ptsname");
	}

	// Set the initial size
	if (ioctl(pty_master, TIOCSWINSZ, ) < 0) {
		die_perror("ioctl(TIOCSWINSZ)");
	}

	pty_slave = open(slave_path, O_RDWR | O_NOCTTY);
	if (pty_slave < 0) {
		die_perror("open(slave)");
	}

	// Create a pipe to communicate with mc
	if (pipe([0]) < 0) {
		die_perror("pipe");
	}

	// Fork a process to run mc
	child_pid = fork();
	if (child_pid < 0) {
		die_perror("fork");
	} else if (!child_pid) {
		char *exec_args[] = {"mc", (char*)NULL};

		if (setsid() < 0) {
			die_perror("setsid");
		}
		if (ioctl(pty_slave, TIOCSCTTY, NULL) < 0) {
			die_perror("ioctl(TIOCSCTTY)");
		}
		if (dup2(pty_slave, 0) < 0
|| dup2(pty_slave, 1) < 0
|| dup2(pty_slave, 2) < 0
|| dup2(pipefd[1], 3) < 0) {
			die_perror("dup2");
		}
		if (pty_slave > 3) {
			close_fd(pty_slave);
		}

		(void)execvp(exec_args[0], exec_args);
		die_perror("execvp");
	}

	close_fd(pty_slave);
	pty_slave = -1;
	close_fd(pipefd[1]);
	pipefd[1] = -1;

	// Have a 

Bug#826563: stable-updates fix for Bug#826563: perl: Apparent regression in TryCatch

[Adam D. Barratt]

On Tue, 2016-06-07 at 00:46 +0100, Dominic Hargreaves wrote:
> On Mon, Jun 06, 2016 at 08:54:23PM +0100, Dominic Hargreaves wrote:
[...]
> > In hindsight, it's obvious that Debian's testing of this update wasn't
> > sufficient either. Such breaking changes in perl stable updates are,
> > I believe, exceedingly rare, but equally we had not attempted a wholesale,
> > or near-wholesale update in Debian stable before, and the breakage
> > wasn't reported in any real-world testing using the stable update
> > installed from source. In future, we should perform similar automated
> > testing against jessie-proposed-updates as we do in experimental when
> > a new major version of perl is introduced.
[...]
> I've prepared an updated package of libdevel-declare-perl, which builds
> and tests out fine with both perl 5.20.2-3+deb8u4 and 5.20.2-3+deb8u5.
> 
> A debdiff for stable is attached. Release team, are you happy for me
> to upload (is the distribution correct for stable-updates)?

Yes, it is, in as much as one never uploads to stable-updates - one
uploads to stable, via p-u, and we cherry-pick uploads from there
sideways into -updates at our discretion once they're ready. Please go
ahead with the upload to p-u and we'll see from there.

In general it's also preferable if a new release.d.o bug is filed to
track the upload, rather than CCing debian-release on bugs belonging to
another package.

(I realise that this is a regression, but the popcon stats for
libdevel-declare-perl have a "recent" count of 10, which does make me
wonder how wide an impact this is actually having in practice.)

Regards,

Adam

Bug#826611: not support using unpatched qt

[Martin Hanson]

Package: wkhtmltopdf
Version: 0.12.1-2
Severity: grave

This package is pretty useless!

The switch --no-pdf-compression, is not support using unpatched qt, and will be 
ignored.The switch --footer-right, is not support using unpatched qt, and will 
be ignored.The switch --toc-header-text, is not support using unpatched qt, and 
will be ignored.Error: This version of wkhtmltopdf is build against an 
unpatched version of QT, and does not support more then one input document.
Exit with code 1, due to unknown error.
Makefile:22: recipe for target 'pdf' failed
make: *** [pdf] Error 1

The upstream binary, which is compiled against a patched version, works 
flawlessly.

Kind regards

Bug#823128: RFP: proxychains-ng -- redirect connections through proxy servers

[Carlos Maddela]

Control: retitle -1 ITP: proxychains-ng -- redirect connections through
proxy servers

On Sun, 1 May 2016 02:57:50 -0400 Jason Hennessey wrote:
> Package: wnpp
> Severity: wishlist
>
> The current proxychains package is relatively old, and development has
> continued in a different project called proxychains-ng according to this
> ubuntu report from 2013, the maintainer announced in a forum on the
> original sourceforge site that development had moved to github:
> https://bugs.launchpad.net/ubuntu/+source/proxychains/+bug/1109235
>
> The new repo contains several useful additions, such as the ability to
> specify a config file on the command line as well as using the remote
> host to do DNS resolving (which allows things like resolving TOR onion
> addresses), and may be found at: https://github.com/rofl0r/proxychains-ng
>
> Thanks for any help!
>
>
>

Bug#796589: [pkg-apparmor] Bug#796589: apparmor: Has init script in runlevel S but no matching service file

[Felipe Sateler]

On 6 June 2016 at 20:03, Seth Arnold  wrote:
>
> On Mon, Jun 06, 2016 at 08:49:46PM -0300, Felipe Sateler wrote:
> > Control: tags -1 patch
> >
> > On Sat, 22 Aug 2015 17:04:38 -0300 fsate...@debian.org wrote:
> > > Hi,
> > >
> > > Your package apparmor has an initscript that is enabled in runlevel
> > > S, but it does not provide a corresponding systemd service unit.
> >
> > Please find attached a unit that wraps the currently existing init
> > script. Proper integration (which I understand is being worked on) can
> > be added later.
>
> Felipe, I really liked the idea of your comment on the corresponding
> upstream bug:
> https://bugs.launchpad.net/apparmor/+bug/1503762
> Your comment (in isolation):
> https://bugs.launchpad.net/apparmor/+bug/1503762/comments/4
>
> Is there a strong enough reason to ship the wrapping-the-sysv .service
> file? That feels like an odd step to take.

I am not an apparmor user, so I cannot judge the correctness of the
new service file, or test that it works fine in sufficient
configurations. Moreover, the init script appears to do a lot more
work than just invoke `/usr/sbin/apparmor_parser -r $paths`, how can I
be sure the new unit would be equivalent?

Therefore I stuck with the minimal approach: make apparmor ship a file
similar to what is currently being generated by systemd. This has a
much smaller chance of being broken.

I hope this explains.

-- 

Saludos,
Felipe Sateler

Bug#826613: ITP: golang-github-google-shlex -- Automatically exported from code.google.com/p/go-shlex

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-google-shlex
  Version : 0.0~git20150127.0.6f45313-1
  Upstream Author : Google
* URL : https://github.com/google/shlex
* License : Apache-2.0
  Programming Lang: Go
  Description : A simple lexer for Go that supports shell-style quoting

 go-shlex is a simple lexer for Go.  It splits input in to tokens using
 shell-style rules for quoting, commenting, and escaping.

Rationale for packaging: Needed by govendor-1.0.3

Bug#796589: [pkg-apparmor] Bug#796589: apparmor: Has init script in runlevel S but no matching service file

[Seth Arnold]

On Mon, Jun 06, 2016 at 08:49:46PM -0300, Felipe Sateler wrote:
> Control: tags -1 patch
> 
> On Sat, 22 Aug 2015 17:04:38 -0300 fsate...@debian.org wrote:
> > Hi,
> >
> > Your package apparmor has an initscript that is enabled in runlevel
> > S, but it does not provide a corresponding systemd service unit.
> 
> Please find attached a unit that wraps the currently existing init
> script. Proper integration (which I understand is being worked on) can
> be added later.

Felipe, I really liked the idea of your comment on the corresponding
upstream bug:
https://bugs.launchpad.net/apparmor/+bug/1503762
Your comment (in isolation):
https://bugs.launchpad.net/apparmor/+bug/1503762/comments/4

Is there a strong enough reason to ship the wrapping-the-sysv .service
file? That feels like an odd step to take.

Thanks


signature.asc
Description: PGP signature

Bug#826070: python-escript: FTBFS in indep-only mode: no prerm scripts to tweak

[Aaron M. Ucko]

Santiago Vila  writes:

> Please note that if we apply the same standard to every bug like this
> (i.e. FTBFS when using dpkg-buildpackage -A), lots of bugs here should
> be serious as well:

That's a good point.  However, I'd argue that pure source-only uploads
with no maintainer-supplied arch-all packages (as occurred here) call
for a higher severity in this scenario.

> (BTW: I have just added this bug to the collection :-)

Great, thanks.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#796589: apparmor: Has init script in runlevel S but no matching service file

[Felipe Sateler]

Control: tags -1 patch

On Sat, 22 Aug 2015 17:04:38 -0300 fsate...@debian.org wrote:
> Hi,
>
> Your package apparmor has an initscript that is enabled in runlevel
> S, but it does not provide a corresponding systemd service unit.

Please find attached a unit that wraps the currently existing init
script. Proper integration (which I understand is being worked on) can
be added later.

I added a RequiresMountsFor=/var/lib because the init script tries to
read and write to /var. Unfortunately, because /var can be
remote-mounted, this can cause a dependency loop if the network is
brought up later in the boot process (ie, by a service with
DefaultDependencies=yes). Thus we cannot reasonably restrict apparmor
to start Before=sysinit.target without possibly introducing dependency
loops. If the /var dependency is optional, then please drop the
RequiresMountsFor, and add Before=sysinit.target so that all normal
services start properly contained.

Also, apparmor init script is not stopped on shutdown (and thus I did
not add a Conflicts on shutdown.target), you might want to consider
dropping the ExecStop in that case.

Result is untested (other than build-install), as I have no idea how
to test a security module is working ok.

Saludos
diff -Nru apparmor-2.10/debian/apparmor.service 
apparmor-2.10/debian/apparmor.service
--- apparmor-2.10/debian/apparmor.service   1969-12-31 21:00:00.0 
-0300
+++ apparmor-2.10/debian/apparmor.service   2016-06-06 19:22:31.0 
-0400
@@ -0,0 +1,16 @@
+[Unit]
+Description=AppArmor initialization
+After=local-fs.target
+ConditionVirtualization=!container
+ConditionSecurity=apparmor
+RequiresMountsFor=/var/lib
+DefaultDependencies=no
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/etc/init.d/apparmor start
+ExecStop=/etc/init.d/apparmor stop
+ExecReload=/etc/init.d/apparmor reload
+
+[Install]
+WantedBy=sysinit.target
diff -Nru apparmor-2.10/debian/changelog apparmor-2.10/debian/changelog
--- apparmor-2.10/debian/changelog  2016-03-29 17:30:38.0 -0300
+++ apparmor-2.10/debian/changelog  2016-06-06 19:12:08.0 -0400
@@ -1,3 +1,11 @@
+apparmor (2.10-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a systemd unit wrapping the init script.
+Closes: #796589
+
+ -- Felipe Sateler   Mon, 06 Jun 2016 19:11:31 -0400
+
 apparmor (2.10-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru apparmor-2.10/debian/control apparmor-2.10/debian/control
--- apparmor-2.10/debian/control2016-01-25 18:33:08.0 -0300
+++ apparmor-2.10/debian/control2016-06-06 19:24:06.0 -0400
@@ -16,7 +16,8 @@
 libpam-dev,
 texlive-latex-base, texlive-latex-recommended,
 python-all-dev, python, python3-all-dev, python3,
-perl (>= 5.8.0), liblocale-gettext-perl, pkg-config
+perl (>= 5.8.0), liblocale-gettext-perl, pkg-config,
+dh-systemd
 Standards-Version: 3.9.6
 Homepage: http://apparmor.net/
 Vcs-Bzr: https://anonscm.debian.org/bzr/collab-maint/apparmor
diff -Nru apparmor-2.10/debian/rules apparmor-2.10/debian/rules
--- apparmor-2.10/debian/rules  2015-08-28 13:57:01.0 -0300
+++ apparmor-2.10/debian/rules  2016-06-06 19:23:48.0 -0400
@@ -11,7 +11,7 @@
 export PYTHON_VERSIONS=python3
 
 %:
-   dh $@ --with=python2,python3,apache2
+   dh $@ --with=python2,python3,apache2,systemd
 
 
 override_dh_auto_configure:

Bug#826612: RFP: deerportal -- A hybrid of a card and a board game where you have to challenge four classical elements.

[Rafal Zawadzki]

Package: wnpp
Severity: wishlist

* Package name: deerportal
  Version : 0.6.0
  Upstream Author : bluszcz & ukata 
* URL : https://devcarpet.net/deerportal
* License : zlib
  Programming Lang: C++
  Description : A hybrid of a card and a board game where you have to 
challenge four classical elements.


A computer multiplayer board game driven by the four classical elements. 
For 0-4 players. Game takes place in an ancient world where Almighty
Deer God is protecting all the compassionate creatures. 

Bug#826563: stable-updates fix for Bug#826563: perl: Apparent regression in TryCatch

[Dominic Hargreaves]

On Mon, Jun 06, 2016 at 08:54:23PM +0100, Dominic Hargreaves wrote:
> Thanks Niko for analysis. The sequence of events went like this:
> 
> 1) a commit (which fixed a segfault, but broke compatibility) was
>committed to the upstream development branch
> 2) upstream testing detected the issue in Devel::Declare, and a new
>version was released to CPAN fixing the problem.
> 3) the fix was backported to maint-5.20, and in the process of that
>backporting, the knowledge that there was a known issue was lost.
> 
> The general feeling on IRC was that point release updates should indeed
> avoid breaking old versions of libraries on CPAN, and that a known
> issue should have been included in the perldelta. This will be added
> to the release managers guide in future.
> 
> In hindsight, it's obvious that Debian's testing of this update wasn't
> sufficient either. Such breaking changes in perl stable updates are,
> I believe, exceedingly rare, but equally we had not attempted a wholesale,
> or near-wholesale update in Debian stable before, and the breakage
> wasn't reported in any real-world testing using the stable update
> installed from source. In future, we should perform similar automated
> testing against jessie-proposed-updates as we do in experimental when
> a new major version of perl is introduced.
> 
> My plan is:
> 
> 1) submit a new version of libdevel-declare-perl for immediate
>inclusion in stable-updates.
> 2) kick off a test rebuild of packages using perl to catch any issues
>in this update (at least those which we can catch by package builds
>and test suites).
> 3) document this in the perl maintenance notes on the wiki for future
>reference
> 
> I should be able to do at least the first two of these this evening.

I've prepared an updated package of libdevel-declare-perl, which builds
and tests out fine with both perl 5.20.2-3+deb8u4 and 5.20.2-3+deb8u5.

A debdiff for stable is attached. Release team, are you happy for me
to upload (is the distribution correct for stable-updates)?

Thanks,
Dominic.
diff -Nru libdevel-declare-perl-0.006017/debian/changelog libdevel-declare-perl-0.006017/debian/changelog
--- libdevel-declare-perl-0.006017/debian/changelog	2014-10-08 21:24:17.0 +0100
+++ libdevel-declare-perl-0.006017/debian/changelog	2016-06-07 00:30:57.0 +0100
@@ -1,3 +1,10 @@
+libdevel-declare-perl (0.006017-1+deb8u1) jessie; urgency=high
+
+  * Team upload.
+  * Fix breakage caused by change in perl stable update (Closes: #826563)
+
+ -- Dominic Hargreaves   Tue, 07 Jun 2016 00:30:47 +0100
+
 libdevel-declare-perl (0.006017-1) unstable; urgency=medium
 
   [ Salvatore Bonaccorso ]
diff -Nru libdevel-declare-perl-0.006017/debian/patches/0001-dont-use-sub_inwhat-RT-102918.patch libdevel-declare-perl-0.006017/debian/patches/0001-dont-use-sub_inwhat-RT-102918.patch
--- libdevel-declare-perl-0.006017/debian/patches/0001-dont-use-sub_inwhat-RT-102918.patch	1970-01-01 01:00:00.0 +0100
+++ libdevel-declare-perl-0.006017/debian/patches/0001-dont-use-sub_inwhat-RT-102918.patch	2016-06-07 00:08:52.0 +0100
@@ -0,0 +1,25 @@
+From 7fc37409865dab1d5bbd358c57be8ce5c8b00a8b Mon Sep 17 00:00:00 2001
+From: Matthew Horsfall 
+Date: Mon, 23 Mar 2015 15:27:48 -0400
+Subject: [PATCH] dont use sub_inwhat (RT#102918)
+
+---
+ stolen_chunk_of_toke.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/stolen_chunk_of_toke.c b/stolen_chunk_of_toke.c
+index c667eaa..b9e5037 100644
+--- a/stolen_chunk_of_toke.c
 b/stolen_chunk_of_toke.c
+@@ -342,7 +342,7 @@ S_skipspace(pTHX_ register char *s, int incline)
+ 	 * of the buffer, we're not reading from a source filter, and
+ 	 * we're in normal lexing mode
+ 	 */
+-	if (s < PL_bufend || !PL_rsfp || PL_sublex_info.sub_inwhat ||
++	if (s < PL_bufend || !PL_rsfp || PL_lex_inwhat ||
+ 		PL_lex_state == LEX_FORMLINE)
+ 	return s;
+ 
+-- 
+2.1.4
+
diff -Nru libdevel-declare-perl-0.006017/debian/patches/series libdevel-declare-perl-0.006017/debian/patches/series
--- libdevel-declare-perl-0.006017/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libdevel-declare-perl-0.006017/debian/patches/series	2016-06-07 00:11:41.0 +0100
@@ -0,0 +1 @@
+0001-dont-use-sub_inwhat-RT-102918.patch

Bug#826563: Pending fixes for bugs in the libdevel-declare-perl package

[pkg-perl-maintainers]

tag 826563 + pending
thanks

Some bugs in the libdevel-declare-perl package are closed in revision
c5adf9217a66bf3d9dabf087c39dbc063240145d in branch '  jessie' by
Dominic Hargreaves

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdevel-declare-perl.git/commit/?id=c5adf92

Commit message:

Fix breakage caused by change in perl stable update (Closes: #826563)

Bug#826610: RFS: psensor/1.1.5-1 [FTBFS fix]

[jeanfi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: psensor
  Version : 1.1.5-1
  Upstream Author : Jean-Philippe Orsini jea...@gmail.com
* URL : http://wpitchoune.net/psensor
* License : GPLv2
  Section : utils

It builds those binary packages:

psensor- display graphs for monitoring hardware temperature
psensor-common - common files for Psensor and Psensor server
psensor-server - Psensor server for monitoring hardware sensors remotely

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/p/psensor/psensor_1.1.5-1.dsc

More information about psensor can be obtained from
https://wpitchoune.net/psensor.

Changes since the last upload:

  * New upstream release
  + fixed build failure. (Closes: #808519)
  * debian/control
  + switched to standard 3.9.8.

Regards,
Jean-Philippe Orsini



signature.asc
Description: OpenPGP digital signature

Bug#825112: (no subject)

[Barry Warsaw]

Just wondering if anybody's made progress on this.  I was blown away by the
talk on Xonsh at Pycon 2016 [*] and of course the first thing I did was look
for it in Debian. :)  I'd be happy to help package this up.

[*] https://www.youtube.com/watch?v=uaje5I22kgE

Bug#826609: gnome-calendar: does not start at all

[Michael Biebl]

Am 07.06.2016 um 00:41 schrieb Andreas Hilboll:
> Package: gnome-calendar
> Version: 3.20.2-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> gnome-calendar does not start on my Strech amd64 system.  When invoking the 
> command 'gnome-calendar' in the terminal, I get the error message
> 
>$ gnome-calendar 
>
>(gnome-calendar:4888): GLib-GIO-ERROR **: Settings schema 
> 'org.gnome.shell.calendar' is not installed

That schema is provided by gnome-shell-common

We either need to add that as a dependency or (better) make
gnome-calendar handle it gracefully if the schema doesn't exist.

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#826609: gnome-calendar: does not start at all

[Andreas Hilboll]

Package: gnome-calendar
Version: 3.20.2-1+b1
Severity: important

Dear Maintainer,

gnome-calendar does not start on my Strech amd64 system.  When invoking the 
command 'gnome-calendar' in the terminal, I get the error message

   $ gnome-calendar 
   
   (gnome-calendar:4888): GLib-GIO-ERROR **: Settings schema 
'org.gnome.shell.calendar' is not installed
   
   Trace/breakpoint trap



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

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

Versions of packages gnome-calendar depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-9
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcamel-1.2-57  3.20.2-2
ii  libecal-1.2-19   3.20.2-2
ii  libedataserver-1.2-213.20.2-2
ii  libedataserverui-1.2-1   3.20.2-2
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgoa-1.0-0b3.20.1-1
ii  libgtk-3-0   3.20.5-4
ii  libical2 2.0.0-0.4
ii  libicu55 55.1-7
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.23-2
ii  libnss3-1d   2:3.23-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libsecret-1-00.18.3-1
ii  libsoup2.4-1 2.54.1-1
ii  libsqlite3-0 3.13.0-1
ii  libxml2  2.9.3+dfsg1-1

Versions of packages gnome-calendar recommends:
ii  evolution-data-server  3.20.2-2

gnome-calendar suggests no packages.

-- no debconf information

Bug#677865: [PATCH] Always use flock for file locking; drop Recommends on libfile-fcntllock-perl

[Josh Triplett]

On Mon, Jun 06, 2016 at 11:44:00PM +0200, Guillem Jover wrote:
> On Sun, 2016-06-05 at 14:37:51 -0700, Josh Triplett wrote:
> > Control: tags -1 + patch
> > 
> > The attached patch implements the change I suggested, dropping fcntl
> > locking in favor of flock, and documenting that change in the changelog
> > along with the rationale.
> 
> > >From 0c6eddc8200e7bea482ad65c5870f7977847d26a Mon Sep 17 00:00:00 2001
> > From: Josh Triplett 
> > Date: Sun, 5 Jun 2016 14:27:38 -0700
> > Subject: [PATCH] Always use flock for file locking; drop Recommends on
> >  libfile-fcntllock-perl
> > 
> > Per the flock(2) manpage, NFS clients going back to Linux 2.6.12
> > translate flock into an fcntl lock on the entire file.
> 
> This is a non-portable Linux-only assumption. dpkg works on other
> systems besides Linux-based ones.

I'm aware; however, the question is whether other NFS client
implementations fail to implement flock, and whether dpkg supports doing
parallel builds on those systems on their less capable NFS
implementations.  What other NFS client implementations does dpkg
support, and what do those other clients do with flock?

It's unfortunate that the failure mode for flock on NFS is "silently
no-op" rather than "fail"; the latter would make it easier to fall back
to a serial build, for instance.  Is there any reliable, portable way to
detect an NFS filesystem with non-functional locking, or more generally
a filesystem with non-functional locking?

> I'm also unhappy even about the
> fallback to flock when fcntl is not available, as on other systems
> the locks might not see each other so that's the worst possible
> behavior.

Another potential solution to the problem would be to avoid serializing
this at all, which then avoids the need to lock.  What if each run of
the requisite tool generated a different target control file, for
instance?  Or perhaps debian/files should become debian/files.d?  As
long as the corresponding dpkg tools support reading that format when
constructing a .deb, migrating to that for parallel builds seems
reasonable.  That might also speed up dpkg-gencontrol, which at the
moment can be a major bottleneck in the parallel build of a multi-binary
package.

> I've in fact been looking into this recently. And I'll ping the perl
> maintainers to try to get the required packaging fixes implemented in
> libfile-fcntllock-file done. Otherwise I'll probably embed something
> similar to that module as a private Dpkg module.

Great to hear; thank you.

- Josh Triplett

Bug#826608: hfsprogs: Please switch to use libmd instead of OpenSSL's libcrypto

[Guillem Jover]

Source: hfsprogs
Source-Version: 332.25-11
Severity: wishlist
Tags: patch

Hi!

The attached patch switches this package from OpenSSL's libcrypto to
libmd, which is a smaller library containing only digest functions. It
is also available in the base system of most current Unixes. And has
no obnoxious 4-clause BSD licensed code.

Thanks,
Guillem
diff -Naur hfsprogs-332.25/debian/control hfsprogs-332.25.new/debian/control
--- hfsprogs-332.25/debian/control	2013-10-24 08:42:58.0 +0200
+++ hfsprogs-332.25.new/debian/control	2016-06-07 00:11:46.777328589 +0200
@@ -6,7 +6,7 @@
 Build-Depends:
  debhelper (>= 9),
  libbsd-dev,
- libssl-dev
+ libmd-dev
 Standards-Version: 3.9.3
 
 Package: hfsprogs
diff -Naur hfsprogs-332.25/debian/patches/-Use-libmd-instead-of-OpenSSL-s-libcrypto.patch hfsprogs-332.25.new/debian/patches/-Use-libmd-instead-of-OpenSSL-s-libcrypto.patch
--- hfsprogs-332.25/debian/patches/-Use-libmd-instead-of-OpenSSL-s-libcrypto.patch	1970-01-01 01:00:00.0 +0100
+++ hfsprogs-332.25.new/debian/patches/-Use-libmd-instead-of-OpenSSL-s-libcrypto.patch	2016-06-07 00:12:10.805447738 +0200
@@ -0,0 +1,58 @@
+From 532b3647d7e56f7b0ae02f58b2616a37682d8b83 Mon Sep 17 00:00:00 2001
+From: Guillem Jover 
+Date: Tue, 7 Jun 2016 00:08:28 +0200
+Subject: [PATCH] Use libmd instead of OpenSSL's libcrypto
+
+The former is smaller, has no obnoxious 4-clause BSD license terms,
+and is available on most base Unix systems now.
+---
+ newfs_hfs.tproj/Makefile   |2 +-
+ newfs_hfs.tproj/makehfs.c  |2 +-
+ vsdbutil.tproj/Makefile|2 +-
+ vsdbutil.tproj/vsdbutil_main.c |2 +-
+ 4 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/newfs_hfs.tproj/Makefile
 b/newfs_hfs.tproj/Makefile
+@@ -26,7 +26,7 @@ MAKEFILE = tool.make
+ NEXTSTEP_INSTALLDIR = /sbin
+ WINDOWS_INSTALLDIR = /sbin
+ PDO_UNIX_INSTALLDIR = /sbin
+-LIBS = -lcrypto 
++LIBS = -lmd
+ DEBUG_LIBS = $(LIBS)
+ PROF_LIBS = $(LIBS)
+ 
+--- a/newfs_hfs.tproj/makehfs.c
 b/newfs_hfs.tproj/makehfs.c
+@@ -45,7 +45,7 @@
+ #include 
+ #include 
+ 
+-#include 
++#include 
+ 
+ #include 
+ 
+--- a/vsdbutil.tproj/Makefile
 b/vsdbutil.tproj/Makefile
+@@ -24,7 +24,7 @@ MAKEFILE = tool.make
+ NEXTSTEP_INSTALLDIR = /usr/sbin
+ WINDOWS_INSTALLDIR = /Library/Executables
+ PDO_UNIX_INSTALLDIR = /bin
+-LIBS = -lcrypto
++LIBS = -lmd
+ DEBUG_LIBS = $(LIBS)
+ PROF_LIBS = $(LIBS)
+ 
+--- a/vsdbutil.tproj/vsdbutil_main.c
 b/vsdbutil.tproj/vsdbutil_main.c
+@@ -53,7 +53,7 @@
+ 
+ #include 
+ 
+-#include 
++#include 
+ #include 
+ 
+ struct FinderAttrBuf {
diff -Naur hfsprogs-332.25/debian/patches/0001-Create-short-Makefiles-for-Debian.patch hfsprogs-332.25.new/debian/patches/0001-Create-short-Makefiles-for-Debian.patch
--- hfsprogs-332.25/debian/patches/0001-Create-short-Makefiles-for-Debian.patch	2013-10-24 08:42:58.0 +0200
+++ hfsprogs-332.25.new/debian/patches/0001-Create-short-Makefiles-for-Debian.patch	2016-06-07 00:11:46.777328589 +0200
@@ -85,7 +85,7 @@
 +all: newfs_hfs
 +
 +newfs_hfs: $(OFILES)
-+	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OFILES) -lcrypto
++	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OFILES) -lmd
 +
 +clean:
 +	$(RM) newfs_hfs $(OFILES)
diff -Naur hfsprogs-332.25/debian/patches/0002-Add-exclude-Darwin-specific-code.patch hfsprogs-332.25.new/debian/patches/0002-Add-exclude-Darwin-specific-code.patch
--- hfsprogs-332.25/debian/patches/0002-Add-exclude-Darwin-specific-code.patch	2013-10-24 08:42:58.0 +0200
+++ hfsprogs-332.25.new/debian/patches/0002-Add-exclude-Darwin-specific-code.patch	2016-06-07 00:12:21.129498933 +0200
@@ -5,32 +5,30 @@
 Modify some of the files so that they can be compiled without the
 Apple owned frameworks in a Debian system (and possibly others).
 ---
- fsck_hfs.tproj/cache.c  |   4 ++
- fsck_hfs.tproj/dfalib/BTree.c   |   2 +
- fsck_hfs.tproj/dfalib/BlockCache.c  |   3 +
- fsck_hfs.tproj/dfalib/SBTree.c  |   2 +
- fsck_hfs.tproj/dfalib/SDevice.c |  92 -
- fsck_hfs.tproj/dfalib/SKeyCompare.c |   2 +
- fsck_hfs.tproj/dfalib/SRepair.c |   2 +
- fsck_hfs.tproj/dfalib/SRuntime.h|   7 ++-
- fsck_hfs.tproj/dfalib/SUtils.c  |   5 +-
- fsck_hfs.tproj/dfalib/SVerify2.c|   7 +++
- fsck_hfs.tproj/dfalib/Scavenger.h   |  11 +++-
- fsck_hfs.tproj/dfalib/hfs_endian.c  |   4 ++
- fsck_hfs.tproj/dfalib/hfs_endian.h  |   7 ++-
- fsck_hfs.tproj/fsck_hfs.c   |  61 +++
- fsck_hfs.tproj/utilities.c  |   8 ++-
- include/missing.h   | 115 
- newfs_hfs.tproj/hfs_endian.c|   5 ++
- newfs_hfs.tproj/hfs_endian.h|   5 ++
- newfs_hfs.tproj/makehfs.c   |  72 --
- newfs_hfs.tproj/newfs_hfs.c |  74 ---
- newfs_hfs.tproj/newfs_hfs.h |  26 
+ fsck_hfs.tproj/cache.c  |4 +
+ fsck_hfs.tproj/dfalib/BTree.c   |2 
+ 

Bug#825572: Uploaded to DELAYED/2

[David Prévot]

Hi Mathieu,

On Mon, Jun 06, 2016 at 09:50:21PM +0200, Mathieu Parent wrote:

> I've uploaded php-sabre-vobject (2.1.7-3) to DELAYED/2. to fix this RC

Thanks for your update! No need to wait IMHO, so I just ran:

dcut reschedule \
--file=php-sabre-vobject_2.1.7-3_amd64.changes --days=0

FYI, there is now a buildd available for arch:all, so you could have
simply dput the _source.changes without any binary package.

Regards

David


signature.asc
Description: PGP signature

Bug#825123: debarchiver: release files generated by debarchiver use weak digest algos in signatures

[Ola Lundqvist]

reopen 825123
severity 825123 important
thanks

Hi Christoph

You were perfectly correct in your suspicion about my config file. I
did have the hash algorithm specified there. I just did not know that
myself... It was changed in 2014. I can not tell if I did that or some
upgrade script. I really hope it was me.

I had:
cert-digest-algo SHA256
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
CAST5 ZLIB BZIP2 ZIP Uncompressed
default-recipient-self
keyserver pgpkeys.mit.edu
personal-digest-preferences SHA256
default-key XXX

I have checked and "personal-digest-preferences SHA256" is the one to use.
cert-digest-algo and default-preference-list do not have an effect to this case.

I several options here:
1) Document this clearly. I think I tend to prefer this alternative.
2) Use some option. I think --pgp7 could do the trick potentially.
3) Introduce some option to give the digest preference with default to
SHA512 (and with the possibility to disable that gpg command
preference).
4) Combination of 1 and 2.
5) Combination of 1 and 3.

See further below.

On Mon, Jun 6, 2016 at 11:44 PM, Christoph Anton Mitterer
 wrote:
...CUT...
>> I have done some testing and the hash depends on the version of gpg
>> you have and what key you have generated.
>>
>> If you have at least the version of gpg in jessie (I tested on
>> jessie)
>> and a 4096 bit RSA key then the default hash is SHA256 which from
>> what
> Hmm I actually suspected that first, and created all new keys (upload
> and repo keys), RSA4096 primary for C only and another RSA4096 signing
> subkey (and all of the binding/user signatures with SHA256)... but it
> didn't help.
>
> The signatures on the repo files were still made with SHA1 (and I'm
> running on sid, with the gpg of that).

My test was flawed. See above.

>> In addition to that the algorithm is configurable in
>> ~/.gnupg/gpg.conf
>> The statement to use is (without the quotes):
>> "personal-digest-preferences SHA256"
>> or whatever hash you would like to use.
>
> Hmm I think that's the reason why it worked for you (and I forgot about
> that).

Indeed it was.

> What I did, was making keys with SHA256,... but these aren't the digest
> preferences (and apparently gpg doesn't automatically set the digest-
> prefs of the key based on the algos used for it's creation).
> What you set above is exactly that,... i.e. what digest to use when
> signing content (not keys/UIDs),
>
>
>> Based on this I do not think this is a bug in at least jessie and
>> later and thus this should not be seen as a grave bug. Or for that
>> matter a bug at all in current stable and later. Therefore I'm
>> closing
>> this bug now.
> I'd agree,.. but I think it would be worth to EITHER include the above
> in the documentation of debarchiver (since it will probably take some
> time until gpg changes its default to >SHA1)...

I do not think they will change anytime soon unless a vast majority of
other implementations change and have done that for a long while.
See the phpN options for more details.

> OR, one could possibly
> make a check for debarchiver, to see whether something better than SHA1
> was already used and (*only*) if not, set that manually when signing.
> But such a check would be actually a bit tricky, because it would need
> to find out which UserID is actually used for signing, and check the
> preferences of that.

Yes that would indeed be very tricky. I think it is better that people
find this out by the fact that apt tools do not accept it.

> TBH, I'm not sure whether apt even just checks for the signature algo
> strength of the actual data signature (i.e. Release file, etc.) or
> whether it also checks for the UID/subkey binding signtures on the key.

I'm not 100% sure either. I'm not even sure that apt do not accept SHA1 keys.
What I do know is that apt check the signing key against the keyring.
But default against the standard debian keyring and that keyring no
longer have any SHA1 keys as all maintainers had to replace it with a
4096 key (I know as I was forced to do that myself).

>> I could probably accept that is a documentation bug for an upgrade
>> case, or that it should be clarified that 4096 bit keys should be
>> used
>> when signing the archive. If you think I should document this better,
>> please re-open the bug with a non-grave severity.
> I'd probably tend to call it a documentation wishlist/improvement
> idea... but I have no strong opinion.

Let it be important for now.

>
...CUT...

Best regards,

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#826606: ITP: resweb -- web interface to pyres jobs

[Gilles Dubuc]

Package: wnpp
Severity: wishlist
Owner: Gilles Dubuc 

* Package name: resweb
  Version : 0.1.7
  Upstream Author : Matt George 
* URL : https://github.com/binarydud/pyres
* License : MIT License
  Programming Lang: Python
  Description : web interface to pyres jobs

Resweb originally started as part of the pyres project. However, I
realized that for many reasons, both it and pyres would benefit from
being their own projects. Hopefully this will help the release
schedule of both pyres and resweb.

Bug#730073: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes

[Ben Hutchings]

On Mon, 2016-06-06 at 21:15 +, Arno Schuring wrote:
> Hi Ben,
> 
> > this configuration is no longer supported.
> 
> Fair enough. Thanks for considering.
> 
> Does that mean /etc/kernel-img.conf will disappear completely?

Some settings there will continue to be supported by the official
linux-image packages and are documented in linux-update-symlinks(1).

kernel-package supports several another (different) settings (but seems
to have removed support for do_symlinks and no_symlinks some time ago).

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be
development of an easy way to factor large prime numbers. - Bill Gates


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

Bug#826607: jessie-pu: package clamav/0.99.2+dfsg-0+deb8u2

[Sebastian Andrzej Siewior]

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

The last version (0.99.2+dfsg-0+deb8u1) removed AllowSupplementaryGroups
and hit stable over the weekend. Now Hans van Kranenburg had an
unattended upgrade and the config file was not fixed up (i.e. the option
removed as suggested during the upgrade process). clamav did not start,
he fixed it manually and reported #826406.
This update will ignore the AllowSupplementaryGroups option whether set
or not and the behaviour will remain unchanged. All binaries will behave
the same except they won't complain about the AllowSupplementaryGroups
option. The plan is not to push this change into unstable so people
upgrading Jessie -> Stretch have to have this option removed at this
point.

I am not sure if this update makes sense at this point since most people
got probably bitten by this, cursed my name and moved on. So if you
think that this update makes sense here it is - otherwise...

Sebastian
diff --git a/debian/.git-dpm b/debian/.git-dpm
index 462fb68..286a2a5 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-2489109e048f803a6019c00671cff2b43f139555
-2489109e048f803a6019c00671cff2b43f139555
+279c06a817c13eb22dc3ade949ea8b4a8aea9825
+279c06a817c13eb22dc3ade949ea8b4a8aea9825
 48a96d2a3f0f4aca12f39f62a53fe1671a6e15a2
 48a96d2a3f0f4aca12f39f62a53fe1671a6e15a2
 clamav_0.99.2+dfsg.orig.tar.xz
diff --git a/debian/changelog b/debian/changelog
index 9cde7f8..5ebcb45 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+clamav (0.99.2+dfsg-0+deb8u2) stable; urgency=medium
+
+  * Don't fail if AllowSupplementaryGroups is still set in the config file but
+ignore it and continue (Closes: #826406).
+
+ -- Sebastian Andrzej Siewior   Mon, 06 Jun 2016 22:06:52 +0200
+
 clamav (0.99.2+dfsg-0+deb8u1) stable; urgency=medium
 
   * Import new Upstream.
diff --git a/debian/patches/ingore-AllowSupplementaryGroups-option.patch b/debian/patches/ingore-AllowSupplementaryGroups-option.patch
new file mode 100644
index 000..b152276
--- /dev/null
+++ b/debian/patches/ingore-AllowSupplementaryGroups-option.patch
@@ -0,0 +1,28 @@
+From 279c06a817c13eb22dc3ade949ea8b4a8aea9825 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Mon, 6 Jun 2016 21:17:34 +0200
+Subject: Ignore AllowSupplementaryGroups if set
+
+Ignore the AllowSupplementaryGroups option if set. This should ease
+stable auto upgrade in case nobody touches the config files.
+
+BTS: https://bugs.debian.org/826406
+Patch-Name: ingore-AllowSupplementaryGroups-option.patch
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ shared/optparser.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/shared/optparser.c b/shared/optparser.c
+index e2b28cc..f8911ea 100644
+--- a/shared/optparser.c
 b/shared/optparser.c
+@@ -285,6 +285,8 @@ const struct clam_option __clam_options[] = {
+ 
+ { "User", NULL, 0, CLOPT_TYPE_STRING, NULL, -1, NULL, 0, OPT_CLAMD | OPT_MILTER, "Run the daemon as a specified user (the process must be started by root).", "clamav" },
+ 
++{ "AllowSupplementaryGroups", NULL, 0, CLOPT_TYPE_BOOL, MATCH_BOOL, 0, NULL, 0, OPT_CLAMD | OPT_FRESHCLAM | OPT_MILTER, "Initialize a supplementary group access (the process must be started by root).", "no" },
++
+ /* Scan options */
+ { "Bytecode", "bytecode", 0, CLOPT_TYPE_BOOL, MATCH_BOOL, 1, NULL, 0, OPT_CLAMD | OPT_CLAMSCAN, "With this option enabled ClamAV will load bytecode from the database. It is highly recommended you keep this option on, otherwise you'll miss detections for many new viruses.", "yes" },
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 82aadd6..3c7804d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,3 +7,4 @@ clamav_add_private_fts_implementation.patch
 fix-ssize_t-size_t-off_t-printf-modifier.patch
 libclamav-use-libmspack.patch
 drop-AllowSupplementaryGroups-option-and-make-it-def.patch
+ingore-AllowSupplementaryGroups-option.patch
diff --git a/shared/optparser.c b/shared/optparser.c
index e2b28cc..f8911ea 100644
--- a/shared/optparser.c
+++ b/shared/optparser.c
@@ -285,6 +285,8 @@ const struct clam_option __clam_options[] = {
 
 { "User", NULL, 0, CLOPT_TYPE_STRING, NULL, -1, NULL, 0, OPT_CLAMD | OPT_MILTER, "Run the daemon as a specified user (the process must be started by root).", "clamav" },
 
+{ "AllowSupplementaryGroups", NULL, 0, CLOPT_TYPE_BOOL, MATCH_BOOL, 0, NULL, 0, OPT_CLAMD | OPT_FRESHCLAM | OPT_MILTER, "Initialize a supplementary group access (the process must be started by root).", "no" },
+
 /* Scan options */
 { "Bytecode", "bytecode", 0, CLOPT_TYPE_BOOL, MATCH_BOOL, 1, NULL, 0, OPT_CLAMD | OPT_CLAMSCAN, "With this option enabled ClamAV will load bytecode from the database. It is highly recommended you keep this option on, 

Bug#825123: debarchiver: release files generated by debarchiver use weak digest algos in signatures

[Ola Lundqvist]

On Mon, Jun 6, 2016 at 11:47 PM, Christoph Anton Mitterer
 wrote:
..CUT...
> Another way would probably be to simply add the preference setting to
> the gpg config (for the debarchiver user)... may in the beginning if
> later (user) settings would override such.
> But I personally wouldn't like that, as I think tools shouldn't mess
> around with that automagically...

Agree. Let us not do that.

// Ola


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#695552: Olá amigo

[Wang Jianlin]

Olá amigo
Tenho a intenção de dar-lhe uma parte de minha riqueza como uma doação 
financeira livre-arbítrio para você, Responder a participar.

Wang Jianlin
Grupo Wanda

Bug#826605: geeqie: thumbnails disappear after deleting an image

[Christoph Anton Mitterer]

Package: geeqie
Version: 1:1.3-1
Severity: normal


Hi.

After deleting an image (from within geequie) the thumbnail list gets empty
(all white), until one e.g. Page-Up/Down, when it's redrawn.

Cheers,
Chris.


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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.3-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-11
ii  libcairo21.14.6-1+b1
ii  libexiv2-14  0.25-3
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-5
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgtk2.0-0  2.24.30-2
ii  libjpeg62-turbo  1:1.4.2-2
ii  liblcms2-2   2.7-1
ii  liblircclient0   0.9.0~pre1-1.2
ii  liblua5.1-0  5.1.5-8
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpangoft2-1.0-01.40.1-1
ii  libstdc++6   6.1.1-5
ii  libtiff5 4.0.6-1

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.1.3-5
ii  exiftran 2.10-2+b2
ii  exiv20.25-3
ii  imagemagick  8:6.8.9.9-7.1
ii  librsvg2-common  2.40.15-1
ii  ufraw-batch  0.22-1
ii  zenity   3.20.0-1

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.16-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.4.2-2
ii  ufraw0.22-1
pn  xpaint   

-- no debconf information

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

Hi!

On Sun, 2015-05-24 at 20:11:42 +0300, Niko Tyni wrote:
> On Wed, May 28, 2014 at 08:10:50AM +0200, Guillem Jover wrote:
> > On Tue, 2014-05-27 at 23:56:03 +0300, Niko Tyni wrote:
> 
> > > @debian-perl: To make this usable for the original problem (giving
> > > dpkg-dev a working File::FcntlLock without a transitive hard dependency
> > > on perlapi-*), I suppose the package should either be split or the
> > > ${perl:Depends} dependency should be relaxed to a recommendation.
> > 
> > Either would work for me, the latter might be problematic for current
> > code not assuming that it can fallback to use one of the pure perl
> > versions though. Although checking now it seems only libdpkg-perl is
> > making use of the module in Debian, so it might not be such an issue
> > after all; and would avoid a round-trip over NEW, a very tiny package,
> > and would guarantee the packages and modules are always present (even
> > if not fully functional). Anyway, I'm fine with whatever you decide.
> 
> Hi, we've been looking at this again at the Debian Perl sprint in
> Barcelona. Jens: see below for another feature request (and sorry
> for bothering you again with this :)
> 
> > > (Hm, my preliminary testing indicates that 5.20.0 may introduce new
> > >  challenges around PERL_DL_NONLAZY.  Urgh. Will investigate.)
> > 
> > Thanks, will take that into account! And I'm obviously interested in
> > any results from that investigation, which might imply having to switch
> > to always use the pure version for example. :)
> 
> We ended up moving XS modules into Perl version specific paths in 5.20, so
> PERL_DL_NONLAZY=1 should no longer be needed, and the above "challenges"
> became moot. Perl shouldn't be able to see binary incompatible modules
> anymore.
> 
> However, this introduced another problem. As the architecture dependent
> parts of @INC now vary with the Perl version, packages that put files
> there also need a dependency on perlapi-* to ensure they match the
> installed Perl version, otherwise they won't be found at all. See Perl
> policy 4.4.2, at
> 
>  
> https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps
> 
> To achieve the goal of having a libfile-fcntllock-perl package which
> doesn't have a hard dependency on perlapi-*, we need another place to
> put File::FcntlLock::Pure, which is architecture dependent but not
> Perl version dependent. That could be something like
>  /usr/lib//libfile-fcntllock-perl
> However, I'd like to punt information about that solely to the
> libfile-fcntllock-perl package, so that callers wouldn't need
> to be aware of the details.
> 
> Jens: would it be possible to have the main File::FcntlLock module
> fall back to ::Pure (or even ::Inline after that, I suppose) in case
> ::XS is not found on @INC? Or are the API differences mentioned
> in the documentation big enough that this wouldn't really work?
> In that case maybe something like File::FcntlLock::Any with a minimal
> API would make sense?
> 
> For full disclosure, if we had the fallback we could setup the
> modules something like this:
> 
>  /usr/share/perl5/File/FcntlLock.pm
> on normal arch-independent @INC; tries ::XS first and
> falls back to ::Pure from a special directory
> 
>  /usr/lib//libfile-fcntllock-perl/File/FcntllLock/Pure.pm
> in a special directory that only File::FcntlLock knows
> possibly with an additional symlink on the normal @INC too
> 
>  /usr/lib///File/FcntlLock/XS.pm (and .so)
> on normal arch-dependent @INC
> 
> The "special directory" part would be a Debian-specific deviation
> that wouldn't need any upstream support.
> 
> This way we could honestly have the package just Recommend
> perlapi-*, and have it still work (even if in a degraded state)
> when there's version skew between Perl and the XS parts.
> 
> (Jens: I can have a shot at a patch for this if that helps...)

I've been looking recently at creating a small helper to delegate the
locking to, because the automatic dbgsym packages and dpkg coloring
have exacerbated this annoyance when building packages :), but that
poses varios problems, and using an XS module is definitely the
cleanest approach. And the mail from Josh just reminded me that this
seems to have fallen through the cracks. :)

As I've mentioned before I'd really prefer to use the pre-existing
module to avoid duplicating work, but if the correct solution might
take too much effort, I might look into embedding something based on
this module into dpkg itself temporarily.

Also maybe we should file the above as a bug report against
libfile-fcntllock-perl and block this one aginst the new one?

Thanks,
Guillem

Bug#826044: needrestart: Hangs in apt hook with a zombie

[Axel Beckert]

Hi Thomas,

Thomas Liske wrote:
> Is the problem reproducable?

I've got a new (partial) answer on that: It seems non-deterministic.
I'd say it happend in about 5-10% of the cases in the past few days
(i.e. 2 times within a week or so).

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#825123: debarchiver: release files generated by debarchiver use weak digest algos in signatures

[Christoph Anton Mitterer]

On Mon, 2016-06-06 at 23:44 +0200, Christoph Anton Mitterer wrote:
> I'd agree,.. but I think it would be worth to EITHER include the
> above
> in the documentation of debarchiver (since it will probably take some
> time until gpg changes its default to >SHA1)... OR, one could
> possibly
> make a check for debarchiver, to see whether something better than
> SHA1
> was already used and (*only*) if not, set that manually when signing.
> But such a check would be actually a bit tricky, because it would
> need
> to find out which UserID is actually used for signing, and check the
> preferences of that.

Another way would probably be to simply add the preference setting to
the gpg config (for the debarchiver user)... may in the beginning if
later (user) settings would override such.
But I personally wouldn't like that, as I think tools shouldn't mess
around with that automagically...

smime.p7s
Description: S/MIME cryptographic signature

Bug#826599: kdepim-runtime depends and build-depends on packages that are no longer built.

[Maximiliano Curia]

Control: reassign -1 kdepim-runtime 4:4.14.10-2
Control: tag -1 pending

¡Hola peter!

El 2016-06-06 a las 20:34 +0100, peter green escribió:
package: kdepim-runtime 
severity: serious 
version: 2.2.0-2


The version seems to be the one for libkgapi2-2, but you are reporting it to 
kdepim-runtime.


Even though libkgapi is the offending package here, this will be solved with 
the upload of kdepim-runtime and kdepim.


kdepim-runtime depends on libkgapi2-2 and build-depends on 
libkgapi-dev . These packages were previously built by the source 
package libkgapi but are no longer built.


There is a pending transition for this, that will be completed when kdepim 
enters unstable.

https://release.debian.org/transitions/html/auto-libkgapi.html

This was noted via irc by a release team member and we agreed that 
this could wait for now. At least if it's not breaking anything right now, 
I could upload a src:libkgapi2 if the current state is really affecting 
anything.


This appears to be fixed in the version in experimental, maybe it's 
time to upload that to sid?


Not yet, we still need a few more packages that need to go through the NEW
queue.

Happy hacking,
--
"Seek simplicity, and distrust it." -- Whitehead's Rule
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#825123: debarchiver: release files generated by debarchiver use weak digest algos in signatures

[Christoph Anton Mitterer]

Hey Ola.

On Mon, 2016-06-06 at 23:28 +0200, Ola Lundqvist wrote:
> Thank you for your report, and sorry for a late reply.
No worries :)


> I have done some testing and the hash depends on the version of gpg
> you have and what key you have generated.
> 
> If you have at least the version of gpg in jessie (I tested on
> jessie)
> and a 4096 bit RSA key then the default hash is SHA256 which from
> what
Hmm I actually suspected that first, and created all new keys (upload
and repo keys), RSA4096 primary for C only and another RSA4096 signing
subkey (and all of the binding/user signatures with SHA256)... but it
didn't help.

The signatures on the repo files were still made with SHA1 (and I'm
running on sid, with the gpg of that).


> In addition to that the algorithm is configurable in
> ~/.gnupg/gpg.conf
> The statement to use is (without the quotes):
> "personal-digest-preferences SHA256"
> or whatever hash you would like to use.

Hmm I think that's the reason why it worked for you (and I forgot about
that).

What I did, was making keys with SHA256,... but these aren't the digest
preferences (and apparently gpg doesn't automatically set the digest-
prefs of the key based on the algos used for it's creation).
What you set above is exactly that,... i.e. what digest to use when
signing content (not keys/UIDs),


> Based on this I do not think this is a bug in at least jessie and
> later and thus this should not be seen as a grave bug. Or for that
> matter a bug at all in current stable and later. Therefore I'm
> closing
> this bug now.
I'd agree,.. but I think it would be worth to EITHER include the above
in the documentation of debarchiver (since it will probably take some
time until gpg changes its default to >SHA1)... OR, one could possibly
make a check for debarchiver, to see whether something better than SHA1
was already used and (*only*) if not, set that manually when signing.
But such a check would be actually a bit tricky, because it would need
to find out which UserID is actually used for signing, and check the
preferences of that.

TBH, I'm not sure whether apt even just checks for the signature algo
strength of the actual data signature (i.e. Release file, etc.) or
whether it also checks for the UID/subkey binding signtures on the key.


> I could probably accept that is a documentation bug for an upgrade
> case, or that it should be clarified that 4096 bit keys should be
> used
> when signing the archive. If you think I should document this better,
> please re-open the bug with a non-grave severity.
I'd probably tend to call it a documentation wishlist/improvement
idea... but I have no strong opinion.


> For wheezy this is a bug, but I do not think it is severe enough to
> issue a DLA. If you object I'm happy to help out with that (I happen
> to know that drill :-) ).
No that's fine :)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#677865: [PATCH] Always use flock for file locking; drop Recommends on libfile-fcntllock-perl

[Guillem Jover]

Control: tags -1 - patch

Hi!

On Sun, 2016-06-05 at 14:37:51 -0700, Josh Triplett wrote:
> Control: tags -1 + patch
> 
> The attached patch implements the change I suggested, dropping fcntl
> locking in favor of flock, and documenting that change in the changelog
> along with the rationale.

> >From 0c6eddc8200e7bea482ad65c5870f7977847d26a Mon Sep 17 00:00:00 2001
> From: Josh Triplett 
> Date: Sun, 5 Jun 2016 14:27:38 -0700
> Subject: [PATCH] Always use flock for file locking; drop Recommends on
>  libfile-fcntllock-perl
> 
> Per the flock(2) manpage, NFS clients going back to Linux 2.6.12
> translate flock into an fcntl lock on the entire file.

This is a non-portable Linux-only assumption. dpkg works on other
systems besides Linux-based ones. I'm also unhappy even about the
fallback to flock when fcntl is not available, as on other systems
the locks might not see each other so that's the worst possible
behavior.

I've in fact been looking into this recently. And I'll ping the perl
maintainers to try to get the required packaging fixes implemented in
libfile-fcntllock-file done. Otherwise I'll probably embed something
similar to that module as a private Dpkg module.

Thanks,
Guillem

Bug#826604: override: bubblewrap:admin/optional

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: bubblew...@packages.debian.org

bubblewrap was initially uploaded with Priority: extra and Section: web.
However, it isn't really web-related, and is likely to become an
indirect dependency (or at least an indirect Recommends) for task-gnome
in future, via this dependency chain:

gnome-software -> flatpak -> bubblewrap

when Flatpak stops shipping a private copy of bubblewrap (#824647),
and gnome-software switches from xdg-app to flatpak and adds the appropriate
build-dependency.

In the recent 0.1.0 upload we changed Flatpak from web/extra to
admin/optional, which puts it in the same category as (for example) sudo
and policykit-1. This seems more appropriate. Please apply the same change
in the overrides file.

Thanks,
S

Bug#826603: ttf-unifont: 301C WAVE DASH is drawn wrong

[Christoph Anton Mitterer]

Package: ttf-unifont
Version: 1:8.0.01-1
Severity: normal
Tags: upstream

Hi.

The glyph for 301C 〜 WAVE DASH is drawn wrong by that font.
The problem is apparently that this was buggy in one of the
first Unicode versions and later corrected.

https://en.wikipedia.org/wiki/Wave_dash shows it pretty well.

Cheers,
Chris.


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

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

Versions of packages ttf-unifont depends on:
ii  xfonts-utils  1:7.7+3

ttf-unifont recommends no packages.

ttf-unifont suggests no packages.

-- no debconf information

Bug#826486: flatpak: Rhythmbox won't launch without libpython3.4

[Simon McVittie]

On Sun, 05 Jun 2016 at 19:51:11 +0100, Liban Hannan wrote:
> After installing libpython3.4 through apt, Rhythmbox3 launches successfully.
> 
> However, my understanding is that a flatpak app shouldn't require extra
> dependencies.

I'm a little surprised this is even possible - it's unexpected for a Flatpak
app to be able to see the system-wide copy of Python at all, never mind
requiring it.

I'll look into this soon and work out whether it's a Flatpak bug or a
bug in the upstream-distributed bundle. (Or both :-)

S

Bug#826602: fonts-droid-fallback: 301C WAVE DASH is drawn wrong

[Christoph Anton Mitterer]

Package: fonts-droid-fallback
Version: 1:6.0.1r16-1
Severity: normal
Tags: upstream


Hi.

The glyph for 301C 〜 WAVE DASH is drawn wrong by that font.
The problem is apparently that this was buggy in one of the
first Unicode versions and later corrected.

https://en.wikipedia.org/wiki/Wave_dash shows it pretty well.

Cheers,
Chris.


-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  fontconfig 2.11.0-6.4   amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.6.3-3+b1   amd64FreeType 2 font engine, shared 
library files
ii  libxft2:amd64  2.3.2-1  amd64FreeType-based font drawing 
library for X

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

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

Versions of packages fonts-droid-fallback depends on:
ii  dpkg  1.18.7

Versions of packages fonts-droid-fallback recommends:
ii  fonts-noto-mono  20160116-1

Versions of packages fonts-droid-fallback suggests:
ii  fonts-noto  20160116-1

-- no debconf information

Bug#730073: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes

[Arno Schuring]

Hi Ben,

> this configuration is no longer supported.

Fair enough. Thanks for considering.

Does that mean /etc/kernel-img.conf will disappear completely?


Arno

From: Ben Hutchings 
Sent: Sunday, June 5, 2016 12:18:50 AM
To: 730...@bugs.debian.org; Arno
Subject: Re: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes

On Wed, 20 Nov 2013 23:22:46 +0100 Arno  wrote:
> Package: src:linux
> Version: 3.11.8-1
> Severity: normal
> 
> Dearest maintainer,
> 
> The latest kernel upgrade fails to complete its installation on my system. If
> I remember correctly, the previous new kernel failed to install in the same
> way but I chose to work around it instead of reporting it back then.
> 
> The symptom is a failing postinst script because initrd is missing:

I recently found this bug myself while reviewing the maintainer scripts.

> If I'm reading the postinst script correctly, this error is from either
> line 383 or line 422, which is called from image_magic() if the
> destination path is neither missing nor a symlink. This is the case on
> my system, because I have set both do_symlinks=no and no_symlinks=yes in
> /etc/kernel-img.conf (what's the difference between them?).

do_symlinks = no disables creating symlinks for the 'default' kernel and initrd.
no_symlinks = yes enables copying to the default filenames.

> For new
> kernels, the initrd has not been generated yet (that happens at the end
> of the script) and cp doesn't handle that case as gracefully as ln does.

Yes.  This regression was introduced when we moved the call to update-
initramfs into a hook script (around version 2.6.38).

> Even though the failure mode is created by no_symlinks in kernel-img.conf,
> simply changing those settings does not allow the installation to
> continue. That's because the /initrd.img file still exists, and
> image_magic() is driven by the existing paths, not the config settings.
> Conversely, simply setting no_symlinks=yes in the config does not prevent
> a new kernel to be installed initially -- but as soon as a new initrd is
> generated (and the /initrd symlink is replaced with a file), the next
> kernel installation will fail regardless of the current config setting.

I'm afraid my answer to this is that this configuration is no longer
supported.  If many people were using it, I would try to fix it, but it
seems that yours was the only bug report.  Future kernel packages will
warn and will create symlinks instead of copying.

Ben.

--
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg

Bug#826601: ITP: itty -- the itty-bitty python web framework

[Gilles Dubuc]

Package: wnpp
Severity: wishlist
Owner: Gilles Dubuc 

* Package name: python-itty
  Version : 0.8.2
  Upstream Author : Daniel Lindsley 
* URL : https://github.com/toastdriven/itty
* License : BSD License
  Programming Lang: Python
  Description : itty.py is a little experiment, an attempt at a
Sinatra influenced micro-framework that does just enough to be useful
and nothing more.

Currently supports:

Routing
Basic responses
Content-types
HTTP Status codes
URL Parameters
Basic GET/POST/PUT/DELETE support
User-definable error handlers
Redirect support
File uploads
Header support
Static media serving

Bug#826595: caja-sendto: further options using zip and bzip2 (and add 7zip, rar, etc)

[John Paul Adrian Glaubitz]

On 06/06/2016 08:45 PM, Max wrote:
> hello, I think is useful add further options like bzip (setting compression), 
> zip (adding password) and add other compression tools like 7zip, rar, etc.
> thanks

Same as with caja-image-converter, I recommend reporting this issue upstream 
[1].

Also, if you're particularly interested in these features, you could fork the 
code, make
the suggested changes and open a pull request on github. The fastest way to get 
wishlist
bugs like this one resolved is actually doing the work yourself.

It's open source software, after all.

Adrian

> [1] https://github.com/mate-desktop/caja-extensions

-- 
 .''`.  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

Bug#826594: caja-image-converter: automatic sub-directory

[John Paul Adrian Glaubitz]

On 06/06/2016 11:00 PM, John Paul Adrian Glaubitz wrote:
> On 06/06/2016 08:36 PM, Max wrote:
>> Hi, is it possible add an option to automatic create a sub-directory with 
>> inside it the converted images?
>> It's boring if I convert hundred of hundred of images, later move them to 
>> another dir.
> 
> This bug isn't particularly Debian-specific and you might want to report it 
> upstream [1].

Ignore the URL from my last mail, caja-image-converter is now part of 
caja-extensions [1].

> [1] https://github.com/mate-desktop/caja-extensions

-- 
 .''`.  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

Bug#826594: caja-image-converter: automatic sub-directory

[John Paul Adrian Glaubitz]

On 06/06/2016 08:36 PM, Max wrote:
> Hi, is it possible add an option to automatic create a sub-directory with 
> inside it the converted images?
> It's boring if I convert hundred of hundred of images, later move them to 
> another dir.

This bug isn't particularly Debian-specific and you might want to report it 
upstream [1].

> [1] https://github.com/mate-desktop/mate-file-manager-image-converter

-- 
 .''`.  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

Bug#825849: powerdns 100% CPU usage

[Markus Koschany]

On 06.06.2016 22:42, Christian Hofstaedtler wrote:
> * Martijn Bruinsma  [160530 20:24]:
>> Package: pdns-server
>> Version: 3.4.1-4+deb8u5
>>
>> I used apt-get to upgrade from version 3.4.1-4+deb8u4 to 3.4.1-4+deb8u5 
>> which left me with 100% Powerdns CPU usage (before the upgrade it was in the 
>> 25-30% range) and a mostly unresponsive Powerdns server. There are no 
>> messages in the error logs.
>> Aside from the Powerdns upgrade and a bunch of upgrades for other packages, 
>> apt-get also installed an upgrade for Libbotan (from 1.10.8-2 to 
>> 1.10.8-2+deb8u1) and after some testing the combination of the Powerdns and 
>> Libbotan packages turned out to be the source of the problem: when I 
>> downgraded both packages back to 3.4.1-4+deb8u4 and 1.10.8-2 respectively, 
>> everything was fine again.
> 
> I'd appreciate it if the security team / uploaders of the new
> botan1.10 and pdns 3.4.1-4+deb8u5 packages could chime in on this.

Hello,

pdns 3.4.1-4+deb8u5 was a no-change rebuild against botan1.10
1.10.8-2+deb8u1. If there is a regression it must be in botan1.10.

I have never used pdns before. Could you share you configuration with
us? How can we reproduce this issue?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#821805: kdevplatform: FTBFS in testing (ui_newclass.h: No such file or directory)

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 06 June 2016 17:47:04 Lisandro Damián Nicanor Pérez Meyer wrote:
[snip] 
> Moreover he already found the fix and marked the bug as pending. If he
> doesn't upload it soon I'll do it tomorrow.

Which he already did :)

Thank you both guys :)

-- 
La ciencia sin la religión es renga, la religión sin la ciencia es ciega.
 Albert Einstein

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


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

Bug#798179: openconnect: Link to Juniper VPN will not be established without reconnect

[Adnan Hodzic]

I also forgot to update you. But after numerous (NetworkManager), this
problem disappeared on Stretch.

So please feel free to close this bug report, as this problem is not an
issue anymore.

On Sun, May 29, 2016 at 7:20 PM, Mike Miller  wrote:

> On Sun, Oct 18, 2015 at 05:06:21 +0200, Adnan Hodzic wrote:
> > Hello,
> >
> > I've upgraded my whole system to Stretch now, and I can confirm that I
> > still have problem which I initially submitted in this bug report.
> >
> > Please let me know if I can provide you with any additional information
> > which could help you resolve it.
>
> NetworkManager debug logs would be helpful (your earlier logs do not
> have debug log level enabled), and ensure you are running the latest NM
> 1.2.2.
>
> As David said earlier, the problem may turn out to be that
> NetworkManager just doesn't work well when you configure things behind
> its back. I would not be surprised if you are able to debug this and
> determine that OpenConnect is behaving correctly, writing the expected
> resolv.conf, and NetworkManager is noticing a state change and deciding
> to "refresh" resolv.conf with its current internal state of what your
> DNS should be, which does not include the Juniper tunnel that you just
> brought up.
>
> Apologies for not seeing this earlier,
>
> --
> mike
>

Bug#785606: linux-image-4.0.0-1-amd64: DragonRise joystick support broken in 4.0.2-1

[Florent Rougon]

It seems the bug was fixed by this upstream commit:

commit 18339f59c3a6698ee17d32970c9e1e450b16e7c3
Author: Maciej Zuk
Date:   Thu Sep 3 21:46:39 2015 +0200

HID: dragonrise: fix HID Descriptor for 0x0006 PID

Fixed HID descriptor for DragonRise Joystick.  Replaced default descriptor
which doubles Z axis and causes mixing values of X and Z axes.

This means the first release incorporating the fix is v4.4 (v4.4-rc1
already contains it).

-- 
Florent

Bug#821805: kdevplatform: FTBFS in testing (ui_newclass.h: No such file or directory)

[Lisandro Damián Nicanor Pérez Meyer]

reopen 821805
notfixed 821805 1.7.3-1
thanks

Hi! Pino confirmed that it was a bug when being built with only one core. So I 
must keep my word and reopen this bug :)

Moreover he already found the fix and marked the bug as pending. If he doesn't 
upload it soon I'll do it tomorrow.

I'm also marking this bug as not fixed in 1.7.3-1, it seems I simply didn't 
get to reproduce it.

Kinds regards, Lisandro.

-- 
"With great power comes great responsibility."
  Peter Parker's uncle.

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


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

Bug#826600: sane-backends: saned option to change watchdog timeout

[Dhionel Díaz]

Source: sane-backends
Version: 1.0.25-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Some time after deploying a network shared scanner I found out that the
access to the device could be blocked by an idle client. A brief
revision showed that saned has an internal watchdog that can enforce a
timeout on idle connections; however, it was disabled in the default
debug level and also had a fixed value.

Attached you will find a patch that allows the configuration of the
watchdog timeout and enables it in the default debug level. The patch
builds upon the one sent with report #821255, in order to use the new
command line option processing scheme. For completeness, that patch is
also attached to the present message.

I've performed some brief tests and the changes work as expected. I hope
they can be useful.

Regards,


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

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


-- 
Dhionel Díaz
Centro Nacional de Desarrollo e Investigación en Tecnologías Libres
Ministerio del Poder Popular para
Educación Universitaria, Ciencia y Tecnología
diff -Nru sane-backends-1.0.25/debian/patches/0233-saned-remotescanners.patch sane-backends-1.0.25/debian/patches/0233-saned-remotescanners.patch
--- sane-backends-1.0.25/debian/patches/0233-saned-remotescanners.patch	1969-12-31 20:00:00.0 -0400
+++ sane-backends-1.0.25/debian/patches/0233-saned-remotescanners.patch	2016-04-13 18:38:35.0 -0430
@@ -0,0 +1,159 @@
+Description: saned option to report network-attached devices to clients
+Author: Jens-U. Mozdzen 
+Author: Dhionel Díaz 
+Bug: https://alioth.debian.org/tracker/index.php?func=detail=314768_id=30186=410366
+Last-Update: 2016-04-13
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/doc/saned.man
 b/doc/saned.man
+@@ -10,6 +10,7 @@
+ .I [ n ]
+ .B | \-s
+ .I [ n ]
++.B | \-r
+ .B | \-h
+ .B ]
+ .SH DESCRIPTION
+@@ -37,6 +38,14 @@
+ .B saned
+ will drop root privileges and run as this user (and group).
+ .PP
++If the
++.B \-r
++flag is specified, saned will also report remote scanners (those that are accessed
++via saned's "net" backend) when receiving an inquiry to list all devices. As the
++remote scanner may not be available at the time of the request, enabling this
++option may cause a significant delay, experienced by the remote client.
++Default is not to report those scanners.
++.PP
+ The
+ .B \-d
+ and
+@@ -94,6 +103,14 @@
+ machine, we strongly recommend using the Netfilter
+ \fInf_conntrack_sane\fP module instead.
+ .PP
++\fBreexport_remote_scanners\fP = \fI[ true | yes | 1 ]\fP
++Enables reporting remote scanners (those accessed via saned's "net"
++backend) to clients. As the remote scanner may not be available at
++the time of the request, enabling this option may cause a significant
++delay, experienced by the remote client.
++Any value other than "true", "yes" or "1" will keep this option disabled,
++which is the default when this option nor the command line flag "-r" is specified.
++.PP
+ The access list is a list of host names, IP addresses or IP subnets
+ (CIDR notation) that are permitted to use local SANE devices. IPv6
+ addresses must be enclosed in brackets, and should always be specified
+--- a/frontend/saned.c
 b/frontend/saned.c
+@@ -246,6 +246,7 @@
+ static int num_handles;
+ static int debug;
+ static int run_mode;
++static SANE_Bool reexport_remote_scanners_disabled = SANE_TRUE;
+ static Handle *handle;
+ static union
+ {
+@@ -1834,7 +1835,7 @@
+ 
+ 	reply.status =
+ 	  sane_get_devices ((const SANE_Device ***) _list,
+-			SANE_TRUE);
++			reexport_remote_scanners_disabled);
+ 	sanei_w_reply (w, (WireCodecFunc) sanei_w_get_devices_reply, );
+   }
+   break;
+@@ -2697,6 +2698,23 @@
+   DBG (DBG_INFO, "read_config: data port range: %d - %d\n", data_port_lo, data_port_hi);
+ }
+ }
++  else if (strstr(config_line, "reexport_remote_scanners") != NULL)
++{
++  optval = sanei_config_skip_whitespace (++optval);
++	  if ((optval != NULL) && (*optval != '\0'))
++	{
++		  if (optval == endval)
++		{
++  DBG (DBG_ERR, "read_config: invalid value for data_portrange\n");
++  continue;
++}
++		  else if ((strcmp( optval, "yes") == 0) || (strcmp( optval, "true") == 0) ||(strcmp( optval, "1") == 0))
++		{
++  reexport_remote_scanners_disabled = SANE_FALSE;
++  DBG (DBG_INFO, "main: enabled serving remote scanner devices\n");
++		}
++		}
++}
+ }
+   fclose (fp);
+   DBG (DBG_INFO, "read_config: 

Bug#825849: powerdns 100% CPU usage

[Christian Hofstaedtler]

* Martijn Bruinsma  [160530 20:24]:
> Package: pdns-server
> Version: 3.4.1-4+deb8u5
> 
> I used apt-get to upgrade from version 3.4.1-4+deb8u4 to 3.4.1-4+deb8u5 which 
> left me with 100% Powerdns CPU usage (before the upgrade it was in the 25-30% 
> range) and a mostly unresponsive Powerdns server. There are no messages in 
> the error logs.
> Aside from the Powerdns upgrade and a bunch of upgrades for other packages, 
> apt-get also installed an upgrade for Libbotan (from 1.10.8-2 to 
> 1.10.8-2+deb8u1) and after some testing the combination of the Powerdns and 
> Libbotan packages turned out to be the source of the problem: when I 
> downgraded both packages back to 3.4.1-4+deb8u4 and 1.10.8-2 respectively, 
> everything was fine again.

I'd appreciate it if the security team / uploaders of the new
botan1.10 and pdns 3.4.1-4+deb8u5 packages could chime in on this.

Many thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: PGP signature

Bug#823925: Fixed in unstable

[Pascal Giard]

Hi,
 I faced the exact same issue, the suggested workaround worked but is no
longer required for me. Indeed, with the latest updates to the synaptics
and libinput packages, my synaptics trackpad works again w/o any added
config in xorg.conf.d/ .

Regards,

-Pascal
-- 
Homepage (http://www.ece.mcgill.ca/~pgiard1)
Debian GNU/Linux (http://www.debian.org)
TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
ISIP Laboratory: McGill (http://www.isip.ece.mcgill.ca)
COMunité/LACIME: École de technologie supérieure (http://comunite.etsmtl.ca)

Bug#826593: transition: confuse

[Aurelien Jarno]

On 2016-06-06 20:30, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 06/06/16 20:25, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > Upstream has released a new version of confuse, which includes an ABI
> > change from libconfuse0 to libconfuse1. I have already uploaded the new
> > version to experimental, so a tracker is already available [1] to get
> > the list of reverse dependencies
> > 
> > In addition I have been able to successfully build all reverse
> > dependencies against this version on amd64. I therefore do not expect
> > any particular issue with this transition.
> 
> Go ahead.

Thanks for the quick answer. I have just uploaded it to sid.

Aurelien

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

Bug#826577: transition: qtquick1-opensource-src

[Emilio Pozuelo Monfort]

On 06/06/16 17:16, Lisandro Damián Nicanor Pérez Meyer wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RT! With the arrival of Qt 5.6.1 we will be removing
> src:qtquick1-opensource-src. We have already been filing bugs against the
> affected packages, which should be really a few now.
> 
> I would like to set up a tracker to have a proper view of the removal.
> I'll ask for a Qt 5.6.1 transition later.
> 
> Note: I have not tried the ben file below.

$ dak rm -Rn qtquick1-opensource-src
Will remove the following packages from unstable:

libqt5declarative5 |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
qtquick1-5-dbg |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
qtquick1-5-dev |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
qtquick1-5-dev-tools |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, 
i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, 
s390x
qtquick1-5-examples |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
qtquick1-opensource-src |5.5.1-2 | source
qtquick1-qml-plugins |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, 
i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, 
s390x
qtquick1-qmltooling-plugins |5.5.1-2 | amd64, arm64, armel, armhf, 
hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, 
powerpc, ppc64el, s390x

Maintainer: Debian Qt/KDE Maintainers 

--- Reason ---

--

Checking reverse dependencies...
# Broken Build-Depends:
kadu: qtquick1-5-dev
kadu-mime-tex: qtquick1-5-dev
musescore: qtquick1-5-dev
phonon: qtquick1-5-dev

Dependency problem found.

Cheers,
Emilio

Bug#818472: [DRE-maint] Bug#818472: ruby-diaspora-vines: unsatisfiable Depends: ruby-eventmachine (>= 1.0.8)

[Cédric Boutillier]

Hi!

I noticed that this package has no repository on Alioth in the Ruby
team. Could you please push the Git repo to the team infrastructure?

I could also this weekend start a new one by importing the existing .dsc
package.

Cheers,

Cédric


signature.asc
Description: PGP signature

Bug#826587: apt: misleading message on trying to remove Important:yes packages

[Julian Andres Klode]

On Mon, Jun 06, 2016 at 09:23:30PM +0200, Adam Borowski wrote:
> On Mon, Jun 06, 2016 at 08:48:12PM +0200, Julian Andres Klode wrote:
> > On Mon, Jun 06, 2016 at 07:29:44PM +0200, Adam Borowski wrote:
> > > When trying to remove an Important:yes package, the message claims it's
> > > essential:
> 
> > Well, it sort of is. Not in the "Essential: yes" sense, but in a broader
> > sense.
> 
> My point is, the word "essential" has a specific meaning, so reusing it for
> something only somewhat similar is bound to cause confusion -- at the least,
> make the user think he's dealing with an actually Essential package.

The same applies to important, which is the main reason everyone wants a 
different name :/ (it's a historic artefact that I just re-used, it used
to mean the same as Essential in early APT versions; now it's basically: Do
not remove if already installed).

> 
> There's a difference between needing the highest level of confirmation known
> to apt and something dpkg doesn't even require confirmation for.
> 
> > we have not decided on an official name for that field, the current one is
> > just a very old one.
> 
> In that case, perhaps using it in packages is premature?

Not really, we're (I am) supporting it. It's mostly a matter of getting dpkg to 
support
it for extra safety that an official field would bring (dpkg would then require
--force-remove-somethinglikeessential to remove it).

Main use case so far was local system configuration meta packages, but init
systems and bootloaders seem like a very good thing as well. Basically anything
that should not be removed normally once installed.

> 
> > So, no idea what to do here.
> 
> Hmm, if you're still debating what Important should do (and even its very
> name), making big changes here might indeed be a waste of effort because of
> the risk of having to do them again.  Thus, what about changing just the
> message for now?  An interface for overriding it can wait until you're happy
> with the specs.

I'm not sure what you mean with overriding it - my problem is to
think of a more useful message...

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#826591: [pkg-firebird-general] Bug#826591: fb_config --embedliibs gives non-existing -lfbembed

[Damyan Ivanov]

Control: tags -1 upstream
Control: retitle -1 fb_config --embedlibs gives non-existing -lfbembed

-=| Rene Engelhard, 06.06.2016 20:13:47 +0200 |=-
> Package: firebird-dev
> Version: 3.0.0.32483.ds4-3
> Severity: important
> 
> On Mon, Jun 06, 2016 at 11:27:17AM +, Debian Bug Tracking System wrote:
> >  firebird3.0 (3.0.0.32483.ds4-3) experimental; urgency=medium
> >  .
> >* install fb_config in firebird-dev (Closes: #826320)
> 
> Thanks, but it seems that doesn't do what it should?
> 
> % fb_config --embedlibs
> -L/usr/lib -lfbembed
> 
> Which of course fails given there is no libfbembed.so anymore. TTBOMK
> people should use -lfbclient?

Ouch. Your guess seems correct to me. I'll file a bug upstream and try 
to help them with a patch.

> > AC_MSG_NOTICE([fb_config found])
> > FIREBIRD_VERSION=`$FIREBIRDCONFIG --version`
> > AC_MSG_CHECKING([for Firebird Client library])
> > FIREBIRD_CFLAGS=`$FIREBIRDCONFIG --cflags`
> > FIREBIRD_LIBS=`$FIREBIRDCONFIG --embedlibs`
> > FilterLibs "${FIREBIRD_LIBS}"
> > FIREBIRD_LIBS="${filteredlibs}"
> 
> And that one is used here.


signature.asc
Description: Digital signature

Bug#826563: perl: Apparent regression in TryCatch with stable update

[Dominic Hargreaves]

On Mon, Jun 06, 2016 at 04:15:30PM +0300, Niko Tyni wrote:
> On Mon, Jun 06, 2016 at 02:36:10PM +0200, Guillem Jover wrote:
> > Package: perl
> > Version: 5.20.2-3+deb8u5
> > Severity: serious
> > Control: affects -1 libtrycatch-perl
> 
> > We've noticed some code using the TryCatch module (libtrycatch-perl
> > package) that stopped working after the stable update. Setting as
> > serious as this looks like a regression for code that used to work,
> > and for which I don't see anything supposedly wrong with it (?), which
> > follows the documented pattern. Here's a small reproducer showing the
> > problem:
> 
> Thanks for the report. The libtrycatch-perl test suite fails now,
> as does the one in libdevel-declare-perl.
> 
> The issue seems to be in libdevel-declare-perl:
>  https://rt.perl.org/Public/Bug/Display.html?id=123865
> 
> I've tested that applying the patch there to libdevel-declare-perl makes
> your test script work again, and makes the libtrycatch-perl test suite
> pass again too.

Thanks Niko for analysis. The sequence of events went like this:

1) a commit (which fixed a segfault, but broke compatibility) was
   committed to the upstream development branch
2) upstream testing detected the issue in Devel::Declare, and a new
   version was released to CPAN fixing the problem.
3) the fix was backported to maint-5.20, and in the process of that
   backporting, the knowledge that there was a known issue was lost.

The general feeling on IRC was that point release updates should indeed
avoid breaking old versions of libraries on CPAN, and that a known
issue should have been included in the perldelta. This will be added
to the release managers guide in future.

In hindsight, it's obvious that Debian's testing of this update wasn't
sufficient either. Such breaking changes in perl stable updates are,
I believe, exceedingly rare, but equally we had not attempted a wholesale,
or near-wholesale update in Debian stable before, and the breakage
wasn't reported in any real-world testing using the stable update
installed from source. In future, we should perform similar automated
testing against jessie-proposed-updates as we do in experimental when
a new major version of perl is introduced.

My plan is:

1) submit a new version of libdevel-declare-perl for immediate
   inclusion in stable-updates.
2) kick off a test rebuild of packages using perl to catch any issues
   in this update (at least those which we can catch by package builds
   and test suites).
3) document this in the perl maintenance notes on the wiki for future
   reference

I should be able to do at least the first two of these this evening.

Thanks and apologies.
Dominic.

Bug#825572: Uploaded to DELAYED/2

[Mathieu Parent]

 Hello David,

I've uploaded php-sabre-vobject (2.1.7-3) to DELAYED/2. to fix this RC

Cheers,
-- 
Mathieu Parent

Bug#826599: kdepim-runtime depends and build-depends on packages that are no longer built.

[peter green]

package: kdepim-runtime
severity: serious
version: 2.2.0-2

kdepim-runtime depends on libkgapi2-2 and build-depends on libkgapi-dev 
. These packages were previously built by the source package libkgapi 
but are no longer built.


This appears to be fixed in the version in experimental, maybe it's time 
to upload that to sid?

Bug#826369: flashplugin-nonfree: Cannot update Flash Player to version available on upstream site (latest version)

[Philipp Spitzer]

Package: flashplugin-nonfree
Version: 1:3.6.1
Followup-For: Bug #826369

Dear all,

I have the same problem on my machine using the stable release (1:3.6.1):


root@sirius:/# update-flashplugin-nonfree --status
Flash Player version installed on this system  : 11.2.202.616
Flash Player version available on upstream site: 11.2.202.621
flash-mozilla.so - auto mode
  link currently points to
  /usr/lib/flashplugin-nonfree/libflashplayer.so
  /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
  Current 'best' version is
  '/usr/lib/flashplugin-nonfree/libflashplayer.so'.
root@sirius:/# update-flashplugin-nonfree --install
root@sirius:/# update-flashplugin-nonfree --status
Flash Player version installed on this system  : 11.2.202.616
Flash Player version available on upstream site: 11.2.202.621
flash-mozilla.so - auto mode
  link currently points to
  /usr/lib/flashplugin-nonfree/libflashplayer.so
  /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
  Current 'best' version is
  '/usr/lib/flashplugin-nonfree/libflashplayer.so'.



Interestingly, the call of
update-flashplugin-nonfree --install
does not last very long and does not show the dots I remember from
previous updates.

With the --verbose flag the call get's lengthy but interesting:



root@sirius:/# update-flashplugin-nonfree --install --verbose
options :  --install --verbose --
temporary directory: /tmp/flashplugin-nonfree.aVfy8OUhCH
importing public key ...
selected action = --install
installed version = 11.2.202.616
upstream version = 11.2.202.621
wgetoptions= -nd -P .   -v --progress=dot:default 
downloading
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.i386.pgp.asc
...
--2016-06-06 20:53:44--
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.i386.pgp.asc
Resolving people.debian.org (people.debian.org)... 5.153.231.30,
2001:41c8:1000:21::21:30
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:80...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location:
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.i386.pgp.asc
[following]
--2016-06-06 20:53:45--
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.i386.pgp.asc
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443...
connected.
HTTP request sent, awaiting response... 404 Not Found
2016-06-06 20:53:45 ERROR 404: Not Found.

wget failed to download
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.621.sha512.i386.pgp.asc
downloading
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.i386.pgp.asc
...
--2016-06-06 20:53:45--
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.i386.pgp.asc
Resolving people.debian.org (people.debian.org)... 5.153.231.30,
2001:41c8:1000:21::21:30
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:80...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location:
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.i386.pgp.asc
[following]
--2016-06-06 20:53:45--
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.i386.pgp.asc
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1248 (1.2K) [text/plain]
Saving to: './fp10.sha512.i386.pgp.asc'

 0K . 100%
1.10M=0.001s

2016-06-06 20:53:46 (1.10 MB/s) - './fp10.sha512.i386.pgp.asc' saved
[1248/1248]

verifying PGP fp10.sha512.i386.pgp.asc ...
copying
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.i386.tar.gz
...
verifying checksum install_flash_player_11_linux.i386.tar.gz ...
wgetoptions= -nd -P .   -v --progress=dot:default  -O
/tmp/flashplugin-nonfree.aVfy8OUhCH/install_flash_player_11_linux.i386.tar.gz
downloading
https://fpdownload.adobe.com/get/flashplayer/pdc/11.2.202.616/install_flash_player_11_linux.i386.tar.gz
...
verifying checksum install_flash_player_11_linux.i386.tar.gz ...
unpacking install_flash_player_11_linux.i386.tar.gz ...
verifying checksum contents of install_flash_player_11_linux.i386.tar.gz
...
moving libflashplayer.so to /usr/lib/flashplugin-nonfree ...
setting permissions and ownership of
/usr/lib/flashplugin-nonfree/libflashplayer.so ...
Flash Player version: 11.2.202.616
moving install_flash_player_11_linux.i386.tar.gz to
/var/cache/flashplugin-nonfree ...
flash-mozilla.so - auto mode
  link currently points to
/usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is
'/usr/lib/flashplugin-nonfree/libflashplayer.so'.
calling update-alternatives ...
flash-mozilla.so - auto mode
  link currently points to
/usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50

Bug#825658: [Pkg-xfce-devel] Bug#825658: Bug#825658: release.debian.org: XFWM4 Compositor Issue - Patches released for LightDM-GTK-Greeter and XFWM4

[Yves-Alexis Perez]

On dim., 2016-06-05 at 18:00 +1000, Jeff Mills wrote:
> Not sure you got my last reply.  By upstream do you mean patched
> released packages?

At least committed in upstream repository.

> If so I am aware that the package has been updated in Xubuntu 16.04,
> this is a link to the related issue on Xfce4 Forum:
> https://forum.xfce.org/viewtopic.php?id=10859
> Patch log for Xfwm4 in the change logs here:
> Xfwm4
> http://changelogs.ubuntu.com/changelogs/pool/universe/x/xfwm4/xfwm4_4.12
> .3-1ubuntu2/changelog
> I could not find a patch entry for the LightDM-gtk-greeter package.
> Hoping this is what you need.

Unfortunately those links are not exploitable. It's random mess of people
saying “me too” here and there, which I don't have time to review.

If you want something to be fixed, please provide a simple, unique link, for
each issue, pointing to a tested patch, preferably vetted by upstream.

Regards,
-- 
Yves-Alexis

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

Bug#826384: libogre-1.9.0: Does not setup its own runtime link paths (ldconfig)

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist


Hi,

2016-06-05 9:05 GMT+01:00 shasheene :
> Package: libogre-1.9.0
> Version: libgre-1.9-dev, libogre-1.8-dev (and on Wheezy, libogre-1.7.4-dev)
> Severity: important
>
> Dear Maintainer,
>
> I have encountered this bug when attempting to build the example code for a 
> library named 'libhand' [1], which I have recently took upon myself to 
> maintain and update to support modern Debian/Linux.
>
> The package libogre-dev (and its related variants) on Debian 7/8 or Ubuntu 
> 12.04/14.04/16.04 does not appear to setup its runtime link parameters 
> correctly.
>
> The issue occurs when OGRE attempts to dynamically load a plugin with 
> loadPlugin() [2] I get the following output:
> *-*-* OGRE Initialising
> *-*-* Version 1.8.0 (Byatis)
> Loading library RenderSystem_GL
> Exception: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic 
> library RenderSystem_GL.  System Error: RenderSystem_GL.so: cannot open 
> shared object file: No such file or directory in DynLib::load at 
> /build/ogre-1.8-LbVXIp/ogre-1.8-1.8.0+dfsg1/OgreMain/src/OgreDynLib.cpp (line 
> 91)
>
> I have found a work around, if I first run:
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/OGRE-1.9.0
> sudo ldconfig
>
> The application then succeeds to create a rendered image.
>
> I am fairly new to OGRE, so I could be misusing the API (there is another 
> call, installPlugin() that suggests using loadPlugin() if possible). I do 
> know that loadPlugin() can use a plugin.cfg file (that specifies the linking 
> paths), but this is not the Debian way to do runtime linking. As a user of 
> libogre-dev, that's not a portable solution: using a script to populate the 
> exact path to the shared objects (depending on architecture) inside a local 
> plugin.cfg file seems to wrong way to go about it.
>
> I would have thought the /etc/ld.so.conf.d/[arch]-linux-gnu.conf file would 
> have sufficed for the search paths. given it doesn't appear to maybe the OGRE 
> deb file should do something like deploy a file to /etc/ld.so.conf.d/ and run 
> `sudo ldconfig` when it installs.
>
> [1] https://github.com/jonkeane/libhand
> [2] 
> http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_root.html#af0744e85bddb05885a91809bcdf8f864

As you say above, the path to the plugins is provided via plugins.cfg,
along with the set of plugins that the application wants to load (so
the application avoids "paying" for resources that doesn't use, avoids
crashes if the plugins don't work in the given hardware --which
happened in the past--, etc.).

At some point this file plugins.cfg was provided in Debian by the OGRE
packages, but after asking upstream it looks like most OGRE
installations and non-Linux platforms do not provide a "default"
plugins.cfg, and in the OGRE world applications are the ones providing
this file.

This is what other applications in Debian using OGRE already do.


Adding paths globally through /etc/ld.so.conf.d/ is not a good
solution, I think, because then all searches for libraries would be
forced to look into that directory, even if they are not OGRE
applications at all.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#826592: [Debian GNUstep maintainers] Bug#826592: gnustep-gui: FTBFS: 22 Failed builds

[Eric Heintzmann]

Yes, the tests failed to build.
This is because of the new version of gnustep-make.
But an upload of a new version of gnustep-gui is planned,
as soon as gnustep-base will be ready.

Le 06/06/2016 à 20:16, Chris Lamb a écrit :
> Source: gnustep-gui
> Version: 0.24.0-3.1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> gnustep-gui fails to build from source in unstable/amd64:
>
>   [..]
>
> if [ -f .//$l.lproj/$f -o -d .//$l.lproj/$f ]; then \
>   cp -fr .//$l.lproj/$f \
> ./StandardPicker.bundle/Resources/$l.lproj/; \
> else \
>   echo "Warning: .//$l.lproj/$f not found - ignoring"; \
> fi; \
>   done; \
> else \
>   echo "Warning: .//$l.lproj not found - ignoring"; \
> fi; \
>   done
>   echo "OLD_GNUSTEP_STAMP_ASTRING = _GSStandardColorPicker-" > 
> ./StandardPicker.bundle/stamp.make
>   (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
> echo "  NSExecutable = \"StandardPicker\";"; \
> echo "  NSMainNibFile = \"\";"; \
> echo "  NSPrincipalClass = \"GSStandardColorPicker\";"; \
> echo "}") >StandardPicker.bundle/Resources/Info-gnustep.plist
>   if [ -r "" ]; then \
> plmerge StandardPicker.bundle/Resources/Info-gnustep.plist ; \
>   fi
>   Making all for bundle NamedPicker...
>   cd .; \
>   /usr/share/GNUstep/Makefiles/mkinstalldirs ./obj/NamedPicker.obj/
>   /usr/share/GNUstep/Makefiles/mkinstalldirs NamedPicker.bundle/.
>   gcc GSNamedColorPicker.m -c \
> -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
> -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
> -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -fgnu-runtime -fconstant-string-class=NSConstantString -I../Headers/Additions 
> -I../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>  -o obj/NamedPicker.obj/GSNamedColorPicker.m.o
>   gcc -shared  -rdynamic -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed 
> -pthread  -fexceptions -o ./NamedPicker.bundle/./NamedPicker 
> ./obj/NamedPicker.obj/GSNamedColorPicker.m.o   -L../Source/./obj 
> -L../Models/./obj-L/usr/local/lib -L/usr/lib  -lgnustep-gui
> -lgnustep-base-lobjc   -lm
>   /usr/share/GNUstep/Makefiles/mkinstalldirs NamedPicker.bundle/Resources
>   for f in GSNamedColorPicker.tiff; do \
> if [ -f .//$f -o -d .//$f ]; then \
>   cp -fr .//$f ./NamedPicker.bundle/Resources/; \
> else \
>   echo "Warning: .//$f not found - ignoring"; \
> fi; \
>   done
>   echo "OLD_GNUSTEP_STAMP_ASTRING = _GSNamedColorPicker-" > 
> ./NamedPicker.bundle/stamp.make
>   (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
> echo "  NSExecutable = \"NamedPicker\";"; \
> echo "  NSMainNibFile = \"\";"; \
> echo "  NSPrincipalClass = \"GSNamedColorPicker\";"; \
> echo "}") >NamedPicker.bundle/Resources/Info-gnustep.plist
>   if [ -r "" ]; then \
> plmerge NamedPicker.bundle/Resources/Info-gnustep.plist ; \
>   fi
>   Making all for bundle WheelPicker...
>   cd .; \
>   /usr/share/GNUstep/Makefiles/mkinstalldirs ./obj/WheelPicker.obj/
>   /usr/share/GNUstep/Makefiles/mkinstalldirs WheelPicker.bundle/.
>   gcc GSWheelColorPicker.m -c \
> -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
> -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
> -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -fgnu-runtime -fconstant-string-class=NSConstantString -I../Headers/Additions 
> -I../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>  -o obj/WheelPicker.obj/GSWheelColorPicker.m.o
>   gcc GSColorSliderCell.m -c \
> -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
> -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
> -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -fgnu-runtime -fconstant-string-class=NSConstantString -I../Headers/Additions 
> -I../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>  -o obj/WheelPicker.obj/GSColorSliderCell.m.o
>   gcc -shared  -rdynamic -Wl,-z,relro -Wl,-z,defs 

Bug#826589: dpkg-gencontrol : "character 'S' not allowed" when running "make deb-pkg"

[Rares Aioanei]

You're right, clear case of PEBKAC. Please close at your conenience. Yes,
it also fails with -CHBAX, don't know why I remembered it worked.

On Mon, Jun 6, 2016 at 9:21 PM, Guillem Jover  wrote:

> Hi!
>
> On Mon, 2016-06-06 at 20:50:10 +0300, Rares Aioanei wrote:
> > Package: dpkg-dev
> > Version: 1.18.7
> > Severity: normal
> > File: /usr/bin/dpkg-gencontrol
>
> >* What led up to the situation?
> >I want to create a vanilla kernel .deb file. My kernel is configured
> to
> > have "-SCHBAX" appended to the version.
>
> The versions when generating Linux kernel packages tend to end up in
> the package name.
>
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >  Ran 'make menuconfig' and 'make deb-pkg'
> >* What was the outcome of this action?
> >  After compiling, when generating the packages, the process fails
> with
> > dpkg-gencontrol saying "character 'S' not allowed"
> >  If I remove the 'S' so the suffix in the name becomes "-CHBAX" the
> > compilation/package generation succeeds.
>
> Uppercase letters are not valid in package names. I find it very
> strange that just removing S and leaving -CHBAX let it build though.
> Are you sure you didn't remove the entire suffix?
>
> In any case this seems like user error, so I'm planning to close it in
> a bit. I'm mostly interested to know if for whatever reason the -CHBAX
> was accepted, which it should have not.
>
> Thanks,
> Guillem
>



-- 
Rares Aioanei

Bug#821805: kdevplatform: FTBFS in testing (ui_newclass.h: No such file or directory)

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 06 June 2016 20:27:22 Santiago Vila wrote:
> On Mon, Jun 06, 2016 at 11:10:03AM -0700, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > > This would still be a bug, right? Otherwise we would have to create a
> > > new control field for this, maybe "Build-CPUs: 2". I hope not!
> > 
> > Yes, but I doubt it would be RC as it does not affects the official
> > builds.
> 
> Feel free to downgrade to important if you wish.
> 
> I personally do not share the idea that a bug needs to happen in the
> official buildds to be RC, and I'll try to elaborate:
> 
> Imagine a package which FTBFS with 1/2 of probability.

Not really to have an argument on this, but as long as the FTBFS happen on 
non-official archs it's not RC. If it FTBFSs happen in official archs then it 
is RC, even it if happens half of the time.

But if someone can prove the bug is *really* happening due to -j1 I would 
concur it's RC, otherwise it might be something else.

FWIW I have filed a bug against qemu for building issues in parallel builds in 
the past, so maybe the bug is related to qemu/kvm.



-- 
You don’t marry someone you can live with – you marry the person who you
cannot live without.
  Anonymous

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


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

Bug#826587: apt: misleading message on trying to remove Important:yes packages

[Adam Borowski]

On Mon, Jun 06, 2016 at 08:48:12PM +0200, Julian Andres Klode wrote:
> On Mon, Jun 06, 2016 at 07:29:44PM +0200, Adam Borowski wrote:
> > When trying to remove an Important:yes package, the message claims it's
> > essential:

> Well, it sort of is. Not in the "Essential: yes" sense, but in a broader
> sense.

My point is, the word "essential" has a specific meaning, so reusing it for
something only somewhat similar is bound to cause confusion -- at the least,
make the user think he's dealing with an actually Essential package.

There's a difference between needing the highest level of confirmation known
to apt and something dpkg doesn't even require confirmation for.

> we have not decided on an official name for that field, the current one is
> just a very old one.

In that case, perhaps using it in packages is premature?

> So, no idea what to do here.

Hmm, if you're still debating what Important should do (and even its very
name), making big changes here might indeed be a waste of effort because of
the risk of having to do them again.  Thus, what about changing just the
message for now?  An interface for overriding it can wait until you're happy
with the specs.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#826598: ITP: golang-gopkg-dancannon-gorethink.v2 -- Go driver for RethinkDB

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block -1 by 826597
Control: affects -1 notary

   Package name: golang-gopkg-dancannon-gorethink.v2
Version: 2.0.4
Upstream Author: Daniel Cannon
License: Apache-2.0
URL: http://gopkg.in/dancannon/gorethink.v2
Description: Go driver for RethinkDB
 This package provides native Golang driver for RethinkDB.


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

Bug#826597: ITP: golang-github-hailocab-go-hostpool -- flexibly pool among multiple hosts from Go application

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-hailocab-go-hostpool
Version: 0.0~git20160125.
Upstream Author: Bitly
License: Expat
URL: https://github.com/hailocab/go-hostpool
Description: flexibly pool among multiple hosts from Go application
 go-hostpool is a Go package to intelligently and flexibly pool among
 multiple hosts from your Go application. Host selection can operate in
 round robin or epsilon greedy mode, and unresponsive hosts are avoided.


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

Bug#826573: cme: drops build profiles on dependencies

[Dominique Dumont]

On Mon, 06 Jun 2016 16:12:43 +0200 Stephen Kitt  wrote:
> Package: cme> running cme fix dpkg-control removes the build profiles:
> 
>mingw-w64-i686-dev (>= 3.0~svn5915),
>mingw-w64-x86-64-dev (>= 3.0~svn5915),
> 
> It would be nice if cme left them alone...

Indeed. I'll handle this.

Sorry about that.

All the best

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

Bug#826596: bsdutils: wall, write unable to handle UTF-8 characters.

[Vladimir Kudrya]

Package: bsdutils
Version: 1:2.28-5
Severity: normal

Dear Maintainer, wall and write are not able to handle UTF-8 characters:

Sending:
$ echo 'test тест' | write user
$ echo 'test тест' | wall

Receiving:
Message from user@hostname on pts/6 at 21:37 ...
test M-QM-^BM-PM-5M-QM-^AM-QM-^B
EOF

Broadcast message from user@hostname (pts/6) (Mon Jun  6 21:37:21 
2016):   

   
test \321\202\320\265\321\201\321\202


It seems that upstream BSD utilities have support for multibyte characters:
https://svnweb.freebsd.org/base/head/usr.bin/wall/wall.c?revision=241848=markup#l226
Thanks Guido Berhoerster, xwrited developer, for providing this info.

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

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

Versions of packages bsdutils depends on:
ii  libc62.22-9
ii  libsystemd0  230-2

Versions of packages bsdutils recommends:
ii  bsdmainutils  9.0.10

bsdutils suggests no packages.

-- no debconf information

Bug#826587: apt: misleading message on trying to remove Important:yes packages

[Julian Andres Klode]

On Mon, Jun 06, 2016 at 07:29:44PM +0200, Adam Borowski wrote:
> Package: apt
> Version: 1.2.12
> Severity: minor
> 
> Hi!
> When trying to remove an Important:yes package, the message claims it's
> essential:

Well, it sort of is. Not in the "Essential: yes" sense, but in a broader
sense. And we have not decided on an official name for that field, the
current one is just a very old one.

So, no idea what to do here.


-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#826595: caja-sendto: further options using zip and bzip2 (and add 7zip, rar, etc)

[Max]

Package: caja-sendto
Version: 1.14.0-1
Severity: wishlist

hello, I think is useful add further options like bzip (setting compression), 
zip (adding password) and add other compression tools like 7zip, rar, etc.
thanks

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

Kernel: Linux 4.5.0-2-686-pae (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: sysvinit (via /sbin/init)

Versions of packages caja-sendto depends on:
ii  caja-extensions-common   1.14.0-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-9
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcaja-extension1   1.14.1-1
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgtk-3-0   3.20.5-4
ii  libgupnp-1.0-4   0.20.16-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1

caja-sendto recommends no packages.

Versions of packages caja-sendto suggests:
ii  icedove 1:45.1.0-1
pn  pidgin | gajim  
ii  python-dbus 1.2.4-1

-- no debconf information

Bug#322540: ppc64 patch for yaboot FTBFS and e2fslibs1.41-dev

[Mathieu Malaterre]

-- Forwarded message --
From: Lennart Sorensen 
Date: Mon, Jun 6, 2016 at 6:57 PM
Subject: Re: Bug#825110: ppc64 patch for yaboot FTBFS and e2fslibs1.41-dev
To: Mathieu Malaterre , 825...@bugs.debian.org
Cc: Milan Kupcevic , debian-powe...@lists.debian.org


On Tue, May 31, 2016 at 09:17:20AM -0400,  wrote:
> On Tue, May 31, 2016 at 02:07:31PM +0200, Mathieu Malaterre wrote:
> > I understand your point for ppc64el, but since `yaboot` gets build on
> > ppc64, some users may break their systems...
>
> According to buildd, it fails to build on ppc64 (not surprising since
> it requires 32bit static libraries to link).  yaboot does not currently
> exist in the archive for anything other than 32bit powerpc.  So there
> is no reason for it to even attempt to build on 64bit.

Well in case anyone wants to try and fix it, these patches seem to fix
yaboot build on ppc64:

diff -urN yaboot-1.3.17.orig/debian/control yaboot-1.3.17/debian/control
--- yaboot-1.3.17.orig/debian/control   2015-11-02 02:54:41.0 +
+++ yaboot-1.3.17/debian/control2016-06-06 15:36:46.0 +
@@ -3,7 +3,7 @@
 Priority: important
 Maintainer: Debootloaders Yaboot Maintainers Team

 Uploaders: Aurélien GÉRÔME , Milan Kupcevic 
-Build-Depends: debhelper (>= 9), e2fslibs1.41-dev
+Build-Depends: debhelper (>= 9), e2fslibs1.41-dev, libc6-dev-powerpc [ppc64]
 Standards-Version: 3.9.6
 Homepage: http://yaboot.ozlabs.org


diff -urN e2fsprogs1.41-1.41.14.orig/debian/rules
e2fsprogs1.41-1.41.14/debian/rules
--- e2fsprogs1.41-1.41.14.orig/debian/rules 2015-11-02
02:20:29.0 +
+++ e2fsprogs1.41-1.41.14/debian/rules  2016-06-06 15:56:42.0 +
@@ -4,6 +4,7 @@

 export DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotector
 export DEB_CFLAGS_MAINT_APPEND=-fgnu89-inline -fno-builtin-malloc
+export CC:=$(CC) -m32

 %:
dh $@  --with autotools-dev
@@ -11,10 +12,18 @@
 override_dh_auto_install:
dh_auto_install --destdir=debian/tmp -- install-libs

+override_dh_auto_build:
+   dh_auto_build -- libs
+
 override_dh_auto_clean:
dh_auto_clean
rm -f asm_types.h public_config.h

+override_dh_auto_test:
+
+override_dh_auto_configure:
+   dh_auto_configure -- --host=powerpc-linux-gnu --target=powerpc-linux-gnu
+
 get-orig-source:
wget 
http://downloads.sourceforge.net/project/e2fsprogs/e2fsprogs/1.41.14/e2fsprogs-1.41.14.tar.gz
\
 -O e2fsprogs1.41_1.41.14.orig.tar.gz

The fix is that since yaboot is always built 32bit, then on ppc64 we
better build-dep on the 32bit libc headers and stuff, and when building
the e2fslibs it has to be built 32bit, not 64bit, since yaboot is the
only user and it is building 32bit.  While at it I made it stop building
all the other crap that wasn't actually being packaged since it was
taking too long to build.

I am not entirely pleased with the CC variable as a way to pass the
-m32 needed, but it seems to work.  Maybe someone can see a cleaner way
(maybe the configure command somehow) to do that.

I would have sent this to bug 322540 since that is the ppc64 yaboot
bug, but for some reason it is closed and archived even though it never
actually worked and was never actually built on ppc64.  That seems like
a mistake.

--
Len Sorensen

Bug#826594: caja-image-converter: automatic sub-directory

[Max]

Package: caja-image-converter
Version: 1.14.0-1
Severity: wishlist

Hi, is it possible add an option to automatic create a sub-directory with 
inside it the converted images?
It's boring if I convert hundred of hundred of images, later move them to 
another dir.
Thanks!

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

Kernel: Linux 4.5.0-2-686-pae (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: sysvinit (via /sbin/init)

Versions of packages caja-image-converter depends on:
ii  caja-extensions-common  1.14.0-1
ii  imagemagick 8:6.8.9.9-7+b2
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.22-9
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcaja-extension1  1.14.1-1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.1-1
ii  libgtk-3-0  3.20.5-4
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1

caja-image-converter recommends no packages.

caja-image-converter suggests no packages.

-- no debconf information

Bug#826593: transition: confuse

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 06/06/16 20:25, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> Upstream has released a new version of confuse, which includes an ABI
> change from libconfuse0 to libconfuse1. I have already uploaded the new
> version to experimental, so a tracker is already available [1] to get
> the list of reverse dependencies
> 
> In addition I have been able to successfully build all reverse
> dependencies against this version on amd64. I therefore do not expect
> any particular issue with this transition.

Go ahead.

Cheers,
Emilio

Bug#826593: transition: confuse

[Aurelien Jarno]

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

Dear release team,

Upstream has released a new version of confuse, which includes an ABI
change from libconfuse0 to libconfuse1. I have already uploaded the new
version to experimental, so a tracker is already available [1] to get
the list of reverse dependencies

In addition I have been able to successfully build all reverse
dependencies against this version on amd64. I therefore do not expect
any particular issue with this transition.

Regards,
Aurelien


[1] https://release.debian.org/transitions/html/auto-confuse.html

Ben file:

title = "confuse";
is_affected = .depends ~ "libconfuse0" | .depends ~ "libconfuse1";
is_good = .depends ~ "libconfuse1";
is_bad = .depends ~ "libconfuse0";

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

Kernel: Linux 4.6.0-trunk-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)

Bug#821805: kdevplatform: FTBFS in testing (ui_newclass.h: No such file or directory)

[Santiago Vila]

On Mon, Jun 06, 2016 at 11:10:03AM -0700, Lisandro Damián Nicanor Pérez Meyer 
wrote:

> > This would still be a bug, right? Otherwise we would have to create a
> > new control field for this, maybe "Build-CPUs: 2". I hope not!
> 
> Yes, but I doubt it would be RC as it does not affects the official builds.

Feel free to downgrade to important if you wish.


I personally do not share the idea that a bug needs to happen in the
official buildds to be RC, and I'll try to elaborate:

Imagine a package which FTBFS with 1/2 of probability.

If the last build in the official autobuilders was successful, it just
means that you were lucky that time, it would not mean that the
package builds "fine".

This is of course a theoretical exercise, or a "mental experiment",
but I once did in fact find a package behaving like that:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817033


I also found some funny case of a package which FTBFS when built under
stretch kernel (due to a bad interaction between the kernel and systemd).

Since autobuilders are still running jessie, the error would never
happen in an official autobuilder (yet). This is the bug if you are
curious, it made three different packages to FTBFS:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823530



Back to our case, it could be that official autobuilders have more
than one CPU, but I would call that an accident, not something which
is "granted" or "promised". In other words, having two CPUs is
not build essential.


Thanks.

Bug#826134: RFS: libvpd/2.2.5-1 ITP: libvpd -- VPD Database access library

[Frederic Bonnard]

Hi,

I did new upload right there :
https://mentors.debian.net/package/libvpd
https://mentors.debian.net/debian/pool/main/libv/libvpd/libvpd_2.2.5-1.dsc

> lets see:
> 
> usr/include/libvpd-2/*
> usr/lib/*/*.so
> usr/lib/*/pkgconfig/*
> 
> maybe you can put
> usr/include
> usr/lib/*/*.so
> usr/lib/*/pkgconfig
> 
> (I didn't check the above)

done
That works. And I changed to this in the new packaging.

For usr/include/libvpd-2/* -> usr/include
I initially used that "generic" regexps but I wondered and prefered more
targetted regexps to avoid copying files that were wrongly installed in that
path, in case of a later upstream version.
Meaning that the idea was that I see things failing and fix it, or extend the 
regexp
if that's correct, but don't put things blindly in that path.
However, I used usr/include in the packaging.

> and for the library you can do something like
> usr/lib/*/lib*.so.*

done

> "etc/udev/rules.d/90-vpdupdate.rules /lib/udev/rules.d"
> isn't this something that dh_installudev should do?

done
right, I didn't see there was also a dh_installbla for udev at that time :)

> rules file has a lot of useless stuff (comments, dh_options)

done

> d/patches: remove

done

> missing licenses:
> config/install-sh: MIT/X11 (BSD like)
> config/missing: GPL (v2 or later) GENERATED FILE
> config/ar-lib: GPL (v2 or later) GENERATED FILE
> config/depcomp: GPL (v2 or later) GENERATED FILE
> config/ltmain.sh: GPL (v2 or later)

done
Actually, for the last 4, the embedded license says :
---
 As a special exception to the GNU General Public License, if you
 distribute this file as part of a program that contains a
 configuration script generated by Autoconf, you may include it under
 the same distribution terms that you use for the rest of that program.
---
Does that mean that it could be distributed with the global license of the
project? And maybe needn't being explictly listed in d/copyright ?
Anyway, I added those files as well as config.guess, config.sub, aclocal.m4,
Makefile.in and configure with their specific Copyright and License, just in
case.

> debian/copyright: LGPL (v2.1 or later)
> 
> wrong copyright:
> License: LGPL-2+
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU Lesser General Public License as published
> by the Free Software Foundation; either version 2.1, or (at your option)
> 
> 
> 2+!=2.1+

done
Indeed, I missed something here.

> other stuff LGTM

On the lintian side, here is what remains :
P: libvpd source: debian-watch-may-check-gpg-signature
I: libvpd-2.2-2: spelling-error-in-binary 
usr/lib/powerpc64le-linux-gnu/libvpd_cxx-2.2.so.2.2.5 occured occurred
W: libvpd-2.2-2: dev-pkg-without-shlib-symlink 
usr/lib/powerpc64le-linux-gnu/libvpd-2.2.so.2.2.5 
usr/lib/powerpc64le-linux-gnu/libvpd-2.2.so
W: libvpd-2.2-2: dev-pkg-without-shlib-symlink 
usr/lib/powerpc64le-linux-gnu/libvpd_cxx-2.2.so.2.2.5 
usr/lib/powerpc64le-linux-gnu/libvpd_cxx-2.2.so

For the last 2, I think lintian gets lost with .so that are differently named :
lrwxrwxrwx root/root 0 2016-06-06 15:44 
./usr/lib/powerpc64le-linux-gnu/libvpd.so -> libvpd-2.2.so.2.2.5
lrwxrwxrwx root/root 0 2016-06-06 15:44 
./usr/lib/powerpc64le-linux-gnu/libvpd_cxx.so -> libvpd_cxx-2.2.so.2.2.5

F.

Bug#826589: dpkg-gencontrol : "character 'S' not allowed" when running "make deb-pkg"

[Guillem Jover]

Hi!

On Mon, 2016-06-06 at 20:50:10 +0300, Rares Aioanei wrote:
> Package: dpkg-dev
> Version: 1.18.7
> Severity: normal
> File: /usr/bin/dpkg-gencontrol

>* What led up to the situation?
>I want to create a vanilla kernel .deb file. My kernel is configured to
> have "-SCHBAX" appended to the version.

The versions when generating Linux kernel packages tend to end up in
the package name.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  Ran 'make menuconfig' and 'make deb-pkg'
>* What was the outcome of this action?
>  After compiling, when generating the packages, the process fails with
> dpkg-gencontrol saying "character 'S' not allowed"
>  If I remove the 'S' so the suffix in the name becomes "-CHBAX" the
> compilation/package generation succeeds.

Uppercase letters are not valid in package names. I find it very
strange that just removing S and leaving -CHBAX let it build though.
Are you sure you didn't remove the entire suffix?

In any case this seems like user error, so I'm planning to close it in
a bit. I'm mostly interested to know if for whatever reason the -CHBAX
was accepted, which it should have not.

Thanks,
Guillem

Bug#824931: similar to bug #824931

[Marc Lehmann]

On Mon, Jun 06, 2016 at 04:37:32PM +0200, Marco d'Itri  wrote:
> While I still think that this would be the most generally useful 
> semantics for other inetd-started daemons, I can see how it could 
> surprise telnet/rsh users.

It surely also suprises ftp users, samba users and users of other
services. I am not sure why you keep ignoring those and single out telnet
or rsh/rlogin? There is nothing special about rsh - all openbsd-inetd
services are affected the same way.

> Since I am not sure if there is a simple solution that could be 
> implemented in the telnetd package, at this point I am considering to 
> set KillMode=process as the default for openbsd-inetd.

It should be obvious that behaviour that is decades old and didn't suffer
from any obvious problems shouldn't be changed without a good reason,
which is the case for both bugs. Arguably, the systemd change has a better
rationale than the openbsd-inetd change.

So the mode that most closely resembles to what inetd has always done
should be the default unless there is reason to change.

This is especially true for "old" services - the older a service is, the
better the reason must be to break it. If a maintainer thinks breaking
stuff is ok just because he likes the new behaviour he/she is doing a bad
job.

> OTOH, I am not sure that this use (corner) case of telnet/rsh users is 
> more important than the others, even if the current default is 
> a regression for them, so I am still undecided...

A shame, really. In the absence of any good reason for a change, a change
shouldn't be done. If it breaks stuff, it should be undone.

In any case, it doesn't affect me anymore, because I already made the
transition to rlinetd, which doesn't have this bug, even if it cost me one
production box which had to be rebooted because openbsd-inetd killed all
kinds of system services when I installed rlinetd (because oßpenbsd killed
them and the apt-get process doing the rlinetd installation).

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#826592: gnustep-gui: FTBFS: 22 Failed builds

[Chris Lamb]

Source: gnustep-gui
Version: 0.24.0-3.1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

gnustep-gui fails to build from source in unstable/amd64:

  [..]

if [ -f .//$l.lproj/$f -o -d .//$l.lproj/$f ]; then \
  cp -fr .//$l.lproj/$f \
./StandardPicker.bundle/Resources/$l.lproj/; \
else \
  echo "Warning: .//$l.lproj/$f not found - ignoring"; \
fi; \
  done; \
else \
  echo "Warning: .//$l.lproj not found - ignoring"; \
fi; \
  done
  echo "OLD_GNUSTEP_STAMP_ASTRING = _GSStandardColorPicker-" > 
./StandardPicker.bundle/stamp.make
  (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
echo "  NSExecutable = \"StandardPicker\";"; \
echo "  NSMainNibFile = \"\";"; \
echo "  NSPrincipalClass = \"GSStandardColorPicker\";"; \
echo "}") >StandardPicker.bundle/Resources/Info-gnustep.plist
  if [ -r "" ]; then \
plmerge StandardPicker.bundle/Resources/Info-gnustep.plist ; \
  fi
  Making all for bundle NamedPicker...
  cd .; \
  /usr/share/GNUstep/Makefiles/mkinstalldirs ./obj/NamedPicker.obj/
  /usr/share/GNUstep/Makefiles/mkinstalldirs NamedPicker.bundle/.
  gcc GSNamedColorPicker.m -c \
-MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
-DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
-D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
-Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security -fgnu-runtime 
-fconstant-string-class=NSConstantString -I../Headers/Additions -I../Headers 
-I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
 -o obj/NamedPicker.obj/GSNamedColorPicker.m.o
  gcc -shared  -rdynamic -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -pthread  
-fexceptions -o ./NamedPicker.bundle/./NamedPicker 
./obj/NamedPicker.obj/GSNamedColorPicker.m.o   -L../Source/./obj 
-L../Models/./obj-L/usr/local/lib -L/usr/lib  -lgnustep-gui
-lgnustep-base-lobjc   -lm
  /usr/share/GNUstep/Makefiles/mkinstalldirs NamedPicker.bundle/Resources
  for f in GSNamedColorPicker.tiff; do \
if [ -f .//$f -o -d .//$f ]; then \
  cp -fr .//$f ./NamedPicker.bundle/Resources/; \
else \
  echo "Warning: .//$f not found - ignoring"; \
fi; \
  done
  echo "OLD_GNUSTEP_STAMP_ASTRING = _GSNamedColorPicker-" > 
./NamedPicker.bundle/stamp.make
  (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
echo "  NSExecutable = \"NamedPicker\";"; \
echo "  NSMainNibFile = \"\";"; \
echo "  NSPrincipalClass = \"GSNamedColorPicker\";"; \
echo "}") >NamedPicker.bundle/Resources/Info-gnustep.plist
  if [ -r "" ]; then \
plmerge NamedPicker.bundle/Resources/Info-gnustep.plist ; \
  fi
  Making all for bundle WheelPicker...
  cd .; \
  /usr/share/GNUstep/Makefiles/mkinstalldirs ./obj/WheelPicker.obj/
  /usr/share/GNUstep/Makefiles/mkinstalldirs WheelPicker.bundle/.
  gcc GSWheelColorPicker.m -c \
-MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
-DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
-D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
-Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security -fgnu-runtime 
-fconstant-string-class=NSConstantString -I../Headers/Additions -I../Headers 
-I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
 -o obj/WheelPicker.obj/GSWheelColorPicker.m.o
  gcc GSColorSliderCell.m -c \
-MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
-DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
-D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
-Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security -fgnu-runtime 
-fconstant-string-class=NSConstantString -I../Headers/Additions -I../Headers 
-I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
 -o obj/WheelPicker.obj/GSColorSliderCell.m.o
  gcc -shared  -rdynamic -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -pthread  
-fexceptions -o ./WheelPicker.bundle/./WheelPicker 
./obj/WheelPicker.obj/GSWheelColorPicker.m.o 
./obj/WheelPicker.obj/GSColorSliderCell.m.o   -L../Source/./obj 
-L../Models/./obj-L/usr/local/lib -L/usr/lib  -lgnustep-gui
-lgnustep-base-lobjc   -lm
  /usr/share/GNUstep/Makefiles/mkinstalldirs WheelPicker.bundle/Resources
  for f in GSWheelColorPicker.tiff; do \
if [ -f 

Bug#826591: fb_config --embedliibs gives non-existing -lfbembed

[Rene Engelhard]

Package: firebird-dev
Version: 3.0.0.32483.ds4-3
Severity: important

Hi,

On Mon, Jun 06, 2016 at 11:27:17AM +, Debian Bug Tracking System wrote:
>  firebird3.0 (3.0.0.32483.ds4-3) experimental; urgency=medium
>  .
>* install fb_config in firebird-dev (Closes: #826320)

Thanks, but it seems that doesn't do what it should?

% fb_config --embedlibs
-L/usr/lib -lfbembed

Which of course fails given there is no libfbembed.so anymore. TTBOMK
people should use -lfbclient?

> AC_MSG_NOTICE([fb_config found])
> FIREBIRD_VERSION=`$FIREBIRDCONFIG --version`
> AC_MSG_CHECKING([for Firebird Client library])
> FIREBIRD_CFLAGS=`$FIREBIRDCONFIG --cflags`
> FIREBIRD_LIBS=`$FIREBIRDCONFIG --embedlibs`
> FilterLibs "${FIREBIRD_LIBS}"
> FIREBIRD_LIBS="${filteredlibs}"

And that one is used here.

Regards,
 
Rene

Bug#821805: kdevplatform: FTBFS in testing (ui_newclass.h: No such file or directory)

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 06 June 2016 19:49:15 Santiago Vila wrote:
> On Mon, Jun 06, 2016 at 02:07:13PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > Santiago: Are you building with -j1?
> 
> I guess so. My virtual machines have only one CPU.

That might be the reason.

> > So far the only buildds that show this bug are hppa, hurd-i386, ppc64 and
> > sparc64 (all non-official ports). I suspect all of them being using -j1 to
> > build.
> 
> That would be really strange indeed. Sometimes I have seen packages to
> fail when they are build in parallel, but I have never seen a package
> to fail when it's not build in parallel.

Well, it *might* be a reason.

> This would still be a bug, right? Otherwise we would have to create a
> new control field for this, maybe "Build-CPUs: 2". I hope not!

Yes, but I doubt it would be RC as it does not affects the official builds.

-- 
Cuando alguna persona va al ataque contra Wikipedia argumentando
que no es confiable "porque encontró ya varios errores", hago la
siguiente pregunta: "¿Corregiste esos errores cuando los
encontraste?" Invariablemente, la respuesta es "no".
  Ariel Torres, "Probablemente, la Wikipedia esté bien"
  La Nación Tecnología, Sábado 25 de agosto de 2007
  http://www.lanacion.com.ar/tecnologia/nota.asp?nota_id=937889

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


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

Bug#826590: ruby-passenger: passenger-memory-stats doesn't display Total counter in Jessie

[Alex Kiousis]

Source: ruby-passenger
Version: 4.0.53-1
Severity: normal

Dear Maintainer,

We use the script passenger-memory-stats as a munin plugin source. When
upgrading from Wheezy to Jessie we saw that the output of the script
didn't include the footers with the total numbers (but otherwise the
script run fine).

E.g. this was missing:

### Processes: 15
### Total private dirty RSS: 1310.94 MB


After some digging around i ended up with this:
/usr/sbin/passenger-memory-stats calls
AdminTools::MemoryStats:platform_provides_private_dirty_rss_information
which returns PlatformInfo:os_name which in turn looksup
rb_config['target_os'] (on Wheezy it used RUBY_PLATFORM).
This (/usr/lib/x86_64-linux-gnu/ruby/2.1.0/rbconfig.rb) returns
"linux-gnu" on Ruby 2.1.0 and "linux" on previous versions:

p4.grnet.gr:~# locate rbconfig.rb | xargs -I{} sh -c "echo {} && grep
target_os {}"
/usr/lib/ruby/1.8/x86_64-linux/rbconfig.rb
  CONFIG["target_os"] = "linux"
/usr/lib/ruby/1.9.1/x86_64-linux/rbconfig.rb
  CONFIG["target_os"] = "linux"
/usr/lib/x86_64-linux-gnu/ruby/2.1.0/rbconfig.rb
  CONFIG["target_os"] = "linux-gnu"

I believe the problem is in 'platform_info/operating_system.rb'.
Based on the comment on line 32:

'# Linux is always identified as"linux".'

Upstream code is now like this (line 39):

 elsif rb_config['target_os'] =~ /^linux-/

the shipped script contains this (line 37):

 elsif rb_config['target_os'] == "linux-"

So i believe this is a bug that is fixed upstream but occurs in the
currently packaged version.

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

Kernel: Linux 3.16.0-4-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)

Bug#826036: closed by Ghislain Antony Vaillant <ghisv...@gmail.com> (Bug#826036: fixed in pyfftw 0.10.3+dfsg1-1)

[Marten van Kerkwijk]

Dear Ghislain,

Thanks for looking into the installation problems, and solving them!
(I'll check as soon as the package lands somewhere).

All the best,

Marten

p.s.  Sorry for not reacting to your earlier request to provide library
  information.  Oddly, I don't recall getting that by e-mail; I only
  saw it now that I got the message that the bug was closed.

Bug#826569: libreoffice writer: doesn't let you select a different language for spell checking

[Rene Engelhard]

On Mon, Jun 06, 2016 at 06:27:25PM +0200, José Luis González wrote:
> Interestingly my document was written in English and it didn't guess
> English, plus it showed Spanish instead. Probably because Spanish was
> set as the language of the text.

Jup. AFAICT per default it's the locale.

> > and/or check whether they appear in 
> > Tools -> Options -> Language Settings -> Writing Aids -> Edit..
> 
> They don't appear there. Only the modules and the standard, technical
> and IgnoreAllList user dictionaries.

?? Next to the modules there's Edit which then has a dropdown with all
languages and which shows what has what available.

> They were installed. As I said before, the problem was the language of
> the text was set as Spanish. Until I set it to British the British
> dictionary didn't appear in the menu, together with Spanish.

But that explains it, if the language is Spanish it will check it as
Spanish of course.

Regards,

Rene

Bug#784682: Make wishlist

[Joerg Dorchain]

reopen 784682
retitle 784682 "Please backport new version to jessie"
severity wishlist
thanks

Hello Zed,

reopening this bug as a hint for people like me who ran into problems
with the version of snoopy currently in stable.

The dangling file descriptor that is fixed in the mentioned upstream bug
report also affects co-existence with other packages, for me notably
puppet. The package recompiles without change on jessie, so backport is
rather trivial, just needs an upload to the backport queue. A recent
version of snoopy might also fix other bugs.

TIA for considering.

Bye,

Joerg

Bug#826589: dpkg-gencontrol : "character 'S' not allowed" when running "make deb-pkg"

[Rares Aioanei]

Package: dpkg-dev
Version: 1.18.7
Severity: normal
File: /usr/bin/dpkg-gencontrol

Dear Maintainer,


   * What led up to the situation?
   I want to create a vanilla kernel .deb file. My kernel is configured to
have "-SCHBAX" appended to the version.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Ran 'make menuconfig' and 'make deb-pkg'
   * What was the outcome of this action?
 After compiling, when generating the packages, the process fails with
dpkg-gencontrol saying "character 'S' not allowed"
 If I remove the 'S' so the suffix in the name becomes "-CHBAX" the
compilation/package generation succeeds.
   * What outcome did you expect instead?
   I didn't expect dpkg-gencontrol to be sensible about certain characters
in the kernel name.

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

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

Versions of packages dpkg-dev depends on:
ii  base-files9.6
ii  binutils  2.26-9
ii  bzip2 1.0.6-8
ii  libdpkg-perl  1.18.7
ii  make  4.1-9
ii  patch 2.7.5-1
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages dpkg-dev recommends:
ii  build-essential  11.7
ii  fakeroot 1.20.2-1
ii  gcc [c-compiler] 4:5.3.1-3
ii  gcc-5 [c-compiler]   5.3.1-21
ii  gnupg1.4.20-6
ii  gnupg2   2.1.11-7
ii  gpgv 1.4.20-6
ii  libalgorithm-merge-perl  0.08-3
Versions of packages dpkg-dev suggests:
pn  debian-keyring  

-- no debconf information

-- 
Rares Aioanei

Bug#821805: kdevplatform: FTBFS in testing (ui_newclass.h: No such file or directory)

[Santiago Vila]

On Mon, Jun 06, 2016 at 02:07:13PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Santiago: Are you building with -j1?

I guess so. My virtual machines have only one CPU.

> So far the only buildds that show this bug are hppa, hurd-i386, ppc64 and 
> sparc64 (all non-official ports). I suspect all of them being using -j1 to 
> build.

That would be really strange indeed. Sometimes I have seen packages to
fail when they are build in parallel, but I have never seen a package
to fail when it's not build in parallel.

This would still be a bug, right? Otherwise we would have to create a
new control field for this, maybe "Build-CPUs: 2". I hope not!

Thanks.

Bug#624251: RFP: joyce -- Amstrad PCW Emulator

[Stephen Kitt]

On Tue, Apr 26, 2011 at 10:02:47PM +0100, Mark Hobley wrote:
> * Package name: joyce
>   Version : 2.2.4
>   Upstream Author : j...@seasip.demon.co.uk (John Elliot)
> * URL : http://www.seasip.demon.co.uk/Unix/Joyce/

This is now at http://www.seasip.info/Unix/Joyce/index.html

> * License : Mixed licences
>   Programming Lang: 
>   Description : Amstrad PCW Emulator
> 
> This is an emulator of the Amstrad PCW which can be used on several platforms.


signature.asc
Description: PGP signature

Bug#825918: Bug#813546: Actually 1954 error message groups

[積丹尼 Dan Jacobson]

I note a full purge and then fresh install of all these programs avoids
the errors.

Bug#826588: spice: diff for NMU version 0.12.6-4.1

[Salvatore Bonaccorso]

Package: spice
Version: 0.12.6-4
Severity: normal
Tags: patch pending

Dear Liang and Michael,

I've prepared an NMU for spice (versioned as 0.12.6-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru spice-0.12.6/debian/changelog spice-0.12.6/debian/changelog
--- spice-0.12.6/debian/changelog	2015-11-06 08:48:27.0 +0100
+++ spice-0.12.6/debian/changelog	2016-06-06 19:22:50.0 +0200
@@ -1,3 +1,13 @@
+spice (0.12.6-4.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2016-0749: heap-based buffer overflow in smartcard interaction
+(Closes: #826585)
+  * CVE-2016-2150: host memory access from guest using crafted primary surface
+parameters (Closes: #826584)
+
+ -- Salvatore Bonaccorso   Mon, 06 Jun 2016 19:22:10 +0200
+
 spice (0.12.6-4) unstable; urgency=medium
 
   * stop depending libspice-server-dev on libcacard-dev (#802413).
diff -Nru spice-0.12.6/debian/patches/CVE-2016-0749/0001-smartcard-add-a-ref-to-item-before-adding-to-pipe.patch spice-0.12.6/debian/patches/CVE-2016-0749/0001-smartcard-add-a-ref-to-item-before-adding-to-pipe.patch
--- spice-0.12.6/debian/patches/CVE-2016-0749/0001-smartcard-add-a-ref-to-item-before-adding-to-pipe.patch	1970-01-01 01:00:00.0 +0100
+++ spice-0.12.6/debian/patches/CVE-2016-0749/0001-smartcard-add-a-ref-to-item-before-adding-to-pipe.patch	2016-06-06 19:22:50.0 +0200
@@ -0,0 +1,89 @@
+From  Mon Sep 17 00:00:00 2001
+From: Marc-Andre Lureau 
+Date: Thu, 17 Dec 2015 18:13:47 +0100
+Subject: [PATCH] smartcard: add a ref to item before adding to pipe
+
+There is an unref when the message is sent.
+
+==17204== ERROR: AddressSanitizer: heap-use-after-free on address 0x6008000144a8 at pc 0x7fffee0ce245 bp 0x7fffc630 sp 0x7fffc620
+READ of size 4 at 0x6008000144a8 thread T0
+#0 0x7fffee0ce244 in smartcard_unref_vsc_msg_item /home/elmarco/src/spice/spice/server/smartcard.c:608
+#1 0x7fffee0cb451 in smartcard_unref_msg_to_client /home/elmarco/src/spice/spice/server/smartcard.c:178
+#2 0x7fffedfcdf14 in spice_char_device_read_from_device /home/elmarco/src/spice/spice/server/char-device.c:330
+#3 0x7fffedfd1763 in spice_char_device_wakeup /home/elmarco/src/spice/spice/server/char-device.c:901
+#4 0x7fffee05da98 in spice_server_char_device_wakeup /home/elmarco/src/spice/spice/server/reds.c:2990
+#5 0x5593fa34 in spice_chr_write /home/elmarco/src/qemu/spice-qemu-char.c:189
+#6 0x559375f1 in qemu_chr_fe_write /home/elmarco/src/qemu/qemu-char.c:220
+#7 0x55b3b682 in ccid_card_vscard_send_msg.isra.2 /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:76
+#8 0x55b3c466 in ccid_card_vscard_send_error /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:91
+#9 0x55b3c466 in ccid_card_vscard_handle_message /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:242
+#10 0x55b3c466 in ccid_card_vscard_read /home/elmarco/src/qemu/hw/usb/ccid-card-passthru.c:289
+#11 0x5593f169 in vmc_write /home/elmarco/src/qemu/spice-qemu-char.c:41
+#12 0x7fffedfcee6d in spice_char_device_write_to_device /home/elmarco/src/spice/spice/server/char-device.c:477
+#13 0x7fffedfcfd31 in spice_char_device_write_buffer_add /home/elmarco/src/spice/spice/server/char-device.c:629
+#14 0x7fffee0ce9df in smartcard_channel_write_to_reader /home/elmarco/src/spice/spice/server/smartcard.c:675
+#15 0x7fffee0cc7db in smartcard_char_device_notify_reader_add /home/elmarco/src/spice/spice/server/smartcard.c:341
+#16 0x7fffee0ce4f3 in smartcard_add_reader /home/elmarco/src/spice/spice/server/smartcard.c:648
+#17 0x7fffee0cf2e2 in smartcard_channel_handle_message /home/elmarco/src/spice/spice/server/smartcard.c:763
+#18 0x7fffedffe21f in red_peer_handle_incoming /home/elmarco/src/spice/spice/server/red-channel.c:307
+#19 0x7fffedffe4f6 in red_channel_client_receive /home/elmarco/src/spice/spice/server/red-channel.c:325
+#20 0x7fffee00726c in red_channel_client_event /home/elmarco/src/spice/spice/server/red-channel.c:1566
+#21 0x55c3c53d in qemu_iohandler_poll /home/elmarco/src/qemu/iohandler.c:143
+#22 0x55c3b800 in main_loop_wait /home/elmarco/src/qemu/main-loop.c:504
+#23 0x556f160c in main_loop /home/elmarco/src/qemu/vl.c:1818
+#24 0x556f160c in main /home/elmarco/src/qemu/vl.c:4394
+#25 0x7fffed7d0b14 in __libc_start_main /usr/src/debug/glibc-2.17-c758a686/csu/libc-start.c:274
+#26 0x556f9c20 in _start (/home/elmarco/src/qemu/x86_64-softmmu/qemu-system-x86_64+0x1a5c20)
+0x6008000144a8 is located 24 bytes inside of 40-byte region [0x600800014490,0x6008000144b8)
+freed by thread T0 here:
+#0 0x74e61009 in __interceptor_free 

Bug#826587: apt: misleading message on trying to remove Important:yes packages

[Adam Borowski]

Package: apt
Version: 1.2.12
Severity: minor

Hi!
When trying to remove an Important:yes package, the message claims it's
essential:

(gcc6-amd64-sbuild)root@umbar:/# apt-get purge init
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  sysvinit-core
Use 'apt autoremove' to remove it.
The following packages will be REMOVED:
  init*
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  init
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 15.4 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] ^C
(gcc6-amd64-sbuild)root@umbar:/# apt-cache show init
<...>
Important: yes
<...>

(gcc6-amd64-sbuild)root@umbar:/# dpkg --purge init
(Reading database ... 11961 files and directories currently installed.)
Removing init (1.34) ...

Bug#821805: kdevplatform: FTBFS in testing (ui_newclass.h: No such file or directory)

[Lisandro Damián Nicanor Pérez Meyer]

tag 821805 moreinfo
thanks

On Monday 06 June 2016 17:23:10 Santiago Vila wrote:
> found 821805 1.7.3-2
> thanks
> 
> Dear maintainers:
> 
> This package still FTBFS in testing for me, and I can reproduce it
> every time in different machines.
> 
> I attach a recent build log.
> 
> Feel free to ask about any detail regarding my build environment which
> is not already answered in the build log or in previous messages in
> this thread.

Santiago: Are you building with -j1?

So far the only buildds that show this bug are hppa, hurd-i386, ppc64 and 
sparc64 (all non-official ports). I suspect all of them being using -j1 to 
build.

I could not reproduce this bug on amd64/i386 on real hardware (ie, not 
qemu/kvm) so far.

-- 
Must it be assumed that because we are engineers beauty is not
our concern, and that while we make our constructions robust
and durable we do not also strive to make them elegant?
Is it not true that the genuine conditions of strength always
comply with the secret conditions of harmony?
 Gustave Eiffel, 1887

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


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

Bug#788374: system-config-printer-udev: systemd service fails with "failed to connect to CUPS"

[Tomaž Šolc]

Hi

On 06. 06. 2016 15:23, Laurent Bigonville wrote:
> Could you please also check if the cups.socket is active? The systemd
> service file is explicitly requiring it:
> 
> Requires=cups.socket
> After=cups.socket

cups.socket is active and seems to be activated before configure-printer
according to systemd.

This is the currently reported status. 2016-04-28 around 20:00 was the
last reboot of this system.

$ systemctl status cups.socket
● cups.socket - CUPS Printing Service Sockets
   Loaded: loaded (/lib/systemd/system/cups.socket; enabled)
   Active: active (running) since čet 2016-04-28 20:00:23 CEST; 1 months
8 days ago
   Listen: /var/run/cups/cups.sock (Stream)

$ systemctl status cups.service
● cups.service - CUPS Printing Service
   Loaded: loaded (/lib/systemd/system/cups.service; enabled)
   Active: active (running) since pon 2016-06-06 18:33:03 CEST; 1min 5s ago
 Docs: man:cupsd(8)
   man:cupsd.conf(5)
 Main PID:  (cupsd)
   CGroup: /system.slice/cups.service
   └─ /usr/sbin/cupsd -f

$ systemctl status configure-printer@usb-007-002.service
● configure-printer@usb-007-002.service - Configure Plugged-In Printer
   Loaded: loaded (/lib/systemd/system/configure-printer@.service; static)
   Active: failed (Result: exit-code) since čet 2016-04-28 20:00:29
CEST; 1 months 8 days ago
 Main PID: 750 (code=exited, status=1/FAILURE)

Best regards
Tomaž



signature.asc
Description: OpenPGP digital signature

Bug#826586: corosync-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/corosync/html/corosync-blackbox.8.html

[Andreas Beckmann]

Package: corosync-doc
Version: 2.3.5-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package corosync-doc.
  Preparing to unpack .../corosync-doc_2.3.5-8_all.deb ...
  Unpacking corosync-doc (2.3.5-8) ...
  dpkg: error processing archive 
/var/cache/apt/archives/corosync-doc_2.3.5-8_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/corosync/html/corosync-blackbox.8.html', 
which is also in package corosync 1.4.6-1.1
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/corosync-doc_2.3.5-8_all.deb


cheers,

Andreas


corosync=1.4.6-1.1_corosync-doc=2.3.5-8.log.gz
Description: application/gzip