Bug#792307: closed by Brian Potkin <claremont...@gmail.com> (Re: Bug#863974: hplip should not require systemd)

[Christian Mueller]

Correct, sorry, I've been running without any systemd components for 
such a long time that I forgot the details. Either way, systemd 
components are currently pulled in and activated (logind-systemd).


I don't have a good example for Linux off the top of my head because 
I've removed systemd a long time ago but maybe an example from OS X 
(which seems to be the origin of quite a few concepts introduced with 
systemd) explains my general problem: the socket used for X11 is stored 
in a private tmp diretory which can't be accessed by other users, thus I 
can't su to another login and still use X11 programs. That's what breaks 
my workflow - I usually have two or three different logins active on the 
same desktop and private tmp directories break things for me sooner or 
later. Of course I can set up a shared directory accessible by all users 
but that's not the point. Plus the ever-growing list of tmpfs mount 
points is really getting to me.


I know that ConsoleKit is no longer maintained but that's what I'm using 
right now because it's set up as a dependency. Maybe it would be 
possible to ditch all dependencies to "fast user switching" without 
systemd and go back to the old way of things where ownership of console 
devices is set to whoever logs into a local console when no other 
console is active. This way, folks who don't want Linux turned into 
something resembling Windows or OS X can work the way they're used to 
and all others can have systemd and all the things that come with it...


Like I said, I'm more than happy to provide a patch for policykit that 
does all that dynamically, i.e. doesn't need hard dependencies to 
systemd but uses it when present, dynamically loading the systemd libs. 
But if there's no interest it would be a waste of time. I'd also be 
willing to step up as maintainer for ConsolKit if that helps. Or both.


On 06/04/2017 11:05 AM, Simon McVittie wrote:

On Sat, 03 Jun 2017 at 22:50:58 +0200, Christian Mueller wrote:

(separate temp mount points for
each user) which, apart from the incredible clutter in the list of mounted
file systems, breaks my workflows (I need a single /tmp for all users).

systemd-logind mounts a small tmpfs at /run/user/$uid for each concurrent
user, as its way to implement XDG_RUNTIME_DIR without letting users cause
denial of service by filling up /run. /tmp remains visible to all users.


Just having a version of policykit-1 compiled without systemd
dependencies would solve all our issues and it's a tiny little change in the
rules file.

The change is tiny, but the support burden is not.

To be able to implement the policies that it provides, polkit needs a
way to determine which users are logged-in, which of those logged-in
users are local (getty, xdm etc. but not ssh), and which of those local
users are on the active VT. Historically, that was implemented by
ConsoleKit, which no longer has upstream maintainers[1], and does not
appear to have Debian maintainers either. On Linux systems (with
either systemd, sysvinit + systemd-shim or Upstart + systemd-shim)
the replacement is systemd-logind.

 S

[1] https://www.freedesktop.org/wiki/Software/ConsoleKit/

Bug#792307: closed by Brian Potkin <claremont...@gmail.com> (Re: Bug#863974: hplip should not require systemd)

[Christian Mueller]

Hi Brian,

I just realized that my bug report, #792307, got merged with #863974 
which may have the same underlying cause but a different interpretation 
of the results. Yes, just installing the systemd binary won't enable it 
as the active init system but another part of the dependency chain, 
libpam-systemd, already imports some of the systemd patterns (separate 
temp mount points for each user) which, apart from the incredible 
clutter in the list of mounted file systems, breaks my workflows (I need 
a single /tmp for all users).


Debian always maintained that systemd would be optional and I would hope 
for a little more flexibility when it comes to [reasonable] requests to 
allow setting up desktop systems without having systemd bits and pieces 
getting in the way. Just having a version of policykit-1 compiled 
without systemd dependencies would solve all our issues and it's a tiny 
little change in the rules file. We would simply have two alternatives 
for policykit-1, one with and one without systemd. Or dynamic support at 
runtime. If there's anything I can do to help getting this implemented, 
especially the runtime detection, please let me know - I'm more than 
happy to put this together but only if I this is not a lost cause 
because nobody is interested in accepting this as a patch, anyway.


Thanks,
--Christian

On 06/03/2017 09:57 PM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the policykit-1 package:

