Bug#1063470: debsums: man page documents removed "--generate=keep" option

[Ben Harris]

Package: debsums
Version: 3.0.2.1
Severity: minor

Dear Maintainer,

The man debsums(1) man page says:

   -g, --generate=[missing|all][,keep[,nocheck]]
...
  keep   Write  the  extracted/generated  sums  to
 /var/lib/dpkg/info/package.md5sums.

However, if I try to use the "keep" option, debsums reports:

wraith:/tmp$ debsums --generate=all,keep,nocheck debsums_3.0.2.1_all.deb
debsums: the --generate=keep option has been removed and does nothing. at 
/usr/bin/debsums line 847.

Since the option no longer does anything, it should either be removed 
from the man page or documented as doing nothing.

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

Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

Versions of packages debsums depends on:
ii  libdpkg-perl  1.22.4
ii  libfile-fnmatch-perl  0.02-3+b2
ii  perl  5.38.2-3
ii  ucf   3.0043+nmu1

debsums recommends no packages.

Versions of packages debsums suggests:
ii  bash-completion  1:2.11-8

-- Configuration Files:
/etc/default/debsums changed:
CRON_CHECK="monthly"


-- debconf information:
* debsums/apt-autogen: true
* debsums/croncheck: monthly

Bug#1062204: Acknowledgement (Newly-created clusters have restrictive postgresql.conf permissions)

[Ben Harris]

Control: found -1 patroni/3.1.1-1

I've just tested a couple of other versions of the Debian patroni package 
from snapshot.debian.org:


3.0.4-1 does not have the problem: postgresql.conf is world-readable.

3.1.1-1 has the problem: postgresql.conf is not world-readable.

--
Ben Harris, University of Cambridge Information Services.

Bug#1062204: Newly-created clusters have restrictive postgresql.conf permissions

[Ben Harris]

Package: patroni
Version: 3.2.2-1

When Patroni creates a new PostgreSQL cluster, the postgresql.conf file in 
/etc/patroni// ends up without world read permission. 
This means that tools that use pg_wrapper (such as /usr/bin/psql) can't 
find the cluster's port number and don't work by default.


I think this problem was introduced by this upstream commit:

https://github.com/zalando/patroni/commit/01d07f86cd525c0f324074ee026faf6d7f179839

But I'm not sure if it's an upstream bug, or a latent flaw in the Debian 
packaging.



To reproduce:

On a fresh Debian system, install patroni, postgresql, and etcd-server.

Configure /etc/patroni/dcs.yml as shown below.

# systemctl stop postgresql@16-main
# pg_dropcluster 16 main
# pg_createconfig_patroni 16 test
# systemctl start patroni@16-test
# pg_isready
/var/run/postgresql/:5432 - accepting connections
# adduser user
(press Return lots)
# su - user
$ pg_isready
Error: Invalid data directory for cluster 16 test

If I change the permissions on /etc/postgresql/16/test/postgresql.conf 
from 600 to 644 then pg_isready works as the unprivileged user.



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

Kernel: Linux 6.6.13-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages patroni depends on:
ii  python33.11.6-1
ii  python3-cdiff  1.0-1.1
ii  python3-click  8.1.6-1
ii  python3-dateutil   2.8.2-3
ii  python3-etcd   0.4.5-4
ii  python3-pkg-resources  68.1.2-2
ii  python3-prettytable3.6.0-1
ii  python3-psutil 5.9.8-1
ii  python3-psycopg2   2.9.9-1+b1
ii  python3-urllib31.26.18-2
ii  python3-yaml   6.0.1-2

Versions of packages patroni recommends:
ii  iproute2  6.7.0-2

Versions of packages patroni suggests:
ii  etcd-server  3.4.23-4+b8
pn  haproxy  
pn  patroni-doc  
ii  postgresql   16+256
pn  vip-manager  

-- Configuration Files:
/etc/patroni/dcs.yml changed:
etcd3:
  host: 127.0.0.1:2379


-- no debconf information

Bug#1037202: libunity9: Multi-Arch: same, but not co-installable

[Ben Harris]

Package: libunity9
Version: 7.1.4+19.04.20190319-6+b1
Severity: normal

Dear Maintainer,

While cross-grading an i386 system to amd64, I tried to co-install both 
i386 and amd64 versions of libunity9.  This should be possible as they are 
both marked "Multi-Arch: same".  However, dpkg complains:


wraith:~/crossgrade# dpkg -i libunity9_7.1.4+19.04.20190319-6+b1_i386.deb
(Reading database ... 431882 files and directories currently installed.)
Preparing to unpack libunity9_7.1.4+19.04.20190319-6+b1_i386.deb ...
Unpacking libunity9:i386 (7.1.4+19.04.20190319-6+b1) over 
(7.1.4+19.04.20190319-6+b1) ...
Setting up libunity9:i386 (7.1.4+19.04.20190319-6+b1) ...
Processing triggers for libc-bin (2.36-9) ...
Processing triggers for libglib2.0-0:amd64 (2.74.6-2) ...
Processing triggers for libglib2.0-0:i386 (2.74.6-2) ...
wraith:~/crossgrade# dpkg -i libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb
(Reading database ... 431882 files and directories currently installed.)
Preparing to unpack libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb ...
Unpacking libunity9:amd64 (7.1.4+19.04.20190319-6+b1) ...
dpkg: error processing archive libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb 
(--install):
 trying to overwrite shared '/usr/bin/unity-scope-loader', which is different 
from other instances of package libunity9:amd64
Processing triggers for libc-bin (2.36-9) ...
Errors were encountered while processing:
 libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb

/usr/bin/unity-scope-loader is indeed an i386 executable in the i386 
package and an amd64 executable in the amd64 package.


I think either unity-scopes-loader should be removed from the libunity9 
package or libunity9 should be marked as "Multi-Arch: no".


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

--
Ben Harris, University of Cambridge Information Services.

Bug#905852: Solo no longer crashes when resized very small

[Ben Harris]

Control: tags -1 fixed-upstream

I've just committed this fix to upstream Solo:

https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=3cd51d001769c657ebb4184bd05343af4d7e12b1

This fixes the assertion failure when a Solo grid with pencil marks is 
resized to its minimum tile size.


--
Ben Harris

Bug#729250: Pattern 1xn generation bug fixed in 2017

[Ben Harris]

Control: fixed -1 20191231.79a5378-1

I think Pattern's difficulties with generating 1xn puzzles were fixed by 
this upstream commit:


https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b8313181a6104624000e9cc008e8e26b67aeb655

The first entry in the Debian change log after that is for version 
20191231.79a5378-1.


To demonstrate the fix, run "sgt-pattern --generate 1000 1x1".  Pattern 
will generate 1000 rather uninteresting puzzles in a fraction of a second.


--
Ben Harris

Bug#550311: slant: shading of filled squares has always been configurable

[Ben Harris]

Colours in Puzzles have been configurable by environment variable since 
long before shading of filled squares in Slant was introduced by Debian.


So it's always been possible to use "SLANT_COLOUR_7=d4d4d4" to turn off 
the shading of filled squares.  Though it might need the precise colour 
value changed to match the default background.


--
Ben Harris

Bug#642207: Probably fixed upstream

[Ben Harris]

Control: tags -1 fixed-upstream

I've just committed what I hope is an adequate fix for this upstream, 
adding "in order" to the description of each set of clues.


https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=232cbaf5a8affcb0c61f1355f0569efaae534ad9

--
Ben Harris

Bug#1025269: ITP dotnet in debian archive

[Ben Harris]

Package: dotnet-sdk-6.0
Version: 6.0.403-1
Severity: normal

ITP for dotnet in debian


-- 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-16-amd64 (SMP w/6 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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

Versions of packages dotnet-sdk-6.0 depends on:
ii  aspnetcore-runtime-6.0  6.0.11-1
ii  aspnetcore-targeting-pack-6.0   6.0.11-1
ii  dotnet-apphost-pack-6.0 6.0.11-1
ii  dotnet-runtime-6.0  6.0.11-1
ii  dotnet-targeting-pack-6.0   6.0.11-1
ii  netstandard-targeting-pack-2.1  2.1.0-1

dotnet-sdk-6.0 recommends no packages.

dotnet-sdk-6.0 suggests no packages.

-- no debconf information

Bug#835439: gdb --write segfaults on quit in _bfd_elf_strtab_finalize

[Ben Harris]

Control: fixed 835439 10.1-2

Looking through my old Debian bug reports, I found this one that I'm still 
in a position to test, and I can confirm that the problem is fixed (and 
probably has been for several years):


wraith:/tmp/hello$ cat > hello.c
#include 

int main(int argc, char **argv)
{

printf("hello, world\n");
return 0;
}
wraith:/tmp/hello$ gcc -o hello hello.c
wraith:/tmp/hello$ gdb --quiet --write hello
Reading symbols from hello...
(No debugging symbols found in hello)
(gdb) quit
wraith:/tmp/hello$

--
Ben Harris, University of Cambridge Information Services.

Bug#1012807: curl: "unexpected eof" from Patroni API endpoint after client upgrade to OpenSSL 3

[Ben Harris]

Package: curl
Version: 7.83.1-1+b1
Severity: normal
Control: fixed -1 7.83.0-1

Dear Maintainer,

Patroni (Debian package "patroni") is a piece of cluster management 
software for PostgreSQL that provides an HTTPS endpoint for managing it.  
When connecting to a Patroni instance from curl 7.83.0-1 (a version 
using libssl1.1), everything works happily:

wraith:~# curl --fail --insecure https://infra-db.srv.uis.cam.ac.uk:8008/ -o 
/dev/null
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   6510   6510 0  62928  0 --:--:-- --:--:-- --:--:-- 65100

However, when I upgrade to curl 7.83.1-1+b1, I get an error from the 
same request:

wraith:~# curl --fail --insecure https://infra-db.srv.uis.cam.ac.uk:8008/ -o 
/dev/null
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   6510   6510 0  22106  0 --:--:-- --:--:-- --:--:-- 22448
curl: (56) OpenSSL SSL_read: error:0A000126:SSL routines::unexpected eof while 
reading, errno 0

I would expect the two versions to behave the same.

Patroni uses Python's "http.server" to implement its API endpoint, so it 
may be possible to construct a simple test-case out of that.  I haven't 
yet tried.

I'm not certain that this bug is in cURL rather than in OpenSSL, Python, 
or Patroni, but cURL is the part I'm interacting with so it seems like a 
good place to start.

Here are the versions of libcurl4's dependencies, since they might be 
relevant:

ii  libbrotli1:i3861.0.9-2+b3
ii  libgssapi-krb5-2:i386  1.19.2-2+b2
ii  libidn2-0:i386 2.3.2-2
ii  libldap-2.5-0:i386 2.5.12+dfsg-2
ii  libnghttp2-14:i386 1.47.0-1+b1
ii  libpsl5:i386   0.21.0-1.2
ii  librtmp1:i386  2.4+20151223.gitfa8646d.1-2+b2
ii  libssh2-1:i386 1.10.0-3+b1
ii  libssl3:i386   3.0.3-7
ii  libzstd1:i386  1.5.2+dfsg-1

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 curl depends on:
ii  libc6 2.33-7
ii  libcurl4  7.83.1-1+b1
ii  zlib1g1:1.2.11.dfsg-4

curl recommends no packages.

curl suggests no packages.

-- no debconf information

Bug#1003292: Unpassworded superuser account now causes errors in log

[Ben Harris]

On Thu, 24 Mar 2022, Michael Banck wrote


I had reported that problem here and it got fixed in 2.1.3:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzalando%2Fpatroni%2Fissues%2F2162data=04%7C01%7Cbjh21%40universityofcambridgecloud.onmicrosoft.com%7C9e6d230170b542905a4a08da0d9cf315%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637837264988923002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TTrqAXz6csCVvQJgukeP2%2B3DwarS5V%2B9ApPJBUHxqVw%3Dreserved=0

Let me know if you still see this problem.


I can confirm that having upgraded to 2.1.3-1.pgdg20.04+1 and removed the 
superuser password, I'm no longer seeing errors in the system log.  Thank 
you!


--
Ben Harris, University of Cambridge Information Services.

Bug#868568: [Pkg-shadow-devel] Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Ben Harris]

On Tue, 8 Mar 2022, Serge E. Hallyn wrote


So deluser was doing the right thing, right?

The bug is how you got into this state?  Either the adduser for
the high uid should have checked for it being a delegated subuid,
or the adduser which added the subuids to the lower subuid should
have refused when the higher subuid existed as a uid.


As far as I can see, there is no checking for collisions in either 
direction: useradd depends on the ranges [UID_MIN,UID_MAX] and 
[SUB_UID_MIN,SUB_UID_MAX] not overlapping, and issues a warning if you 
assign a static UID outside the specified range.


--
Ben Harris, University of Cambridge Information Services.

Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Ben Harris]

I ran into a problem very similar to the one described in Debian bug 
868568: deleting a user with a UID < 10 failed because of a process 
that was running as a user with a UID >= 10.  It turned out to be 
because the larger user ID was recorded in /etc/subuid as a subordinate 
user-ID for the lower-numbered user.  Blanking out /etc/subuid and 
/etc/subgid caused deluser to behave as normal.


According to login.defs(5), the default range of subuids starts at 10. 
If you're using UIDs over 10 for normal users then you probably want 
to change that (or find a way to disable subordinate user-IDs entirely).


--
Ben Harris, University of Cambridge Information Services.

Bug#1003292: Unpassworded superuser account now causes errors in log

[Ben Harris]

Package: patroni
Version: 2.1.2-2

I actually encountered this problem in the PGDG package of Patroni for 
Ubuntu (version 2.1.2-2.pgdg18.04+1), but it claims to be an unchanged 
rebuild of Debian release 2.1.2-2, so I expect this is the best place to 
report problems.


In /etc/patroni/config.yml.in, which is added by the Debian packaging, 
there's this section:


# A superuser role is required in order for Patroni to manage the local
# Postgres instance.  If the option `use_unix_socket' is set to `true', then
# specifying an empty password results in no md5 password for the superuser
# being set and sockets being used for authentication. The `password:' line is
# nevertheless required.  Note that pg_rewind will not work if no md5 password
# is set.
superuser:
  username: "postgres"
  password:

That to me implies that not setting a superuser password should work as 
long as I have use_unix_socket set to true and use_pg_rewind set to false, 
both of which I do.  And up to Patroni 2.1.1 it did.  With the upgrade to 
2.1.2, Patroni still seems to work correctly but it produces log messages 
like this every ten seconds:


Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: 2022-01-07 
17:51:09,869 ERROR: Exception when working with leader
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: Traceback (most recent 
call last):
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3/dist-packages/patroni/postgresql/rewind.py", line 60, in 
check_leader_is_not_in_recovery
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: with 
get_connection_cursor(connect_timeout=3, options='-c statement_timeout=2000', 
**conn_kwargs) as cur:
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3.8/contextlib.py", line 113, in __enter__
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: return 
next(self.gen)
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3/dist-packages/patroni/postgresql/connection.py", line 44, in 
get_connection_cursor
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: conn = 
psycopg.connect(**kwargs)
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 127, in connect
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: conn = 
_connect(dsn, connection_factory=connection_factory, **kwasync)
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: psycopg2.OperationalError: 
connection to server at "172.28.208.196", port 5432 failed: fe_sendauth: no 
password supplied

It looks like Patroni now wants to connect to other nodes as a superuser 
even when use_pg_rewind is false.


I haven't managed to find anywhere in the upstream Patroni documentation 
that says that running with no password on the superuser account should 
work, so I think this is probably an error in the comment in config.yml.in 
rather than a bug in Patroni itself.


--
Ben Harris, University of Cambridge Information Services.

Bug#994000: undertime: missing dependency ModuleNotFoundError: No module named 'ephem'

[Ben Harris]

Package: undertime
Version: 2.4.0
Severity: important

Dear Maintainer,

import ephem fails when running moonphases.

installing python3-ephem resolves this issue; please add it as a dep.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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

Versions of packages undertime depends on:
ii  python3 3.9.2-3
ii  python3-dateparser  1.0.0-1
ii  python3-tabulate0.8.7-0.1
ii  python3-termcolor   1.1.0-3
ii  python3-tz  2021.1-1
ii  python3-yaml5.3.1-5

undertime recommends no packages.

undertime suggests no packages.

-- no debconf information

Bug#990041: dehydrated: Incorrect filename for example domains.txt in README.Debian

[Ben Harris]

Package: dehydrated
Version: 0.7.0-2
Severity: minor

Dear Maintainer,

In /usr/share/dehydrated/README.Debian, there is the following sentence
about domains.txt:


An example for a domain.txt can be found at
/usr/share/doc/dehydrated/examples/domains.txt.example.


This has two errors.  A trivial one is that "domain.txt" should read
"domains.txt", since that's the name of the file that dehydrated looks
for.

The second error is that "domains.txt.example" should read simply
"domains.txt", since the package contains
/usr/share/doc/dehydrated/examples/domains.txt but not
/usr/share/doc/dehydrated/examples/domains.txt.example.

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

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

Versions of packages dehydrated depends on:
ii  ca-certificates  20210119
ii  curl 7.74.0-1.2
ii  openssl  1.1.1k-1

