Bug#1022149: ktimetracker total data loss
This looks of it could be the same issue as bug 1021938, which is due to a regression in libical version 3.0.15. -- David Jarvie KAlarm author, KDE developer
Bug#968281: I cannot export alarms in Kalarm
This bug description looks like https://bugs.kde.org/show_bug.cgi?id=374337. This was fixed in KDE Applications 16.12.1. (The version you are reporting about is an earlier version, 16.04.3.) -- David Jarvie. KDE developer, KAlarm author.
Bug#671619: Bug has been fixed upstream
This bug has already been fixed upstream (see https://bugs.kde.org/show_bug.cgi?id=271580). The fix was done after KDE 4.4.11 was released, so it is unlikely to be released as a new kdepim version. The latest kdepim/kalarm 4.4 branch sources should be obtained from git to get the fix (or get the git commit mentioned in the KDE bug report). -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Bug#367935: checkinstall's temporary script is deleted by installwatch and installation therefore fails
The bug has occurred again. I built Qt 4 (downloaded from KDE's SVN qt-copy), and then tried to install it with this command: checkinstall --pkgname=qt4x make install_qmake install_mkspecs sub-src-install_subtargets sub-tools-install_subtargets install_htmldocs It's a pretty big package to install, but it happens to produce the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367935: checkinstall's temporary script is deleted by installwatch and installation therefore fails
On Wednesday 07 June 2006 06:42, Felipe Sateler wrote: What is the install command you are using? Can you easily reproduce this bug? I tried reinstalling checkinstall-1.5.3-3, and now it seems to work without my patch. It previously failed consistently for a period of weeks, and I have no idea why it now works when previously it didn't (unless either there is something in the rand calls which is time sensitive, or another library has changed). It used to fail even with a simple test script containing something like mkdir -p /var/tmp/abcde. However, I still think that my patch (or something else with a similar effect) is a sensible precaution, since it eliminates any possibility that checkinstall and installwatch can use the same temporary directory, and therefore prevents the problem I described. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367935: checkinstall's temporary script is deleted by installwatch and installation therefore fails
Package: checkinstall
Version: 1.5.3-3
Severity: grave
Tags: patch
Justification: renders package unusable
Checkinstall creates a script in a temporary directory for execution
by installwatch. Installwatch also uses a temporary directory, which
it removes if it already exists. Checkinstall and installwatch both
use the same algorithm to create a temporary directory name, with the
result that they both use the same temporary directory, so that
installwatch deletes the directory containing checkinstall's script.
There is then nothing for installwatch to execute, resulting in a
failure message:
/usr/bin/installwatch: line 345:
/var/tmp/KIKjLRhMLrIpmlArapqN/installscript.sh: No such file or directory
This can be fixed with certainty by making the temporary directory names
used by checkinstall and installwatch different lengths, as in the
following patch.
=
--- /usr/bin/checkinstall 2004-04-12 13:58:38.0 +0100
+++ checkinstall2006-05-18 19:08:37.0 +0100
@@ -656,7 +656,7 @@
# Find a safe TMP_DIR
-TMP_DIR=${BASE_TMP_DIR}/`awk 'BEGIN { srand(); for (i=1;i21;i++) { a=95;
while (a 90 a 97) { a=65+int(50*rand())}; printf(%c, a) } }'`
+TMP_DIR=${BASE_TMP_DIR}/`awk 'BEGIN { srand(); for (i=1;i22;i++) { a=95;
while (a 90 a 97) { a=65+int(50*rand())}; printf(%c, a) } }'`
[ -e $TMP_DIR ] rm -rf $TMP_DIR
if [ -e $TMP_DIR ]; then
echo
=
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages checkinstall depends on:
ii file4.17-1 Determines file type using magic
ii installwatch0.7.0beta4-1 Track installation of local softwa
checkinstall recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367077: installwatch: Segmentation faults on mkdir, cp
Package: installwatch Version: 0.6.3-2 Severity: grave Justification: renders package unusable Whenever I run checkinstall, I get a segmentation fault when it invokes installwatch. It used to work until around 2 - 4 weeks ago. This fault renders checkinstall useless. The output on the console is, for example: Copying documentation directory... /var/tmp/pBcFXBogLSoZdCkGjJOn/installscript.sh: line 14: 22439 Segmentation fault mkdir -p /usr/share/doc/qt41 The fault occurs even if the directory being created by mkdir already exists. I tried creating a little script and manually running installwatch. The commands 'mkdir' and 'cp' both fail with a segmentation fault, whereas 'echo' doesn't. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages installwatch depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries installwatch recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361270: Upgrade of initramfs-tools made kernel unbootable with lilo
Package: initramfs-tools Version: 0.59b Severity: critical Justification: breaks the whole system Upgrading initramfs-tools yesterday caused the current kernel 2.6.15-1 to become unbootable, apparently because the upgrade process regenerated initrd.img-2.6.15-1-k7. The upgrade process should have warned me to rerun lilo. Note that I normally use kernel 2.6.15-1-k7, rather than 2.6.12 listed below, but due to 2.6.15 being unbootable I had to boot into 2.6.12. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-4 Tiny utilities for small and embed ii cpio 2.6-11 GNU cpio -- a program to manage ar ii klibc-utils 1.2.4-1small statically-linked utilities ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii udev 0.088-2/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361270: Upgrade of initramfs-tools made kernel unbootable with lilo
On Friday 07 April 2006 21:44, maximilian attems wrote: kernel-package wants to drop ability to run lilo on the postinstall. grub is the _default_. update-initramfs can easily check for an lilo.conf and warn in those cases. A warning (preferably in the form of a prompt which must be acknowledged) would be fine as far as I'm concerned. I've never been entirely happy about kernel-package offering to replace the MBR or run lilo directly, since my MBR is not written by either lilo or grub. Regards, David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351623: Fix doesn't work for me
I had the same problem since the latest kernel update. I did a 'reiserfsck --clean-attributes' and changed /etc/fstab to add 'noattrs' options, but on at least one reiserfs partition, I'm still getting lots of the same errors. That partition is reiser v3.5 format, while my other reiserfs partitions are v3.6. I haven't yet noticed any problems on the v3.6 partitions, although I didn't get very many before, so they may yet happen. Downgrade to 2.6.12 kernel seems the only answer for now. -- David Jarvie. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