#792307: policykit-1: There should be a variant of policykit-1 which doesn't 
depend on systemd

It has been closed by Brian Potkin .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Brian Potkin 
 by
replying to this email.

Bug#834732: dkms compiler erro

[Christian Mueller]

For the sake of completeness, here's the dkms compiler error with kernel 
3.16.7:


...
  CC [M]  /var/lib/dkms/fglrx/15.12/build/firegl_public.o
/var/lib/dkms/fglrx/15.12/build/firegl_public.c: In function 
‘KCL_LockUserPages’:
/var/lib/dkms/fglrx/15.12/build/firegl_public.c:3231:5: error: implicit 
declaration of function ‘get_user_pages_remote’ 
[-Werror=implicit-function-declaration]
 ret = get_user_pages_remote(current, current->mm, vaddr, page_cnt, 
1, 0, (struct page **)page_list, NULL);

 ^
...

Bug#712841: A bit late, but still an issue...

[Christian Mueller]

That would be great. You mean customise.conf, correct? Anything I can do 
to help?


Thanks,
--Christian

P.S.: Thanks for all the effort you put into this - I'm using Debian on 
ARM devices for my mail/DNS/VPN/... server(s) since the old NSLU2 days 
and it all started on on cyrius.com :)


On 05/05/2016 10:59 PM, Martin Michlmayr wrote:

* Christian Mueller <ch...@mumac.de> [2016-04-29 22:20]:

Long story cut short: if there is a way to identify TS-119 vs. TS-219
hardware, a fix would be very welcome.

There's a configuration file on /dev/mtdblock5 which contains the
device type.  I'm starting to think the easiest solution would be to
mount that device, check the device type and configure qcontrol
accordingly.

Bug#712841: A bit late, but still an issue...

[Christian Mueller]

Hi all,

I've just upgraded my trusty and apparently indestructable TS-119 to 
Jessie and stumbled over this bug. I've simply commented-out the line 
that increases the fan error count and the beeping has stopped but I see 
log entries which show qcontrol trying to set fan speeds due to 
temperature measurements.


Long story cut short: if there is a way to identify TS-119 vs. TS-219 
hardware, a fix would be very welcome. If not, I guess an option in 
/etc/default/qcontrol to simply disable any kind of thermal management 
involving fans would be nice, too (overtemp handling excluded, of course)


Thanks,
--Christian

Bug#794420: Test file

[Christian Mueller]

I tried to send the test file as base64-encoded email yesterday (71KB, 
around 16 A4 pages when printed) but it never showed up in the bug 
report; I guess it might have been too large. Do you have any other 
means to upload test files?



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

Bug#794420: ghostscript: ps2pdf13 produces incomplete files with PS files generated by Windows printer drivers

[Christian Mueller]

Package: ghostscript
Version: 9.06~dfsg-2+deb8u1
Severity: important

When setting up a Windows client to print through my main Debian box, I noticed
that the test page came out incomplete - only the logo and one letter was
printed.

I tracked this down to CUPS using compatibility version 1.3 when converting the
PS file to a PDF file (/usr/lib/cups/filters/pstopdf). This can be reproduced
using ps2pdf13 and ps2pdf12 with the file I indent to attach to this bug report
(hoping that I can attach files).

I've changed the CUPS filter to use PDF compatibility version 1.2 and can now
print from Windows - this might be an acceptable workaround until the underlying
cause has been fixed but this is, of course, a different package. I'm still
submitting this bug to ghostscript because this is where I believe it's
ultimately located.

The importance of this defect is, I believe, relatively high because it appears
toprevent any Windows client from printing anything on a Debian 8.1 server, at
least in situations as mine whether the printer doesn't speak Postscript and
CUPS needs to handle the input file.

Please stand by for the example file (the printer test page from Windows).

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

