Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Tollef Fog Heen]

Package: xkb-data
Version: 2.38-2
Severity: serious
Justification: makes a subset of systems effectively unusable
X-Debbugs-Cc: none, Tollef Fog Heen 

With commit 0fb34101788d84e9a1d98b3730cc7b9295e0f19b in
xkeyboard-config, `group(alts_toggle)` changed behaviour in a way such
that the right alt no longer generates altgr.  This is very problematic
with keyboard layouts such as Norwegian where that is required to type @
(altgr-2) or $ (altgr-4).

setxkmap no -print on my system outputs:

xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+no+inet(evdev)+level3(ralt_switch)+compose(caps)+group(alts_toggle)"
};
xkb_geometry  { include "pc(pc105)" };
};

which includes the problematic toggle.  I don't know if the right fix is
to revert the relevant commit (reintroducing the problem in
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/316)
or something else, but the current way it works is not great.

Happy to help debug this further, let me know what I can provide.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1003955: Acknowledgement (systemd: systemd-networkd: wireguard AllowedIPs is inserted into routing table)

[Tollef Fog Heen]

]] Michael Biebl 

> sorry for the inconvenience

No worries.

> Am 18.01.22 um 17:03 schrieb Tollef Fog Heen:
> > It seems like this is
> > https://github.com/systemd/systemd/issues/21964.
> > 
> 
> I'm working on an update as we speak. 250.3-1 should hit the archive
> later today.

Thanks a lot for the quick reaction on this and that you're maintaining
systemd.  Much appreciated!

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1003955: Acknowledgement (systemd: systemd-networkd: wireguard AllowedIPs is inserted into routing table)

[Tollef Fog Heen]

It seems like this is https://github.com/systemd/systemd/issues/21964.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1003955: systemd: systemd-networkd: wireguard AllowedIPs is inserted into routing table

[Tollef Fog Heen]

Package: systemd
Version: 250.2-3
Severity: critical
Justification: completely breaks network connectivity in certain setups
X-Debbugs-Cc: none, Tollef Fog Heen 

(Feel free to downgrade, but this completely broke network on my testing
system, which weren't it my laptop and sat in front of me, it'd be
really hard to debug.)

It seems like systemd-networkd between 249.7-1 and 250.2-3 started
adding IPs specified in AllowedIPs in WireGuardPeer stanzas in netdev
units to the routing table.

The documentation in systemd.netdev states:

   Note that this only affects routing inside the network interface 
itself, i.e. the
   packets that pass through the tunnel itself. To cause packets to be 
sent via the
   tunnel in the first place, an appropriate route needs to be added as 
well — either in
   the "[Routes]" section on the ".network" matching the wireguard 
interface, or
   externally to systemd-networkd.

This is the historic behaviour, and this behaviour can be had by using
RouteTable=off in the WireGuardPeer section.

The reason it broke is I have a multi-peer wireguard setup where I
direct traffic to the different peers a machine can talk to using BGP
and bird, and therefore has AllowedIPs=0.0.0.0/0 for the netdevs. After
the upgrade, systemd-networkd proceeded to make my default route point
at the tunnels (which are not suitable as default routes) in addition to
my regular default route, causing most of the traffic to end up on the
floor.

It might be possible to detect this in a postinst, but it's probably
brittle, so I'd consider changing the default RouteTable setting to off.

-- System Information:
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-6
ii  libaudit11:3.0.6-1+b1
ii  libblkid12.37.2-6
ii  libc62.33-2
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.27-1
ii  libcryptsetup12  2:2.4.3-1
ii  libfdisk12.37.2-6
ii  libgcrypt20  1.9.4-5
ii  libgnutls30  3.7.2-5
ii  libgpg-error01.43-1
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-6
ii  libpam0g 1.4.0-11
ii  libseccomp2  2.5.3-2
ii  libselinux1  3.3-1+b1
ii  libsystemd0  250.2-3
ii  libzstd1 1.4.8+dfsg-3
ii  mount2.37.2-6
ii  util-linux   2.37.2-6

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.12.20-3
ii  ntp [time-daemon]   1:4.2.8p15+dfsg-1

Versions of packages systemd suggests:
ii  libfido2-11.9.0-1
ii  libtss2-esys-3.0.2-0  3.1.0-3
ii  libtss2-mu0   3.1.0-3
ii  libtss2-rc0   3.1.0-3
ii  policykit-1   0.105-31
ii  systemd-container 250.2-3

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   250.2-3
ii  libpam-systemd   250.2-3
ii  udev 250.2-3

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1001046: todoman: crashes on startup

[Tollef Fog Heen]

]] Tollef Fog Heen 

> I have no idea what's wrong here, except «it used to work» (as in,
> yesterday, but that update included, amongst many others, an update from
> python3-click 7.1.2-1 to 8.0.2-1, so based on the backtrace, maybe
> relevant?)

fwiw, duwngrading to 7.1.2-1 makes todoman not break again, so looks
like both a bug in todoman for not supporting python3-click, and a
missing Breaks (or API bump) in python3-click.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1001046: todoman: crashes on startup

[Tollef Fog Heen]

Package: todoman
Version: 3.9.0-1
Severity: serious
X-Debbugs-Cc: none, Tollef Fog Heen 

I have no idea what's wrong here, except «it used to work» (as in,
yesterday, but that update included, amongst many others, an update from
python3-click 7.1.2-1 to 8.0.2-1, so based on the backtrace, maybe
relevant?)

$ todoman
Traceback (most recent call last):
  File "/usr/bin/todoman", line 33, in 
sys.exit(load_entry_point('todoman==3.9.0', 'console_scripts', 'todoman')())
  File "/usr/lib/python3/dist-packages/click/core.py", line 1126, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1051, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1635, in invoke
super().invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1393, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 752, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 26, in 
new_func
return f(get_current_context(), *args, **kwargs)
 File "/usr/lib/python3/dist-packages/todoman/cli.py", line 39, in wrapper
return f(*a, **kw)
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 312, in cli
invoke_command(
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 322, in 
invoke_command
click_ctx.invoke(cli.commands[command], args)
  File "/usr/lib/python3/dist-packages/click/core.py", line 752, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 84, in 
new_func
return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 752, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 39, in wrapper
return f(*a, **kw)
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 635, in list
hide_list = (len([_ for _ in ctx.db.lists()]) == 1) or 
(len(kwargs["lists"]) == 1)
TypeError: object of type 'NoneType' has no len()

-- System Information:
Versions of packages todoman depends on:
ii  libjs-sphinxdoc4.2.0-5
ii  python33.9.7-1
ii  python3-atomicwrites   1.4.0-2
ii  python3-click  8.0.2-1
ii  python3-click-log  0.2.1-2
ii  python3-configobj  5.0.6-5
ii  python3-dateutil   2.8.1-6
ii  python3-humanize   3.12.0-1
ii  python3-icalendar  4.0.3-4
ii  python3-parsedatetime  2.6-2
ii  python3-tabulate   0.8.7-0.1
ii  python3-urwid  2.1.2-2+b1
ii  python3-xdg0.27-2

todoman recommends no packages.

Versions of packages todoman suggests:
ii  vdirsyncer  0.16.8-2

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1000732: python3-click-threading: broken monkeypatching

[Tollef Fog Heen]

]] Tollef Fog Heen 

> Versions of packages python3-click-threading depends on:
> ii  python33.9.7-1
> ii  python3-click  8.0.2-1

The problem goes away if I downgrade to python3-click 7.1.2-1, so maybe
there's a missing Breaks there too.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1000732: python3-click-threading: broken monkeypatching

[Tollef Fog Heen]

Package: python3-click-threading
Version: 0.4.4-2
Severity: serious
X-Debbugs-Cc: none, Tollef Fog Heen 

It seems like the monkeypatching in
/usr/lib/python3/dist-packages/click_threading/monkey.py is broken, at
least for me. I'm using python3-click-threading by way of vdirsyncer:

$ vdirsyncer -vdebug sync
debug: Using 1 maximal workers.
) -> None
lambda ) -> None: clear._real_click_fn() -> None)
error: Unknown error occurred: unmatched ')' (, line 1)
error: Use `-vdebug` to see the full traceback.
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
30, in inner
debug: f(*a, **kw)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
145, in sync
debug: with wq.join():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/utils.py", line 
364, in join
debug: with ui_worker.patch_click():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/__init__.py", 
line 144, in patch_click
debug: with patch_ui_functions(wrapper):
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/monkey.py", line 
50, in patch_ui_functions
debug: stub_f = eval('lambda {s}: {n}._real_click_fn({a})'

Adding a few prints shows that it's trying do do an eval of the string:

lambda ) -> None: clear._real_click_fn() -> None)

This, unsurprisingly, does not work.  I'm not sure what component has
changed in a way that breaks python3-click-threading, but the patching
seems pretty brittle.

-- System Information:

Versions of packages python3-click-threading depends on:
ii  python33.9.7-1
ii  python3-click  8.0.2-1

python3-click-threading recommends no packages.

python3-click-threading suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#988082: shim-signed: Fails to install on non-UEFI systems

[Tollef Fog Heen]

Package: shim-signed
Version: 1.34~1+deb10u1+15.4-2~deb10u1
Severity: serious
X-Debbugs-Cc: none, Tollef Fog Heen 

Looks like postinst is poking into /sys/firmware/efi, which doesn't
exist on a non-UEFI system.

Preparing to unpack .../shim-signed_1.34~1+deb10u1+15.4-2~deb10u1_amd64.deb ...
Unpacking shim-signed:amd64 (1.34~1+deb10u1+15.4-2~deb10u1) over 
(1.33+15+1533136590.3beb971-7) ...
Preparing to unpack 
.../shim-signed-common_1.34~1+deb10u1+15.4-2~deb10u1_all.deb ...
Unpacking shim-signed-common (1.34~1+deb10u1+15.4-2~deb10u1) over 
(1.33+15+1533136590.3beb971-7) ...
Preparing to unpack .../shim-unsigned_15.4-3~deb10u1_amd64.deb ...
Unpacking shim-unsigned (15.4-3~deb10u1) over (15.4-2~deb10u1) ...
Setter opp shim-signed:amd64 (1.34~1+deb10u1+15.4-2~deb10u1) ...
cat: /sys/firmware/efi/fw_platform_size: No such file or directory
dpkg: error processing package shim-signed:amd64 (--configure):
 installed shim-signed:amd64 package post-installation script subprocess 
returned error exit status 1
Setter opp shim-signed-common (1.34~1+deb10u1+15.4-2~deb10u1) ...
No DKMS packages installed: not changing Secure Boot validation state.
Setter opp shim-unsigned (15.4-3~deb10u1) ...
Det oppsto feil ved behandling av:
 shim-signed:amd64
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

(It's a fair question to ask «why are you installing it here?», in this
particular case, it's a bug, but one could very well be doing this as a
part of migrating from legacy to UEFI boot.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#920553: pkg-config: Undefined subroutine ::warning called at /usr/share/pkg-config-dpkghook line 34.

[Tollef Fog Heen]

]] Axel Beckert 

Hi, thanks for reporting this.

> pkg-config fails to upgrade on two machines (1x amd64 with i386 as
> foreign architecture, 1x pure i386) as follows for me:

Both of those probably have a non-valid dpkg architecture enabled, such
as «x86».  What does dpkg --print-foreign-architectures on them output?

[...]

> It does though not happen on all of my sid machines, including other
> amd64 machines. Maybe a missing dependency on some Perl module or so?

It was a missing import; I've fixed this now, but if it's something else
than what I think it is, then it'd be good to get the other bug fixed
too, so it'd be good to get an answer to my question above.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#916772: pkg-config: missing Depends: dpkg-dev

[Tollef Fog Heen]

severity 916772 normal
thanks

]] Helmut Grohne 

> # i686-linux-gnu-pkg-config --libs libssl

This is a supported, but non-standard configuration, so I'm downgrading
this from serious.

