Bug#1025417: linux: LOCK_DOWN_IN_EFI_SECURE_BOOT help claims confidentiality mode

[Kalle Olavi Niemitalo]

Source: linux
Version: 5.10.149-2
Severity: trivial

debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
modifies security/lockdown/Kconfig to add the
LOCK_DOWN_IN_EFI_SECURE_BOOT option, whose help claims:

> Enabling this option results in kernel lockdown being
> triggered in confidentiality mode if EFI Secure Boot is
> set.

However, the lockdown is actually in integrity mode, rather than
confidentiality mode:

> #ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
>lock_kernel_down("EFI Secure Boot",
> LOCKDOWN_INTEGRITY_MAX);
> #endif

The implementation was apparently changed for
https://bugs.debian.org/956197 but the documentation
was not updated at that time.

https://salsa.debian.org/kernel-team/linux/-/commit/c2ea339ee4296658084804c0e678f03832ab2d79

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

Kernel: Linux 5.10.0-19-amd64 (SMP w/8 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#840610: UnicodeEncodeError: 'ascii' codec can't encode character

[Kalle Olavi Niemitalo]

Kalle Olavi Niemitalo <k...@iki.fi> writes:

> Content-Type: text/plain; charset=iso-8859-15
> Content-Disposition: attachment; filename=de.po
> Content-Transfer-Encoding: quoted-printable

Oops, that file was UTF-8 originally, but my MUA recoded it to
iso-8859-15, which is inconsistent with the Content-Type header
inside the file.  Here is the file again, now in its original
UTF-8 encoding.
msgid ""
msgstr ""
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

msgid "test"
msgstr "Prüfung"

Bug#840610: UnicodeEncodeError: 'ascii' codec can't encode character

[Kalle Olavi Niemitalo]

Matthias Klose  writes:

> It would be good to have a self-contained example to show the
> exact issue.

Enable the "de_AT.UTF-8" locale in "dpkg-reconfigure locales",
copy the attached files to a directory, and run "make check"
there.  The C version outputs "test" with glibc 2.19, but the
Python version fails with Python 3.4.2:

gcc -Wall -Wextra -o 840610 840610.c
mkdir -p de/LC_MESSAGES
msgfmt -o de/LC_MESSAGES/840610.mo de.po
LANGUAGE=de_AT.UTF-8 LC_ALL=C ./840610
test
LANGUAGE=de_AT.UTF-8 LC_ALL=C python3 ./840610.py
Traceback (most recent call last):
  File "./840610.py", line 8, in 
print(gettext.dgettext('840610', 'test'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 2: 
ordinal not in range(128)
Makefile:21: recipe for target 'check' failed
make: *** [check] Error 1

You can also play with commands like

strace -E LANGUAGE=de_AT.UTF-8 -E LC_ALL=C -e file ./840610
strace -E LANGUAGE=de_AT.UTF-8 -E LC_ALL=C.UTF-8 -e file ./840610

which show that, if LC_ALL=C exactly, then glibc doesn't even
attempt to open any 840610.mo file.  This is the special case
that was added in glibc 2.2.1 and has not been implemented
in the Python gettext library, as of Python 3.4.2.

#define _GNU_SOURCE 1
#include 
#include 
#include 
#include 
#include 

int
main(void)
{
if (setlocale(LC_ALL, "") == NULL)
error(1, errno, "setlocale");
if (bindtextdomain("840610", ".") == NULL)
error(1, errno, "bindtextdomain");
if (puts(dgettext("840610", "test")) == EOF)
error(1, errno, "puts");
return 0;
}
#! /usr/bin/python3

import locale
import gettext

locale.setlocale(locale.LC_ALL, '')
gettext.bindtextdomain('840610', '.')
print(gettext.dgettext('840610', 'test'))
msgid ""
msgstr ""
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

msgid "test"
msgstr "Prüfung"
#! /usr/bin/make -f

PYTHON = python3
CC = gcc
CFLAGS = -Wall -Wextra

all: 840610 de/LC_MESSAGES/840610.mo

clean:
rm -f 840610
rm -rf de

840610: 840610.c
$(CC) $(CFLAGS) -o 840610 840610.c

de/LC_MESSAGES/840610.mo: de.po
mkdir -p de/LC_MESSAGES
msgfmt -o de/LC_MESSAGES/840610.mo de.po

check: all
LANGUAGE=de_AT.UTF-8 LC_ALL=C ./840610
LANGUAGE=de_AT.UTF-8 LC_ALL=C $(PYTHON) ./840610.py

Bug#842746: openmpi: FTBFS on hurd-i386, please disable Java

[Kalle Olavi Niemitalo]

Kalle Olavi Niemitalo <k...@iki.fi> writes:

> Please disable the Java bindings of openmpi on hurd-i386, like
> they are already disabled on hppa.

I verified that disabling Java bindings with the following patch
lets openmpi 2.0.1-7 build on hurd-i386.  However, I'm afraid
this patch would also affect builds on plain i386, because the
findstring function of GNU Make does not treat spaces or
quotation marks as anything special.

--- debian/rules~   2016-10-21 21:01:25.0 +0300
+++ debian/rules2016-11-01 00:14:57.0 +0200
@@ -13,7 +13,7 @@
 # No ibverbs support available on kFreeBSD, Hurd
 NO_VERBS_ARCH:= "hurd-i386 kfreebsd-amd64 kfreebsd-i386 s390x"
 FABRIC_ARCH:=  " amd64 i386 "
-NO_JAVA_ARCH:= "hppa"
+NO_JAVA_ARCH:= "hppa hurd-i386"
 NO_TEST_ARCH:= "hppa hurd-i386"
 
 BTL_TESTS:= --enable-opal-btl-usnic-unit-tests

I think the proper fix would be to remove the quotation marks and
replace the findstring function with the filter function, which
specifically deals with whitespace-separated words.  Like this:

NO_JAVA_ARCH := hppa hurd-i386

# The following assumes the value of $(DEB_HOST_ARCH) is only one
# whitespace-separated word.  If it matches any of the patterns
# in $(NO_JAVA_ARCH), then the filter function returns it
# unchanged, and it does not equal the empty string, so ifeq
# skips the JAVA assignment.
ifeq ($(filter $(NO_JAVA_ARCH),$(DEB_HOST_ARCH)),)
JAVA := --with-jdk-dir=/usr/lib/jvm/default-java --enable-mpi-java
endif

Likewise with the other lists of archs.  I tested this condition
by explicitly assigning values to DEB_HOST_ARCH and it seemed to
work OK.  I did not test it as part of debian/rules though,
because I don't have "sid" build environments for anything other
than hurd-i386.

Bug#842746: openmpi: FTBFS on hurd-i386, please disable Java

[Kalle Olavi Niemitalo]

Source: openmpi
Version: 2.0.1-7
Severity: normal
User: debian-h...@lists.debian.org
Usertags: hurd

Samuel Thibault  writes:

> openmpi 2.0.1-7 currently FTBFS, which makes a lot of package
> unbuildable because openmpi is the default mpi implementation. Version
> 2.0.1-4 did build, so there's probably not so much to fix, could
> somebody have a look?

When openmpi 2.0.1-4 was successfully built for hurd-i386, the
Java bindings were accidentally disabled because the
"NO_JAVA_ARCH" check was reversed as described in Bug#837446.
Now that the check has been corrected, openmpi again fails to
build on hurd-i386.  The main problem is that hurd-i386 uses Java
libraries from gcj-6-jre-lib, which does not support the methods
added in Java 1.6.  In particular, the java.nio.Buffer class
lacks the array() and isDirect() methods.  The errors in the
build log
https://buildd.debian.org/status/fetch.php?pkg=openmpi=hurd-i386=2.0.1-7=1477146240
look very similar to the ones hppa got in Bug#837446.

Please disable the Java bindings of openmpi on hurd-i386, like
they are already disabled on hppa.

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

Kernel: GNU-Mach 1.7+git20160809-486-dbg/Hurd-0.8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#840610: UnicodeEncodeError: 'ascii' codec can't encode character

[Kalle Olavi Niemitalo]

Robert Luberda  writes:

> According to GNU gettext documentation[1]: "The variable LANGUAGE is
> ignored if the locale is set to ‘C’."

That exception was added on 2001-01-03, for glibc 2.2.1.
In glibc 2.2, LANGUAGE used to override LC_ALL=C.

In Python 2.0 (released on 2000-10-16), 2.7, and 3.5.0, gettext.py
checks LANGUAGE first, like glibc 2.2.  The loop that checks the
environment variables is exactly the same in these three versions.

I searched for "gettext" at bugs.python.org but it didn't find a
bug report for the priority of LANGUAGE vs. LC_ALL=C in gettext.
http://bugs.python.org/issue1166948 says 'LANGUAGE is honoured
even if the default locale is "C"' but I think that refers to
locale.getdefaultencoding, not to gettext.

Bug#838244: hurd: license incompatibility between ext2fs (GPLv2-only) and libparted (GPLv3-or-later)

[Kalle Olavi Niemitalo]

Samuel Thibault  writes:

> But storeio can be used as an intermediate between the two.

"storeio --store-type=part 1:device:hd0" apparently supports
file_get_storage_info and reports the partition boundaries there,
so the I/O would not have to go through the storeio translator.

libstore/encode.c (too_big) has a comment saying "The RPC
protocol uses 32-bit off_t's" but that is false since 2002.

Bug#838244: hurd: license incompatibility between ext2fs (GPLv2-only) and libparted (GPLv3-or-later)

[Kalle Olavi Niemitalo]

Package: hurd
Version: 1:0.8.git20160826-1
Severity: serious
File: /hurd/ext2fs.static

The ext2fs translator contains GPLv2-only code copied from Linux,
but it is linked (through libstore) with libparted, which is
GPLv3-or-later since 2007.  This combination violates at least
one of the licenses.  The problem is clearest in ext2fs.static
but FSF doctrine is it applies to dynamic linking as well.

One of the Hurd developers acknowledged in August 2007 that
ext2fs in the Hurd contains GPLv2-only code:
https://lists.gnu.org/archive/html/bug-hurd/2007-08/msg00073.html

The "BSD-licensed liblabel" was suggested as a replacement of
libparted, on the #hurd IRC channel on 2016-09-15.
Until that is implemented, the partition-table support in
libstore could be disabled altogether, because GNU Mach currently
provides a named device for each partition.

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

Kernel: GNU-Mach 1.7+git20160809-486-dbg/Hurd-0.8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.8.git20160826-1
ii  libblkid1 2.28.1-1
ii  libbz2-1.01.0.6-8
ii  libc0.3   2.23-5
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20160625-1+b1
ii  libtinfo5 6.0+20160625-1+b1
ii  libx11-6  2:1.6.3-1+b1
ii  netdde0.0.20150828-3
ii  sysv-rc   2.88dsf-59.8
ii  xkb-data  2.17-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages hurd recommends:
pn  bf-utf-source  

Versions of packages hurd suggests:
pn  hurd-doc  

-- Configuration Files:
/etc/default/hurd-console changed:
ENABLE='false'
DISPLAY='-d vga'
KBD='-d pc_kbd'
if [ -f /etc/default/keyboard ]
then
  . /etc/default/keyboard
fi
[ -z "$XKBLAYOUT" ] || KBD="$KBD --keymap $XKBLAYOUT"
KBD_REPEAT='--repeat=kbd'
MOUSE='-d pc_mouse --protocol=ps/2'
MOUSE_REPEAT='--repeat=mouse'


-- no debconf information

Bug#792622: missing licenses in debian/copyright

[Kalle Olavi Niemitalo]

My inventory of the licenses in gnumach 2:1.7+git20160809-2 is not
yet complete.  I'm seeing two kinds of license violations so far.

University of Utah advertising clause vs. GNU GPL
-

Several files have a license notice like this:

> Copyright (c) 1994 The University of Utah and
> the Computer Systems Laboratory at the University of Utah (CSL).
> All rights reserved.
>
> Permission to use, copy, modify and distribute this software is hereby
> granted provided that (1) source code retains these copyright, permission,
> and disclaimer notices, and (2) redistributions including binaries
> reproduce the notices in supporting documentation, and (3) all advertising
> materials mentioning features or use of this software display the following
> acknowledgement: ``This product includes software developed by the
> Computer Systems Laboratory at the University of Utah.''
>
> THE UNIVERSITY OF UTAH AND CSL ALLOW FREE USE OF THIS SOFTWARE IN ITS "AS
> IS" CONDITION.  THE UNIVERSITY OF UTAH AND CSL DISCLAIM ANY LIABILITY OF
> ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
>
> CSL requests users of this software to return to csl-d...@cs.utah.edu any
> improvements that they make and grant CSL redistribution rights.

This includes an advertising clause, which AFAIK is incompatible
with GPLv1, GPLv2, and GPLv3.  In June 2007, one of the original
Hurd developers was going to ask the University of Utah to
rescind the advertising clause, but the results were never posted
to bug-hurd.

https://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00068.html
https://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00069.html
https://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00075.html
https://www.gnu.org/licenses/license-list.html#OriginalBSD

GPLv3-or-later vs. GPLv2-only
-

The following files are copyrighted by the FSF, licensed under
GPLv3-or-later, and built into the gnumach binary:

i386/grub/acpi.h
i386/grub/compiler.h
i386/grub/cpu/io.h
i386/grub/cpu/time.h
i386/grub/cpu/types.h
i386/grub/err.h
i386/grub/misc.h
i386/grub/mm.h
i386/grub/symbol.h
i386/grub/time.h
i386/grub/types.h
i386/i386at/acpi.c
i386/i386at/acpihalt.c
kern/gsync.c
kern/gsync.h

Many files copied from Linux are licensed under GPLv2-only, and
they too are built into the gnumach binary.  Here is one that
carries its own license notice, so the license is easy to verify:

linux/src/drivers/scsi/BusLogic.c

"nm gnumach" shows both grub_acpi_halt and
BusLogic_HardwareResetHostAdapter, i.e. the binary contains both
GPLv3-or-later and GPLv2-only code, which is an unlicensed
combination according to the FSF.

https://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
https://savannah.gnu.org/bugs/?49024

Mozilla Public License v1.1 not a problem
-

Many files under linux/pcmcia-cs/ have license notices that
refer to MPLv1.1.  However, that does not cause a license
incompatibility, because all of those files are dual licensed
under GPLv2-only, and none of them is actually built.

Bug#838198: 9base: FTBFS on hurd-i386: fatal error:can't create y.tab.h, :1

[Kalle Olavi Niemitalo]

sam/_libc.h has:

OREAD = 0,
OWRITE = 1,
ORDWR = 2,
OCEXEC = 4,

but it looks like nothing #includes that file, so perhaps that
doesn't have to be patched.  Have you tested sam on the Hurd?

If these flags are sent in the Topen and Tcreate requests of the
9P protocol, then changing their values breaks compatibility
between network hosts that run different implementations.
Do the Debian packages support that protocol?

Bug#792622: missing licenses in debian/copyright

[Kalle Olavi Niemitalo]

This message applies to gnumach 2:1.7+git20160809-2.

The following files are not used by "dpkg-buildpackage -uc -b
-nc", i.e. their atimes do not change during this binary-arch
build, and the build succeeds even if they are removed.

./ChangeLog.0
./ChangeLog.00
./DEVELOPMENT
./ddb/db_mp.h
./ddb/tr.h
./debian/watch
./device/dev_master.h
./doc/fdl.texi
./doc/gpl.texi
./doc/stamp-vti
./i386/i386/ast_types.h
./i386/i386/cpu.h
./i386/i386/kttd_machdep.h
./i386/i386/lock.h
./i386/i386/sched_param.h
./i386/include/mach/i386/cthreads.h
./kern/act.h
./kern/refcount.h
./kern/shuttle.h
./linux/dev/README
./linux/dev/drivers/net/Space.c
./linux/dev/drivers/net/auto_irq.c
./linux/dev/drivers/net/net_init.c
./linux/dev/drivers/net/wavelan.p.h
./linux/dev/drivers/scsi/eata_dma.c
./linux/dev/drivers/scsi/g_NCR5380.c
./linux/dev/glue/net.c
./linux/dev/include/asm-i386/smp.h
./linux/dev/include/asm-i386/uaccess.h
./linux/dev/include/linux/etherdevice.h
./linux/dev/include/linux/if.h
./linux/dev/include/linux/modversions.h
./linux/dev/include/linux/netdevice.h
./linux/dev/include/linux/notifier.h
./linux/dev/include/linux/pm.h
./linux/dev/include/linux/skbuff.h
./linux/dev/include/linux/threads.h
./linux/dev/net/core/dev.c
./linux/pcmcia-cs/clients/3c574_cs.c
./linux/pcmcia-cs/clients/3c589_cs.c
./linux/pcmcia-cs/clients/ax8390.h
./linux/pcmcia-cs/clients/axnet_cs.c
./linux/pcmcia-cs/clients/fmvj18x_cs.c
./linux/pcmcia-cs/clients/nmclan_cs.c
./linux/pcmcia-cs/clients/ositech.h
./linux/pcmcia-cs/clients/pcnet_cs.c
./linux/pcmcia-cs/clients/smc91c92_cs.c
./linux/pcmcia-cs/clients/xirc2ps_cs.c
./linux/pcmcia-cs/glue/ds.c
./linux/pcmcia-cs/glue/pcmcia.c
./linux/pcmcia-cs/glue/pcmcia_glue.h
./linux/pcmcia-cs/glue/wireless_glue.h
./linux/pcmcia-cs/include/linux/crc32.h
./linux/pcmcia-cs/include/linux/slab.h
./linux/pcmcia-cs/include/pcmcia/bulkmem.h
./linux/pcmcia-cs/include/pcmcia/bus_ops.h
./linux/pcmcia-cs/include/pcmcia/ciscode.h
./linux/pcmcia-cs/include/pcmcia/cisreg.h
./linux/pcmcia-cs/include/pcmcia/cistpl.h
./linux/pcmcia-cs/include/pcmcia/cs.h
./linux/pcmcia-cs/include/pcmcia/cs_types.h
./linux/pcmcia-cs/include/pcmcia/driver_ops.h
./linux/pcmcia-cs/include/pcmcia/ds.h
./linux/pcmcia-cs/include/pcmcia/mem_op.h
./linux/pcmcia-cs/include/pcmcia/ss.h
./linux/pcmcia-cs/include/pcmcia/version.h
./linux/pcmcia-cs/modules/bulkmem.c
./linux/pcmcia-cs/modules/cirrus.h
./linux/pcmcia-cs/modules/cistpl.c
./linux/pcmcia-cs/modules/cs.c
./linux/pcmcia-cs/modules/cs_internal.h
./linux/pcmcia-cs/modules/ds.c
./linux/pcmcia-cs/modules/ene.h
./linux/pcmcia-cs/modules/i82365.c
./linux/pcmcia-cs/modules/i82365.h
./linux/pcmcia-cs/modules/o2micro.h
./linux/pcmcia-cs/modules/pci_fixup.c
./linux/pcmcia-cs/modules/ricoh.h
./linux/pcmcia-cs/modules/rsrc_mgr.c
./linux/pcmcia-cs/modules/smc34c90.h
./linux/pcmcia-cs/modules/ti113x.h
./linux/pcmcia-cs/modules/topic.h
./linux/pcmcia-cs/modules/vg468.h
./linux/pcmcia-cs/modules/yenta.h
./linux/pcmcia-cs/wireless/hermes.c
./linux/pcmcia-cs/wireless/hermes.h
./linux/pcmcia-cs/wireless/hermes_rid.h
./linux/pcmcia-cs/wireless/ieee802_11.h
./linux/pcmcia-cs/wireless/orinoco.c
./linux/pcmcia-cs/wireless/orinoco.h
./linux/pcmcia-cs/wireless/orinoco_cs.c
./linux/src/COPYING
./linux/src/drivers/net/3c501.c
./linux/src/drivers/net/3c503.c
./linux/src/drivers/net/3c503.h
./linux/src/drivers/net/3c505.c
./linux/src/drivers/net/3c505.h
./linux/src/drivers/net/3c507.c
./linux/src/drivers/net/3c509.c
./linux/src/drivers/net/3c515.c
./linux/src/drivers/net/3c59x.c
./linux/src/drivers/net/8390.c
./linux/src/drivers/net/8390.h
./linux/src/drivers/net/ac3200.c
./linux/src/drivers/net/apricot.c
./linux/src/drivers/net/at1700.c
./linux/src/drivers/net/atp.c
./linux/src/drivers/net/atp.h
./linux/src/drivers/net/de4x5.c
./linux/src/drivers/net/de4x5.h
./linux/src/drivers/net/de600.c
./linux/src/drivers/net/de620.c
./linux/src/drivers/net/de620.h
./linux/src/drivers/net/depca.c
./linux/src/drivers/net/depca.h
./linux/src/drivers/net/e2100.c
./linux/src/drivers/net/eepro.c
./linux/src/drivers/net/eepro100.c
./linux/src/drivers/net/eexpress.c
./linux/src/drivers/net/epic100.c
./linux/src/drivers/net/eth16i.c
./linux/src/drivers/net/eth82586.h
./linux/src/drivers/net/ewrk3.c
./linux/src/drivers/net/ewrk3.h
./linux/src/drivers/net/fmv18x.c
./linux/src/drivers/net/hamachi.c
./linux/src/drivers/net/hp-plus.c
./linux/src/drivers/net/hp.c
./linux/src/drivers/net/hp100.c
./linux/src/drivers/net/hp100.h
./linux/src/drivers/net/i82586.h
./linux/src/drivers/net/intel-gige.c
./linux/src/drivers/net/kern_compat.h
./linux/src/drivers/net/lance.c
./linux/src/drivers/net/myson803.c
./linux/src/drivers/net/natsemi.c
./linux/src/drivers/net/ne.c
./linux/src/drivers/net/ne2k-pci.c
./linux/src/drivers/net/ni52.c
./linux/src/drivers/net/ni52.h
./linux/src/drivers/net/ni65.c
./linux/src/drivers/net/ni65.h
./linux/src/drivers/net/ns820.c
./linux/src/drivers/net/pci-scan.c
./linux/src/drivers/net/pci-scan.h
./linux/src/drivers/net/pcnet32.c

Bug#792622: missing licenses in debian/copyright

[Kalle Olavi Niemitalo]

Samuel Thibault  writes:

> It is really non-technical work, a matter of using the check-copyright
> script to check that the various licences are referenced in
> debian/copyright (there is no hard need to reference files exactly,
> the only minimal need is knowing which licences end up in the gnumach
> binary).

What check-copyright script do you mean?
https://packages.debian.org/search?searchon=contents=check-copyright=filename=unstable=any
shows only these:

* /usr/share/gnulib/check-copyright in gnulib 20140202+stable-2.
  It only checks the licenses of gnulib modules, which gnumach
  does not use.  The latest version is online at
  http://git.savannah.gnu.org/cgit/gnulib.git/plain/check-copyright
  and has no functional differences.

* /usr/share/gocode/src/github.com/syncthing/syncthing/script/check-copyright.go
  in golang-github-syncthing-syncthing-dev 0.14.4+dfsg1-1.
  It ignores licenses and only checks for missing copyright notices.

Bug#836529: hurd: won't boot if /etc/hurd/runsystem is runsystem.gnu, because runsystem.hurd does not exist

[Kalle Olavi Niemitalo]

Package: hurd
Version: 1:0.8.git20160826-1
Severity: normal

The hurd package makes /etc/hurd/runsystem a symlink that is
managed with the alternatives system.  The default is
runsystem.sysv, and runsystem.gnu is also available.

However, if I use 'update-alternatives --config runsystem' to
select runsystem.gnu, then the system fails to boot, because
/etc/hurd/runsystem.gnu runs /hurd/init, which requires
/etc/hurd/runsystem.hurd, which does not exist.

I tried to fix this by installing daemons/runsystem.hurd from the
Debian Hurd source tree to /etc/hurd/runsystem.hurd and making it
executable.  That helped but there were still several problems:

1. runsystem.hurd runs /libexec/rc, which does not exist.
   /etc/hurd/rc should be used instead.

2. runsystem.hurd runs /libexec/runttys, which does not exist.
   /sbin/runttys should be used instead.

3. runsystem.hurd sets PATH=/bin:/sbin, which omits /usr/bin and
   /usr/sbin.  The login shell apparently inherits that that
   setting and uses it for some startup script, causing errors:
   -bash: id: command not found
   -bash: [: : integer expression expected

4. The file systems listed in /etc/fstab were not automatically
   mounted.  I suppose I could work around this by setting them as
   passive translators, but then it would be more difficult to
   ensure that a user won't cause the file-system translator to
   start while root is running fsck on the store.

5. dhclient did not start automatically.  I suppose I could set a
   fixed IP address instead, or edit some startup script.

Please make the hurd package install runsystem.hurd to /etc/hurd/,
and patch it to fix problems 1 to 3.  That way, runsystem.gnu
will at least work well enough to let root log in and either
switch back to runsystem.sysv or fix problems 4 and 5 locally.

Alternatively, runsystem.gnu could be removed from the package
and unregistered from the alternatives system.

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

Kernel: GNU-Mach 1.7+git20160809-486-dbg/Hurd-0.8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.8.git20160826-1
ii  libblkid1 2.28.1-1
ii  libbz2-1.01.0.6-8
ii  libc0.3   2.23-5
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20160625-1+b1
ii  libtinfo5 6.0+20160625-1+b1
ii  libx11-6  2:1.6.3-1+b1
ii  netdde0.0.20150828-3
ii  sysv-rc   2.88dsf-59.8
ii  xkb-data  2.17-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages hurd recommends:
pn  bf-utf-source  

Versions of packages hurd suggests:
pn  hurd-doc  

-- Configuration Files:
/etc/default/hurd-console changed:
ENABLE='false'
DISPLAY='-d vga'
KBD='-d pc_kbd'
if [ -f /etc/default/keyboard ]
then
  . /etc/default/keyboard
fi
[ -z "$XKBLAYOUT" ] || KBD="$KBD --keymap $XKBLAYOUT"
KBD_REPEAT='--repeat=kbd'
MOUSE='-d pc_mouse --protocol=ps/2'
MOUSE_REPEAT='--repeat=mouse'


-- no debconf information

Bug#836428: hurd, initscripts: /tmp cleaning deletes files through a firmlink

[Kalle Olavi Niemitalo]

Richard Braun  writes:

> A true fix would mean we provide the same assumptions the init
> scripts on Unix.

Programs deleting or modifying files in /tmp already have to be
careful not to follow other users' symlinks.  Perhaps you could
reuse that somehow.  __hurd_file_name_lookup_retry in glibc has
some code that returns ENOENT if O_NOFOLLOW is used on an
untrusted translator, but I haven't examined whether that
triggers in the /tmp-cleaning case.  (rpctrace doesn't reveal it.
IIRC, it does trigger if I try to cp -a a directory in which a
file uses the hello translator.)

Bug#836428: hurd, initscripts: /tmp cleaning deletes files through a firmlink

[Kalle Olavi Niemitalo]

Package: hurd
Version: 1:0.8.git20160826-1

Richard Braun  writes:

> This was famously shown with the example of the
> firmlink translator used in /tmp, which would cause the removal of
> any file targeted by the firmlink on /tmp cleanup during system
> startup.

That was already fixed in daemons/rc.sh as Debian bug #39925
(hurd: /libexec/rc waits for /tmp/* translators), likely in
version 19990714 of the Debian hurd package.  The bug has been
reintroduced: although the fixed script is still installed
(now as /etc/hurd/rc), it is no longer run by default.  Instead,
/lib/init/bootclean.sh in the initscripts package cleans /tmp.

I don't see an open bug report about this in the hurd or
initscripts package, and #39925 has been deleted,
so I'm filing a new one now.

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

Kernel: GNU-Mach 1.7+git20160809-486-dbg/Hurd-0.8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.8.git20160826-1
ii  libblkid1 2.28.1-1
ii  libbz2-1.01.0.6-8
ii  libc0.3   2.23-5
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20160625-1+b1
ii  libtinfo5 6.0+20160625-1+b1
ii  libx11-6  2:1.6.3-1+b1
ii  netdde0.0.20150828-3
ii  sysv-rc   2.88dsf-59.8
ii  xkb-data  2.17-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages hurd recommends:
pn  bf-utf-source  

Versions of packages hurd suggests:
pn  hurd-doc  

Versions of other related packages:
ii  initscripts2.88dsf-59.8
ii  sysvinit-core  2.88dsf-59.8
ii  sysvinit-utils 2.88dsf-59.8
ii  coreutils  8.25-2+b1

-- Configuration Files:
/etc/default/hurd-console changed:
ENABLE='false'
DISPLAY='-d vga'
KBD='-d pc_kbd'
if [ -f /etc/default/keyboard ]
then
  . /etc/default/keyboard
fi
[ -z "$XKBLAYOUT" ] || KBD="$KBD --keymap $XKBLAYOUT"
KBD_REPEAT='--repeat=kbd'
MOUSE='-d pc_mouse --protocol=ps/2'
MOUSE_REPEAT='--repeat=mouse'

/etc/hurd/rc changed:
PATH=/bin:/sbin:/usr/bin:/usr/sbin
swapon -a
echo juu > /doh
if [ -r /fastboot ]
then
# ... or don't.
rm -f /fastboot
echo Fast boot ... skipping disk checks
elif [ $1x = autobootx ]
then
echo Automatic boot in progress...
date
fsysopts / --update --readonly
/sbin/fsck -p -A
case $? in
# Successful completion
0)
fsysopts / --update --writable
;;
# Filesystem modified (but ok now)
1)
fsysopts / --update --writable
;;
# Filesystem modified, filesystem should be restarted
# Ideally we would only restart the filesystem
2 | 3)
/sbin/reboot
;;
# Fsck couldn't fix it.
4 | 5 | 8 | 9)
echo "Automatic boot failed... help!"
exit 1
;;
# Signal that really interrupted something
20 | 130 | 131)
echo "Boot interrupted"
exit 1
;;
# Special `let fsck finish' interruption (SIGQUIT)
12)
echo "Boot interrupted (filesystem checks complete)"
exit 1
;;
# Oh dear.
*)
echo "Unknown error during fsck (exit status $?)"
exit 1
;;
esac
fi
echo -n cleaning up left over files...
rm -f /etc/nologin
rm -f /var/lock/LCK.*
if test -d /tmp; then
  # Forcibly remove all translators in the directory.
  # It is then safe to attempt to remove files and descend directories.
  # All parameters must begin with "./".
  function remove_translators() {
local f
for f; do
  settrans -pagfS "$f"
  if [ -L "$f" ] || [ ! -d "$f" ]; then
rm "$f"
  else
remove_translators "$f"/* "$f"/.[!.] "$f"/.??*
rmdir "$f"
  fi
done
  }
  (cd /tmp
   shopt -s nullglob
   for f in * .[!.] .??*; do
 case "$f" in
 'lost+found'|'quotas') ;;
 *) remove_translators "./$f"
 esac
   done)
  unset -f remove_translators  # because it relies on nullglob
fi
if test -d /var/run; then
  (cd /var/run && {
find . ! -type d ! -name utmp ! -name innd.pid \
  -exec rm -f -- {} \;
cp /dev/null utmp
if grep -q ^utmp: /etc/group
then
chmod 664 utmp
chgrp utmp utmp
fi; })
fi
rm -fr /run/*
mkdir -p /run/lock /run/shm
chmod 1777 /run/lock /run/shm
: > /run/utmp
echo done
if ! test -e /proc/cmdline ; then
  settrans -c /proc /hurd/procfs --compatible
fi
ln -s /proc/mounts /var/run/mtab
ln -sf /proc/mounts /etc/mtab
chmod 664 /etc/motd
(
trap ":" INT QUIT TSTP
if [ -d /etc/rc.boot ]
then
for i in /etc/rc.boot/S*
do
[ ! -f $i ] && continue

Bug#835513: [PATCH] rpctrace: Pass prefixed_name to _hurd_exec_file_name.

[Kalle Olavi Niemitalo]

This fixes the following test case:

  mkdir testy
  echo '#! /bin/bash' > testy/prog
  echo 'printf "%s\n" "$0"' >> testy/prog
  chmod +x testy/prog
  PATH=$(pwd)/testy /bin/rpctrace -E PATH=/usr/bin:/bin -o /dev/null prog

Before this patch, the output is:

  /bin/bash: prog: No such file or directory

After this patch, the output is similar to:

  /home/kalle/testy/prog

* utils/rpctrace.c (traced_spawn): Get prefixed_name from
file_name_path_lookup and pass it to _hurd_exec_file_name.
---

Samuel Thibault  writes:

> It seems simple enough that it's not copyrightable, could you send a
> patch?  (english phrasing can always have ambiguity issues...)

Here is the patch I last built.  It fixes both test cases.
However, I wrote the commit message before finding the shorter
test case and filing the bug.  Perhaps one should replace the
lengthy description with just a DEP-3 "Bug-Debian" header.

https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
says a series of minor changes can become significant.
I list my previously applied patches so that you have the correct
information for your decision:

commit 52d0590bca46d1368a6c5588d214e3724ebad358
  diffstat (+7 -4) excluding ChangeLog, which was not from me
  posted to 39...@bugs.debian.org (deleted) on 1999-07-01
"hurd: /libexec/rc waits for /tmp/* translators"
  applied on 1999-07-01

commit 9e84be3cabcdd988f4c4af9f0794d0ba2d6929c1
  diffstat (+1 -1)
  posted to http://bugs.debian.org/47382 on 1999-10-14
"libdiskfs/opts-std-startup.c (parse_startup_opt): TOGGLE never clears the 
variable"
  applied on 1999-10-14

commit 0e0bcad3e157579dbeafec933ac6ccbc00a515a3
  diffstat (+1 -1)
  posted to http://bugs.debian.org/62557 on 2000-04-17
"[patch] #! doubles first character of argument"
  applied on 2000-07-20

commit ca5b01f538c122dc1f0e989f5703c75b8cf8ca3a
  "rpctrace: Print beyond '\0' in MACH_MSG_TYPE_CHAR."
  diffstat (+2 -1)
  posted to bug-hurd on 2016-08-23
  applied on 2016-08-23

 utils/rpctrace.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/utils/rpctrace.c b/utils/rpctrace.c
index 95ff124..10843bc 100644
--- a/utils/rpctrace.c
+++ b/utils/rpctrace.c
@@ -1622,8 +1622,9 @@ traced_spawn (char **argv, char **envp)
   task_t traced_task;
   struct sender_info *ti;
   struct receiver_info *receive_ti;
+  char *prefixed_name;
   file_t file = file_name_path_lookup (argv[0], getenv ("PATH"),
-  O_EXEC, 0, 0);
+  O_EXEC, 0, _name);
 
   if (file == MACH_PORT_NULL)
 error (1, errno, "command not found: %s", argv[0]);
@@ -1664,7 +1665,8 @@ traced_spawn (char **argv, char **envp)
  the actual task, so the RPCs to map in the program itself do not get
  traced.  Could have an option to use TASK_WRAPPER here instead.  */
 #ifdef HAVE__HURD_EXEC_FILE_NAME
-  err = _hurd_exec_file_name (traced_task, file, *argv, argv, envp);
+  err = _hurd_exec_file_name (traced_task, file, prefixed_name ?: *argv,
+ argv, envp);
 #else
   err = _hurd_exec (traced_task, file, argv, envp);
 #endif
@@ -1675,6 +1677,7 @@ traced_spawn (char **argv, char **envp)
  cannot die and hence our TRACED_TASK ref cannot have been released.  */
   mach_port_deallocate (mach_task_self (), task_wrapper);
 
+  free (prefixed_name);
   return pid;
 }
 
-- 
2.6.4

Bug#835513: rpctrace passes incomplete filename to _hurd_exec_file_name if it finds COMMAND in PATH

[Kalle Olavi Niemitalo]

Package: hurd
Version: 1:0.8.git20160809-1
Severity: normal
File: /bin/rpctrace

If the COMMAND argument of rpctrace does not contain slash, then
rpctrace searches for it in PATH.  If the file found is a script
file, then the interpreter of the script needs to know the file
name so that it can open the file.  However, when rpctrace calls
_hurd_exec_file_name, it specifies COMMAND unchanged as the file
name.  The interpreter then typically does not find the file.

For example, /bin/which in debianutils 4.8 has "#! /bin/sh".
If you run:

  cd /
  PATH=/bin
  rpctrace which

then it shows that dash outputs "/bin/sh: 0: Can't open which"
after calling dir_lookup("which" 1 0) in some directory.
rpctrace should specify the correct file name "/bin/which"
instead; then dash would be able to open the file.

Another, more complex test case:

  mkdir testy
  echo '#! /bin/bash' > testy/prog
  echo 'printf "%s\n" "$0"' >> testy/prog
  chmod +x testy/prog
  PATH=$(pwd)/testy /bin/rpctrace -E PATH=/usr/bin:/bin -o /dev/null prog

Actual output:

  /bin/bash: prog: No such file or directory

Expected output similar to:

  /home/kalle/testy/prog

Fixing this is simple: get prefixed_name from the existing
file_name_path_lookup call, and if it isn't NULL, then use it
instead of *argv and free it afterwards.

AFAIK, the _hurd_exec_file_name patches are not yet in the
upstream Hurd, so I'm filing this in Debian only.

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

Kernel: GNU-Mach 1.7+git20160809-486-dbg/Hurd-0.8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.8.git20160809-1
ii  libblkid1 2.28.1-1
ii  libbz2-1.01.0.6-8
ii  libc0.3   2.23-4
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20160625-1+b1
ii  libtinfo5 6.0+20160625-1+b1
ii  libx11-6  2:1.6.3-1+b1
ii  netdde0.0.20150828-3
ii  sysv-rc   2.88dsf-59
ii  xkb-data  2.17-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages hurd recommends:
pn  bf-utf-source  

Versions of packages hurd suggests:
pn  hurd-doc  

-- Configuration Files:
/etc/default/hurd-console changed:
ENABLE='false'
DISPLAY='-d vga'
KBD='-d pc_kbd'
if [ -f /etc/default/keyboard ]
then
  . /etc/default/keyboard
fi
[ -z "$XKBLAYOUT" ] || KBD="$KBD --keymap $XKBLAYOUT"
KBD_REPEAT='--repeat=kbd'
MOUSE='-d pc_mouse --protocol=ps/2'
MOUSE_REPEAT='--repeat=mouse'


-- no debconf information


pgpPTLEIwKDxf.pgp
Description: PGP signature

Bug#651741: Bug#801348: xserver-xorg: X server controls wrong backlight device

[Kalle Olavi Niemitalo]

This Bug #801348 looks pretty similar to Bug #651741, which I
reported originally in 2011.  The hardware is different though.

You can probably make it work by putting this in /etc/X11/xorg.conf:

Section "Device"
Option  "Backlight" "intel_backlight"
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

This requires xserver-xorg-video-intel 2.20.7 or later;
you have 2:2.21.15-2+b2, which is new enough.

Linux apparently has a blacklist for buggy ACPI backlight
interfaces nowadays:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/video.c?id=refs/tags/v3.16#n418
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/acpi_video.c?id=refs/tags/v4.7#n409

I should finally file a bug in the kernel Bugzilla and ask them
to add my Sony Vaio VPCYA1V9E to the blacklist.


pgpSTcZOr6Vj3.pgp
Description: PGP signature

Bug#829591: hurd: pseudoterminal hangs when I press ^O (flush)

[Kalle Olavi Niemitalo]

I have implemented the term changes almost as planned:

> * Copy the discard-output flag from the FLUSHO bit of
>   termios::c_lflag, when TIOCSETA, TIOCSETAW, or TIOCSETAF is
>   used.  This is term/users.c (set_state), I believe.  The GNU C
>   Library already defines FLUSHO in both  and
>   .

It was easier to delete the FLUSH_OUTPUT flag altogether and make
everything use the FLUSHO flag of termstate.c_lflag instead.
That way, the discard-output flag doesn't have to be separately
copied.  This change alone causes the discard-output flag to be
cleared in each new ssh session, and when bash is about to
display its prompt.  It's definitely an improvement.

> * Clear the discard-output flag when TIOCSTART is used.
>   This is term/users.c (S_tioctl_tiocstart), I believe.

Right, S_tioctl_tiocstart should clear FLUSHO, like it clears
USER_OUTPUT_SUSP except in a different variable.
I didn't test this part though.

> * Clear the discard-output flag when the user types almost any
>   other character, like the glibc documentation said.

That was the hardest part.  input_character should clear FLUSHO
on any character, unless:
(1) the character is the DISCARD character and it caused FLUSHO
to be set during the current call; or
(2) the character is the STOP character and it caused
USER_OUTPUT_SUSP to be set during the current call; or
(3) USER_OUTPUT_SUSP was already set on entry, and was not
cleared during the current call because the character is not
the START character and the IXANY mode is not set.
I implemented those at the end of input_character.  The code
detects (1) by checking whether FLUSHO is clear in the lflag
variable, which was copied from termstate.c_lflag at the
beginning of input_character.

Also, if input_character clears FLUSHO during the current call,
then any previously set FLUSHO must not prevent the current
character from being echoed.  I implemented that by making
echo_char clear FLUSHO unconditionally.  (This is similar to what
NetBSD does, except they also have some weird flag for tabs.)
echo_char is called only from within input_character (possibly
via reprint_line or erase_l), so the user must have typed
something if echo_char is called; and it is not called in the
cases (1)(2)(3) listed above.  (Arguably, it should be called in
case (1), but that is no problem if FLUSHO is set after the call
rather than before.)  If echoing is disabled, then echo_char is
not called so FLUSHO may remain set longer than usual, but it
will be cleared at the end of input_character anyway.

A Hurd developer advised me not to post the patches themselves
because I don't intend to assign copyright to the FSF.  The
diffstat (not counting the "prominent notices") is 18 insertions
and 7 deletions, and the FSF considers "around 15 lines of code"
the limit for a "tiny change".


pgpomQPr4d23H.pgp
Description: PGP signature

Bug#830584: Hurd termios.h: TABDLY does not include TAB3, so "stty tab0" does not undo "stty tab3"

[Kalle Olavi Niemitalo]

Package: libc0.3-dev
Version: 2.23-1
Severity: minor
File: /usr/include/i386-gnu/bits/termios.h
User: debian-h...@lists.debian.org
Usertags: hurd

/usr/include/i386-gnu/bits/termios.h defines:

# define TABDLY (3 << 10)   /* TAB delay.  */
# define TAB0   (0 << 10)   /* TAB delay type 0.  */
# define TAB1   (1 << 10)   /* TAB delay type 1.  */
# define TAB2   (2 << 10)   /* TAB delay type 2.  */
# define TAB3   (1 << 2)/* Expand tabs to spaces.  */
# define OXTABS TAB3/* Expand tabs to spaces.  */

The TABDLY mask does not include the TAB3 bit.
Because of this, "stty tab3" sets the bit, but "stty tab0" does
not clear it:

kalle@luuska:~$ stty sane
kalle@luuska:~$ stty -a
speed 38400 baud; rows 36; columns 149;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; status = ; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl 
echoke -flusho -extproc
kalle@luuska:~$ stty -g
2302:3:4b00:5cf:4:ff:ff:7f:17:15:12:ff:3:1c:1a:19:11:13:16:f:1:0:ff:ff
kalle@luuska:~$ stty tab3
kalle@luuska:~$ stty -a
speed 38400 baud; rows 36; columns 149;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; status = ; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl 
echoke -flusho -extproc
kalle@luuska:~$ stty -g
2302:7:4b00:5cf:4:ff:ff:7f:17:15:12:ff:3:1c:1a:19:11:13:16:f:1:0:ff:ff
kalle@luuska:~$ stty tab0
kalle@luuska:~$ stty -a
speed 38400 baud; rows 36; columns 149;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; status = ; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl 
echoke -flusho -extproc
kalle@luuska:~$ stty -g
2302:7:4b00:5cf:4:ff:ff:7f:17:15:12:ff:3:1c:1a:19:11:13:16:f:1:0:ff:ff
kalle@luuska:~$ 

On Debian GNU/Linux, "stty tab0" undoes "stty tab3", and that's
what it should do on Debian GNU/Hurd too.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.7+git20160607-486-dbg/Hurd-0.8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc0.3-dev:hurd-i386 depends on:
ii  gnumach-dev  2:1.7+git20160607-1
ii  hurd-dev [hurd-headers-dev]  1:0.8.git20160522-4.kon.1
ii  libc-dev-bin 2.23-1
ii  libc0.3  2.23-1

libc0.3-dev:hurd-i386 recommends no packages.

Versions of packages libc0.3-dev:hurd-i386 suggests:
pn  glibc-doc 
ii  manpages-dev  4.06-1

Versions of other packages related to the bug report:
ii  coreutils  8.25-2
ii  hurd   1:0.8.git20160522-4.kon.1

My hurd package is the same as 1:0.8.git20160522-4 except I
patched trans/streamio.c and libpipe/pipe.c not to block on
zero-size reads; upstream bugs 48371 and 48372 respectively.
Those patches do not affect termios.

-- no debconf information


pgpHrZW2l9V34.pgp
Description: PGP signature

Bug#829591: hurd: pseudoterminal hangs when I press ^O (flush)

[Kalle Olavi Niemitalo]

Control: retitle -1 term should clear discard-output flag in more situations

Although the FreeBSD manual page for termios(4)
https://www.freebsd.org/cgi/man.cgi?query=termios=0=4=FreeBSD+10.3-RELEASE+and+Ports=default=html
documents the DISCARD key, the kernel doesn't appear to implement it:
https://svnweb.freebsd.org/base/stable/10/sys/kern/tty_ttydisc.c?revision=256281=markup#l897
There, the ttydisc_rint function recognizes VLNEXT but not VDISCARD.

In contrast, NetBSD implements DISCARD:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/tty.c?rev=1.271=text/x-cvsweb-markup_with_tag=MAIN
There, the ttyinput_wlock function recognizes VDISCARD and toggles
the FLUSHO flag.  This flag is also cleared in several more places:
* At the end of ttyinput_wlock, except in these cases:
  - a break, parity error, or a framing error was ignored
  - the DISCARD or STOP character was just received
  - output remains suspended with STOP.
* In the ttioctl function, if the TIOCSTART ioctl is used.
* In the ttioctl function, if the TIOCSETA, TIOCSETAW, or
  TIOCSETAF ioctl is used.  It actually copies the flag from
  the FLUSHO bit of termios::c_lflag.
* In the ttyrub function, if the ECHO flag is set and the EXTPROC
  flag is not set.  This function is called when a previously
  typed character needs to be deleted.
* In the ttyecho function, unless it's being called because the
  user pressed the TAB key.

The term translator should thus be changed:
* Clear the discard-output flag when the user types almost any
  other character, like the glibc documentation said.
* Clear the discard-output flag when TIOCSTART is used.
  This is term/users.c (S_tioctl_tiocstart), I believe.
* Copy the discard-output flag from the FLUSHO bit of
  termios::c_lflag, when TIOCSETA, TIOCSETAW, or TIOCSETAF is
  used.  This is term/users.c (set_state), I believe.  The GNU C
  Library already defines FLUSHO in both  and
  .

With those changes, I think my previous open_hook patch would
no longer be necessary because sshd would call tcsetattr without
FLUSHO and thereby clear the flag.

Bug#829591: hurd: pseudoterminal hangs when I press ^O (flush)

[Kalle Olavi Niemitalo]

I patched term/users.c (open_hook) so it clears the FLUSH_OUTPUT
flag if the tty was not already open.

I built hurd from commit bc170131016969f1d79409337833046ae1f4501b
(2016-06-14 "pfinet: fix memory leak") + the following changes:

* debian/patches/exec_filename_*.patch from the Debian hurd
  1:0.8.git20160522-4 sources, for https://savannah.gnu.org/bugs/?28934
* term/users.c change described above
* trans/streamio.c change for https://savannah.gnu.org/bugs/?48371
* libpipe/pipe.c change for https://savannah.gnu.org/bugs/?48372

I installed /hurd/exec, /hurd/exec.static, /hurd/ext2fs,
/hurd/ext2fs.static, /hurd/fifo, /hurd/new-fifo, /hurd/pflocal,
/hurd/streamio, /hurd/term, /lib/i386-gnu/libpipe.a, and
/lib/i386-gnu/libpipe.so.0.3.  Then rebooted.

To test the change, I connected to the Hurd VM via SSH and got
/dev/ttyp0.  Then ran cat, typed abc, pressed ^O, typed def
(which did not appear), killed the ssh client, and connected
again.  The motd and the shell prompt appeared OK, and the tty
command showed that this was /dev/ttyp0 again.

I also built vim-7.4.1829 and ran its test suite, which passed.

Bug#829591: hurd: pseudoterminal hangs when I press ^O (flush)

[Kalle Olavi Niemitalo]

Control: retitle -1 hurd: should clear discard-output flag when pseudoterminal 
is destroyed

Samuel Thibault noted that pressing ^O a second time makes the
terminal work again.  It turns out this is a documented feature.
https://www.gnu.org/software/libc/manual/html_node/Other-Special.html#index-VDISCARD
says:

> The DISCARD character is recognized only when IEXTEN is set,
> but in both canonical and noncanonical mode. Its effect is to
> toggle the discard-output flag. When this flag is set, all
> program output is discarded. Setting the flag also discards all
> output currently in the output buffer. Typing any other
> character resets the flag.
>
> This character is available on BSD systems and GNU/Linux and
> GNU/Hurd systems.

Contrary to this glibc documentation, typing another character
does not reset the flag on GNU/Hurd.  I don't know whether that
is a bug in Hurd.  IEEE Std 1003.1, 2013 Edition reserves the
VDISCARD name but does not say how it works.
http://www.unix.com/man-page/freebsd/4/termios/ describes the
DISCARD character but does not say that other characters reset
the flag.

Linux 3.16.0 has room for the DISCARD character in struct termios
but does not recognize it when typed, even if IEXTEN is set.
This explains why I was not familiar with the feature.

That leaves one problem: if I first set the discard-output flag
by pressing ^O, and then kill the ssh client so that the
processes using the pseudoterminal get SIGHUP and die, the flag
remains set.  If someone else then logs in via ssh and happens to
get the same tty/pty pair, they get neither /etc/motd nor the
shell prompt.  They can fix the situation by pressing ^O but
surely the discard-output should be cleared automatically.

In the hurd/term code, the flag is termflags & FLUSH_OUTPUT.
The flag is changed only in main.c (main), which initializes the
whole termflags variable, and in munge.c (input_character),
which toggles the flag if it gets the DISCARD character.
There is no ioctl that explicitly reports or changes the state of
the flag.  It is thus not feasible for sshd to clear the flag;
instead, the term translator should do that on its own.

Samuel Thibault suggests that the flag should be cleared in
ptyio.c (pty_po_destroy_hook) or users.c (po_destroy_hook).
I think pseudoterminals should entirely reinitialize termflags
and other terminal-specific state between sessions because that's
what would happen with /dev/pts/ (Debian bug#556550) too.
With other kinds of terminals ("device" or "hurdio"), one can
expect that the same device will remain connected, so it seems
better to preserve the terminal settings.

Bug#829591: hurd: pseudoterminal hangs when I press ^O (flush)

[Kalle Olavi Niemitalo]

Package: hurd
Version: 1:0.8.git20160522-4
Severity: normal

Connect to the hurd machine via ssh.  Type the password when
prompted.  Run "stty -a" via the ssh connection.  It outputs:

speed 38400 baud; rows 36; columns 149;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; status = ; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl 
echoke

Note that flush = ^O.  Next, run "tty".  It outputs:

/dev/ttyp0

Then, start "cat" without arguments and type "abc".  The letters
appear in the ssh client as intended.  Press ^O.  Nothing seems
to happen.  Type "def".  Those letters do not appear in the ssh
client; this is a bug.

On the gnumach console, kill -9 the cat process.  Nothing happens
in the ssh client; no shell prompt appears.

On the gnumach console, kill -9 the shell process.  The ssh
client exits, saying that the connection was closed.

Try to connect to the hurd machine by ssh again.  Type the
password when prompted.  The shell prompt should now appear, but
it doesn't.

On the gnumach console, kill -9 the "/hurd/term /dev/ttyp0
pty-slave /dev/ptyp0" process.  The ssh client exits, saying that
the connection was closed.

Try to connect to the hurd machine by ssh again.  Type the
password when prompted.  The login now succeeds.

These symptoms suggest that the bug is in /hurd/term.

(If you press ^O in the shell, instead of running cat, then the
results depend on the shell: the bug happens with bash but not
with zsh.  I guess zsh disables the flush feature.)

(A similar hang happens if I run tmux on the console and press ^O
there.  This further confirms that the bug is in /hurd/term and
not in ssh.)

-- System Information:
Debian Release: 8.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.4+git20150409-486/Hurd-0.8
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.8.git20160522-4
ii  libblkid1 2.25.2-4.1+hurd.1
ii  libbz2-1.01.0.6-7+b2
ii  libc0.3   2.22-13
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20160319-2
ii  libtinfo5 6.0+20160319-2
ii  libx11-6  2:1.6.2-3
ii  netdde0.0.20150208-1
ii  sysv-rc   2.88dsf-59
ii  xkb-data  2.12-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages hurd recommends:
pn  bf-utf-source  

Versions of packages hurd suggests:
pn  hurd-doc  

Versions of other packages related to the bug report:
ii  bash4.3-12
ii  coreutils   8.23-4
ii  openssh-server  1:6.7p1-6
ii  tmux1.9-6
dpkg-query: no packages found matching zsh

-- Configuration Files:
/etc/default/hurd-console changed:
ENABLE='false'
DISPLAY='-d vga'
KBD='-d pc_kbd'
if [ -f /etc/default/keyboard ]
then
  . /etc/default/keyboard
fi
[ -z "$XKBLAYOUT" ] || KBD="$KBD --keymap $XKBLAYOUT"
KBD_REPEAT='--repeat=kbd'
MOUSE='-d pc_mouse --protocol=ps/2'
MOUSE_REPEAT='--repeat=mouse'


-- no debconf information


pgpHxFPqIbTPk.pgp
Description: PGP signature

Bug#829308: rsyslog: cannot load imklog.so on Hurd (undefined symbol)

[Kalle Olavi Niemitalo]

Package: rsyslog
Version: 8.16.0-1+b4
Severity: normal
User: debian-h...@lists.debian.org
Usertags: hurd

I get this to /var/log/syslog on each boot:

Jul  2 16:19:36 luuska rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" 
x-pid="1207" x-info="http://www.rsyslog.com;] start
Jul  2 16:19:36 luuska rsyslogd-2066: could not load module 
'/usr/lib/rsyslog/imklog.so', dlopen: /usr/lib/rsyslog/imklog.so: undefined 
symbol: klogWillRunPrePrivDrop  [v8.16.0 try http://www.rsyslog.com/e/2066 ]

and although gnumach writes "unexpected RESEND from keyboard" to
the console when I use a key combination to unfocus the
virtualbox window, rsyslog does not forward that message to
/var/log/kern.log.

The error happens because the build system of rsyslog does not
recognize the GNU Hurd and builds imklog.so without compiling
bsd.c, which would define the missing symbols.  To fix that,
one would first have to patch configure.ac so it recognizes
${host}=i586-pc-gnu and sets os_type="bsd".  (config.guess would
output "i686-unknown-gnu0.8" instead but that doesn't matter here
because dh_auto_configure provides the --build= option.)

That change would fix the missing symbols but rsyslog would then
hit a Hurd bug: https://savannah.gnu.org/bugs/?48371 "read(fd,
NULL, 0) from /dev/klog blocks until there is data".  This causes
rsyslog to block on startup.  To work around it, you can #if out
the read call and related code in plugins/imklog/bsd.c
(klogWillRunPostPrivDrop).  Then it'll start quickly and actually
log the kernel messages.

After those fixes, rsyslog would still be slow to exit when the
OS is shut down.  I haven't tried to find the reason for that.

I do not intend to publish any patches for rsyslog but I hope
this description will help someone else fix the bug.

-- System Information:
Debian Release: 8.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.4+git20150409-486/Hurd-0.8
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.22
ii  libc0.3  2.22-13
ii  libestr0 0.1.10-2
ii  libjson-c3   0.12-3
ii  liblogging-stdlog0   1.0.5-2
ii  liblognorm2  1.1.2-1.1+b2
ii  libuuid1 2.28-5
ii  lsb-base 4.1+Debian13+nmu1
ii  zlib1g   1:1.2.8.dfsg-2

Versions of packages rsyslog recommends:
ii  logrotate  3.8.7-1+b1

Versions of packages rsyslog suggests:
pn  rsyslog-doc
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- no debconf information


pgpadaObZw1f8.pgp
Description: PGP signature

Bug#651741: gnome-power-manager: display backlight brightness has no effect on Sony Vaio VPCYA1V9E

[Kalle Olavi Niemitalo]

I upgraded my Sony Vaio VPCYA1V9E from Wheezy to Jessie.
It now has these versions of packages:

xserver-xorg-video-intel2:2.21.15-2+b2  amd64
linux-image-3.16.0-4-amd64  3.16.7-ckt25-1  amd64

As a test, I commented out all of /etc/X11/xorg.conf.
/var/log/Xorg.0.log then showed:

[166061.586] (II) intel(0): Creating default Display subsection in Screen sectio
n
"Default Screen Section" for depth/fbbpp 24/32
[166061.586] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[166061.586] (==) intel(0): RGB weight 888
[166061.586] (==) intel(0): Default visual is TrueColor
[166061.586] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics
[166061.587] (**) intel(0): Relaxed fencing enabled
[166061.587] (**) intel(0): Wait on SwapBuffers? enabled
[166061.587] (**) intel(0): Triple buffering? enabled
[166061.587] (**) intel(0): Framebuffer tiled
[166061.587] (**) intel(0): Pixmaps tiled
[166061.587] (**) intel(0): 3D buffers tiled
[166061.587] (**) intel(0): SwapBuffers wait enabled
[166061.587] (==) intel(0): video overlay key set to 0x101fe
[166061.587] (II) intel(0): Output LVDS1 has no monitor section
[166061.616] (--) intel(0): found backlight control interface 
/sys/class/backlight/acpi_video0
[166061.618] (II) intel(0): Output VGA1 has no monitor section
[166061.619] (II) intel(0): Output HDMI1 has no monitor section
[166061.619] (II) intel(0): Output DP1 has no monitor section

As in Wheezy, the X server thought it was changing the backlight
brightness, but the changes did not take effect.

Unlike in Wheezy, this newer version of xserver-xorg-video-intel
already supports Option "Backlight".  My xorg.conf now contains
only the following settings:

Section "Device"
Option "Backlight"  "intel_backlight"
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

/var/log/Xorg.0.log now shows:

[166953.670] (II) intel(0): Creating default Display subsection in Screen 
section
"Default Screen Section" for depth/fbbpp 24/32
[166953.670] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[166953.670] (==) intel(0): RGB weight 888
[166953.670] (==) intel(0): Default visual is TrueColor
[166953.670] (**) intel(0): Option "Backlight" "intel_backlight"
[166953.670] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics
[166953.709] (**) intel(0): Relaxed fencing enabled
[166953.709] (**) intel(0): Wait on SwapBuffers? enabled
[166953.709] (**) intel(0): Triple buffering? enabled
[166953.709] (**) intel(0): Framebuffer tiled
[166953.709] (**) intel(0): Pixmaps tiled
[166953.709] (**) intel(0): 3D buffers tiled
[166953.709] (**) intel(0): SwapBuffers wait enabled
[166953.709] (==) intel(0): video overlay key set to 0x101fe
[166953.709] (II) intel(0): Output LVDS1 has no monitor section
[166953.709] (**) intel(0): found backlight control interface 
/sys/class/backlight/intel_backlight
[166953.711] (II) intel(0): Output VGA1 has no monitor section
[166953.712] (II) intel(0): Output HDMI1 has no monitor section
[166953.712] (II) intel(0): Output DP1 has no monitor section

and the backlight control is working OK.
Still, it would be better if it worked out of the box, without
requiring me to edit xorg.conf.
On the other hand, Sony Vaio VPCYA1V9E is a bit old now
(I don't know when this was manufactured, but the BIOS is from 2010),
so perhaps there aren't too many new installs nowadays.


pgpQ6IazrVvxs.pgp
Description: PGP signature

Bug#797043: Bug#797079: wheezy-pu: package mozilla-noscript/2.6.8.19-1~deb7u2

[Kalle Olavi Niemitalo]

David Prévot  writes in Bug#797079:

> Uploaded (with the improved changelog and metadata suggested by Kalle),
> thanks.

I installed xul-ext-noscript 2.6.8.19-1~deb7u2 from
wheezy-proposed-updates, and it works OK.

However, I see the patch now has the following line:

Origin: backport, 
http://anonscm.debian.org/cgit/pkg-mozext/noscript.git/diff/components/noscriptService.js?h=upstream/2.6.8.42=upstream/2.6.8.42_rc1

That URL is a bit misleading because the diff is neither from
upstream/2.6.8.42 to upstream/2.6.8.42_rc1 nor vice versa;
it's instead from the parent commit (upstream/2.6.8.41) to
upstream/2.6.8.42_rc1.  When the query string of the URL contains
multiple "h" fields, cgit uses only the last one:

http://git.zx2c4.com/cgit/tree/cgit.c?h=v0.11.2#n300

A shorter URL would thus work just as well:

Origin: backport, 
http://anonscm.debian.org/cgit/pkg-mozext/noscript.git/diff/components/noscriptService.js?h=upstream/2.6.8.42_rc1

Or if you wanted to specify the older version explicitly,
you'd use "id2":

Origin: backport, 
http://anonscm.debian.org/cgit/pkg-mozext/noscript.git/diff/components/noscriptService.js?h=upstream/2.6.8.42_rc1=upstream/2.6.8.41

It's totally not worth making a new upload but I wanted to
mention it in case more backports are needed later.

Bug#797043: Bug#797079: wheezy-pu: package mozilla-noscript/2.6.8.19-1~deb7u2

[Kalle Olavi Niemitalo]

David Prévot taf...@debian.org writes:

 +  [ Kalle Olavi Niemitalo ]
 +  * Temporarily allow scripts with recent iceweasel
 +(Closes: #797043)

Those functions in noscriptService.js are used not only for
setting up the menu (from which the user could temporarily
whitelist sites), but also for deciding which tabs to reload
after the whitelist has been changed.  I would thus prefer
this kind of changelog entry:

  * Fix enumeration of scripts on iceweasel = 35.
Backported from upstream 2.6.8.42rc1.  (Closes: #797043)

I'm not sure how to format the backport in DEP-3 though, because
upstream doesn't seem to have a public version-control system.
Can it be done like this?

Origin: backport, 
http://anonscm.debian.org/cgit/pkg-mozext/noscript.git/diff/components/noscriptService.js?h=upstream/2.6.8.42id=2218a38a22e43834ce09c75fd5c3c5dc75bc7cf6

I searched the *.js files of xul-ext-noscript 2.6.8.19-1~deb7u1
with a regexp and didn't find any other places where a let
statement uses the variable being defined.  The regexp did not
cover statements that define multiple variables, though.

Bug#640865: Images load automatically, even though image loading is disabled

[Kalle Olavi Niemitalo]

Possibly related upstream bugs:

Bug 331257 - data: images show up when 'load images' 
(Tools-Options-content-checkbox) is disabled
Bug 449273 - SVG:display desc (and title?) as text if images are blocked
Bug 1196784 - img tag with srcset attribute bypasses permissions.default.image=2

https://bugzilla.mozilla.org/buglist.cgi?bug_id=331257,449273,1196784

Bug#797043: xul-ext-noscript: dumbed down menu with iceweasel 38.2.0esr-1~deb7u1 cannot temporarily allow scripts

[Kalle Olavi Niemitalo]

Package: xul-ext-noscript
Version: 2.6.8.19-1~deb7u1
Severity: normal

Originally with these packages:

ii  iceweasel 31.8.0esr-1~deb7u1  amd64  Web browser based on Firefox
ii  xul-ext-noscript  2.6.8.19-1~deb7u1   allpermissions manager for Icew

I reset the noscript settings, restarted Iceweasel, opened
http://www.debian.org/, and hovered over the noscript button in
the navigation bar.  A menu with the following options popped up:

  Salli tilapäisesti debian.org
  Salli debian.org
  ---
  Epäluotettava 
  Viimeksi estetyt sivustot 
  ---
  Tilapäisesti salli kaikki tällä sivulla
  Salli kaikki tällä sivulla
  Salli scriptit yleisesti (turvaton)
  ---
  Asetukset (O)...
  Tietoja NoScript 2.6.8.19istä...

I then quit Iceweasel, upgraded it to 38.2.0esr-1~deb7u1, started
it again, opened http://www.debian.org/, and hovered over the
noscript button in the navigation bar.  A menu with the following
options popped up:

  Viimeksi estetyt sivustot 
  ---
  Salli scriptit yleisesti (turvaton)
  ---
  Asetukset (O)...
  Tietoja NoScript 2.6.8.19istä...
  
This menu no longer lets me temporarily add sites to the whitelist.
I suppose I could add the sites permanently via the options dialog box,
but that would be rather inconvenient.

It looks like there is some kind of incompatibility between
iceweasel 38.2.0esr-1~deb7u1, which is being offered as a
security update, and xul-ext-noscript 2.6.8.19-1~deb7u1, which is
still in wheezy.

I then installed xul-ext-noscript 2.6.9.3-1 from jessie.
That had no dependency problems and made the menu work again.

In /usr/share/doc/xul-ext-noscript/changelog.gz, this item looks
relevant, because 31.8.0esr-1~deb7u1  35  38.2.0esr-1~deb7u1:

 v 2.6.8.42rc1
 =
 x Fixed script sources enumeration breakage in Firefox 35
  (Moz Bug 1068508, thanks Octoploid for reporting)

Upstream NoScript does not appear to have a public
version-control repository but someone has collected the released
versions to GitHub.  The differences between 2.6.8.41 and
2.6.8.42rc1 are here:

https://github.com/avian2/noscript/commit/0b09ec993cad215af6a20eeba7d20ffa7df12cec

The relevant part appears to be in xpi/components/noscriptService.js.
I installed xul-ext-noscript 2.6.9.3-1 again, and patched it in
place as follows:

--- /usr/share/xul-ext/noscript/components/noscriptService.js.~2.6.8.19~
2014-03-25 04:45:50.0 +0200
+++ /usr/share/xul-ext/noscript/components/noscriptService.js   2015-08-27 
11:54:02.402450512 +0300
@@ -5280,7 +5280,7 @@
   
   // Collect document / cached plugin URLs
   let win = document.defaultView;
-  let docURI = docURI = document.documentURI;
+  let docURI = document.documentURI;
   let url = this.getSite(docURI);
   
   if (url) {

then restarted Iceweasel -- and now the menu works again.

Can you push this patch to wheezy?

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xul-ext-noscript depends on:
ii  iceweasel  38.2.0esr-1~deb7u1

xul-ext-noscript recommends no packages.

xul-ext-noscript suggests no packages.

-- no debconf information

Bug#766404: iceweasel-l10n-fi: misleading translation Muokkaa valitsimia in customizableWidgets

[Kalle Olavi Niemitalo]

Philipp Kewisch mozi...@kewis.ch writes:

 I do make the official Lightning packages, but if Icedove is using
 something different then I don't create those packages. For any language
 specific issues, I'd suggest filing a bug in the respective language
 component on bugzilla.mozilla.org.

Before I refile the iceweasel-l10n-fi bugs to bugzilla.mozilla.org,
I'd like to check that they haven't already been fixed in the latest
unreleased translations.  Where can I find those?

I looked at:
* http://hg.mozilla.org/releases/l10n/mozilla-aurora/fi/
  last modified on 2014-10-13 (10 days ago)
* http://hg.mozilla.org/l10n-central/fi/
  last modified on 2014-07-28 (87 days ago)
of which the first one is fresher, but it has releases in its
name, suggesting that the changes are first made somewhere else
and then released to this repository.


pgpBi5E5ZnhsO.pgp
Description: PGP signature

Bug#766404: iceweasel-l10n-fi: misleading translation Muokkaa valitsimia in customizableWidgets

[Kalle Olavi Niemitalo]

Package: iceweasel-l10n-fi
Version: 1:31.2.0esr-2~deb7u1
File: 
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Severity: minor
Tags: upstream, l10n

Click the menu button at the right end of the tool bar, and then
click the Muokkaa button at the bottom of the menu to start
customizing it.  By default, the topmost item in the menu is the
Leikkaa Kopioi Liitä (Cut Copy Paste) widget.  Drag the widget
to the Lisää työkaluja ja ominaisuuksia area at left side of
the menu.  A miniature version of the widget appears there, and
it has a caption below it: Muokkaa valitsimia.  This caption is
misleading because you cannot use the widget to edit any
controls; rather, the widget consists of controls with which you
can edit text.

Within langpack...@iceweasel.mozilla.org.xpi, the string is defined in
chrome/fi/locale/browser/customizableui/customizableWidgets.properties.
It seems this has not yet been fixed in the upstream repository:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/fi/file/ed5975cb1b75/browser/chrome/browser/customizableui/customizableWidgets.properties
http://hg.mozilla.org/l10n-central/fi/file/45c33ed9944f/browser/chrome/browser/customizableui/customizableWidgets.properties
but I'm not that familiar with their version-control practices.

Alternative translations:
* Muokkausvalitsimet would be more correct, and pretty close
  to the current translation.  I'm not sure controls is
  customarily translated to valitsimet, though.
* Muokkauksen valitsimet would be consistent with Lähennyksen
  valitsimet in customizableWidgets.properties, but it seems a
  bit clunky and might even be misunderstood as something with
  which you can select edits that you have previously made.
* Muokkaussäätimet would be consistent with Näytä säätimet
  in chrome/fi/locale/browser/browser.dtd.  However, säätimet
  seems very appropriate for trackbars or dials but not so good
  for instant commands like Leikkaa (Copy).
* Muokkauspainikkeet would reflect that the widget consists of
  three buttons.  This is my favorite for now.
* Muokkauskomennot seems old-fashioned.  I don't think user
  interfaces nowadays talk about giving commands to the computer.
* Leikepöytä would reflect that all three buttons in the widget
  relate to the clipboard, but I think that word isn't used much
  nowadays, so users might not recognize it.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages iceweasel-l10n-fi depends on:
ii  iceweasel  31.2.0esr-2~deb7u1

Versions of packages iceweasel-l10n-fi recommends:
ii  xul-ext-mozvoikko  2.0.1-1

iceweasel-l10n-fi suggests no packages.

-- no debconf information


pgpvnspDMgfWR.pgp
Description: PGP signature

Bug#561670: Powermanga : new upstream release (version 0.92)

[Kalle Olavi Niemitalo]

Markus Koschany a...@gambaru.de writes:

 I now assume that those bugs are either fixed in the latest
 version of Powermanga, 0.92, or that more information are
 needed to fix them.

Bug #561670 D-pad won't move the ship straight left doesn't seem
seem fixed in the upstream Powermanga 0.92.  If you search for
SDL_HAT_LEFT in src/display_sdl.c, you'll see that it still sets
both joy_right = 1 and joy_left = 1.  It's a bit difficult for me
to test it in practice though, as I forgot where I've put the gamepad.

What kind of information would you need to fix this?


pgpkHYrRTHfNV.pgp
Description: PGP signature

Bug#561670: Powermanga : new upstream release (version 0.92)

[Kalle Olavi Niemitalo]

# Bcc: control@ so that nobody accidentally sends replies there.
package powermanga
found 561670 0.92-1
quit

Markus Koschany a...@gambaru.de writes:

 In this case more information means that it would be interesting to know
 what would happen if you changed the variables to a different value but
 I understand that it's difficult to test without a gamepad.

Found it!

Testing with input-events from input-utils 1.0-1, I get:
   bustype : BUS_USB
   vendor  : 0x46d
   product : 0xc218
   version : 272
   name: Logitech Logitech RumblePad 2 US
   phys: usb-:00:1d.0-1.5/input0
   uniq: 
   bits ev : EV_SYN EV_KEY EV_ABS EV_MSC EV_FF

The pad has the following input sensors:
* button 1: EV_MSC MSC_SCAN 589825 and EV_KEY BTN_TRIGGER (0x120)
* button 2: EV_MSC MSC_SCAN 589826 and EV_KEY BTN_THUMB (0x121)
* button 3: EV_MSC MSC_SCAN 589827 and EV_KEY BTN_THUMB2 (0x122)
* button 4: EV_MSC MSC_SCAN 589828 and EV_KEY BTN_TOP (0x123)
* button 5: EV_MSC MSC_SCAN 589829 and EV_KEY BTN_TOP2 (0x124)
* button 6: EV_MSC MSC_SCAN 589830 and EV_KEY BTN_PINKIE (0x125)
* button 7: EV_MSC MSC_SCAN 589831 and EV_KEY BTN_BASE (0x126)
* button 8: EV_MSC MSC_SCAN 589832 and EV_KEY BTN_BASE2 (0x127)
* button 9: EV_MSC MSC_SCAN 589833 and EV_KEY BTN_BASE3 (0x128)
* button 10: EV_MSC MSC_SCAN 589834 and EV_KEY BTN_BASE4 (0x129)
* left stick direction: EV_ABS ABS_X and ABS_Y, both ranging from 0 to 255
* left stick button: EV_MSC MSC_SCAN 589835 and EV_KEY BTN_BASE5 (0x12a)
* right stick direction: EV_ABS ABS_Z and ABS_RZ, both ranging from 0 to 255
* right stick button: EV_MSC MSC_SCAN 589836 and EV_KEY BTN_BASE6 (0x12b)
* D-pad direction: EV_ABS ABS_HAT0X and ABS_HAT0Y, both ranging from -1 to +1

There are also two buttons that do not generate input events:
* The MODE toggle button swaps the left stick with the D-pad.
  In that mode, the left stick generates ABS_HAT0X and ABS_HAT0Y,
  and the D-pad generates ABS_X and ABS_Y with values in the set
  {1, 128, 254}.)
* The VIBRATION button turns the vibrator on for a moment.
  I suppose the button may also enable or disable programmatic
  control of the vibrator, but I haven't tested that.

The bug with powermanga 0.90-dfsg-2 applies specifically to the
ABS_HAT0X and ABS_HAT0Y axes, which the D-pad controls by default;
thus the title of the bug.  The ABS_X and ABS_Y axes also control
the ship but the bug does not affect them.  So if you're testing
with a controller that does not have the hat axes, then I guess
you won't see the bug.

The Debian powermanga 0.92-1 amd64 binary requires libc6 2.14,
which I don't have on Wheezy, so I built a local package from the
0.92-1 sources.  I tested that the resulting binary has the bug.


pgpmG0z6hUHN3.pgp
Description: PGP signature

Bug#718883: ardentryst: IndexError in Worm Woods

[Kalle Olavi Niemitalo]

Kalle Olavi Niemitalo k...@iki.fi writes:

 Normally, if you try to jump above the top of the level, the
 hero hits a ceiling.  However, at the left side of the NPC who
 asks for Anneludine Shells, there is a hole in the ceiling.  By
 wearing Winged Boots, Pyralis was able to jump through that
 hole and then walk to the right above the ceiling.

The ceiling appears to be an unintended feature.
There is no such ceiling in the Sempridge5 map data.
Instead, if the player character tries to jump above the map,
then abs_y becomes negative in play_level.Character.sense.
and the [abs_y/40] index becomes [-1], which Python interprets
as counting from the end of the array, so the collision check
ends up looking at the bottom of the map.
In this part of Worm Woods, there is a gap in the floor of the
lower level, and that then becomes the hole in the ceiling.

Therefore, fixing this bug should not involve editing the map data.
play_level.Character.sense should instead be changed to return False
if abs_y  0.  It already has a similar check for abs_y = 480.


pgpOINgcLup7D.pgp
Description: PGP signature

Bug#583864: #583864 - gnome-settings-daemon: XF86TouchpadToggle gets out of sync on hibernation

[Kalle Olavi Niemitalo]

althaser altha...@gmail.com writes:

 Could you please still reproduce this issue with newer
 gnome-settings-daemon version like 3.4.2+git20121218.7c1322-3+deb7u3 or
 3.8.5-2 ?

I upgraded the laptop to Wheezy and the bug no longer occurs.

Test A:
1. Disable the touchpad by pressing the touchpad toggle button.
   The button lights up.
2. echo disk  /sys/power/state
3. Wait until Linux saves the pages to disk and turns the screen off.
4. Wait until the fan turns off and the touchpad toggle button
   is no longer lit.
5. Press the power button.  The touchpad toggle button lights up;
   the BIOS apparently remembers the touch pad was disabled.
6. Enter the Linux disk encryption passphrase.
7. Wait until GNOME comes back up.  The touchpad toggle button stays lit.
8. Try to use the touchpad.  It correctly remains disabled.
9. Press the touchpad toggle button.  The light goes out, and
   the onscreen indicator shows the touchpad is enabled.
10. Try to use the touchpad.  It works correctly.

Test B:
1-5. As in test A.
6. At the passphrase prompt, hold the power button for a
   few seconds so the laptop turns off.
7. Press the power button again.  The touchpad toggle button
   does not light up.
8. Enter the Linux disk encryption passphrase.
9. Wait until GNOME comes back up.  The touchpad toggle button stays dim.
10. Try to use the touchpad.  It works correctly.
11. Press the touchpad toggle button.  It lights up, and the
onscreen indicator shows the touchpad is disabled.
12. Try to use the touchpad.  It correctly remains disabled.

I can no longer reach the failure mode where the touchpad remains
disabled no matter how many times I press the button.

How it was fixed: The touchpad toggle button used to generate the
XF86TouchpadToggle keysym, but in Wheezy, it instead generates
XF86TouchpadOff or XF86TouchpadOn.  When gnome-settings-daemon
3.4.2+git20121218.7c1322-3+deb7u3 receives XF86TouchpadOff or
XF86TouchpadOn, it shows the new state on the screen but does not
save the state anywhere.¹²

Support for XF86TouchpadOff or XF86TouchpadOn was first included
in GNOME_SETTINGS_DAEMON_2_91_4.³  The experimental Debian package
of gnome-settings-daemon 2.91.5.1-1 includes that change.
However, I'm not sure it'd be right to mark the bug as having
been fixed in that version, because the fix required changes in
Linux and in the X server too.  All of them are in Wheezy though.

¹ 
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-media-keys-manager.c?h=gnome-3-4id=7c13221aa9081fff70ab258a5e86a78506cf7359#n1820
² 
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/shortcuts-list.h?h=gnome-3-4id=7c13221aa9081fff70ab258a5e86a78506cf7359#n91
³ 
https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-0id=1c8f64d1dc6beb7d27a6dce74fa29e27e8c34583


pgpXm4ZDLuzPR.pgp
Description: PGP signature

Bug#583864: #583864 - gnome-settings-daemon: XF86TouchpadToggle gets out of sync on hibernation

[Kalle Olavi Niemitalo]

Kalle Olavi Niemitalo k...@iki.fi writes:

 Support for XF86TouchpadOff or XF86TouchpadOn was first included
 in GNOME_SETTINGS_DAEMON_2_91_4.  The experimental Debian package
 of gnome-settings-daemon 2.91.5.1-1 includes that change.
 However, I'm not sure it'd be right to mark the bug as having
 been fixed in that version, because the fix required changes in
 Linux and in the X server too.  All of them are in Wheezy though.

On further review, it seems the change was in udev, not in Linux.
/lib/udev/keymaps/acer maps the scancodes of the touchpad toggle
key to distinct keycodes:

| 0xF1 f22 # Fn+F7 Touchpad toggle (off-to-on)
| 0xF2 f23 # Fn+F7 Touchpad toggle (on-to-off)

This was done in upstream udev 165 but the Debian udev 164-2
sources also carry this change as debian/patches/backport9.
Squeeze includes udev 164-3 so the fix is there already.

Although linux/input.h defines KEY_TOUCHPAD_TOGGLE,
KEY_TOUCHPAD_ON, and KEY_TOUCHPAD_OFF, those keycodes are
not used because the X11 protocol does not support so many keys.¹
KEY_F21, KEY_F22, and KEY_F23 are used instead.

In xkb-data 2.5.1-3 of Wheezy, /usr/share/X11/xkb/symbols/inet includes:

| key FK21   {  [ XF86TouchpadToggle]   };
| key FK22   {  [ XF86TouchpadOn]   };
| key FK23   {  [ XF86TouchpadOff   ]   };

These FK22 and FK23 mappings were added before the upstream
xkeyboard-config 2.1.²  The first fixed Debian package was
xkeyboard-config 2.1-1 (experimental).  Squeeze has xkb-data
1.8-2, which instead maps FK22 to XF86TouchpadToggle.

Summary of fixed versions:
* udev 164-2; the fix is already in Squeeze.
* xkb-data 2.1-1
* gnome-settings-daemon 2.91.5.1-1

When I reported this bug in May 2010, Squeeze had not yet been
frozen.  The current versions in Squeeze seem unlikely to handle
the touchpad toggle key properly: udev now maps the on-to-off
transition to F23 but xkb-data 1.8-2 does not map that to
anything, as far as I can tell.  I can't test Squeeze now that
I've upgraded the laptop to Wheezy.  Anyway, Squeeze is already
oldstable so I don't expect it will be fixed.

¹ http://www.x.org/wiki/Development/X12/#resourcelimits
² https://bugs.freedesktop.org/show_bug.cgi?id=31333


pgpTKQr2t2YF3.pgp
Description: PGP signature

Bug#744799: elinks follows HTTP redirects to file:// URLs

[Kalle Olavi Niemitalo]

Jakub Wilk jw...@debian.org writes:

 elinks follows HTTP 302 redirects to file:// URLs. This can cause
 information disclosure or, if protocol.file.allow_special_files is
 enabled, denial of service:

If a local user is running ELinks and getting the output to a
terminal, then ELinks will display the contents of the file to
the user, but the user would have been able to read the file
anyway, so I don't think this is a problem.

If a daemon gets a request from an untrusted user, runs ELinks,
collects its output and sends it back to the user, then this
behavior can cause unwanted disclosure of information.  I suspect
such daemons should use elinks -anonymous, which disables local
file browsing.

If the original URI redirects to a http URL, then -anonymous
doesn't prevent it.  Such a request too might be able to access
resources that the original user cannot:
* Saved HTTP cookies or Kerberos tickets might satisfy access
  controls on the HTTP server.  I think the daemon can ensure
  that the user account doesn't have these, so ELinks needn't
  be changed to explicitly block them when -anonymous is used.
* Access control by client IP address, IPsec, or servers at
  private IP addresses.  I don't think ELinks should be
  responsible of restricting access to such servers.

 $ elinks -eval 'set protocol.file.allow_special_files=1' -dump 
 'http://httpbin.org/redirect-to?url=file:///dev/urandom'

That option is just asking for trouble.
Anyway, the daemon can use setrlimit(2) to make the error occur sooner.

 ERROR at /build/elinks-PqPvvp/elinks-0.12~pre6/src/util/memory.c:34: Out of 
 memory (realloc returned NULL): retry #1/3, I still exercise my patience and 
 retry tirelessly.
 ERROR at /build/elinks-PqPvvp/elinks-0.12~pre6/src/util/memory.c:34: Out of 
 memory (realloc returned NULL): retry #2/3, I still exercise my patience and 
 retry tirelessly.
 ERROR at /build/elinks-PqPvvp/elinks-0.12~pre6/src/util/memory.c:46: Out of 
 memory (realloc returned NULL) after 3 tries, I give up and try to continue. 
 Pray for me, please.
 ELinks: Out of memory

Because -dump was used, recovering from this out-of-memory error
does not make sense.


pgpR1ankYtoSE.pgp
Description: PGP signature

Bug#718883: ardentryst: IndexError in Worm Woods

[Kalle Olavi Niemitalo]

Package: ardentryst
Version: 1.71-4
Severity: normal

I was playing as Pyralis in Worm Woods (Sempridge5).  Normally,
if you try to jump above the top of the level, the hero hits a
ceiling.  However, at the left side of the NPC who asks for
Anneludine Shells, there is a hole in the ceiling.  By wearing
Winged Boots, Pyralis was able to jump through that hole and then
walk to the right above the ceiling.  When Pyralis was already
above the ceiling and jumped some more, the game ended with an
IndexError.  I guess the abs_y variable became negative.

Other observations:
* The error handler tried to create bugreport.txt, but that
  failed because /usr/games/ardentryst changes to the
  /usr/share/games/ardentryst directory and I don't have write
  access there.  It would be better to place bugreport.txt
  in the same directory as log.txt.
* /usr/share/games/ardentryst/Levels/Sempridge5 seems to be in
  Python Pickle format, and it's not obvious to me how it should
  be edited to block the hole in the ceiling.  There is code in
  mapping.py to convert maps from XML to Pickle, but the source
  package does not include any XML sources for maps, and I don't
  know whether the existing maps were even converted that way.

% ardentryst 
Ext.reader.Sax2 not found

---
Ardentryst v.20090726 (1.71-Comet Unstable) 1:11 PM AEST   
   by Jordan Trudgett  
---

Ardentryst Copyright (C) 2007, 2008, 2009 Jordan Trudgett
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; for details, see the COPYING file.

An error has occurred. 
Traceback (most recent call last):
  File /usr/share/games/ardentryst/ardentryst.py, line 4718, in module
main()
  File /usr/share/games/ardentryst/ardentryst.py, line 4419, in main
handle_game(Game, True)
  File /usr/share/games/ardentryst/ardentryst.py, line 3085, in handle_game
PLAYLOCALS)#, DEMO.dem)
  File /usr/share/games/ardentryst/play_level.py, line 2880, in playlevel
PLAYER.movement_jump_tick()
  File /usr/share/games/ardentryst/play_level.py, line 5499, in 
movement_jump_tick
if self.senseabove(): self.inertia[1] = max(0, self.inertia[1])
  File /usr/share/games/ardentryst/play_level.py, line 5593, in senseabove
s1 = self.sense(10, -60)
  File /usr/share/games/ardentryst/play_level.py, line 5692, in sense
looktile = LEVEL.map[abs_x/40][abs_y/40]
IndexError: list index out of range
Traceback (most recent call last):
  File /usr/share/games/ardentryst/ardentryst.py, line 4722, in module
handleException(e)
  File /usr/share/games/ardentryst/ardentryst.py, line 683, in handleException
open(bugreport.txt, w).write(open(os.path.join(SAVEDIRECTORY, 
log.txt), r).read())
IOError: [Errno 13] Permission denied: 'bugreport.txt'

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ardentryst depends on:
ii  fonts-freefont-ttf [ttf-freefont]  20120503-1
ii  python 2.7.3-4
ii  python-pygame  1.9.1release+dfsg-8
ii  ttf-freefont   20120503-1

ardentryst recommends no packages.

ardentryst suggests no packages.

-- no debconf information


pgpgf_swUNrv4.pgp
Description: PGP signature

Bug#717884: ardentryst: entering the inventory menu selects the first entry but does not scroll it to the view

[Kalle Olavi Niemitalo]

Package: ardentryst
Version: 1.71-4
Severity: minor

If the inventory menu has scrolled so that the first few entries
are no longer visible, and you then press Left to return to the
main menu and Right to reenter the inventory menu, the game
selects the first inventory entry but does not scroll it to the
view.  If you have enough entries in the inventory (e.g. 18),
then you can even press Down a couple of times to select other
invisible entries, and the game won't scroll at that time either.
However, if you press Up, then the game notices that the
selected entry is above the topmost visible entry, and scrolls it
to the view.

The game should either scroll the selected entry to the view
immediately when the player enters the inventory menu, or
select an entry that is already visible.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ardentryst depends on:
ii  fonts-freefont-ttf [ttf-freefont]  20120503-1
ii  python 2.7.3-4
ii  python-pygame  1.9.1release+dfsg-8
ii  ttf-freefont   20120503-1

ardentryst recommends no packages.

ardentryst suggests no packages.

-- no debconf information


pgpu40k16HYzw.pgp
Description: PGP signature

Bug#717885: ardentryst: shopkeeper says a Buy-mode phrase in Sell mode

[Kalle Olavi Niemitalo]

Package: ardentryst
Version: 1.71-4
Severity: minor

In a shop, if you first choose Sell and press C to sell an item,
but then press X to cancel the transaction, then the shopkeeper
asks what you want to buy, even though you're still selling
rather than buying.

For example, enter Elchim's Shop in Entarya.  In the
Buy/Sell/Exit menu, choose Sell.  Elchim asks: Do you have
anything valuable?  Select an item such as Anneludine Shell and
press C.  Elchim asks: How many will that be?  Now press X to
cancel.  Elchim asks: What would you like to buy?  That doesn't
make sense, because it is not possible to buy items in this
screen.  In contrast, if you choose to sell zero pieces of an
item, then Elchim asks again: Do you have anything valuable?

The same happens in other shops as well: at least in Ferna's
Stall and in Tyra's Shop.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ardentryst depends on:
ii  fonts-freefont-ttf [ttf-freefont]  20120503-1
ii  python 2.7.3-4
ii  python-pygame  1.9.1release+dfsg-8
ii  ttf-freefont   20120503-1

ardentryst recommends no packages.

ardentryst suggests no packages.

-- no debconf information


pgpN5oo15Yeol.pgp
Description: PGP signature

Bug#699892: [Pan-devel] Seeking advice on Pan license issue with optional TLS component

[Kalle Olavi Niemitalo]

Dominique Dumont d...@debian.org writes:

 Le jeudi 21 février 2013 23:12:28, vous avez écrit :
 It looks like the license of GNUTLS 3.1.x may eventually be
 changed from LGPLv3+ back to LGPLv2.1+.  If that succeeds,
 I believe it would solve the incompatibility with Pan.
 http://lists.gnutls.org/pipermail/gnutls-devel/2013-February/006086.html

 Thanks for the info. I'll forward this upstream.

Gnutls 3.1.10 now has LGPLv2.1+ again.
http://lists.gnutls.org/pipermail/gnutls-devel/2013-March/006202.html


pgpiSEeh2x0Nu.pgp
Description: PGP signature

Bug#699892: [Pan-devel] Seeking advice on Pan license issue with optional TLS component

[Kalle Olavi Niemitalo]

Dominique Dumont domi.dum...@free.fr writes:

 I'll put back SSL support for Pan in Debian unstable once the problematic 
 code 
 is relicensed or re-written.

It looks like the license of GNUTLS 3.1.x may eventually be
changed from LGPLv3+ back to LGPLv2.1+.  If that succeeds,
I believe it would solve the incompatibility with Pan.
http://lists.gnutls.org/pipermail/gnutls-devel/2013-February/006086.html

Alternatively, the SSL support could be rewritten to use the NSS
library from Mozilla; that one remains GPLv2-compatible.  I don't
know yet how different its API is.


pgpigeLXZ15d5.pgp
Description: PGP signature

Bug#651741: gnome-power-manager: display backlight brightness has no effect on Sony Vaio VPCYA1V9E

[Kalle Olavi Niemitalo]

package xserver-xorg-video-intel
tags 651741 - fixed-upstream
found 651741 xserver-xorg-video-intel/2:2.19.0-6
quit

The upstream developers of xf86-video-intel denied my request to
blacklist the faulty VAIO ACPI implementation.  They said Linux
should be patched instead.  I have not yet reported the problem
to the kernel bugzilla.

However, later upstream versions let the system administrator
override the automatic selection of a backlight control device,
by adding Option Backlight to /etc/X11/xorg.conf:

Section Device
Option AccelMethoduxa
Option Backlight  intel_backlight
Identifier  Card0
Driver  intel
BusID   PCI:0:2:0
EndSection

This option was added in xf86-video-intel 2.20.6, and a serious
bug in it was fixed in 2.20.7.  The current version in Debian
experimental is 2:2.20.5-1, which does not support this option.

As a workaround until Linux automatically disables the useless
backlight control device, I propose backporting this option.
For UXA, the backport is pretty easy; please see the attached
patch.  For SNA, it would require more work, and I did not
attempt it.

To test this patch on Sony Vaio VPCYA1V9E, I built and installed
xserver-xorg-video-intel 2:2.19.0-6 + this patch, created an
/etc/X11/xorg.conf containing only the Device section shown
above, and restarted the X server.  /var/log/Xorg.0.log then
showed that /sys/class/backlight/intel_backlight was being used,
and I was able to control the backlight with xrandr and with key
combinations.

Backport the following upstream commits, but omit SNA support because
it has conflicts and resolving them would too easily cause new bugs.
Add a note about this Debian-specific backport in man/intel.man.

Debian bug #651741 http://bugs.debian.org/651741

  commit 414e87255cdee6eb556703ddefd194af71b985ed
  Author: Chris Wilson ch...@chris-wilson.co.uk
  AuthorDate: 2012-08-26 19:47:31 +0100
  Commit: Chris Wilson ch...@chris-wilson.co.uk
  CommitDate: 2012-08-26 19:47:31 +0100

Add Option Backlight to override the probed backlight control interface

The automatic selection may not correspond with the correct backlight
(such as in a multi-gpu, multi-panel device) or the user may simply
prefer another control interface. This allows them to override the
chosen interface using

  Option Backlight my-backlight

to specify '/sys/class/backlight/my-backlight' as the interface to use
instead.

Suggested-by: Alon Levy al...@redhat.com
References: https://bugs.freedesktop.org/show_bug.cgi?id=29273
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

  commit 164ae7a4f9fd3e538f1b506031d297088fc0c659
  Author: Chris Wilson ch...@chris-wilson.co.uk
  AuthorDate: 2012-09-02 17:19:12 +0100
  Commit: Chris Wilson ch...@chris-wilson.co.uk
  CommitDate: 2012-09-02 17:20:19 +0100

man: Malformed Backlight section

Reported-by: Matthew Monaco dgbale...@0x01b.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54397
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

  commit 3dc644b2a959fc559e1138b332ed42d7235de42f
  Author: Сковорода Никита Андреевич chalk...@gmail.com
  AuthorDate: 2012-09-03 13:44:21 +0400
  Commit: Chris Wilson ch...@chris-wilson.co.uk
  CommitDate: 2012-09-03 23:09:08 +0100

uxa: Fix Backlight option support.

Signed-off-by: Сковорода Никита Андреевич chalk...@gmail.com

  commit 886f3cef4101a674bb62656cf7f3046643cae4b1
  Author: Chris Wilson ch...@chris-wilson.co.uk
  AuthorDate: 2012-09-05 15:27:21 +0100
  Commit: Chris Wilson ch...@chris-wilson.co.uk
  CommitDate: 2012-09-05 15:27:21 +0100

uxa: Fix cut'n'paste error in Option Backlight

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

Index: xserver-xorg-video-intel-2.19.0/man/intel.man
===
--- xserver-xorg-video-intel-2.19.0.orig/man/intel.man	2012-10-21 15:30:31.268126472 +0300
+++ xserver-xorg-video-intel-2.19.0/man/intel.man	2012-10-21 15:35:27.360135750 +0300
@@ -138,6 +138,18 @@
 .IP
 Default: Textured video adaptor is preferred.
 .TP
+.BI Option \*qBacklight\*q \*q string \*q
+Override the probed backlight control interface. Sometimes the automatically
+selected backlight interface may not correspond to the correct, or simply
+most useful, interface available on the system. This allows you to override
+that choice by specifying the entry under /sys/class/backlight to use.
+.IP
+Default: Automatic selection.
+.IP
+Debian-specific: This option was backported from upstream release 2.20.7.
+Because SNA support was omitted in this backport, the option has no effect
+if AccelMethod is sna.
+.TP
 .BI Option \*qFallbackDebug\*q \*q boolean \*q
 Enable printing of debugging information on acceleration fallbacks to the
 server log.
Index: xserver-xorg-video-intel-2.19.0/src/intel_display.c

Bug#682937: iceweasel-l10n-fi: access key E conflict in cookieAcceptDialog

[Kalle Olavi Niemitalo]

Package: iceweasel-l10n-fi
Version: 1:10.0.6esr-1
File: /usr/lib/iceweasel/extensions/langpack...@iceweasel.mozilla.org.xpi
Severity: minor
Tags: upstream, l10n

In the Finnish language pack, in the dialog box that asks whether
to accept a cookie, the check box and the Deny (Estä) button
both have E as their access key.  The result is that pressing
Alt+E toggles the focus between the check box and the button.
Pressing E or Shift+E does nothing if the focus is in the check
box, and closes the dialog box (presumably by choosing the Deny
button) if the focus is not in the check box.

Within the XPI file, these access keys are defined in
chrome/fi/locale/fi/cookie/cookieAcceptDialog.dtd and
chrome/fi/locale/fi/cookie/cookieAcceptDialog.properties.
Although only one of them is in upper case, that does not
prevent the conflict.

Please change it so that no two widgets in the dialog box have
the same access key.  I suggest using K for the check box.

It seems this has not yet been fixed in the upstream repository:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/fi/file/73c4feace425/toolkit/chrome/cookie/cookieAcceptDialog.dtd
but I'm not that familiar with their version-control practices.

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages iceweasel-l10n-fi depends on:
ii  iceweasel  10.0.6esr-1

Versions of packages iceweasel-l10n-fi recommends:
ii  xul-ext-mozvoikko  2.0.1-1

iceweasel-l10n-fi suggests no packages.

-- no debconf information


pgpUIs81R7PlM.pgp
Description: PGP signature

Bug#681752: stow --restow -- emacs claims stow: No packages to stow or unstow

[Kalle Olavi Niemitalo]

Package: stow
Version: 2.2.0-1
Severity: normal

I have a script that configures and builds a package and stows
the resulting binaries.  As a precaution against hypothetical
package names that start with a dash, it uses -- like so:

( cd -- ${stowdir}  stow --restow -- ${PKG_STOWNAME} )

This used to work, but now when I try with stow 2.2.0-1, it fails:

| ( cd -- /home/Kalle/prefix/stow  stow --restow -- emacs )
| stow: No packages to stow or unstow
|
| stow (GNU Stow) version 2.2.0
|
| SYNOPSIS:
|
| stow [OPTION ...] [-D|-S|-R] PACKAGE ... [-D|-S|-R] PACKAGE ...
|
| OPTIONS:
|
| -d DIR, --dir=DIR Set stow dir to DIR (default is current dir)
| -t DIR, --target=DIR  Set target to DIR (default is parent of stow dir)
|
| -S, --stowStow the package names that follow this option
| -D, --delete  Unstow the package names that follow this option
| -R, --restow  Restow (like stow -D followed by stow -S)
|
| --ignore=REGEXIgnore files ending in this Perl regex
| --defer=REGEX Don't stow files beginning with this Perl regex
|   if the file is already stowed to another package
| --override=REGEX  Force stowing files beginning with this Perl regex
|   if the file is already stowed to another package
| --adopt   (Use with care!)  Import existing files into stow 
package
|   from target.  Please read docs before using.
| -p, --compat  Use legacy algorithm for unstowing
|
| -n, --no, --simulate  Do not actually make any filesystem changes
| -v, --verbose[=N] Increase verbosity (levels are 0,1,2,3;
| -v or --verbose adds 1; --verbose=N sets level)
| -V, --version Show stow version number
| -h, --helpShow this help
|
| Report bugs to: bug-s...@gnu.org
| Stow home page: http://www.gnu.org/software/stow/
| General help using GNU software: http://www.gnu.org/gethelp/
| make[1]: *** [pkg-stow] Virhe 1

Without --, it works OK.  However, I don't see in the above
command-line synopsis anything that would disallow inserting --
there.  -- is supposed to treat all subsequent arguments as
non-options, and package names are not intended to be options,
so -- should be fine.

I guess the problem is that Stow collects the package names from
the command line by giving a Handler for non-option arguments
to Getopt::Long::GetOptions, which stops reading arguments from
@ARGV when it sees --.  Stow should follow the GetOptions call
with a loop that processes any remaining package names from @ARGV.

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

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages stow depends on:
ii  dpkg  1.16.4.3
ii  install-info  4.13a.dfsg.1-10
ii  perl  5.14.2-12

stow recommends no packages.

Versions of packages stow suggests:
ii  doc-base  0.10.3

-- no debconf information


pgpD5FxjWiLNP.pgp
Description: PGP signature

Bug#681753: Undefined subroutine main::error called at /usr/bin/stow line 568

[Kalle Olavi Niemitalo]

Package: stow
Version: 2.2.0-1
Severity: minor

Kalle@Niukka:~/prefix/stow 1% stow --restow ./emacs
Undefined subroutine main::error called at /usr/bin/stow line 568, DATA line 
18.

It tries to call error(Slashes are not permitted in package names)
but never defines that subroutine.  This is the only call to it.

The severity is minor because the command line would have caused
an error in any case.

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

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages stow depends on:
ii  dpkg  1.16.4.3
ii  install-info  4.13a.dfsg.1-10
ii  perl  5.14.2-12

stow recommends no packages.

Versions of packages stow suggests:
ii  doc-base  0.10.3

-- no debconf information


pgp2GIFSh3tH2.pgp
Description: PGP signature

Bug#681752: stow --restow -- emacs claims stow: No packages to stow or unstow

[Kalle Olavi Niemitalo]

tags 681752 + patch
quit

This is how I think it should be fixed.
Both stow --restow emacs and stow --restow -- emacs work now.

This patch is rather simple, perhaps not copyrightable.
Either way, I am not assigning copyright to the FSF.  According
to /usr/share/doc/stow/copyright, the FSF has no copyright on
GNU Stow anyway.

--- /usr/bin/stow	2012-04-14 08:23:45.0 +0300
+++ /home/Kalle/any-arch/bin/stow	2012-07-16 13:02:01.0 +0300
@@ -473,6 +473,19 @@
 my @pkgs_to_stow   = ();
 my $action = 'stow';
 
+my $remember_package_action = sub {
+if ($action eq 'restow') {
+push @pkgs_to_unstow, $_[0];
+push @pkgs_to_stow, $_[0];
+}
+elsif ($action eq 'unstow') {
+push @pkgs_to_unstow, $_[0];
+}
+else {
+push @pkgs_to_stow, $_[0];
+}
+};
+
 unshift @ARGV, get_config_file_options();
 #$,=\n; print @ARGV,\n; # for debugging rc file
 
@@ -510,21 +523,12 @@
 'R|restow'  = sub { $action = 'restow' },
 
 # Handler for non-option arguments
-'' =
-sub {
-if ($action eq 'restow') {
-push @pkgs_to_unstow, $_[0];
-push @pkgs_to_stow, $_[0];
-}
-elsif ($action eq 'unstow') {
-push @pkgs_to_unstow, $_[0];
-}
-else {
-push @pkgs_to_stow, $_[0];
-}
-},
+'' = $remember_package_action,
 ) or usage();
 
+# If GetOptions stopped at --, process any remaining arguments.
+$remember_package_action-($_) foreach @ARGV;
+
 usage()   if $options{help};
 version() if $options{version};
 


pgpw4yNLw1to5.pgp
Description: PGP signature

Bug#676990: inkscape: Finnish mnemonic conflicts between top-level menus

[Kalle Olavi Niemitalo]

Package: inkscape
Version: 0.48.3.1-1+b1
Severity: normal
Tags: l10n

When I run Inkscape with LANG=fi_FI.utf8, the menu bar has the
following mnemonics for menus (English equivalents in parentheses):

  _Tiedosto (_File)
  _Muokkaa  (_Edit)
  _Näytä(_View)
  _Taso (_Layer)
  _Kohde(_Object)
  _Polku(_Path)
  _Teksti   (_Text)
  _Suotimet (Filter_s)
  Laajennokset  (Exte_nsions)
  _Ohje (_Help)

When I press Alt+T, Inkscape opens one of the three menus
beginning with T: Tiedosto, Taso, or Teksti.  Worse, it changes
each time.  This makes it very inconvenient to use the menus by
keyboard.  Please change the mnemonics of Taso and Teksti so they
don't conflict with Tiedosto or other menus.

There are also conflicts within the Tiedosto menu, but they are
harder to fix and less important than the conflicts between the
top-level menus, so I'm not requesting any change to those now.

Because the mnemonics of the menus are already translated in PO
files, I think this bug has a better chance of getting fixed than
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473246, which
was marked wontfix.


pgprwk2ZAoOm0.pgp
Description: PGP signature

Bug#662300: Patch to fix left-up movement bug

[Kalle Olavi Niemitalo]

Martin Erik Werner martinerikwer...@gmail.com writes:

 Here is a patch which fixes this issue for me, it is based on a
 suggestion at
 http://egoboo.sourceforge.net/phpBB3/viewtopic.php?f=3t=1177p=61333#p61333, 
 see the DEP-3 header for more information.

That patch adds casts to two control_is_pressed subtractions in
set_one_player_latch.  However, the bug also occurs in three
statements in camera_move.  IIRC, this causes sprites to
disappear when you try to rotate the camera.  Instead of adding
casts to each of those calls, I recommend changing
control_is_pressed so it returns int.

In https://egoboo.svn.sourceforge.net/svnroot/egoboo/branches/2.8.x/,
control_is_pressed has been renamed to input_device_control_active,
and game/camera.c and game/game.c no longer do arithmetic with its
return values.


pgpJYAtwvkiJg.pgp
Description: PGP signature

Bug#588912: inkscape: CSS class selector matches a suffix, not only a whole word

[Kalle Olavi Niemitalo]

Package: inkscape
Version: 0.48.3.1-1+b1

To clarify: the large circle near the top left corner of
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=cssbug.svg;att=1;bug=588912
should have a dark grey stroke and a light grey fill,
but Inkscape instead shows a red stroke.


pgpcYgD6Frdeh.pgp
Description: PGP signature

Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals

[Kalle Olavi Niemitalo]

package gcc-4.3
found 517653 gcc-4.4/4.4.7-1
found 517653 gcc-4.6/4.6.3-1
found 517653 gcc-4.7/4.7.0-3
quit

Kalle Olavi Niemitalo k...@iki.fi writes:

 Compiling this with gcc-4.3 -Wall -c

 int
 main (void)
 {
   return hello == there;
 }

 results in a warning:

 hoh.c: In function ‘main’:
 hoh.c:4: warning: comparison with string literal results in unspecified 
 behavior

The same happens with more recent versions:

% gcc-4.4 -Wall -c hoh.c
hoh.c: In function ‘main’:
hoh.c:4: warning: comparison with string literal results in unspecified behavior
% gcc-4.6 -Wall -c hoh.c
hoh.c: In function ‘main’:
hoh.c:4:18: warning: comparison with string literal results in unspecified 
behavior [-Waddress]
% gcc-4.7 -Wall -c hoh.c
hoh.c: In function ‘main’:
hoh.c:4:18: warning: comparison with string literal results in unspecified 
behavior [-Waddress]
% dpkg -l gcc-4.4 gcc-4.6 gcc-4.7
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   VersionDescription
+++-==-==-
ii  gcc-4.44.4.7-1GNU C compiler
ii  gcc-4.64.6.3-1GNU C compiler
ii  gcc-4.74.7.0-3GNU C compiler


pgpCOZanLy8Zd.pgp
Description: PGP signature

Bug#666568: [acer_wmi] rfkill blocks WLAN on Sony VAIO VPCYA1V9E, regardless of hardware switch

[Kalle Olavi Niemitalo]

Jonathan Nieder jrnie...@gmail.com writes:

 Closing optimistically.  As usual, confirmation either way about the
 fix would be welcome.

I installed linux-image-3.2.0-2-amd64 3.2.15-1, commented out
blacklist acer-wmi, and rebooted to that kernel.  The acer-wmi
module was loaded and WLAN still works.


pgpHyw6okRqZM.pgp
Description: PGP signature

Bug#666568: [acer_wmi] rfkill blocks WLAN on Sony VAIO VPCYA1V9E, regardless of hardware switch

[Kalle Olavi Niemitalo]

Jonathan Nieder jrnie...@gmail.com writes:

 Please test the attached patch, following instructions from [1] or the
 following instructions:

Thank you; I didn't realize this had already been fixed upstream.

stable/linux-3.2.y was v3.2.13 = 02905906ddc049720ded93ded03bbc2652f4646a.
That version has the bug; acer-wmi blocks WLAN on my VAIO as reported.
Cherry-picking 5719b81988f3c24ff694dc3a37e35b35630a3966 fixes it.
I deviated from your instructions by not using -s in git cherry-pick.


pgpfEyOXFNeqs.pgp
Description: PGP signature

Bug#163629: fixed in egoboo 1:2.8.1-1

[Kalle Olavi Niemitalo]

package egoboo-data
found 163629 egoboo/1:2.8.1-1
quit

Mark Purcell m...@debian.org writes:

* Upstream fixes:
  - Closes: #163629: egoboo-data: rogue can gain full speed even with ball

Nope, it has not been fixed.
When you pick up the iron ball, it lowers your maximum acceleration:

| Hardware watchpoint 4: $rogue-maxaccel_reset
| 
| Old value = 0.875
| New value = 0.5625
| chr_set_maxaccel (pchr=0x12780d8, new_val=0.5625) at char.c:10091
| (gdb) bt
| #0  chr_set_maxaccel (pchr=0x12780d8, new_val=0.5625) at char.c:10091
| #1  0x0045ab09 in enchant_apply_add (ienc=1, value_idx=5, ieve=76) at 
enchant.c:686
| #2  0x0045b4af in enc_config_do_init (penc=0x141ba48) at enchant.c:869
| #3  0x0045c3b7 in enc_config_init (penc=0x141ba48) at enchant.c:1317
| #4  0x0045c2b0 in enc_run_config (penc=0x141ba48) at enchant.c:1259
| #5  0x0045bfa3 in enc_config_activate (penc=0x141ba48, 
max_iterations=100) at enchant.c:1146
| #6  0x0045cf22 in spawn_one_enchant (owner=125, target=123, 
spawner=125, enc_override=200, modeloptional=256) at enchant.c:1525
| #7  0x004dfb1f in scr_EnchantTarget (pstate=0x7fffe0d0, 
pself=0x127a5a8) at script_functions.c:2752
| #8  0x004c94e3 in scr_run_function (pstate=0x7fffe0d0, 
pself=0x127a5a8) at script.c:571
| #9  0x004c834f in scr_run_function_call (pstate=0x7fffe0d0, 
pself=0x127a5a8) at script.c:316
| #10 0x004c7eb0 in scr_run_chr_script (character=125) at script.c:249
| #11 0x0046d364 in let_all_characters_think () at game.c:3600
| #12 0x004632b2 in update_game () at game.c:818
| #13 0x00463dc3 in do_game_proc_running (gproc=0x1723bc0) at 
game.c:1190
| #14 0x00464276 in do_game_proc_run (gproc=0x1723bc0, 
frameDuration=0.033644914627075195) at game.c:1344
| #15 0x00504736 in do_ego_proc_running (eproc=0x195d2c0) at 
egoboo.c:304
| #16 0x00504a05 in SDL_main (argc=1, argv=0x7fffe398) at 
egoboo.c:435
| #17 0x005239e9 in main (argc=1, argv=0x7fffe398) at 
platform/sys_linux.c:65

