Bug#1053502: More info on the failing script

[Kalle Kivimaa]

For me the postinst failed in the multi-sed at # Set custom settings in 
settings_local.py

The failing part is the second expression doing ADMINS, which expaned as:

-e /^ADMINS = ($/,/^)$/{s|'root@localhost
 ('Kalle Kivimaa', 'kalle.kivi...@iki.fi'),'|'root@localhost’|}

If I simply removed this -e expression the dpkg-configure finished fine.

--
Kalle Kivimaa
+358-40-5007717

Bug#1034467: debian-faq: difficulties understanding the concept of stable-updates from the docs

[kalle]

On Sun, 2023-04-16 at 08:18 +0200, Joost van Baal-Ilić wrote:
> Do you maybe have the time to come up
> with a suggested text to put in e.g. the FAQ?

I would take the time. But I do not esteem myself trying to figure out
the mechanisms as being an efficient endeavour right now.
I will probably give in some suggested text, should I come to more
knowledge about this. 

greetings,
kalle

Bug#1029802: ITP: cloudflare-go -- Go library for the Cloudflare v4 API

[Kalle M. Aagaard]

Package: wnpp
Severity: wishlist
Owner: Kalle M. Aagaard 

* Package name: cloudflare-go
  Version : 0.59.0-1
  Upstream Author : Cloudflare