> If adding dpkg-dev to Depends is not desired, the cross-wrapper could be
> extended to give a useful error message in case $multiarch is empty:
> 
> --- /usr/share/pkg-config-crosswrapper
> +++ /usr/share/pkg-config-crosswrapper
> @@ -11,6 +11,10 @@
>triplet="${basename%-pkg-config}"
># Normalized multiarch path if any, e.g. i386-linux-gnu for i386
>multiarch="`dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 
> 2>/dev/null`"
> +  if test "$?" != 0; then
> +echo "Please apt install dpkg-dev to use this program." 1>&2
> +exit 1
> +  fi
># Native multiarch path
>native_multiarch="$(cat /usr/lib/pkg-config.multiarch)"

This looks reasonable.

> dpkg-dev should be added to Recommends in that case.

Suggests seems more appropriate here.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904459: Uploading soon?

[Tollef Fog Heen]

]] Daniel Baumann 

> On 10/12/2018 09:56 AM, Tollef Fog Heen wrote:
> > any chance you could find time to get this uploaded soon? It'd be great
> > to have netdata back in testing (and in buster when it gets released).
> 
> yep, working on it.. will take a couple of days though. having netdata
> in buster is important to me too.

Thank you! :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904459: Uploading soon?

[Tollef Fog Heen]

Hi,

any chance you could find time to get this uploaded soon? It'd be great
to have netdata back in testing (and in buster when it gets released).

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#908162: grub-efi-amd64-signed: cryptdisk support missing

[Tollef Fog Heen]

Package: grub-efi-amd64-signed
Version: 1+2.02+dfsg1+6
Severity: critical
Justification: makes the system completely unbootable

When grub-efi-amd64-signed is installed and /boot is on an encrypted
file system and GRUB_ENABLE_CRYPTODISK=y is present in
/etc/default/grub, the system fails to boot, since cryptodisk appears to
be missing from the installed image.

Removing grub-efi-amd64-signed works around the problem, since it then
seems to use a locally built image?  I suspect just adding cryptodisk to
GRUB_MODULES in grub's debian/build-efi-images would be sufficient to
make this work correctly.

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#899223: sparkleshare: fails to start without any error message

[Tollef Fog Heen]

Package: sparkleshare
Version: 2.0.1-1
Severity: grave

After the recent update, sparkleshare fails to start without any kind of
useful error message on multiple machines.

First, it hits a mono bug that's triggered by the new libncurses, which
can either be worked around with «TERM=xterm sparkleshare start» or
patched by
https://github.com/mono/mono/commit/2c1f45f3791f274855e0f5fd2fb0af71c9a756f7
(thanks to Jo Shields for that link).

It then runs like:
$ TERM=dumb sparkleshare start
06.47.09 Environment | SparkleShare 2.0.1
06.47.09 Environment | Git LFS 
06.47.09 Environment | Git 2.17.0
06.47.09 Environment | GNOME (Unix 4.16.0.1)
06.47.09 Cmd |  | gvfs-set-attribute "/home/tfheen/SparkleShare" 
metadata::custom-icon-name org.sparkleshare.SparkleShare

and then just exits.  strace does not really shed any light on what's
going on.

I'm happy to help out with debugging this issue if you can't reproduce
it.

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

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sparkleshare depends on:
ii  git 1:2.17.0-1
ii  gnome-icon-theme3.12.0-3
ii  gvfs1.36.1-1
ii  libappindicator3-0.1-cil12.10.0+git20151221-5
ii  libgdk3.0-cil   2.99.3-2+b1
ii  libgio3.0-cil   2.99.3-2+b1
ii  libglib3.0-cil  2.99.3-2+b1
ii  libgtk3.0-cil   2.99.3-2+b1
ii  libjs-jquery3.2.1-1
ii  libmono-corlib4.5-cil   4.6.2.7+dfsg-1
ii  libmono-posix4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system4.0-cil   4.6.2.7+dfsg-1
ii  libnotify3.0-cil3.0.3-3
ii  libpango3.0-cil 2.99.3-2+b1
ii  libwebkit2-sharp-4.0-cil2.10.9+git20160917-1.1
ii  mono-runtime4.6.2.7+dfsg-1

Versions of packages sparkleshare recommends:
ii  python   2.7.15~rc1-1
ii  python-nautilus  1.1-6

sparkleshare suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#884173: Solved-for-me

[Tollef Fog Heen]

Good catch Toote,

it went away when I manually removed the Signal extension it all works a
lot better (just mv-ed out of ~/.config/chromium/Default/Extensions).
If you use it, does it help for you as well?  Should extensions be able
to crash the browser? (Not sure if they can include native code.)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#877966: This is happening again

[Tollef Fog Heen]

]] Julien Cristau 

> On 12/12/2017 03:39 PM, Tollef Fog Heen wrote:
> > DSA, thoughts on this?  Sounds reasonable?
> > 
> I think the issue is also made worse by mirror-bytemark being
> consistently much slower than the other backends, and how ftpsync
> behaves in a pathological way when mirrors have very different speeds.

Agreed, we should fix this on both the mirror-health side and how we
push.

> When doing a staged push, we start stage1 for all downstreams.  Each of
> those, when it's done, waits for up to $PUSHDELAY, by default 10
> minutes, for its siblings to signal they're also done with stage1.  If
> all goes well, everyone waits for everyone else to be done with stage1,
> then within 5 seconds of each other they run stage2.

Why do we do this?  To avoid having inconsistent mirrors?  Can we solve
this by having names that incorporate _health instead and just have
mirrors take whatever time they need?  This will cause some traffic to
slosh around as mirrors go healthy and unhealthy, but hopefully not more
than what we can handle?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#884173: Backtrace

[Tollef Fog Heen]

This happens for me too:

$ /usr/bin/chromium -g
# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/tfheen/bin:/usr/local/bin:/home/tfheen/.local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin
#GTK_PATH=
#  CHROMIUM_FLAGS=--enable-remote-extensions 
--show-component-extension-options --ignore-gpu-blacklist 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.be3nwP
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...Reading symbols from 
/usr/lib/debug/.build-id/ca/13b14d742fddeb5910cd30a74e53d1af48ad1b.debug...(no 
debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/lib/chromium/chromium --enable-remote-extensions 
--show-component-extension-options --ignore-gpu-blacklist 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdd739700 (LWP 14296)]
[New Thread 0x7fffdcf38700 (LWP 14301)]
[New Thread 0x7fffdb558700 (LWP 14302)]
[New Thread 0x7fffdad57700 (LWP 14303)]
[New Thread 0x7fffd9d55700 (LWP 14304)]
[New Thread 0x7fffda556700 (LWP 14305)]
[New Thread 0x7fffd9d4d700 (LWP 14306)]
[New Thread 0x7fffd954c700 (LWP 14307)]
[New Thread 0x7fffd7107700 (LWP 14308)]
[New Thread 0x7fffd6906700 (LWP 14309)]
[New Thread 0x7fffd6105700 (LWP 14310)]
[New Thread 0x7fffd5904700 (LWP 14311)]
[New Thread 0x7fffd5103700 (LWP 14312)]
[New Thread 0x7fffd4902700 (LWP 14313)]
[New Thread 0x7fffd4101700 (LWP 14314)]
[New Thread 0x7fffd3900700 (LWP 14315)]
[New Thread 0x7fffd30ff700 (LWP 14316)]
[New Thread 0x7fffd28fe700 (LWP 14317)]
[New Thread 0x7fffd20fd700 (LWP 14318)]
[New Thread 0x7fffd18fc700 (LWP 14319)]
[New Thread 0x7fffd10fb700 (LWP 14320)]
[New Thread 0x7fffd08fa700 (LWP 14321)]
[New Thread 0x7fffd00f9700 (LWP 14322)]
[New Thread 0x7fffcf8f8700 (LWP 14323)]
[New Thread 0x7fffcf0f7700 (LWP 14324)]
[New Thread 0x7fffce8f6700 (LWP 14325)]
[New Thread 0x7fffce0f5700 (LWP 14326)]
[New Thread 0x7fffcd8f4700 (LWP 14327)]
[New Thread 0x7fffcce6d700 (LWP 14328)]
[New Thread 0x7fffbbe42700 (LWP 14355)]
[14252:14324:1213/195506.734934:ERROR:io_thread.cc(743)] Cannot use V8 Proxy 
resolver in single process mode.
[New Thread 0x7fffbb641700 (LWP 14356)]
[New Thread 0x7fffb9e3e700 (LWP 14358)]
[New Thread 0x7fffba63f700 (LWP 14359)]
[New Thread 0x7fffbae40700 (LWP 14357)]
[14252:14324:1213/195506.827087:ERROR:io_thread.cc(743)] Cannot use V8 Proxy 
resolver in single process mode.
[New Thread 0x7fffb5a67700 (LWP 14362)]
[New Thread 0x7fffb5266700 (LWP 14363)]
[New Thread 0x7fffb4a65700 (LWP 14365)]
[New Thread 0x7fffb4264700 (LWP 14366)]
[New Thread 0x7fffb3a63700 (LWP 14367)]
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[New Thread 0x7fffb28db700 (LWP 14368)]
[Thread 0x7fffb28db700 (LWP 14368) exited]
[New Thread 0x7fffb193d700 (LWP 14370)]
[New Thread 0x7fffb113c700 (LWP 14371)]
[New Thread 0x7fffb093b700 (LWP 14372)]
[New Thread 0x7fffb013a700 (LWP 14373)]
[14252:14355:1213/195506.960725:ERROR:connection.cc(1964)] Web sqlite error 1, 
errno 0: no such column: instant_url, sql: SELECT id, short_name, keyword, 
favicon_url, url, safe_for_autoreplace, originating_url, date_created, 
usage_count, input_encodings, suggest_url, prepopulate_id, created_by_policy, 
instant_url, last_modified, sync_guid, alternate_urls, 
search_terms_replacement_key, image_url, search_url_post_params, 
suggest_url_post_params, instant_url_post_params, image_url_post_params, 
new_tab_url, last_visited FROM keywords ORDER BY id ASC
[New Thread 0x7fffaf939700 (LWP 14374)]
[New Thread 0x7fffaf057700 (LWP 14375)]
[New Thread 0x7fffae856700 (LWP 14376)]
[New Thread 0x7fffade43700 (LWP 14377)]
[New Thread 0x7fffad43f700 (LWP 14387)]
[New Thread 0x7fffabdd7700 (LWP 14404)]
[Thread 0x7fffabdd7700 (LWP 14404) exited]
[New Thread 0x7fffabdd7700 (LWP 14405)]
[New Thread 0x7fffaaf4a700 (LWP 14406)]
[New Thread 0x7fffa9fc5700 (LWP 14407)]
[New Thread 0x7fffa79ec700 (LWP 14408)]
[New Thread 0x7fffa716b700 (LWP 14409)]

Bug#877966: This is happening again

[Tollef Fog Heen]

]] Santiago Vila 

> While building a lot of packages today, I found that this is happening again:
> 
> 503  Quorum weight not reached [IP: 151.101.112.204 80]

Hi,

yeah, we saw an outage on the 9th, need to investigate why it hit us.  I
suspect it was due to (all dates the the 9th, all times are UTC):

21:08:21 mirror push on mirror-conova is done
21:08:22 mirror-skroutz declares itself unhealthy due to being out of date
21:08:58 mirror-accumu declares itself unhealthy due to being out of date
21:09:10 mirror-bytemark declares itself unhealthy due to being out of date
21:09:56 mirror-conova declares itself unhealthy due to scheduled shutdown
21:16:44 mirror push on mirror-skroutz is done
21:17:22 mirror-skroutz declares itself healthy
21:17:37 mirror push on mirror-accumu is done
21:17:58 mirror-accumu declares itself healthy
21:19:32 mirror-skroutz hits a bug in mirror-health and declares itself
 unhealthy due to connect timeouts to mirror-conova
21:20:07 mirror-accumu hits a bug in mirror-health and declares itself
 unhealthy due to connect timeouts to mirror-conova
21:26:10 mirror-accumu comes back and is healthy
21:26:11 mirror-skroutz comes back and is healthy
21:26:53 mirror-conova comes back and is healthy

Dec 10:
03:45:34 mirror-bytemark push is done
03:45:47 mirror-bytemark comes back and is healthy

So what happened was essentially that we did a reboot *just* after a
push had finished, leading to a mirror declaring itself unhealthy.

I've fixed the bug that caused the second outage from ~2120 until ~2126
now, so we should not run into that one again at least.

I wonder if the right fix is to ignore timestamps from any unhealthy
hosts, and to reset latest_ts on each iteration through check_uptodate.
If we initialise latest_ts to 0, that will mean we do consider ourselves
healthy in the case of nobody else being healthy.  If somebody else is
newer than us and healthy, we consider ourselves unhealthy.

DSA, thoughts on this?  Sounds reasonable?

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#844142: norwegian: FTBFS: rm: cannot remove 'munch[123].tmp': No such file or directory

[Tollef Fog Heen]

]] Petter Reinholdtsen 

> [Lucas Nussbaum]
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> 
> I believe this package can not be built in parallell.  Could this be the
> trigger for this build problem?

I think so, so I've uploaded a fix which disables parallel builds.  It
should be visible on the buildds in not too long, the last version had
maybe-failed on a bunch of them.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839682: ledger-el: Fails to install if emacs23 is still installed

[Tollef Fog Heen]

Package: ledger-el
Version: 3.1.2~pre1+g3a00e1c+dfsg1-1
Severity: serious

It seems like ledger-el tries to install for all installed emacs
versions, but fails when it hits emacs23:

Setting up ledger-el (3.1.2~pre1+g3a00e1c+dfsg1-1) ...
Install emacsen-common for emacs23
emacsen-common: Handling install of emacsen flavor emacs23
Wrote /etc/emacs23/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install ledger-el for emacs23
install/ledger-el: Handling install for emacsen flavor emacs23
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-check.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-commodities.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-complete.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-exec.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-fontify.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-fonts.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-init.elc

In toplevel form:
ledger-mode.el:51:1:Error: Required feature `cl-macs' was not provided
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-navigate.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-occur.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-post.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-reconcile.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-regex.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-report.elc