When you are stepping into a bear trap, your maximum acceleration
first returns to its original value:

| Hardware watchpoint 4: $rogue-maxaccel_reset
| 
| Old value = 0.5625
| New value = 0.875
| chr_set_maxaccel (pchr=0x12780d8, new_val=0.875) at char.c:10091
| (gdb) bt
| #0  chr_set_maxaccel (pchr=0x12780d8, new_val=0.875) at char.c:10091
| #1  0x0045da7c in enchant_remove_add (ienc=1, value_idx=5) at 
enchant.c:1731
| #2  0x00458efd in remove_enchant (ienc=1, enc_parent=0x0) at 
enchant.c:284
| #3  0x00459d8d in enchant_apply_set (ienc=0, value_idx=2, profile=41) 
at enchant.c:463
| #4  0x0045b481 in enc_config_do_init (penc=0x141b790) at enchant.c:863
| #5  0x0045c3b7 in enc_config_init (penc=0x141b790) at enchant.c:1317
| #6  0x0045c2b0 in enc_run_config (penc=0x141b790) at enchant.c:1259
| #7  0x0045bfa3 in enc_config_activate (penc=0x141b790, 
max_iterations=100) at enchant.c:1146
| #8  0x0045cf22 in spawn_one_enchant (owner=103, target=123, 
spawner=103, enc_override=200, modeloptional=256) at enchant.c:1525
| #9  0x004dfb1f in scr_EnchantTarget (pstate=0x7fffe0d0, 
pself=0x1262ad8) at script_functions.c:2752
| #10 0x004c94e3 in scr_run_function (pstate=0x7fffe0d0, 
pself=0x1262ad8) at script.c:571
| #11 0x004c834f in scr_run_function_call (pstate=0x7fffe0d0, 
pself=0x1262ad8) at script.c:316
| #12 0x004c7eb0 in scr_run_chr_script (character=103) at script.c:249
| #13 0x0046d364 in let_all_characters_think () at game.c:3600
| #14 0x004632b2 in update_game () at game.c:818
| #15 0x00463dc3 in do_game_proc_running (gproc=0x1723bc0) at 
game.c:1190
| #16 0x00464276 in do_game_proc_run (gproc=0x1723bc0, 
frameDuration=0.033865928649902344) at game.c:1344
| #17 0x00504736 in do_ego_proc_running (eproc=0x195d2c0) at 
egoboo.c:304
| #18 0x00504a05 in SDL_main (argc=1, argv=0x7fffe398) at 
egoboo.c:435
| #19 0x005239e9 in main (argc=1, argv=0x7fffe398) at 
platform/sys_linux.c:65