Kernel: Linux 3.16.7-ckt11-amd64-cm1.5 (SMP w/6 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ghostscript depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  gsfonts1:8.11+urwcyr1.0.7~pre44-4.2
ii  libc6  2.19-18
ii  libgs9 9.06~dfsg-2+deb8u1

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.06~dfsg-2+deb8u1

-- no debconf information


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

Bug#792307: policykit-1: There should be a variant of policykit-1 which doesn't depend on systemd

[Christian Mueller]

Package: policykit-1
Version: 0.105-8
Severity: normal

Policykit has been around for a while and many packages required it long before
systemd appeared on the scene (in my case, blueman, lightdm-gtk-greeter, colord,
hplip to name a few). It's companion, ConsoleKit, now comes in two flavors,
one being systemd-logind, the other the original ConsoleKit, and the 
dependencies
across the Debian packages have been set up to depend on either one of them.

What I'm proposing is to use a similar solution for policyit. For example, there
could be two packages: systemd-policykit-1 and policykit-1, the former one
compiled with --enable-systemd, the latter compiled with --disable-systemd. Or,
since we're talking about a release already out, the packages could be named
policykit-1 (with systemd) and policykit-1-nosystemd (without systemd). Or
something around those lines - you get the picture :)

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

Kernel: Linux 3.16.7-ckt11-amd64-cm1.4 (SMP w/6 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages policykit-1 depends on:
ii  dbus   1.8.18-0+deb8u1
ii  libc6  2.19-18
ii  libglib2.0-0   2.42.1-1
ii  libpam0g   1.1.8-3.1
ii  libpolkit-agent-1-00.105-8
ii  libpolkit-backend-1-0  0.105-8
ii  libpolkit-gobject-1-0  0.105-8

policykit-1 recommends no packages.

policykit-1 suggests no packages.

-- no debconf information


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

Bug#640729: netbase: /etc/sysctl.d/bindv6only.conf should not be the default

[Christian Mueller]

Package: netbase
Version: 4.45
Severity: important
Tags: ipv6


I've just discovered that netbase now sets the system parameter bindv6only. 
This seems completely wrong to me, especially in the light that acceptance
for IPv6 is still very low simply because there's next to no
interoperability with IPv4.  Luckily, at least servers can listen for IPv4
and IPv6 connections with a single socket, using :::x.x.x.x addresses
for IPv4 clients.  I've been busy changing my own code (tons of stuff) to do
just that (i.e. listen to a single IPv6 socket which will also accept IPv4
connections) and now I find out that this is disabled per default in
Debian...!

The comment in /etc/sysctl.d/bindv6only says:

# This is the default behaviour of almost all modern operating systems.

This is the first time I hear about this. All boxes I'm dealing with (SunOS,
HP-UX, AIX, various Linux distributions) have this questionable feature
disabled and will accept IPv4 connections on an IPv6 socket.  The only
operating system I know of that doesn't (didn't?) have a dual mode IP stack
is Windows ;)


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

Kernel: Linux 2.6.32-cm1.7-686 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages netbase depends on:
ii  initscripts 2.88dsf-13.1 scripts for initializing and shutt
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip

Versions of packages netbase recommends:
ii  ifupdown  0.6.10 high level tools to configure netw

netbase suggests no packages.

-- no debconf information



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

Bug#639779: netbase: /etc/sysctl.d/bindv6only.conf should not be the default

[Christian Mueller]

Package: netbase
Version: 4.45
Severity: important
Tags: ipv6


I've just discovered that netbase now sets the system parameter 
bindv6only. This seems completely wrong to me, especially in the light 
that acceptance for IPv6 is still very low simply because there's next 
to no interoperability with IPv4.  Luckily, at least servers can listen 
for IPv4 and IPv6 connections with a single socket, using :::x.x.x.x 
addresses for IPv4 clients.  I've been busy changing my own code (tons 
of stuff) to do just that (i.e. listen to a single IPv6 socket which 
will also accept IPv4 connections) and now I find out that this is 
disabled per default in Debian...!


The comment in /etc/sysctl.d/bindv6only says:

# This is the default behaviour of almost all modern operating systems.

This is the first time I hear about this. All boxes I'm dealing with 
(SunOS, HP-UX, AIX, various Linux distributions) have this questionable 
feature disabled and will accept IPv4 connections on an IPv6 socket. The 
only operating system I know of that doesn't (didn't?) have a dual mode 
IP stack is Windows ;)



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

Kernel: Linux 2.6.32-cm1.7-686 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages netbase depends on:
ii  initscripts 2.88dsf-13.1 scripts for initializing 
and shutt
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 
init scrip


Versions of packages netbase recommends:
ii  ifupdown  0.6.10 high level tools to 
configure netw