In toplevel form:
ledger-schedule.el:35:1:Error: Required feature `cl-macs' was not provided
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-sort.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-state.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-test.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-texi.elc
Wrote /usr/share/emacs23/site-lisp/ledger-el/ledger-xact.elc
ERROR: install script from ledger-el package failed
dpkg: error processing package ledger-el (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 ledger-el
E: Sub-process /usr/bin/dpkg returned an error code (1)

It should probably not try to install itself for emacs23.

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

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

Versions of packages ledger-el depends on:
ii  emacsen-common  2.0.8

ledger-el recommends no packages.

Versions of packages ledger-el suggests:
ii  ledger  3.1.2~pre1+g3a00e1c+dfsg1-1

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#825149: golang-mode: fails to install if emacs23 is installed

[Tollef Fog Heen]

Package: golang-mode
Version: 3:1.4.0-1
Severity: serious
Justification: fails to install

It looks like golang-mode tries to build for emacs23 too, which doesn't
have cl-lib:

Setting up golang-mode (3:1.4.0-1) ...
Install emacsen-common for emacs23
emacsen-common: Handling install of emacsen flavor emacs23
Wrote /etc/emacs23/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install golang-mode for emacs23
install/golang-mode: Handling install for emacsen flavor emacs23
Loading 00debian-vars...
Loading /etc/emacs/site-start.d/20apel.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50develock-el.el (source)...
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Info: Skip debian-el loading if run under dpkg control.
Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)...
Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)...
Loading /etc/emacs/site-start.d/50evernote-mode.el (source)...
Loading /etc/emacs/site-start.d/50eweouz.el (source)...
Loading /etc/emacs/site-start.d/50flim.el (source)...
Loading /etc/emacs/site-start.d/50global.el (source)...
Loading /etc/emacs/site-start.d/50golang-mode.el (source)...
Loading /etc/emacs/site-start.d/50ledger.el (source)...
ledger removed but not purged, skipping setup
Loading /etc/emacs/site-start.d/50ledger-el.el (source)...
Loading /etc/emacs/site-start.d/50lua-mode.el (source)...
Loading /etc/emacs/site-start.d/50org-mode.el (source)...
Loading /etc/emacs/site-start.d/50puppet-el.el (source)...
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...
Loading /etc/emacs/site-start.d/50twittering-mode.el (source)...
Loading /etc/emacs/site-start.d/50vc-svn.el (source)...
Loading /etc/emacs/site-start.d/50w3m-el.el (source)...
Loading /etc/emacs/site-start.d/50yaml-mode.el (source)...
Loading /etc/emacs/site-start.d/51debian-el.el (source)...

In toplevel form:
go-mode.el:16:1:Error: Cannot open load file: cl-lib
ERROR: install script from golang-mode package failed
dpkg: error processing package golang-mode (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 golang-mode
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

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

Versions of packages golang-mode depends on:
ii  emacs23-nox [emacsen]  23.4+1-4.1+b1
ii  emacs24 [emacsen]  24.5+1-6+b2
ii  emacsen-common 2.0.8

golang-mode recommends no packages.

golang-mode suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

[Tollef Fog Heen]

]] Pierre Ynard 

> Please tell me, what do I do with it??

Personally, I'd get some more recent hardware.  Or run stable.

In CPU performance terms, a Pentium MMX (at 200MHz) is about half to a
third of the speed of the first-generation raspberry pi (underclocked to
700MHz).  There's a limit to how long we're going to support old
hardware.  The last of the Pentium MMX-es was released in 1999-01.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#802950: norwegian: FTBFS when awk is mawk

[Tollef Fog Heen]

]] Petter Reinholdtsen 

> [Robert Luberda]
> > `--source' seems to be supported by GNU awk only.
> 
> Tollef, what is your view here?  Should the build be changed to
> always use gawk, or rewritten to not use --source?

Probably just use gawk.  Seems like the easier option?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#802950: norwegian: FTBFS when awk is mawk

[Tollef Fog Heen]

]] Petter Reinholdtsen 

> [Tollef Fog Heen]
> > Probably just use gawk.  Seems like the easier option?
> 
> Yeah.  Do you need a hand with the patch?

Nah, should be trivial enough, going to make a sweep and upload soonish,
I think.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#790765: FTBFS: [munched.A] Error 1

[Tollef Fog Heen]

]] Martin Michlmayr 

 Package: norwegian
 Version: 2.0.10-7
 Severity: serious
 
 I'm not sure I included the right error message but norwegian fails to
 build in unstable.

Indeed it does.  Seems to be caused by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794152

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#787378: eweouz: FTBFS with evolution-data-server 3.16

[Tollef Fog Heen]

]] peter green 

 http://debdiffs.raspbian.org/main/e/eweouz/eweouz_0.9+rpi1.debdiff

Thanks, applied and uploaded. :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#782030: stunnel4: Fails to restart on slow/loaded systems

[Tollef Fog Heen]

Package: stunnel4
Version: 3:5.06-2
Severity: serious

From the init script:

  force-reload|restart)
echo -n Restarting $DESC: 
killdaemons
sleep 5
startdaemons
echo $NAME.
;;

Nothing here ensures the daemons have actually exited before it tries to
start the new daemon.

There's a variant of the same bug in that the init script will return on
stop before the daemon has actually stopped.  Should be easy enough to
fix with a loop in killdaemons, or by using start-stop-daemon instead
which will wait for you.

Serious since this means restarts will randomly fail.

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

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

Versions of packages stunnel4 depends on:
ii  adduser3.113+nmu3
ii  libc6  2.19-17
ii  libssl1.0.01.0.1k-3
ii  libsystemd0215-14
ii  libwrap0   7.6.q-25
ii  multiarch-support  2.19-17
ii  netbase5.3
ii  openssl1.0.1k-3
ii  perl   5.20.2-3
ii  perl-modules   5.20.2-3

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  none

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#766187: [Pkg-sysvinit-devel] The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2

[Tollef Fog Heen]

]] Henrique de Moraes Holschuh 

 On Thu, 11 Dec 2014, Gerrit Pape wrote:
  On Tue, Dec 09, 2014 at 11:24:11AM +, Gerrit Pape wrote:
   On Mon, Nov 24, 2014 at 10:08:49PM +, Simon McVittie wrote:
On 24/11/14 21:41, Gerrit Pape wrote:
 Better than (2) would be to make the existence of /etc/inittab still
 essential for jessie, by moving the corresponding code from
 sysvinit-core into the essential init package.  What do you think?

If you go this route, I think initscripts might be a better home for
   
   As I wrote above, I actually don't have the time to go any road at all.
   
   The packages worked just fine until I learnt that support for the
   inittab interface is dropped in jessie.  I fixed the packages.  Now I
   learnt that the existence of /etc/inittab is no longer essential, next
   thing breaking my packages - when switching jessie to sysvinit.
   
   Please advise whether I should reassign this release critically to the
   init and sysvinit packages, or upload the ugly workaround to copy
   sysvinit maintainer script code for generating /etc/inittab into the two
   affected packages.
  
  Hi init and sysvinit maintainers, it looks like I don't get reasonable
  advise on debian-devel.
  
  What is your stand on this?
 
 You *are* allowed to create /etc/inittab when it is missing.

.. but only if it wasn't removed by the sysadmin.  Admin changes must be
preserved, including removal.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#754669: fixed in sash 3.8-2

[Tollef Fog Heen]

]] Cyril Brulebois 

Hi,

 Tollef Fog Heen tfh...@debian.org (2014-07-16):
  Format: 1.8
  Date: Wed, 16 Jul 2014 20:48:59 +0200
  Source: sash
  Binary: sash
  Architecture: source amd64
  Version: 3.8-2
  Distribution: unstable
  Urgency: medium
  Maintainer: Tollef Fog Heen tfh...@debian.org
  Changed-By: Tollef Fog Heen tfh...@debian.org
  Description:
   sash   - Stand-alone shell
  Closes: 754669
  Changes:
   sash (3.8-2) unstable; urgency=medium
   .
 * Use #if instead of #ifdef for HAVE_LINUX_* in sash.c to make this
   build on kfreebsd.  Closes: #754669
 
 It now fails with a missing include:
 | cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
 -Werror=format-security -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes 
 -DHAVE_GZIP=1 -DHAVE_LINUX_ATTR=0 -DHAVE_LINUX_CHROOT=0 
 -DHAVE_LINUX_LOSETUP=0 -DHAVE_LINUX_PIVOT=0 -DHAVE_LINUX_MOUNT=0 
 -DHAVE_BSD_MOUNT=1 -DMOUNT_TYPE='ufs'  -c cmds.c
 | cmds.c:35:24: fatal error: linux/loop.h: No such file or directory
 |  #include linux/loop.h
 | ^
 | compilation terminated.
 
 Do you want a reopen or a new bug report?

I just fixed this, so neither should be necessary.  Now I also test
built on falla. :-)

Thanks for the poke.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#747535: Processed: systemd-sysv: #747535 Was: Re: systemd-fsck?

[Tollef Fog Heen]

severity 747535 important
thanks

]]  (Debian Bug Tracking System)

 Processing commands for cont...@bugs.debian.org:
 
  severity 747535 serious
 Bug #747535 [systemd-sysv] systemd-sysv: Ask before installing when upgrading 
 to/installing jessie
 Severity set to 'serious' from 'important'

No, it's not.  We don't consider it unsuitable for release.  Feel free
to get the release team to chime in or provide a justification pointing
to the relevant bit of policy.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#746577: closed by Michael Biebl bi...@debian.org (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

[Tollef Fog Heen]

]] Zack Weinberg 

 On 05/06/2014 08:08 AM, Tollef Fog Heen wrote:
  ]] Zack Weinberg 
  
  On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen tfh...@err.no wrote:
  ]] Zack Weinberg
  Fundamentally what I want is a bulletproof procedure for reverting to
  sysvinit in case something goes wrong.
 
  Sounds like you're arguing that sysvinit-core should no longer ship
  /sbin/init, then, so systemd-sysv doesn't have to conflict with it.
 
  Wouldn't that make the sysvinit implementation of /sbin/init
  completely unavailable?  This is an earnest question.  I do not have
  access to package contents right now.
  
  No, to revert you'd boot with init=/sbin/sysvinit.
 
 Ah, I understand now.  Yes, this + systemd-sysv and upstart *also* stop
 shipping /sbin/init (it becomes a symlink under control of the
 administrator) + documentation would be a satisfactory conclusion as far
 as I'm concerned.  If we were to also move 'reboot' and friends to a
 shared utilities package, that might make the systemd-sysv package
 unnecessary.