dehydrated recommends no packages.

dehydrated suggests no packages.

-- no debconf information

Bug#989048: userv: client doesn't accept numeric UID on command line (probable doc bug)

[Ben Harris]

Package: userv
Version: 1.2.0
Severity: normal

Dear Ian,

The userv spec, describing the command-line interface, says:


service-user specifies which user is to provide the service. The user
may be a login name or a numeric uid, or - to indicate that the
service user is to be the same as the calling user.


However, the option to provide a numeric UID doesn't work:

wraith:~$ id
uid=12528(bjh21) gid=12528(bjh21) groups=12528(bjh21)
wraith:~$ userv 12528 foo
userv: failure: requested service user `12528' is not a user

As far as I can tell, this is an error in the specification: there is 
nothing in the userv client code that even tries to handle a numeric UID 
passed on the command line.  The same error appears in the manual page.


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

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages userv depends on:
ii  libc6  2.31-12

userv recommends no packages.

userv suggests no packages.

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#985845: pgbouncer: Obsolete URL in README.Debian

[Ben Harris]

Package: pgbouncer
Version: 1.15.0-1
Severity: minor

Dear Maintainer,

/usr/share/doc/pgbouncer/README.Debian includes this:

General usage information can be found at
  http://wiki.postgresql.org/wiki/PgBouncer

However, that page now just says:

The information that used to be on this wiki page is contained on the
PgBouncer website (https://www.pgbouncer.org/).

The README.Debian file should be updated to link to that new URL.

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pgbouncer depends on:
ii  libc-ares2 1.17.1-1
ii  libc6  2.31-9
ii  libevent-2.1-7 2.1.12-stable-1
ii  libpam0g   1.4.0-6
ii  libssl1.1  1.1.1j-1
ii  lsb-base   11.1.0
ii  postgresql-common  225

pgbouncer recommends no packages.

Versions of packages pgbouncer suggests:
ii  python3   3.9.2-2
ii  python3-psycopg2  2.8.6-2

-- Configuration Files:
/etc/pgbouncer/pgbouncer.ini [Errno 13] Permission denied: 
'/etc/pgbouncer/pgbouncer.ini'
/etc/pgbouncer/userlist.txt [Errno 13] Permission denied: 
'/etc/pgbouncer/userlist.txt'

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#983675: wev: Emits "invalid version" error at startup and consumes 100% CPU

[Ben Harris]

Package: wev
Version: 1.0.0-2
Severity: important
X-Debbugs-Cc: bj...@bjh21.me.uk

Dear Maintainer,

When run with no arguments, "wev" emits an error message and then 
hangs.  "top" shows its CPU usage as 100.0% and on my laptop the fan 
starts up suggesting a lot of CPU usage.  The precise error message 
depends on which Wayland compositor wev running under.

Under GNOME Shell (gnome-shell 3.38.3-2):

wl_registry@2: error 0: invalid version for global wl_seat (17): have 5, wanted 
6

Under Weston (weston 9.0.0-2):

wl_registry@2: error 0: invalid version for global xdg_wm_base (18): have 1, 
wanted 2

I think that, even if wev can't run under a particular compositor, it 
should not consume 100% of a CPU thread while doing so.  I have tagged 
this bug as "important" because it seems that this makes wev useless 
under two major Wayland compositors.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

Versions of packages wev depends on:
ii  libc6   2.31-9
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libxkbcommon0   1.0.3-2

wev recommends no packages.

wev suggests no packages.

-- no debconf information

Bug#959891: postgresql-client-12: pgbench is in the wrong package

[Ben Harris]

Package: postgresql-client-12
Version: 12.2-4
Severity: normal

Dear Maintainer,

The "pgbench" program doesn't seem to be in the postgresql-client-12
package, being instead in postgresql-12, the server package.  I think
this is probably a mistake: pgbench is listed as a "client application"
here:

https://www.postgresql.org/docs/12/reference-client.html

If I install postgresq-12, I can use pgbench against a remote database,
so it looks like it does indeed work correctly as a client.

I think this came about because pgbench used to be part of
postgresql-contrib-10, and it got merged into the wrong package when
postgresql-contrib-10 was abolished.

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

Kernel: Linux 5.6.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postgresql-client-12 depends on:
ii  libc6 2.30-4
ii  libedit2  3.1-20191231-1
ii  libpq512.2-4
ii  postgresql-client-common  214
ii  sensible-utils0.0.12+nmu1
ii  zlib1g1:1.2.11.dfsg-2

postgresql-client-12 recommends no packages.

Versions of packages postgresql-client-12 suggests:
ii  postgresql-12  12.2-4
pn  postgresql-doc-12  

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#931637: Slight inaccuracy in explanation of "apt upgrade"

[Ben Harris]

Package: release-notes
Severity: minor

In section 4.4.4, "Minimal system upgrade", the Release notes say that 
"apt upgrade" "has the effect of upgrading those packages which can be 
upgraded without requiring any other packages to be removed or installed".


However, when I ran this command (and consistently with my past experience 
of "apt upgrade"), it didn't just upgrade packages, but also installed new 
ones.  I think this is a change from "apt-get upgrade", which behaved as 
described here.


To correct this, I think the words "or installed" should be omitted from 
the end of the sentence.


--
Ben Harris, University of Cambridge Information Services.

Bug#924926: libgpiod2 should not conflict with libgpiod1

[Ben Harris]

On Wed, 3 Apr 2019, SZ Lin (林上智) wrote:


The APIs between libgpiod1 and libgpiod2 are quite different, and thus
the conflict setting was added to avoid any potential problem.


Differences in API (or ABI) shouldn't cause any trouble: programs built 
using the old -dev package will use libgpiod.so.1, and programs built 
using the new -dev package will use libgpiod.so.2.  This is precisely why 
they have different SONAMEs.



Can you make sure that it is harmless to co-install these two versions?


Well, I've tried co-installing them (admittedly on Raspbian, but the 
changes between the Debian and Raspbian versions are minimal) and both old 
and new versions of gpiodetect work, and pick up their correct library 
versions:


bjh21@fugloy:/tmp $ sudo /usr/bin/gpiodetect
gpiochip0 [pinctrl-bcm2835] (54 lines)
bjh21@fugloy:/tmp $ sudo ./gpiod-1.2/usr/bin/gpiodetect
gpiochip0 [pinctrl-bcm2835] (54 lines)
bjh21@fugloy:/tmp $ ldd /usr/bin/gpiodetect
libgpiod.so.1 => /usr/lib/arm-linux-gnueabihf/libgpiod.so.1 (0xb6f18000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6dca000)
/lib/ld-linux-armhf.so.3 (0xb6f2e000)
bjh21@fugloy:/tmp $ ldd ./gpiod-1.2/usr/bin/gpiodetect
libgpiod.so.2 => /usr/lib/arm-linux-gnueabihf/libgpiod.so.2 (0xb6fb8000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e6a000)
/lib/ld-linux-armhf.so.3 (0xb6fce000)

So they appear to be co-installable, and both work properly when they're 
co-installed.  I can't see any reason why they should interact badly.


--
Ben Harris

Bug#924926: libgpiod2 should not conflict with libgpiod1

[Ben Harris]

Package: libgpiod2
Version: 1.2-3
Severity: normal

Dear Maintainer,

The libgpiod2 package currently conflicts with libgpiod1.  As far as I 
can tell, this is unnecessary.  The two packages share no files and 
provide different SONAMEs, and seem to be co-installable.  I have tried 
installing both (with --force-conflicts) and my program linked against 
libgpiod.so.1 still works.

This conflict is a problem because it means that I can't install the new 
libgpiod-dev and recompile my program against it without first breaking 
the existing version.  This makes a smooth upgrade more difficult than 
it should be.

Debian Policy, in a footnote, has this to say about conflicts between 
versions of shared libraries:

"There are some exceptional situations in which co-installation of two 
versions of a shared library is not safe, and the new shared library 
package has to conflict with the previous shared library package. This 
is never desirable, since it causes significant disruption during 
upgrades and potentially breaks unpackaged third-party binaries, but is 
sometimes unavoidable. These situations are sufficiently rare that they 
usually warrant project-wide discussion, and are complex enough that the 
rules for them cannot be codified in Debian Policy."


I've glanced over the last year of debian-devel and I haven't noticed 
any sign of the expected project-wide discussion.

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

Kernel: Linux 4.19.0-2-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgpiod2 depends on:
ii  libc6   2.28-8
ii  libgcc1 1:8.3.0-2
ii  libstdc++6  8.3.0-2

libgpiod2 recommends no packages.

libgpiod2 suggests no packages.

-- no debconf information

Bug#916516: systemd: timedatectl mangles IPv6 address of NTP server

[Ben Harris]

Control: forwarded -1 https://github.com/systemd/systemd/issues/11169

On Sat, 15 Dec 2018, Michael Biebl wrote:


Since this doesn't look like a Debian specific problem, would you mind
filing this issue upstream at
https://github.com/systemd/systemd/issues


Done: https://github.com/systemd/systemd/issues/11169

--
Ben Harris

Bug#916516: systemd: timedatectl mangles IPv6 address of NTP server

[Ben Harris]

On Sat, 15 Dec 2018, Michael Biebl wrote:


Am 15.12.18 um 11:24 schrieb Ben Harris:

Package: systemd
Version: 239-13
Severity: minor
Tags: ipv6

Dear Maintainer,

I have configured timesyncd to use sntp.cam.ac.uk as an NTP server (see
configuration below).  That name resolves to 2001:630:212:8::123:20.


It resolves to 131.111.8.28 here.
Do you get no IPv4 address for sntp.cam.ac.uk?


The name resolves to both an IPv4 and an IPv6 address.  On my system, 
timesyncd prefers the IPv6 address, so I think the presence or otherwise 
of the IPv4 address is irrelevant to the display bug.


Indeed, the same problem occurs if I explicitly specify the IPv6 address:

wraith:~# grep ^NTP= /etc/systemd/timesyncd.conf
NTP=2001:630:212:8::123:20

wraith:~# timedatectl timesync-status | head -1
   Server: ::2001:630:212:8:0:0 (2001:630:212:8::123:20)

--
Ben Harris

Bug#916516: systemd: timedatectl mangles IPv6 address of NTP server

[Ben Harris]

Package: systemd
Version: 239-13
Severity: minor
Tags: ipv6

Dear Maintainer,

I have configured timesyncd to use sntp.cam.ac.uk as an NTP server (see 
configuration below).  That name resolves to 2001:630:212:8::123:20.  
However, if I run "timedatectl timesync-status" I get a different 
address:

wraith:~$ timedatectl timesync-status | head -1
   Server: ::2001:630:212:8:0:0 (sntp.cam.ac.uk)

Something similar happens if I run "timedatectl show-timesync":

wraith:~$ timedatectl show-timesync | grep ^ServerAddress=
ServerAddress=::2001:630:212:8:0:0

It looks like the NTP server address is being shifted right by 32 bits:

right: 2001:0630:0212:0008:::0123:0020
wrong: ::2001:0630:0212:0008::

Since timesyncd is working (and ::2001:630:212:8:0:0 isn't a working NTP 
server), it seems that the problem is only in the display of IPv6 
addresses in timedatectl.

-- Package-specific info:

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

Kernel: Linux 4.18.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.1-3+b1
ii  libaudit11:2.8.4-2
ii  libblkid12.32.1-0.1
ii  libc62.27-8
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.5-2
ii  libgcrypt20  1.8.4-4
ii  libgnutls30  3.5.19-1+b1
ii  libgpg-error01.32-3
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-2
ii  libkmod2 25-2
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.32.1-0.1
ii  libpam0g 1.1.8-3.8
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  239-13
ii  mount2.32.1-0.1
ii  procps   2:3.3.15-2
ii  util-linux   2.32.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.10-1
ii  libpam-systemd  239-13

Versions of packages systemd suggests:
ii  policykit-10.105-22
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 239-13

-- Configuration Files:
/etc/systemd/timesyncd.conf changed:
[Time]
NTP=sntp.cam.ac.uk


-- no debconf information

Bug#912256: tigervnc-viewer: xtigervncviewer does not use the system X.509 root certificates by default

[Ben Harris]

Package: tigervnc-viewer
Version: 1.9.0+dfsg-1
Severity: normal

Dear Maintainer,

I have a VNC server configured to use VeNCrypt/X509None security.  It
has an X.509 certificate issued by Let's Encrypt (and shared with the
Web server on the system).  If I connect to it like this:

xtigervncviewer cnh.infra.csi.cam.ac.uk

then I get a message telling me that my certificate "has been signed by
an unknown authority".  On the other hand, if I specify a root 
certificate:


xtigervncviewer -X509CA /etc/ssl/certs/DST_Root_CA_X3.pem 
cnh.infra.csi.cam.ac.uk

the viewer connects without complaint.

I would expect, on a Debian system, that a TLS client would use the
system certificate store in /etc/ssl/certs by default, so
xtigervncviewer would connect without complaint without my having to
specify which root certificate to use.  At the very least it should have
an option to use the system certificate store.

By contrast, the "openssl" and "gnutls-cli" commands correctly validate
the server's certificate when they connect to port 443.

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

Kernel: Linux 4.18.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tigervnc-viewer depends on:
ii  libc6  2.27-6
ii  libfltk-images1.3  1.3.4-7
ii  libfltk1.3 1.3.4-7
ii  libfontconfig1 2.13.1-1
ii  libgcc11:8.2.0-7
ii  libgnutls303.5.19-1
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libpam0g   1.1.8-3.8
ii  libstdc++6 8.2.0-7
ii  libx11-6   2:1.6.7-1
ii  libxcursor11:1.1.15-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-2
ii  libxinerama1   2:1.1.4-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-1

tigervnc-viewer recommends no packages.

Versions of packages tigervnc-viewer suggests:
ii  tigervnc-common  1.9.0+dfsg-1

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#876770: ssl: Connecting to TLS 1.0 server is complex and fragile

[Ben Harris]

Package: libpython3.5-minimal
Version: 3.5.4-2
Severity: normal

Dear Maintainer,

Trying to use the "ssl" module to connect to a server that only supports 
TLS 1.0 (confirmed by <https://www.ssllabs.com/ssltest>) leads to an 
error:


wraith:~$ python3
Python 3.5.4 (default, Aug 12 2017, 14:08:14) 
[GCC 7.1.0] on linux

Type "help", "copyright", "credits" or "license" for more information.

import socket, ssl
host = "vc.csi.cam.ac.uk"
ctx = ssl.create_default_context()
ctx.wrap_socket(socket.create_connection((host, 443)), server_hostname=host)

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/ssl.py", line 385, in wrap_socket
_context=self)
  File "/usr/lib/python3.5/ssl.py", line 760, in __init__
self.do_handshake()
  File "/usr/lib/python3.5/ssl.py", line 996, in do_handshake
self._sslobj.do_handshake()
  File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: VERSION_TOO_LOW] version too low (_ssl.c:719)

This does not happen in Python 3.4.2 on oldstable.

The obvious way to enable a deprecated protocol is to modify the context 
options as described in 
/usr/share/doc/python3.5-doc/html/library/ssl.html for SSLv3, but that 
doesn't work:



ctx.options &= ~ssl.OP_NO_TLSv1
ctx.wrap_socket(socket.create_connection((host, 443)), server_hostname=host)

Traceback (most recent call last):
...
ssl.SSLError: [SSL: VERSION_TOO_LOW] version too low (_ssl.c:719)

That's not surprising, since the default options don't include that flag:


ssl.create_default_context().options & ssl.OP_NO_TLSv1

0

The only way I've found to make the connection work is to use the 
deprecated PROTOCOL_TLSv1:



ctx = ssl.SSLContext(protocol=ssl.PROTOCOL_TLSv1)
ctx.wrap_socket(socket.create_connection((host, 443)), server_hostname=host)



But that loses me all of the automatic security I get from 
create_default_context, so I have to re-enable certificate checking and 
perhaps disable some ciphers.  It's also fragile as (if the 
documentation is to be believed) PROTOCOL_TLSv1 _only_ supports TLS 1.0, 
and not TLS 1.1 or TLS 1.2, so if the server is upgraded my code may 
surprisingly break, or at least not transparently upgrade to a newer TLS 
version.


At the very least, the documentation should be updated to describe this 
behaviour, but I think it would be better if it were possible to 
re-enable TLS 1.0 support by modifying a context returned by 
ssl.create_default_context() rather than by re-implementing it.


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

Kernel: Linux 4.11.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libpython3.5-minimal depends on:
ii  libc6  2.24-17
ii  libssl1.1  1.1.0f-5

Versions of packages libpython3.5-minimal recommends:
ii  libpython3.5-stdlib  3.5.4-2

libpython3.5-minimal suggests no packages.

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#862935: installation-reports: vmlinuz missing from armhf netboot SD image

[Ben Harris]

On Sun, 18 Jun 2017, Cyril Brulebois wrote:


This failed to boot on my BeagleBone Black.  Here is the console log: […]


I'm not sure this is the same issue we fixed a few days ago:
 
https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?id=e59da9cf6fe9608102182b596aca9e7fababd8d3

but this is likely. I first thought it affected a specific platform, but
that's actually the common partition.img.gz which is too small?


I think so, yes.


If you have a chance of trying again with Stretch final images, that
would be helpful.


I just did.  I booted the image from:

http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/

today, and it works correctly (at least as far as the installer menu -- I 
don't currently want to overwrite my existing installation).  Thank you.


--
Ben Harris

Bug#864876: uservd leaks a file descriptor into service process

[Ben Harris]

Package: userv
Version: 1.2.0
Severity: minor
Control: found -1 1.1.1

Dear Ian,

When I try to run one of the Linux LVM2 tools through userv, the tool
complains:

wraith:~$ userv --override "execute /sbin/lvs" bjh21 spoo
File descriptor 10 (socket:[5821023]) leaked on lvs invocation. Parent PID 
9592: /usr/sbin/uservd
  WARNING: Running as a non-root user. Functionality may be unavailable.
[...]

That first message appears to be true, as demonstrated by:

wraith:~$ userv --override "execute ls -l /proc/self/fd" bjh21 spoo
total 0
lr-x-- 1 bjh21 bjh21 64 Jun 16 11:09 0 -> /run/userv/257e.257f.0 (deleted)
l-wx-- 1 bjh21 bjh21 64 Jun 16 11:09 1 -> /run/userv/257e.257f.1 (deleted)
lrwx-- 1 bjh21 bjh21 64 Jun 16 11:09 10 -> socket:[5823157]
l-wx-- 1 bjh21 bjh21 64 Jun 16 11:09 2 -> /run/userv/257e.257f.2 (deleted)
lr-x-- 1 bjh21 bjh21 64 Jun 16 11:09 3 -> /proc/9603/fd

I would expect that the service process would only inherit those file
descriptors required by the specification, namely 0, 1, and 2 in the
examples above.  I accept, though, that the spec doesn't say this in so
many words.

If I attach strace to the uservd parent, I can see the offending file
descriptor being opened like this:

[pid  9461] socketpair(AF_UNIX, SOCK_STREAM, 0, [4, 10]) = 0

I think this corresponds with the call from fork_service_synch(), so I
don't think this is a security problem: the parent process doesn't read
from its end of the socket after the service is executed.

I've also found the same behaviour in userv 1.1.1 on Debian GNU/Linux 8
(jessie).

--
Ben Harris, University of Cambridge Information Services.

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

Kernel: Linux 4.9.0-3-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages userv depends on:
ii  libc6  2.24-11

userv recommends no packages.

userv suggests no packages.

-- no debconf information

Bug#862935: installation-reports: vmlinuz missing from armhf netboot SD image

[Ben Harris]

Package: installation-reports
Severity: important

-- Package-specific info:

Boot method: netboot SD-card image
Image version: 
http://ftp.nl.debian.org/debian/dists/testing/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
 [20170407]
Date: 2017-05-18T22:00+01:00

Machine: BeagleBone Black
Partitions:

Disk /dev/mmcblk1: 3.6 GiB, 3825205248 bytes, 7471104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0aa12372

Device Boot   Start End Sectors  Size Id Type
/dev/mmcblk1p1 *   2048  438271  436224  213M 83 Linux
/dev/mmcblk1p2   438272 6483967 6045696  2.9G 83 Linux
/dev/mmcblk1p3  6486014 7469055  983042  480M  5 Extended
/dev/mmcblk1p5  6486016 7469055  983040  480M 82 Linux swap / Solaris

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

Initial boot:   [E]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I installed the system using a serial console from an Ubuntu 16.04 box 
using picocom and GNOME Terminal.  I also used this Ubuntu box for 
downloading and manipulating boot images.


I assembled an image from parts in images/netboot/SD-card-images:

zcat firmware.BeagleBoneBlack.img.gz partition.img.gz | sudo sh -c 'cat > 
/dev/sdc'

This failed to boot on my BeagleBone Black.  Here is the console log:

8<
U-Boot SPL 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51)
Trying to boot from MMC1
MMC partition switch failed
*** Warning - MMC partition switch failed, using default environment



U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - bad CRC, using default environment

 not set. Validating first E-fuse MAC
Net:   cpsw
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
1575 bytes read in 6 ms (255.9 KiB/s)
Running bootscript from mmc0 ...
## Executing script at 8200
Mainline u-boot / new-style environment detected.
This installer medium does not contain a suitable device-tree file for
this system (am335x-boneblack.dtb). Aborting boot process.
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
1575 bytes read in 7 ms (219.7 KiB/s)
## Executing script at 8000
Mainline u-boot / new-style environment detected.
reading vmlinuz
** Unable to read file vmlinuz **
SCRIPT FAILED: continuing...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
1575 bytes read in 6 ms (255.9 KiB/s)
Running bootscript from mmc0 ...
## Executing script at 8200
Mainline u-boot / new-style environment detected.
reading vmlinuz
** Unable to read file vmlinuz **
** Invalid partition 2 **
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
** Unable to read file uEnv.txt **
** File not found /boot/zImage **
## Error: "bootcmd_nand0" not defined
starting USB...
USB0:   Port not available.
cpsw Waiting for PHY auto negotiation to complete. TIMEOUT !
BOOTP broadcast 1
>8

The critical line seems to be "** Unable to read file vmlinuz **". 
Indeed, there's no file called "vmlinuz" on the SD card.  I tried to copy 
on the "vmlinuz" from images/netboot, but that failed:


bjh21@sole:/tmp/debian-stretch-rc3$ sudo cp vmlinuz /media/bjh21/EB55-8514/.
cp: error writing '/media/bjh21/EB55-8514/./vmlinuz': No space left on device

I deleted the partition from the SD card, created a bigger one, and 
installed the contents of the partition image and the vmlinuz file 
referenced above.  This booted successfully.


The first question was a little odd, asking me to select a language for 
the installation process, with a choice between "English" and "C".  There 
wasn't any clear explanation of what "C" meant.


Thereafter, everything went well until the reboot after installation. 
First, the console started emitting "C" characters a few times per second, 
which makes me think of XMODEM.  Maybe I accidentally typed something at 
the wrong moment while putting the MicroSD card away.  Anyway, afterwards 
the GNOME 

Bug#862597: clang-3.9-doc: -doc package contains (almost) no documentation

[Ben Harris]

Package: clang-3.9-doc
Version: 1:3.9.1-8
Severity: grave
Justification: renders package unusable

Dear Maintainer,

According to its description, this package should contain documentation 
for Clang.  It is, however, almost empty:


wraith:~$ dpkg -L clang-3.9-doc
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/clang-3.9-doc
/usr/share/doc/clang-3.9-doc/NEWS.Debian.gz
/usr/share/doc/clang-3.9-doc/changelog.Debian.gz
/usr/share/doc/clang-3.9-doc/copyright

Those files are also in clang-3.9, so this package is almost entirely
useless.  The same problem appears to afflict clang-4.0-doc and
clang-5.0-doc, but not clang-3.8-doc.

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

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

-- no debconf information

Bug#855414: python-pyvmomi-doc: include sample code

[Ben Harris]

Package: python-pyvmomi-doc
Version: 5.5.0-2014.1.1-3
Severity: wishlist

The upstream pyVmomi distribution includes a couple of example Python 
scripts in the "samples" directory.  Could you please include them in 
the python-pyvmomi-doc package, probably in 
/usr/share/doc/python-pyvmomi-doc/examples?  That would make it rather 
easier for a beginner like me to know where to start.


--
Ben Harris, University of Cambridge Information Services.

Bug#835439: gdb --write segfaults on quit in _bfd_elf_strtab_finalize

[Ben Harris]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20948

On Tue, 13 Dec 2016, Hector Oron wrote:

Thanks for the report, I am able to reproduce it with the upcoming 7.12 
package. Could you please forward this one upstream to the GNU GDB 
community and keep this one up to date.


It looks like it's already been reported upstream:

https://sourceware.org/bugzilla/show_bug.cgi?id=20948

--
Ben Harris, University of Cambridge Information Services.

Bug#848067: xorg: Xorg segfault in RRSetChanged at startup with MGA G550

[Ben Harris]

Package: xorg
Version: 1:7.7+7
Severity: important

Dear Maintainer,

I'm attempting to run Xorg on a system with on-board Intel video and an 
add-on PCI Matrix G550 card.  I have configured the system BIOS to use 
the G550 as the primary video card.


In this state, whenever I start Xorg, it segfaults.  Curiously, this 
happens even if I remove xserver-xorg-video-intel or if I remove 
xserver-xorg-video-mga.  I have not tried removing both, but I don't 
expect that to produce a useful X server.


I have followed the instructions for generating a backtrace here:

http://pkg-xorg.alioth.debian.org/howto/use-gdb.html

Note that the xorg.conf incantation to disable "mga" doesn't seem to 
have any effect, but I forgot to remove it.


--
Ben Harris, University of Cambridge Information Services.  Tel: (01223) 748438

GDB backtrace:

#0  0x7fcbcf0c1067 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 2545
selftid = 2545
#1  0x7fcbcf0c2448 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7fcbd1cbdc98,
sa_sigaction = 0x7fcbd1cbdc98}, sa_mask = {__val = {2,
  140726308285808, 140513363119559, 5, 0, 0, 140513328573736, 1,
  140726308285808, 140513374837808, 140513363145445, 0,
  140513328763664, 140513369829824, 140726308285568, 0}},
  sa_flags = -775361120, sa_restorer = 0x7fcbd17b0980}
sigs = {__val = {32, 0 }}
#2  0x7fcbd155762e in OsAbort () at ../../os/utils.c:1361
No locals.
#3  0x7fcbd14324dc in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT)
at ../../../../hw/xfree86/common/xf86Init.c:1088
i = 
#4  0x7fcbd1432596 in AbortDDX (error=error@entry=EXIT_ERR_ABORT)
at ../../../../hw/xfree86/common/xf86Init.c:1132
i = 
#5  0x7fcbd155cef2 in AbortServer () at ../../os/log.c:783
No locals.
#6  0x7fcbd155dd5d in FatalError (
f=f@entry=0x7fcbd1588b28 "Caught signal %d (%s). Server aborting\n")
at ../../os/log.c:924
args = {{gp_offset = 24, fp_offset = 48,
overflow_arg_area = 0x7ffd659dae60,
reg_save_area = 0x7ffd659dad90}}
args2 = {{gp_offset = 8, fp_offset = 48,
overflow_arg_area = 0x7ffd659dae60,
reg_save_area = 0x7ffd659dad90}}
beenhere = 1
#7  0x7fcbd1554f7c in OsSigHandler (signo=11, sip=,
unused=) at ../../os/osinit.c:147
unused = 
sip = 
signo = 11
#8  
No locals.
#9  RRSetChanged (pScreen=0x7fcbd1cb4c40) at ../../randr/randr.c:558
master = 
mastersp = 0x0
#10 0x7fcbd14b6c34 in RRScreenSetSizeRange (
pScreen=pScreen@entry=0x7fcbd1cb4c40, minWidth=,
minHeight=, maxWidth=,
maxHeight=) at ../../randr/rrinfo.c:228
No locals.
#11 0x7fcbd1473925 in xf86RandR12CreateScreenResources12 (
pScreen=0x7fcbd1cb4c40) at ../../../../hw/xfree86/modes/xf86RandR12.c:1580
c = 
pScrn = 
config = 0x7fcbd1cb1c30
#12 xf86RandR12CreateScreenResources (pScreen=pScreen@entry=0x7fcbd1cb4c40)
at ../../../../hw/xfree86/modes/xf86RandR12.c:838
pScrn = 0x7fcbd1cb6060
config = 
c = 
width = 
height = 
mmWidth = 
mmHeight = 
#13 0x7fcbd14664f0 in xf86CrtcCreateScreenResources (screen=0x7fcbd1cb4c40)
at ../../../../hw/xfree86/modes/xf86Crtc.c:712
screen = 0x7fcbd1cb4c40
scrn = 
config = 
#14 0x7fcbd13f5404 in dix_main (argc=2, argv=0x7ffd659db508,
envp=) at ../../dix/main.c:213
pScreen = 0x7fcbd1cb4c40
i = 0
alwaysCheckForInput = {0, 1}
#15 0x7fcbcf0adb45 in __libc_start_main (main=0x7fcbd13df8e0 ,
argc=2, argv=0x7ffd659db508, init=, fini=,
rtld_fini=, stack_end=0x7ffd659db4f8) at libc-start.c:287
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -7903727559547672260,
140513365588197, 140726308287744, 0, 0, 7902298449705576764,
7910519680052767036}, mask_was_saved = 0}}, priv = {pad = {
  0x0, 0x0, 0x7fcbd1561b10 <__libc_csu_init>, 0x7ffd659db508},
data = {prev = 0x0, cleanup = 0x0, canceltype = -782886128}}}
not_first_call = 
#16 0x7fcbd13df90e in _start ()
No symbol table info available.


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

lrwxrwxrwx 1 root root 13 Dec  8 16:34 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2401376 Feb 11  2015 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
04:00.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. 
Millennium G550 [102b:2527] (rev 01)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 46 Dec 13 13:25 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Sect

Bug#234107: Status of @ sign in Morse code

[Ben Harris]

It looks like ITU-R has taken over International Morse Code and it's now 
specified in ITU-R Recommmendation M.1677-1 (10/2009):


http://www.itu.int/rec/R-REC-M.1677-1-200910-I/en

The footnote on page 1 claims that the definition of morse code in ITU-T 
Recommendation F.1 has been withdrawn, which would leave M.1677-1 as the 
best official definition of International Morse Code.


M.1677-1 includes a code for '@', which I hope is definitive enough for 
the maintainer to add it to morse(6).  Of course the manual page will need 
to be updated to refer to the new standard.


--
Ben Harris

Bug#835439: gdb --write segfaults on quit in _bfd_elf_strtab_finalize

[Ben Harris]

Package: gdb
Version: 7.11.1-2
Severity: normal

Dear Maintainer,

When I use "gdb --write" on a trivial executable and immediately type
"quit", GDB segfaults:

wraith:/tmp/hello$ cat > hello.c
#include 

int main(int argc, char **argv)
{

printf("hello, world\n");
return 0;
}
wraith:/tmp/hello$ gcc -o hello hello.c
wraith:/tmp/hello$ gdb --quiet --write hello
Reading symbols from hello...(no debugging symbols found)...done.
(gdb) quit
Segmentation fault
wraith:/tmp/hello$

With gdb-dbg installed and running gdb under gdb, I get this stack
backtrace when doing the same thing:

#0  _bfd_elf_strtab_finalize (tab=0x0)
at /build/gdb-NKZwtf/gdb-7.11.1/bfd/elf-strtab.c:342
#1  0x08321a7b in _bfd_elf_assign_file_positions_for_non_load 
(abfd=0x8755528)

at /build/gdb-NKZwtf/gdb-7.11.1/bfd/elf.c:5840
#2  _bfd_elf_write_object_contents (abfd=0x8755528)
at /build/gdb-NKZwtf/gdb-7.11.1/bfd/elf.c:5876
#3  0x08306a92 in bfd_close (abfd=0x8755528)
at /build/gdb-NKZwtf/gdb-7.11.1/bfd/opncls.c:733
#4  0x082062d7 in gdb_bfd_close_or_warn (abfd=0x8755528)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/gdb_bfd.c:490
#5  gdb_bfd_unref (abfd=0x8755528)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/gdb_bfd.c:618
#6  0x08224275 in exec_close () at 
/build/gdb-NKZwtf/gdb-7.11.1/gdb/exec.c:94

#7  0x082249a3 in exec_close_1 (self=0x86465e0 )
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/exec.c:122
#8  0x0821ad22 in target_close (targ=0x86465e0 )
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/target.c:3318
#9  0x0821aee8 in unpush_target (t=0x86465e0 )
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/target.c:752
#10 0x0821af2c in unpush_target_and_assert (target=0x86465e0 )
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/target.c:762
#11 0x0821afba in pop_all_targets_above (above_stratum=dummy_stratum)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/target.c:776
#12 pop_all_targets () at /build/gdb-NKZwtf/gdb-7.11.1/gdb/target.c:791
#13 0x082b4276 in quit_force (args=0x0, from_tty=1)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/top.c:1578
#14 0x082b31c7 in execute_command (p=, from_tty=1)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/top.c:475
#15 0x081ed993 in command_handler (command=0x8661cb8 "quit")
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-top.c:491
#16 0x081ede52 in command_line_handler (rl=0x87c9008 "")
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-top.c:696
#17 0xb7f8deb2 in rl_callback_read_char ()
   from /lib/i386-linux-gnu/libreadline.so.6
#18 0x081ed9f8 in rl_callback_read_char_wrapper (client_data=0x0)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-top.c:171
#19 0x081eda44 in stdin_event_handler (error=0, client_data=0x0)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-top.c:430
#20 0x081ec1b6 in handle_file_event (file_ptr=0x8798798,
ready_mask=)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-loop.c:708
#21 0x081ec885 in gdb_wait_for_event (block=block@entry=1)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-loop.c:834
#22 0x081eca1b in gdb_do_one_event ()
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-loop.c:323
#23 0x081ecb4e in start_event_loop ()
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/event-loop.c:347
#24 0x081e60c8 in current_interp_command_loop ()
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/interps.c:317
#25 0x081e6b32 in captured_command_loop (data=0x0)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/main.c:318
#26 0x081e38d6 in catch_errors (func=0x81e6b20 ,
func_args=0x0, errstring=0x839d2a5 "", mask=RETURN_MASK_ALL)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/exceptions.c:240
#27 0x081e7713 in captured_main (data=0xb6e0)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/main.c:1157
#28 0x081e38d6 in catch_errors (func=0x81e7080 ,
func_args=0xb6e0, errstring=0x839d2a5 "", mask=RETURN_MASK_ALL)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/exceptions.c:240
#29 0x081e7fc8 in gdb_main (args=0xb6e0)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/main.c:1165
#30 0x08095e77 in main (argc=3, argv=0xb7a4)
at /build/gdb-NKZwtf/gdb-7.11.1/gdb/gdb.c:32

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

Kernel: Linux 4.6.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
ii  libbabeltrace-ctf1  1.4.0-3
ii  libbabeltrace1  1.4.0-3
ii  libc6   2.23-4
ii  libexpat1   2.2.0-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libncurses5 6.0+20160625-1
ii  libpython3.53.5.2-3
ii  libreadline66.3-8+b4
ii  libtinfo5   6.0+20160625-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gdb recommends:
ii  gdbserver 7.11.1-2
ii  libc6-dbg [libc-dbg]  2.23-4

Versions of packages gdb suggests:
pn  gdb-doc  

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#830777: nfs-common: rpc.idmapd does not start under systemd on a pure client system

[Ben Harris]

Package: nfs-common
Version: 1:1.2.8-9.1
Severity: normal

Dear Maintainer,

I have a system that acts as an NFSv4 client.  It does not have
nfs-kernel-server installed.  After a recent reboot, I found that none
of the files in my NFS-mounted home directory was owned by me any more:

bjh21@wraith:~/config/platforms-ansible$ ls -l ~/.ssh
total 609
-rw-r--r-- 1 4294967294 4294967294616 Aug 14  2015 authorized_keys
...

I found that rpc.idmapd was not running, and could not be started:

wraith:/home/bjh21/config/platforms-ansible# service nfs-idmapd status
* nfs-idmapd.service - NFSv4 ID-name mapping service
   Loaded: loaded (/lib/systemd/system/nfs-idmapd.service; static; vendor preset
   Active: inactive (dead)
wraith:/home/bjh21/config/platforms-ansible# service nfs-idmapd start
Failed to start nfs-idmapd.service: Unit nfs-server.service not found.

When I copied /lib/systemd/system/nfs-idmapd.service to 
/etc/systemd/system and commented out the line 
"BindsTo=nfs-server.service", things got better and "service nfs-idmapd 
start" worked.  After a few seconds, my home directory had the correct 
owner:


bjh21@wraith:~/config/platforms-ansible$ ls -l ~/.ssh
total 609
-rw-r--r-- 1 bjh21 bjh21616 Aug 14  2015 authorized_keys

I think that nfs-common should arrange that rpc.idmapd is started even on 
systems without nfs-kernel-server installed, or at least that there is a 
note in NEWS.Debian telling users how to turn it back on.


--
Ben Harris, University of Cambridge Information Services.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
172   udp762  ypbind
171   udp762  ypbind
172   tcp763  ypbind
171   tcp763  ypbind
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = cam.ac.uk
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --

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

Kernel: Linux 4.6.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages nfs-common depends on:
ii  adduser  3.115
ii  init-system-helpers  1.36
ii  libc62.22-13
ii  libcap2  1:2.25-1
ii  libcomerr2   1.43.1-1
ii  libdevmapper1.02.1   2:1.02.127-1
ii  libevent-2.0-5   2.0.21-stable-2+b1
ii  libgssapi-krb5-2 1.14.2+dfsg-1
ii  libk5crypto3 1.14.2+dfsg-1
ii  libkeyutils1 1.5.9-9
ii  libkrb5-31.14.2+dfsg-1
ii  libmount12.28-5
ii  libnfsidmap2 0.25-5
ii  libtirpc10.2.5-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20160629
ii  rpcbind  0.2.3-0.5
ii  ucf  3.0036

Versions of packages nfs-common recommends:
ii  python  2.7.11-2

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- Configuration Files:
/etc/default/nfs-common changed:
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes


-- no debconf information

Bug#797768: systemd: os-release(5) has outdated reference to CPE

[Ben Harris]

Package: systemd
Version: 224-1
Severity: minor
Tags: upstream

Dear Maintainer,

os-release(5) includes this description of the "CPE_NAME" parameter:

   CPE_NAME=
   A CPE name for the operating system, following the Common Platform
   Enumeration Specification[2] as proposed by the MITRE Corporation.
   This field is optional. Example:
   "CPE_NAME="cpe:/o:fedoraproject:fedora:17""

This example name seems to be formatted according to CPE 2.2, which specified a 
single URI-like textual format for CPE Names.  CPE 2.2 was superseded in August 
2011 by CPE 2.3, which specifies an abstract CPE Name and two different textual 
bindings.  By simply referring to "A CPE name", os-release(5) fails to specify 
which of these formats is meant.


I'd suggest that the reference be updated to either explicitly refer to the URI 
binding of a CPE name for the operating system, or to explicitly refer to CPE 2.2. 
Since CPE 2.3 URI bindings are meant to be backward-compatible with CPE 2.2, I'd 
suggest that the former is the better approach.


As of CPE 2.3, it seems that NIST have taken over maintenance of CPE, so the 
reference to MITRE should probably be replaced by a reference to NIST, and the Web 
reference changed to point to <http://scap.nist.gov/specifications/cpe/>.


--
Ben Harris, University of Cambridge Information Services.

-- Package-specific info:

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

Kernel: Linux 4.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.9.2-3
ii  libaudit1   1:2.4.4-1
ii  libblkid1   2.26.2-9
ii  libc6   2.19-19
ii  libcap2 1:2.24-11
ii  libcap2-bin 1:2.24-11
ii  libcryptsetup4  2:1.6.6-5
ii  libgcc1 1:5.1.1-14
ii  libgcrypt20 1.6.3-2
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.26.2-9
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-1
ii  libselinux1 2.3-2+b1
ii  libsystemd0 224-1
ii  mount   2.26.2-9
ii  sysv-rc 2.88dsf-59.2
ii  udev224-1
ii  util-linux  2.26.2-9

Versions of packages systemd recommends:
ii  dbus1.8.20-1
ii  libpam-systemd  224-1

Versions of packages systemd suggests:
pn  systemd-ui  

-- no debconf information

Bug#797768: systemd: os-release(5) has outdated reference to CPE

[Ben Harris]

Control: forwarded -1 https://github.com/systemd/systemd/issues/1121

On Wed, 2 Sep 2015, Michael Biebl wrote:


Since this is an upstream issue, it would be great if you can file a bug
report at https://github.com/systemd/systemd/issues and report back with
the bug number.


Done.  The upstream bug number is 1121, and I've marked this one as 
forwarded to it (see above).


--
Ben Harris, University of Cambridge Information Services.

Bug#795080: sks: cron.daily invokes db_archive, but no dependency on db-util

[Ben Harris]

Package: sks
Version: 1.1.5-4
Severity: normal

The daily cron job for sks is failing on my system, sending me email
that says:

/etc/cron.daily/sks:
/etc/cron.daily/sks: line 29: db_archive: command not found
run-parts: /etc/cron.daily/sks exited with return code 127

It should not be doing this.  The message appears to be from this bit of
/etc/cron.daily/sks:


clean_directory() {
dir=$1
if [ -d $dir ]
then
db_archive -h $dir -d
fi
return 0
}

# The DB directory holds indexes and keys.
clean_directory /var/lib/sks/DB


It looks to me like db_archive is provided by the db-util package, which 
is not installed on my system.  sks depends on db5.3-util, but not on 
db-util.  Maybe sks should be using db5.3_archive explicitly, or maybe it 
should depend on db-util.


--
Ben Harris, University of Cambridge Information Services.

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

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages sks depends on:
ii  adduser 3.113+nmu3
ii  db5.3-util  5.3.28-9
ii  libc6   2.19-19
ii  libdb5.35.3.28-9
ii  logrotate   3.8.7-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

sks recommends no packages.

Versions of packages sks suggests:
ii  exim4-daemon-light [mail-transport-agent]  4.86-2
pn  procmail   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#770492: linux-image-3.16.0-4-686-pae: chown removes security.capability xattr on other users' files

[Ben Harris]

none
pn  firmware-bnx2   none
pn  firmware-bnx2x  none
pn  firmware-brcm80211  none
pn  firmware-intelwimax none
pn  firmware-ipw2x00none
pn  firmware-ivtv   none
pn  firmware-iwlwifinone
pn  firmware-libertas   none
pn  firmware-linux  none
pn  firmware-linux-nonfree  none
pn  firmware-myricomnone
pn  firmware-netxen none
pn  firmware-qlogic none
pn  firmware-ralink none
pn  firmware-realteknone
pn  xen-hypervisor  none

-- debconf information excluded

--
Ben Harris, University of Cambridge Information Services.  Tel: (01223) 334728


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

Bug#764318: libjpeg-progs still needs conflict with libjpeg-turbo-progs

[Ben Harris]

Control: clone -1 -2
Control: reassign -2 libjpeg-turbo-progs/1:1.3.1-3
Control: fixed -2 libjpeg-turbo-progs/1:1.3.1-6
Control: reassign -1 libjpeg-progs/1:9a-2

It looks like it's necessary for the new libjpeg-progs to include a 
conflict with libjpeg-turbo-progs, since at the moment APT tries to 
install them in the wrong order.  On my system at the moment:


wraith:/home/bjh21# dpkg -l 'libjpeg*progs'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  libjpeg-progs  1:1.3.1-3all  Programs for manipulating JPEG fi
ii  libjpeg-turbo- 1:1.3.1-3i386 Programs for manipulating JPEG fi

Both libjpeg-progs 1:9a-2 and libjpeg-turbo-progs 1:1.3.1-6 are available 
to APT, but it chooses to upgrade libjpeg-progs and keep back 
libjpeg-turbo-progs:


wraith:/home/bjh21# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  libjpeg-turbo-progs
The following packages will be upgraded:
  libjpeg-progs
1 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
65 not fully installed or removed.
Need to get 0 B/82.6 kB of archives.
After this operation, 121 kB of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 246510 files and directories currently installed.)
Preparing to unpack .../libjpeg-progs_1%3a9a-2_i386.deb ...
Unpacking libjpeg-progs (1:9a-2) over (1:1.3.1-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/libjpeg-progs_1%3a9a-2_i386.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/exifautotran.1.gz', which is also in 
package libjpeg-turbo-progs 1:1.3.1-3
Errors were encountered while processing:
 /var/cache/apt/archives/libjpeg-progs_1%3a9a-2_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

APT needs to be told that the new libjpeg-progs can't coexist with 
libjpeg-turbo-progs 1:1.3.1-3, which I think requires adding a Conflicts: 
header to libjpeg-progs (or use of alternatives).



I've tried to re-organise this bug report to reflect the fact that changes 
were needed to both packages.  I've reassigned 764318 back to 
libjpeg-progs alone, while there's a new clone to represent the (fixed) 
lack of a Conflicts: header in libjpeg-turbo-progs.  According to the BTS 
documentation, it's only appropriate to have a bug assigned to two 
packages if it can be fixed by a change to either one of those packages. 
In this case, it appears that changes to both packages were required.


--
Ben Harris, University of Cambridge Information Services.


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

Bug#764318: libjpeg-progs still needs conflict with libjpeg-turbo-progs

[Ben Harris]

On Wed, 22 Oct 2014, Bill Allombert wrote:


On Wed, Oct 22, 2014 at 11:12:24AM +0100, Ben Harris wrote:

Control: clone -1 -2
Control: reassign -2 libjpeg-turbo-progs/1:1.3.1-3
Control: fixed -2 libjpeg-turbo-progs/1:1.3.1-6
Control: reassign -1 libjpeg-progs/1:9a-2

It looks like it's necessary for the new libjpeg-progs to include a
conflict with libjpeg-turbo-progs, since at the moment APT tries to
install them in the wrong order.  On my system at the moment:

Both libjpeg-progs 1:9a-2 and libjpeg-turbo-progs 1:1.3.1-6 are
available to APT, but it chooses to upgrade libjpeg-progs and keep
back libjpeg-turbo-progs:


Hello Ben, since the broken libjpeg-turbo-progs/1:1.3.1-3 was never part
of a stable release, this is not strictly necessary: it does not break
the wheezy to jessie upgrade.

Just remove it before perfomring the upgrade.

Since we are very close to the freeze, I would rather dispense with uploading
a work around for the libjpeg-turbo-progs/1:1.3.1-3 breakage.


OK.  Now I have to work out how to undo what I just did to the BTS...

--
Ben Harris, University of Cambridge Information Services.


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

Bug#766105: 486 kernel doesn't boot on net4501; CC_STACKPROTECTOR_NONE helps

[Ben Harris]

On Tue, 21 Oct 2014, Ben Hutchings wrote:


Will custom kernels running on 486es still be supported, or is Debian
intending to desupport the 486 in userland as well?


They might still work.  gcc is now configured to target 586 and above,
but I don't think there are any 586-only instructions that it will
automatically generate.

However, given that this fatal bug has not (so far as I know) been
reported in the 5 years since it was introduced in unstable, I suspect
you're one of a very few people still using Debian on a 486, and you may
find many other things broken.


Actually, I've been running wheezy on an old kernel on another net4501 for 
some months now, and it makes a perfectly adequate DNS and DHCP server. 
It's possible that the rest of the archive is horribly broken, but the 
essential parts seem to work fine.


--
Ben Harris


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

Bug#766105: 486 kernel doesn't boot on net4501; CC_STACKPROTECTOR_NONE helps

[Ben Harris]

On Tue, 21 Oct 2014, Ben Hutchings wrote:


It appears that the stack protector depends on the TSC for
initialisation.  This is not implemented by the Intel 486 or its clones.


Oops.  That suggests that there's an upstream problem as well, since the 
kernel configuration system shouldn't allow you to enable the stack 
protector without disabling 486 support.



We should perhaps have renamed the 486 flavour to 586 when enabling this
feature, but it wasn't noticed at the time.

It's a bit late to change the flavour name for jessie, as it is
unfortunately used in many other places.  I can at least correct the
description.


This will also need an update to the Installation Guide, since it 
currently says that 486 processors are supported:


http://d-i.debian.org/manual/en.i386/ch02s01.html#idp6106384

Will custom kernels running on 486es still be supported, or is Debian 
intending to desupport the 486 in userland as well?


--
Ben Harris


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

Bug#766105: 486 kernel doesn't boot on net4501; CC_STACKPROTECTOR_NONE helps

[Ben Harris]

Package: linux
Version: 3.16.5-1
Version: 3.16.3-2
Version: 3.2.57-3
Version: linux-2.6/2.6.31-1
Severity: important

Attempting to boot the kernel in linux-image-3.16-3-486 on a Soekris 
Engineering net4501 fails.  With console=ttyS0 earlyprintk=serial on the 
kernel command-line, I get the following on the serial console:



Loading Linux 3.16-3-486 ...
Loading initial ramdisk ...
early console in decompress_kernel

Decompressing Linux... Parsing ELF... No relocation needed... done.
Booting the kernel.


No output appears on the console after that.  I'm using grub-pc 
1.99-27+deb7u2, and the BIOS is comBIOS 1.33 (the last one released for 
the net4501).  The net4501 is built around an AMD Élan SC520, which has a 
486 core.


If I recompile the kernel using the following procedure, I get one that 
boots:


$ debian/rules setup
$ make O=debian/build/build_i386_none_486 CC=/usr/lib/ccache/gcc-4.8 menuconfig
  [ disable stack protector (setting CC_STACKPROTECTOR_NONE) ]
$ make -j2 O=debian/build/build_i386_none_486 CC=/usr/lib/ccache/gcc-4.8 bzImage

This suggests that the kernel stack protector is what's causing the 
problem.


The same bug seems to have existed since Debian first enabled the kernel 
stack protector back in 2.6.31.  I've tested the versions listed in the 
pseudo-headers.


--
Ben Harris

Bug#766107: Description refers to wrong file name

[Ben Harris]

Package: kernel-package
Version: 13.014
Severity: minor
Control: found -1 12.036+nmu1

The package description for kernel-package ends with, Please look at
/usr/share/doc/kernel-package/Rationale.gz for a full list of advantages. 
So I tried:


wraith:/tmp/linux$ zless /usr/share/doc/kernel-package/Rationale.gz
gzip: /usr/share/doc/kernel-package/Rationale.gz: No such file or directory

It appears that the file is no longer supplied gzipped, and hence has lost 
its .gz extension.  The description should be updated to match.


--
Ben Harris


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

Bug#765499: Policy still thinks UIDs are 32-bit

[Ben Harris]

Package: debian-policy
Version: 3.9.6.0
Severity: minor

I'm not sure if this is the correct route for a Debian user to raise 
policy issues -- please feel free to redirect me elsewhere.


Policy 9.2.2 lists ranges of UIDs and GIDs and what they're used for in 
Debian.  However, it limits itself to UIDs and GIDs below 65536.  As far 
as I can tell, on a modern Debian GNU/Linux i386 system UIDs and GIDs are 
unsigned 32-bit integers.  In consequence, Policy leaves the status of 
UIDs above 65535 undefined, and mis-states the value of (uid_t)(-1).


I'd suggest that at a minimum this section should be updated to (a) 
explicitly reserve the range from 65536 to 4294967294 inclusive for 
end-users, (b) reserve 4294967295 as the 32-bit (uid_t)(-1), and (c) note 
that 65535 is still reserved for compatibility with systems with 16-bit 
UIDs.


--
Ben Harris, University of Cambridge Information Services.


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

Bug#730430: bdf2psf: does not cope with short bitmap rows in BDF

[Ben Harris]

Package: bdf2psf
Version: 1.102
Severity: normal
Tags: patch

In the BITMAP part of a BDF character definition, trailing zero bytes are 
allowed to be omitted.  However, when a font has them missing, bdf2psf 
ignores the entire glyph.  For instance, converting the 
100dpi-courB10.bdf font from the console-setup-1.102 source distribution 
with this command:


bdf2psf --fb 100dpi-courB10.bdf \
  /usr/share/bdf2psf/standard.equivalents \
  /usr/share/bdf2psf/ascii.set 256 foo.psf

gives a sequence of warnings starting with:

WARNING: U+0020: no glyph defined

Obviously, the font does define a space character -- bdf2psf is just 
ignoring it.  The resulting PSF-format font is almost unusable.


The attached patch solves the problem, but it may be that it also renders 
unnecessary the test for box-drawing and block element characters on the 
previous line.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing') Architecture: i386 (i686)
Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages bdf2psf depends on:
ii  perl  5.18.1-4

bdf2psf recommends no packages.

bdf2psf suggests no packages.

-- no debconf information

--
Ben Harris--- console-setup-1.102/Fonts/bdf2psf.orig	2011-03-19 02:01:10.0 +
+++ console-setup-1.102/Fonts/bdf2psf	2013-11-25 00:02:44.0 +
@@ -463,7 +463,7 @@
 		$row = hex ($1)  -$shiftbits;
 	}
 	if (($u = 0x2500  $u = 0x259f)
-		|| length($1) == 2 * matrix_row_size ()) {
+		|| length($1) = 2 * matrix_row_size ()) {
 		for my $i (1 ... matrix_row_size ()) {
 		push (@glyph_bytes,
 			  ($row  8 * (matrix_row_size () - $i))  0xff);

Bug#726760: e2fsprogs: resize2fs requires ext4 kernel module for ext3 resize

[Ben Harris]

Control: retitle -1 e2fsprogs: resize2fs(8) man page suggests ext3 on-line 
resize always possible

On Sat, 2 Nov 2013, Theodore Ts'o wrote:


The Filesystem does not support online resizing message is emitted
when the resize_inode feature is not set on the file system.  This can
happen because the file system was created without the resize_inode
present, which reserves block group descriptors which are needed so we
can resize the file system with out requiring moving the inode table
blocks (which is not something we can do for an online resize).


That would explain it.  I think this filesystem was created in 1999 as 
ext2, so it's lacking quite a lot of features, resize_inode among them.


I think this is a documentation bug, though -- the man page for resize2fs 
says about on-line resizing:


# If the filesystem is mounted, [resize2fs] can be  used  to  expand  the
# size  of  the  mounted filesystem, assuming the kernel supports on-line
# resizing.  (As of this writing, the Linux 2.6 kernel  supports  on-line
# resize for filesystems mounted using ext3 and ext4.).

I think it would be appropriate for the man page to mention that some ext3 
filesystems can't be resized on-line so as to avoid wild goose chases like 
mine.


--
Ben Harris, University of Cambridge Computing Service.


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

Bug#727112: mt-st: description incorrectly says mt is diverted

[Ben Harris]

Package: mt-st
Version: 1.1-5
Severity: minor

The description for mt-st says:

Mt-st diverts (replaces) the GNU version of mt, in the cpio package.

However, it seems that the mt-st package actually installs an 
alternative for mt, alongside the GNU version.


I'd suggest replacing diverts (replaces) with provides an alternative 
to.


--
Ben Harris, University of Cambridge Computing Service.


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

Bug#726760: e2fsprogs: resize2fs requires ext4 kernel module for ext3 resize

[Ben Harris]

Package: e2fsprogs
Version: 1.42.8-1
Severity: minor

Dear Maintainer,

I have a system with only ext3 filesystems.  When I tried to resize the
root filesystem using resize2fs I got a surprising error message:

wraith:/tmp# resize2fs -p /dev/wraith/root
resize2fs 1.42.8 (20-Jun-2013)
Filesystem at /dev/wraith/root is mounted on /; on-line resizing required
old_desc_blocks = 34, new_desc_blocks = 65
resize2fs: Filesystem does not support online resizing

I poked it with strace and discovered:

access(/sys/fs/ext4/features/meta_bg_resize, R_OK) = -1 ENOENT (No such file 
or directory)
write(2, resize2fs, 9resize2fs)= 9
write(2, : , 2: )   = 2
write(2, Filesystem does not support onli..., 43) = 43

Running modprobe ext4 caused resize2fs to be more willing to run (but it 
failed later):


wraith:/tmp# resize2fs -p /dev/wraith/root
resize2fs 1.42.8 (20-Jun-2013)
Filesystem at /dev/wraith/root is mounted on /; on-line resizing required
old_desc_blocks = 34, new_desc_blocks = 65
Performing an on-line resize of /dev/wraith/root to 16785408 (1k) blocks.
resize2fs: Inappropriate ioctl for device While trying to add group #1088

If resize2fs requires the use of /sys/fs/ext4/features/meta_bg_resize in
order to resize an ext3 filesystem on-line then I think the need to load
the ext4 module should be documented in its man page.

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

Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.42.8-1
ii  libblkid1   2.20.1-5.5
ii  libc6   2.17-93
ii  libcomerr2  1.42.8-1
ii  libss2  1.42.8-1
ii  libuuid12.20.1-5.5
ii  util-linux  2.20.1-5.5

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  none
ii  gpart  0.1h-11+b1
ii  parted 2.3-16

-- no debconf information

--
Ben Harris, University of Cambridge Computing Service.


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

Bug#726655: [PATCH] floppy: Correct documentation of driver options when used as a module.

[Ben Harris]

From: Ben Harris bj...@cam.ac.uk

The options have to be passed space-separated and prefixed by floppy=, 
rather than separately and unprefixed.


This fixes http://bugs.debian.org/726655.

Signed-off-by: Ben Harris bj...@cam.ac.uk
---
This patch is against Linux 3.12-rc5.

--- linux-3.12-rc5/Documentation/blockdev/floppy.txt.orig   2013-10-13 
23:41:28.0 +0100
+++ linux-3.12-rc5/Documentation/blockdev/floppy.txt2013-10-18 
21:03:27.0 +0100
@@ -39,15 +39,15 @@ Module configuration options
 

  If you use the floppy driver as a module, use the following syntax:
-modprobe floppy options
+modprobe floppy floppy=options

 Example:
- modprobe floppy omnibook messages
+ modprobe floppy floppy=omnibook messages

  If you need certain options enabled every time you load the floppy driver,
 you can put:

- options floppy omnibook messages
+ options floppy floppy=omnibook messages

 in a configuration file in /etc/modprobe.d/.

--
Ben Harris, University of Cambridge Computing Service.


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

Bug#726655: linux-doc-3.10: blockdev/floppy.txt.gz incorrectly documents module option syntax

[Ben Harris]

Package: linux-doc-3.10
Version: 3.10.11-1
Severity: normal

Dear Maintainer,

In /usr/share/doc/linux-doc-3.10/Documentation/blockdev/floppy.txt.gz,
the following text appears:

8
 If you use the floppy driver as a module, use the following syntax:
modprobe floppy options

Example:
 modprobe floppy omnibook messages

 If you need certain options enabled every time you load the floppy 
driver,

you can put:

 options floppy omnibook messages

in a configuration file in /etc/modprobe.d/.
8

However, this syntax does not work:

wraith:~# modprobe floppy omnibook messages
ERROR: could not insert 'floppy': Invalid argument

dmesg says:
[ 7459.764805] floppy: `' invalid for parameter `omnibook'

