Bug#720891: cpm: fails to start on i386
On 02/04/2014 06:27 PM, Kacper Wysocki wrote: Does the problem still occur with git master branch tip revision? I'm afraid so. I just tried again against 9cc7f9757f140f10999bb364bbca3fcc5a46 on a Debian i386 jessie system, and I got the same results: windlord:~/tmp/cpm ./cpm Cannot drop root privileges. (695) Dang it. I'll try in a jessie i386 vm and get back to you. I simply cannot reproduce this. We might have fixed it at some point between 0.28 and 0.31? CPM runs as expected on 32-bit jessie: == user@jessi386:~$ cpm --version cpm 0.31 (32 bit) CDK version 5.0 (20060507). GpgME version 1.4.3 (rcpt). ncursesw version 5.9 (20140118). XML2 version 2.9.1. zlib version 1.2.8. cracklib is enabled. Written by Harry Brueckner harr...@mm.st 2005-2009. Maintained by Kacper Wysocki k...@redpill-linpro.com 2010. user@jessi386:~$ cpm Running without root privileges: yes Memory protection from core dumps:yes Memory protection from swap writings: no Max. memory lock ok: no (64 kB) Memory protection from ptrace spying: yes Validation of environment variables: yes Cracklib dictionary (/var/cache/cracklib/cracklib_dict):yes Maximum security level not reached. Your database will be less protected while CPM is running. Are you sure you want to continue? signature.asc Description: OpenPGP digital signature
Bug#720891: cpm: fails to start on i386
Does the problem still occur with git master branch tip revision? I'm afraid so. I just tried again against 9cc7f9757f140f10999bb364bbca3fcc5a46 on a Debian i386 jessie system, and I got the same results: windlord:~/tmp/cpm ./cpm Cannot drop root privileges. (695) Dang it. I'll try in a jessie i386 vm and get back to you. -- Kacper Wysocki / Security^Infrastructure Systems Consultant Certs: RHCE ZANESA SFCSC My-ADBA V3A Telephone +47 21 54 41 86 / Mobile +47 943 94 126 Redpill Linpro - Changing the Game signature.asc Description: OpenPGP digital signature
Bug#734312: src:cpm: cpm FTBFS on SPARC and SPARC64 do to undefined PT_SYSCALL
On 01/05/2014 09:27 PM, Paul Gevers wrote: Package: src:cpm Version: 0.28-1 Severity: serious Tags: upstream patch Justification: fails to build from source (but built successfully in the past) cpm fails to build from source [1] on SPARC and SPARC64 do to upstream commit 2ba8958a7c. As that commit was needed to build on kFreeBSD, my guess is that a check should be implemented to see if PT_SYSCALL is defined and if not use PTRACE_SYSCALL. Be aware, I have no idea what I am doing code-wise here, but the package builds on SPARC (porterbox) with the attached patch applied. Hi Paul, thanks for reporting this, and posting a patch. I have now applied (a modified version of) the patch as commit 0497c49b3f. If the fix builds cleanly on kFreeBSD and SPARC/SPARC64 then it will go into release 0.29. Regards, Kacper signature.asc Description: OpenPGP digital signature
Bug#720891: cpm: fails to start on i386
On 08/27/2013 06:34 AM, Russ Allbery wrote: The patch makes the warning about the kernel version go away, but cpm still won't start. It just exits after reporting the error: Cannot drop root privileges. (689) This is running cpm out of the build tree after compiling it as a regular user (with that patch). Having tried this in a i386 chroot I have found nothing amiss. I'll try on a i386/jessie machine I might have somewhere. Does the problem still occur with git master branch tip revision? cheers, -Kacper signature.asc Description: OpenPGP digital signature
Bug#720892: cpm: initial curses screen setup not correct
However, now that you mention it it might be worth doing for the next release of CPM. I've inserted a call to clear the screen as of today's git. This will make its way to debian soon. 0K -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721484: cpm: does not support de_DE.UTF-8
On 09/01/2013 10:41 AM, Dominik George wrote: Package: cpm Version: 0.28-1 Severity: normal Tags: l10n cpm with German localization does not work properly on de_DE.UTF-8 (umlauts are rendered as other characters). Hi, this is a bug in CDK and we are in the middle of a giant rewrite to end our dependency on CDK. To work around this, use the german iso codepages or file a bug on CDK. Thanks, Kacper signature.asc Description: OpenPGP digital signature
Bug#720892: cpm: initial curses screen setup not correct
On 08/26/2013 05:17 AM, Russ Allbery wrote: Package: cpm Version: 0.28-1 Severity: normal When cpm first starts and initializes its curses interface, it doesn't correctly clear the screen, so the current contents of the screen are still displayed with only the pieces that are part of cpm's menu and interface structure overwritten. This is with a simple xterm (package xterm) as the terminal. Ok. This is really a CDK issue. We already force a redraw after certain actions (a window resize amongst other things) and I was hoping not to touch it before throwing out CDK altogether. However, now that you mention it it might be worth doing for the next release of CPM. 0K signature.asc Description: OpenPGP digital signature
Bug#720891: cpm: fails to start on i386
On 08/27/2013 06:34 AM, Russ Allbery wrote: Kacper Wysocki k...@redpill-linpro.com writes: Although this is a priority, it should not break all i386 systems. Please try out the following patch and see if it fixes the issue: The patch makes the warning about the kernel version go away, but cpm still won't start. It just exits after reporting the error: Cannot drop root privileges. (689) This is running cpm out of the build tree after compiling it as a regular user (with that patch). Interesting, I will have to reproduce this here because this is certainly not what I expect to happen after the privilege check. 0K signature.asc Description: OpenPGP digital signature
Bug#720891: cpm: fails to start on i386
Severity: normal
On 08/26/2013 04:52 AM, Russ Allbery wrote:
Package: cpm
Version: 0.28-1
Severity: grave
Justification: renders package unusable
cpm 0.28-1 fails to start at all on i386 systems. No matter how it
is run, it just produces the errors:
Failed to scan kernel release. (Success, 0)
Cannot drop root privileges. (684)
It does work on amd64. I also tried 0.26-1, but it has the same
problem.
Actually, it's not the architecture, but your kernel release which is
the likely cause for this failure.
This is upstream https://github.com/comotion/cpm/issues/35
Although this is a priority, it should not break all i386 systems.
Please try out the following patch and see if it fixes the issue:
diff --git a/security.c b/security.c
index 4735636..52479b7 100644
--- a/security.c
+++ b/security.c
@@ -454,9 +454,14 @@ int check_kernel_version()
}else if(!strncmp(uts.sysname, Linux, 5)){
int maj,min,rel;
if(sscanf(uts.release, %d.%d.%d, maj, min, rel) != 3) {
- fprintf(stderr, %s (%s, %d)\n,
- _(Failed to scan kernel release.),
- strerror(errno),errno);
+ // maybe it's a 3.10-rc3 release.
+ if(sscanf(uts.release, %d.%d, maj, min) != 2) {
+ fprintf(stderr, %s (%s, %d)\n,
+ _(Failed to scan kernel release.),
+ strerror(errno),errno);
+ return 0;
+ }
+ rel = 9; // instead of passing garbage
}else{
//fprintf(stdout, kernel rel: %d.%d\n, maj, min);
if(maj 2 ||
signature.asc
Description: OpenPGP digital signature
Bug#643989: cpm doesn't honor LC_ALL
On 10/01/2011 03:04 PM, Jörg Sommer wrote: the environment variable LC_ALL should override the setting of the LANG variable, but cpm doesn't behave so. % env -i HOME=$HOME LANG=de_DE.UTF-8 LC_ALL=C /usr/bin/cpm Ausführung ohne Root Privilegien:ja Hello, I have now had a chance to look at your issue. This bug relates to the interaction between gettext and CPM's security functions which clear the environment. These functions clear the LC_ALL env (and indeed all vars except for a small whitelist) before initializing gettext, causing the misfeature you are seeing. Although I am not aware of any security implications of moving the gettext call before the security call, I am still reluctant to do so, therefore I have added code to copy the LC_ALL and LC_MESSAGES variables to the clean environment. This code will be included in the next release of CPM and should solve this bug. Regards, Kacper signature.asc Description: OpenPGP digital signature
Bug#643988: broken string length calculation for multibytes
On 10/01/2011 03:11 PM, Jörg Sommer wrote: as you can see below, the ja in the first line is offset by one. This is caused by the ü which is 2 Bytes, but only one character. Hello, this is a bug in CDK, the ncurses interface used by CPM. CDK does not support multibyte strings at all; the i18n features only work correctly with ISO codepages and single-byte strings. As described in https://github.com/comotion/cpm/issues/1 we can either: -wait until CDK gains multibyte char support, which is unlikely as per Thomas E. Dickey, the CDK maintainer's website stating: The wide-character support is most important to most users. Implementing it is not as simple as plugging in the ncursesw library. You can do that, but all that it achieves at the moment is to make line-drawing work properly with UTF-8 encoding. or we can rewrite the CDK gui to forgo CDK and perhaps even ncurses. I am not into waiting for hell to freeze over and therefore I am currently exploring the second option. This has the added benefit of making the CPM codebase a lot smaller, and may result in security benefits as well as a more usable interface. Regards, Kacper signature.asc Description: OpenPGP digital signature
Bug#655470: hexer: Hexer trashes memory upon wrong key
Package: hexer Version: 0.1.7-1 Severity: critical Justification: breaks unrelated software While in hex field input mode hit an invalid key, such as backspace when there isn't anything to backspace over, hexer promptly fills up all memory on my system, freezing system operations due to trashing, and if I wait long enough rather than hard reboot, hexer eventually gets blown away by the OOM killer. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hexer depends on: ii libc62.13-24 ii libncurses5 5.9-4 hexer recommends no packages. hexer 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#626783: cpm: Wrong hash algorithm reported: 8 (sha256)
On 05/15/2011 11:42 AM, Torquil Macdonald Sørensen wrote: Package: cpm Version: 0.25-1 Severity: normal When cpm tries to encrypt after I have inputted some data in an initial database, I get the following error message: GpgMe error Wrong hash algorithm reported: 8 (sha256) Selecting OK, give the error message: Error encrypting the data. could not encrypt database file. Hi Torquil, that seems right, CPM 0.25 supports only the SHA1 hash algorithm. However, I have pushed CPM 0.26 which also supports SHA256, SHA384 and SHA512. https://github.com/comotion/cpm/commit/9ac6b893de8bdf0500905f8c9533a7e9d771e7f9 A package should get built shortly. -K -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#431682: libwnck complains about unhandled actions
kthx, requested info forwarded upstream. -Kacper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431682: libwnck complains about unhandled actions
Package: libwnck
Version: 2.18.2-1
when using a window manager that uses actions which libwnck doesn't
know about, like say openbox 3.4 in combination with rox and TaskTray,
libwnck complains very loudly:
(TaskTray:9403): Wnck-WARNING **: Unhandled action type (nil)
(TaskTray:9403): Wnck-WARNING **: Unhandled action type (nil)
(TaskTray:9403): Wnck-WARNING **: Unhandled action type (nil)
(TaskTray:9403): Wnck-WARNING **: Unhandled action type (nil)
... ad nauseum
AFAIU new actions are being hammered out all the time by the fine
folks at xorg and gnome, so I suggest the messages be throttled, or
ideally, removed, as in the attached patch.
-Kacper
--- libwnck/window.c.old 2007-07-04 10:30:26.0 +0200
+++ libwnck/window.c 2007-07-04 10:39:53.0 +0200
@@ -2188,12 +2188,6 @@
else if (atoms[i] == _wnck_atom_get (_NET_WM_ACTION_FULLSCREEN))
window-priv-actions |= WNCK_WINDOW_ACTION_FULLSCREEN;
- else
-{
- const char *name = _wnck_atom_name (atoms [i]);
- g_warning (Unhandled action type %s, name ? name: (nil));
-}
-
i++;
}
Bug#81668: the fix that caused this symptom is solving the wrong problem
On 4/16/07, Florian Weimer [EMAIL PROTECTED] wrote: * Kacper Wysocki: 1. If the attacker has the ability to spoof my DNS, I have been compromized. It doesn't need to resolve to a FQDN, a spoofed DNS can resolve my shortname to the IP of their choice. They can do this for all my services, not only ssh. SSH is supposed t work (IOW, fail reliably) even when the attacker controls DNS (or the routing, for that matter). The only way to achieve that is not to rely on DNS, which means that the specified host name must be processed unaltered. ... which is where the IP comes in. Since the hostkey exchange relies on the security of that first time connection, the specified hostname doesn't need to be processed at all - it functions merely as a menemonic for the user. However, at some point it'll have to be looked up in DNS - and if it's done that critical first time as a point of reference (user gets notified of the resolution along with the key fingerprint), later lookups can be DNS-spoofing-proof where your approach isn't. To put simply: the hostkey lookup in known_hosts is most securely done when matched only on IP, then the hostkey signature comparison can run its course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#81668: the fix that caused this symptom is solving the wrong problem
The canonical system name (as returned by name servers) is used by sshd(8) to verify the client host when logging in; other names are needed because ssh does not convert the user-supplied name to a canonical name before checking the key, because someone with access to the name servers would then be able to fool host au- thentication. If we can't rely on nameserver replies (and we can't) then relying on checking any name against the one in known_hosts. Let's look at the (bogous) exploit: The exploit would go something like this.. I have accounts on three boxes A, B and C. I'm currently using A. An attacker has compromised C, and has the capability of spoofing my DNS. I ssh from A to B. SSH asks for B's IP, the attacker replies with the IP of C. SSH asks for the IP's PTR record, to get the canonical host name. DNS (rightfully) gives C. SSH connects to C, checks the host key against the canicalized name C, host key matches. I get prompted for a password, and I type my password on B. Attacker has compromised my account on B. 1. If the attacker has the ability to spoof my DNS, I have been compromized. It doesn't need to resolve to a FQDN, a spoofed DNS can resolve my shortname to the IP of their choice. They can do this for all my services, not only ssh. 2. To mediate this disaster, ssh should check hostkeys based purely on IPs. If the *IP*'s don't match, the hostkeys don't get checked at all, and you'll get an I've never heard about this host before ssh dialogue: The authenticity of host 'foo (192.168.1.42)' can't be established. RSA key fingerprint is 10:2f:27:49:66:48:31:de:69:55:a5:79:9d:fa:cc:ce. Are you sure you want to continue connecting (yes/no)? Sounds better, doesn't it? Now my .ssh/known_hosts file should still have my _unencrypted_ short name (the one I asked for the 1st time I used ssh against that host) tied to the host key I got that first time, along with the _fingerprint_, as that's the only thing readably checkable and verifiable by a simple mortal. BUT considering the amount of unresolved and wontfix bugs at http://bugs.debian.org/ssh and the, eh, quality of the very first bug I end up reading while about to post my own, this might not be the most effective forum for improving the quality of ssh. With this many unclosed bugs (some with patches available!) looks like there's noone reading them, nor even forwarding upstream. If you are neither an SSH developer nor a Debian maintainer, nor plan to be either, why are you butting in Tommi? What's it to you? It's not like you're helping, is it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370384: pretty unacceptable
What on earth is the jigdo package doing in debian at all? Just having it in the repository risks misleading many users - myself included - as the package delivers none of the functionality it has been promising for nearly a year! This package is *unusable*. Either the maintainer fixes jigdo to actually process .jigdo files and assemble .ISO images, or this package should be taken out of testing. I'm bumping the severity of this bug to grave for uselessness. Users beware: use jigdo-lite instead. -Kacper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399363: gDeskCal recurring event dates generated incorrectly
Package: gdeskcal
Version: 0.57.1-2
After correspondence with Martin Grimme I realized my previous patch
(which has been applied in 0.57.1-2) generates recurrences every 4
weeks for events which recur monthly, which is not the correct
behaviour. E.g. I have created an event Test on August 31st,
recurring every month for 10 times:
* August 31st
* September 28th
* October 26th
* November 23rd
* December 21st
...
* May 10th - not really end of month... ;)
Attached is a little patch that adds the year and month first, then
changes the day to the last day of the month if it's out of range,
thereby calculating the recurring date correctly.
There's a problem with this method, however: the fallback sticks, so
an event originally set to the 31st will be on the 30th until it hits
February, when it'll stick as 29th for leap years, or 28th forever
after. This is because the next recurrence of an event is calculated
based on the previous occurance, not based on the original occurence.
Fixing this will require a more intrusive patch.
diff -urdp gdeskcal-0.57.1/code/CalMediator.py gdeskcal-0.57.2-kw/code/CalMediator.py
--- gdeskcal-0.57.1/code/CalMediator.py 2006-11-19 14:03:37.0 +0100
+++ gdeskcal-0.57.2-kw/code/CalMediator.py 2006-05-09 21:33:58.400603120 +0200
@@ -105,6 +105,7 @@ class CalMediator:
# configure
self.set_config(self.__config)
+self.__window.set_keep_below(True)
diff -urdp gdeskcal-0.57.1/code/planner/CalEditor.py gdeskcal-0.57.2-kw/code/planner/CalEditor.py
--- gdeskcal-0.57.1/code/planner/CalEditor.py 2006-11-19 14:03:37.0 +0100
+++ gdeskcal-0.57.2-kw/code/planner/CalEditor.py 2006-05-09 22:06:59.166480936 +0200
@@ -217,9 +217,11 @@ class CalEditor(gtk.Dialog):
elif (p and p[0] == {):
entries = p[1:-1].split(|)
# The GTK devs deprecated OptionMenu in favor of ComboBox
# but there is no quick way to fix it, ComboBox is a beast in
# comparison to this simplicity. --KW
+# addendum:
+# However, ComboBoxen can't be set_keep_below(False)
option = gtk.OptionMenu()
option.show()
menu = gtk.Menu()
diff -urdp gdeskcal-0.57.1/code/planner/cal/Date.py gdeskcal-0.57.2-kw/code/planner/cal/Date.py
--- gdeskcal-0.57.1/code/planner/cal/Date.py 2006-11-19 14:03:37.0 +0100
+++ gdeskcal-0.57.2-kw/code/planner/cal/Date.py 2006-08-26 19:17:20.0 +0200
@@ -1,5 +1,5 @@
import time
-import calendar
+from calendar import monthrange,timegm
from datetime import datetime,timedelta
@@ -56,9 +56,9 @@ class Date:
#
def __utc_to_localtime(self):
-secs = calendar.timegm(self._to_time())
+secs = timegm(self._to_time())
localtime = time.localtime(secs)
-localsecs = calendar.timegm(localtime)
+localsecs = timegm(localtime)
diff = int(localsecs - secs)
self.add_time(0, 0, 0, 0, 0, diff)
@@ -105,27 +105,32 @@ class Date:
# Adds a given amount of time to the given date. Amounts may be negative.
#
def add_time(self, dyear, dmonth, dday, dhour = 0, dmin = 0, dsec = 0):
+
+# print Running add_time(%s, Y:%d, M:%d, D:%d, H:%d, M:%d, S:%d) % (self, dyear, dmonth, dday, dhour, dmin, dsec)
+self.__year = self.__year + dyear
+if self.__month + dmonth 12:
+ self.__year = self.__year + 1
+ dmonth = dmonth - 12
+self.__month = self.__month + dmonth
+
+(firstday, numdays) = monthrange(self.__year, self.__month)
+if self.__day numdays:
+ self.__day = numdays
+
old_time = self._to_time()
dt_current_time = datetime.fromtimestamp(time.mktime(old_time))
-delta = timedelta(dday, 0, 0, 0, 0, 0, dmonth * 4 + dyear * 52 )
-
+delta = timedelta(dday, dsec, 0, 0, dmin, dhour, 0)
dt_current_time = dt_current_time + delta
-
t = dt_current_time.timetuple()
self.__year = t[0]
self.__month = t[1]
self.__day = t[2]
self.__hours = t[3]
self.__mins = t[4]
self.__secs = t[5]
-# add any hours, minutes or seconds separately. Why? -KW
-if (dhour or dmin or dsec): self.__add_daytime(dhour, dmin, dsec)
-
-
-
def __add_daytime(self, dhour, dmin, dsec):
ch, cm, cs = self.get_daytime()
Bug#228924: deprecations were fixed - try again
Hi, the deprecations (including the 'gtk' module import error) were fixed by me in gdeskcal 0.57.1-2. Don't know about the original bug reported by Marius Gedminas. Could you please confirm that gdeskcal no longer fails to start? TIA, -Kacper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344154: ddd won't honour app-defaults
It seems that DDD binds the scroll wheel in Ddd.in and also loads its
default bindings from /etc/X11/app-defaults/Ddd. However, flipping the
bindings for Btn[45]{Up,Down} from next-line() to previous-line() and
vice versa has no effect whatsoever!
I'd really like to fix this but I can't find any other place the
bindings are set.
Cheers,
-Kacper
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396199: lesstif2 inversed scrollwheel
Package: lesstif2 Version: 0.94.4-2 For a time now ddd has been scrolling up when I scroll down, and vice versa (see #344154). I tracked this down to libXm - Transltns.c where Btn4Down is bound to a down action and Btn5Down is bound to an up action while they should be bound the other way around. The following patch changes to the correct binding. Cheers, -Kacper diff -urp lesstif2-0.94.4/lib/Xm-2.1/Transltns.c lesstif2-0.94.4-kw/lib/Xm-2.1/Transltns.c --- lesstif2-0.94.4/lib/Xm-2.1/Transltns.c 2004-10-02 16:01:57.0 +0200 +++ lesstif2-0.94.4-kw/lib/Xm-2.1/Transltns.c 2006-10-30 16:28:51.0 +0100 @@ -670,8 +670,8 @@ XmConst char _XmTextIn_XmTextEventBindin /* Scroll wheel */ \nShiftBtn4Down:page-left() \nShiftBtn5Down:page-right() -\nBtn5Down: scroll-one-line-up() -\nBtn4Down: scroll-one-line-down() +\nBtn5Down: scroll-one-line-down() +\nBtn4Down: scroll-one-line-up() #endif ; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344154: it's lesstif2's fault
I did some more bughunting and found that lesstif2's libXm is binding the Btn4Down and Btn5Down actions upside-down. See lesstif2 bug #396199 for patch. Cheers, -Kacper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395429: gaim: symbol lookup error: gaim: undefined symbol: gaim_network_is_available
Package: gaim Version: 2.0.0+beta4-3 Severity: important I get gaim: symbol lookup error: gaim: undefined symbol: gaim_network_is_available when launching gaim. Some sort of linking error perhaps? This is in i386/unstable. Rebuilding the package fixed the problem. Cheers, -Kacper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383732: Patch sent to author
Upstream Martin Grimme has received and acknowledged the patch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295644: Processed: severity 295644 grave due to age and usability
Apologies, I thought the age and justification of this bug (above) sufficed. The bug does indeed occur in every instance where the recurring event is on a date that would be incorrectly computed. This to me was a show-stopper, which prompted me to write the patch in the first place, but it's certainly possible I read the guidelines wrong. IMHO a new release should certainly not contain this bug, but hey, you're the man. Maybe important is better? Didn't mean to abuse severity. Anyways, upstream Martin Grimme has been notified has acknowledged receipt of the patch. Thanks, -Kacper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295644: [PATCH bugfix] gdeskcal-0.57.1-timeparse.diff
I've added validation to the calendar.ics file parsing, as well as rewritten the add_time() function to work correctly with months of different length and leap years fixing this time validation bug. -Kacper diff -Nur gdeskcal-0.57.1/code/planner/cal/Date.py gdeskcal-0.57.2-kw/code/planner/cal/Date.py --- gdeskcal-0.57.1/code/planner/cal/Date.py 2004-03-15 23:46:05.0 +0100 +++ gdeskcal-0.57.2-kw/code/planner/cal/Date.py 2006-05-09 01:13:39.913505056 +0200 @@ -1,5 +1,6 @@ import time import calendar +from datetime import datetime,timedelta @@ -23,6 +24,13 @@ if (is_utc): self.__utc_to_localtime() +# Validate the time +try: + sttime = self._to_time() +except ValueError: + print * Date.__init__() ERROR: This date does not exist: %s %s %s %s:%s:%s % (year, month, day, hours, mins, secs) + + def __cmp__(self, other): @@ -98,52 +106,22 @@ # def add_time(self, dyear, dmonth, dday, dhour = 0, dmin = 0, dsec = 0): -current_time = self._to_time() -year = current_time[0] -month = current_time[1] -day = current_time[2] -julian_day = current_time[7] - -if (calendar.isleap(year)): ndays = 366 -else: ndays = 365 - - -julian_day += dday -while (julian_day ndays): -julian_day -= ndays -year += 1 -while (julian_day 1): -julian_day += ndays -year -= 1 - -month += dmonth -while (month 12): -month -= 12 -year += 1 -while (month 1): -month += 12 -year -= 1 - -year += dyear - - -if (dday): -t = time.strptime(%(year)d %(julian_day)d % vars(), -%Y %j) -elif (dyear): -t = time.strptime(%(year)d %(month)d %(day)d % vars(), -%Y %m %d) - -else: -t = time.strptime(%(year)d %(month)d %(day)d % vars(), -%Y %m %d) -#t = time.strptime(%(year)d %(month)d %(julian_day)d % vars(), -#%Y %m %j) +old_time = self._to_time() +dt_current_time = datetime.fromtimestamp(time.mktime(old_time)) +delta = timedelta(dday, 0, 0, 0, 0, 0, dmonth * 4 + dyear * 52 ) -self.__year = t[0] +dt_current_time = dt_current_time + delta + +t = dt_current_time.timetuple() + +self.__year = t[0] self.__month = t[1] -self.__day = t[2] +self.__day = t[2] +self.__hours = t[3] +self.__mins = t[4] +self.__secs = t[5] +# add any hours, minutes or seconds separately. Why? -KW if (dhour or dmin or dsec): self.__add_daytime(dhour, dmin, dsec) @@ -180,8 +158,6 @@ self.__mins = cm self.__secs = cs - - # # Returns the time interval to another date in seconds. # diff -Nur gdeskcal-0.57.1/code/planner/iCalLoader.py gdeskcal-0.57.2-kw/code/planner/iCalLoader.py --- gdeskcal-0.57.1/code/planner/iCalLoader.py 2004-03-15 23:46:05.0 +0100 +++ gdeskcal-0.57.2-kw/code/planner/iCalLoader.py 2006-05-03 20:42:44.513923200 +0200 @@ -216,8 +216,8 @@ self.__objects[-1].add_event(event) self.__objects.append(event) -rrule = event.get_recurrences() -event.set_recurrences(rrule) +rrule = event.get_recurrences() +# event.set_recurrences(rrule) while (1): l = lines.pop()
Bug#383732: [PATCH] gDeskcal py-gtk deprecations fix
Package: gdeskcal Version: 0.57.1-1 gDeskCal uses a variety of functions and constants that are deprecated as of Python 2.3 (?). This patch fixes them all, except for the use of gtk.OptionMenu, which has been deprecated in favour of gtk.ComboBox. Cheers, -Kacper diff -Nur gdeskcal-0.57.1/code/BGWatcher.py gdeskcal-0.57.2-kw/code/BGWatcher.py --- gdeskcal-0.57.1/code/BGWatcher.py 2004-03-15 23:46:05.0 +0100 +++ gdeskcal-0.57.2-kw/code/BGWatcher.py 2006-05-09 01:27:41.121621984 +0200 @@ -1,7 +1,7 @@ from Observable import Observable import desktop -import gtk +import gobject import time @@ -20,7 +20,7 @@ self.__old_bg = 0 self.__last_update = 0 -gtk.timeout_add(50, self.__check_bg) +gobject.timeout_add(50, self.__check_bg) @@ -30,18 +30,18 @@ id = desktop.get_wallpaper_id() if (id != self.__old_bg): self.__last_update = str(time.time()) -gtk.timeout_add(500, self.__notify_update, self.__last_update) -#gtk.idle_add(self.__notify_update, self.__last_update) +gobject.timeout_add(500, self.__notify_update, self.__last_update) +#gobject.idle_add(self.__notify_update, self.__last_update) self.__old_bg = id except StandardError, e: if (self.__old_bg): self.__last_update = str(time.time()) -gtk.timeout_add(500, self.__notify_update, self.__last_update) -#gtk.idle_add(self.__notify_update, self.__last_update) +gobject.timeout_add(500, self.__notify_update, self.__last_update) +#gobject.idle_add(self.__notify_update, self.__last_update) self.__old_bg = 0 -return gtk.TRUE +return True @@ -50,4 +50,4 @@ if (timestamp != self.__last_update): return self.update_observer(self.OBS_CHANGE_BG) -return gtk.FALSE +return False diff -Nur gdeskcal-0.57.1/code/Cal.py gdeskcal-0.57.2-kw/code/Cal.py --- gdeskcal-0.57.1/code/Cal.py 2004-03-15 23:46:05.0 +0100 +++ gdeskcal-0.57.2-kw/code/Cal.py 2006-05-09 01:30:14.521301688 +0200 @@ -4,6 +4,7 @@ import sfrmapper import gtk +import gobject import pango import time import os @@ -71,22 +72,22 @@ gtk.Fixed.__init__(self) # month (and year) -self.__lbl_month = CalLabel(2, 1, gtk.FALSE) +self.__lbl_month = CalLabel(2, 1, False) self.__lbl_month.show() self.put(self.__lbl_month, 0, 0) # year alone -self.__lbl_year = CalLabel(1, 1, gtk.FALSE) +self.__lbl_year = CalLabel(1, 1, False) self.__lbl_year.show() self.put(self.__lbl_year, 0, 0) # weekdays -self.__lbl_weekdays = CalLabel(7, 1, gtk.TRUE) +self.__lbl_weekdays = CalLabel(7, 1, True) self.__lbl_weekdays.show() self.put(self.__lbl_weekdays, 0, 0) # days -self.__lbl_days = CalLabel(7, 6, gtk.TRUE) +self.__lbl_days = CalLabel(7, 6, True) self.__lbl_days.show() self.put(self.__lbl_days, 0, 0) @@ -238,8 +239,8 @@ # def set_month(self, month = 0, year = 0): -while (gtk.gdk.events_pending()): gtk.mainiteration() -gtk.idle_add(self.__idle_set_month, month, year) +while (gtk.gdk.events_pending()): gtk.main_iteration() +gobject.idle_add(self.__idle_set_month, month, year) def __idle_set_month(self, month, year): diff -Nur gdeskcal-0.57.1/code/CalMediator.py gdeskcal-0.57.2-kw/code/CalMediator.py --- gdeskcal-0.57.1/code/CalMediator.py 2004-03-15 23:46:05.0 +0100 +++ gdeskcal-0.57.2-kw/code/CalMediator.py 2006-05-09 01:35:02.244561104 +0200 @@ -15,6 +15,7 @@ from planner.Planner import Planner +import gobject import gtk import os import sys @@ -216,7 +217,7 @@ self.set_config(self.__config) month, year = self.__cal.get_month() -gtk.timeout_add(250, self.__cal.set_month, month, year) +gobject.timeout_add(250, self.__cal.set_month, month, year) self.__cmd_set_month_bg() @@ -268,7 +269,7 @@ filename = alpha = 0 -gtk.idle_add(self.__window.set_bg_image, filename, alpha) +gobject.idle_add(self.__window.set_bg_image, filename, alpha) @@ -280,7 +281,7 @@ def __cmd_quit(self): self.__config.save() -gtk.mainquit() +gtk.main_quit() diff -Nur gdeskcal-0.57.1/code/CalWindow.py gdeskcal-0.57.2-kw/code/CalWindow.py --- gdeskcal-0.57.1/code/CalWindow.py 2004-03-15 23:46:05.0 +0100 +++ gdeskcal-0.57.2-kw/code/CalWindow.py 2006-05-09 01:28:27.090633632 +0200 @@ -8,6 +8,7 @@ import os import sys import gtk +import gobject @@ -40,7 +41,7 @@ GlassWindow.__init__(self, gtk.WINDOW_TOPLEVEL) import icon; self.set_icon(icon.ICON) self.set_title(gDeskCal) -
Bug#302658: workaround for failure to obtain lease
Hi,
I got bitten by this as well. My take on the problem is that if you
have the resolvconf package installed, the script
/etc/udhcpc/default.deconfig
(called upon invocation by udhcpc) instead of running ifconfig runs
resolvconf, which does not put the network device in the state required
for udhcpc to work, resulting in bind() and such things returning
ENETDOWN.
The solution is to either apply the attached patch, which simply makes
sure ifconfig brings up the device regardless of whether you have
resolvconf installed, or not use the resolvconf package.
This and the companion bug (#302655) are two months old, and should be
attended to.
-K
--- default.deconfig 2005-04-01 16:05:50.0 -0500
+++ default.deconfig.new 2005-06-07 07:45:51.877221416 -0400
@@ -3,6 +3,5 @@
if [ -x /sbin/resolvconf ] ; then
resolvconf -d ${interface}.udhcpc
-else
- /sbin/ifconfig $interface 0.0.0.0
fi
+/sbin/ifconfig $interface 0.0.0.0
pgpjr7kt1NtEr.pgp
Description: PGP signature
Bug#312332: avoid spurious SIOCDELRT on obtaining lease
Package: udhcpc Version: 0.9.8cvs20050124-3 Hi, the script /etc/udhcpc/default.bound uses a method to flush default routes that evokes a spurious error, as in: # sudo ifup eth0 udhcpc (v0.9.9-pre) started Sending discover... Sending select for xxx.xxx.xxx.xxx... Lease of xxx.xxx.xxx.xxx obtained, lease time 51916 deleting routers SIOCDELRT: No such process adding dns xxx.xxx.xxx.xxx adding dns xxx.xxx.xxx.xxx adding dns xxx.xxx.xxx.xxx The attached patch fixes the SIOCDELR: No such process and some English, at the cost of being slightly more verbose. Going even further, the scripts could do with a quiet option so as not to produce output on ifup. I could whip something simple up, if the package maintainer would be interested. -K --- default.bound.old 2005-06-07 09:35:46.081749952 -0400 +++ default.bound 2005-06-07 09:51:41.880446464 -0400 @@ -10,9 +10,10 @@ if [ -n $router ] then - echo deleting routers - while /sbin/route del default gw 0.0.0.0 dev $interface - do : + echo Resetting default routes + for i in `/sbin/route -n | grep ^default.*$interface` + do + route del default gw 0.0.0.0 dev $interface done for i in $router
Bug#302658: workaround for failure to obtain lease
On 06/07/05 08:51:14, Eric Van Buggenhaut wrote: On Tue, Jun 07, 2005 at 12:06:46PM +, Kacper Wysocki wrote: [snip] but instead of -else - /sbin/ifconfig $interface 0.0.0.0 fi +/sbin/ifconfig $interface 0.0.0.0 I'd rather use -else - /sbin/ifconfig $interface 0.0.0.0 fi +/sbin/ifconfig $interface up Any comment ? Thanks for the quick follow-up. Seems to work fine here, however the former ifconfig stanza is upstream, maybe they should use 'ifconfig $interface up' as well for their sample scripts, as it is indeed cleaner. -K pgpHOF3Oivt4n.pgp Description: PGP signature
Bug#295644: gdeskcal does not check dates of repeat events for errors
package: gdeskcal version: 0.57.1-1 Invalid dates are passed to Date.add_time. This can happen if the calendar.ics file is corrupted, or more likely, if a repeat event generates an invalid date. For example, an event to repeat every month on the 31st will cause an invalid date every second month. More annoyingly, any cross-month repeat event set later than the 28th will be an invalid event in February. The ValueError exception caused by this invalid date does not halt the program; but the calendar will not show dates until you scroll a month back and forth. Here's an example calendar.ics stanza that will cause an error: BEGIN:VEVENT DTSTART:20031230T08 SUMMARY:Pay rent RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=8 END:VEVENT If you have a lot of events these can be difficult to find. Here's a trace (most recent last): /usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py:90: GtkDeprecationWarning: gtk.mainloop is deprecated, use gtk.main instead self.warn(message, DeprecationWarning) Traceback (most recent call last): File /usr/share/gdeskcal/code/Cal.py, line 301, in __idle_set_month if (self.__planner.get_events(year, month, day)): File /usr/share/gdeskcal/code/planner/Planner.py, line 132, in get_events events += cal.get_events(year, month, day) File /usr/share/gdeskcal/code/planner/cal/Calendar.py, line 42, in get_events if (e.occurs_on(year, month, day)): File /usr/share/gdeskcal/code/planner/cal/CalEvent.py, line 115, in occurs_on self.__compute_recurrences(year) File /usr/share/gdeskcal/code/planner/cal/CalEvent.py, line 43, in __compute_recurrences recs = self.__recs.get_recurrences(self.get_start(), year) File /usr/share/gdeskcal/code/planner/cal/Recurrences.py, line 123, in get_recurrences rule.get_delta(rule.DAY)) File /usr/share/gdeskcal/code/planner/cal/Date.py, line 139, in add_time %Y %m %d) File /usr/lib/python2.3/_strptime.py, line 513, in strptime julian = datetime_date(year, month, day).toordinal() - \ ValueError: day is out of range for month I notified the author of gdeskcal by email in August, but never received a reply. Cheers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