I don't see any reason for the symlink being removed from systemd-sysv.
After all, if you don't want that symlink, just use systemd, not -sysv.

If you for some reason insist on having systemd-sysv installed, but
/sbin/init pointing to something else, there's always dpkg-divert.  I
can't find any non-contrived reason to do that, though.

 Ideally, also, if systemd is installed on a system that is currently
 running sysvinit, that doesn't change what /sbin/init points to; the
 administrator has to do that as a separate operation.

That is how it is today.  If you want to change /sbin/init, you install
systemd-sysv.

I'm quite ok with what we're doing now: if you're installing something
that depends on systemd-sysv | systemd-shim, you get the new default
(systemd).  If you don't like the new default, you get to take positive
action to select what you would like to use instead.

[...]

  I have still not seen any reason whatsoever for this to be a command
  rather than just changing a configuration file.
 
 I have no problem with that.  I suggested a command because I thought
 the switch might be more complicated than just changing what /sbin/init
 is symlinked to, but right now it looks to me like that should be enough.

Ok, good, then we're in agreement about that at least.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#746577: closed by Michael Biebl bi...@debian.org (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

[Tollef Fog Heen]

]] Zack Weinberg 

 On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen tfh...@err.no wrote:
  ]] Zack Weinberg
  Fundamentally what I want is a bulletproof procedure for reverting to
  sysvinit in case something goes wrong.
 
  Sounds like you're arguing that sysvinit-core should no longer ship
  /sbin/init, then, so systemd-sysv doesn't have to conflict with it.
 
 Wouldn't that make the sysvinit implementation of /sbin/init
 completely unavailable?  This is an earnest question.  I do not have
 access to package contents right now.

No, to revert you'd boot with init=/sbin/sysvinit.

 Note that coinstallability is not enough -- the bulletproof procedure
 (e.g. update-init-system) must also be implemented, shipped, and
 documented.

I have still not seen any reason whatsoever for this to be a command
rather than just changing a configuration file.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#746577: closed by Michael Biebl bi...@debian.org (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

[Tollef Fog Heen]

]] Zack Weinberg 

 On 2014-05-03 12:18 PM, Tollef Fog Heen wrote:
  Zack Weinberg wrote:
  1) Switching from sysvinit to systemd (and vice versa, if necessary)
  should be accomplished via a command dedicated to the purpose; it
  should *not* occur as a side effect of installing, removing,
  upgrading, or downgrading any package.
 
  So you say.  I (with my systemd maintainer hat on) disagrees, and this
  has already been in wheezy and works quite well.
 
  2) The procedure I described should be the official procedure for
  making the changeover.
 
  Again, you say so, but provide no rationale or reason why.
 
 Fundamentally what I want is a bulletproof procedure for reverting to
 sysvinit in case something goes wrong.  I made an analogy earlier to
 how upgrading to a newer upstream kernel (with Debian's packaging)
 keeps the old kernel installed and trivially bootable, in case
 something goes wrong.  This is not because the kernel maintainers know
 of specific situations where something *will* go wrong; it is because
 there is a nontrivial chance that something *could* go wrong, and in
 the worst case that will render the system unbootable.

Sounds like you're arguing that sysvinit-core should no longer ship
/sbin/init, then, so systemd-sysv doesn't have to conflict with it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#746577: closed by Michael Biebl bi...@debian.org (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

[Tollef Fog Heen]

]] Zack Weinberg 

 On Fri, May 2, 2014 at 12:48 PM, Michael Biebl bi...@debian.org wrote:
  This is already possible today: The systemd package (intentionally)
  doesn't conflict with sysvinit-core since there are no file conflicts.
 
  You can install it and boot with init=/lib/systemd/systemd.
  The systemd-sysv package is intentionally conflicting with
  sysvinit-core, since systemd-sysv ships /sbin/init (as a symlink to
  /lib/systemd/systemd).
 
  So no, I'm not entirely sure what you are looking for.
 
 Oh good, almost all the work has been done then!
 
 1) Switching from sysvinit to systemd (and vice versa, if necessary)
 should be accomplished via a command dedicated to the purpose; it
 should *not* occur as a side effect of installing, removing,
 upgrading, or downgrading any package.

So you say.  I (with my systemd maintainer hat on) disagrees, and this
has already been in wheezy and works quite well.

 2) The procedure I described should be the official procedure for
 making the changeover.

Again, you say so, but provide no rationale or reason why.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#742034: [Pkg-clamav-devel] Bug#742034: clamav-daemon: postinst creates broken config file

[Tollef Fog Heen]

]] Scott Kitterman 

 This is 741765. Fixed in unstable and I'll update stable and oldstable 
 shortly. 

I doubt it is, since 741765 is «timps: FTBFS: nafconsole.c:611:38:
error: 'CPPFunction' undeclared (first use in this function)»

I think you mean #741675. :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#742034: clamav-daemon: postinst creates broken config file

[Tollef Fog Heen]

Package: clamav-base
Version: 0.98.1+dfsg-1+deb7u2
Severity: serious

My generated clamd.conf contains:

LogRotate 10 clamav-base/LogRotate doesn't exist

This looks like fallout from the lack of error handling in the
postinst.

This obviously breaks clamav-daemon on startup.

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---

Config file: freshclam.conf
---

clamav-milter.conf not found

Software settings
-
Version: 0.98.1
Optional features supported: MEMPOOL IPv6 FRESHCLAM_DNS_FIX AUTOIT_EA06 BZIP2 
JIT

Database information

Database directory: /var/lib/clamav/
WARNING: freshclam.conf and clamd.conf point to different database directories
bytecode.cld: version 236, sigs: 43, built on Wed Feb  5 18:36:14 2014
main.cld: version 55, sigs: 2424225, built on Tue Sep 17 16:57:28 2013
daily.cld: version 18619, sigs: 828177, built on Tue Mar 18 05:44:10 2014
Total number of signatures: 3252445

Platform information

uname: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
OS: linux-gnu, ARCH: x86_64, CPU: x86_64
Full OS version: Ubuntu 8.04.4 LTS
zlib version: 1.2.7 (1.2.7), compile flags: a9
Triple: x86_64-pc-linux-gnu
CPU: i686, Little-endian
platform id: 0x0a214c4c0804070201040702

Build information
-
GNU C: 4.7.2 (4.7.2)
GNU C++: 4.7.2 (4.7.2)
CPPFLAGS: -D_FORTIFY_SOURCE=2
CFLAGS: -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall
CXXFLAGS: -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall
LDFLAGS: -Wl,-z,relro
Configure: 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
-Wall' 'LDFLAGS=-Wl,-z,relro' '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-clamav' 
'--with-dbdir=/var/lib/clamav/' '--sysconfdir=/etc/clamav' '--enable-milter' 
'--disable-clamuko' '--with-gnu-ld' '--enable-dns-fix' '--disable-unrar' 
'--libdir=/usr/lib' '--with-system-tommath' '--without-included-ltdl' 
'build_alias=x86_64-linux-gnu'
sizeof(void*) = 8
Engine flevel: 76, dconf: 76

--- data dir ---
totalt 211836
-rw-r--r-- 1 clamav clamav345088 feb.   5 19:27 bytecode.cld
-rw-r--r-- 1 clamav clamav  53085696 mars  18 06:27 daily.cld
-rw-r--r-- 1 clamav clamav 163468288 sep.  18 00:13 main.cld
-rw--- 1 clamav clamav  1092 mars  18 08:27 mirrors.dat

-- System Information:
Distributor ID: Ubuntu
Description:Ubuntu 8.04.4 LTS
Release:8.04
Codename:   hardy
Architecture: amd64 (x86_64)

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

Versions of packages clamav-daemon depends on:
ii  clamav-base 0.98.1+dfsg-1+deb7u2
ii  clamav-freshclam [clamav-data]  0.98.1+dfsg-1+deb7u2
ii  libbz2-1.0  1.0.6-4
ii  libc6   2.13-38+deb7u1
ii  libclamav6  0.98.1+dfsg-1+deb7u2
ii  libncurses5 5.9-10
ii  libtinfo5   5.9-10
ii  lsb-base4.1+Debian8+deb7u1
ii  ucf 3.0025+nmu3
ii  zlib1g  1:1.2.7.dfsg-13

clamav-daemon recommends no packages.

Versions of packages clamav-daemon suggests:
pn  clamav-docs  none
pn  daemon   none

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#704423: systemd: gdm does not start, user sessions have multiple issues, root session works normally

[Tollef Fog Heen]

]] Alex Vanderpol 

 (I have to wonder now, though... if that package is necessary to make
 things work properly, why isn't a dependency of the package?)

Because it's not always needed, hence fits the definition of a
Recommends perfectly:

  This declares a strong, but not absolute, dependency.

  The Recommends field should list packages that would be found together
  with this one in all but unusual installations.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#695906: ifupdown: removal of /etc/network/interfaces is not preserved

[Tollef Fog Heen]

Package: ifupdown
Version: 0.7.5
Severity: serious
Justification: Overwrites local changes to configuration

Steps to reproduce:

rm /etc/network/interfaces
apt-get --reinstall install ifupdown

observe that /etc/network/interfaces exists.

If I remove the file, that change should be preserved on upgrades.

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

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

Versions of packages ifupdown depends on:
ii  dpkg 1.16.9
ii  initscripts  2.88dsf-34
ii  iproute  20120521-3
ii  libc62.13-35
ii  lsb-base 4.1+Debian8

ifupdown recommends no packages.

Versions of packages ifupdown suggests:
ii  isc-dhcp-client [dhcp-client]  4.2.2.dfsg.1-5+deb70u2
ii  net-tools  1.60-24.2
ii  ppp2.4.5-5.1+b1
pn  rdnssd none

-- debconf information:
  ifupdown/convert-interfaces: true
  ifupdown/convert-interfaces-hotplug: true

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#695906: ifupdown: removal of /etc/network/interfaces is not preserved

[Tollef Fog Heen]

]] Bob Proulx 

 Tollef Fog Heen wrote:
  rm /etc/network/interfaces
  apt-get --reinstall install ifupdown
  observe that /etc/network/interfaces exists.
  If I remove the file, that change should be preserved on upgrades.
 
 But /etc/network/interfaces is not an ifupdown conffile.

It's a configuration file, and removing a configuration file is, or at
least has historically been, a completely valid local change.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#695906: Bug#688772: gnome Depends network-manager-gnome

[Tollef Fog Heen]

]] Steve Langasek 

 On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote:
  ]] Steve Langasek 
 
- Installing the gnome or the NM package must not cause the network to
  break on upgrade, even temporarily, under any circumstances.
 
  Is this a requirement for other network-providing packages as well?  If
  so, openvpn for instance is RC-buggy because upgrading it will restart
  any configured VPNs.  We don't require other packages to continue to
  work uninterrupted during upgrades, and while I can agree NM is in a bit
  of special situation by virtue of controlling the network, I am not sure
  being as strict as you are here is reasonable.
 
 Sorry, my wording was a bit sloppy there.  What I meant to say was, an
 upgrade that pulls in either gnome or network-manager as a new package must
 not cause the network to break, even temporarily.  So on new installation
 of the NM package, my expectation is that it will not tamper with the
 current network state, because doing so may break the admin's remote
 connection to the machine.

Ok, fair enough.

 I think it's important that an upgrade of the NM package *also* not cause
 the network to drop, but that's a slightly different point than the one I
 was meaning to make.

My question then still stands: Do you consider NM in any way special
here or does the same requirement apply to other network-providing apps?

- Installing the gnome or the NM package must not cause any network
  configuration the user has specified to be lost.
 
  This is reasonable, and makes ifupdown RC-buggy, since rm-ing
  /etc/network/interfaces and reinstalling the package will change the
  network configuration (the file is recreated).  I've just filed a bug
  about this.
 
 I think you're missing several steps in your proof that this is RC buggy. ;)

I had enough steps in there that one of the release managers agreed with
me.

 The policy requirement isn't that *filesystem* changes be preserved, it's
 that *configuration* changes be preserved.  In what way does deleting
 /etc/network/interfaces constitute a valid configuration that must be
 preserved?