netbase suggests no packages.

-- no debconf information



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

Bug#585786: New dependencies pull in mdadm and mdsetup even when not needed

[Christian Mueller]

Since xfce depends on eject and eject depends on libdevmapper, the fix 
to 585786 causes mdadm and mdsetup to be installed when I try to update 
my Squeeze box. However, I don't use RAIDs or LVM and would rather not 
have the corresponding tools installed. This may not be very important 
but it's a nuisance...


Wouldn't it be better to have mdadm and mdsetup depend on a specific 
version of libdevmapper? Or is this an issue with eject depending on 
libdevmapper?


Thanks,
--Christian



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

Bug#570283: Some more information...

[Christian Mueller]

Since the gcc version used to compile dash might have an impact, here's 
the version I'm currently using. If you need more information (like a 
complete list of all packages), please let me know. Regarding the 
kernel: It's a stock Debian kernel source with one file patched to 
initialize the eSATA controller in the SheevaPlug 
(arch/arm/mach-kirkwood/sheevaplug-setup.c)


$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-9' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --enable-multiarch --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-objc-gc --disable-sjlj-exceptions 
--enable-checking=release --build=arm-linux-gnueabi 
--host=arm-linux-gnueabi --target=arm-linux-gnueabi

Thread model: posix
gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9)

Another idea: If you could provide debug symbols for the dash build 
coming with Debian Sequeeze I could debug the original binary.






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

Bug#570283: runaway memory leak when processing DBOX2 CDK configure scripts

[Christian Mueller]

Package: dash
Version: 0.5.5.1-3
Severity: important

Hi all,

this is a bit of a weird problem. I tried to compile a DBOX2 (tuxbox)
image on a SheevaPlug and found dash would eat up all memory while running
certain configure scripts. In order to find out what's going on, I compiled
dash with

  - apt-get source dash
  - cd dash-0.5.5.1
  - dkpg-buildpackage -rfakeroot -nc

and link the resulting binary to /bin/dash for debugging purposes. However,
the problem did not occur with the binary compiled this way, with or without
debugging information (DEB_BUILD_OPTIONS set ot unset)

In order to reproduce the problem, a rather lengthy procedure is required
(on a SheevaPlug with Debian Sequeeze and development tools):

 # useradd dbox
 # su - dbox
 $ mkdir prj; cd prj
 $ mkdir tuxbox; cd tuxbox
 $ for i in apps boot driver hostapps cdk; do
 git clone git://gitorious.org/~seife/tuxbox-cvs/$i.git
   done
 $ cd cdk
 $ ./autogen.sh
 $ ./configure --with-cvsdir=/home/dbox/tuxbox \
   --prefix=/home/dbox/tuxbox/dbox2 \
   --with-boxtype=dbox2 \
   --with-checkImage=rename \
   --enable-fx2-c64emu \
   --enable-fx2-lemm \
   --enable-fx2-mines \
   --enable-fx2-sudoku \
   --enable-fx2-yahtzee \
   --enable-fx2-solitair \
   --enable-fx2-satfind \
   --enable-dvbsnoop \
   --with-procps
 $ make yadd-neutrino

This may work fine (I remember seeing an OOM in dmesg but it was somewhere
in the middle of the build and hard to evaluate so I rebuilt with /bin/sh
pointing to /bin/bash.)

It will take around 1-2 hours to bootstrap the cross-build environment and
compile the base installation.