I think the above happens because
basicdat/globalobjects/traps/beartrap.obj/enchant.txt
contains this line:
Remove overridden enchants ( TRUE or FALSE ): TRUE

Immediately afterwards, the bear trap resets your maximum
acceleration to zero:

| Hardware watchpoint 4: $rogue-maxaccel_reset
| 
| Old value = 0.875
| New value = 0
| chr_set_maxaccel (pchr=0x12780d8, new_val=0) at char.c:10091
| (gdb) bt
| #0  chr_set_maxaccel (pchr=0x12780d8, new_val=0) at char.c:10091
| #1  0x0045ab09 in enchant_apply_add (ienc=0, value_idx=5, ieve=41) at 
enchant.c:686
| #2  0x0045b4af in enc_config_do_init (penc=0x141b790) at enchant.c:869
| #3  0x0045c3b7 in enc_config_init (penc=0x141b790) at enchant.c:1317
| #4  0x0045c2b0 in enc_run_config (penc=0x141b790) at enchant.c:1259
| 

Bug#651741: gnome-power-manager: display backlight brightness has no effect on Sony Vaio VPCYA1V9E

[Kalle Olavi Niemitalo]

package gnome-power-manager
reassign 651741 xserver-xorg-video-intel
quit

Kalle Olavi Niemitalo k...@iki.fi writes:

 So, the next thing I'll try will be moving it back to the top.