* URL : https://github.com/cloudflare/cloudflare-go
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go library for the Cloudflare v4 API

 cloudflare-go
 .
 Go Reference (https://pkg.go.dev/github.com/cloudflare/cloudflare-go)
 [Image: Test] (https://github.com/cloudflare/cloudflare-
 go/workflows/Test/badge.svg) Go Report Card
 (https://goreportcard.com/report/github.com/cloudflare/cloudflare-go)
 .
  | **Note**: This library is under active development as we expand it to
  | cover
  | our (expanding!) API. Consider the public API of this package a
 little
  | unstable as we work towards a v1.0.
 .
 A Go library for interacting with Cloudflare's API v4
 (https://api.cloudflare.com/). This library allows you to:
 .
  * Manage and automate changes to your DNS records within Cloudflare
  * Manage and automate changes to your zones (domains) on Cloudflare,
including
adding new zones to your account
  * List and modify the status of WAF (Web Application Firewall) rules
for your
zones
  * Fetch Cloudflare's IP ranges for automating your firewall
whitelisting
 .
 A command-line client, flarectl (/cmd/flarectl), is also available as
 part of this project.
 .
 Features
 .
 The current feature list includes:
 .
  [x] Cache purging
  [x] Cloudflare IPs
  [x] Custom hostnames
  [x] DNS Firewall
  [x] DNS Records
  [x] Firewall (partial)
  [x] Gateway Locations
  [x] Keyless SSL (https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-
  technical-details/)
  [x] Load Balancing (https://blog.cloudflare.com/introducing-load-
  balancing-intelligent-failover-with-cloudflare/)
  [x] Logpush Jobs (https://developers.cloudflare.com/logs/logpush/)
  [x] Magic Transit / Magic WAN
  [x] mTLS Certificate Store
  [x] Notifications
  [ ] Organization Administration
  [x] Origin CA (https://blog.cloudflare.com/universal-ssl-encryption-all-the-
  way-to-the-origin-for-free/)
  [x] Railgun (https://www.cloudflare.com/railgun/) administration
  [x] Rate Limiting
  [x] User Administration (partial)
  [x] Web Application Firewall (WAF)
  [x] Workers KV
  [x] Zone cache settings
  [x] Zone Lockdown and User-Agent Block rules
  [x] Zones
  [x] Managed Headers
 .
 Pull Requests are welcome, but please open an issue (or comment in an
 existing issue) to discuss any non-trivial changes before submitting
 code.
 .
 Installation
 .
 You need a working Go environment. We officially support only currently
 supported Go versions according to Go project's release policy
 (https://go.dev/doc/devel/release#policy).
 .
   go get github.com/cloudflare/cloudflare-go
 .
 Getting Started
 .
   package main
 .
   import (
"context"
"fmt"
"log"
"os"
 .
"github.com/cloudflare/cloudflare-go"
   )
 .
   func main() {
// Construct a new API object using a global API key
api, err := cloudflare.New(os.Getenv("CLOUDFLARE_API_KEY"),
 os.Getenv("CLOUDFLARE_API_EMAIL"))
// alternatively, you can use a scoped API token
// api, err :=
 cloudflare.NewWithAPIToken(os.Getenv("CLOUDFLARE_API_TOKEN"))
if err != nil {
log.Fatal(err)
}
 .
// Most API calls require a Context
ctx := context.Background()
 .
// Fetch user details on the account
u, err := api.UserDetails(ctx)
if err != nil {
log.Fatal(err)
}
// Print user details
fmt.Println(u)
 .
// Fetch the zone ID
id, err := api.ZoneIDByName("example.com") // Assuming example.com
 exists in your Cloudflare account already
if err != nil {
log.Fatal(err)
}
 .
// Fetch zone details
zone, err := api.ZoneDetails(ctx, id)
if err != nil {
log.Fatal(err)
}
// Print zone details
fmt.Println(zone)
   }
 .
 Also refer to the API documentation
 (https://pkg.go.dev/github.com/cloudflare/cloudflare-go) for how to use
 this package in-depth.
 .
 Experimental improvements
 .
 This library is starting to ship with experimental improvements that are
 not yet ready for production but will be introduced before the next
 major version. See experimental README (/docs/experimental.md) for full
 details.
 .
 License
 .
 BSD licensed. See the (/LICENSE) file for details.

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#1019350: gnome-terminal: "Select All" merely selects the visible part of terminal contents

[kalle]

Package: gnome-terminal
Version: 3.44.1-1
Severity: normal

Dear Maintainer,

when using the terminal to solve a problem or to perform some other rather
complex operation that cannot be described with a few sentences, I would like
to be able to save the complete terminal contents to a file for reference in
case I have to perform that same operation on a different machine.
"Copy as HTML" is especially nice because colors are preserved.

But sadly, "Select All" doesn't select the full contents of the scrollback
buffer as you would expect, but merely what is currently visible.

Well, you can select everything using the mouse, but this would be a pain for a
huge number of lines.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-2
ii  dbus-x11 [dbus-session-bus]   1.14.0-2
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gnome-terminal-data   3.44.1-1
ii  gsettings-desktop-schemas 43~alpha-1
ii  libatk1.0-0   2.38.0-1
ii  libc6 2.34-7
ii  libdconf1 0.40.0-3
ii  libgcc-s1 12.2.0-1
ii  libglib2.0-0  2.73.3-3
ii  libgtk-3-03.24.34-3
ii  libpango-1.0-01.50.9+ds-1
ii  libstdc++612.2.0-1
ii  libuuid1  2.38.1-1
ii  libvte-2.91-0 0.69.99-1
ii  libx11-6  2:1.8.1-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.2-2
ii  nautilus-extension-gnome-terminal  3.44.1-1
ii  yelp   42.1-2

gnome-terminal suggests no packages.

-- no debconf information

Bug#990831: $OPTIND issue solved in bash 5.1-2+b3

[kalle]

Dear maintainer,

With bash 5.1-2+b3, the output of
getopts abc opt hello; EC=$?; echo $opt $OPTIND $EC is
y 1 1

The value of $OPTIND is correct now.

But as already mentioned, $opt == x was strange, and the same holds for 
$opt == y now.


The bash manual states that if the first non-option arg is encountered, 
opt is set to ?,

so this is another bug.

For me, it's irrelevant since I don't use the value of $opt after 
getopts has exited with a non-zero exit value,

but maybe it's relevant to others.

Bug#990831: getopts: $OPTIND == 2 although no option arg supplied.

[kalle]

Package: bash
Version: 5.1-2+b2
Severity: important

Dear maintainer,

With bash 5.1-2+b2, the output of

getopts abc opt hello; EC=$?; echo $opt $OPTIND $EC

is

x 2 1

$EC == 1 is correct, $opt == x is strange but irrelevant, but $OPTIND == 2 is
not the
index of the first non-option arg, the correct value is 1.
This corrupts all my scripts which use shift $((OPTIND - 1)) to process the
non-option args.

After downgrading to bash 5.0-4, the output of the above command is

x 1 1

as it should be.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   11.1
ii  debianutils  4.11.2
ii  libc62.31-12
ii  libtinfo66.2+20201114-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2

Versions of packages bash suggests:
pn  bash-doc  

Bug#958462: amavis hits ALL_TRUSTED for milter connections

[Kalle Kaljuste]

Can confirm that the patch also works with the debian-based sendmail -
amavisd-milter - amavisd-new - SA setup.

The consequence of triggering ALL_TRUSTED was that SA skipped all the
RBL lookups.

Bug#921194: amarok: Amarok depends on libmariadbd18, which doesn't exist any longer

[Kalle Michanek]

Package: amarok
Version: 2.9.0-1+b1
Severity: normal
Tags: a11y

Dear Maintainer,

libmariadbd18 does not exist any longer, but Amarok still depends on it. This 
would make Amarok uninstallable unless
one has installed it from other sources or has kept it from when it was 
available in the repos.

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

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

Versions of packages amarok depends on:
ii  amarok-common2.9.0-1
ii  amarok-utils 2.9.0-1+b1
ii  kde-runtime  4:17.08.3-2
ii  libavcodec58 10:4.1-dmo4
ii  libavformat5810:4.1-dmo4
ii  libavutil56  10:4.1-dmo4
ii  libc62.28-5
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libgl1   1.1.0-1
ii  libglib2.0-0 2.58.2-3
ii  libgpod4 0.8.3-13
ii  libkcmutils4 4:4.14.38-3
ii  libkdecore5  4:4.14.38-3
ii  libkdeui54:4.14.38-3
ii  libkdewebkit54:4.14.38-3
ii  libkdnssd4   4:4.14.38-3
ii  libkfile44:4.14.38-3
ii  libkio5  4:4.14.38-3
ii  libknewstuff3-4  4:4.14.38-3
ii  libktexteditor4  4:4.14.38-3
ii  liblastfm1   1.0.9-1
ii  libmariadbclient18 [libmariadbclient18]  1:10.3.12-2
ii  libmariadbd181:10.1.37-3
ii  libmtp9  1.1.16-1
ii  libofa0  0.9.3-19
ii  libphonon4   4:4.10.2-1
ii  libplasma3   4:4.14.38-3
ii  libqca2  2.1.3-2
ii  libqjson00.8.1-3+b1
ii  libqt4-dbus  4:4.8.7+dfsg-17
ii  libqt4-network   4:4.8.7+dfsg-17
ii  libqt4-opengl4:4.8.7+dfsg-17
ii  libqt4-script4:4.8.7+dfsg-17
ii  libqt4-scripttools   4:4.8.7+dfsg-17
ii  libqt4-sql   4:4.8.7+dfsg-17
ii  libqt4-svg   4:4.8.7+dfsg-17
ii  libqt4-xml   4:4.8.7+dfsg-17
ii  libqtcore4   4:4.8.7+dfsg-17
ii  libqtgui44:4.8.7+dfsg-17
ii  libqtscript4-core0.2.0-1+b1
ii  libqtscript4-gui 0.2.0-1+b1
ii  libqtscript4-network 0.2.0-1+b1
ii  libqtscript4-sql 0.2.0-1+b1
ii  libqtscript4-uitools 0.2.0-1+b1
ii  libqtscript4-xml 0.2.0-1+b1
ii  libqtwebkit4 2.3.4.dfsg-10
ii  libsolid44:4.14.38-3
ii  libstdc++6   8.2.0-15
ii  libthreadweaver4 4:4.14.38-3
ii  libx11-6 2:1.6.7-1
ii  phonon   4:4.10.2-1

Versions of packages amarok recommends:
pn  clamz
pn  kio-audiocd  

Versions of packages amarok suggests:
pn  amarok-doc 
ii  libqt4-sql-mysql   4:4.8.7+dfsg-17
pn  libqt4-sql-psql
ii  libqt4-sql-sqlite  4:4.8.7+dfsg-17
pn  moodbar

Versions of packages amarok-common depends on:
ii  perl  5.28.1-3

amarok-common recommends no packages.

Versions of packages amarok is related to:
ii  phonon-backend-gstreamer [phonon-backend]  4:4.9.0-1

-- no debconf information

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 <sthiba...@debian.org> 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#803696: obnam: breaks on "No such device or address" looking for CACHEDIR.TAG in sshfs mount

[Kalle Sandström]

Package: obnam
Version: 1.17-1
Severity: important
Tags: upstream

Dear Maintainer,

Error message:

00h00m05s 1 files 0 B scanned: scanning for files in /home/${USERNAME}ERROR: 
RCE08AX: I/O error: /home/${USERNAME}/sshfs/CACHEDIR.TAG: 6: No such device or 
address

(variables inserted.)

This is clearly caused by sshfs not being an ordinary filesystem, and therefore
reporting (incorrectly) an ENODEV when it should report ENOENT. However, obnam
is at fault for crapping out instead of proceeding.

Fixed by rolling back to version 1.8.


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

Kernel: Linux 4.1.2+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages obnam depends on:
ii  libc6 2.19-19
ii  python2.7.9-1
ii  python-cliapp 1.20140719-1
ii  python-fuse   2:0.2.1-10
ii  python-larch  1.20131130-1
ii  python-paramiko   1.10.1-1
ii  python-tracing0.8-1
ii  python-ttystatus  0.23-1
ii  python-yaml   3.11-2+b1

obnam recommends no packages.

obnam suggests no packages.

-- no debconf information

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 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#794065: kannel: run_kannel_box prevents logging of kannel.conf errors

[Kalle Niemitalo]

Jonas Smedegaard d...@jones.dk writes:

 Right.  I am aware but consider that an emergency feature.

I would think run_kannel_box and --parachute are themselves emergency features.

 I am not yet comfortable writing systemd init scripts, so would myself 
 just rely on its ability to use legacy sysvinit scripts.  If you wanna 
 also make draft systemd scripts then that's certainly appreciated but 
 not really needed IMO.

Although I build Kannel from a source tree based on your Debian sources,
we actually run it on Ubuntu 14.04 LTS with Upstart.  Job configuration
files for that would therefore be more useful to us.  I guess you won't
want to spend time on them though, now that Ubuntu too has switched to
systemd.


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

Bug#794609: kannel-dev: missing dependency on freetds-dev

[Kalle Niemitalo]

Package: kannel-dev
Version: 1.4.4-1

kannel-dev does not declare a dependency on freetds-dev.  However,
kannel-dev includes /usr/bin/gw-config, and gw-config --libs outputs:

-L/usr/lib/kannel -lgw -lwap -lgwlib -lpq -lmysqlclient_r -lssl -ldl -lpam 
-lpcreposix -lrt -lresolv -lnsl -lm  -lpthread -lxml2 -lpcreposix -lpcre 
-L/usr/lib -lcrypto -lssl -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread 
-lz -lm -ldl -L/usr/local/lib -lsqlite -L/usr/local/lib -lsqlite3 
-L/usr/lib/x86_64-linux-gnu -L/usr/lib -lhiredis -L/usr/lib -lct

The -lct argument refers to /usr/lib/x86_64-linux-gnu/libct.so, which is
in the freetds-dev package.

So if you try to build a trivial program

int main(void)
{
return 0;
}

against $(gw-config --cflags) and $(gw-config --libs) without installing
freetds-dev, you get an error:

/usr/bin/ld: cannot find -lct
collect2: error: ld returned 1 exit status

It looks like kannel-dev should depend on freetds-dev, then.


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

Bug#794065: [Pkg-kannel-devel] Bug#794065: kannel: run_kannel_box prevents logging of kannel.conf errors

[Kalle Niemitalo]

Jonas Smedegaard d...@jones.dk writes:

 Oh my... Do you know if upstream is already aware of that issue?

I found these in redmine:

  https://redmine.kannel.org/issues/116
  run_kannel_box should be deprecated in favor of --parachute

  https://redmine.kannel.org/issues/69
  Patch to provide syslog support to run_kannel_box

and from mailing lists:

  http://article.gmane.org/gmane.comp.mobile.kannel.user/10727
  Subject: RE: disable output to stdout

  http://article.gmane.org/gmane.comp.mobile.kannel.devel/24815
  Subject: Re: run_kannel_box - forcing umask to be 077
  please stop using run_kannel_box because it's deprecated

 It might be as simple as commenting out line run_kannel_box.c line 393 
 (calling rebind_standard_streams() ), but I would love someone else than 
 me to hack it - someone more fluent in C and knows the details of what 
 exactly is needed to spawn a background process reliably.  You, perhaps?

Because run_kannel_box is apparently deprecated, I don't think
I should spend my employer's time on improving it.

 I don't like the for any reason - I can imagine sane reasons for dying 
 that shouldn't be turned into init system looping like crazy.

sysvinit is able to respawn processes listed in /etc/inittab if they
die, and there is a respawning too fast: disabled for %d minutes
limit.  This respawn feature of sysvinit is normally used only for
getty and sulogin, but the equivalent feature of Upstart seems to be
used for pretty much any service one wants to keep running.  I'm not
familiar with systemd but I imagine it too has something similar.

 Makes sense to leak passwords at debug-grade verbosity levels.

 If code leaks passwords at less verbose levels, we should patch that 
 (and make upstream aware).

 If default config/init sets debug-grade verbosity we should fix that.

 Other than that we can perhaps add comment in config file to warn about 
 such leakage when raising verbosity.

OK.  Currently though, the files in /var/log/kannel are not
world-readable, so writing passwords there is not too bad.

 An, would you like to join the Debian Kannel 
 team and collaborate directly on maintaining this package?

I'd rather not.  I intend to stop fixing Kannel bugs when I get it
working sufficiently well in my employer's environment.


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

Bug#717728: [PATCH] Use sqlite3_libversion(), not sqlite3_version[].

[Kalle Niemitalo]

My local Kannel 1.4.4 sources now have 18 patches in debian/patches/.
I am managing them with gbp pq.  Unfortunately, gbp pq import in
git-buildpackage 0.6.9 does not recognize the DEP-3 Description and
Author headers, because it uses git mailinfo.  I have therefore
reformatted the metadata of my patch in the following way, which I
believe still complies with DEP-3.  If you too can switch to this
format, there is a small chance it might help me merge changes from
Debian in the future.  I'm not sure what to do about patch numbers in
file names though -- they cannot match because 32_va-start-non-null.patch
is neither applicable nor required in Kannel 1.4.4.

From: Kalle Niemitalo kalle.niemit...@procomp.fi
Date: Tue, 9 Jun 2015 19:37:17 +0300
Subject: sqlite3: Use sqlite3_libversion, not sqlite3_version

Using sqlite3_version[] causes a has different size in shared object
warning at run time if the length of the version number has changed
in the sqlite3 shared library.  It is not clear whether anything
worse will happen in addition to the warning, but we can avoid the
problem altogether by calling sqlite_libversion() instead.

Bug-Debian: http://bugs.debian.org/717728
Last-Update: 2015-06-09
---
 gwlib/dbpool_sqlite3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gwlib/dbpool_sqlite3.c b/gwlib/dbpool_sqlite3.c
index 71e31f2..b735b08 100644
--- a/gwlib/dbpool_sqlite3.c
+++ b/gwlib/dbpool_sqlite3.c
@@ -86,7 +86,7 @@ static void *sqlite3_open_conn(const DBConf *db_conf)
 }
 
 info(0, SQLite3: Opened or created database file `%s'., 
octstr_get_cstr(conf-file));
-info(0, SQLite3: library version %s., sqlite3_version);
+info(0, SQLite3: library version %s., sqlite3_libversion());
 
 return db;
 

Bug#766215: allow to turn off sslv3 to close POODLE vulnerability in kannel

[Kalle Niemitalo]

Jonas Smedegaard d...@jones.dk writes:

 Assuming your analysis is correct, it seems to me that best way forward 
 would be to suggest upstream to have a configuration option to pass 
 flags to OpenSSL.  Would either of you do that?

I do not intend to forward this bug upstream.


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

Bug#794065: kannel: run_kannel_box prevents logging of kannel.conf errors

[Kalle Niemitalo]

Package: kannel
Version: 1.4.3-2+b2
Severity: normal

Jonas Smedegaard d...@jones.dk writes in Bug#590544:

 I don't know if Kannel not already spits out sensible errors in log 
 messages, but if not then yes, that's a good suggestion to pass 
 upstream.

Regarding errors in log messages

If there is an error in /etc/kannel/kannel.conf (e.g. if it tries to set
a configuration variable that Kannel does not support), then bearerbox
fails not start, but the error message is not logged anywhere in
/var/log.  This makes the configuration error difficult to find and fix.

strace shows that bearerbox tries to write error messages to stderr
but gets ENOSPC because run_kannel_box has redirected fd 2 to /dev/full.

As a workaround, one can run bearerbox in a tty and see the error
messages that way.  However, that requires a cumbersome invocation of
sudo or su if one wants the bearerbox process to get the same uid and
gid as when started from the init script.

If you're going to revise the init scripts, then perhaps you can get rid
of run_kannel_box altogether and instead have the init system (systemd
or whatever) restart the boxes if they die for any reason.  That way,
the init system would also be in a position to log the signal that
killed the process.

There Kannel boxes can be configured to write their messages to syslog,
but AFAIK that requires setting the syslog-level variable in
kannel.conf, so it won't help if the problem is with kannel.conf itself.
Also, the messages written to /var/log/kannel/ often appear to include
passwords, so I'm wary of writing them to syslog.


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

Bug#590544: sensible handling of values in /etc/default/kannel

[Kalle Niemitalo]

Jonas Smedegaard d...@jones.dk writes:

 Might make sense to then split into multiple binary packages, one for 
 each daemon, but that could be done as a separate step later.

Separating the daemons to different packages seems a bit risky because,
if the versions of smsbox and bearerbox do not match and gw/msg-decl.h
has been changed between the versions, then the boxes will not be able
to parse the messages sent by each other.  So you might have to set
up versioned dependencies.

OTOH it is already possible, and perhaps even typical, to run the boxes
on different computers, in which case package dependencies cannot
prevent version mismatches.  And if the administrator searches the Web
for Msg packet was invalid., then it'll be pretty clear that a version
mismatch is the likely reason.  So the risk doesn't seem too bad.

I suppose it could be helpful to explicitly check the version at the
beginning of each connection and log an error blaming the administrator,
but that would be an upstream issue.


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

Bug#648084: kannel: git repository disagrees with the uploaded source package

[Kalle Niemitalo]

Niels Thykier ni...@thykier.net writes:

 I wanted to write a patch for the missing build-arch/build-indep
 targets in kannel.  But on closer examination, it turns out that
 the git repository and the last uploaded packages seems to be
 disagreeing on contents/version.

 Below is the diff between the changelog of the source package and
 the git repository.  It appears that the git version has the
 targets I wanted to add as a patch, so kudos if you keep at least
 that part.  :D

The debian/rules git gets the build-arch and build-indep targets from
cdbs, but the build-indep target still compiles the C code too:

* build-indep depends on build/kannel-docs;
  /usr/share/cdbs/1/rules/buildcore.mk defines it like this:
  build-indep: $(patsubst %,build/%,$(DEB_INDEP_PACKAGES))

* build/kannel-docs depends on common-build-indep;
  /usr/share/cdbs/1/rules/buildcore.mk defines it like this:
  $(patsubst %,build/%,$(DEB_INDEP_PACKAGES)) :: build/% : common-build-indep 
configure/%

* common-build-indep depends on $(cdbs_make_build_stamps);
  /usr/share/cdbs/1/class/makefile.mk defines it like this:
  common-build-arch common-build-indep:: $(cdbs_make_build_stamps)

* $(cdbs_make_build_stamps) expands to debian/stamp-makefile-build

* $(cdbs_make_build_stamps) has a rule in
  /usr/share/cdbs/1/class/makefile.mk.  It runs:
+$(DEB_MAKE_INVOKE) $(DEB_MAKE_BUILD_TARGET)
touch $@

* $(DEB_MAKE_INVOKE) expands to make  -C . 

* $(DEB_MAKE_BUILD_TARGET) expands to 

So in the end, make -C . is run and builds the whole thing.
The same happens with the build-arch target.

It seems this can be partially fixed by defining DEB_MAKE_BUILD_TARGET
= dummy in debian/rules.  There is already a suitable dummy target in
Makefile.  The rules for debian/stamp-makefile-build would then just
update .depend, which doesn't take very long.  However, when that
finishes, the build system would build the targets listed in
DEB_MAKE_INSTALL_TARGET, and that includes install, which depends on
all, which always builds the C code and also builds the documents
if $(DOCSTARGET) is docs.

I don't understand how cdbs expects this to be implemented.


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

Bug#688656: Duplicate function main while linking

[Kalle Niemitalo]

Michael Tautschnig m...@debian.org writes:

 The package build process produces an archive libwmlscript.a as follows:

 ar rc libwmlscript.a wmlscript/wmlsc.o ...

 with wmlsc already containing a main function. Subsequently libwmlscript.a 
 is
 linked to multiple object files containing their own main function (including
 wmlscript/wmlsc.o, again), which leads to duplicate definitions of main, and
 thus undefined behaviour as the linker is free to pick either of them.

I don't believe there is undefined behaviour in this case.
Details below.  Regardless, fixing this would make the sources
easier to understand.

The linker does not link all the members of libwmlscript.a into
the output file, only those that satisfy undefined references.
So although libwmlscript.a(wmlsc.o) and libwmlscript.a(wmlsdasm.o)
both define a main function, the linker links neither of those
because it already has a main function from the wmlsc.o that was
specified in the command line, and those members do not satisfy
any other undefined references either.

libwmlscript.a(wmlsdasm.o) also defines a lookup_function symbol.
If you add the -Wl,--undefined=lookup_function option to the gcc
command that links wmlscript/wmlsc from wmlscript/wmlsc.o,
libwmlscript.a, and other archives, then the linker will link
libwmlscript.a(wmlsdasm.o) in order to satisfy the reference to
lookup_function.  That then causes an error:

libwmlscript.a(wmlsdasm.o): In function `main':
/home/kalle/build/kannel/wmlscript/wmlsdasm.c:98: multiple definition of `main'
wmlscript/wmlsc.o:/home/kalle/build/kannel/wmlscript/wmlsc.c:115: first defined 
here
collect2: error: ld returned 1 exit status

Because that error does not normally occur during the build, I think it
is clear that the linker normally links neither libwmlscript.a(wmlsc.o)
nor libwmlscript.a(wmlsdasm.o) into the output file wmlscript/wmlsc.

If you instead removed wmlscript/wmlsc.o from the command line,
then the linker would try to find a main function in the archives,
and I think it could choose either libwmlscript.a(wmlsc.o) or
libwmlscript.a(wmlsdasm.o).  I think that would be undefined behaviour.


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

Bug#788816: /etc/kannel/kannel.conf usually contains passwords, should not be world-readable

[Kalle Niemitalo]

Package: kannel
Version: 1.4.3-2
Severity: wishlist

/etc/kannel/kannel.conf usually contains passwords, for the http admin
interface and SMSC communications.  The kannel package installs this
file and directory with the following permissions:

drwxr-xr-x 2 root root 4096 Jun 15 12:57 /etc/kannel
-rw-r--r-- 1 root root  536 Feb  6  2010 /etc/kannel/kannel.conf

Thus, all users and daemons of the server can read the passwords from
this file.  I'd like to protect the passwords so that only Kannel and
root can read them.  Although I can use include= to make Kannel read
the passwords from a separate file, that does not solve the problem
because the permissions issues shown below would then apply to that file.

If I remove the other access permissions from the file, like this:

drwxr-xr-x 2 root root 4096 Jun 15 12:57 /etc/kannel
-rw-r- 1 root root  536 Feb  6  2010 /etc/kannel/kannel.conf

then bearerbox and wapbox won't start, because they run as
kannel:nogroup and therefore cannot read kannel.conf.

If I also make Kannel own the file, like this:

drwxr-xr-x 2 root   root 4096 Jun 15 12:57 /etc/kannel
-rw-r- 1 kannel root  536 Feb  6  2010 /etc/kannel/kannel.conf

then Kannel will start OK.  However, this configuration gives Kannel
write access to /etc/kannel/kannel.conf, which violates the principle
of least privilege.

I have therefore created also a kannel group, made it the default
group of the kannel user so that Kannel runs as kannel:kannel, and
changed the permissions as follows:

drwxr-sr-x 2 root kannel 4096 Jun 15 12:57 /etc/kannel
-rw-r- 1 root kannel  536 Feb  6  2010 /etc/kannel/kannel.conf

I would like this configuration to be made the default.
I kept the /etc/kannel directory world-readable so that I still
get tab completion for sudo nano /etc/kannel/kannel.conf.

The same effect could also be achieved with ACLs, but I think those
would be more difficult for system administrators to understand because
ls -l does not show the full ACL and one has to use chacl -l or getfacl
instead.


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

Bug#788335: kannel: wrong license in the copyright file

[Kalle Niemitalo]

Package: kannel
Version: 1.4.3-2
Severity: serious
Justification: Policy 12.5

The LICENSE file of the Kannel source tree contains The Kannel Software
License, Version 1.0, which includes some restrictions on the use of the
Kannel name.  However, /usr/share/doc/kannel/copyright in the binary
package is a different license that does not mention these restrictions.

The upstream developers apparently relicensed Kannel in November 2003:
https://redmine.kannel.org/projects/kannel/repository/revisions/3938

Please update the copyright file in the Debian package.

Bug#788335: [PATCH] Update debian/copyright from LICENSE.

[Kalle Niemitalo]

Bug-Debian: http://bugs.debian.org/788335
---

This patch is meant to apply on top of the changes that I posted
to Bug#786747 new upstream stable version Kannel 1.4.4.

 debian/changelog |  1 +
 debian/copyright | 86 +++-
 2 files changed, 55 insertions(+), 32 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 0e52ab1..d60a31d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -17,6 +17,7 @@ kannel (1.4.4-0~procomp1) UNRELEASED; urgency=low
 + Include /usr/bin/decode_emimsg in the kannel package.
 + Although the sqlbox and opensmppbox add-ons are now part of the
   source tree, this version of the packaging does not build them.
+  * Update debian/copyright from LICENSE. Closes: bug#788335.
 
  --
 
diff --git a/debian/copyright b/debian/copyright
index 16f8e21..b3864ae 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -5,35 +5,57 @@ This is Kannel, originally packaged for Debian by Lars 
Wirzenius
 Original author is the Kannel project, see http://www.kannel.org,
 run by Wapit Ltd, see http://www.wapit.com.
 
-Copyright (c) 1998 WAPIT OY LTD.
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-1. Redistributions of source code must retain the above copyright notice,
-this list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in the
-documentation and/or other materials provided with the distribution.
-
-3. All advertising materials mentioning features or use of this software
-must display the following acknowledgement: This product includes software
-developed by WAPIT OY LTD.
-
-4. The name of the author may not be used to endorse or promote products
-derived from this software without specific prior written permission.
-
-
-THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
-IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
-IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
-INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
-BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
-USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
-ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ 
+The Kannel Software License, Version 1.0 
+
+Copyright (c) 2001-2014 Kannel Group  
+Copyright (c) 1998-2001 WapIT Ltd.   
+All rights reserved. 
+
+Redistribution and use in source and binary forms, with or without 
+modification, are permitted provided that the following conditions 
+are met: 
+
+1. Redistributions of source code must retain the above copyright 
+   notice, this list of conditions and the following disclaimer. 
+
+2. Redistributions in binary form must reproduce the above copyright 
+   notice, this list of conditions and the following disclaimer in 
+   the documentation and/or other materials provided with the 
+   distribution. 
+
+3. The end-user documentation included with the redistribution, 
+   if any, must include the following acknowledgment: 
+  This product includes software developed by the 
+   Kannel Group (http://www.kannel.org/). 
+   Alternately, this acknowledgment may appear in the software itself, 
+   if and wherever such third-party acknowledgments normally appear. 
+
+4. The names Kannel and Kannel Group must not be used to 
+   endorse or promote products derived from this software without 
+   prior written permission. For written permission, please  
+   contact o...@kannel.org. 
+
+5. Products derived from this software may not be called Kannel, 
+   nor may Kannel appear in their name, without prior written 
+   permission of the Kannel Group. 
+
+THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 
+OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED.  IN NO EVENT SHALL THE KANNEL GROUP OR ITS CONTRIBUTORS 
+BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,  
+OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT  
+OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR  
+BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,  
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE  
+OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,  
+EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

Bug#786747: new upstream stable version Kannel 1.4.4

[Kalle Niemitalo]

I have been working on packaging Kannel 1.4.4 for my employer.
My 1.4.4 packages are currently based on a combination of:

* The Debian kannel 1.4.3-2 source package.
* Commit f06eabdb677ffe76df1fa99ded318e72ac1435a5 (2013-04-18)
  at git://git.debian.org/git/collab-maint/kannel.git
  (see also Bug#648084 kannel: git repository disagrees with the
  uploaded source package).
* Upstream gateway-1.4.4.tar.gz, which I imported to the upstream
  and pristine-tar branches.  I omitted the debian directory
  from the upstream branch but not from kannel_1.4.4.orig.tar.gz,
  which then is exactly the same as gateway-1.4.4.tar.gz.
* Several local patches, some of which fix Debian bugs.

debian/changelog currently looks like this:

kannel (1.4.4-0~procomp1) UNRELEASED; urgency=low

  [ Jonas Smedegaard ]
  * Drop README.Debian: Contained only outdated or superfluous info.
  * Ease building with git-buildpackage:
+ Git-ignore quilt .pc dir.
+ Add source local-options.
  * Drop old no longer used clutch from rules file.
  * Rewrite rules file using CDBS.
  * Build-depend on cdbs.
  
  [ Kalle Niemitalo ]
  * New upstream release. Closes: bug#786747.
+ Remove debian/patches/32_va-start-non-null.patch, applied upstream.
+ Build-depend on docbook-xml and sgml-data, rather than docbook.
+ Configure with XML_DCL=/usr/share/xml/declaration/xml1n.dcl.
+ Include /usr/bin/decode_emimsg in the kannel package.
+ Although the sqlbox and opensmppbox add-ons are now part of the
  source tree, this version of the packaging does not build them.
  * Update debian/copyright from LICENSE. Closes: bug#788335.
  * If $START_WAPBOX or $START_SMSBOX is defined but the value is not 1,
then don't start that box. Closes: bug#590544.
  * Add patch 34 to use sqlite3_libversion(). Closes: bug#717728.
  * Enable FreeTDS support, needed for DLR storage in Microsoft SQL Server.
+ Add patch 35 to recognize dead database connections.
  * Remove soap/Makefile when cleaning the source directory.

 -- Kalle Niemitalo kalle.niemit...@procomp.fi  Wed, 10 Jun 2015 15:02:24 
+0300

I intend to file most of the patches to the relevant Debian bugs,
and I have permission to do this from my employer.

Here is the patch needed for building 1.4.4.
First merge the Debian 1.4.3-2 sources with collab-maint/kannel.git
and gateway-1.4.4.tar.gz as described above, then apply this patch.
You will probably want to change the version number in debian/changelog.

---
 debian/changelog  | 11 ++-
 debian/control|  2 +-
 debian/kannel.install |  1 +
 debian/patches/32_va-start-non-null.patch | 21 -
 debian/patches/series |  1 -
 debian/rules  |  3 ++-
 6 files changed, 14 insertions(+), 25 deletions(-)
 delete mode 100644 debian/patches/32_va-start-non-null.patch

diff --git a/debian/changelog b/debian/changelog
index 7257b69..0e52ab1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-kannel (1.4.3-3) UNRELEASED; urgency=low
+kannel (1.4.4-0~procomp1) UNRELEASED; urgency=low
 
   [ Jonas Smedegaard ]
   * Drop README.Debian: Contained only outdated or superfluous info.
@@ -8,6 +8,15 @@ kannel (1.4.3-3) UNRELEASED; urgency=low
   * Drop old no longer used clutch from rules file.
   * Rewrite rules file using CDBS.
   * Build-depend on cdbs.
+  
+  [ Kalle Niemitalo ]
+  * New upstream release. Closes: bug#786747.
++ Remove debian/patches/32_va-start-non-null.patch, applied upstream.
++ Build-depend on docbook-xml and sgml-data, rather than docbook.
++ Configure with XML_DCL=/usr/share/xml/declaration/xml1n.dcl.
++ Include /usr/bin/decode_emimsg in the kannel package.
++ Although the sqlbox and opensmppbox add-ons are now part of the
+  source tree, this version of the packaging does not build them.
 
  --
 
diff --git a/debian/control b/debian/control
index 2e58937..e570393 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Paul Dwerryhouse p...@dwerryhouse.com.au
 Uploaders: Jonas Smedegaard d...@jones.dk
 Build-Depends: cdbs (= 0.4.53), debhelper ( 7.0.0), libxml2-dev, libssl-dev 
(= 0.9.8), openssl, libmysqlclient-dev | libmysqlclient15-dev, libsqlite0-dev, 
sqlite, libsqlite3-dev, sqlite3, libpq-dev, libpam0g-dev, autoconf, automake, 
autotools-dev, libpcre3-dev
-Build-Depends-Indep: docbook-dsssl, jadetex, transfig, imagemagick, 
ghostscript, jade, docbook
+Build-Depends-Indep: docbook-dsssl, jadetex, transfig, imagemagick, 
ghostscript, jade, docbook-xml, sgml-data
 Vcs-Git: git://git.debian.org/git/collab-maint/kannel.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/kannel.git;a=summary
 Homepage: http://www.kannel.org/
diff --git a/debian/kannel.install b/debian/kannel.install
index ae972c1..f24cd07 100644
--- a/debian/kannel.install
+++ b/debian/kannel.install
@@ -2,6 +2,7 @@ usr/bin/wmlsc

Bug#590544: [PATCH] Compare START_SMSBOX and START_WAPBOX to 1, not to empty.

[Kalle Niemitalo]

Bug-Debian: http://bugs.debian.org/590544
---

This patch is meant to apply on top of the changes that I posted
to Bug#786747 new upstream stable version Kannel 1.4.4
and Bug#788335 kannel: wrong license in the copyright file.

 debian/changelog   | 2 ++
 debian/kannel.init | 8 
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index d60a31d..5ca13e5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,8 @@ kannel (1.4.4-0~procomp1) UNRELEASED; urgency=low
 + Although the sqlbox and opensmppbox add-ons are now part of the
   source tree, this version of the packaging does not build them.
   * Update debian/copyright from LICENSE. Closes: bug#788335.
+  * If $START_WAPBOX or $START_SMSBOX is defined but the value is not 1,
+then don't start that box. Closes: bug#590544.
 
  --
 
diff --git a/debian/kannel.init b/debian/kannel.init
index 5c3052c..334ad76 100644
--- a/debian/kannel.init
+++ b/debian/kannel.init
@@ -55,7 +55,7 @@ case $1 in
--no-extra-args \
$BOXPATH/bearerbox -v 4 -- $CONF
 sleep 1 # Wait for bearerbox
-test ! -z $START_WAPBOX  (
+test $START_WAPBOX = 1  (
 log_progress_msg wapbox
start-stop-daemon --start --quiet \
--pidfile $PIDFILES/kannel_wapbox.pid \
@@ -66,7 +66,7 @@ case $1 in
--no-extra-args \
$BOXPATH/wapbox -v 4 -- $CONF
 )
-test ! -z $START_SMSBOX  (
+test $START_SMSBOX = 1  (
 log_progress_msg smsbox
start-stop-daemon --start --quiet \
--pidfile $PIDFILES/kannel_smsbox.pid \
@@ -82,13 +82,13 @@ case $1 in
 
   stop)
 log_daemon_msg Stopping WAP gateway
-test ! -z $START_SMSBOX  (
+test $START_SMSBOX = 1  (
log_progress_msg smsbox
start-stop-daemon --stop --retry 5 --quiet \
--pidfile $PIDFILES/kannel_smsbox.pid \
--exec $BOXPATH/run_kannel_box
 )
-test ! -z $START_WAPBOX  (
+test $START_WAPBOX = 1  (
log_progress_msg wapbox
start-stop-daemon --stop --retry 5 --quiet \
--pidfile $PIDFILES/kannel_wapbox.pid \
-- 
1.9.1


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

Bug#717728: [PATCH] Use sqlite3_libversion(), not sqlite3_version[].

[Kalle Niemitalo]

Bug-Debian: http://bugs.debian.org/717728
---

This patch is meant to apply on top of the changes that I posted
to Bug#786747 new upstream stable version Kannel 1.4.4,
Bug#788335 kannel: wrong license in the copyright file,
and Bug#590544 [kannel] sensible handling of values in /etc/default/kannel.

I first incorrectly sent this to Bug#715213 nmu: kannel_0.7.2-3.
Now resending to the correct Bug#717728.

 debian/changelog   |  1 +
 debian/patches/34_sqlite3_libversion.patch | 21 +
 debian/patches/series  |  1 +
 3 files changed, 23 insertions(+)
 create mode 100644 debian/patches/34_sqlite3_libversion.patch

diff --git a/debian/changelog b/debian/changelog
index 5ca13e5..b3c7c33 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -20,6 +20,7 @@ kannel (1.4.4-0~procomp1) UNRELEASED; urgency=low
   * Update debian/copyright from LICENSE. Closes: bug#788335.
   * If $START_WAPBOX or $START_SMSBOX is defined but the value is not 1,
 then don't start that box. Closes: bug#590544.
+  * Add patch 34 to use sqlite3_libversion(). Closes: bug#717728.
 
  --
 
diff --git a/debian/patches/34_sqlite3_libversion.patch 
b/debian/patches/34_sqlite3_libversion.patch
new file mode 100644
index 000..6304cd3
--- /dev/null
+++ b/debian/patches/34_sqlite3_libversion.patch
@@ -0,0 +1,21 @@
+Description: Use sqlite3_libversion() instead of sqlite3_version[].
+ Using sqlite3_version causes a has different size in shared object
+ warning at run time if the length of the version number has changed
+ in the sqlite3 shared library.  It is not clear whether anything
+ worse will happen in addition to the warning, but we can avoid the
+ problem altogether by calling sqlite_libversion() instead.
+Author: Kalle Niemitalo kalle.niemit...@procomp.fi
+Bug-Debian: http://bugs.debian.org/717728
+Last-Update: 2015-06-09
+
+--- kannel-1.4.4.orig/gwlib/dbpool_sqlite3.c
 kannel-1.4.4/gwlib/dbpool_sqlite3.c
+@@ -86,7 +86,7 @@ static void *sqlite3_open_conn(const DBC
+ }
+ 
+ info(0, SQLite3: Opened or created database file `%s'., 
octstr_get_cstr(conf-file));
+-info(0, SQLite3: library version %s., sqlite3_version);
++info(0, SQLite3: library version %s., sqlite3_libversion());
+ 
+ return db;
+ 
diff --git a/debian/patches/series b/debian/patches/series
index d0c60d2..fb6e3b0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 33_docpatch.patch
+34_sqlite3_libversion.patch
-- 
1.9.1


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

Bug#715213: [PATCH] Use sqlite3_libversion(), not sqlite3_version[].

[Kalle Niemitalo]

Bug-Debian: http://bugs.debian.org/717728
---

This patch is meant to apply on top of the changes that I posted
to Bug#786747 new upstream stable version Kannel 1.4.4,
Bug#788335 kannel: wrong license in the copyright file,
and Bug#590544 [kannel] sensible handling of values in /etc/default/kannel.

 debian/changelog   |  1 +
 debian/patches/34_sqlite3_libversion.patch | 21 +
 debian/patches/series  |  1 +
 3 files changed, 23 insertions(+)
 create mode 100644 debian/patches/34_sqlite3_libversion.patch

diff --git a/debian/changelog b/debian/changelog
index 5ca13e5..b3c7c33 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -20,6 +20,7 @@ kannel (1.4.4-0~procomp1) UNRELEASED; urgency=low
   * Update debian/copyright from LICENSE. Closes: bug#788335.
   * If $START_WAPBOX or $START_SMSBOX is defined but the value is not 1,
 then don't start that box. Closes: bug#590544.
+  * Add patch 34 to use sqlite3_libversion(). Closes: bug#717728.
 
  --
 
diff --git a/debian/patches/34_sqlite3_libversion.patch 
b/debian/patches/34_sqlite3_libversion.patch
new file mode 100644
index 000..6304cd3
--- /dev/null
+++ b/debian/patches/34_sqlite3_libversion.patch
@@ -0,0 +1,21 @@
+Description: Use sqlite3_libversion() instead of sqlite3_version[].
+ Using sqlite3_version causes a has different size in shared object
+ warning at run time if the length of the version number has changed
+ in the sqlite3 shared library.  It is not clear whether anything
+ worse will happen in addition to the warning, but we can avoid the
+ problem altogether by calling sqlite_libversion() instead.
+Author: Kalle Niemitalo kalle.niemit...@procomp.fi
+Bug-Debian: http://bugs.debian.org/717728
+Last-Update: 2015-06-09
+
+--- kannel-1.4.4.orig/gwlib/dbpool_sqlite3.c
 kannel-1.4.4/gwlib/dbpool_sqlite3.c
+@@ -86,7 +86,7 @@ static void *sqlite3_open_conn(const DBC
+ }
+ 
+ info(0, SQLite3: Opened or created database file `%s'., 
octstr_get_cstr(conf-file));
+-info(0, SQLite3: library version %s., sqlite3_version);
++info(0, SQLite3: library version %s., sqlite3_libversion());
+ 
+ return db;
+ 
diff --git a/debian/patches/series b/debian/patches/series
index d0c60d2..fb6e3b0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 33_docpatch.patch
+34_sqlite3_libversion.patch
-- 
1.9.1


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

Bug#766215: allow to turn off sslv3 to close POODLE vulnerability in kannel

[Kalle Niemitalo]

In kannel-1.4.4/gwlib/conn.c, conn_init_ssl() uses SSLv23_client_method(),
and server_ssl_init() uses SSLv23_server_method().  The SSL_CTX_new(3SSL)
manual page says those support all of SSLv2, SSLv3, and TLSv1; and
openssl-1.0.1f/ssl/s23_clnt.c shows that they support TLSv1.1 and TLSv1.2
as well.  Thus, I think Kannel should already be able to connect to a
server that allows only TLSv1, if the server at least understands SSLv2
client hello messages.

If you want to prevent Kannel from using SSLv2 and SSLv3, I guess Kannel
could be changed to call SSL_CTX_set_options or SSL_set_options with
SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 options.  It would perhaps be easiest
to do that to global_ssl_context and global_server_ssl_context so that
the options apply to all SSL objects.  Is there any scenario in which
one would want to support SSLv3 on some connections but not on all?


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

Bug#786747: new upstream stable version Kannel 1.4.4

[Kalle Niemitalo]

Source: kannel
Version: 1.4.3-2+b2
Severity: wishlist

http://kannel.org/news.shtml#1.4.4 says that the stable version
Kannel 1.4.4 was released on 1 August 2014.  Debian currently
has Kannel 1.4.3-2+b2 in stable, testing, and unstable.  Please
consider packaging 1.4.4, which fixes several upstream bugs.

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#762173: laptop-mode-tools: Can confirm w/ USB keyboards

[Kalle Sandström]

Package: laptop-mode-tools
Version: 1.66-1
Followup-For: Bug #762173

Dear Maintainer,

I can confirm that this bug persists in verseion 1.66-1. Description follows.

   * What led up to the situation?
 - desire to operate computer with an external keyboard.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 - plugged in an USB keyboard. (brands: Ducky Mini, Ducky G2PRO)
 - started typing
   * What was the outcome of this action?
 - first keypress was lost whenever keyboard wasn't operated for two seconds
   * What outcome did you expect instead?
 - first keypress to register as it should on a keyboard


Furthermore I observed that under /sys/bus/usb/devices/3-1.2/power, the
autosuspend values hadn't been set to -1 as instructed by
/etc/laptop-mode/conf.d/usb-autosuspend.conf . It seems that laptop-mode is
ignoring this configuration file, or that the relevant components are not being
executed at the correct times.

Calling `invoke-rc.d laptop-mode restart' did not change the situation.

Kernel is a kernel.org stable 3.16.4 without Debian patches built with
kernel-package.


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

Kernel: Linux 3.16.4+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages laptop-mode-tools depends on:
ii  lsb-base4.1+Debian13
ii  psmisc  22.21-2
ii  util-linux  2.20.1-5.9

Versions of packages laptop-mode-tools recommends:
ii  ethtool 1:3.16-1
ii  hdparm  9.43-1.1
ii  net-tools   1.60-26
ii  python-qt4  4.11.2+dfsg-1
ii  sdparm  1.07-1
ii  udev208-8
ii  wireless-tools  30~pre9-8

Versions of packages laptop-mode-tools suggests:
ii  acpid  1:2.0.23-1
ii  apmd   3.2.2-14

-- Configuration Files:
/etc/laptop-mode/conf.d/bluetooth.conf changed:
DEBUG=0
CONTROL_BLUETOOTH=1
BATT_ENABLE_BLUETOOTH=0
AC_ENABLE_BLUETOOTH=0
BLUETOOTH_INTERFACES=hci0

/etc/laptop-mode/conf.d/ethernet.conf changed:
DEBUG=0
CONTROL_ETHERNET=auto
BATT_THROTTLE_ETHERNET=0
LM_AC_THROTTLE_ETHERNET=0
NOLM_AC_THROTTLE_ETHERNET=0
THROTTLE_SPEED=slowest
DISABLE_WAKEUP_ON_LAN=1
ETHERNET_DEVICES=eth1
DISABLE_ETHERNET_ON_BATTERY=1

/etc/laptop-mode/conf.d/usb-autosuspend.conf changed:
DEBUG=0
CONTROL_USB_AUTOSUSPEND=auto
AUTOSUSPEND_USE_WHITELIST=0
AUTOSUSPEND_USBID_BLACKLIST=04d9:0230 04d9:0130 046d:c51a 0f39:0611 04a9:190d
AUTOSUSPEND_USBTYPE_BLACKLIST=
AUTOSUSPEND_USBID_WHITELIST=
AUTOSUSPEND_USBTYPE_WHITELIST=
BATT_SUSPEND_USB=1
LM_AC_SUSPEND_USB=1
NOLM_AC_SUSPEND_USB=0
AUTOSUSPEND_TIMEOUT=2

/etc/laptop-mode/conf.d/wireless-iwl-power.conf changed:
DEBUG=0
CONTROL_IWL_POWER=auto
IWL_AC_POWER=0
IWL_BATT_POWER=3

/etc/laptop-mode/laptop-mode.conf changed:
ENABLE_LAPTOP_MODE_TOOLS=1
VERBOSE_OUTPUT=0
LOG_TO_SYSLOG=1
DEBUG=0
ENABLE_LAPTOP_MODE_ON_BATTERY=1
ENABLE_LAPTOP_MODE_ON_AC=0
ENABLE_LAPTOP_MODE_WHEN_LID_CLOSED=0
ENABLE_AUTO_MODULES=1
MINIMUM_BATTERY_CHARGE_PERCENT=5
DISABLE_LAPTOP_MODE_ON_CRITICAL_BATTERY_LEVEL=1
DISABLE_BATTERY_ALARM_CHECK=0
HD=/dev/[hs]d[abcdefgh]
PARTITIONS=auto /dev/mapper/*
ASSUME_SCSI_IS_SATA=1
LM_BATT_MAX_LOST_WORK_SECONDS=900
LM_AC_MAX_LOST_WORK_SECONDS=120
CONTROL_READAHEAD=1
LM_READAHEAD=1024
NOLM_READAHEAD=256
CONTROL_NOATIME=1
USE_RELATIME=1
CONTROL_HD_IDLE_TIMEOUT=1
LM_AC_HD_IDLE_TIMEOUT_SECONDS=15
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=5
NOLM_HD_IDLE_TIMEOUT_SECONDS=7200
CONTROL_HD_POWERMGMT=auto
BATT_HD_POWERMGMT=1
LM_AC_HD_POWERMGMT=254
NOLM_AC_HD_POWERMGMT=254
CONTROL_HD_WRITECACHE=1
NOLM_AC_HD_WRITECACHE=0
NOLM_BATT_HD_WRITECACHE=0
LM_HD_WRITECACHE=1
CONTROL_MOUNT_OPTIONS=1
LM_DIRTY_RATIO=60
NOLM_DIRTY_RATIO=40
LM_DIRTY_BACKGROUND_RATIO=1
NOLM_DIRTY_BACKGROUND_RATIO=10
DEF_UPDATE=5
DEF_XFS_AGE_BUFFER=15
DEF_XFS_SYNC_INTERVAL=30
DEF_XFS_BUFD_INTERVAL=1
DEF_MAX_AGE=30
XFS_HZ=100
LM_SECONDS_BEFORE_SYNC=1


-- no debconf information


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

Bug#764611: Problem persists with 2.42.0-2

[Kalle A . Sandström]

Hello,

The issue persists with exactly the same symptoms in the patched version
which recently made its way into testing. Same w/ deadbeef, albeit that is
a deb-mm package.

-KS

Bug#763787: libglib2.0-0: applications abort with Attempt to unlock mutex that was not locked message

[Kalle Sandström]

Source: libglib2.0-0
Version: 2.42.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
 - customary apt-get upgrade from testing

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 - start of application (deadbeef, sonata) from window manager or terminal
   window

   * What was the outcome of this action?
 - window appears, then disappears instantly
 - error message on terminal window

   * What outcome did you expect instead?
 - window appears, application enters usable state


Downgrading all glib2 packages to 2.41.1-2 from snapshot.debian.org solves the
problem, as described above, entirely.

I've classified the bug as grave and rendering package unusable, however,
since glib2 provides no independent functionality to the flesh-and-blood user,
this implies unusability in packages that utilize glib2.

I'm surprised that this sort of garba^Wunfortunate malfunction, for which bug
#758619 has existed since 19th of August this year, can still hit testing; and
that it has seemingly gone untested to a degree at which the bug hasn't been
seen by the glib2 maintainers. Nor, seemingly, glib2's developers. Or anyone
else in the chain of consumption.

This report may be merged with #758619 since terminal-mode reportbug didn't
offer to do so already.

Regards,
  -KS

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

Kernel: Linux 3.16.3+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

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#759471: xfce4-power-manager: Doesn't receive plug/unplug events or power state, after startup

[Kalle Sandström]

Package: xfce4-power-manager
Version: 1.2.0-5
Severity: important

Dear Maintainer,

xfce4-power-manager seems to have rotted, again. It now fails to notice when
the laptop's charger is connected or disconnected, and its battery level
indicator (i.e. the one that comes up w/ Fn+F3 on Thinkpads) shows stale
information. This also leads to it being unable to indicate that battery level
is critically low, causing sudden (and quite jarring) out-of-battery
situations.

The problem appeared recently, within the past two weeks, from testing. I have
determined that the problem is not related to my custom kernel (by booting an
older custom kernel on which the problem never appeared), nor to the hardware
in use (by upgrading a spare Thinkpad and confirming that the same failure
occurs).

As I'm systematically abstaining from sipping the systemd cyanide pop, I find
it credible that the problem lay in the various stealth systemd dependencies in
the most recent ACPI or general PM handling in Debian, and so the bug should be
refiled appropriately -- but I've got neither the knowledge, skills, nor
ability to do so.

Relatedly, since april-may 2014, it's been the case that xfce4-power-manager
has been unable to effect suspend or hibernate either at command or
automatically. This problem repeats on all laptops upgraded from testing since
april-ish. (I blame the brave new systemd world, and thus lennart fucking
pöttering, for the issue; but that's neither here nor there.)


I've classed this bug as important because in combination with the
suspend/hibernate permission issue, this bug inhibits xfce4-power-manager's
proper function entirely.


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

Kernel: Linux 3.16.1+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.19-9
ii  libdbus-1-3   1.8.6-2
ii  libdbus-glib-1-2  0.102-1
ii  libgdk-pixbuf2.0-02.30.7-1
ii  libglib2.0-0  2.40.0-4
ii  libgtk2.0-0   2.24.24-1
ii  libnotify40.7.6-2
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.2-1
ii  libxfce4ui-1-04.10.0-5
ii  libxfce4util6 4.10.1-1
ii  libxfconf-0-2 4.10.0-2
ii  libxrandr22:1.4.2-1
ii  upower0.99.0-3
ii  xfce4-power-manager-data  1.2.0-5

Versions of packages xfce4-power-manager recommends:
pn  libpam-systemd   none
pn  systemd-shim | systemd-sysv  none

Versions of packages xfce4-power-manager suggests:
ii  udisks   1.0.5-1+b1
pn  xfce4-power-manager-plugins  none

-- no debconf information


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

Bug#755074: cryptsetup: Also, cryptsetup's boot-time script fails to mount a LUKS home filesystem

[Kalle Sandström]

Package: cryptsetup
Version: 2:1.6.6-1
Followup-For: Bug #755074

Dear Maintainer,

In addition to the bug reported above, which I can confirm, cryptsetup's
boot-time scripts fail to mount the encrypted /home filesystem, defined below.
Instead a /dev/mapper/pigdog0-home_crypt_unformatted is left behind, and later
scripts (obviously) fail to fsck and mount /home from its correct device node.

The problem appeared with a recent (within the last two months) upgrade from
testing. The affected system is being kept systemd-free, if that matters.

Included fstab was redacted to omit encryption-related but non-cryptsetup
information.


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.16.1+ root=/dev/mapper/pigdog0-root ro 
i915.i915_enable_rc6=7 i915.lvds_downclock=1 pcie_aspm=force 
cgroup_disable=memory zcache zcache.compressor=lz4 zswap.enabled=1 
zswap.compressor=lz4 intel_pstate=disable quiet

-- /etc/crypttab
pigdog0-home_crypt /dev/mapper/pigdog0-home none luks,discard

swap0 /dev/mapper/pigdog0-swap0 /dev/urandom swap,discard,size=128
swap1 /dev/mapper/pigdog1-swap1 /dev/urandom swap,size=128

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file system mount point   type  options   dump  pass
proc/proc   procdefaults0   0
/dev/mapper/pigdog0-root /   ext4
relatime,acl,discard,errors=remount-ro 0   1
UUID=ee743e23-fc63-49d2-a2ec-8125b264ca4f /boot ext2defaults0   
2
#UUID=764e5bd8-1ecc-4a8d-9e8f-17e130e5df0c /bootext2defaults
0   2
/dev/mapper/pigdog0-home_crypt /home   ext4relatime,acl,discard 
   0   2
/dev/mapper/pigdog0-usr /usrext4relatime,acl,discard0   
2
/dev/mapper/pigdog0-local /usr/local  ext4relatime,acl,discard0 
  2
/dev/mapper/pigdog0-var /varext4relatime,acl,discard0   
2
/dev/mapper/pigdog1-##  /## ext4defaults,acl,relatime   0   
2

#/dev/pigdog0/ia32-testing  /srv/chroot/ia32-testingext4
defaults,acl,relatime,discard   0   2

/dev/scd0   /media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/sdc1   /media/usbkey   vfatuser,flush,noauto,nosuid,nodev  0   0
/dev/mmcblk0p1  /media/sd   vfatuser,flush,noauto,nosuid,nodev  0   0

/dev/mapper/swap0 noneswapsw,pri=1  0   0
/dev/mapper/swap1 noneswapsw,pri=-1  0   0


#none   /tmptmpfs   defaults0   0
none/sys/kernel/debug   debugfs defaults0   0

/##.sh#/##/pigdog   /mnt/## fusenoauto,nosuid,nodev,rw  
0   0

-- lsmod
Module  Size  Used by
sha256_generic 16804  6 
algif_skcipher 17051  0 
af_alg 12988  1 algif_skcipher
ctr12927  1 
ccm17534  1 
bnep   17306  2 
snd_hrtimer12604  1 
snd_seq48841  1 
snd_seq_device 13132  1 snd_seq
cpufreq_userspace  12525  0 
cpufreq_conservative14184  0 
cpufreq_powersave  12454  0 
cpufreq_stats  12782  0 
autofs427337  2 
binfmt_misc12853  1 
pktcdvd30855  0 
cdrom  31102  1 pktcdvd
uinput 17372  1 
rpcsec_gss_krb526051  0 
nfsd  233580  2 
auth_rpcgss46925  2 nfsd,rpcsec_gss_krb5
oid_registry   12419  1 auth_rpcgss
nfs_acl12511  1 nfsd
nfs   171079  0 
lockd  66687  2 nfs,nfsd
fscache45304  1 nfs
sunrpc199722  8 
nfs,nfsd,rpcsec_gss_krb5,auth_rpcgss,lockd,nfs_acl
uvcvideo   74806  0 
videobuf2_vmalloc  12816  1 uvcvideo
videobuf2_memops   12519  1 videobuf2_vmalloc
videobuf2_core 31328  1 uvcvideo
v4l2_common12906  1 videobuf2_core
ecb12737  0 
videodev  118075  3 uvcvideo,v4l2_common,videobuf2_core
btusb  25625  0 
bluetooth 271066  6 bnep,btusb
6lowpan_iphc   16588  1 bluetooth
ext2   66512  1 
bbswitch   12878  0 
hdaps  13623  0 
tp_smapi   23525  0 
thinkpad_ec12813  2 hdaps,tp_smapi
loop   26563  0 
firewire_sbp2  21744  0 
firewire_core  56665  1 firewire_sbp2
crc_itu_t  12347  1 firewire_core
fuse   83350  3 
parport_pc 26300  0 
ppdev  12686  0 
lp 17074  0 
parport35749  3 lp,ppdev,parport_pc
dm_crypt   22551  4 

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#721049: ktorrent: Experimental ktorrent depends on a removed package (libkworkspace4abi1)

[Kalle Michanek]

Package: ktorrent
Version: 4.3.1-1
Severity: normal

I just noticed (via aptitude) that likworkspace4abi1 is not in the repositories 
any longer. When I tried to uninstall it, aptitude was complaining about
ktorrent was depending on it. Shouldn't ktorrent depend on libkworkspace4abi2 
instead?

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

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

Versions of packages ktorrent depends on:
ii  kde-runtime 4:4.10.5-1
ii  ktorrent-data   4.3.1-1
ii  libc6   2.17-92
ii  libgcc1 1:4.8.1-2
ii  libgeoip1   1.5.1-2
ii  libkcmutils44:4.10.5-1
ii  libkdecore5 4:4.10.5-1
ii  libkdeui5   4:4.10.5-1
ii  libkdewebkit5   4:4.10.5-1
ii  libkdnssd4  4:4.10.5-1
ii  libkemoticons4  4:4.10.5-1
ii  libkidletime4   4:4.10.5-1
ii  libkio5 4:4.10.5-1
ii  libknotifyconfig4   4:4.10.5-1
ii  libkparts4  4:4.10.5-1
ii  libkprintutils4 4:4.10.5-1
ii  libkrosscore4   4:4.10.5-1
ii  libktorrent-l10n1.3.1-1
ii  libktorrent51.3.1-1
ii  libkutils4  4:4.10.5-1
ii  libkworkspace4abi1  4:4.8.4-6
ii  libnepomuk4 4:4.10.5-1
ii  libnepomukutils44:4.10.5-1
ii  libphonon4  4:4.6.0.0-3
ii  libqt4-dbus 4:4.8.5+dfsg-2
ii  libqt4-network  4:4.8.5+dfsg-2
ii  libqt4-qt3support   4:4.8.5+dfsg-2
ii  libqt4-script   4:4.8.5+dfsg-2
ii  libqt4-svg  4:4.8.5+dfsg-2
ii  libqt4-xml  4:4.8.5+dfsg-2
ii  libqtcore4  4:4.8.5+dfsg-2
ii  libqtgui4   4:4.8.5+dfsg-2
ii  libqtwebkit42.2.1-5
ii  libsolid4   4:4.10.5-1
ii  libsoprano4 2.9.2+dfsg.1-4
ii  libstdc++6  4.8.1-2
ii  libsyndication4 4:4.10.5-1
ii  libtag1c2a  1.8-dmo1
ii  phonon  4:4.6.0.0-3

ktorrent recommends no packages.

Versions of packages ktorrent suggests:
pn  krosspython none
ii  plasma-widget-ktorrent  4.3.1-1

-- no debconf information


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

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#717994: xdotool: 'type' in a script ignores newlines

[Kalle Raiskila]

Package: xdotool
Version: 1:3.20130111.1-3
Severity: normal

Dear Maintainer,

The following shows an error in xdotool:

$ cat xdoscript 
key KP_Enter
type 'abc'
key KP_Enter
type '123'
$ xdotool xdoscript 

abckeyKP_Entertype123$ 
$ abckeyKP_Entertype123


I.e. in a script, after the first line with a 'type' command
the rest of the script file is echoed verbatim. Expected (and
elsewhere experienced) behaviour is that only the rest of the 
line with the type command is echoed, the next line starting 
a new command.

The xdoscript is plain ASCII, with unix line endings.
Setting locale to C does not fix the issue.

thank you for your time, 
Kalle

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

Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=sv_FI.UTF-8, LC_CTYPE=sv_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xdotool depends on:
ii  libc6 2.17-7
ii  libx11-6  2:1.6.0-1
ii  libxdo3   1:3.20130111.1-3

xdotool recommends no packages.

xdotool suggests no packages.

-- no debconf information


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

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#708390: Dirty indeed

[Kalle Söderman]

On Thu, May 16, 2013 at 8:44 AM, Paul Wise p...@debian.org wrote:

 On Thu, May 16, 2013 at 2:07 PM, Nicolae Crefelean wrote:

  Is it too late to spread the word all over again for new graphics? I know
  some people who could try their hand if they had time and given the
 chance.

 It is too late for wheezy, but not too late for jessie, which is only
 just getting started.



Hi all,

Noticed this discussion and would like to add that my intention when
designing the front page layout and the original banner (for the website
re-design way back) was that the banner would change more often than it
does now. I never imagined that the banner would stay the same for a whole
release cycle.

I would be great if the banner changed for Debconfs and other
important/funny/interesting events. It could then fall back to a more
neutral, perhaps not even release specific, design like the original one. I
know debian is short on good designers but if the banners are short lived
it matters less if mistakes are made. I realize this is all work that has
to be done and like myself people very little spare time. Just wanted to
clarify how the original idea for the banner was conceived.

Regards
Kalle Söderman
-- 
http://www.kalleswork.net | gpg: 6D87C839

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