If, on the other hand, I specify:

wraith:~# modprobe floppy floppy=omnibook floppy=messages

the module loads successfully.

Testing the option floppy=0,0,cmos instead provokes a message in dmesg:

[ 7531.667569] floppy0: setting CMOS code to 0

which indicates that this format is actually understood by the driver.

The documentation should be updated to match the option syntax accepted
by the floppy driver:

8
 If you use the floppy driver as a module, use the following syntax:
modprobe floppy options

Example:
 modprobe floppy floppy=omnibook floppy=messages

 If you need certain options enabled every time you load the floppy 
driver,

you can put:

 options floppy floppy=omnibook floppy=messages

in a configuration file in /etc/modprobe.d/.
8

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

Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

-- no debconf information

--
Ben Harris, University of Cambridge Computing Service.


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

Bug#712379: ata_id byteswaps strings: fixed upstream and a patch

[Ben Harris]

Tags: patch

This bug appears to have been fixed by this upstream commit:

https://git.kernel.org/cgit/linux/hotplug/udev.git/commit/src/extras/ata_id/ata_id.c?id=2b2823b4b5c41ec629e346cc6dc8407f1d519eb4

I think that commit appears in udev 181.

I've manually made an equivalent change to udev 175 and it fixes the 
problem for me.  The patch is attached.