The policy requirement is not that the configuration changes are
valid. It's not ok to replace a config file just because it has a syntax
error in it, is it?  Also, see below.

 When ifupdown recreates the file, it populates it only with a
 config for lo.  I don't think it's reasonable to claim that it's valid and
 intentional to configure a system in such a way that it will fail to bring
 up the loopback interface on boot.  In fact, booting the system without lo
 breaks so many assumptions that Ubuntu, for example, *unconditionally*
 brings up lo on boot, whether or not it's configured in
 /etc/network/interfaces.  I consider restoring a stock /e/n/i on package
 upgrade to be in the same category.

Putting «iface lo» into /etc/network/interfaces is not only a way to
ensure there is a loopback interface on boot. It's also a way for
ifupdown to claim to handle that interface (this is a natural
consequence of the CTTE ruling; that ifupdown is special and has
precedence and other tools should stay away from interfaces where there
is a ifupdown configuration for the interface), so if ifupdown does add
that configuration, there is no way for me to have ifupdown installed so
I can read the man page at the same time as letting other tools manage
lo.

I might also dislike the name «lo» for loopback and rename the lo
interface to something else, and let «lo» be the name of yet another
interface. It's a bit crazy, but not much cares about network interface
names apart from the network configuration tools, so this would actually
break a most unusual, but otherwise valid configuration of the network
stack.  ifupdown would break that configuration.

 If the reason you raise this concern is because of my comment that NM should
 always report the system online unless it controls all the network
 interfaces, I was implicitly excluding lo from the reckoning.  First,
 it's not relevant to whether the machine is online, and second, there's only
 one valid state for this interface (up) so there's no configuration to
 fight over the management of.

Your mail triggered me to go look, but it wasn't otherwise directly
related, no.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#695906: Bug#688772: gnome Depends network-manager-gnome

[Tollef Fog Heen]

]] Steve Langasek 

 And by the way, if you're going to treat it as a serious bug, you'd better
 get filing other bugs for consistency.  Just off the top of my head,
 base-passwd has had the same handling of /etc/passwd for *years* without
 anyone objecting.  To me, this is very clearly a matter of moving the goal
 posts.

I file those bugs whenever I see them and has been doing this for a
while.  See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558784 for
another example.

  It's not ok to replace a config file just because it has a syntax error in
  it, is it?  Also, see below.
 
 Replace, no.  Repair, maybe.

I don't think it should do that, it should notify the admin.  Trying to
guess the intentions of admins is not particularly easy.

   When ifupdown recreates the file, it populates it only with a
   config for lo.  I don't think it's reasonable to claim that it's valid and
   intentional to configure a system in such a way that it will fail to bring
   up the loopback interface on boot.  In fact, booting the system without lo
   breaks so many assumptions that Ubuntu, for example, *unconditionally*
   brings up lo on boot, whether or not it's configured in
   /etc/network/interfaces.  I consider restoring a stock /e/n/i on package
   upgrade to be in the same category.
 
  Putting «iface lo» into /etc/network/interfaces is not only a way to
  ensure there is a loopback interface on boot. It's also a way for
  ifupdown to claim to handle that interface (this is a natural
  consequence of the CTTE ruling; that ifupdown is special and has
  precedence and other tools should stay away from interfaces where there
  is a ifupdown configuration for the interface), so if ifupdown does add
  that configuration, there is no way for me to have ifupdown installed so
  I can read the man page at the same time as letting other tools manage
  lo.
 
 I don't see where the previous TC ruling says that ifupdown is special. 
 Rather, it says that upgrading gnome-core shouldn't cause network-manager to
 clobber the user's network preferences on upgrade, /whichever/ tool they
 were using to manage those.

I did explicitly say it was a natural consequence of the ruling, not
that the ruling itself said so.  The alternative is for the relation to
be symmetrical, so ifupdown should stay away from managing interfaces
where there exists a NM config for the interface without there existing
an explicit configuration for the ifupdown interface?  It's easy enough
to generate such a configuration by using mappings, for instance.

This becomes a nightmare once you drag wicd into this and all tools need
to know about what other tools might want to manage an interface.  I
think it's important that we end up with something that's actually
supportable, rather than something which might be formally better, but
in practice so complex it becomes brittle beyond repair.

 That should be trivially easy in the case of lo.  If the /e/n/i entry for lo
 is missing, or matches this:
 
   iface lo inet loopback
 
 ... it's fair game.  If it's something else, then /against all reason/, the
 user has configured lo in a non-standard way, and NM should respect that.
 
 So I don't think this bug in ifupdown in any way blocks NM from being able
 to do the right thing.  If you disagree, let's explore this further.

I don't think I've said it blocks NM from doing the right thing.  I've
said it's a bug in ifupdown.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#692916: wicd-daemon: Using non-Essential tools in config script

[Tollef Fog Heen]

Package: wicd-daemon
Severity: serious
Version: 1.7.2.4-3

(possibly also older versions)

from wicd-daemon.config:

# Add selected users
for u in $users; do
hasuser=$((getent passwd | grep -w $u) || true)
if [ -n $hasuser ]; then
adduser --quiet $u netdev
fi
done

adduser is not Essential: yes, and the config script must work with only
Essential packages installed.  (See 3.9.1 Prompting in maintainer
scripts in policy.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#685317: ruby-merb-haml: missing dependency on ruby-haml

[Tollef Fog Heen]

Package: ruby-merb-haml
Version: 1.1.3-1
Severity: serious

ruby-merb-haml imports haml and so needs to depend on it.

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

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

Versions of packages ruby-merb-haml depends on:
ii  ruby  4.9
ii  ruby1.8 [ruby-interpreter]1.8.7.358-4
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-1

ruby-merb-haml recommends no packages.

ruby-merb-haml suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#679728: systemd: diversion removed in postinst, should be removed in preinst

[Tollef Fog Heen]

]] Teodor MICU 

Hi,

 2012/7/2 Tollef Fog Heen tfh...@err.no:
  That's quite odd.
 
  Can you please provide the output of «grep systemd /var/log/dpkg.log»?
 
 See below. I've reinstalled «systemd» this morning on my workstation.

Ah, it looks like it never actually got to the configure step of
systemd.  Does that sound correct, and is the diversion correctly
removed now?  If not, could you please try downgrading to 44-2 and then
upgrading and verifying that the diversion is gone?

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#679728: systemd: diversion removed in postinst, should be removed in preinst

[Tollef Fog Heen]

]] Teodor MICU 

 Diversion is not removed at all on package removal:

 | root@frost:~# ls -hl /lib/lsb/
 | total 16K
 | drwxr-xr-x 2 root root 4.0K Jul  2 11:11 init-functions.d
 | -rw-r--r-- 1 root root  12K May 30 17:01 init-functions.systemd
 | root@frost:~# dpkg -S /lib/lsb/init-functions.d
 | lsb-base: /lib/lsb/init-functions.d
 | root@frost:~# dpkg -S /lib/lsb/init-functions.systemd
 | diversion by systemd from: /lib/lsb/init-functions
 | diversion by systemd to: /lib/lsb/init-functions.systemd
 |
 | root@frost:~# dpkg -l '*systemd*'
 | ii  libsystemd-daemon0:i 44-3i386
 | ii  libsystemd-login0:i3 44-3i386
 | un  systemd  none

Did you upgrade to 44-3 before removing it or not?

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#679728: systemd: diversion removed in postinst, should be removed in preinst

[Tollef Fog Heen]

]] Teodor MICU 

 2012/7/2 Tollef Fog Heen tfh...@err.no:
  Did you upgrade to 44-3 before removing it or not?
 
 Yes, I've upgraded almost all packages (including systemd) and then
 reported Bug#679873: lsb-base: Can't open /lib/lsb/init-functions.
 
 Later I've uninstalled systemd packages to work around the problem,
 but I've discovered that systemd removal is not enough.

That's quite odd.

Can you please provide the output of «grep systemd /var/log/dpkg.log»?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#675161: Still present in 1:1.0.1-1

[Tollef Fog Heen]

found 675161 1:1.0.1-1
thanks

I'm still seeing this bug with:

ii  xserver-xorg-video-nouve 1:1.0.1-1X.Org X server -- Nouveau 
display driver

it seems like it happens less frequently than with older versions.

To the extent it matters, my gfx card is

01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 
Ti] (rev a1)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#679728: systemd: diversion removed in postinst, should be removed in preinst

[Tollef Fog Heen]

Package: systemd
Version: 44-2
Severity: serious

This breaks other packages installed in the same apt run.

00:12  uau Mithrandir: with latest debian systemd package, 
/lib/lsb/init-functions doesn't exist between unpacking 
 and postinst that removes diversion
00:12  uau /etc/init.d/vsftpd: 22: .: Can't open /lib/lsb/init-functions
- vsftpd prerm executed during that 
 interval

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

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

Versions of packages systemd depends on:
ii  dpkg 1.16.4.3
ii  initscripts  2.88dsf-22.1
ii  libacl1  2.2.51-8
ii  libaudit01:1.7.18-1.1
ii  libc62.13-33
ii  libcap2  1:2.22-1
ii  libcryptsetup4   2:1.4.3-2
ii  libdbus-1-3  1.6.0-1
ii  libkmod2 8-2
ii  liblzma5 5.1.1alpha+20120614-1
ii  libpam0g 1.1.3-7.1
ii  libselinux1  2.1.9-5
ii  libsystemd-daemon0   44-2
ii  libsystemd-id128-0   44-2
ii  libsystemd-journal0  44-2
ii  libsystemd-login044-2
ii  libudev0 175-3.1
ii  libwrap0 7.6.q-23
ii  udev 175-3.1
ii  util-linux   2.20.1-5.1

Versions of packages systemd recommends:
ii  libpam-systemd  44-2

Versions of packages systemd suggests:
ii  python2.7.3~rc2-1
ii  python-cairo  1.8.8-1+b2
ii  python-dbus   1.1.0-1
pn  systemd-gui   none

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#676817: systemd and dovecot

[Tollef Fog Heen]

]] Nicholas Bamber 

  However, whilst I don't know anything about systemd, this still looks
  like a little broken. I am puzzled that the dependency is on systemd and
  not libsystemd-daemon-dev. After all the libsystemd-daemon-dev package
  contains the /usr/include/systemd/sd-daemon.h file which is included
  by some dovecot source files.

It might be for the systemd.pc file, which is shipped in systemd itself.

The reason for this is I don't see a point in having a systemd-dev
package that only contains this file, when installing systemd doesn't
actually hurt or change your system any more than any other random
non-daemon package.

I think it's fairly obvious this build-dependency only makes sense on
Linux, yes.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#676817: systemd and dovecot

[Tollef Fog Heen]

]] Nicholas Bamber 

 Tollef,
   Thanks for the response. What about the libsystemd-daemon-dev package?
 Is that required (on Linux)?

I don't know in detail why dovecot build-deps on systemd, but I believe
it's for the socket activation.  It can either include sd-daemon.[ch] in
the source tree, in which case no build-dependency is needed, or it can
use the files from the systemd tree, in which case the dependency is
needed.  I don't know which of those solutions dovecot has chosen.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#676817: systemd and dovecot

[Tollef Fog Heen]

]] Nicholas Bamber 

Hi,

I would be most grateful if you quoted the way is usually done on email
lists.

   I would be very grateful if you could have a look. Andreas Barth has
 basically repeated the point I made in the third paragraph of my
 original post.

Yes, and you're both mistaken.  systemd is not a normal daemon package,
it does not start any daemons, nor replace init merely by being
installed.  Installing systemd onto a system is about as intrusive to
the system as a whole as installing nvi.

 Nothing you have said is really reassuring me. You talk about how a
 package needs something to make socket activation to work and
 sd-daemon.h is a way to do that. Well that file is available in
 libsystemd-daemon-dev, and the current package as a dependency on
 systemd rather than libsystemd-daemon-dev. It might be right but it
 does not feel right.

I would suggest you ask the dovecot maintainer why he build-depends on
systemd rather than libsystemd-daemon-dev if it is in fact for the
reasons I listed.  I gave a suggestion as to why he would do so, as well
as a reason for why systemd.pc is not in its own package, but as I am
not the maintainer of dovecot and there's no way for me to actually
know, short of asking, which you can just as easily do yourself.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#668307: initscripts: recreates /etc/motd

[Tollef Fog Heen]

Package: initscripts
Version: 2.88dsf-22.1
Severity: serious
Justification: policy 10.7.3, does not preserve local changes