That works, and I no longer think gnome-power-manager should
be changed, so I'm reassigning the bug.

Please change intel_output_backlight_init() in
xserver-xorg-video-intel to prefer the intel_backlight
device rather than acpi_video0, at least on
Sony Vaio VPCYA1V9E.  This should be done because
/sys/class/backlight/acpi_video0/brightness does not
affect the brightness of the backlight on this machine but
/sys/class/backlight/intel_backlight/brightness does.

On other machines, I think it would be safest to keep using
acpi_video0, so as not to cause new bugs.  I'm not sure what
would be the best way for xserver-xorg-video-intel to detect this
laptop model.  I can think of these ways:

(a) User override via xorg.conf, documented in intel(4).
Would be OK for knowledgeable users, but difficult to
find for others, especially if it is initially not even
clear that the backlight is controlled via the X server.

(b) PCI subsystem.  Here, lspci -vn shows:

00:02.0 0300: 8086:0046 (rev 02) (prog-if 00 [VGA controller])
Subsystem: 104d:907c

intel_driver.h defines the SUBVENDOR_ID and SUBSYS_ID macros,
which intel_output_backlight_init could use on
intel_get_screen_private(output-scrn)-PciInfo.
The problem with this is that the subsystem ID might cover
more laptop models than necessary.