--
Ben HarrisIndex: udev-175/extras/ata_id/ata_id.c
===
--- udev-175.orig/extras/ata_id/ata_id.c	2013-06-17 17:33:35.0 +0100
+++ udev-175/extras/ata_id/ata_id.c	2013-06-17 17:35:20.532775727 +0100
@@ -307,8 +307,8 @@
 	assert ((dest_len  1) == 0);
 
 	while (dest_len  0) {
-		c1 = ((uint16_t *) identify)[offset_words]  8;
-		c2 = ((uint16_t *) identify)[offset_words]  0xff;
+		c1 = identify[offset_words * 2 + 1];
+		c2 = identify[offset_words * 2];
 		*dest = c1;
 		dest++;
 		*dest = c2;

Bug#668828: Updating found versions and confirming workaround

[Ben Harris]

found 668828 xserver-xorg-video-nouveau/1:1.0.1-5
thanks

This bug affects my iMac G5 running Debian 7.1 (wheezy).  In my case, the 
main symptom was that emacs23 didn't display any text when moved into the 
bottom half of the screen.  The xorg.conf file in message #45 works around 
the problem for me.


--
Ben Harris


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

Bug#712379: ata_id: strings byteswapped on powerpc

[Ben Harris]

Package: udev
Version: 175-7.2
Severity: normal

Dear Maintainer,

The ata_id helper on my iMac G5 returns garbled strings.  For my SATA 
SSD (attached to a host adaptor using the sata_svw driver) it reports:


root@adamant:~# /lib/udev/ata_id /dev/sda
ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276

I think the string there should begin SAMSUNG_SSD, which suggests that 
ata_id is swapping (or erroneously failing to swap) adjacent pairs of 
characters.  A similar thing happens with my PATA DVD drive (attached to 
a host adaptor using the pata-pci-macio driver):


root@adamant:~# /lib/udev/ata_id /dev/sr0
AMSTIHATVD-D_R_JU8-52

The kernel reports the correct descriptions for the devices at boot time 
(from dmesg):


ata1.00: ATAPI: MATSHITADVD-R   UJ-825, DBN7, max UDMA/66
ata2.00: ATA-7: SAMSUNG SSD UM410 Series 2.5 16GB, VAM12D1Q, max UDMA/100

I think udev got this right when I had the same SSD in my i386 laptop 
running Ubuntu 12.04.


A consequence of this is that the wrong identifiers appear in 
/dev/disk/by-id:


root@adamant:~# ls /dev/disk/by-id
ata-AMSTIHATVD-D_R_JU8-52
ata-ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276
ata-ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276-part1
ata-ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276-part2
ata-ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276-part3
ata-ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276-part4
ata-ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276-part5
scsi-SATA_SAMSUNG_SSD_UM4DCV0900949SE949A2467
scsi-SATA_SAMSUNG_SSD_UM4DCV0900949SE949A2467-part1
scsi-SATA_SAMSUNG_SSD_UM4DCV0900949SE949A2467-part2
scsi-SATA_SAMSUNG_SSD_UM4DCV0900949SE949A2467-part3
scsi-SATA_SAMSUNG_SSD_UM4DCV0900949SE949A2467-part4
scsi-SATA_SAMSUNG_SSD_UM4DCV0900949SE949A2467-part5

Complete ata_id --export output for both devices:

root@adamant:~# /lib/udev/ata_id --export /dev/sda
ID_ATA=1
ID_TYPE=disk
ID_BUS=ata
ID_MODEL=ASSMNU_GSS_DMU14_0eSirse2_5.__61BG
ID_MODEL_ENC=ASSMNU\x20GSS\x20DMU14\x200eSirse2\x205.\x20\x2261BG\x20\x20\x20\x20\x20\x20
ID_REVISION=AV1MD2Q1
ID_SERIAL=ASSMNU_GSS_DMU14_0eSirse2_5.__61BG_CD0V099094ES49A94276
ID_SERIAL_SHORT=CD0V099094ES49A94276
ID_ATA_WRITE_CACHE=1
ID_ATA_WRITE_CACHE_ENABLED=1
ID_ATA_FEATURE_SET_HPA=1
ID_ATA_FEATURE_SET_HPA_ENABLED=1
ID_ATA_FEATURE_SET_PM=1
ID_ATA_FEATURE_SET_PM_ENABLED=1
ID_ATA_FEATURE_SET_SECURITY=1
ID_ATA_FEATURE_SET_SECURITY_ENABLED=0
ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6
ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=6
ID_ATA_FEATURE_SET_SMART=1
ID_ATA_FEATURE_SET_SMART_ENABLED=1
ID_ATA_FEATURE_SET_AAM=1
ID_ATA_FEATURE_SET_AAM_ENABLED=1
ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128
ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=254
ID_ATA_DOWNLOAD_MICROCODE=1
ID_ATA_SATA=1
ID_ATA_SATA_SIGNAL_RATE_GEN2=1
ID_ATA_SATA_SIGNAL_RATE_GEN1=1
ID_ATA_ROTATION_RATE_RPM=0
root@adamant:~# /lib/udev/ata_id --export /dev/sr0
ID_ATA=1
ID_TYPE=cd
ID_BUS=ata
ID_MODEL=AMSTIHATVD-D_R_JU8-52
ID_MODEL_ENC=AMSTIHATVD-D\x20R\x20\x20JU8-52\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_REVISION=BD7N
ID_SERIAL=AMSTIHATVD-D_R_JU8-52

-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc64)