The next step, however, seems easier to reproduce:

 $ ulimit -v 786432
 $ make extra

 ( rm -rf ncftp-3.2.2 || /bin/true )  bunzip2 -cd
 /home/dbox/prj/tuxbox/cdk/Archive/ncftp-3.2.2-src.tar.bz2 | TAPE=- tar -x 
 / ((for f1 in config.guess config.sub; do (for f2 in `find ncftp-3.2.2 -name
 / $f1`; do (test -e $f2  rm -f $f2  ln -s
 / /home/dbox/prj/tuxbox/cdk/Patches/$f1 $f2  echo updated $f2) done)
 / / done) || /bin/true)
 updated ncftp-3.2.2/sh/config.guess
 updated ncftp-3.2.2/sh/config.sub
 cd ncftp-3.2.2  \
 AR=powerpc-tuxbox-linux-gnu-ar
 AS=powerpc-tuxbox-linux-gnu-as CC=powerpc-tuxbox-linux-gnu-gcc
 CXX=powerpc-tuxbox-linux-gnu-g++ NM=powerpc-tuxbox-linux-gnu-nm
 RANLIB=powerpc-tuxbox-linux-gnu-ranlib STRIP=powerpc-tuxbox-linux-gnu-strip
 CFLAGS=-pipe -Os CXXFLAGS=-pipe -Os LDFLAGS=-Wl,-O1
 PKG_CONFIG_PATH=/home/dbox/prj/tuxbox/dbox2/cdkroot/lib/pkgconfig \
 ./configure \
 --build=armv5tel-unknown-linux-gnueabi \
 --host=powerpc-tuxbox-linux-gnu \
 --prefix=  \
 make clean all LD=powerpc-tuxbox-linux-gnu-ld  \
 make install DESTDIR=/home/dbox/prj/tuxbox/dbox2/cdkroot
 creating cache ./config.cache
 checking if you set and exported the environment variable CC...
 powerpc-tuxbox-linux-gnu-gcc
 checking for environment variable CFLAGS... -pipe -Os
 checking for environment variable CPPFLAGS... no
 checking for environment variable LDFLAGS... -Wl,-O1
 checking for environment variable LIBS... no
 checking version of C library... Segmentation fault
 ^C

This is where dash used up all of the memory and ended up with a SEGV
because I set ulimit -v 786432.

As mentioned above, trying to compile dash on the SheevaPlug resulted in a
binary that did not show this particular behavior. Might be an issue with
the gcc version used to compile the packages, or a cross-compile issue...


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

Kernel: Linux 2.6.32-cm1.0-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dash depends on:
ii  debianutils   3.2.2  Miscellaneous utilities specific t
ii  dpkg  1.15.5.6   Debian package management system
ii  libc6 2.10.2-2   GNU C Library: Shared libraries

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true



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

Bug#347720: Correction for description of the effects of this bug

[Christian Mueller]

I mixed two things up when I was submitting this bug. The effect of this
bug is *not* that the module load order changes but that too many
modules get loaded.

The problem I had with this, apart from having a bloated initrd image,
was that the USB driver on the affected box was causing severe hardware
problems, blocking interrupts for other PCI cards, and the image created
by mkinitrd would always load the USB driver module at boot time
regardless of what I put into /etc/mkinitrd/mkinitrd.conf

With the suggested fix, only those modules which are really needed at
boot time are loaded. Here's a comparison of the modules loaded with and
without the fix:

With the fix:
-

modprobe -k  piix
modprobe -k  pdc202xx_new
modprobe -k  vesafb  /dev/null 21
modprobe -k  fbcon 2 /dev/null
modprobe -k  unix 2 /dev/null
modprobe -k  megaraid
modprobe -k  aic7xxx
modprobe -k  sd_mod

Without the fix:


modprobe -k  piix
modprobe -k  pdc202xx_new
modprobe -k  vesafb  /dev/null 21
modprobe -k  fbcon 2 /dev/null
modprobe -k  unix 2 /dev/null
modprobe -k  megaraid
modprobe -k  aic7xxx
modprobe -k  vesafb
modprobe -k  font
modprobe -k  sd_mod
modprobe -k  ide-cd
modprobe -k  ide-disk
modprobe -k  ide-generic
modprobe -k  psmouse
modprobe -k  evdev
modprobe -k  mousedev
modprobe -k  tsdev
modprobe -k  raid0
modprobe -k  e100
modprobe -k  3c59x
modprobe -k  pci_hotplug
modprobe -k  ehci-hcd# -- one of those caused
modprobe -k  ohci-hcd# -- hardware problems
modprobe -k  rtc
modprobe -k  pcspkr
modprobe -k  parport_pc
modprobe -k  floppy
modprobe -k  lp




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

Bug#278028: The problem is reproduceable

[Christian Mueller]

Hello, 

I was able to reproduce this problem using the 
non-server variant, version 1.8.7-3, 
on my Debian Sarge system. 

I get only the first appointment as popup and as email, 
and no notification of the second one at all. 


Best regards, 
Christian Müller.