(c) Manufacturer and product name from DMI.
I don't know how to read these in xserver-xorg-video-intel.

(d) Version or checksum of ACPI DSDT, so that the workaround will
be automatically disabled if the firmware is upgraded.
Here, iasl -d shows:

* Original Table Header:
* SignatureDSDT
* Length   0xACA8 (44200)
* Revision 0x02
* Checksum 0x39
* OEM ID   Sony
* OEM Table ID VAIO
* OEM Revision 0x20101102 (537923842)
* Compiler ID  MSFT
* Compiler Version 0x0113 (16777235)

At this time, I like approach (b) best.

Ender Akduman enderakdu...@gmail.com writes:

 By the way do you mean 'backlight' instead of 'backlist' in:
 (...when it was renamed from intel to intel_backlist)

Thank you for the correction.


pgpGXMiQ6kPdp.pgp
Description: PGP signature

Bug#651741: gnome-power-manager: display backlight brightness has no effect on Sony Vaio VPCYA1V9E

[Kalle Olavi Niemitalo]

package xserver-xorg-video-intel
tags 651741 + patch
quit

Kalle Olavi Niemitalo k...@iki.fi writes:

 (b) PCI subsystem.  Here, lspci -vn shows:

 00:02.0 0300: 8086:0046 (rev 02) (prog-if 00 [VGA controller])
 Subsystem: 104d:907c

 intel_driver.h defines the SUBVENDOR_ID and SUBSYS_ID macros,
 which intel_output_backlight_init could use on
 intel_get_screen_private(output-scrn)-PciInfo.

I implemented this in the following patch.  It makes
xserver-xorg-video-intel correctly use intel_backlight on
my Sony VAIO VPCYA1V9E, so that gnome-power-manager can then
control the brightness.  I have not tested on other computers,
especially not on other VAIO models.

Perhaps the upstream maintainer will eventually choose a
different solution; but until then, I think including this patch
in the Debian package would help VAIO users.

Index: xserver-xorg-video-intel-2.17.0/src/intel_display.c
===
--- xserver-xorg-video-intel-2.17.0.orig/src/intel_display.c2012-01-15 
15:38:03.0 +0200
+++ xserver-xorg-video-intel-2.17.0/src/intel_display.c 2012-01-15 
15:56:32.0 +0200
@@ -118,7 +118,8 @@
 #define BACKLIGHT_CLASS /sys/class/backlight
 
 /*
- * List of available kernel interfaces in priority order
+ * List of available kernel interfaces in priority order.
+ * May be overridden by a model-specific workaround.
  */
 static const char *backlight_interfaces[] = {
asus-laptop,
@@ -240,28 +241,55 @@
return max;
 }
 
+static Bool
+intel_output_backlight_probe(xf86OutputPtr output, const char *iface)
+{
+   struct intel_output *intel_output = output-driver_private;
+   char path[BACKLIGHT_PATH_LEN];
+   struct stat buf;
+
+   sprintf(path, %s/%s, BACKLIGHT_CLASS, iface);
+   if (!stat(path, buf)) {
+   intel_output-backlight_iface = iface;
+   intel_output-backlight_max = 
intel_output_backlight_get_max(output);
+   if (intel_output-backlight_max  0) {
+   intel_output-backlight_active_level = 
intel_output_backlight_get(output);
+   xf86DrvMsg(output-scrn-scrnIndex, X_INFO,
+  found backlight control interface %s\n, 
path);
+   return TRUE;
+   }
+   }
+
+   return FALSE;
+}
+
 static void
 intel_output_backlight_init(xf86OutputPtr output)
 {
struct intel_output *intel_output = output-driver_private;
+   intel_screen_private *intel = intel_get_screen_private(output-scrn);
int i;
 
-   for (i = 0; backlight_interfaces[i] != NULL; i++) {
-   char path[BACKLIGHT_PATH_LEN];
-   struct stat buf;
+   /* Debian bug 651741: With Linux 3.1.0 on Sony VAIO VPCYA1V9E,
+* both acpi_video0 and intel_backlight exist and can be
+* adjusted, but only intel_backlight affects the display.
+*/
+   if (VENDOR_ID(intel-PciInfo) == 0x8086 /* Intel */
+DEVICE_ID(intel-PciInfo) == PCI_CHIP_IRONLAKE_M_G
+CHIP_REVISION(intel-PciInfo) == 0x02
+SUBVENDOR_ID(intel-PciInfo) == 0x104d /* Sony */
+SUBSYS_ID(intel-PciInfo) == 0x907c) {
+   xf86DrvMsg(output-scrn-scrnIndex, X_INFO,
+  will prefer intel_backlight on this Sony VAIO 
model\n);
+   if (intel_output_backlight_probe(output, intel_backlight))
+   return;
+   }
 
-   sprintf(path, %s/%s, BACKLIGHT_CLASS, 
backlight_interfaces[i]);
-   if (!stat(path, buf)) {
-   intel_output-backlight_iface = backlight_interfaces[i];
-   intel_output-backlight_max = 
intel_output_backlight_get_max(output);
-   if (intel_output-backlight_max  0) {
-   intel_output-backlight_active_level = 
intel_output_backlight_get(output);
-   xf86DrvMsg(output-scrn-scrnIndex, X_INFO,
-  found backlight control interface 
%s\n, path);
-   return;
-   }
-   }
+   for (i = 0; backlight_interfaces[i] != NULL; i++) {
+   if (intel_output_backlight_probe(output, 
backlight_interfaces[i]))
+   return;
}
+
intel_output-backlight_iface = NULL;
 }
 


pgp0hhmWznWgc.pgp
Description: PGP signature

Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

[Kalle Olavi Niemitalo]

Enrico Tassi gareuselesi...@debian.org writes:

 Please try the attached patch, I'm planning to upload this to unstable
 as soon as possible.

In the liblua5.1-0 package built from your 5.1.4-12 patch, the
shlibs file contains:

liblua5.1-c++ 0 liblua5.1-0
liblua5.1 0 liblua5.1-0

Because liblua5.1-c++.so.0 did not exist in earlier binary
packages, I think you should add (= 5.1.4-12) to that line.

Differences between the dynamic symbols of liblua5.1.so and
liblua5.1-c++.so:

- OK: liblua5.1-c++.so has typeinfo objects for lua_longjmp and
  lua_longjmp*.
- OK: liblua5.1-c++.so has references to libstdc++.so.6 and
  libgcc_s.so.1, and to some symbols of those.
- OK: liblua5.1-c++.so uses fscanf; liblua5.1.so uses __isoc99_fscanf.
  This happens because some GNU extensions conflict with C99 additions
  and are therefore disabled for C by default.
- OK: liblua5.1-c++.so uses isalnum et al; liblua5.1.so uses
  __ctype_b_loc.  This is because ctype.h does not define
  isalnum as a macro when compiled as C++.
- OK: liblua5.1.so has references to _setjmp and _longjmp.
- OK: liblua5.1-c++.so defines lua_ident; liblua5.1.so does not.
  This is because lapi.c defines lua_ident as const char[], which
  implies static in C++.  Applications should not use lua_ident,
  because it is neither declared in any header nor documented the
  Lua 5.1 Reference Manual.

 I've also added one more test to your test file, and now it
 seems to be able to require C modules.

I see you also corrected the exit code.

 Also note the include lua.hpp that adds extern C and
 includes also auxiliary lua headers.

That is somewhat redundant now that you have extern C in
LUA_API.  Originally, I thought the extern C should only be
visible when Lua itself is being compiled; for applications, the
header should behave as in previous versions.  Now though, I
think you made the right choice.  Having extern C in LUA_API
lets application programmers use e.g. lua.h without wrapping it
in extern C { ... } in the application source; and an
application doing that is also portable to Lua installations
built in C++ from unmodified upstream sources.  Such an
application is not portable to Lua installations built in C from
unmodified upstream sources, but that combination would probably
suffer from memory leaks or worse at runtime anyway.

I have not tried liblua5.1-c++.so.0 with Bos Wars yet.  Bos Wars
has a Python-based build system that may take some time for me to
figure out.

Thank you for your effort.


pgpnEMf5Xqe92.pgp
Description: PGP signature

Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

[Kalle Olavi Niemitalo]

I investigated the possibility of just putting the C++ code in
liblua5.1.so: keeping the ABI compatible but adding exception
support.  I think this is feasible for liblua5.1.so but
unfortunately not for liblua5.1.a, because the C++ support needs
several symbols from libsupc++.a and we cannot expect C programs
using liblua5.1.a to link with that.

(This could perhapss be fixed by turning liblua5.1.a into a
linker script like libc.so and libncurses.so are.  It would point
to the real static Lua library and to libsupc++.a from the
version of G++ that was used to compile Lua.  Then, the
liblua5.1-0-dev package would also have to depend on the
corresponding libstdc++6-4.*-dev package.  I think this would
work initially but have rather many steps that can fail later.)

Because supporting exceptions only in liblua5.1.so and not in
liblua5.1.a seems too risky (what happens when someone links with
-static), I guess there should be separate C++ variants of both,
like you already implemented, except with unmangled public symbols.


pgpAMn7suXShG.pgp
Description: PGP signature

Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

[Kalle Olavi Niemitalo]

Enrico Tassi gareuselesi...@debian.org writes:

 I've prepared that patch a while ago (so it may not apply 100% clean).
 I'm attaching it, it is for the lua5.1 package of course. 
 Could you please test it?

Thank you.  The patch conflicted in debian/changelog only.
I had some difficulty getting the Makefile changes applied, due
to unfamiliarity with quilt.  After that, the package compiled
OK, and the resulting shared object does call destructors when
unwinding from an error.  I am attaching my test program.
Compile with:
g++ lua_error.cc $(pkg-config --cflags --libs lua5.1-c++) -o lua_error

Because you made the C++ variant a separate library with mangled
names, it is not compatible with previously compiled modules.
For example, liblua5.1-curl.so.0.0.0 in liblua5.1-curl0 0.3.0-5
wants to call lua_type rather than _Z8lua_typeP9lua_Statei.
This will not be a problem for Bos Wars, which does not use such
modules anyway; but perhaps you should change LUA_CPATH_DEFAULT
in liblua5.1-c++, to support installing C++ variants of modules
as well.

(I wonder why liblua5.1-curl.so.0.0.0 does not declare a
dependency on liblua5.1.so.0 even though it uses functions from
that.)

#include setjmp.h
#include stdlib.h
#include stdio.h
#include lua.h

struct Test
{
	static int refs;
	Test()
	{
		puts(Test::Test());
		++refs;
	}

	Test(const Test )
	{
		puts(Test::Test(const Test ));
		++refs;
	}

	~Test()
	{
		puts(Test::~Test());
		--refs;
	}
};

int Test::refs = 0;

void *
alloc(void *ud, void *ptr, size_t osize, size_t nsize)
{
	if (nsize == 0)
	{
		free(ptr);
		return NULL;
	}
	else
	{
		return realloc(ptr, nsize);
	}
}

int
inner(lua_State *lua)
{
	puts(entered inner);
	Test test;
	puts(before lua_pushstring);
	lua_pushstring(lua, just testing);
	puts(before lua_error);
	lua_error(lua);
	puts(lua_error returned; impossible);
	return 1;
}

int
main()
{
	puts(before lua_newstate);
	lua_State *lua = lua_newstate(alloc, NULL);
	int error = lua_cpcall(lua, inner, NULL);
	switch (error)
	{
	case 0:
		puts(success);
		break;
	case LUA_ERRRUN:
		puts(LUA_ERRRUN);
		break;
	case LUA_ERRMEM:
		puts(LUA_ERRMEM);
		break;
	case LUA_ERRERR:
		puts(LUA_ERRERR);
		break;
	default:
		printf(error %d\n, error);
		break;
	}
	lua_close(lua);

	if (Test::refs == 0)
	{
		printf(Test::refs == %d (OK)\n, Test::refs);
		return EXIT_SUCCESS;
	}
	else
	{
		printf(Test::refs == %d (error)\n, Test::refs);
		return EXIT_SUCCESS;
	}
}


pgpGwj4OZkwQr.pgp
Description: PGP signature

Bug#652443: ioprio_get(2): document who==0

[Kalle Olavi Niemitalo]

Package: manpages-dev
Version: 3.32-0.2
Severity: wishlist
File: /usr/share/man/man2/ioprio_get.2.gz

The ioprio_get(2) manual page describes the meanings of the which
and who parameters:

 IOPRIO_WHO_PROCESS
who is a process ID identifying a single process.

 IOPRIO_WHO_PGRP
who is a process group ID identifying all the members of
a process group.

 IOPRIO_WHO_USER
who is a user ID identifying all of the processes that
have a matching real UID.

The manual page should mention that IOPRIO_WHO_PROCESS and
IOPRIO_WHO_PGRP also allow who==0.  As implemented in
fs/ioprio.c, who==0 means the calling process or its process
group.  The ioprio program in util-linux already uses the
feature.  This is worth documenting separately because
e.g. tcsetpgrp does not treat pgrp==0 in that way.

For IOPRIO_WHO_USER, the situation is more complex: who==0 means
the root user in ioprio_set but the current user (I think the
real UID of the calling process) in ioprio_get.  (That
inconsistency might even be a bug.)

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

Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages manpages-dev depends on:
ii  manpages  3.32-0.2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.6.0.2-3

-- no debconf information


pgpTNjBSvrOxk.pgp
Description: PGP signature

Bug#652445: ionice: treats COMMAND as PID when neither -c nor -n given

[Kalle Olavi Niemitalo]

Package: util-linux
Version: 2.19.1-5
Severity: wishlist
File: /usr/bin/ionice

The ionice(2) manual page describes the two syntaxes:

 ionice [[-c class] [-n classdata] [-t]] -p PID [PID]...
 ionice [-c class] [-n classdata] [-t] COMMAND [ARG]...

However, when I use the latter syntax with neither -c nor -n,
ionice misparses it as the former syntax:

% ionice ls
none: prio 0
ionice: failed to parse pid: 'ls'

i.e. it treats the COMMAND argument ls as a PID.  This behavior
conflicts with what the manual page says about the -p option:

 If this argument is not given, ionice will run the listed
 program with the given parameters.

According to this description, ionice ls should just run the ls
program without changing the I/O priority.  Because this would
not be consistent with nice ls, it might actually be better to
make ionice report a clear error in this case (e.g. ionice:
executing a command requires -c or -n) and change the manual
page accordingly.

Likewise, ionice misparses a PID argument as a COMMAND if
preceded by -p 0:

% ionice -c 0 -p 0 $$
ionice: executing 607 failed: No such file or directory

That might be considered not a bug, because 0 is not valid as a
process ID.  However, the iopriv_get system call does support
who==0, so it should perhaps be allowed here too.

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

Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages util-linux depends on:
ii  debconf [debconf-2.0]  1.5.41  
ii  dpkg   1.16.1.2
ii  initscripts2.88dsf-13.13   
ii  install-info   4.13a.dfsg.1-8  
ii  libblkid1  2.19.1-5
ii  libc6  2.13-21 
ii  libncurses55.9-4   
ii  libselinux12.1.0-4 
ii  libslang2  2.2.4-3 
ii  libuuid1   2.19.1-5
ii  lsb-base   3.2-28  
ii  tzdata 2011n-1 
ii  zlib1g 1:1.2.3.4.dfsg-3

util-linux recommends no packages.

Versions of packages util-linux suggests:
pn  dosfstools  3.0.12-1
pn  kbd 1.15.3-7
pn  util-linux-locales  none  

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:


pgp2fcnfTUlgK.pgp
Description: PGP signature

Bug#560139: liblua5.1-0-dev: C++ version of LUA libraries

[Kalle Olavi Niemitalo]

Enrico Tassi gareuselesi...@debian.org writes:

 On Wed, Dec 09, 2009 at 09:42:18AM +0100, Erich Schubert wrote:
 As far as I know (from discussion with upstream and on #debian-devel) it
 is currently impossible for me to re-use the Debian lua packages for building
 Enigma. The main reason is that C++ exceptions and lua compiled for C use
 will break badly.

 I would be happy to provide a C++ version of the runtime, and would be
 easy. What refrains me is that from the C++ interpreter you will be
 allowed to load C modules (shipped in liblua5.1-* packages) but there
 you will face the same problem I believe. 

I'm looking at this wishlist bug because of Bos Wars, which is
written in C++ and uses Lua and tolua++ (but no Lua modules from
separate packages).  Currently, the exception handling in Bos
Wars is a mess; C++ code very often calls Lua functions, and if
they throw errors (e.g. type mismatch, out of memory), then Bos
Wars typically leaks std::string and other objects.  Although C++
permits that longjmp might call destructors, I have verified that
it does not call them on Debian.  Fixing the leaks with the
current liblua5.1.so seems possible but very cumbersome and
error-prone.  Furthermore, tolua++ would also have to be changed,
because it nowadays generates code that assumes strings will be
destroyed on exceptions.

I don't see why Lua modules compiled as C would have a problem
with liblua5.1 using C++ exceptions.

Although LUAI_THROW and LUAI_TRY are defined in luaconf.h, which
is installed in liblua5.1-0-dev, modules and applications cannot
use these macros.  The macros require struct lua_jmpbuf and
struct lua_State from lstate.h, which is not installed.  Even in
lua5.1 itself, only the luaD_throw function uses LUAI_THROW, and
only the luaD_rawrunprotected function uses LUAI_TRY.  Everything
that needs to throw or handle errors then uses these functions.

Throwing an exception from luaD_throw in liblua5.1.so, correctly
propagating it through a module, and catching it in
luaD_rawrunprotected in liblua5.1.so may require that the module
has been compiled with some kind of exception handling data, so
that the unwinder can find the calling function and check whether
it wanted to catch the exception.  However, it looks like GCC
always generates .cfi_startproc and related pseudo-ops nowadays,
and these then become an .eh_frame section in the binary.  I got
those even when compiling C for x86 with both -fno-exceptions and
-fno-unwind-tables.

Just setting CC=g++ in lua5.1-5.1.4/src/Makefile causes the
function names in the shared library to become mangled, making
the library binary-incompatible with current modules and
applications.  Because applications written in C will not be able
to use the mangled names, the C and C++ variants of the library
would have to be installed side by side, or some extern C would
have to be added.  If there are no other incompatibilities, then
I think extern C would be best, because it does not require
twice the disk space.

When built as C++, LUAI_TRY catches all C++ exceptions, even ones
like std::bad_alloc that were not thrown by LUAI_THROW.  This
makes sense because the Lua stack should be unwound even in that
case.  However, it looks like Lua will then not set an error
message on the Lua stack and will leave some other object there
instead.  This situation is fortunately easy to avoid, by
catching all C++ exceptions in C++ functions called from Lua, and
translating them to lua_error calls.  This requires only one
try...catch per function, so it is much easier than catching all
Lua errors in C++ code that calls Lua.


pgpiQj3LdKdhc.pgp
Description: PGP signature

Bug#623136: abiword: missing newline in the middle of mailcap

[Kalle Olavi Niemitalo]

package abiword
found 623136 abiword/2.9.1-0.2
quit

Here's a patch that I think should fix the bug.
However, I could not test it, because abiword build-depends on
libpsiconv-dev, which is not currently available in wheezy.
Thus not adding the patch tag.
diff -ru abiword_2.9.1-0.2/debian/abiword.mime abiword_2.9.1-0.2-bug623136/debian/abiword.mime
--- abiword_2.9.1-0.2/debian/abiword.mime	2011-11-08 23:53:25.0 +0200
+++ abiword_2.9.1-0.2-bug623136/debian/abiword.mime	2011-12-11 17:19:47.0 +0200
@@ -6,7 +6,8 @@
 application/vnd.plain; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; description=Plain text ; priority=2
 application/vnd.stardivision.writer;  abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; description=StarOffice Writer document ; priority=2
 application/vnd.sun.xml.writer;   abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; description=OpenOffice.org Text document ; priority=2
-application/vnd.ms-word; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; nametemplate=%s.doc ; description=Microsoft Word Document ; priority=2application/wordperfect; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; nametemplate=%s.wpd ; description=Corel WordPerfect Document
+application/vnd.ms-word; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; nametemplate=%s.doc ; description=Microsoft Word Document ; priority=2
+application/wordperfect; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; nametemplate=%s.wpd ; description=Corel WordPerfect Document
 application/vnd.wordperfect; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; nametemplate=%s.wpd ; description=Corel WordPerfect Document
 application/wordperfect5.1; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; description=Corel WordPerfect Document ; priority=2
 application/wordperfect6; abiword '%s' ; edit=abiword '%s' ; test=test $DISPLAY !=  ; description=Corel WordPerfect Document ; priority=2


pgpkk7fMDCaVV.pgp
Description: PGP signature

Bug#651741: gnome-power-manager: display backlight brightness has no effect on Sony Vaio VPCYA1V9E

[Kalle Olavi Niemitalo]

Package: gnome-power-manager
Version: 3.0.2-3
Severity: normal

On a Sony Vaio VPCYA1V9E laptop, if I press Fn+F5 or Fn+F6, then
gnome-power-manager attempts to change the brightness of the
display backlight, and shows a window as if it had worked.
However, the brightness does not change.  Likewise, if I change
the brightness via System Settings - Screen, then the slider
does move, but it has no effect.

Linux 3.1.0 detects two backlight devices:

% ls -l /sys/class/backlight
total 0
lrwxrwxrwx 1 root root 0 Dec 11 20:10 acpi_video0 - 
../../devices/pci:00/:00:02.0/backlight/acpi_video0
lrwxrwxrwx 1 root root 0 Dec 11 20:21 intel_backlight - 
../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
% cat /sys/class/backlight/acpi_video0/max_brightness 
8
% cat /sys/class/backlight/acpi_video0/type
firmware
% cat /sys/class/backlight/intel_backlight/max_brightness 
4882
% cat /sys/class/backlight/intel_backlight/type
raw

Of these, only intel_backlight actually affects the screen of the
laptop; acpi_video0/brightness can be changed (by root) but does
not seem to affect anything.  (I haven't tried with an external
display.)  However, /usr/sbin/gnome-power-backlight-helper always
chooses acpi_video0 and ignores intel_backlight.  It has a
built-in list of backlight devices that it tries to open;
acpi_video0 is on this list but intel_backlight is not.
Because it succeeds in opening acpi_video0, it does not read the
/sys/class/backlight directory to see what other devices exist.

GNOME 3.0 source code for selecting the backlight device:
http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight-helper.c?h=gnome-3-0#n52

In GNOME 3.2, the code has been moved to gnome-settings-daemon,
but still does not recognize intel_backlight:
http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-backlight-helper.c?h=gnome-3-2#n49

It would be best if backlight control worked correctly with the
default settings.  It seems the easiest way to achieve that is to
add intel_backlight to the list in {gpm,gsd}-backlight-helper.c,
somewhere above acpi_video0 so that it takes precedence.

Alternatively, Linux could perhaps be made to entirely omit the
nonfunctional acpi_video0 backlight device and thereby cause
gnome-power-backlight-helper to read the directory and find
intel_backlight.

The acpi_backlight=vendor kernel option seems like a step in the
right direction, as it does make the
/sys/class/backlight/acpi_video0 directory disappear.  However,
it also makes /sys/class/backlight/sony appear instead, and
sony is on the list in gnome-power-backlight-helper, which
therefore still does not read the directory.  Unfortunately,
backlight control via the sony directory does not work either;
both brightness and actual_brightness are constantly -1 there.

If I use acpi_backlight=vendor and unload the sony-laptop module,
then the sony directory disappears too,
gnome-power-backlight-helper opens intel_backlight, and I can
finally change the brightness via the screen settings dialog box!
That solution is still not satisfactory though, because Linux
does not recognize the Fn+F5 and Fn+F6 key combinations without
the sony-laptop module.

The package-specific info below is incomplete because the
bug-reporting script tried to use HAL and I don't have that
installed.  However, dmidecode shows:

# dmidecode 2.11
SMBIOS 2.6 present.
17 structures occupying 853 bytes.
Table at 0x000EA490.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: INSYDE
Version: R0070Z6
Release Date: 11/02/2010
ROM Size: 2048 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 0.70
Firmware Revision: 0.70

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Sony Corporation
Product Name: VPCYA1V9E
Version: C9006WUT
Serial Number: (removed from bug report)
UUID: (removed from bug report)
Wake-up Type: Power Switch
SKU Number: N/A
Family: VAIO

Handle 0x0002, DMI type 2, 16 bytes
Base Board Information
Manufacturer: Sony Corporation
Product Name: VAIO
Version: N/A
Serial Number: C9006WUT
Asset Tag: N/A
Features:
Board is a hosting board
Location In 

Bug#644131: id-utils is GPLv3+ GFDLv1.3+, but debian/copyright claims GPLv2+

[Kalle Olavi Niemitalo]

Package: id-utils
Version: 4.5-3
Severity: normal

/usr/share/doc/id-utils/copyright claims:

 Copyright:
 
   1986-2006 Free Software Foundation, Inc.
 
 License:
 
This package is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

However, the executables actually are under GPL version 3 or later,
and the documentation is under GFDL version 1.3 or later.  The
copyright has also been renewed in 2010.

In /usr/share/emacs/site-lisp/id-utils.el and id-utils-4.5/lisp/idutils.el:

 ;; GNU idutils is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by
 ;; the Free Software Foundation; either version 3, or (at your option)
 ;; any later version.

(That file also contains a misleading comment about PO files.)

In id-utils-4.5/src/mkid.c:

Copyright (C) 1986, 1995-1996, 1999, 2007-2010 Free Software Foundation,
Inc.
...
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

In /usr/share/info/idutils.info.gz and id-utils-4.5/doc/idutils.info:

Copyright (C) 1996, 1999-2000, 2008-2010 Free Software Foundation,
 Inc.
 
  Permission is granted to copy, distribute and/or modify this
  document under the terms of the GNU Free Documentation License,
  Version 1.3 or any later version published by the Free Software
  Foundation; with no Invariant Sections, with the Front-Cover texts
  being A GNU Manual, and with the Back-Cover Texts as in (a)
  below.  A copy of the license is included in the section entitled
  GNU Free Documentation License in the Emacs manual.
 
  (a) The FSF's Back-Cover Text is: You have freedom to copy and
  modify this GNU Manual, like GNU software.  Copies published by
  the Free Software Foundation raise funds for GNU development.
 
  This document is part of a collection distributed under the GNU
  Free Documentation License.  If you want to distribute this
  document separately from the collection, you can do so by adding a
  copy of the license to the document, as described in section 6 of
  the license.

I hoped the license change would have been documented in NEWS and
ChangeLog, but apparently not.  mkid --version doesn't show it either.

Please update the GPL version number and copyright years in
debian/copyright, and add a note about GFDL.

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

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages id-utils depends on:
ii  dpkg  1.16.0.3  
ii  install-info  4.13a.dfsg.1-8
ii  libc6 2.13-21   

id-utils recommends no packages.

id-utils suggests no packages.

-- no debconf information


pgp5tGqXdCnbq.pgp
Description: PGP signature

Bug#638704: libgtk-3-0: segfault on arrow keypress in empty GtkIconView

[Kalle Olavi Niemitalo]

Package: libgtk-3-0
Version: 3.0.11-1
Severity: normal

Start cheese 3.0.1-2.  It is in photo mode by default.  Click on
the empty pane where photos would appear if you took any.  Press
the Right arrow key.  The process dies with SIGSEGV.

This crash does not occur if you do have any photos in the pane.

I then built unoptimized, unstripped versions of cheese, gtk+3.0,
and glib2.0.  Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x7654dffa in gtk_icon_view_set_cell_data (icon_view=0x6b0870, 
item=0x0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkiconview.c:4177
4177iter = item-iter;
(gdb) backtrace
#0  0x7654dffa in gtk_icon_view_set_cell_data (icon_view=0x6b0870, 
item=0x0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkiconview.c:4177
#1  0x7654d23b in gtk_icon_view_move_cursor_left_right (
icon_view=0x6b0870, count=1)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkiconview.c:3856
#2  0x7654c83a in gtk_icon_view_real_move_cursor (icon_view=0x6b0870, 
step=GTK_MOVEMENT_VISUAL_POSITIONS, count=1)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkiconview.c:3535
#3  0x76582365 in _gtk_marshal_BOOLEAN__ENUM_INT (closure=0x6ed210, 
return_value=0x7fffcee0, n_param_values=3, param_values=0x11f3d50, 
invocation_hint=0x7fffcd10, marshal_data=0x7654c6b3)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkmarshalers.c:287
#4  0x75961744 in g_type_class_meta_marshal (closure=0x6ed210, 
return_value=0x7fffcee0, n_param_values=3, param_values=0x11f3d50, 
invocation_hint=0x7fffcd10, marshal_data=0x400)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/glib2.0-2.28.6/./gobject/gclosure.c:878
#5  0x75961432 in g_closure_invoke (closure=0x6ed210, 
return_value=0x7fffcee0, n_param_values=3, param_values=0x11f3d50, 
invocation_hint=0x7fffcd10)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/glib2.0-2.28.6/./gobject/gclosure.c:767
#6  0x7597bb9b in signal_emit_unlocked_R (node=0x6ed330, detail=0, 
instance=0x6b0870, emission_return=0x7fffcee0, 
instance_and_params=0x11f3d50)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/glib2.0-2.28.6/./gobject/gsignal.c:3290
#7  0x7597a01c in g_signal_emitv (instance_and_params=0x11f3d50, 
signal_id=141, detail=0, return_value=0x7fffcee0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/glib2.0-2.28.6/./gobject/gsignal.c:2888
#8  0x764684c5 in gtk_binding_entry_activate (entry=0x6f8b80, 
object=0x6b0870)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkbindings.c:653
#9  0x76469de4 in binding_activate (binding_set=0x6ee020, 
entries=0x11f3970, object=0x6b0870, is_release=0, unbound=0x7fffcfb4)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkbindings.c:1525
#10 0x76469f7e in gtk_bindings_activate_list (object=0x6b0870, 
entries=0x11f3970, is_release=0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkbindings.c:1586
#11 0x7646a1fe in gtk_bindings_activate_event (object=0x6b0870, 
event=0xfb11a0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkbindings.c:1671
#12 0x76723fb1 in gtk_widget_real_key_press_event (widget=0x6b0870, 
event=0xfb11a0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkwidget.c:5767
#13 0x765495db in gtk_icon_view_key_press (widget=0x6b0870, 
event=0xfb11a0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkiconview.c:2154
#14 0x76581df4 in _gtk_marshal_BOOLEAN__BOXED (closure=0x6be9c0, 
return_value=0x7fffd290, n_param_values=2, param_values=0x10c8730, 
invocation_hint=0x7fffd2c0, marshal_data=0x76549548)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/gtk+3.0-3.0.11/./gtk/gtkmarshalers.c:85
#15 0x75961744 in g_type_class_meta_marshal (closure=0x6be9c0, 
return_value=0x7fffd290, n_param_values=2, param_values=0x10c8730, 
invocation_hint=0x7fffd2c0, marshal_data=0x1b0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/glib2.0-2.28.6/./gobject/gclosure.c:878
#16 0x75961432 in g_closure_invoke (closure=0x6be9c0, 
return_value=0x7fffd290, n_param_values=2, param_values=0x10c8730, 
invocation_hint=0x7fffd2c0)
at 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/glib2.0-2.28.6/./gobject/gclosure.c:767
#17 0x7597bb9b in signal_emit_unlocked_R (node=0x66e540, detail=0, 
instance=0x6b0870, emission_return=0x7fffd440, 
instance_and_params=0x10c8730)
at 