Kernel: Linux 3.2.0-4-powerpc64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udev depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38
ii  libselinux12.1.9-5
ii  libudev0   175-7.2
ii  lsb-base   4.1+Debian8
ii  procps 1:3.3.3-3
ii  util-linux 2.20.1-5.3

Versions of packages udev recommends:
ii  pciutils  1:3.1.9-6
ii  usbutils  1:005-3

udev suggests no packages.

-- debconf information excluded

--
Ben Harris


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

Bug#653390: This may be a duplicate

[Ben Harris]

This bug seems to be an instance of bug #650588, so it should probably be 
reassigned to hw-detect and merged.  I'm not quite confident enough to do 
that myself.


--
Ben Harris


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

Bug#688252: vipw uses vi by default; should use /usr/bin/editor

[Ben Harris]

Package: passwd
Version: 1:4.1.5.1-1
Severity: minor

Policy section 11.4 says that every program that launches an editor should 
fall back to /usr/bin/editor.  vipw, though, always falls back to vi.


Fixing this is trivial in the code, but slightly more involved in the 
documentation since all the translated man pages for vipw(8) need to be 
updated.


--
Ben Harris, University of Cambridge Computing Service.


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

Bug#688260: vipw: Erroneous No such file or directory error when editor fails

[Ben Harris]

Package: passwd
Version: 1:4.1.5.1-1
Severity: minor

If the editor invoked by vipw(8) exits with a non-zero exit status, vipw 
reports two spurious No such file or directory errors:


wraith:~# EDITOR=false vipw
vipw: false: No such file or directory
vipw: false: No such file or directory
vipw: /etc/passwd is unchanged

Looking at the source code, I think the first message comes from this bit 
of code in vipwedit():


if (system (buf) != 0) {
fprintf (stderr, %s: %s: %s\n, Prog, editor,
 strerror (errno));
exit (1);
} else {
exit (0);
}

This is wrong, because system() only sets errno when it returns -1 (to 
indicate a failure to fork), and not when it returns the child process's 
exit status.


The second message comes from this code a little later:

if (   (-1 == pid)
|| (WIFEXITED (status) == 0)
|| (WEXITSTATUS (status) != 0)) {
vipwexit (editor, 1, 1);

While a return value of -1 from waitpid() will set errno, a successful 
return of a non-zero exit status will not.


--
Ben Harris, University of Cambridge Computing Service.


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

Bug#679387: TypeError: pull() got an unexpected keyword argument 'show_base'

[Ben Harris]

Package: bzr-svn
Version: 1.2.1-1
Severity: minor

Running bzr pull branch on a Subversion checkout generated a stack
backtrace and the following error:

bzr: ERROR: exceptions.TypeError: pull() got an unexpected keyword argument 
'show_base'

I don't necessarily expect this to work, but a nicer error message would 
be good, hence priority minor.


Full steps to reproduce below:

wraith:/tmp/pull-bug$ bzr init bzr
Created a standalone tree (format: 2a)
wraith:/tmp/pull-bug$ svnadmin create svn-repo
wraith:/tmp/pull-bug$ svn mkdir -m '' file://${PWD}/svn-repo/trunk

Committed revision 1.
wraith:/tmp/pull-bug$ svn checkout file://${PWD}/svn-repo/trunk svn-checkout
Checked out revision 1.
wraith:/tmp/pull-bug$ cd svn-checkout
wraith:/tmp/pull-bug/svn-checkout$ bzr pull ../bzr
Initialising Subversion metadata cache in 
/home/bjh21/.bazaar/svn-cache/51b7064b-8ce7-457f-aaa6-716cb730721e.

bzr: ERROR: exceptions.TypeError: pull() got an unexpected keyword argument 
'show_base'

Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 930, in 
exception_to_return_code
return the_callable(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 1141, in 
run_bzr
ret = run(*run_argv)
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 673, in 
run_argv_aliases
return self.run(**all_cmd_args)
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 697, in run
return self._operation.run_simple(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/cleanup.py, line 136, in 
run_simple
self.cleanups, self.func, *args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/cleanup.py, line 166, in 
_do_with_cleanups
result = func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/builtins.py, line 1244, in run
local=local, show_base=show_base)
TypeError: pull() got an unexpected keyword argument 'show_base'

bzr 2.6.0dev2 on python 2.7.3rc2 (Linux-3.2.0-2-686-pae-i686-with-debian-
wheezy-sid)
arguments: ['/usr/bin/bzr', 'pull', '../bzr']
plugins: bash_completion[2.6.0dev2], bzrtools[2.5.0],
changelog_merge[2.6.0dev2], dbus[0.1.0dev], git[0.6.9], 
gtk[0.104.0dev],

launchpad[2.6.0dev2], netrc_credential_store[2.6.0dev2],
news_merge[2.6.0dev2], po_merge[2.6.0dev2], search[1.7.0dev],
svn[1.2.1],
weave_fmt[2.6.0dev2]
encoding: 'ascii', fsenc: 'utf8', lang: None

*** Bazaar has encountered an internal error.  This probably indicates a
bug in Bazaar.  You can help us fix it by filing a bug report at
https://bugs.launchpad.net/bzr/+filebug
including this traceback and a description of the problem.


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

Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages bzr-svn depends on:
ii  python2.7.3~rc2-1
ii  python-bzrlib 2.6.0~bzr6522-1
ii  python-subvertpy  0.8.10-2
ii  python2.6 2.6.7-4
ii  python2.7 2.7.3~rc2-2.1

Versions of packages bzr-svn recommends:
ii  bzr 2.6.0~bzr6522-1
ii  python-tdb  1.2.10-2
ii  python-xdg  0.19-4

Versions of packages bzr-svn suggests:
pn  bzr-rewrite  none

-- no debconf information


--
Ben Harris, University of Cambridge Computing Service.



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

Bug#669012: libdpkg-perl: Memory leak: Dpkg::Control objects not garbage-collected

[Ben Harris]

Package: libdpkg-perl
Version: 1.16.2
Severity: normal
Tags: patch

When I run a Perl script that repeatedly creates unreferenced 
Dpkg::Control objects, the perl process (as shown in top) consumes 
memory without limit.


A one-line sample:

  perl -MDpkg::Control -e 'Dpkg::Control-new while 1'

I would expect a script like this to have a constant memory usage, as the 
Dpkg::Control objects are garbage-collected soon after being created. 
What I find, though is that after running for thirty seconds, perl has 
consumed over 100 MB of memory.


By contrast, the same test using Dpkg::Index consumes a constant 6 MB.

This problem effectively means that a process can't operate on a large 
number of Dpkg::Control objects sequentially.  I discovered this when I 
wrote a program that iterated over all the packages in every current 
Ubuntu release and my system ran out of memory.


The cause of the problem appears to the a circular reference between a 
Dpkg::Control::Hash and its contained tied hash.  I've attached a patch 
that explicitly breaks this loop when a Dpkg::Control::Hash is destroyed, 
following the advice in perlobj(1).  This appears to solve the memory leak 
and to pass debian/rules check.


--
Ben Harris, University of Cambridge Computing Service.

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

Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages libdpkg-perl depends on:
ii  dpkg  1.16.2
ii  libtimedate-perl  1.2000-1
ii  perl  5.14.2-9

Versions of packages libdpkg-perl recommends:
ii  bzip2 1.0.6-1
ii  xz-utils  5.1.1alpha+20110809-3

Versions of packages libdpkg-perl suggests:
ii  binutils2.22-6
ii  debian-keyring  2012.02.22
ii  gnupg   1.4.12-4
ii  gpgv1.4.12-4
ii  patch   2.6.1-3

-- no debconf information
--- /usr/share/perl5/Dpkg/Control/Hash.pm	2012-03-19 08:16:14.0 +
+++ /home/bjh21/dmerge/Dpkg/Control/Hash.pm	2012-04-16 15:07:50.733028819 +0100
@@ -119,6 +119,16 @@
 return $self;
 }
 
+# There is naturally a circular reference between the tied hash and its
+# containing object.  Happily, the extra layer of scalar reference can
+# be used to detect the destruction of the object and break the loop so
+# that everything gets garbage-collected.
+
+sub DESTROY {
+my ($self) = @_;
+delete $$self-{'fields'};
+}
+
 =item $c-set_options($option, %opts)
 
 Changes the value of one or more options.
@@ -392,9 +402,10 @@
 }
 
 # $self-[0] is the real hash
-# $self-[1] is an array containing the ordered list of keys
-# $self-[2] is an hash describing the relative importance of each field
-# (used to sort the output).
+# $self-[1] is a reference to the hash contained by the parent object.
+# This reference bypasses the top-level scalar reference of a
+# Dpkg::Control::Hash, hence ensuring that that reference gets DESTROYed
+# properly.
 
 # Dpkg::Control::Hash-new($parent)
 #
@@ -412,7 +423,7 @@
 my ($class, $parent) = @_;
 die Parent object must be Dpkg::Control::Hash
 if not $parent-isa(Dpkg::Control::Hash);
-return bless [ {}, $parent ], $class;
+return bless [ {}, $$parent ], $class;
 }
 
 sub FETCH {
@@ -427,7 +438,7 @@
 my $parent = $self-[1];
 $key = lc($key);
 if (not exists $self-[0]-{$key}) {
-	push @{$$parent-{'in_order'}}, field_capitalize($key);
+	push @{$parent-{'in_order'}}, field_capitalize($key);
 }
 $self-[0]-{$key} = $value;
 }