: tfheen@qurzaw ~  sudo rm -f /etc/motd
: tfheen@qurzaw ~  sudo dpkg-reconfigure initscripts
: tfheen@qurzaw ~  ls -l /etc/motd*
lrwxrwxrwx 1 root root  13 april 10 22:41 /etc/motd - /var/run/motd

It shouldn't recreate that file if the admin has removed it.

(It should also point at /run rather than /var/run, but that's a more
minor matter.)

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

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

Versions of packages initscripts depends on:
ii  coreutils   8.13-3.1
ii  debianutils 4.3
ii  libc6   2.13-27
ii  lsb-base4.1+Debian0
ii  mount   2.20.1-4
ii  sysv-rc 2.88dsf-22.1
ii  sysvinit-utils  2.88dsf-22.1
ii  ucf 3.0025+nmu2

Versions of packages initscripts recommends:
ii  e2fsprogs  1.42.2-1
ii  psmisc 22.16-1

initscripts suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#668312: sysv-rc: hidden dotfile in /etc used as state file (/etc/init.d/.legacy-bootordering)

[Tollef Fog Heen]

Package: sysv-rc
Version: 2.88dsf-22.1
Severity: serious
Justification: FHS violation, does not respect local admin changes

sysv-rc uses /etc/init.d/.legacy-bootordering as a flag file, which is
essentially a state file to know whether to convert to new ordering or
not.  It should live in /var/lib/sysv-rc or similar instead.

If this is meant to be a configuration file, it must not be recreated
after it's deleted.  It should probably also not be a hidden file, since
there's no good reason for it.

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

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

Versions of packages sysv-rc depends on:
ii  debconf [debconf-2.0]  1.5.42
ii  insserv1.14.0-2.2
ii  sysvinit-utils 2.88dsf-22.1

Versions of packages sysv-rc recommends:
ii  lsb-base  4.1+Debian0

Versions of packages sysv-rc suggests:
pn  bum   none
pn  sysv-rc-conf  none

-- debconf information:
* sysv-rc/unable-to-convert:
  sysv-rc/convert-legacy: true

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#558784: status of this bug?

[Tollef Fog Heen]

]] Helmut Grohne 

 Using regular files might be easier to implement, because shipping those
 files in /etc makes them conffiles. Using symbolic links may be a
 cleaner solution. Using more files provides more (or easier) flexibility
 to the user and therefore seems preferable even though it causes more
 work. In order to support the current apt-key the
 debian-archive-removed-keys.gpg would need to include all present keys
 (and thus clean trusted.gpg). The change would again loose user
 configuration, but this seems unavoidable to me.

Well, it would be reasonable to:

ship all keys in keyring package, as symlinks or files in /etc
for each key in $shipped_keyring:
  if key not present in /etc/apt/trusted.gpg and we're upgrading from 
$flag_version
remove /etc/apt/trusted.gpg.d/$key (if it's the right key)

This will preserve user changes just fine, AFAICS?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#642961: systemd: debian-fixup.service goes berserk in /run, breaks boot

[Tollef Fog Heen]

]] Alban Browaeys 

| oneshot should be a good answer . Ie it will break at first shot only
| but still break.

Why would it break?

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#642961: systemd: debian-fixup.service goes berserk in /run, breaks boot

[Tollef Fog Heen]

]] Eckhart Wörner 

| However, this seems to break on /var/run already being bind-mounted on
| /run. The condition holds, and therefore /run (aka /var/run) is wiped
| out, breaking the boot process.

Can you see if the attached patch fixes this?

diff --git a/debian/debian-fixup.service b/debian/debian-fixup.service
index 5b391db..6848466 100644
--- a/debian/debian-fixup.service
+++ b/debian/debian-fixup.service
@@ -6,5 +6,5 @@ DefaultDependencies=no
 
 [Service]
 ExecStart=/lib/systemd/debian-fixup
-Type=simple
+Type=oneshot
 RemainAfterExit=true

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#622756: [buildd-tools-devel] Bug#622756: Bug#622756: Installing systemd breaks schroot

[Tollef Fog Heen]

]] Roger Leigh 

| We currently use rbind for /dev, /sys and /proc.  Could you possibly
| let me know what's mounted under each on the /host/, minus the
| autofs mounts?  A complete list of the autofs mountpoints would also
| be useful.

A slightly fuller list:

rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,relatime 0 0
none /dev devtmpfs rw,relatime,size=1987396k,nr_inodes=496849,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=797768k,mode=755 0 0
/dev/mapper/qurzaw-root / ext4 
rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup 
rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/ns cgroup rw,nosuid,nodev,noexec,relatime,ns 0 0
cgroup /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0
cgroup /sys/fs/cgroup/cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
systemd-1 /dev/mqueue autofs 
rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /dev/hugepages autofs 
rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /sys/kernel/debug autofs 
rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs 
rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /sys/kernel/security autofs 
rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /lib/init/rw autofs 
rw,relatime,fd=37,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
tmpfs /var/lock tmpfs rw,nosuid,relatime,size=797768k,mode=755 0 0
tmpfs /media tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
tmpfs /var/run tmpfs rw,nosuid,relatime,size=797768k,mode=755 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
/dev/sda1 /boot ext4 rw,relatime,errors=remount-ro,barrier=1,data=writeback 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,relatime 0 0

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#622756: [buildd-tools-devel] Bug#622756: Installing systemd breaks schroot

[Tollef Fog Heen]

-xr-x  13 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys
drwxr-xr-x  11 root root  220 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/blkio
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/cpu
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/cpuacct
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/cpuset
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/devices
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/freezer
drwxr-xr-x   2 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/net_cls
drwxr-xr-x   6 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/ns
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/cgroup/systemd
drwxr-xr-x   2 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/fs/fuse/connections
drwxr-xr-x  17 root root0 Apr 14 20:45 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/kernel/debug
drwxr-xr-x  17 root root0 Apr 14 20:45 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/kernel/debug
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/kernel/security
drwxr-xr-x   3 root root0 Apr 14 18:36 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/sys/kernel/security

| What is systemd doing here that we're breaking on?  Is /dev/mqueue
| a symlink or separate mount?  Why is the umount failing so badly?

It's an autofs mount:

: tfheen@qurzaw ~  mount | grep mqueue
systemd-1 on /dev/mqueue type autofs 
(rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
systemd-1 on 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/dev/mqueue
 type autofs (rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on 
/var/lib/schroot/mount/squeeze-i386-fb18d103-2f36-42a7-b430-6014096537fe/dev/mqueue
 type mqueue (rw,relatime)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#620125: calibre: Segfaults on startup

[Tollef Fog Heen]

 for the libxml2 a
ii  python-mechanize   0.1.11-1.1stateful programmatic web browsing
ii  python-pkg-resources   0.6.14-4  Package Discovery and Resource Acc
ii  python-pyparsing   1.5.2-2   Python parsing module
ii  python-pypdf   1.12-3PDF toolkit implemented solely in 
ii  python-pythonmagick0.9.1-3+b1Object-oriented Python interface t
ii  python-qt4 4.8.3-1   Python bindings for Qt4
ii  python-routes  1.12.3-1  Routing Recognition and Generation
ii  ttf-liberation 1.06.0.20100721-1 Fonts with the same metrics as Tim
ii  xdg-utils  1.1.0~rc1-2   desktop integration utilities from

Versions of packages calibre recommends:
ii  python-dnspython  1.8.0-1DNS toolkit for Python

calibre suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#608443: Processed: your mail

[Tollef Fog Heen]

severity 608443 important
thanks

]]  (Debian Bug Tracking System)

|  severity 608443 grave
| Bug #608443 {Done: Tollef Fog Heen tfh...@debian.org} 
[yubikey-personalization] yubikey-personalization: AES key generation is 
unsecure (no salt used)
| Severity set to 'grave' from 'normal'

I don't see why you think missing salting should be grave.  Sure, it
should be fixed, but it's hardly the end of the world.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#592620: time: diff for NMU version 1.7-23.1

[Tollef Fog Heen]

]] gregor herrmann 

| Salvatore has prepared an NMU for time (versioned as 1.7-23.1) and
| I've uploaded it to DELAYED/5 on his request. Please feel free to
| tell me if I should delay it longer.

Five days is plenty; thanks for taking the time to prepare the NMU.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#582995: Not only CFLAGS

[Tollef Fog Heen]

]] Jo Shields 

| pkg-config should not escape : in calls to --libs either. It's broken
| building basically every Mono app or lib in the archive.

I have a 0.25 in the pipeline which should be released either tonight or
tomorrow which fixes this.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#580020: clamav-base: always edits /etc/aliases (does not respect admin changes)

[Tollef Fog Heen]

Package: clamav-base
Severity: serious
Justification: violates policy §10.7.3 Behavior
Version: 0.96+dfsg-4

From clamav-base.postinst:

  if [ -f /etc/aliases ] || [ -L /etc/aliases ]; then
if ! grep -qi ^clamav /etc/aliases; then
  echo clamav: root  /etc/aliases
  newal=`which newaliases || true`
  if [ -n $newal ]  [ -x $newal ]; then
$newal || true
  fi
fi
  fi

This means there is no way for me to not have the clamav alias in
/etc/aliases, for instance if I want to have it defined somewhere else.

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

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

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are



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

Bug#565539: Processed: Reopening #565539 as sash still FTBFS on the kfreebsd buildds

[Tollef Fog Heen]

severity 565539 important
thanks

]]  (Debian Bug Tracking System)

|  severity 565539 serious
| Bug #565539 [sash] sash: FTBFS on kfreebsd
| Severity set to 'serious' from 'important'

How is this serious, given that sash hasn't previously built on
kfreebsd?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#575067: ohai: does not depend on ruby, but calls ruby

[Tollef Fog Heen]

 Mar 2010 10:02:43 +0100] DEBUG:  End uname -v STDERR 
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG: Ran  (uname -v) returned 0
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG:  Begin uname -m STDOUT 
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG: i686
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG:  End uname -m STDOUT 
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG:  Begin uname -m STDERR 
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG: 
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG:  End uname -m STDERR 
[Tue, 23 Mar 2010 10:02:43 +0100] DEBUG: Ran  (uname -m) returned 0
/usr/lib/ruby/1.8/ohai/system.rb:121:in `join': can't convert nil into String 
(TypeError)
from /usr/lib/ruby/1.8/ohai/system.rb:121:in `all_plugins'
from /usr/lib/ruby/1.8/ohai/system.rb:118:in `each'
from /usr/lib/ruby/1.8/ohai/system.rb:118:in `all_plugins'
from /usr/lib/ruby/1.8/ohai/application.rb:89:in `run_application'
from /usr/lib/ruby/1.8/ohai/application.rb:67:in `run'
from /usr/bin/ohai:40

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Navn  Versjon   Beskrivelse
+++-=-=-==
un  ruby  ingen   (ingen beskrivelse 
tilgjengelig)
ii  libohai-ruby1.8   0.5.0-1   Ruby 1.8 library to 
collect data about your operating system
ii  ohai  0.5.0-1   Detects data about your 
operating system and reports it in JSON

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

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

-- 
Tollef Fog Heen
Varnish Software
t: +47 21 54 41 73



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

Bug#558784: apt: re-adds removed keys

[Tollef Fog Heen]

]] David Kalnischkies 

| I still don't think it is a real bug as APT has a hard dependency on
| debian-archive-keyring ~ it doesn't recommend this keys, it says:
| You must have ALL these keys installed to use APT correctly and
| on the other hand i see no reason why someone want to remove a
| key from the debian-archive-keyring which would be not better be
| done by the package itself for all users…
| (we could questioning the dependency itself now of course)

Let's agree to disagree about this? :-)

[...]