Bug#634200: gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.

[Kalle Olavi Niemitalo]

Ray Dillinger b...@sonic.net writes:

 display.c starts with the lines:


 #define _X_OPEN_SOURCE_EXTENDED

There is an extra underscore after the X.
Correcting that fixes the implicit-declaration error for me.

Also, for consistency with other uses of this macro, it would be
best to define it with the value 1, like -D_XOPEN_SOURCE_EXTENDED
does if the value is not specified:

#define _XOPEN_SOURCE_EXTENDED 1

The value does not seem to matter for ncursesw, though.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630647: Finnish translation uses %1$d syntax not supported by grub_printf

[Kalle Olavi Niemitalo]

Package: grub-common
Version: 1.98+20100804-14
Severity: minor
File: /usr/share/locale/fi/LC_MESSAGES/grub.mo
Tags: l10n

-- Steps to reproduce:
0. Have a partition containing an ext2 or ext3 file system that
   has been written to.  (In case it matters, my disk has a GUID
   partition table.)
1. Get to the GRUB command prompt, in grub-pc or grub-emu.
2. Execute set lang=fi.
3. Type ls (hd0, or similar, substituting the name of the disk.
   Do not press Enter.
4. Press the Tab key.  

-- Actual results:
GRUB displays something like:

grub ls (hd0,
Mahdollisia osioita ovat:

Osio hd0,gpt1: Tuntematon tiedostoj?rjestelm?
Osio hd0,gpt2: Tiedostoj?rjestelm?tyyppi ext2 - Nimi? ?boot? -
Viimeinen muokkausaika $d.$d.$d $d:$d:$d $s, UUID
2097e2f5-7cc4-4fc0-84bc-7780ae74edd5
Osio hd0,gpt3: Tuntematon tiedostoj?rjestelm?
Osio hd0,gpt4: Tuntematon tiedostoj?rjestelm?
Osio hd0,gpt5: Tuntematon tiedostoj?rjestelm?

Note the $d.$d.$d $d:$d:$d $s part.  (The question marks appear
in grub-emu; I don't remember whether they do in grub-pc too.)

-- Expected results:
GRUB should have instead displayed a date and a time.
Like this, for example:

grub ls (hd0,
Mahdollisia osioita ovat:

Osio hd0,gpt1: Tuntematon tiedostoj?rjestelm?
Osio hd0,gpt2: Tiedostoj?rjestelm?tyyppi ext2 - Nimi? ?boot? -
Viimeinen muokkausaika 15.6.2011 07:17:24 Wednesday, UUID
2097e2f5-7cc4-4fc0-84bc-7780ae74edd5
Osio hd0,gpt3: Tuntematon tiedostoj?rjestelm?
Osio hd0,gpt4: Tuntematon tiedostoj?rjestelm?
Osio hd0,gpt5: Tuntematon tiedostoj?rjestelm?

(Localizing Wednesday is not in the scope of this bug report.)

-- Cause:
po/fi.po in the source tree does:

#: normal/misc.c:88
#, c-format
msgid - Last modification time %d-%02d-%02d %02d:%02d:%02d %s
msgstr - Viimeinen muokkausaika %3$d.%2$d.%1$d %4$d:%5$d:%6$d %7$s

However, grub_vsnprintf_real in kern/misc.c does not support
numbered argument conversion specifications like %1$d.

Only this one translation in po/fi.po has the bug.  There are
dollar signs in po/zh_CN.po too but they have been commented out.

-- Change request:
Please either change the C code to support numbered arguments,
or change the translation not to use them.
The easiest fix would be to make the Finnish msgstr use the same
%d-%02d-%02d %02d:%02d:%02d %s format as the msgid.
Although the year-month-day format is not widely used in Finland,
it would surely be better than not seeing the date at all.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages grub-common depends on:
ii  base-files  6.0squeeze1  Debian base system miscellaneous f
ii  dpkg1.15.8.10Debian package management system
ii  gettext-base0.18.1.1-3   GNU Internationalization utilities
ii  install-info4.13a.dfsg.1-6   Manage installed documentation in 
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libdevmapper1.02.1  2:1.02.48-5  The Linux Kernel Device Mapper use
ii  libfreetype62.4.2-2.1FreeType 2 font engine, shared lib
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages grub-common recommends:
pn  os-prober none (no description available)

Versions of packages grub-common suggests:
pn  grub-emu  none (no description available)
pn  multiboot-doc none (no description available)
pn  xorriso   none (no description available)

-- no debconf information


pgppgiyYp1wVw.pgp
Description: PGP signature

Bug#628737: lfhex: Cursor Position does not appear in status bar

[Kalle Olavi Niemitalo]

Package: lfhex
Version: 0.42-3
Severity: normal
Tags: patch, upstream

According to http://stoopidsimple.com/lfhex/screenshots and the
source code, lfhex 0.42 is supposed to have a Cursor Position
field where the user can type a number to quickly skip to that
position.  However, when I run lfhex, that field does not appear.
The status bar initially shows Ready and then goes blank.

I debugged this and the problem seems to be with QStatusBar,
which gets confused about which items it should display because
the status bar itself is still hidden when HexGui::HexGui adds
the items to it and displays the temporary Ready message.  I am
not sure whether QStatusBar is intended to support that kind of
use.  Anyway, the following lfhex patch works around the problem
by removing the message; which may be a good idea in any case, so
that the user can set the Cursor Position immediately after the
window opens, without first having to wait for the message to go
away.

diff -ru lfhex-0.42-3/src/hexGui.cpp lfhex-0.42/src/hexGui.cpp
--- lfhex-0.42-3/src/hexGui.cpp 2008-09-19 03:36:49.0 +0300
+++ lfhex-0.42-3-statusbar/src/hexGui.cpp   2011-06-01 00:08:01.0 
+0300
@@ -121,7 +121,6 @@
   menuBar()-addMenu(viewMenu);
 
   resize(400,196);
-  statusBar()-showMessage(Ready,2000);
   statusBar()-addWidget(new QLabel(Cursor Offset:,statusBar()));
   offsetLineEdit = new QLineEdit(statusBar());
 //  offsetLineEdit-setValidator( new HexValidator(offsetLineEdit) );

If one wanted to keep the message, one could instead override
QWidget::showEvent(QShowEvent *) and show the message from there.
Because the window and the status bar have been shown by that
time, QStatusBar would then correctly track which items it needs
to display.  Such a change would however require additional logic,
to avoid showing the message again if the window is iconified and
restored.

I will try to notify the upstream author of lfhex about this bug.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lfhex depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libqtcore44:4.6.3-4  Qt 4 core module
ii  libqtgui4 4:4.6.3-4  Qt 4 GUI module
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3

lfhex recommends no packages.

lfhex suggests no packages.

-- no debconf information


pgp5zhpkvnd6j.pgp
Description: PGP signature

Bug#627134: mutt registers as a message/rfc822 viewer but requires an mbox with From_ lines

[Kalle Olavi Niemitalo]

Package: mutt
Version: 1.5.20-9+squeeze1
Severity: normal
File: /usr/lib/mime/packages/mutt

I have been using the Gnus nnml back end to save my email.
It creates one file per message, and these are not mbox files as
they do not begin with a From_ line; rather, they are straight
RFC 822 with some extra header fields such as X-From-Line,
X-Gnus-Mail-Source, and Xref.  A sample file is attached.

Now, I had found one of these email files with grep, and wanted
to quickly view an attachment of it without first having to
locate the message in Gnus.  So, I tried opening it with see:

% see Mail/pre/mail/test/63 
Warning: unknown mime-type for Mail/pre/mail/test/63 -- using 
application/octet-stream
Error: no view mailcap rules found for type application/octet-stream

That didn't work out, but see(1) told me how to specify the MIME
type:

% see message/rfc822:Mail/pre/mail/test/63 
Mail/pre/mail/test/63 is not a mailbox.

Still no luck.

If I copy the file aside and change the X-From-Line header field
of the copy to From_, then Mutt is happy to display the message.
However, that line should not be required in message/rfc822; from
what I can tell, RFC 822 and RFC 2822 do not even allow such a
line, and the definition of message/rfc822 in RFC 2046 section
5.2.1 says nothing about it.

Thus, if Mutt registers itself as a mailcap handler for
message/rfc822, it should be able to open and display a
non-mailbox file.  This might involve a new option; or
if Mutt already supports such an option, then the mailcap
registration should be changed to use it.

-- Package-specific info:
Mutt 1.5.20 (2009-06-14)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 2.6.32-5-amd64 (x86_64)
ncurses: ncurses 5.7.20100313 (compiled with 5.7)
libidn: 1.15 (compiled with 1.18)
hcache backend: tokyocabinet 1.4.37
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL=/usr/sbin/sendmail
MAILPATH=/var/mail
PKGDATADIR=/usr/share/mutt
SYSCONFDIR=/etc
EXECSHELL=/bin/sh
MIXMASTER=mixmaster
To contact the developers, please mail to mutt-...@mutt.org.
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode
misc/hg.pmdef.debugtime
debian-specific/build_doc_adjustments.diff
features/ifdef
features/xtitles
features/trash-folder
features/purge-message
features/sensible_browser_position
features-old/patch-1.5.4.vk.pgp_verbose_mime
features/compressed-folders
features/compressed-folders.debian
debian-specific/Muttrc
debian-specific/Md.etc_mailname_gethostbyname.diff
debian-specific/use_usr_bin_editor.diff
debian-specific/correct_docdir_in_man_page.diff
debian-specific/dont_document_not_present_features.diff
debian-specific/document_debian_defaults
debian-specific/assumed_charset-compat
debian-specific/467432-write_bcc.patch
misc/define-pgp_getkeys_command.diff
misc/gpg.rc-paths
misc/smime.rc
upstream/533209-mutt_perror.patch
upstream/533459-unmailboxes.patch
upstream/533439-mbox-time.patch
upstream/531430-imapuser.patch
upstream/534543-imap-port.patch
upstream/538128-mh-folder-access.patch
upstream/537818-emptycharset.patch
upstream/535096-pop-port.patch
upstream/542910-search-segfault.patch
upstream/533370-pgp-inline.patch
upstream/533520-signature-highlight.patch
upstream/393926-internal-viewer.patch
upstream/543467-thread-segfault.patch
upstream/544180-italian-yesorno.patch
upstream/542817-smimekeys-tmpdir.patch
upstream/544794-smtp-batch.patch
upstream/537694-segv-imap-headers.patch
upstream/548577-gpgme-1.2.patch
upstream/548494-swedish-intl.patch
upstream/553321-ansi-escape-segfault.patch
upstream/553238-german-intl.patch
upstream/557395-muttrc-crypto.patch
upstream/545316-header-color.patch
upstream/568295-references.patch
upstream/547980-smime_keys-chaining.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/547739-manual-typos.patch
upstream/311296-rand-mktemp.patch
upstream/573823-imap_internal_date
upstream/542344-dont_fold_From_
upstream/537061-dont-recode-saved-attachments.patch
upstream/path_max
misc/hyphen-as-minus.patch
misc/smime_keys-manpage.patch
mutt.org

-- System Information:
Debian Release: 6.0.1
  APT prefers oldstable
  APT policy: 

Bug#573325: openssh-client: ssh-agent strips LD_LIBRARY_PATH from user profile in X sessions

[Kalle Olavi Niemitalo]

Package: x11-common
Version: 1:7.5+8
File: /etc/X11/Xsession.d/90x11-common_ssh-agent

/etc/X11/Xsession.d/90x11-common_ssh-agent nowadays saves and
restores TMPDIR:

  STARTUP=$SSHAGENT $SSHAGENTARGS ${TMPDIR:+env TMPDIR=$TMPDIR} $STARTUP

Please consider tunneling LD_LIBRARY_PATH in the same way.
Until then, I've added a similar hack in ~/.xsessionrc.

I spent half an hour searching for what deleted the variable
(and now more complaining about it...).  It's documented in
/usr/share/doc/openssh-client/README.Debian.gz (since bug
#167974), but I didn't originally know ssh-agent was the cause,
so didn't look there.  Perhaps this should be mentioned in
Xsession(5) as well?

Also, I think the problem could be fixed with two executables.
A not-setgid wrapper would create a pipe and fork.  The child
process would write all of its environment variables to the pipe
and exit.  The parent process would exec the setgid ssh-agent and
tell it the file descriptor of the pipe.  The setgid ssh-agent
would lose some environment variables on startup but read them
all back from the pipe and eventually pass them to execle().


pgpB53XrEh6ue.pgp
Description: PGP signature

Bug#624715: dash.1: too many spaces in descriptions of PS1, PS2, PS4

[Kalle Olavi Niemitalo]

Jonathan Nieder jrnie...@gmail.com writes:

 Could you send a patch relative to src/dash.1 of

   git://git.kernel.org/pub/scm/utils/dash/dash.git master

 (or, barring that, a diff -u between the shipped dash.1 and your
 modified version)?

Here's the diff against 0.5.5.1-7.4.

--- dash.1.~1~  2011-05-01 13:44:58.0 +0300
+++ dash.1  2011-05-01 13:45:36.0 +0300
@@ -2271,16 +2271,16 @@
 There is a maximum of 10 mailboxes that can be monitored at once.
 .It Ev PS1
 The primary prompt string, which defaults to
-.Dq $ \  ,
+.Dq $\  ,
 unless you are the superuser, in which case it defaults to
-.Dq # \  .
+.Dq #\  .
 .It Ev PS2
 The secondary prompt string, which defaults to
-.Dq \*[Gt] \  .
+.Dq \*[Gt]\  .
 .It Ev PS4
 Output before each line when execution trace (set -x) is enabled,
 defaults to
-.Dq + \  .
+.Dq +\  .
 .It Ev IFS
 Input Field Separators.
 This is normally set to


pgpXwvpnkpeGs.pgp
Description: PGP signature

Bug#624715: dash.1: too many spaces in descriptions of PS1, PS2, PS4

[Kalle Olavi Niemitalo]

Package: dash
Version: 0.5.5.1-7.4
Severity: minor
File: /usr/share/man/man1/dash.1.gz

LANG=C man dash shows:

 PS1The primary prompt string, which defaults to ``$  '', unless
you are the superuser, in which case it defaults to ``#  ''.

 PS2The secondary prompt string, which defaults to ``  ''.

 PS4Output before each line when execution trace (set -x) is
enabled, defaults to ``+  ''.

Each of the documented default values has a graphic character and
two spaces between the quotation marks.  However, the actual
default values have only one space, rather than two.

LANG=fi_FI.UTF-8 man dash shows the same spaces as LANG=C,
although the surrounding quotation marks are different.

The source code of the man page goes like this:

.It Ev PS1
The primary prompt string, which defaults to
.Dq $ \  ,
unless you are the superuser, in which case it defaults to
.Dq # \  .

Apparently, the Dq macro outputs a space between the first
parameter (the dollar sign) and the second parameter (a space).
I tried merging those parameters, like this:

.It Ev PS1
The primary prompt string, which defaults to
.Dq $\  ,
unless you are the superuser, in which case it defaults to
.Dq #\  .

and that fixed the bug for PS1.  The manual page already uses
similar syntax in the documentation of set -x, so this change
should not cause portability problems.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dash depends on:
ii  debianutils   3.4Miscellaneous utilities specific t
ii  dpkg  1.15.8.10  Debian package management system
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

dash recommends no packages.

dash suggests no packages.

Versions of manual-page viewers:
ii  groff 1.20.1-10  GNU troff text-formatting system
ii  groff-base1.20.1-10  GNU troff text-formatting system (
ii  man-db2.5.7-8on-line manual pager
ii  x11-apps  7.5+5  X applications

-- debconf information:
* dash/sh: true


pgp5OVETWiAA9.pgp
Description: PGP signature

Bug#594324: network-manager-gnome: nm-connection-editor segfaults on editing wired network

[Kalle Olavi Niemitalo]

package network-manager-gnome
fixed 594324 network-manager-applet/0.8.2-1
quit

Kalle Olavi Niemitalo k...@iki.fi writes:

 This fix is included in network-manager-applet 0.8.1.997 =
 0.8.2-beta1.

I tested this by upgrading network-manager-gnome, libnm-glib2,
and libnm-util1 to 0.8.3.999-1 in my Squeeze system, regardless
of other dependencies.  This version of nm-connection-editor did
not crash.

Likewise with network-manager-gnome 0.8.2-1 from snapshot.debian.org.
I didn't see amd64 binaries of network-manager 0.8.2-1 there, so
I used libnm-glib2 and libnm-util1 0.8.3.999-1 in this test too.

The disposed twice warnings were still there but instance of
invalid non-instantiatable type was not.

I'm marking this bug fixed but leaving it for the maintainer or
submitter to close.


pgpAAuvUqWhje.pgp
Description: PGP signature

Bug#566625: NetworkManager applet for GNOME crashes deleting wireless connections

[Kalle Olavi Niemitalo]

package network-manager-gnome
fixed 566625 network-manager-applet/0.7.999-1
quit

This bug seems to be caused by uninitialized GError *error in
network-manager-applet-0.7.2/src/gconf-helpers/nma-gconf-connection.c
(nma_gconf_connection_new).  nm-connection-editor did not crash
when I tested with a debug build, because the variable somehow
became NULL then; but if I set error = (GError *) 1 with GDB
after the declaration, then it crashed.  Also, valgrind shows the
bug in the debug build without GDB:

==9114== Conditional jump or move depends on uninitialised value(s)
==9114==at 0x756CF1F: g_clear_error (gerror.c:300)
==9114==by 0x441864: nma_gconf_connection_new (nma-gconf-connection.c:83)
==9114==by 0x437905: connection_changes_done (nma-gconf-settings.c:317)
==9114==by 0x757D6F1: g_main_context_dispatch (gmain.c:1960)
==9114==by 0x7581567: g_main_context_iterate (gmain.c:2591)
==9114==by 0x7581A74: g_main_loop_run (gmain.c:2799)
==9114==by 0x41C0BA: main (main.c:291)

The Debian network-manager-gnome 0.7.2-2 binary likewise crashes
somewhere in g_clear_error:

#0  0x750b2165 in *__GI_raise (sig=value optimized out)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x750b4f70 in *__GI_abort () at abort.c:92
#2  0x750e827b in __libc_message (do_abort=value optimized out, 
fmt=value optimized out) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x750f1ad6 in malloc_printerr (action=3, 
str=0x751a89f0 munmap_chunk(): invalid pointer, 
ptr=value optimized out) at malloc.c:6267
#4  0x7540eee2 in IA__g_error_free (error=0x756bc170)
at /scratch/build-area/glib2.0-2.24.2/glib/gerror.c:138
#5  0x7540ef26 in IA__g_clear_error (err=0x7fffe0b8)
at /scratch/build-area/glib2.0-2.24.2/glib/gerror.c:302
#6  0x0043824a in nma_gconf_connection_new ()
#7  0x0043096d in ?? ()
#8  0x7541f6f2 in g_main_dispatch (context=0x68eae0)
at /scratch/build-area/glib2.0-2.24.2/glib/gmain.c:1960
#9  IA__g_main_context_dispatch (context=0x68eae0)
at /scratch/build-area/glib2.0-2.24.2/glib/gmain.c:2513
#10 0x75423568 in g_main_context_iterate (context=0x68eae0, 
block=value optimized out, dispatch=value optimized out, 
self=value optimized out)
at /scratch/build-area/glib2.0-2.24.2/glib/gmain.c:2591
#11 0x75423a75 in IA__g_main_loop_run (loop=0x6e7760)

The code in nma_gconf_connection_new looks like this:

GError *error;
...
connection = nm_gconf_read_connection (client, conf_dir, error);
if (connection) {
...
} else {
g_warning (%s: (%s) error reading connection: (%d) %s,
   __func__, conf_dir,
   error ? error-code : -1,
   error  error-message ? error-message : 
(unknown));
g_clear_error (error);
}

http://developer.gnome.org/glib/unstable/glib-Error-Reporting.html
says: A GError* must be initialized to NULL before passing its
address to a function that can report errors.  Thus, the bug is
in network-manager-applet, not in gconf_client_all_dirs to which
nm_gconf_read_connection passes the error pointer.

The bug was caused by a patch that was made to fix CVE-2009-4144,
included in network-manager-applet 0.7.3-beta2, and applied by Debian
as 03-CVE-2009-4144_fix_ca_cert_handling_after_cert_file_deletion.patch
in network-manager-applet 0.7.2-2:
http://git.gnome.org/browse/network-manager-applet/commit/?h=NETWORKMANAGER_APPLET_0_7id=4020594dfbf566f1852f0acb36ad631a9e73a82b
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560067
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4144

The bug was fixed in network-manager-applet 0.7.3:
http://git.gnome.org/browse/network-manager-applet/commit/?h=NETWORKMANAGER_APPLET_0_7id=71e294a08119f9a1023518a3803631a808bf87bd
https://bugzilla.gnome.org/show_bug.cgi?id=621401
https://bugzilla.novell.com/show_bug.cgi?id=611630

In network-manager-applet 0.7.0, 0.8.0, and 0.8.4,
nma_gconf_connection_new does not use GError at all and thus
cannot have this bug.  The flawed patch was removed in Debian
network-manager-applet 0.7.999-1.


pgpGSz6hMofgz.pgp
Description: PGP signature

Bug#594324: network-manager-gnome: nm-connection-editor segfaults on editing wired network

[Kalle Olavi Niemitalo]

Package: network-manager-gnome
Version: 0.8.1-2
File: /usr/bin/nm-connection-editor

I think I'm seeing the same segfault, with both wired and
wireless connections; but only after nm-connection-editor has
prompted for the root password.  If I create or modify or delete
a single-user connection, then nm-connection-editor does not
prompt for the root password and does not crash.

To debug the crash, I rebuilt network-manager-applet with
DEB_BUILD_OPTIONS=nostrip noopt debug.  (I suppose the debug
had no effect.)  There is a GDB session at the end of this
message.

The crash happens because get_permissions_cb is called on a
CEPolkitButton that has already been finalized.  The g_class
pointer no longer points to a CEPolkitButtonClass, and that makes
CE_POLKIT_BUTTON_GET_PRIVATE (object) print a warning and return
NULL.  Because CEPolkitButtonPrivate *priv thus becomes NULL,
priv-perm_calls then crashes.

It seems this bug has been fixed in the upstream Git repository:
http://git.gnome.org/browse/network-manager-applet/commit/?h=NMA_0_8id=9737403b155d303cffbd08fe4a84c510ac995c8b
https://bugzilla.redhat.com/show_bug.cgi?id=603566

This fix is included in network-manager-applet 0.8.1.997 =
0.8.2-beta1.  There is a different (perhaps more reliable?)
fix in network-manager-applet 0.8.997 = 0.9.0-beta3.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager-gnome depends on:
ii  dbus-x11   1.2.24-4  simple interprocess messaging syst
ii  gconf2 2.28.1-6  GNOME configuration database syste
ii  gnome-icon-theme   2.30.3-2  GNOME Desktop icon theme
ii  libatk1.0-01.30.0-1  The ATK accessibility toolkit
ii  libc6  2.11.2-10 Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libdbus-1-31.2.24-4  simple interprocess messaging syst
ii  libdbus-glib-1-2   0.88-2.1  simple interprocess messaging syst
ii  libfontconfig1 2.8.0-2.1 generic font configuration library
ii  libfreetype6   2.4.2-2.1 FreeType 2 font engine, shared lib
ii  libgconf2-42.28.1-6  GNOME configuration database syste
ii  libglade2-01:2.6.4-1 library to load .glade files at ru
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libgnome-bluetooth72.30.0-2  GNOME Bluetooth tools - support li
ii  libgnome-keyring0  2.30.1-1  GNOME keyring services library
ii  libgtk2.0-02.20.1-2  The GTK+ graphical user interface 
ii  libnm-glib-vpn10.8.1-6+squeeze1  network management framework (GLib
ii  libnm-glib20.8.1-6+squeeze1  network management framework (GLib
ii  libnm-util10.8.1-6+squeeze1  network management framework (shar
ii  libnotify1 [libnotify1 0.5.0-2   sends desktop notifications to a n
ii  libpango1.0-0  1.28.3-1+squeeze2 Layout and rendering of internatio
ii  libxml22.7.8.dfsg-2  GNOME XML library
ii  network-manager0.8.1-6+squeeze1  network management framework daemo
ii  policykit-1-gnome  0.96-3GNOME authentication agent for Pol
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

Versions of packages network-manager-gnome recommends:
ii  gnome-bluetooth   2.30.0-2   GNOME Bluetooth tools
ii  libpam-gnome-keyring [libpam- 2.30.3-5   PAM module to unlock the GNOME key
ii  mobile-broadband-provider-inf 20101106-1 database of mobile broadband servi
ii  notification-daemon   0.5.0-2daemon to displays passive pop-up 

Versions of packages network-manager-gnome suggests:
pn  network-manager-openvpn-gnome none (no description available)
pn  network-manager-pptp-gnomenone (no description available)
pn  network-manager-vpnc-gnomenone (no description available)

-- no debconf information

GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from 
/home/Kalle/build/x86_64-unknown-linux-gnu/Debian/network-manager-applet-0.8.1/src/connection-editor/nm-connection-editor...done.
(gdb) set environment LANG=en_US.UTF-8
(gdb) break ce-polkit-button.c:dispose
Breakpoint 1 at 0x434e49: file 

Bug#608124: Reports wrong URI for No such file or directory.

[Kalle Olavi Niemitalo]

In elinks-0.12/src/session/session.c, doc_loading_callback does:

if (!is_in_state(download-state, S_OK)) {
print_error_dialog(ses, download-state,
   ses-doc_view-document-uri,
   download-pri);
}

Here, ses-doc_view-document-uri is the URI of the frameset,
which is the wrong thing to display.  The URI of the frame seems
to be in download-conn-uri or download-conn-proxied_uri.
(download-cached was NULL in my test, so download-cached-uri
was unusable.  Also, ses-loading_uri was NULL.)

When ELinks is beginning to download a frame, request_frame
calls request_additional_file, which constructs struct
file_to_load, which has struct download as a member.
Although request_additional_file returns struct file_to_load *,
the return value is never used.  Instead, process_file_requests
finds these structures in the session::more_files list and calls
load_uri on each.  load_uri can call download-callback without
ever setting a non-null download-conn: for example, if the URI
is malformed, or if init_connection fails.

This means doc_loading_callback cannot reliably get the frame URI
From download-conn if the download has failed.  Do not imitate
the #ifdef CONFIG_GLOBHIST section of doc_loading_callback
because that gets run only if the download has succeeded.

I suspect we should either add the URI to struct download, or add
it as a third parameter to doc_loading_callback and update all
callers.

Or maybe add dynamically allocated error objects so that the URI
can be carried as part of the error...?  That would also be a way
to propagate the GnuTLS certificate status bits together with
S_SSL_ERROR.


pgpuCUF9tXwYq.pgp
Description: PGP signature

Bug#601933: elinks: problems handling UTF-8

[Kalle Olavi Niemitalo]

ELinks 0.11.* do not support UTF-8 as the character set of the
terminal.  You can instead select an 8-bit character set that
contains many of the characters you need, and enable the UTF-8
I/O option.  ELinks 0.11.* do not support fullwidth characters
either.

ELinks 0.12pre1 and later versions support UTF-8 and fullwidth
characters.

I don't think any version of ELinks yet supports right-to-left
characters.


pgpLG7Ic6NCVD.pgp
Description: PGP signature

Bug#598072: elinks: disabling mouse usage

[Kalle Olavi Niemitalo]

Drake Wilson dr...@begriffli.ch writes:

 It would be nice if I could tell ELinks to
 ignore the mouse completely, either globally or on a finer-grained
 basis, but I see nothing in the Terminals or User Interface option
 groups or in the keybinding manager that provides this.

The Main section of the keybinding manager is supposed to
include Toggle mouse handling (toggle-mouse) since 0.11.0.
If you use the Search button, please note that it does not
search in closed folders.  (I don't know why.)

Also, in xterm and gnome-terminal at least, holding the Shift key
makes the terminal handle mouse events on its own rather than
pass them to ELinks.


pgpTmn3aHfaLn.pgp
Description: PGP signature

Bug#623136: abiword: missing newline in the middle of mailcap

[Kalle Olavi Niemitalo]

Package: abiword
Version: 2.8.2-2.1
Severity: normal
File: /usr/lib/mime/packages/abiword

My /etc/mailcap contains the following entry, which apparently
came from /usr/lib/mime/packages/abiword:

application/vnd.ms-word; abiword '%s' ; edit=abiword '%s' ; test=test 
$DISPLAY !=  ; nametemplate=%s.doc ; description=Microsoft Word Document 
; priority=2application/wordperfect; abiword '%s' ; edit=abiword '%s' ; 
test=test $DISPLAY !=  ; nametemplate=%s.wpd ; description=Corel 
WordPerfect Document

This should be split into two entries, as follows:

application/vnd.ms-word; abiword '%s' ; edit=abiword '%s' ; test=test 
$DISPLAY !=  ; nametemplate=%s.doc ; description=Microsoft Word Document 
; priority=2
application/wordperfect; abiword '%s' ; edit=abiword '%s' ; test=test 
$DISPLAY !=  ; nametemplate=%s.wpd ; description=Corel WordPerfect 
Document

(You may also want to add priority=2 to the
application/wordperfect and application/vnd.wordperfect entries,
because all other entries in the abiword file have priority=2.)

The missing newline triggered a small memory leak in ELinks,
which did not expect two descriptions for the same entry: 
http://bugzilla.elinks.cz/show_bug.cgi?id=1113

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages abiword depends on:
ii  abiword-com 2.8.2-2.1efficient, featureful word process
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 Fonts for the Ghostscript interpre
ii  libabiword- 2.8.2-2.1efficient, featureful word process
ii  libaiksauru 1.2.1+dev-0.12-6 graphical interface to the Aiksaur
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libcairo2   1.8.10-6 The Cairo 2D vector graphics libra
ii  libdbus-1-3 1.2.24-4 simple interprocess messaging syst
ii  libdbus-gli 0.88-2.1 simple interprocess messaging syst
ii  libgcc1 1:4.4.5-8GCC support library
ii  libgcrypt11 1.4.5-2  LGPL Crypto library - runtime libr
ii  libglib2.0- 2.24.2-1 The GLib library of C routines
ii  libgnutls26 2.8.6-1  the GNU TLS library - runtime libr
ii  libgoffice- 0.8.8-1  Document centric objects library -
ii  libgsf-1-11 1.14.18-1Structured File Library - runtime 
ii  libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface 
ii  libjpeg62   6b1-1The Independent JPEG Group's JPEG 
ii  libloudmout 1.4.3-7  Lightweight C Jabber library
ii  libots0 0.5.0-2  Open Text Summarizer (library)
ii  libpng12-0  1.2.44-1 PNG library - runtime
ii  libreadline 6.1-3GNU readline and history libraries
ii  libsoup2.4- 2.30.2-1 an HTTP library implementation in 
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  libwmf0.2-7 0.2.8.4-6.1+b1   Windows metafile conversion librar
ii  libwpd8c2a  0.8.14-1 Library for handling WordPerfect d
ii  libwpg-0.1- 0.1.3-1  WordPerfect graphics import/conver
ii  libwps-0.1- 0.1.2-1  Works text file format import filt
ii  libxml2 2.7.8.dfsg-2 GNOME XML library
ii  libxslt1.1  1.1.26-6 XSLT 1.0 processing library - runt

Versions of packages abiword recommends:
ii  abiword-plugin-grammar 2.8.2-2.1 grammar checking plugin for AbiWor
ii  abiword-plugin-mathvie 2.8.2-2.1 equation editor plugin for AbiWord
ii  aspell-en [aspell-dict 6.0-0-6   English dictionary for GNU Aspell
ii  poppler-utils  0.12.4-1.2PDF utilitites (based on libpopple
ii  ttf-liberation 1.05.2.20091019-4 Fonts with the same metrics as Tim

abiword suggests no packages.

-- no debconf information


pgpdEtFJhhtDj.pgp
Description: PGP signature

Bug#561838: xserver-xorg-core: Infinite loop on startup if Wacom tablet is already connected

[Kalle Olavi Niemitalo]

Cyril Brulebois k...@debian.org writes:

 is this still happening with the X stack from squeeze/sid, or from
 experimental?

I could no longer reproduce the hang, even after downgrading
xserver-xorg to 1:7.4+4 and dependencies to compatible versions,
and reinstalling hal.  I did not try downgrading udev from 164-3
to whatever version was in testing back then.

The hang was very reproducible when I originally reported it.


pgpWmCUjmpXDk.pgp
Description: PGP signature

Bug#616538: TOLUA_NIL documented but not defined

[Kalle Olavi Niemitalo]

Package: libtolua++5.1-dev
Version: 1.0.93-1
Severity: normal

Quoting from /usr/share/doc/libtolua++5.1-dev/tolua++.html:

 For Lua object types (lua_Object), tolua defines a constant
 that can be used to specify nil as default value:

 void func (lua_Object lo = TOLUA_NIL);

However, tolua++ does not actually define TOLUA_NIL, so
attempting to use it results in a compiler error.  Grepping
through the source tree shows the only occurrences of TOLUA_NIL
are in doc/tolua++.html.

I see the documentation actually says tolua rather than
tolua++ at that point.  However, tolua 5.1.2-1 does not define
TOLUA_NIL either.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libtolua++5.1-dev depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  liblua5.1-0   5.1.4-5Simple, extensible, embeddable pro
ii  liblua5.1-0-dev [liblua5.1-de 5.1.4-5Simple, extensible, embeddable pro

libtolua++5.1-dev recommends no packages.

libtolua++5.1-dev suggests no packages.

-- no debconf information


pgp4mPsVilXw2.pgp
Description: PGP signature

Bug#616557: generated code copies array contents from wrong Lua stack location if preceded by lua_State *

[Kalle Olavi Niemitalo]

Package: tolua++5.1-dev
Severity: normal

If I declare a function in a *.pkg file like this:

void fun(lua_State *state, int numbers[42]);

then tolua++ generates the following stub for Lua to call:

/* function: fun */
#ifndef TOLUA_DISABLE_tolua_huh_fun00
static int tolua_huh_fun00(lua_State* tolua_S)
{
#ifndef TOLUA_RELEASE
 tolua_Error tolua_err;
 if (
 !tolua_istable(tolua_S,1,0,tolua_err) ||
 !tolua_isnoobj(tolua_S,2,tolua_err)
 )
  goto tolua_lerror;
 else
#endif
 {
  lua_State* state =  tolua_S;
  int numbers[42];
  {
#ifndef TOLUA_RELEASE
   if (!tolua_isnumberarray(tolua_S,2,42,0,tolua_err))
goto tolua_lerror;
   else
#endif
   {
int i;
for(i=0; i42;i++)
numbers[i] = ((int)  tolua_tofieldnumber(tolua_S,2,i+1,0));
   }
  }
  {
   fun(state,numbers);
  }
  {
   int i;
   for(i=0; i42;i++)
tolua_pushfieldnumber(tolua_S,2,i+1,(lua_Number) numbers[i]);
  }
 }
 return 0;
#ifndef TOLUA_RELEASE
 tolua_lerror:
 tolua_error(tolua_S,#ferror in function 'fun'.,tolua_err);
 return 0;
#endif
}
#endif //#ifndef TOLUA_DISABLE

In th e tolua_isnumberarray, tolua_tofieldnumber, and
tolua_pushfieldnumber calls, the second argument is wrong.
It should be 1 rather than 2, because numbers is the first
parameter in the Lua stack, even though it is the second
parameter of the C++ function.  Note that the generated code
has previously called tolua_istable(tolua_S,1,0,tolua_err)
with the correct stack index.

If I move the lua_State * parameter to the end of the list,
then numbers is the first parameter in both Lua and C++,
and tolua++ generates correct code.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


pgpi55Fib7Gfr.pgp
Description: PGP signature

Bug#616557: generated code copies array contents from wrong Lua stack location if preceded by lua_State *

[Kalle Olavi Niemitalo]

package libtolua++5.1-dev
found 616557 tolua++/1.0.93-1
quit

Kalle Olavi Niemitalo k...@iki.fi writes:

 In the tolua_isnumberarray, tolua_tofieldnumber, and
 tolua_pushfieldnumber calls, the second argument is wrong.
 It should be 1 rather than 2, because numbers is the first
 parameter in the Lua stack, even though it is the second
 parameter of the C++ function.

I think the attached patch fixes it; the resulting code looks OK.
I haven't added a test case though, so not setting the patch tag.
Also, as this patch affects the output, I suspect TOLUA_VERSION
should be changed to e.g. tolua++-1.0.93-2 (Debian), so that
people running tolua++ on other systems will understand why their
output differs from that generated with this patch.

tolua++ (1.0.93-1.kon.1) local; urgency=low

  * Local version!
  * Add patch debian/patches/state_with_array.patch:
correct Lua stack location of arrays preceded by lua_State *
(Closes: #616557)

Description: correct Lua stack location of arrays preceded by lua_State *
Author: Kalle Olavi Niemitalo k...@iki.fi
Forwarded: no

--- tolua++-1.0.93.orig/src/bin/lua/function.lua	2008-11-11 20:14:49.0 +0200
+++ tolua++-1.0.93/src/bin/lua/function.lua	2011-03-05 20:53:46.0 +0200
@@ -161,7 +161,9 @@ function classFunction:supcode (local_co
   local i=1
   while self.args[i] do
self.args[i]:getarray(narg)
-   narg = narg+1
+   if isbasic(self.args[i].type) ~= state then
+	   narg = narg+1
+   end
i = i+1
   end
  end
@@ -288,7 +290,9 @@ function classFunction:supcode (local_co
local i=1
while self.args[i] do
 self.args[i]:setarray(narg)
-narg = narg+1
+if isbasic(self.args[i].type) ~= state then
+	narg = narg+1
+end
 i = i+1
end
   end


pgps9CVT5zmWy.pgp
Description: PGP signature

Bug#616601: tolua++-generated stub can leak a variable-size array on element type mismatch

[Kalle Olavi Niemitalo]

Package: libtolua++5.1-dev
Version: 1.0.93-1
Severity: normal

If a *.pkg file declares a function with a variable-size array
parameter, then the C++ stub generated by tolua++ allocates
the array with the Mtolua_new_dim macro, copies the contents
of the corresponding Lua table there, passes the array to the
C++ function, copies any modified contents back to the Lua
table, and frees the array with the Mtolua_delete_dim macro.
By default, these macros use the new[] and delete[] operators.

However, if the Lua table contains values that cannot be
converted to the element type of the C++ array, then the stub
notices this after it has allocated the array, and it calls
tolua_error, which indirectly calls longjmp and never returns.
The array is never freed in this case; that is a memory leak.
Because of the type mismatch error, the stub doesn't even call
the wrapped C++ function, so tolua++ cannot claim the bug is
in that function.

Here is a program that triggers the bug:

#include cassert
#include tolua++.h
#include leak-tolua.h

static int
bad_call(lua_State *state)
{
int ret = luaL_loadstring(state, func(42, {'not a number'}));
assert(ret == 0);

lua_call(state, 0, 0);
return 0;
}

int
main(void)
{
lua_State *state = luaL_newstate();
assert(state != NULL);

int openok = tolua_leak_open(state);
assert(openok == 1);

for (int i = 0; i  1; ++i)
{
int ret = lua_cpcall(state, bad_call, NULL);
assert(ret == LUA_ERRRUN);
lua_pop(state, 1);
}

lua_close(state);
return 0;
}
$void func(int len, int array[]) {}

void func(int len, int array[len]);
TOLUAXX = tolua++5.1
CPPFLAGS = -I/usr/include/lua5.1
CXXFLAGS = -ggdb -Wall

leak: leak.cpp leak-tolua.cpp leak-tolua.h
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -o leak leak.cpp leak-tolua.cpp 
-ltolua++5.1 -llua5.1

leak-tolua.cpp leak-tolua.h: leak.pkg
$(TOLUAXX) -o leak-tolua.cpp -H leak-tolua.h leak.pkg

.PHONY: clean
clean:
$(RM) leak leak-tolua.cpp leak-tolua.h
==32489== Memcheck, a memory error detector
==32489== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==32489== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for 
copyright info
==32489== Command: ./leak
==32489== 
==32489== 
==32489== HEAP SUMMARY:
==32489== in use at exit: 1,680,000 bytes in 10,000 blocks
==32489==   total heap usage: 201,998 allocs, 191,998 frees, 11,571,386 bytes 
allocated
==32489== 
==32489== 1,680,000 bytes in 10,000 blocks are definitely lost in loss record 1 
of 1
==32489==at 0x4C24A72: operator new[](unsigned long) 
(vg_replace_malloc.c:305)
==32489==by 0x401C67: tolua_leak_func00(lua_State*) (leak-tolua.cpp:40)
==32489==by 0x4E35A55: luaD_precall (ldo.c:319)
==32489==by 0x4E40810: luaV_execute (lvm.c:587)
==32489==by 0x4E35FC4: luaD_call (ldo.c:377)
==32489==by 0x4E31305: lua_call (lapi.c:782)
==32489==by 0x401AC8: bad_call(lua_State*) (leak.cpp:11)
==32489==by 0x4E35A55: luaD_precall (ldo.c:319)
==32489==by 0x4E35F68: luaD_call (ldo.c:376)
==32489==by 0x4E35646: luaD_rawrunprotected (ldo.c:116)
==32489==by 0x4E356C4: luaD_pcall (ldo.c:463)
==32489==by 0x4E310B6: lua_cpcall (lapi.c:856)
==32489== 
==32489== LEAK SUMMARY:
==32489==definitely lost: 1,680,000 bytes in 10,000 blocks
==32489==indirectly lost: 0 bytes in 0 blocks
==32489==  possibly lost: 0 bytes in 0 blocks
==32489==still reachable: 0 bytes in 0 blocks
==32489== suppressed: 0 bytes in 0 blocks
==32489== 
==32489== For counts of detected and suppressed errors, rerun with: -v
==32489== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libtolua++5.1-dev depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  liblua5.1-0   5.1.4-5Simple, extensible, embeddable pro
ii  liblua5.1-0-dev [liblua5.1-de 5.1.4-5Simple, extensible, embeddable pro

libtolua++5.1-dev recommends no packages.

libtolua++5.1-dev suggests no packages.

-- no debconf information


pgp3sxDVdKY0e.pgp
Description: PGP signature

Bug#603914: Please drop non-UTF8 locales

[Kalle Olavi Niemitalo]

Vincent Danjean vdanj...@debian.org writes:

   For example, I've lots of old text data in latin1. Some of them are on
 non-rewritable media. Being able to see them with
 LC_CTYPE=fr_FR less toto.txt is very convenient.

less does not convert the characters to UTF-8 for display, so you
also need a latin1 terminal for that command, and typing file names
in such a terminal will make them latin1 too, which is not nice.
Alternatively: iconv --from-code=ISO-8859-1 toto.txt | less

   There are also lots of old web pages written in latin1 that are still
 used (old exercises, ...) Not being able to see them properly on a
 Debian system would be a pain.

I don't believe you need a latin1 locale for viewing latin1 web
pages.  The charset will be available from iconv() in any case,
or browsers may have charset converters built in.
Iceweasel 3.5.15 here can display Shift_JIS web pages
all right even though I don't have any such locale installed.
http://www.toei-anim.co.jp/tv/dejimon/ for example.


pgpMgeXE2KXTN.pgp
Description: PGP signature

Bug#603914: Please drop non-UTF8 locales

[Kalle Olavi Niemitalo]

Josselin Mouette j...@debian.org writes:

 I think wheezy would be a good time to finally ditch non-UTF8 locales. 
 IIRC, we made the switch to UTF8 by default in etch (and we were already 
 way too late in doing that), and supporting non-UTF8 stuff becomes 
 harder and harder, at least for desktop software.

In testing, the C and POSIX locales still don't use UTF-8.
I don't know about unstable.

My latest use of LANG=fi_FI.ISO-8859-1 was when I had a VT420
connected to a serial port (largely for diagnosing graphics
driver problems).  No UTF-8 support there.  However, even then,
it would have been better to use LANG=fi_FI.UTF-8 and recode
only the terminal I/O with some wrapper, so that file names
would have been consistently UTF-8.  The luit program cannot
be used for that because it supports only UTF-8 terminals in
legacy locales, rather than vice versa.  If I remember correctly,
tmux doesn't support such conversions either, but screen does.


pgpKRGCt228ta.pgp
Description: PGP signature

Bug#588912: inkscape: CSS class selector matches a suffix, not only a whole word

[Kalle Olavi Niemitalo]

Package: inkscape
Version: 0.47.0-2+b1
Severity: minor

If the SVG file includes a CSS rule for the selector
rect.world, then it should match rect elements whose class
attribute contains the word world.  In Inkscape however, it
matches rect elements whose class attribute contains any word
ending with world.  I'm attaching a file that demonstrates the
bug.

class=helloworld (large circle): Bug; matches but shouldn't
class=hello (vertical ellipse): OK, doesn't match
class=world (horizontal ellipse): OK, matches
class=hello world (small circle): OK, matches

This bug seems to be in src/libcroco/cr-sel-eng.c
(class_add_sel_matches_node): after strncmp has returned a
nonzero value, which means the word did not match, the loop
increments cur by only one character instead of skipping the
whole word.  In bug #427946, it is said that the src/libcroco/
included in inkscape was forked from libcroco 0.6.  I don't know
whether the class matching code has been fixed in the upstream
libcroco since.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages inkscape depends on:
ii  libaspell15 0.60.6-4 GNU Aspell spell-checker runtime l
ii  libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared lib
ii  libcairo2   1.8.10-4 The Cairo 2D vector graphics libra
ii  libcairomm-1.0-11.8.4-3  C++ wrappers for Cairo (shared lib
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii  libgc1c21:6.8-1.2conservative garbage collector for
ii  libgcc1 1:4.4.4-6GCC support library
ii  libgconf2-4 2.28.1-3 GNOME configuration database syste
ii  libglib2.0-02.24.1-1 The GLib library of C routines
ii  libglibmm-2.4-1c2a  2.24.2-1 C++ wrapper for the GLib toolkit (
ii  libgnomevfs2-0  1:2.24.3-1   GNOME Virtual File System (runtime
ii  libgomp14.4.4-6  GCC OpenMP (GOMP) support library
ii  libgsl0ldbl 1.14+dfsg-1  GNU Scientific Library (GSL) -- li
ii  libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface 
ii  libgtkmm-2.4-1c2a   1:2.20.3-1   C++ wrappers for GTK+ (shared libr
ii  libgtkspell02.0.16-1 a spell-checking addon for GTK's T
ii  liblcms11.18.dfsg-1.2+b2 Color management library
ii  libmagick++37:6.6.0.4-2  object-oriented C++ interface to I
ii  libmagickcore3  7:6.6.0.4-2  low-level image manipulation libra
ii  libpango1.0-0   1.28.1-1 Layout and rendering of internatio
ii  libpangomm-1.4-12.26.2-1 C++ Wrapper for pango (shared libr
ii  libpng12-0  1.2.44-1 PNG library - runtime
ii  libpoppler-glib40.12.4-1 PDF rendering library (GLib-based 
ii  libpoppler5 0.12.4-1 PDF rendering library
ii  libpopt01.16-1   lib for parsing cmdline parameters
ii  libsigc++-2.0-0c2a  2.2.4.2-1type-safe Signal Framework for C++
ii  libstdc++6  4.4.4-6  The GNU Standard C++ Library v3
ii  libwpd8c2a  0.8.14-1 Library for handling WordPerfect d
ii  libwpg-0.1-10.1.3-1  WordPerfect graphics import/conver
ii  libx11-62:1.3.3-3X11 client-side library
ii  libxml2 2.7.7.dfsg-2 GNOME XML library
ii  libxslt1.1  1.1.26-3 XSLT processing library - runtime 
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages inkscape recommends:
ii  aspell   0.60.6-4GNU Aspell spell-checker
ii  imagemagick  7:6.6.0.4-2 image manipulation programs
ii  libwmf-bin   0.2.8.4-6.1 Windows metafile conversion tools
ii  perlmagick   7:6.6.0.4-2 Perl interface to the ImageMagick 
ii  pstoedit 3.45-8+b1   PostScript and PDF files to editab

Versions of packages inkscape suggests:
pn  dia | dia-gnome none   (no description available)
ii  libgnomevfs2-extra  1:2.24.3-1   GNOME Virtual File System (extra m
pn  libsvg-perl none   (no description available)
pn  libxml-xql-perl none   (no description available)
ii  python  2.6.5-5  An interactive high-level object-o
pn  python-lxml none   (no description available)
ii  python-numpy1:1.3.0-3+b2 Numerical Python 

Bug#473678: boswars: game looping endlessly...

[Kalle Olavi Niemitalo]

Another related upstream bug has been fixed in SVN trunk:
  http://savannah.nongnu.org/bugs/?29766
  Path finding method eats CPU futilely when there is not possible path

If I understand correctly, the pathfinder itself was not changed
there, but the higher-level code was changed to retry fewer times
if it doesn't find a path right away.  This change is not in the
boswars-2.6 branch.  It is likely to be released in Bos Wars 2.7.

I had some plans for caching the results from the pathfinder:
  http://savannah.nongnu.org/patch/?7141
  Speed up pathfinder by caching islands
but it now seems such a cache would require also hooking all the
code that moves units, so I'd rather do that only if the current
fix doesn't suffice. 


pgp9H2Ck5EKeS.pgp
Description: PGP signature

Bug#586722: libsnmp-base: NEWS.Debian confusingly refers to udp:172.0.0.1:161 vs. 127.0.0.1

[Kalle Olavi Niemitalo]

Package: libsnmp-base
Version: 5.4.3~dfsg-1
Severity: minor
File: /usr/share/doc/libsnmp-base/NEWS.Debian.gz

When I was upgrading libsnmp-base and libsnmp15 with apt-get
dist-upgrade, I got the following news to the screen, apparently
From apt-listchanges:

 net-snmp (5.4.3~dfsg-1) unstable; urgency=low
 
   As of version 5.4.3, upstream ships a new default configuration in
   /etc/snmp/snmpd.conf, which only uses SNMPv3 rather than SNMPv1 and
   SNMPv2c. This new default configuration also binds to udp:172.0.0.1:161
   by default which conflicts with the former specification of 127.0.0.1
   in /etc/default/snmpd, so now snmpd must be reconfigured here in order
   to be exposed to the network. Be sure to check both files after an
   upgrade.
 
  -- Jochen Friedrich joc...@scram.de  Mon, 07 Jun 2010 17:32:09 +0200

This message is confusing for two reasons:

* It tells me to look in /etc/snmp/snmpd.conf and /etc/default/snmpd,
  but I have neither of those files.  I suppose they would be in the
  snmpd package, which I haven't installed.  Can you make the news
  appear only if that package is installed, or reword it to help
  users understand that it relates only to that package?

* It says udp:172.0.0.1:161 conflicts with 127.0.0.1.  Because
  the first address has a typo in it, I initially got the impression
  that the default address had been changed and I should adjust
  firewalls or something like that, particularly with the news entry
  talking about being exposed to the network.  Even without the
  typo, I think the news entry doesn't make the nature of the conflict
  (trying to bind to the same address multiple times) clear enough.
  The entry in changelog.Debian.gz is much clearer, even though it too
  has the same typo.

I would suggest changing the news to something like this:

   As of version 5.4.3, the snmpd package includes a new default
   configuration in /etc/snmp/snmpd.conf, which only uses SNMPv3
   rather than SNMPv1 and SNMPv2c. This new default configuration
   also binds to udp:127.0.0.1:161 by default which conflicts with
   the former specification of 127.0.0.1 in /etc/default/snmpd.
   If /etc/default/snmpd is not upgraded, snmpd will fail to start
   because it tries to bind to the same address twice. Be sure to
   check both files after an upgrade.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

libsnmp-base depends on no packages.

libsnmp-base recommends no packages.

Versions of packages libsnmp-base suggests:
pn  snmp-mibs-downloader  none (no description available)

-- no debconf information


pgpAwHt3KQ51A.pgp
Description: PGP signature

Bug#583864: gnome-settings-daemon: XF86TouchpadToggle gets out of sync on hibernation

[Kalle Olavi Niemitalo]

Package: gnome-settings-daemon
Version: 2.30.1-1
Severity: normal

This Acer Aspire 5536G laptop has a button for disabling the
touch pad.  The button has a light that shows whether the touch
pad is disabled.  This works whether X is running or not.

In X, the button generates XF86TouchpadToggle key events.  It
seems gnome-settings-daemon grabs this key; on such an event, it
toggles the /desktop/gnome/peripherals/touchpad/touchpad_enabled
GConf key, and apparently then notices that change and enables or
disables the corresponding X input device.  (If I kill
gnome-settings-daemon and toggle the key with gconf-editor, it
does not take effect.)

http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-media-keys-manager.c?id=GNOME_SETTINGS_DAEMON_2_30_1#n639
http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/mouse/gsd-mouse-manager.c?id=GNOME_SETTINGS_DAEMON_2_30_1#n769

Now, the problem is that these two mechanisms sometimes get out
of sync: ACPI or Linux thinks the touch pad should be disabled,
while GNOME or X11 thinks it should be enabled.  No events can
get through.  Then I press the button, and the states turn
around: ACPI or Linux thinks the touch pad should be enabled,
while GNOME or X11 thinks it should be disabled, and still no
events can get through.  Thus, no matter how many times I press
the button, the touch pad still won't work.  This seems to happen
especially if I have first disabled the touch pad by pressing the
button and then shut the laptop lid and had the system suspend to
disk.

Workarounds include:

* When the problem occurs, press Ctrl+Alt+F1 to switch out of
  X, then press the touchpad-toggle button once, and press Alt+F7
  to switch back; ACPI notices that button press but X doesn't, so
  the states will then be in sync again.

* I suppose another workaround would be to toggle the
  touchpad_enabled key with gconf-editor, so ACPI wouldn't know
  about the change.

* Change /apps/gnome_settings_daemon/keybindings/touchpad to
  empty, so gnome-settings-daemon ignores XF86TouchpadToggle.

Regardless, with this model of laptop, I think it would be safest
to automatically disable the XF86TouchpadToggle support in
gnome-settings-daemon, because the firmware and Linux can handle
the button on their own.

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

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome-settings-daemon depends on:
ii  gconf22.28.1-3   GNOME configuration database syste
ii  libc6 2.10.2-9   Embedded GNU C Library: Shared lib
ii  libcairo2 1.8.10-4   The Cairo 2D vector graphics libra
ii  libdbus-1-3   1.2.24-1   simple interprocess messaging syst
ii  libdbus-glib-1-2  0.86-1 simple interprocess messaging syst
ii  libfontconfig12.8.0-2.1  generic font configuration library
ii  libgconf2-4   2.28.1-3   GNOME configuration database syste
ii  libglib2.0-0  2.24.1-1   The GLib library of C routines
ii  libgnome-desktop-2-17 2.30.0-2   Utility library for loading .deskt
ii  libgnome2-common  2.30.0-1   The GNOME library - common files
ii  libgnomekbd4  2.30.1-2   GNOME library to manage keyboard c
ii  libgstreamer-plugins-base0.10 0.10.29-1  GStreamer libraries from the base
ii  libgstreamer0.10-00.10.29-1  Core GStreamer libraries and eleme
ii  libgtk2.0-0   2.20.1-1   The GTK+ graphical user interface 
ii  libnotify1 [libnotify1-gtk2.1 0.4.5-1sends desktop notifications to a n
ii  libx11-6  2:1.3.3-3  X11 client-side library
ii  libxi62:1.3-4X11 Input extension library
ii  libxklavier16 5.0-2  X Keyboard Extension high-level AP

gnome-settings-daemon recommends no packages.

Versions of packages gnome-settings-daemon suggests:
ii  gnome-screensaver 2.30.0-1   GNOME screen saver and locker
ii  metacity [x-window-manager]   1:2.30.1-1 lightweight GTK+ window manager
ii  openbox [x-window-manager]3.4.11.1-1 standards compliant, fast, light-w
ii  twm [x-window-manager]1:1.0.4-2  Tab window manager
ii  x11-xserver-utils 7.5+1  X server utilities

-- no debconf information


pgpRJiORlINjz.pgp
Description: PGP signature

Bug#573704: gettext: msgunfmt colorizes if stdout is terminal, but does not recognize --color

[Kalle Olavi Niemitalo]

Package: gettext
Version: 0.17-9
Severity: wishlist

If I run this in gnome-terminal:

% msgunfmt /usr/share/locale/fi/LC_MESSAGES/gnome-session-2.0.mo

then msgunfmt makes msgids purple and msgstrs blue, by adding
escape sequences like \033[34m to the output.  However, if I
pipe the output to less, like so:

% msgunfmt /usr/share/locale/fi/LC_MESSAGES/gnome-session-2.0.mo |
  less -R

then I do not get any colors.  Apparently, msgunfmt detects that
stdout is not a terminal.  Such detection is all right but there
should be a way to enable colors regardless.  In ls and git, this
is done with a --color option, but msgunfmt does not support that:

% LANG=C msgunfmt --color /usr/share/locale/fi/LC_MESSAGES/gnome-session-2.0.mo
msgunfmt: unrecognized option '--color'
Try `msgunfmt --help' for more information.

I can instead get the desired result by filtering the output
through msgcat:

% msgunfmt /usr/share/locale/fi/LC_MESSAGES/gnome-session-2.0.mo |
  msgcat --color - |
  less -R

but it seems silly that msgunfmt cannot do this on its own, given
that it already supports colorizing the output to a terminal.

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

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gettext depends on:
ii  dpkg 1.15.5.6Debian package management system
ii  gettext-base 0.17-9  GNU Internationalization utilities
ii  install-info 4.13a.dfsg.1-5  Manage installed documentation in 
ii  libc62.10.2-6Embedded GNU C Library: Shared lib
ii  libcroco30.6.2-1 a generic Cascading Style Sheet (C
ii  libglib2.0-0 2.22.4-1The GLib library of C routines
ii  libgomp1 4.4.2-9 GCC OpenMP (GOMP) support library
ii  libncurses5  5.7+20090803-2  shared libraries for terminal hand
ii  libxml2  2.7.6.dfsg-2+b1 GNOME XML library

Versions of packages gettext recommends:
ii  cvs 1:1.12.13-12 Concurrent Versions System
ii  wget1.12-1.1 retrieves files from the web

Versions of packages gettext suggests:
pn  gettext-doc   none (no description available)

-- no debconf information


pgp7E2Z7XUHPV.pgp
Description: PGP signature

Bug#572749: xserver-xorg: segmentation fault when disconnecting/reconnecting Wacom tablet after hibernation

[Kalle Olavi Niemitalo]

Brice Goglin brice.gog...@ens-lyon.org writes:

 So the crash is reproducible?

So far, it has only happened once here.  I used info symbol and
print/x in gdb to add the symbols to the original backtrace.

I now tried replugging the tablet a dozen times without
hibernation and once with hibernation but the X server did not
crash.

 Please try with xserver-xorg-core 1.7.5-1 then.

Oops, I'd better switch to a more up-to-date mirror.
ftp://ftp.jyu.fi/debian/dists/squeeze/Release is from 17 Feb 2010.


pgpNU8zHFujgz.pgp
Description: PGP signature

Bug#572695: elinks: need an option to select binding address and address family

[Kalle Olavi Niemitalo]

Toni Mueller supp...@oeko.net writes:

 I need an option in elinks to select the address to bind to,
 and to force an address family (eg. one of IPv4 or IPv6 only).

For the latter, please see the connection.try_ipv4 and
connection.try_ipv6 options.

http://elinks.cz/documentation/manpages/elinks.conf.5.html#connection.try_ipv4


pgpdy14q0kCKo.pgp
Description: PGP signature

Bug#572695: elinks: need an option to select binding address and address family

[Kalle Olavi Niemitalo]

Toni Mueller supp...@oeko.net writes:

 thanks for the hint, but: There appears to be no command line switch to
 do it, right?

elinks -eval set connection.try_ipv4 = 0

but if that connects to an existing elinks process, then the
setting will be lost, I think.  So if that is a problem, you may
have to combine the option with -no-connect or -session-ring 2 or
something like that.


pgpUQvxIeUdZt.pgp
Description: PGP signature

Bug#568888: binutils build-dependency for readelf -p still not right

[Kalle Olavi Niemitalo]

Source: xulrunner
Version: 1.9.1.8-3

Mike Hommey gland...@debian.org writes:

* debian/control:
  + Add missing ${misc:Depends}
  + Build-depend on binutils with readelf -p support. Closes: #56.

The build-dependency and the runtime dependency on binutils are now:

   binutils (= 2.18~cvs20070812-1~),

However, the following binutils versions do not support readelf -p,
even though they satisfy the dependencies:

2.18~cvs20070812-1 (tested)
2.18-1 (judging from the source)
2.18.1~cvs20071027-1 (judging from the source)
2.18.1~cvs20071027-2 (judging from the source)
2.18.1~cvs20080103-4 (judging from the source  patches)

Indeed, the upstream binutils-2_18-branch still does not support
readelf -p.  That code is in binutils-2_19-branch and later.

I think binutils 2.18.50.20080507-1 is the first Debian package
that supports readelf -p.  I cannot verify that though, because
I have neither sources nor binaries for that version.


pgpJSCZeY97ac.pgp
Description: PGP signature

Bug#571729: autoconf 2.65 is GPLv3+, but debian/copyright still claims GPLv2+

[Kalle Olavi Niemitalo]

Package: autoconf
Version: 2.65-3
Severity: normal
File: /usr/share/doc/autoconf/copyright

According to NEWS and autoconf --version, autoconf 2.65 is
licensed under GNU GPL version 3 or later, with the Autoconf
Configure Script Exception.  The Debian copyright file however
still claims: This version of Autoconf uses GPLv2+ plus the
above-mentioned exceptions for its installed executables, as
described in COPYING.

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

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages autoconf depends on:
ii  debianutils   3.2.2  Miscellaneous utilities specific t
ii  m41.4.13-3   a macro processing language
ii  perl  5.10.1-9   Larry Wall's Practical Extraction 

Versions of packages autoconf recommends:
ii  automake [automaken]  1:1.11.1-1 A tool for generating GNU Standard

Versions of packages autoconf suggests:
pn  autoconf-archive  none (no description available)
pn  autoconf-doc  none (no description available)
pn  autoconf2.13  none (no description available)
ii  gettext   0.17-8 GNU Internationalization utilities
pn  gnu-standards none (no description available)
ii  libtool   2.2.6b-2   Generic library support script

-- no debconf information


pgpyUH1LDx2uv.pgp
Description: PGP signature

Bug#568686: gnome-settings-daemon wakes up every 4 seconds to probe /usr/X11R6/lib/X11

[Kalle Olavi Niemitalo]

Package: fontconfig-config
Version: 2.8.0-2
Severity: wishlist
File: /etc/fonts/fonts.conf

powertop shows 0.2 wakeups per second from gnome-settings-daemon
2.28.1-2.  strace shows it making this call every 4-5 seconds:

inotify_add_watch(20, /usr/X11R6/lib/X11, 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)

gnome-settings-daemon appears to get the name of that nonexistent
directory from /etc/fonts/fonts.conf, which lists:

dir/usr/share/fonts/dir
dir/usr/X11R6/lib/X11/fonts/dir dir/usr/local/share/fonts/dir
dir~/.fonts/dir

If I remove the dir/usr/X11R6/lib/X11/fonts/dir entry and
restart gnome-settings-daemon, then those wakeups don't happen,
and some power may theoretically be saved.
I suppose an alternative would be to create the directory.

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

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fontconfig-config 2.8.0-2 depends on:
ii  debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii  ttf-dejavu-core   2.30-2 Vera font family derivate with add
ii  ttf-freefont  20090104-5 Freefont Serif, Sans and Mono True
ii  ucf   3.0025 Update Configuration File: preserv

fontconfig-config recommends no packages.

fontconfig-config suggests no packages.

Versions of packages gnome-settings-daemon depends on:
ii  gconf2  2.28.0-1 GNOME configuration database syste
ii  libc6   2.10.2-2 GNU C Library: Shared libraries
ii  libcairo2   1.8.8-2  The Cairo 2D vector graphics libra
ii  libdbus-1-3 1.2.16-2 simple interprocess messaging syst
ii  libdbus-glib-1-20.82-2   simple interprocess messaging syst
ii  libfontconfig1  2.8.0-2  generic font configuration library
ii  libgconf2-4 2.28.0-1 GNOME configuration database syste
ii  libglib2.0-02.22.4-1 The GLib library of C routines
ii  libgnome-desktop-2-11   2.28.2-1 Utility library for loading .deskt
ii  libgnomekbd42.28.2-1 GNOME library to manage keyboard c
ii  libgstreamer-plugins-base0. 0.10.25-7GStreamer libraries from the base
ii  libgstreamer0.10-0  0.10.25-4+b1 Core GStreamer libraries and eleme
ii  libgtk2.0-0 2.18.6-1 The GTK+ graphical user interface 
ii  libnotify1 [libnotify1-gtk2 0.4.5-1  sends desktop notifications to a n
ii  libx11-62:1.3.3-1X11 client-side library
ii  libxi6  2:1.3-2  X11 Input extension library
ii  libxklavier15   4.0-2X Keyboard Extension high-level AP

gnome-settings-daemon recommends no packages.

Versions of packages gnome-settings-daemon suggests:
ii  gnome-screensaver 2.28.0-2   GNOME screen saver and locker
ii  metacity [x-window-manager]   1:2.28.0-3 lightweight GTK+ window manager
ii  twm [x-window-manager]1:1.0.4-2  Tab window manager
ii  x11-xserver-utils 7.5+1  X server utilities

-- debconf information:
  fontconfig/subpixel_rendering: Automatic
  fontconfig/enable_bitmaps: false
  fontconfig/hinting_type: Native


pgpaOqyWK9WIS.pgp
Description: PGP signature

Bug#550888: elinks does not recognize Cache-Control response headers

[Kalle Olavi Niemitalo]

Jan Braun janbr...@gmx.de writes:

 [3] RFC 3986, section 3.5:

Thanks for the pointer.  Section 4.4 (Same-Document Reference)
actually seems more relevant.


pgpxTdcL4PzMn.pgp
Description: PGP signature