Bug#198507:
The workaround of using a ? worked. I guess nobody cares to have honest full file manifests for debs.
Bug#82780: duplicate of bug 61008 - patch supplied
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=61008 a patch to fix the behaviour has been supplied. As a workaround for your situation without the patch: remove any 'set colour on' lines from your ~/.ircrc and the system /etc/irc/* scripts and ircII as is without the patch will use your terminal colors instead of forcing white on black. -greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#61008: here's a patch for this issue
See my patch on http://code.krypto.org/patches/
specifically
http://code.krypto.org/patches/ircii-20051015-color-default-01.patch
(attached)
This patch was made against the debian 20051015 ircII but should be
easy to modify and apply against the latest official ircII release
(20060725) which still contains the bug.
The issue is that ircII always hard sets the fg and bg colors instead
of leaving them alone when background_colour and/or foreground_colour
are set to a value meaning terminal default (16).
This patch also changes the default colors when 'set colour on' is in
effect to be the terminal defaults.
-greg
diff --unified=6 -r ircii-20051015/include/config.h.dist
ircii-20051015-fixed/include/config.h.dist
--- ircii-20051015/include/config.h.dist2006-11-29 23:25:30.0
-0800
+++ ircii-20051015-fixed/include/config.h.dist 2006-11-29 22:21:11.588662500
-0800
@@ -110,13 +110,13 @@
* do work without being a pain.
*/
#define DEFAULT_ALWAYS_SPLIT_BIGGEST 1
#define DEFAULT_AUTO_UNMARK_AWAY 0
#define DEFAULT_AUTO_WHOWAS 0
-#define DEFAULT_BACKGROUND_COLOUR 1
+#define DEFAULT_BACKGROUND_COLOUR 16
#define DEFAULT_BEEP 1
#define DEFAULT_BEEP_MAX 3
#define DEFAULT_BEEP_ON_MSG NONE
#define DEFAULT_BEEP_WHEN_AWAY 0
#define DEFAULT_BIND_LOCAL_DCCHOST 1
#define DEFAULT_BOLD_VIDEO 1
@@ -140,13 +140,13 @@
#define DEFAULT_DECRYPT_PROGRAM NULL
#define DEFAULT_EXEC_PROTECTION 1
#define DEFAULT_FLOOD_AFTER 3
#define DEFAULT_FLOOD_RATE 3
#define DEFAULT_FLOOD_USERS 3
#define DEFAULT_FLOOD_WARNING 0
-#define DEFAULT_FOREGROUND_COLOUR 15
+#define DEFAULT_FOREGROUND_COLOUR 16
#define DEFAULT_FULL_STATUS_LINE 1
#define DEFAULT_HELP_PAGER 1
#define DEFAULT_HELP_PROMPT 1
#define DEFAULT_HELP_WINDOW 0
#define DEFAULT_HIDE_CHANNEL_KEYS 0
#define DEFAULT_HIDE_PRIVATE_CHANNELS 1
diff --unified=6 -r ircii-20051015/include/screen.h
ircii-20051015-fixed/include/screen.h
--- ircii-20051015/include/screen.h 2005-09-21 13:20:35.0 -0700
+++ ircii-20051015-fixed/include/screen.h 2006-11-29 22:25:12.851740500
-0800
@@ -39,12 +39,14 @@
#include window.h
#define WAIT_PROMPT_LINE 0x01
#define WAIT_PROMPT_KEY0x02
+#define COLOUR_DEFAULT 16
+
/* Stuff for the screen/xterm junk */
#define ST_NOTHING -1
#define ST_SCREEN 0
#define ST_XTERM 1
diff --unified=6 -r ircii-20051015/source/screen.c
ircii-20051015-fixed/source/screen.c
--- ircii-20051015/source/screen.c 2005-09-22 11:20:03.0 -0700
+++ ircii-20051015-fixed/source/screen.c2006-11-29 23:30:50.193809000
-0800
@@ -468,12 +468,25 @@
*/
static void
display_colours(fgcolour, bgcolour)
int fgcolour;
int bgcolour;
{
+ static int current_fg = COLOUR_DEFAULT;
+ static int current_bg = COLOUR_DEFAULT;
+ static int current_bold = 0;
+ static int current_blink = 0;
+
+ int emit_code = 0;
+ int desired_bold, desired_blink;
+
+ if (fgcolour 0)
+ fgcolour = COLOUR_DEFAULT;
+ if (bgcolour 0)
+ bgcolour = COLOUR_DEFAULT;
+
if (get_int_var(COLOUR_VAR))
{
/* Some people will say that I should use termcap values but
* since:
* 1- iso 6429 is the only used way for colour in the unix
*realm for now
@@ -483,28 +496,81 @@
* ... I'll stick with this way for now. But having only 8-9
* colour is a pity.
*-- Sarayan
*/
/* Written by Bisqwit ([EMAIL PROTECTED]) */
+ /* Reworked to support default terminal color, allowing use of
+* color on non-black background terminals. 20061129
+*-- Gregory P. Smith ([EMAIL PROTECTED])
+*/
/* mirc colours - iso 6469 colours translation tables */
static const u_char trans[] = 7042115332664507;
static const u_char bolds[] = 100010001100;
/* 0123456789ABCDEF */
u_char iso[15]; /* long enough for e[0;1;5;37;40m */
- snprintf(CP(iso), sizeof iso, \33[0;);
- if (bolds[fgcolour] == '1')
- my_strcat(iso, 1;);
- if (bolds[bgcolour] == '1')
- my_strcat(iso, 5;);
- snprintf(CP(my_index(iso, 0)), 7, 3%c;4%cm,
trans[fgcolour15], trans[bgcolour15]);
-
- fwrite(CP(iso), my_strlen(iso), 1, current_screen-fpout);
+ snprintf(CP(iso), sizeof iso, \33[);
+ if (fgcolour != COLOUR_DEFAULT)
+ desired_bold = bolds[fgcolour15] - '0';
+ else
+ desired_bold = current_bold;
+
+ if (bgcolour != COLOUR_DEFAULT
Bug#355296: abcde: album name with * causes gets expanded in shell -- failure
Package: abcde Version: 2.2.6-1 Followup-For: Bug #355296 When trying to rip this CD: http://www.freedb.org/freedb_search_fmt.php?cat=classicalid=4a0e9206 DTITLE=Beethoven / Beethoven: Symphony No.3 Eroica * Overtures The * gets expanded by abcde, then the expansion is processes (spaces replaced with _s, etc) and abcde tries to use it as the directory name (and probably meta data album). possibly exploitable by a malicious cddb response depending on what abcde does with the string... -- System Information: Debian Release: 3.1 Architecture: alpha Kernel: Linux 2.6.15.7-grsec Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages abcde depends on: ii cd-discid 0.9-1 CDDB DiscID utility ii cdda2wav 4:2.01+01a01-2 Creates WAV files from audio CDs ii cdparanoia3a9.8-11 An audio extraction tool for sampl ii flac 1.1.1-5gps01 Free Lossless Audio Codec - comman ii vorbis-tools 1.0.1-1.3 Several Ogg Vorbis Tools ii wget 1.9.1-12 retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297516: python2.3-crypto: SHA256 gives wrong results on alpha
Package: python2.3-crypto
Version: 2.0+dp1-2
Severity: important
[EMAIL PROTECTED]:~$ python
Python 2.3.5 (#2, Feb 9 2005, 11:41:59)
[GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2
Type help, copyright, credits or license for more information.
from Crypto.Hash import SHA256
s = SHA256.new()
s.update('')
s.hexdigest()
'47a69ec7598bed0f7b25e49ee6b4d2abe4200e497d8046b216343f0e36c608a3'
s = SHA256.new()
s.update('abc')
s.hexdigest()
'551ce4769446b343295ea7f819bae21157541986a4de11ab46b2340ea9831f22'
Both of those supposed SHA256 hash results are wrong. Verify them
against a correct implementation of SHA256.
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
and
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
respectively are correct.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: alpha
Kernel: Linux 2.6.10-rc3-nfs31-isa
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages python2.3-crypto depends on:
ii libc6.1 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii python2.3 2.3.5-1 An interactive high-level object-o
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: OpenSSL sha module / license issues with md5.h/md5c.c
On Mon, Feb 14, 2005 at 11:02:23AM +1100, Donovan Baarda wrote: On Sat, 2005-02-12 at 17:35 -0800, Gregory P. Smith wrote: I've created an OpenSSL version of the sha module. trivial to modify to be a md5 module. Its a first version with cleanup to be done and such. being managed in the SF patch manager: https://sourceforge.net/tracker/?func=detailaid=1121611group_id=5470atid=305470 enjoy. i'll do more cleanup and work on it soon. Hmmm. I see the patch entry, but it seems to be missing the actual patch. Did you code this from scratch, or did you base it on the current md5module.c? Is it using the openssl sha interface, or the higher level EVP interface? The reason I ask is it would be pretty trivial to modify md5module.c to use the openssl API for any digest, and would be less risk than fresh-coding one. Ugh. Sourceforge ignored it on the patch submission. i've attached it properly now. This initial version is derived from shamodule.c which does not have any license issues. it is currently only meant as an example of how easy it is to use the openssl hashing interface. I'm taking it an turning it into a generic openssl hash wrapper that'll do md5 sha1 and anything else. -g -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: OpenSSL sha module / license issues with md5.h/md5c.c
I've created an OpenSSL version of the sha module. trivial to modify to be a md5 module. Its a first version with cleanup to be done and such. being managed in the SF patch manager: https://sourceforge.net/tracker/?func=detailaid=1121611group_id=5470atid=305470 enjoy. i'll do more cleanup and work on it soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
I think it would be cleaner and simpler to modify the existing md5module.c to use the openssl md5 layer API (this is just a search/replace to change the function names). The bigger problem is deciding what/how/whether to include the openssl md5 implementation sources so that win32 can use them. yes, that is all i was suggesting. win32 python is already linked against openssl for the socket module ssl support, having the md5 and sha1 modules depend on openssl should not cause a problem. -greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
The md5.h/md5c.c files allow copy and use, but no modification of the files. There are some alternative implementations, i.e. in glibc, openssl, so a replacement should be sage. Any other requirements when considering a replacement? Matthias I believe the plan for md5 and sha1 and such is to use the much faster openssl versions in the future (based on a long thread debating future interfaces to such things on python-dev last summer). That'll sidestep any tedious license issue and give a better implementation at the same time. i don't believe anyone has taken the time to make such a patch yet. -g -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