@@ -441,7 +452,7 @@
 sub DELETE {
 my ($self, $key) = @_;
 my $parent = $self-[1];
-my $in_order = $$parent-{'in_order'};
+my $in_order = $parent-{'in_order'};
 $key = lc($key);
 if (exists $self-[0]-{$key}) {
 	delete $self-[0]-{$key};
@@ -455,7 +466,7 @@
 sub FIRSTKEY {
 my $self = shift;
 my $parent = $self-[1];
-foreach (@{$$parent-{'in_order'}}) {
+foreach (@{$parent-{'in_order'}}) {
 	return $_ if exists $self-[0]-{lc($_)};
 }
 }
@@ -464,7 +475,7 @@
 my ($self, $last) = @_;
 my $parent = $self-[1];
 my $found = 0;
-foreach (@{$$parent-{'in_order'}}) {
+foreach (@{$parent-{'in_order'}}) {
 	if ($found) {
 	return $_ if exists $self-[0]-{lc($_)};
 	} else {

Bug#665640: fuse-emulator-sdl: fuse aborts when pressing joystick button 10

[Ben Harris]

On Sun, 25 Mar 2012, Alberto Garcia wrote:


On Sat, Mar 24, 2012 at 08:59:56PM +, Ben Harris wrote:


The first ten buttons (numbered 0-9) seem to get interpreted by Fuse
correctly, but if I press the eleventh button, fuse displays an
error message, and when I press a key, aborts.


I've just taken a quick look at the code, and with the information
that you provide I'd say that this has already been fixed upstream:

http://fuse-emulator.svn.sourceforge.net/viewvc/fuse-emulator/trunk/fuse/ui/sdl/sdljoystick.c?r1=4259r2=4258pathrev=4259

However I don't have a joystick to verify it. Can you recompile Fuse
with that patch and see if it works for you? If it does I'll make a
new release.


I've applied that patch, and it seems to work correctly.  Thanks for 
finding it.


--
Ben Harris



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

Bug#665640: fuse-emulator-sdl: fuse aborts when pressing joystick button 10

[Ben Harris]

Package: fuse-emulator-sdl
Version: 1.0.0.1a+dfsg1-3
Severity: normal

I have a PlayStation 3 controller connected to my computer by USB.  It
presents as a 19-button, 28-axis joystick.  The first ten buttons
(numbered 0-9) seem to get interpreted by Fuse correctly, but if I
press the eleventh button, fuse displays an error message, and when I
press a key, aborts.

The message is:

fuse: error: get_fire_button_key: which = 0, button = 4366
Aborted

--
Ben Harris

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

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fuse-emulator-sdl depends on:
ii  fuse-emulator-comm 1.0.0.1a+dfsg1-3  The Free Unix Spectrum Emulator (c
ii  libc6  2.11.3-2  Embedded GNU C Library: Shared lib
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libpng12-0 1.2.44-1+squeeze3 PNG library - runtime
ii  libsdl1.2debian1.2.14-6.1Simple DirectMedia Layer
ii  libspectrum8   1.0.0-2+b1ZX Spectrum emulator library - Sha
ii  libxml22.7.8.dfsg-2+squeeze3 GNOME XML library
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

fuse-emulator-sdl recommends no packages.

fuse-emulator-sdl 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#611292: insserv treats corekeeper as invalid file name, inconsistent with manual's *.core unaccepted filename.

[Ben Harris]

The proposed patch is wrong: as written it arranges to reject filenames 
that begin with .core, rather than those that end with .core.  Files 
whose names end .core are already rejected by cfgfile_filter(), and 
files whose names begin .core are rejected by the general rejection of 
filenames beginning with ..


I think the original test is intended to trap old-style core dumps, which 
are always called simply core.  This could be correctly achieved by:


--- insserv.c.orig  2010-02-19 13:08:04.0 +
+++ insserv.c   2012-02-27 12:10:01.0 +
@@ -2764,7 +2764,7 @@
continue;
}

-   if (!strncmp(d-d_name, core, strlen(core))) {
+   if (!strcmp(d-d_name, core)) {
if (isarg)
warn(script name %s is not valid, skipped!\n, d-d_name);
continue;

--
Ben Harris, University of Cambridge Computing Service.



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

Bug#654714: libnfsidmap2: should replace/break old nfs-common

[Ben Harris]

Package: libnfsidmap2
Version: 0.25-1

Because of incompatibilities with my NFS server, I'm running an old 
version of nfs-common (1:1.1.2-6lenny2).  When aptitude attempts to 
install libnfsidmap2, it gets the following error:


(Reading database ... 239571 files and directories currently installed.)
Preparing to replace libnfsidmap2 0.24-1 (using 
.../libnfsidmap2_0.25-1_i386.deb) ...
Unpacking replacement libnfsidmap2 ...
dpkg: error processing /var/cache/apt/archives/libnfsidmap2_0.25-1_i386.deb 
(--install):
 trying to overwrite '/usr/share/man/man5/idmapd.conf.5.gz', which is also in 
package nfs-common 1:1.1.2-6lenny2
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/libnfsidmap2_0.25-1_i386.deb

My reading of Debian Policy, section 7.6.1, is that this should be 
indicated by Breaks and Replaces relations from libnfsidmap2 to 
versions of nfs-common old enough to still contain that file.  This would 
allow APT to work out that it shouldn't try to upgrade libnfsidmap2.


--
Ben Harris, University of Cambridge Computing Service.



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

Bug#649588: Workaround

[Ben Harris]

FYI, I tried following this instruction in apt.conf(5): it should be 
tried to explicitly install the package APT is unable to configure 
immediately.  Specifically, I manually ran:


dpkg -i --auto-deconfigure /var/cache/apt/archives/perl-modules_5.14.2-5_all.deb
dpkg --auto-deconfigure -i /var/cache/apt/archives/perl_5.14.2-5_i386.deb
dpkg --auto-deconfigure -i /var/cache/apt/archives/perl-base_5.14.2-5_i386.deb

The latter two were because having the old versions prevented perl-modules 
from configuring and having a half-upgraded perl worried me.  After that, 
apt-get -f dist-upgrade worked.


--
Ben Harris, University of Cambridge Computing Service.



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

Bug#649588: apt: Could not perform immediate configuration on 'perl-modules'

[Ben Harris]

Package: apt

Version: 0.8.15.9
Severity: normal

Dear Maintainer,

When running apt-get dist-upgrade, I got a run of messages (below) ending
with:

E: Could not perform immediate configuration on 'perl-modules'. Please see man 
5 apt.conf under APT::Immediate-Configure for details. (2)

Looking that up, I find:

   please make sure to report your problem
   also to your distribution and to the APT team with the buglink
   below so they can work on improving or correcting the upgrade
   process.

so I'm doing so.  I assume that this counts as a report to both Debian and
the APT team.

Here's the full apt-get output:

wraith:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree 
Reading state information... Done

Calculating upgrade... Done
The following packages will be REMOVED:
  libextutils-cbuilder-perl libextutils-parsexs-perl libparent-perl
  libperl5.12
The following NEW packages will be installed:
  libfreexl1 libperl5.14 libspatialite3 libx11-doc linux-image-3.1.0-1-686-pae
The following packages have been kept back:
  nfs-common
The following packages will be upgraded:
  doc-base exim4-base exim4-daemon-light gir1.2-networkmanager-1.0
  gir1.2-upowerglib-1.0 gnumeric graphviz imagemagick ldap-utils
  libalgorithm-diff-xs-perl libapt-pkg-perl libauthen-pam-perl
  libbit-vector-perl libcache-fastmmap-perl libcairo-perl libcdt4 libcgraph5
  libclass-xsaccessor-perl libclone-perl libcompress-raw-bzip2-perl
  libcompress-raw-zlib-perl libcrypt-blowfish-perl libcrypt-rijndael-perl
  libcrypt-ssleay-perl libdatetime-perl libdbd-pg-perl libdbd-sqlite3-perl
  libdbi-perl libdevel-caller-perl libdevel-globaldestruction-perl
  libdigest-sha1-perl libfcgi-perl libfile-fnmatch-perl libfont-freetype-perl
  libfuse-perl libgdal1-1.7.0 libgdal1-dev libglib-perl libgnome2-canvas-perl
  libgnome2-perl libgnome2-vfs-perl libgraph4 libgtk2-perl libgvc5 libgvpr1
  libhtml-parser-perl libio-pty-perl libipc-sharelite-perl libldap-2.4-2
  libldap2-dev liblinux-inotify2-perl liblist-moreutils-perl
  liblocale-gettext-perl libmagick++4 libmagickcore4 libmagickcore4-extra
  libmagickwand4 libmoose-perl libmoosex-role-withoverloading-perl
  libnet-dns-perl libnet-libidn-perl libnet-ssleay-perl libnm-glib4
  libnm-util2 libnss3-1d libossp-uuid-perl libossp-uuid16
  libpackage-stash-xs-perl libpadwalker-perl libpango-perl libpar-packer-perl
  libparams-classify-perl libparams-util-perl libparams-validate-perl
  libpathplan4 libpq-dev libpq5 libpthread-stubs0 libpthread-stubs0-dev
  librasterlite1 librdf0 libscope-upper-perl libset-object-perl libsnmp-perl
  libsnmp15 libsocket6-perl libspatialite-dev libsub-identify-perl
  libsub-name-perl libsvn-perl libsvn1 libtemplate-perl libterm-readkey-perl
  libterm-readline-gnu-perl libterm-slang-perl libtext-charwidth-perl
  libtext-iconv-perl libupower-glib1 libuuid-perl libv4l-0 libv4lconvert0
  libvariable-magic-perl libversion-perl libwxbase2.8-0 libwxgtk2.8-0 libx11-6
  libx11-data libx11-dev libx11-xcb1 libxdot4 libxml-libxml-perl
  libxml-libxslt-perl libxml-parser-perl libyaml-libyaml-perl
  libyaml-syck-perl linux-image-2.6-686 linux-image-686-pae linux-libc-dev
  perl perl-base perl-doc perl-modules perl-tk policykit-1-gnome snmp
  subversion upower vim vim-common vim-runtime
130 upgraded, 5 newly installed, 4 to remove and 1 not upgraded.
Need to get 109 MB of archives.
After this operation, 63.5 MB of additional disk space will be used.
Do you want to continue [Y/n]? 
Get:1 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main doc-base all 0.10.3 [102 kB]

Get:2 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main libperl5.14 
i386 5.14.2-5 [724 kB]
Get:3 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libpar-packer-perl i386 1.010-1+b1 [1960 kB]
Get:4 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libsnmp-perl i386 5.4.3~dfsg-2.3+b1 [128 kB]
Get:5 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main libsnmp15 
i386 5.4.3~dfsg-2.3+b1 [2043 kB]
Get:6 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libdevel-globaldestruction-perl all 0.04-2 [7348 B]
Get:7 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libtext-charwidth-perl i386 0.04-7+b1 [11.1 kB]
Get:8 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libpackage-stash-xs-perl i386 0.24-1+b1 [19.7 kB]
Get:9 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
liblist-moreutils-perl i386 0.33-1+b1 [50.5 kB]
Get:10 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libcompress-raw-bzip2-perl i386 2.040-1+b1 [30.8 kB]
Get:11 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libyaml-libyaml-perl i386 0.37-1+b1 [76.7 kB]
Get:12 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libclass-xsaccessor-perl i386 1.12-1+b1 [43.9 kB]
Get:13 http://www-uxsup.csx.cam.ac.uk/pub/linux/debian/ testing/main 
libhtml-parser-perl i386 

Bug#515754: acknowledged by developer (closing 515754)

[Ben Harris]

On Tue, 8 Nov 2011, Debian Bug Tracking System wrote:


This is an automatic notification regarding your Bug report
#515754: nfs-common: Mounting with sec=krb5p fails with access denied by server 
while mounting,
which was filed against the nfs-common package.

It has been marked as closed by one of the developers, namely
Luk Claes l...@debian.org.


Thank you for the notification.  I presume this means that there is no bug 
in nfs-common, and that the inability to mount Kerberized filesystems from 
my Solaris server is intended behaviour.  Is this a bug in Solaris that I 
should be chasing up with Oracle, or is it simply expected that non-Debian 
NFS servers will no longer work with Debian clients?


--
Ben Harris, University of Cambridge Computing Service.



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

Bug#588915: postinst: /usr/sbin/update-initramfs: line 199: do_b: unbound variable

[Ben Harris]

I can confirm that, having upgraded initramfs-tools, my system now manages 
to configure the package correctly and build a working initrd.  Thanks for 
fixing the problem.


--
Ben Harris, University of Cambridge Computing Service.



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

Bug#588915: postinst: /usr/sbin/update-initramfs: line 199: do_b: unbound variable

[Ben Harris]

Package: initramfs-tools
Version: 0.97.2

When configuring initramfs-tools, this happens:

wraith:~# dpkg --configure initramfs-tools
Setting up initramfs-tools (0.97.2) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.32-5-686
/usr/sbin/update-initramfs: line 199: do_b: unbound variable
dpkg: error processing initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 initramfs-tools

Until recently, this system has been running locally-compiled kernels.  I 
recently installed a packaged kernel, linux-image-2.6.32-5-686 version 
2.6.32-15, and this pulled in initramfs-tools for the first time, which 
failed on configuration.


I suspect there's _something_ unusual about my system that causes this 
problem, but better reporting of what it is would be nice.


--
Ben Harris, University of Cambridge Computing Service.



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

Bug#588915: postinst: /usr/sbin/update-initramfs: line 199: do_b: unbound variable

[Ben Harris]

On Tue, 13 Jul 2010, Michael Prokop wrote:


But sadly you didn't provide details about your configuration as
suggested by reportbug. So please provide at least content of
/etc/kernel-img.conf and /etc/initramfs-tools/update-initramfs.conf


Sorry.  This bug (in combination with a bunch of other circumstances) 
means that my normal home directory is AWOL on that machine, and reportbug 
doesn't like being run as root, so I constructed the bug report by hand.


Anyway, I don't have an /etc/kernel-img.conf.  I've attached 
/etc/initramfs-tools/update-initramfs.conf.  FWIW, all the other conffiles 
for initramfs-tools appear to be unmodified as well.


--
Ben Harris, University of Cambridge Computing Service.  Tel: (01223) 334728#
# Configuration file for update-initramfs(8)
#

#
# update_initramfs [ yes | all | no ]
#
# Default is yes
# If set to all update-initramfs will update all initramfs
# If set to no disables any update to initramfs beside kernel upgrade

update_initramfs=yes

#
# backup_initramfs [ yes | no ]
#
# Default is no
# If set to no leaves no .bak backup files.

backup_initramfs=no

Bug#584531: aptitude: Couldn't clean out list directories if current directory inaccessible

[Ben Harris]

Package: aptitude
Version: 0.6.1.5-3
Severity: normal

On my system, users' home directories are mounted by NFS and aren't
accessible by root.  This seems to upset aptitude if I run aptitude update
when su'ed to root in my home directory:

wraith:/home/bjh21# aptitude update
Hit http://www-uxsup.csx.cam.ac.uk testing Release.gpg
Hit http://www-uxsup.csx.cam.ac.uk testing Release
Hit http://www-uxsup.csx.cam.ac.uk testing/main Packages/DiffIndex
Hit http://www-uxsup.csx.cam.ac.uk testing/contrib Packages/DiffIndex
Hit http://www-uxsup.csx.cam.ac.uk testing/non-free Packages/DiffIndex
E: Unable to change to /home/bjh21/ - chdir (13: Permission denied)
E: Couldn't clean out list directories

I can't see that aptitude has any reason to chdir into my home directory, so
it really shouldn't fail when that turns out to be impossible.

From gdb, it looks like the failing call to chdir comes from
pkgAcquire::Clean(std::string).  I've not looked at the source to see how
easy it would be to fix.

-- Package-specific info:
aptitude 0.6.1.5 compiled at Mar 12 2010 09:52:06
Compiler: g++ 4.4.3
Compiled against:
  apt version 4.8.0
  NCurses version 5.7
  libsigc++ version: 2.2.4.2
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20100313
  cwidget version: 0.5.16
  Apt version: 4.8.0
linux-gate.so.1 =  (0xe000)
libapt-pkg-libc6.9-6.so.4.8 = /usr/lib/libapt-pkg-libc6.9-6.so.4.8 
(0xb7e63000)
libncursesw.so.5 = /lib/libncursesw.so.5 (0xb7e1d000)
liblog4cxx.so.10 = /usr/lib/liblog4cxx.so.10 (0xb7c77000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7c71000)
libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7bb1000)
libept.so.0 = /usr/lib/libept.so.0 (0xb7b3d000)
libxapian.so.15 = /usr/lib/libxapian.so.15 (0xb79ed000)
libz.so.1 = /usr/lib/libz.so.1 (0xb79d9000)
libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0xb7955000)
libboost_iostreams.so.1.40.0 = /usr/lib/libboost_iostreams.so.1.40.0 
(0xb794a000)
libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb793)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb783b000)
libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7815000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb77f7000)
libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb76b)
libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb76ac000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb76a7000)
libaprutil-1.so.0 = /usr/lib/libaprutil-1.so.0 (0xb7687000)
libdb-4.8.so = /usr/lib/libdb-4.8.so (0xb7521000)
libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0xb74f3000)
libbz2.so.1.0 = /lib/libbz2.so.1.0 (0xb74e2000)
librt.so.1 = /lib/i686/cmov/librt.so.1 (0xb74d8000)
/lib/ld-linux.so.2 (0xb7f4)
libuuid.so.1 = /lib/libuuid.so.1 (0xb74d4000)
libcrypt.so.1 = /lib/i686/cmov/libcrypt.so.1 (0xb74a2000)
libexpat.so.1 = /usr/lib/libexpat.so.1 (0xb747c000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

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

Kernel: Linux 2.6.27.9 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6.9 0.7.25.3 Advanced front-end for dpkg
ii  libboost-iostreams1.40. 1.40.0-6+b1  Boost.Iostreams Library
ii  libc6   2.10.2-9 Embedded GNU C Library: Shared lib
ii  libcwidget3 0.5.16-3 high-level terminal interface libr
ii  libept0 0.5.30   High-level library for managing De
ii  libgcc1 1:4.4.4-1GCC support library
ii  liblog4cxx100.10.0-1.1   A logging library for C++
ii  libncursesw55.7+20100313-2   shared libraries for terminal hand
ii  libsigc++-2.0-0c2a  2.2.4.2-1type-safe Signal Framework for C++
ii  libsqlite3-03.6.23.1-2   SQLite 3 shared library
ii  libstdc++6  4.4.4-1  The GNU Standard C++ Library v3
ii  libxapian15 1.0.20-2 Search engine library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages aptitude recommends:
ii  apt-xapian-index  0.30   maintenance tools for a Xapian ind
pn  aptitude-doc-en | aptitude-do none (no description available)
ii  libparse-debianchangelog-perl 1.1.1-2parse Debian changelogs and output
ii  sensible-utils0.0.4  Utilities for sensible alternative

Versions of packages aptitude suggests:
pn  debtags   none (no description available)
pn  tasksel   none (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email 

Bug#578527: bsdmainutils: [cal] ncal -J displays wrong date for today

[Ben Harris]

Package: bsdmainutils
Version: 8.0.10
Severity: normal

According to cal(1), there is an option to ncal:

 -J  Display Julian Calendar, if combined with the -e option, display
 date of Easter according to the Julian Calendar.

When I use this, though, I get a rather odd result:

wraith:~$ ncal -J
April 2010
Mo 6 13 20 27
Tu20 14 21 28   
We  1  8 15 22 29
Th  2  9 16 23 30
Fr  3 10 17 24
Sa  4 11 18 25
Su  5 12 19 26

The calendar appears to be correct, but the number for today's date (7th
April Julian) has been replaced by that for the Gregorian calendar (20th
April).  Running ncal -Jh gets the correct result, albeit without today
highlighted:

wraith:~$ ncal -Jh
April 2010
Mo 6 13 20 27
Tu 7 14 21 28
We  1  8 15 22 29
Th  2  9 16 23 30
Fr  3 10 17 24
Sa  4 11 18 25
Su  5 12 19 26

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

Kernel: Linux 2.6.27.9 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages bsdmainutils depends on:
ii  bsdutils  1:2.16.2-0 Basic utilities from 4.4BSD-Lite
ii  debianutils   3.2.2  Miscellaneous utilities specific t
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  libncurses5   5.7+20100313-2 shared libraries for terminal hand

bsdmainutils recommends no packages.

Versions of packages bsdmainutils suggests:
ii  cpp   4:4.4.2-3  The GNU C preprocessor (cpp)
pn  vacation  none (no description available)
ii  wbritish [wordlist]   6-3British English dictionary words f
ii  whois 5.0.2  an intelligent whois client

-- debconf information excluded



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

Bug#573571: insserv fails if cwd inaccessible by root

[Ben Harris]

Package: insserv
Version: 1.12.0-14
Severity: normal

On my system, user home directories are mounted by NFS, and root doesn't
have access to them.  This causes this error when I run insserv:

wraith:/home/bjh21# insserv -n
insserv: popd() can not change directory /home/bjh21: Permission denied
wraith:/home/bjh21# echo $?
1

This does not happen if I run insserv from another directory:

wraith:/tmp# insserv -n
insserv: warning: current stop runlevel(s) (0 1 6) of script `ntp' overwrites 
defaults (empty).
insserv: warning: current stop runlevel(s) (0 1 6) of script `nethack-common' 
overwrites defaults (empty).
insserv: dryrun, not creating .depend.boot, .depend.start, and .depend.stop

I don't think insserv has any reason to look at my home directory, so it
should succeed even in the current directory is inaccessible.

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

Kernel: Linux 2.6.27.9 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages insserv depends on:
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib

insserv recommends no packages.

Versions of packages insserv suggests:
pn  bootchart none (no description available)

-- no debconf information

--
Ben Harris, University of Cambridge Computing Service.



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

Bug#515754: nfs-common: Mounting with sec=krb5p fails with access denied by server while mounting

[Ben Harris]

found 515754 1:1.2.1-3
thanks

On Sun, 28 Feb 2010, Iustin Pop wrote:


On Tue, Feb 17, 2009 at 01:30:22PM +, Ben Harris wrote:

Package: nfs-common
Version: 1:1.1.4-1
Severity: important

When attempting to mount an NFS filesystem using Kerberos 5 security, I get
an error:

wraith:/tmp# mount -osec=krb5p ghast.csi.cam.ac.uk:/export/home/bjh21 /mnt
mount.nfs: access denied by server while mounting 
ghast.csi.cam.ac.uk:/export/home/bjh21

The same happens with sec=krb5 and sec=krb5i as well.  The server should be
offering all of these modes.  If I downgrade nfs-common to 1:1.1.2-6lenny1,
the mount succeeds:


Can you confirm this is still broken with latest nfs-utils in
unstable/testing?


I can confirm that I get the same behaviour with the latest nfs-utils 
(1:1.2.1-3).  I found that the old version was failing as well.  Adding 
allow_weak_crypto=true fixed that, but 1:1.2.1-3 still fails.


I also noticed this in syslog when I tried to do the mount:

Mar  1 14:25:54 wraith rpc.gssd[19094]: rpcsec_gss: gss_init_sec_context: 
(major) Unspecified GSS failure.  Minor code may provide more information - 
(minor) KDC returned error string: NO PREAUTH
Mar  1 14:25:54 wraith last message repeated 3 times

With 1.1.2, I get different messages:

Mar  1 14:39:00 wraith rpc.gssd[21175]: rpcsec_gss: gss_init_sec_context: 
(major) Unspecified GSS failure.  Minor code may provide more information - 
(minor) KDC returned error string: NO PREAUTH
Mar  1 14:39:00 wraith rpc.gssd[21175]: WARNING: Failed to create krb5 context 
for user with uid 0 with any credentials cache for server ghast.csi.cam.ac.uk
Mar  1 14:39:00 wraith rpc.gssd[21175]: rpcsec_gss: gss_init_sec_context: 
(major) Unspecified GSS failure.  Minor code may provide more information - 
(minor) KDC returned error string: NO PREAUTH
Mar  1 14:39:00 wraith rpc.gssd[21175]: WARNING: Failed to create krb5 context 
for user with uid 0 with any credentials cache for server ghast.csi.cam.ac.uk

--
Ben Harris, University of Cambridge Computing Service.



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

Bug#565421: rpm -i should not need --force-debian for source packages

[Ben Harris]

Subject: rpm -i should not need --force-debian for source packages
Package: rpm
Version: 4.7.2-1+b1
Severity: normal

When I try to unpack a source package, this happens:

wraith:/tmp$ rpm -i gnome-panel-2.24.1-2.27.1.src.rpm 
rpm: please use alien to install rpm packages on Debian, if you are really sure use --force-debian switch. See README.Debian for more details.


This seems wrong to me.  Obviously I shouldn't try to install binary
packages like this, but for a source package, rpm -i is roughly equivalent
to dpkg-source -x, both perfectly reasonable things to do on a non-native
system.  README.Debian doesn't contain any suggestion of why unpacking
source packages should be a problem, and even comments on where they'll be
unpacked to.

I think the rpm command should only refuse to install a package if it
isn't a source package.

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

Kernel: Linux 2.6.27.9 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages rpm depends on:
ii  debconf [debconf-2.0]   1.5.28   Debian configuration management sy
ii  libc6   2.10.2-2 GNU C Library: Shared libraries
ii  libelf1 0.143-1  library to read and write ELF file
ii  libnss3-1d  3.12.5-1 Network Security Service libraries
ii  libpopt01.15-1   lib for parsing cmdline parameters
ii  librpm0 4.7.2-1+b1   RPM shared library
ii  librpmbuild04.7.2-1+b1   RPM build shared library
ii  librpmio0   4.7.2-1+b1   RPM IO shared library
ii  perl5.10.1-8 Larry Wall's Practical Extraction 
ii  rpm-common  4.7.2-1  common files for RPM

ii  rpm2cpio4.7.2-1+b1   tool to convert RPM package to CPI
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

rpm recommends no packages.

Versions of packages rpm suggests:
ii  alien 8.79   convert and install rpm and other 
pn  elfutils  none (no description available)

pn  rpm-i18n  none (no description available)

-- debconf information:
* rpm/upgrade-failed:



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

Bug#563741: bzr explodes messily on filenames containing LF

[Ben Harris]

Package: bzr
Version: 1.5-1.1
Version: 2.0.2-1
Version: 2.0.3-1

If I try to commit a new file whose name contains a newline character, bzr 
explodes with a stack trace and asks me to file a bug report.  I don't 
expect bzr to be able to actually record such a silly filename, but it 
would be nice if it failed a little more gracefully.  Sample session 
(using 1.5-1.1) below.  Forcing the repository format gets a similar error 
out of 2.0.2-1, while using the default format gets a different (and 
marginally more helpful) stack trace.


chiark:~$ mkdir foo
chiark:~$ cd foo
chiark:~/foo$ bzr init --pack-0.92
chiark:~/foo$ touch $(printf 'xxx\nyyy')
chiark:~/foo$ bzr add $(printf 'xxx\nyyy')
added xxx
yyy
chiark:~/foo$ bzr commit -m silly filename
Committing to: /u2/bjharris/foo/
added xxx
yyy
bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit bzrlib.knit._PackAccess object at 
0x882f6ec corrupt: incorrect number of lines 4 != 3 for version 
{bjhar...@chiark-20100104231636-4ynpdychlq525n8w}

Traceback (most recent call last):
  File /usr/lib/python2.5/site-packages/bzrlib/commands.py, line 846, in 
run_bzr_catch_errors
return run_bzr(argv)
  File /usr/lib/python2.5/site-packages/bzrlib/commands.py, line 797, in 
run_bzr
ret = run(*run_argv)
  File /usr/lib/python2.5/site-packages/bzrlib/commands.py, line 499, in 
run_argv_aliases
return self.run(**all_cmd_args)
  File /usr/lib/python2.5/site-packages/bzrlib/builtins.py, line 2364, in run
author=author)
  File /usr/lib/python2.5/site-packages/bzrlib/decorators.py, line 165, in 