| The big advantage is that we would no longer need apt-key and
| therefore gpg to add/remove keys to apt's trusted keyring:
| Simple mv, cp  rm would be enough for managing, gpgv for usage and
| gnupg could be dropped from Priority:important-list (see #387688).

Oh, this is great news.

| The small advantage for you would be that this fragment files could
| be real dpkg conf-files and neither apt nor debian-archive-keyring would need
| special code (aka apt-key update) to ensure a correctly setupped keyring.
| 
| The files are still binary files so dpkgs conffile handling wouldn't be that
| helpful, but at least the md5sum mismatch would be noticeable…
| (Yes, binary is required here as gpgv only supports the binary format)
| On the other hand the keyrings could be fragmented in
| debian-archive-keyring-lenny.gpg, debian-archive-keyring-squeeze.gpg,
| whatever.gpg so the situation would be in 99% of all cases
| a removed conffile instead of a modified… (if modified at all).

Sure, binary files in /etc is somewhat icky from a diff(1) point of
view, but I at least can live with that.

| Oh, and yes, after that apt could lower the debian-archive-keyring
| dependency to recommends as it wouldn't need to set it up any longer,
| but i would like to defer this discussion to some point after squeeze…

Works for me.

Thanks for your work on this. :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#565896: closed by Ludovic Rousseau rouss...@debian.org (Bug#565896: fixed in pcsc-lite 1.5.5-2)

[Tollef Fog Heen]

reopen 565896
found 565896 1.5.5-2
thanks

]]  (Debian Bug Tracking System)

|* debian/update-reader.conf: add a SHA1 on the first line of the
|  configuration file to detect manual edition. Closes: #565896 pcscd:
|  overwrites changes in configuration files
|  urgency=medium because of RC bug.

This isn't enough, you still don't handle the case of /etc/readers.conf
being deleted.  Wouldn't it be easier just to use ucf than to reinvent
it?  Using ucf would also allow the user to review any updates and merge
them if appropriate.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#566680: winwrangler: Should not be in unstable, and should not be released with squeeze

[Tollef Fog Heen]

Package: winwrangler
Severity: serious
Version: 0.2.4-2

From winwrangler's description:

Disclaimer: This package is based on a very early release of
WinWrangler and should not be considered production ready by a long
shot.

winwrangler then should not be in unstable, but experimental, or it
should _at least_ have a serious bug filed against it to ensure it does
not get released with squeeze.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#565896: pcscd: overwrites changes in configuration files

[Tollef Fog Heen]

]] Ludovic Rousseau 

| The /etc/reader.conf contains a warning:
| # Do NOT edit this file directly but use update-reader.conf(8) instead.
| 
| update-reader.conf(8) checks that the /etc/reader.conf contains the line:
| ### This file is automatically generated by update-reader.conf
| So a config file written by hand from scratch is _not_ overwritten.

Sure, but that's not the wording in policy, it is that you must preserve
user changes. :-)

| What should the update-reader.conf if the file have been manually
| modified?
| 
| Do you have an example of an update-foo command that does what you
| request for?

Either aborting if the file is modified (with a sensible error message)
or not keeping reader.conf in /etc would both be acceptable
solutions. update-rc.d and update-passwd handle in-/etc updates.  As an
example of something storing the result in /var, take a look at
update-updmap for instance.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#565896: pcscd: overwrites changes in configuration files

[Tollef Fog Heen]

Package: pcscd
Version: 1.5.5-1
Severity: serious

update-reader.conf is called unconditionally in the postinst and
overwrites admin changes to /etc/reader.conf.  This is a violation of
policy 10.7.3.

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are



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

Bug#558784: apt: re-adds removed keys

[Tollef Fog Heen]

]] Julian Andres Klode 

|  so it is actually a double policy violation: removing
|  /etc/apt/trusted.gpg is a perfectly legal configuration change that apt
|  must not override.  Ditto, removing a key is a perfectly legal
|  configuration change that apt must not override in its postinst.
|
| We should move it to /var/lib/apt, cupt does this and it seems to be a
| much more logical location for such data.

Please note that it should still be possible to disable apt keys an
admin does not trust or want to ensure are not installed onto the
system.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#558784: apt: re-adds removed keys

[Tollef Fog Heen]

reopen 558784
thanks

]] David Kalnischkies 

| While i could agree with you on a (very high) metalevel that this could
| be a valid configuration change, i have a few very simple practical
| reasons why not:
|
| - first of all: /etc/apt/trusted.gpg is not a configuration file
|   [in dpkg sense] yes - it looks like one as it is in /etc - and it is in
|   some ways a configuration file, but not directly if you compare it to
|   normal configuration files like xorg.conf.

Yes, it's a configuration file.  If it's not, this is an FHS violation
as only configuration files should be in /etc. Dpkg does not have a
concept of configuration files, it has a concept of conffiles which are
shipped in the package.  The trusted.gpg file is not a conffile.  That
it is not a text file is irrelevant
here.  /etc/ssl/certs/ca-certificates.crt isn't a normal text file you
sit down and configure either.

As to whether it's a valid configuration change: why is it not?  Why is
adding more keys to the keyring valid if removing keys is not?  Why does
even apt-key provide a «remove» command if that's not a valid change of
configuration?

| - apt depends on debian-archive-keyring. So it explicitly says that it
|   requires the complete keyring to work correctly. A administrator who
|   removes parts of this keyring therefore doesn't make a valid configuration
|   change - he breaks the dependency apt has causing apt to do possibly
|   strange things (behavior of applications with broken dependencies is
|   undefined) - Including reimporting the keyring to fix it.
|   (A segfault would be also possible.)

The dependency isn't broken, I have d-a-k installed on the system, apt
and apt-key can access that keyring just fine, if not apt-key update
would not work.

If an application segfaults because of a missing key in a keyring,
that's surely a bug in the package; this whole argument sounds like a
strawman to me.

| - A keyring is a keyring because the keys together form a ring of trust.
|   If you don't trust a key in the ring, you can't trust the keyring
|   (if this wouldn't be the case a keyring should be called loosely coupled
|   group of keys), so if you remove a key you effectively remove the keyring.
|   This is disallowed by the dependency (as said in the previous point).

No.  GPG has a trust database where I can tell it how much I trust the
various keys.  That does not have anything to do with whether they are
in a single file or not.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#560151: mono: Missing source for mcs/class/RabbitMQ.Client/docs/specs/*.cs

[Tollef Fog Heen]

Package: mono
Severity: serious
Version: 2.4.2.3+dfsg-3