write_locked
return unbound(self, *args, **kwargs)
  File /usr/lib/python2.5/site-packages/bzrlib/workingtree_4.py, line 240, in 
commit
result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  File /usr/lib/python2.5/site-packages/bzrlib/decorators.py, line 165, in 
write_locked
return unbound(self, *args, **kwargs)
  File /usr/lib/python2.5/site-packages/bzrlib/mutabletree.py, line 197, in 
commit
revprops=revprops, *args, **kwargs)
  File /usr/lib/python2.5/site-packages/bzrlib/commit.py, line 372, in commit
self.rev_id = self.builder.commit(self.message)
  File /usr/lib/python2.5/site-packages/bzrlib/repository.py, line 137, in 
commit
self.new_inventory, self._config)
  File /usr/lib/python2.5/site-packages/bzrlib/repository.py, line 558, in 
add_revision
rev.inventory_sha1 = inventory_vf.get_sha1s([revision_id])[0]
  File /usr/lib/python2.5/site-packages/bzrlib/knit.py, line 766, in get_sha1s
record_map = self._get_record_map(version_ids)
  File /usr/lib/python2.5/site-packages/bzrlib/knit.py, line 1129, in 
_get_record_map
self._data.read_records_iter(records):
  File /usr/lib/python2.5/site-packages/bzrlib/knit.py, line 2530, in 
read_records_iter
content, digest = self._parse_record(version_id, data)
  File /usr/lib/python2.5/site-packages/bzrlib/knit.py, line 2477, in 
_parse_record
version_id))
KnitCorrupt: Knit bzrlib.knit._PackAccess object at 0x882f6ec corrupt: 
incorrect number of lines 4 != 3 for version 
{bjhar...@chiark-20100104231636-4ynpdychlq525n8w}


bzr 1.5 on python 2.5.2 (linux2)
arguments: ['/usr/bin/bzr', 'commit', '-m', 'silly filename']
encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: None
plugins:
  bzrtools /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools 
[1.5.0]
  launchpad
/usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
*** Bazaar has encountered an internal error.
Please report a bug at https://bugs.launchpad.net/bzr/+filebug
including this traceback, and a description of what you
were doing when the error occurred.

Possibly-relevant packages:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
pn  bzr-gtknone (no description available)
pn  bzr-svnnone (no description available)
ii  bzrtools   1.5.0-1Collection of tools for bzr
ii  libc6  2.7-18 GNU C Library: Shared libraries
ii  python 2.5.2-3An interactive high-level object-oriented la
ii  python-central 0.6.8  register and build utility for Python packag
ii  python-paramik 1.7.4-0.1  Make ssh v2 connections with python
ii  python-pycurl  7.18.2-1   Python bindings to libcurl
pn  xdg-utils  none (no description available)

Kernel version:
Linux chiark 2.6.16.60 #1 SMP Sun Feb 10 14:48:32 GMT 2008 i686 GNU/Linux

.bzr.log is attached.

--
Ben Harris
this is a debug log for diagnosing/reporting problems in bzr
you can delete or truncate this file, or include sections in
bug reports to https://bugs.launchpad.net/bzr/+filebug

0.240  encoding stdout as sys.stdout encoding 'ANSI_X3.4-1968

Bug#559314: lldpd reports incorrect maximum frame size

[Ben Harris]

Package: lldpd
Version: 0.4.0-2
Severity: normal

I'm running lldpd on a machine whose main network interface looks like:

eth0  Link encap:Ethernet  HWaddr 00:c0:4f:68:12:cb
  inet addr:131.111.11.78  Bcast:131.111.255.255  Mask:255.255.0.0
  inet6 addr: fe80::2c0:4fff:fe68:12cb/64 Scope:Link
  inet6 addr: 2001:630:200:8100:2c0:4fff:fe68:12cb/64 Scope:Global
  IPX/Ethernet 802.3 addr:836F0A00:00C04F6812CB
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:79429040 errors:0 dropped:0 overruns:281 frame:0
  TX packets:8684282 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3362518813 (3.1 GiB)  TX bytes:3142623466 (2.9 GiB)
  Interrupt:17

According to Wireshark, the LLDPDUs transmitted by lldpd include a 
Maximum Frame Size TLV indicating a frame size of 1500 octets.  This is 
incorrect: According to IEEE Std 802.1AB-2005 (clause G.5.1):


# a) If the MAC/PHY supports only the basic MAC frame format as defined in
#3.1.1 of IEEE Std 802.3-2002, the maximum frame size field shall be
#set to 1518.
#
# b) If the MAC/PHY supports an extension of the basic MAC frame format 
#for Tagged MAC frames as defined 3.5 of IEEE 802.3-2002, the maximum 
#frame size field shall be set to 1522.

#
# c) If the MAC/PHY supports an extension of the MAC frame format that is 
#different from either of the above, the maximum frame size field 
#shall be set to the maximum value supported.


Thus, lldpd should set this field to 1518, 1522, or some other number 
depending on the network driver's support for tagged VLANs and jumbo 
frames.  1500 is definitely wrong, and it would be better for lldpd not to 
include this TLV at all than to transmit incorrect information.


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

Kernel: Linux 2.6.27.9 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages lldpd depends on:
ii  adduser3.111 add and remove users and groups
ii  libc6  2.10.1-7  GNU C Library: Shared libraries
ii  libsnmp15  5.4.1~dfsg-12 SNMP (Simple Network Management Pr

lldpd recommends no packages.

Versions of packages lldpd suggests:
pn  snmpd none (no description available)

-- 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#559314: lldpd reports incorrect maximum frame size

[Ben Harris]

On Thu, 3 Dec 2009, Vincent Bernat wrote:


OoO En ce début d'après-midi  ensoleillé du jeudi 03 décembre 2009, vers
15:51, Ben Harris bj...@cam.ac.uk disait :


Thus, lldpd should set this field to 1518, 1522, or some other number
depending on the network driver's support for tagged VLANs and jumbo
frames.  1500 is definitely wrong, and it would be better for lldpd
not to include this TLV at all than to transmit incorrect information.


Do you know if this information is available somewhere?


I'm afraid I don't, at least in Linux.  I know where to find the 
appropriate flags in NetBSD, but that doesn't really help.


--
Ben Harris, University of Cambridge Computing Service.

Bug#514958: Seems fixed in 1.1.2-6lenny1

[Ben Harris]

fixed 1:1.1.2-6lenny1
thanks

On my system, neither the manual page nor the --help output mentions 
--mounted.  Both refer to --mounts instead, so it looks like the 
documentation was fixed between 1:1.0.10-6+etch.1 and 1:1.1.2-6lenny1.

-- 
Ben Harris



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

Bug#515754: nfs-common: Mounting with sec=krb5p fails with access denied by server while mounting

[Ben Harris]

Package: nfs-common
Version: 1:1.1.4-1
Severity: important

When attempting to mount an NFS filesystem using Kerberos 5 security, I get
an error:

wraith:/tmp# mount -osec=krb5p ghast.csi.cam.ac.uk:/export/home/bjh21 /mnt
mount.nfs: access denied by server while mounting 
ghast.csi.cam.ac.uk:/export/home/bjh21

The same happens with sec=krb5 and sec=krb5i as well.  The server should be
offering all of these modes.  If I downgrade nfs-common to 1:1.1.2-6lenny1,
the mount succeeds:

wraith:/tmp# dpkg -i nfs-common_1.1.2-6lenny1_i386.deb 
dpkg - warning: downgrading nfs-common from 1:1.1.4-1 to 1:1.1.2-6lenny1.
(Reading database ... 159924 files and directories currently installed.)
Preparing to replace nfs-common 1:1.1.4-1 (using 
nfs-common_1.1.2-6lenny1_i386.deb) ...
Unpacking replacement nfs-common ...
Setting up nfs-common (1:1.1.2-6lenny1) ...
Stopping NFS common utilities: gssd idmapd statd.
Starting NFS common utilities: statd idmapd gssd.
Processing triggers for man-db ...
wraith:/tmp# mount -osec=krb5p ghast.csi.cam.ac.uk:/export/home/bjh21 /mnt
wraith:/tmp# 

The server is running Solaris 10 and the filesystem in question is on ZFS:

ghast:~$ uname -a
SunOS ghast 5.10 Generic_138889-03 i86pc i386 i86pc
ghast:~$ /usr/sbin/zfs get sharenfs data/home/bjh21
NAME PROPERTY  VALUE SOURCE
data/home/bjh21  sharenfs  sec=krb5p:krb5i:krb5,rw,sec=sys,rw=uxsup  inherited 
from data/home

This bug is similar to #511802, but the error message is different.

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

Kernel: Linux 2.6.27.9 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages nfs-common depends on:
ii  adduser   3.110  add and remove users and groups
ii  initscripts   2.86.ds1-61Scripts for initializing and shutt
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libcomerr21.41.3-1   common error description library
ii  libevent1 1.3e-3 An asynchronous event notification
ii  libgssglue1   0.1-2  mechanism-switch gssapi library
ii  libkrb53  1.6.dfsg.4~beta1-6 MIT Kerberos runtime libraries
ii  libnfsidmap2  0.21-2 An nfs idmapping library
ii  librpcsecgss3 0.18-1 allows secure rpc communication us
ii  libwrap0  7.6.q-16   Wietse Venema's TCP wrappers libra
ii  lsb-base  3.2-20 Linux Standard Base 3.2 init scrip
ii  netbase   4.34   Basic TCP/IP networking system
ii  portmap   6.0-9  RPC port mapper
ii  ucf   3.0016 Update Configuration File: preserv

nfs-common recommends no packages.

nfs-common 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#503971: trn editor patch

[Ben Harris]

Um, yes, when I said nano I meant editor.  I clearly forgot to tweak 
the patch from the version in my local package.  Sorry about that.

-- 
Ben Harris, University of Cambridge Computing Service.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503968: trn replaces local KILL files unsafely

[Ben Harris]

Package: trn
Version: 3.6-18.1
Tags: patch

Trn's technique for rewriting a local KILL file (kfile.c::rewrite_kfile()) 
is as follows:

 * unlink old KILL file (still open)
 * open new KILL file
 * read lines from old KILL file, writing into new KILL file
 * close both files

This is unsafe, in that any crash between the first and last steps will 
lose the contents of the file.

The attached patch fixes this problem by writing the KILL file under a new 
name, and then renaming it into place (atomically if possible).  I've only 
minimally tested it so far.

[ I actually noticed this because I was running trn on a system where 
  unlinked files aren't readable at all, so all my lovely rules got eaten, 
  but I appreciate that such systems aren't relevant to Debian. ]

-- 
Ben Harris, University of Cambridge Computing Service.--- kfile.c.orig	1994-11-19 06:01:19.0 +
+++ kfile.c	2008-10-29 22:27:40.0 +
@@ -339,6 +339,7 @@
 ART_NUM thru;
 {
 bool no_kills = 0, has_star_commands = FALSE;
+char *oldkf, *newkf;
 
 if (localkfp) {
 	fseek(localkfp,0L,0);		/* rewind current file */
@@ -352,12 +353,16 @@
 	no_kills = 1;
 }
 strcpy(buf,filexp(getval(KILLLOCAL,killlocal)));
+oldkf = savestr(buf);
+strcat(buf, .tmp);
+newkf = savestr(buf);
 if (!localkfp)
-	makedir(buf,MD_FILE);
-UNLINK(buf);			/* to prevent file reuse */
-if (no_kills)
+	makedir(newkf,MD_FILE);
+if (no_kills) {
+UNLINK(buf);
 	open_kfile(KF_LOCAL);		/* close file and reset open flag */
-else if (newkfp = fopen(buf,w)) {
+}
+else if (newkfp = fopen(newkf,w)) {
 	fprintf(newkfp,THRU %ld\n,(long)thru);
 	while (localkfp  fgets(buf,LBUFLEN,localkfp) != Nullch) {
 	if (strnEQ(buf,THRU,4))
@@ -381,12 +386,21 @@
 	/* Append all the still-valid thread commands */
 	hashwalk(msgid_hash, write_thread_commands, 0);
 	fclose(newkfp);
+#ifdef HAS_RENAME
+	rename(newkf, oldkf);
+#else
+	UNLINK(oldkf);
+	safelink(newkf, oldkf);
+UNLINK(newkf);
+#endif
 	open_kfile(KF_LOCAL);		/* and reopen local file */
 }
 else
-	printf(cantcreate,buf) FLUSH;
+	printf(cantcreate,newkf) FLUSH;
 localkf_changes = 0;
 has_normal_kills = FALSE;
+free(newkf);
+free(oldkf);
 }
 
 /* edit KILL file for newsgroup */

Bug#503971: trn uses /usr/bin/emacs by default

[Ben Harris]

Package: trn
Version: 3.6-18.1
Version: 3.6-16

By default, trn and its associated programs seem to use /usr/bin/emacs as 
their default editor.  This is contrary to Debian Policy, which states 
(section 11.4) that applications should use /usr/bin/editor as the 
default.  The attached trivial patch fixes this.

-- 
Ben Harris, University of Cambridge Computing Service.  Tel: (01223) 334728The Debian version of Pnews uses Emacs by default.  It really should be
/usr/bin/editor, but openSUSE doesn't have one of those, so we'll resort
to Nano, which is a little less novice-hostile than vi.
--- config.sh.orig	2008-09-26 00:00:03.0 +0100
+++ config.sh	2008-09-29 22:08:01.0 +0100
@@ -135,7 +135,7 @@
 d_vfork='define'
 d_voidsig='define'
 signal_t='void'
-defeditor='/usr/bin/emacs'
+defeditor='/usr/bin/nano'
 filexp='/usr/share/trn/filexp'
 d_dirnamlen=''
 i_dirent='define'

Bug#420594: Add Catalyst::View::Mason?

[Ben Harris]

Package: libcatalyst-modules-perl
Version: 15
Severity: wishlist

Debian has Catalyst and HTML::Mason, but it doesn't have 
Catalyst::View::Mason, which would glue them together.  Could we have it, 
please, either in libcatalyst-modules-perl or in its own package?

TIA.

-- 
Ben Harris, University of Cambridge Computing Service.  Tel: (01223) 334728


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413873: Bit of documentation missing

[Ben Harris]

Package: userv
Version: 1.0.5

The HTML and PostScript versions of userv's documentation seem to have a 
piece missing.  Section 4.2.3, Control structure directives has a list 
that starts:

# fi
# Lines following if are interpreted only if the condition is true. Many

The lines showing the syntax of if, elif, and else, which appear to 
be present in the SGML source, are missing in the HTML and PostScript.

-- 
Ben Harris, University of Cambridge Computing Service.  Tel: (01223) 334728


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#392735: Bug still present

[Ben Harris]

package java-gcj-compat
found 392735 1.0.65-10
thanks

1.0.65-10 still seems to have a broken symlink at 
/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/man/man1/gcj-dbtool.1.gz:

wraith:~$ ls -l /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/man/man1/gcj-dbtool.1.gz
lrwxrwxrwx 1 root root 49 Jan 17 13:39 
/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/man/man1/gcj-dbtool.1.gz - 
../../../../../share/man/man1/gcj-dbtool-4.1.1.gz
wraith:~$ ls -l /usr/share/man/man1/gcj-dbtool-4.1.1.gz
ls: /usr/share/man/man1/gcj-dbtool-4.1.1.gz: No such file or directory
wraith:~$ dpkg -s java-gcj-compat | grep ^Version:
Version: 1.0.65-10

-- 
Ben Harris, University of Cambridge Computing Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#306279: dup merging

[Ben Harris]

merge 306279 306385
severity 306279 serious
thanks

Marked as serious because:

If two packages cannot be installed together, one must list the other
in its Conflicts: field.
http://release.debian.org/sarge_rc_policy.txt

--
Ben Harris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#132054: This qualifies as serious

[Ben Harris]

severity 132054 serious
thanks

The bigloo version of afile is described by its man page as:

   Afile - a Module Access File Generator

The netatalk version is described as:

   afile  -  display  type  and creator of Apple Macintosh files (netatalk
   format)

These are clearly different functionality, and hence this bug matches the 
following criterion for serious:


Packages must not install programs in the default PATH with
different functionality with the same file name, even if they
Conflict:.
http://release.debian.org/sarge_rc_policy.txt

--
Ben Harris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]