mcs/class/RabbitMQ.Client/docs/specs/*.cs in the source package are
auto-generated, but the script that was used to generate them and the
spec necessary to do so is not present.

I know the XML file the spec is shipped in is not even suitable for
non-free, but there is a BSD-licenced JSON description of the 0.8 and
0.9.1 (but not 0.9 yet) spec available from
http://hg.rabbitmq.com/rabbitmq-codegen/file/c3da3b2b0584

If you make your C# derivatives of the JSON description, that should be
ok, licence-wise.

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

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

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73



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

Bug#559683: aiccu: postinst depends on existence of /usr/share/doc/aiccu/examples/aiccu.conf

[Tollef Fog Heen]

Package: aiccu
Version: 20070115-10
Severity: serious

Hi,

From http://www.debian.org/doc/debian-policy/ch-docs.html#s12.3:
«Packages must not require the existence of any files in /usr/share/doc/
in order to function».

From aiccu's postinst:

EXAMPLE=/usr/share/doc/aiccu/examples/aiccu.conf

# Check if the /etc/aiccu.conf is actually the example
if [ diff -q $EXAMPLE $CONFIGFILE 2/dev/null /dev/null ]; then
DEFAULTCONFIG=true
else
DEFAULTCONFIG=false
fi

Also, you can't do if tests like that; what you want is

if diff -q $EXAMPLE $CONFIGFILE; then

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

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

Versions of packages aiccu depends on:
ii  debconf [debconf-2.0]   1.5.28   Debian configuration management sy
ii  iproute 20090324-1   networking and traffic control too
ii  iputils-ping3:20071127-2 Tools to test the reachability of 
ii  iputils-tracepath   3:20071127-2 Tools to trace the network path to
ii  libc6   2.10.2-2 GNU C Library: Shared libraries
ii  libgnutls26 2.8.5-2  the GNU TLS library - runtime libr
ii  lsb-base3.2-23   Linux Standard Base 3.2 init scrip

Versions of packages aiccu recommends:
ii  ntp 1:4.2.4p7+dfsg-4 Network Time Protocol daemon and u
ii  ntpdate 1:4.2.4p7+dfsg-4 client for setting system time fro

aiccu suggests no packages.

-- debconf information:
* aiccu/username: TFH1-RIPE
  aiccu/notunnels:
  aiccu/badauth:
* aiccu/tunnelname: T21085
  aiccu/nobrokers:
* aiccu/brokername: tic://tic.sixxs.net

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#558784: apt: re-adds removed keys

[Tollef Fog Heen]

Package: apt
Severity: serious
Version: 0.7.24
Justification: overwrites local configuration changes

I have removed some keys from my apt keyring, but it seems like apt
always re-adds them when configuring:

shashlik# apt-key list
/etc/apt/trusted.gpg

pub   1024D/6070D3A1 2006-11-20 [expired: 2009-07-01]
uid  Debian Archive Automatic Signing Key (4.0/etch) 
ftpmas...@debian.org

pub   1024D/ADB11277 2006-09-17
uid  Etch Stable Release Key debian-rele...@lists.debian.org

[...]

shashlik# apt-key remove ADB11277
OK
shashlik# apt-key update
gpg: key 6070D3A1: Debian Archive Automatic Signing Key (4.0/etch) 
ftpmas...@debian.org not changed
gpg: key ADB11277: public key Etch Stable Release Key 
debian-rele...@lists.debian.org imported
gpg: key BBE55AB3: Debian-Volatile Archive Automatic Signing Key (4.0/etch) 
not changed
gpg: key F42584E6: Lenny Stable Release Key debian-rele...@lists.debian.org 
not changed
gpg: key 55BE302B: Debian Archive Automatic Signing Key (5.0/lenny) 
ftpmas...@debian.org not changed
gpg: key 6D849617: Debian-Volatile Archive Automatic Signing Key (5.0/lenny) 
not changed
gpg: Total number processed: 6
gpg:   imported: 1
gpg:  unchanged: 5
gpg: no ultimately trusted keys found
shashlik# apt-key list
/etc/apt/trusted.gpg


[...]

pub   1024D/ADB11277 2006-09-17
uid  Etch Stable Release Key debian-rele...@lists.debian.org

shashlik# 

from apt.postinst:

case $1 in
configure)

if ! test -f /etc/apt/trusted.gpg; then
cp /usr/share/apt/debian-archive.gpg /etc/apt/trusted.gpg
fi

apt-key update

;;

so it is actually a double policy violation: removing
/etc/apt/trusted.gpg is a perfectly legal configuration change that apt
must not override.  Ditto, removing a key is a perfectly legal
configuration change that apt must not override in its postinst.

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are



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

Bug#558589: libapache2-mod-wsgi: removes conffile on purge

[Tollef Fog Heen]

Package: libapache2-mod-wsgi
Severity: serious

From libapache2-mod-wsgi.postrm:

if [ $1 = purge -o $1 = remove ]; then
# remove pseudo conffile
test -e /etc/apache2/mods-available/wsgi.load  rm -f 
/etc/apache2/mods-available/wsgi.load
fi

Here you are removing the conffile /etc/apache2/mods-available/wsgi.load
on remove, not only on purge.

Also, there is no need to remove conffiles yourself as you do below:

if [ $1 = purge -a -e /etc/apache2/mods-available/wsgi.conf ]; then
# remove conffile
rm -f /etc/apache2/mods-available/wsgi.conf
fi

dpkg does that for you.

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

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

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#540016: ssl-cert: fails to install

[Tollef Fog Heen]

]] sistemas 

severity 540016 normal
thanks

| Fails to install because of not using --force-badname when creating group
| ssl-cert. This is the install log:

What does «grep NAME_REGEX /etc/adduser.conf» return?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#521533: ispell: FTBFS

[Tollef Fog Heen]

Package: ispell
Severity: serious
Version 3.1.20.0-4.4

It seems like textutils is no longer in the archive, maybe you should
go with the trend and update the build-dep to be coreutils?

Automatic build of ispell_3.1.20.0-4.4 on kernite by sbuild/avr32 98
Build started at 20090320-1851
**
Checking available source versions...
Fetching source files...
Reading package lists...
Building dependency tree...
Reading state information...
Need to get 731kB of source archives.
Get:1 http://ftp.uk.debian.org unstable/main ispell 3.1.20.0-4.4 (dsc) [713B]
Get:2 http://ftp.uk.debian.org unstable/main ispell 3.1.20.0-4.4 (tar) [675kB]
Get:3 http://ftp.uk.debian.org unstable/main ispell 3.1.20.0-4.4 (diff) [54.4kB]
Fetched 731kB in 2s (336kB/s)
Download complete and in download only mode
** Using build dependencies supplied by package:
Build-Depends: bison, texinfo, texi2html, debhelper (= 4), wamerican (= 5-2), 
wbritish (= 5-2), libncurses5-dev, textutils, dictionaries-common-dev (= 0.20)
Checking for already installed source dependencies...
bison: missing
texinfo: already installed (4.13a.dfsg.1-1)
texi2html: missing
debhelper: already installed (7.2.6 = 4 is satisfied)
wamerican: missing
wbritish: missing
libncurses5-dev: already installed (5.7+20090228-1~avr32cross)
textutils: missing
dictionaries-common-dev: missing
Checking for source dependency conflicts...
  /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y --force-yes 
install bison texi2html wamerican wbritish textutils dictionaries-common-dev
Reading package lists...
Building dependency tree...
Reading state information...
E: Couldn't find package textutils
apt-get failed.
Package installation failed
Trying to reinstall removed packages:
Trying to uninstall newly installed packages:
Source-dependencies not satisfied; skipping ispell
**
Finished at 20090320-1853
Build needed 00:00:00, 0k disk space

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#502140: RFC: adding pre-depends to libpam-modules for lenny

[Tollef Fog Heen]

]] Steve Langasek 

(Not wearing any particular hat here)

[...]

| Is it ok to make libpam-modules Pre-Depends: debconf (= 0.5) | debconf-2.0
| for lenny?

Yes, I think this sounds reasonable (and your analysis looks good to me).

[...]

| So is it ok to also make libpam-modules Pre-Depends: ${shlibs:Depends} for
| lenny?  For reference, the current shlibs (on i386) are:
| 
|   libc6 (= 2.7-1), libdb4.6, libpam0g (= 0.99.7.1), libselinux1 (= 2.0.59)
| 
| Again, these are all already transitively essential, so the main concern is
| whether further restricting the unpack order will cause any dependency
| loops, which I don't believe it will.

Testing or manually verifying that there are no loops is probably wise,
but otherwise this looks fine too.

| If y'all agree to this change, I can knock out the implementation within a
| couple of days and get another RC bug off the list - then I just have to
| accept the beatings from Christian for the implied addition of a new debconf
| template this late in the lenny freeze... :)

Just send him some cheese and red wine and he'll be happy. :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#489231: reassign

[Tollef Fog Heen]

reassign 489231 ftp.debian.org
retitle 489231 RM: libpam-umask -- RoM: superseded by new libpam-modules
thanks

Hi,

please remove libpam-umask from the archive as it has been superseded
by a module of the same name in libpam-modules.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#482884: severity of 482884 is normal

[Tollef Fog Heen]

# Automatically generated email from bts, devscripts version 
2.10.11ubuntu5.8.04.1
# no justification given
severity 482884 normal




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

Bug#195969: O: libzvt2.0-0 -- The GNOME 2 zvt (zterm) widget

[Tollef Fog Heen]

* Lucas Nussbaum 

| Please note that rcalc and root-portal depend on this package, and will
| break if it is removed. Which action should be taken regarding rcalc and
| root-portal?

I don't think root-portal has many users any more and I don't use it,
so if you'd be so kind as to file a removal bug for that together with
the removal bug for libzvt2.0-0, that'd be good.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#449539: mr: FTBFS

[Tollef Fog Heen]

Package: mr
Severity: serious
Justification: Fails to build from source

Hi,

it seems current mr (both 0.12 and
cf2c132b75dd70c2fdd21768fb9701528272b451) fails to build from source:

 debian/rules build
pod2man -c mr mr  mr.1
(echo []; echo checkout=)  mrconfig.tmp
./mr -c mrconfig.tmp ed | grep -q horse
mr ed: no repositories found to work on
make: *** [build] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

(this is in a sid pbuilder, fwiw)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



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

Bug#407535: python-ldap-doc: no licence in source package

[Tollef Fog Heen]

Package: python-ldap-doc
Severity: serious
Justification: undistributable

Hi,

I am unable to find a reference in the source package for the claim in
debian/copyright that python-ldap-doc is under a Python-style licence.
In fact, I am unable to find any licence information at all, leaving
this package undistributable.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#405360: erlang: contains non-free files

[Tollef Fog Heen]

* Sergei Golovan 

| On 1/3/07, Stephen Gran [EMAIL PROTECTED] wrote:
|  Yes, many do.  It's also not immediately clear to me that this is under
|  a non-free license.  I agree that it could be better worded, but that's
|  not quite the same thing.
| 
| Kenneth Lundin has pointed me (in erlang-questions mailing list) to
| the following document: http://www.ietf.org/ietf/IPR/RSA-MD-all
| 
| It more clearly states that any implementation of the MD2, MD4, and
| MD5 algorithms, derived from the reference C code in RFC-1319,
| RFC-1320, and RFC-1321 may be distrbuted.

No, it states that you may sell implementations derived from the
reference code.  Note that in the second paragraph it says «may be
made, used, and sold», while in the third (where it restricts what you
may do) it says «no right to use, copy, sell, or distribute» which
seems to imply that you're allowed to sell (but not distribute the
code outside of a sale).

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Bug#405295: tuxguitar: files without source in tarball

[Tollef Fog Heen]

Package: tuxguitar
Severity: serious
Justification: undistributable due to missing source for some files

tuxguitar's debian/copyright lists the licence as LGPL.  However, in
the lib/ directory, janel-ant-0.1.jar is shipped with compiled
binaries and no source.

Given that there is no copyright information for the janel-ant-0.1
jar, I believe tuxguitar in its present state is undistributable.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#405360: erlang: contains non-free files

[Tollef Fog Heen]

Package: erlang
Severity: serious
Justification: contains non-free files

lib/erl_interface/src/misc/md5.c in the erlang source package contains 
code where no right is given to distribute derivative works.  See 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340538 for a similar 
bug with some suggested alternative implementations.


- tfheen


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

Bug#405363: openswan: contains non-free files

[Tollef Fog Heen]

Package: openswan
Severity: serious
Justification: contains non-free files

program/pluto/md5.c in the openswan source package contains code where 
no right is given to distribute derivative works.  See 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340538 for a similar 
bug with some suggested alternative implementations.


It looks like md2.[ch] in the same directory has similar licencing problems.

- tfheen



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

Bug#405354: inn2: contains non-free files

[Tollef Fog Heen]

Package: inn2
Severity: serious
Justification: contains non-free files

Hi,

it seems like lib/md5.c (in upstream/tarballs/inn-2.4.3.tar.gz in the 
inn2 source package) contains RSA licenced code which does not include 
the right to distribute derivative works.


See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340538 for a 
similar bug and suggestions on alternate locations to get free md5 
implementations.


- tfheen


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

Bug#400753: squashfs: FTBFS

[Tollef Fog Heen]

Package: squashfs
Severity: serious
Version: 1:3.1r2-4
Justification: FTBFS

Hi,

squashfs seems to use bashisms in its debian/rules, please don't do
this (or use SHELL=/bin/bash in there):

DEB_MAKE_CHECK_TARGET unset, not running checks
DEB_MAKE_INSTALL_TARGET unset, skipping default makefile.mk common-install 
target
dh_installdirs -psquashfs-source
# Create the needed directories
mkdir -p debian/modules/squashfs/debian \
 debian/modules/squashfs/linux-2.6 \
 debian/squashfs-source/usr/src
# Copy the source and header files for 'linux-2.6'
cp linux-2.6/*.{c,h} linux-2.6/Makefile \
debian/modules/squashfs/linux-2.6
cp: cannot stat `linux-2.6/*.{c,h}': No such file or directory
make: *** [install/squashfs-source] Error 1
debuild: fatal error at line 1228:
fakeroot debian/rules binary failed

(my /bin/sh points to dash)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#357227: Reproduced the build failure

[Tollef Fog Heen]

* Lucas Nussbaum 

| I've just reproduced a similar failure, building with sbuild in an etch
| i386 chroot:
| 
| rm munch[123].tmp
| ssed -e 's/stringchar *EE *CE//' -e 's/[EECE]//g' nb.aff.in  nb.aff
| cat forkort.txt munched.B munched.A munched.N munched.M munched.K munched.D 
munc
| hed.O munched.C \
|   | tr -d '\-0-9 ' \
|   | grep \/.*[z\\_\`] \
|comp1.tmp
| make[1]: *** [nb.mch] Error 1
| make[1]: Leaving directory `/build/root/norwegian-2.0.8'
| make: *** [build-stamp] Error 2

Weird.

| I tried to build twice, got the failure each time. However, I also confirm 
than under other conditions (sid chroot, without sbuild), it doesn't fail.
| 
| Full build log: 
http://ox.blop.info/bazaar/buildlogs/20061024/norwegian_2.0.8-2.log.gz

Could you provide a copy of the build tree, please?

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#357227: Reproduced the build failure

[Tollef Fog Heen]

* Lucas Nussbaum 

|  Could you provide a copy of the build tree, please?
| 
| By build tree, do you mean an archive of the directory where the package
| was tentatively build, or an archive of the entire chroot ?

The former should be enough, thanks.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#391917: this is a Debian menu subpolicy violation

[Tollef Fog Heen]

* Bill Allombert 

| Tollef, I plan to NMU this package next week if this bug is not fixed
| before.

No need, I've just been busy with other real-world stuff, but will
hopefully catch up with this over the weekend.

(Technically, this bug is only normal (or maybe important), given that
the wording in policy is that «Menu entries should follow the current
menu policy.», not «must follow the current menu policy», but I don't
really care. :-)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Bug#392565: apache bug, really

[Tollef Fog Heen]

This is really an apache bug.  2.2.3-3 will have a fix for the
problem.  (The fix is checked in, but I would like to run a few tests
before uploading.)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#394658: doesn't depend on correct versions

[Tollef Fog Heen]

severity 394658 wishlist
tags 394658 + wontfix
kthxbye

* Jayen Ashar 

| I think there is a need for an exact dependency.  I upgraded from
| apache2 2.0.55-4.1 to apache2 2.2.3-2 and it didn't do anything.
| Nothing REAL got upgraded.  My copy of apache2-mpm-prefork stayed at
| version 2.0.55-4.1.

Yes, and?  This isn't a bug, there is nothing in apache2's description
which says «this ensures you have the latest version of all apache2
packages installed», and there shouldn't either.  Dependencies should
be as loose as possible, but no looser.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Bug#394714: apache2-mpm-prefork: Apache2 child processes segfaults

[Tollef Fog Heen]

* David Muriel 

| I just upgraded apache2 from version 2.0 to 2.2 and now apache2 no
| longer starts.  The file /var/log/apache2/error.log just shows this:

This is probably a bug in some module.  What modules do you have
enabled?  Can you get a sensible backtrace from gdb --args apache2 -X ?

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#392646: apache2.2-common: doesn't start, child processes segfault

[Tollef Fog Heen]

forcemerge 392049 392646
thanks

John Fry skrev:

Since I upgraded to apache2 on unstable, apache fails to start after 
trying to spawn a bunch of child processes.  Here's a snippet from 
/var/log/apache2/error.log:


Known bug in apr; it doesn't work correctly with 2.4 kernels.

- tfheen


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

Bug#391864: Removing apache2-common fails: API module structure `actions_module' in file /usr/lib/apache2/modules/mod_actions.so is garbled - perhaps this is not an Apache module DSO?

[Tollef Fog Heen]

Olaf van der Spek skrev:

Hi,

I'm still getting the DSO error although the bug is supposed to be fixed.

Is there something trivial I missed (again)?


Your system is in a wedged state that apache can't get you out of.  Just 
chmod -x /usr/sbin/apache2 and the upgrade should work fine.


- tfheen


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

Bug#390819: Apache2.2 upgrade makes apache2-common --remove fail

[Tollef Fog Heen]

* Madko 

| now that apache2 has been upgraded successfully to apache2.2, web server
| cannot be started anymore:

Correct, this is a bug in the PHP package.  It doesn't depend on the
proper ABI and a bug for this has been filed already.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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