Re: ITP: bnc
On Wed, Mar 22, 2000 at 08:31:16PM +0100, Marco d'Itri wrote: I'm packaging the bnc IRC bouncer. IIRC that's already packaged and uploaded to Incoming. BTW your Mail-Followup-To: md, debian-devel@lists.debian.org is wrong... -- enJoy -*/\*- don't even try to pronounce my first name
Re: 5 days till Bug Horizon
On Wed, Mar 22, 2000 at 03:51:48PM +0100, Richard Braakman wrote: On Wed, Mar 22, 2000 at 12:50:19PM +0100, Wichert Akkerman wrote: Package: netbase (debian/main). Maintainer: Anthony Towns [EMAIL PROTECTED] 59282 netbase: portmap is killed too early on shutdown Hasn't this one been fixed by now? Something is up with netbase; it has loads of RC bugs now. This happens to be the only one older than the snapshot date. I've been away, so there hasn't bee a bugfix upload for a few weeks now. That's about all that's been up with it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpHXACMxYBfS.pgp Description: PGP signature
Idea: Debian Developer Information Center
Hi dear co-developers, we're so many developers that's it's getting difficult to know us each other and even more difficult to know our respective habits concerning the way we're doing our Debian job. I think that we need a page (possibly a cgi or a page automatically updated once a day) that would give the maximum of information concerning one maintainer. This would include : - information from the LDAP db (name, email, last seen on ...) - information about the NMU policy that the maintainer has adopted (timeframe before a NMU is allowed, do i need an authorization to do a nmu ?, ...) - the list of packages he's maintaining (yes some maintainer forget that they're maintaining some packages) with up-to-date statistics for each package (number of important/normal/wishlist bugs, standards-version that it does follow, last upload) - a link to the personnal bug page - any other information that may be suitable for such a page like the latest news that must be read by Debian developers (think about debian-devel-announce) With this system, each developer can add his own page on one of his bookmark and from time to time he can check what he's responsible for and what he should do in one look. And anyone can check the page of any developer before doing a NMU, he would be able to see the NMU policy, the time when the maintainer was last seen in Debian and so on ... it's also a good way to evaluate the quality of the work one is doing for Debian. I may be volunteering to work (one day) on something like that but I fear that i'll run into problems since I need to get information from various sources (ldap, bts, packages). Any idea/comment acepted. Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub
Re: xfce package
Le Wed, Mar 22, 2000 at 10:54:15PM +0100, Fabrice Gautier écrivait: XFCE 3 is very different from the xfce in potato. [...] I think you should rename it xfce2 and it should stay in contrib, and be orphaned (but there is no known bug, so doesn't really need a maintener) at least while there is no new RC bugs discovered. And a new package (says xfce3 or simply xfce) should be build (by a new maintener) and go into main I beg to disagree here, there's no point keeping a xfce2 in contrib. But if you really want, then you're free to do it. We're not looking for more work unless it's really useful and in this case it's not that much useful ... Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub
Re: Compiling Error
Date: Wed, 22 Mar 2000 14:55:58 +0100
From: Marcus Brinkmann [EMAIL PROTECTED]
To: Michal Fecanin Araujo [EMAIL PROTECTED]
Cc: Debian Development List debian-devel@lists.debian.org
Subject: Re: Compiling Error
On Wed, Mar 22, 2000 at 01:15:01PM +, Michal Fecanin Araujo wrote:
--
#include stdio.h
FILE *output=stderr;
int main()
{
fprintf(output,Hello World\n);
}
--
The problem is that its not possible to initialize output with stderr
because it is not a constant. Is there any solution to this without
modification of the code, only with gcc options.
No. Your code is invalid, and it should be fixed. You already know the fix.
Now you just have to accept it.
This is an interesting problem which was raised on the pgcc mailing list
last year. Check out my reply to someone's question:
http://www.delorie.com/archives/browse.cgi?p=pgcc/1999/10/23/23:19:18
and Marc Lehmann's answer:
http://www.delorie.com/archives/browse.cgi?p=pgcc/1999/10/24/19:18:25
summary: C is annoying like that, but if you want to have
static FILE *errfile = stderr;
in a library, but have it be legal C (!), you can use GNU C constructors, or
you can
static FILE *errfile = NULL;
#define errfile (errfile?errfile:stderr)
This is easier than explicitly checking at the top of every function which
uses it. I ran into this problem when hacking the Linux-lab-project
http://www.llp.fu-berlin.de/ GPIB drivers for a glibc 2.1 system (rh6.0).
--
#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca)
The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: of bash and ...sbin/
On 22-Mar-00, 15:59 (CST), Jacob Kuntz [EMAIL PROTECTED] wrote: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? We discussed (and argued and flamed and ...) that to death. The objection is mostly due to potential confusion (there are a lot more potential targets for command completion, and most of them are *not* what the user is looking for) and inertia, and the expectation that a user who finds value in use of traceroute or ifconfig or whatever is also a user who is capable of modifying their path. sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
On Thu, Mar 23, 2000 at 08:33:48AM +1100, Craig Sanders wrote: On Tue, Mar 21, 2000 at 04:23:31PM +0900, Junichi Uekawa wrote: garabik COLOR:1:cyan:black garabik COLOR:5:brightcyan:black The same can be said about the default ls colors. It shows directory names with blue on black. yep, i forgot to mention that until after i'd sent the message. blue on black is just a bad idea - too little contrast between fg bg to be readable. yellow on black is probably the best choice: good contrast and not not brigth. Very comfortable. But yellow on a white bg may not be so good. A+ -- Fabrice Gautier [EMAIL PROTECTED] I don't get no respect.
Re: 5 days till Bug Horizon
On Wed, Mar 22, 2000 at 11:09:01AM +0100, Igor Mozetic wrote: Richard Braakman writes: The packages involved are fetchmail, g++, gpm, kernel-image-2.2.14-ide (do we really need it? I assumed it's needed for the bootfloppies), Kernel 2.2.14 is severly broken (OOM problems). We had crashes and killings of essential processes on several machines. And there is no PLIP in it.. But the kernel maintener doesn't seem to think it is a RC bug.(see the BTS) anyway 2.2.15 will close the bug. A+ -- Fabrice Gautier [EMAIL PROTECTED] We are not a loved organization, but we are a respected one. -- John Fisher
Re: of bash and ...sbin/
Jacob Kuntz [EMAIL PROTECTED] writes: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? Do you have a problem putting /sbin:/usr/sbin in your personal path? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
now that you have discovered the awful secret of debian, the secret cabal will have to take care of you. wait right where you are. there will be a knock on the door shortly. craig TINC
Re: ITP: transformiix
Yes, given docbook*, task-sgml, psgml, yasgml, and especially jade, are in text, I'd concur that transformiix should go there too... It will be moved in the next release.
Re: of bash and ...sbin/
Date: Thu, 23 Mar 2000 08:48:47 +1100 From: Craig Sanders [EMAIL PROTECTED] To: Jacob Kuntz [EMAIL PROTECTED] Cc: Chad Miller [EMAIL PROTECTED], debian-devel@lists.debian.org Subject: Re: of bash and ...sbin/ On Wed, Mar 22, 2000 at 11:50:10AM -0500, Jacob Kuntz wrote: Chad Miller ([EMAIL PROTECTED]) wrote: I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . not to mention ifconfig! having these utils in the non-root path is hardly a security risk. if anything, this is just to keep down helpdesk calls like what does MAKEDEV do? personally, since many of these commands print out usefull, non-security-risking data, i don't see any good reason to keep em out. we've had this flamewar before, only a few months ago. just add /sbin:/usr/sbin:/usr/local/sbin to your $PATH and be done with it. it only takes a few seconds (do it in /etc/profile if you want) and it doesn't risk breaking existing scripts. many scripts (both debian scripts and local sysadmin scripts) make use of ping, traceroute, ifconfig and others in the sbin directories. it is common practice to specify the full path to sbin binaries to avoid any potential problems with the PATH being different in different contexts (e.g. login shell vs cron environment vs su or sudo environment). moving these programs to different directories will break those scripts. the minimal benefit of moving them is greatly outweighed by the damage it would cause. in short, add the sbin directories to your PATH and move on. Agreed (mostly). It is very important that Debian have things in the same place as other Linux distros, and other common Unix flavours. Otherwise, scripts from commercial software and other stuff that isn't always as portable as it should be will be spuriously broken on Debian. Lets not not go out of our way to lay traps for vendors who we are hoping will support Debian GNU/*. It seems to me that binary locations are one of those things that Unix is stuck with, even though it would be nice if we could change them. What should be done is to add /usr/sbin and /sbin to the PATH of ordinary mortal users. There is no security issue here, since they could always add it themselves if they actively wanted to cause harm. If you were setting up restricted-shell accounts, you would need to change PATH anyway, since bash is in the standard path, which kind of defeats the restricted shell, except as an anti-cluelessness measure :) OTOH, there are programs that could move. Programs which aren't in other Unices, such as fbset, should maybe stay in /usr/sbin, since it's job is to configure the machine. The FHS (http://www.pathname.com/fhs/1.2/fsstnd-4.10.html) says that /usr/sbin has daemons, non-essential administration tools, and binaries for non-critical server programs. The administrator is not necessarily root, since settings which any user can change can be administered by anyone. I'd call changing screen settings, turning on DPMS on the console with setterm, or stuff like that, counts as admining in my book. Therefore, these programs are admin tools, but users should have /usr/sbin (and probably /sbin) in their PATH, because they can usefully use these admin programs. (even for stuff they're not allowed to change, they can get config info. It probably doesn't help them to see this config info, but they can see it if they're curious.) Everything that is more or less administrative should go in /usr/sbin, which everyone should have in their PATH. (oh yeah, did I mention that /usr/sbin should be the default PATH after you install the base system. Oh, I think I did. hehe :) One thing we should _not_ do is to have things in two places at once, with symlinks. That just sucks, IMHO :) -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: 100Mb/Full Duplex
I hope I understand your question. Donald Becker's web site has a few utilities, 'mdiag' is one, that let you manually set the speed. It worked for my pcmcia EEpro, but it does not work for all cards. *Tim Sailer wrote: Hi folks. I'm having some trouble, actually with a Cisco 6509 switch, but getting it to talk to 20 VALinux machines. My story: I have a rack of 20 machines needing to talk to a Pix firewall with gigbit interfaces on it. To do this, we set up a test rig using an Alteon switch with 1 gigabit interface and 24 100bT ports for the boxes. When we run in this mode, everything performs well. Now, we switch this over to the Cr^Hisco switch, and it all goes to hell. It seems like the 6509 doesn't negotiate with the EEPro100 NICs in the linux boxes. Errors out the butt, and the switch ports claim that they are talking 10/half when they should be talking 100/full. I've looked at the NIC driver source, but it's non-obvious, to me anyway, how to lock these puppies in 100/full. Any pointers? Thanks, Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps I have never found that criticism is ever inhibited by ignorance. ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Lapeyre [EMAIL PROTECTED], [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: blue on black is unreadable
Date: Wed, 22 Mar 2000 13:56:52 -0600
From: Steve Greenland [EMAIL PROTECTED]
To: debian-devel@lists.debian.org
Subject: Re: blue on black is unreadable
On 21-Mar-00, 20:06 (CST), Peter Cordes [EMAIL PROTECTED] wrote:
The Linux text console is readable (barely), but xterm uses and even worse
colour for ANSI blue. (assuming black background). The fix for this
is to change the colour used by xterm for ANSI blue, instead of changing all
apps to use a different ANSI colour escape code.
That's a neat trick for xterms,
Thanks :)
but since even you admit that
blue-on-black is only barely readable on the text console, wouldn't it
be better to just not have default configurations use blue-on-black? (It
shouldn't be a matter of changing apps, only default configs.)
Actually, I took another look at the console. The ANSI bright-blue used by
ls for directories is actually quite easy to see. The normal blue used by
lynx is not great, but readable. I'm sure there is a way to set the colours
the kernel uses somewhere, so doing this would be the best option.
If you're setting up a default color scheme for an app, the basic rule
is to use light colored text on dark backgrounds, and dark colored text
on light backgrounds. The only other thing you need to know is that
neither red nor blue are light colors.
Unless the darkish colours get used as alternate background colours, they
are wasted. There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours. (jed uses blue for it's status line,
but yellow is still visible against the BLUE_COLOUR I suggested.)
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black? With my colour mods to make ls output visible,
could the default change to be gray90 on black? Most new users won't get
around to finding the xterm resources file for a long time, and I imagine
they would be happier with black bg xterms until they do. We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
--
#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca)
The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: 100Mb/Full Duplex
You might try starting at Donald Becker's site -- http://cesdis.gsfc.nasa.gov/linux/drivers/ He has authored many ethernet drivers. He also has some test programs for specific cards which can help. Latest drivers for many cards available. There is a document there on autonegotiation. Links to several sites with fast ethernet information. Tim Sailer [EMAIL PROTECTED] wrote: : Hi folks. : I'm having some trouble, actually with a Cisco 6509 switch, but getting : it to talk to 20 VALinux machines. My story: : I have a rack of 20 machines needing to talk to a Pix firewall with : gigbit interfaces on it. To do this, we set up a test rig using an Alteon : switch with 1 gigabit interface and 24 100bT ports for the boxes. : When we run in this mode, everything performs well. Now, we switch this : over to the Cr^Hisco switch, and it all goes to hell. It seems like the : 6509 doesn't negotiate with the EEPro100 NICs in the linux boxes. Errors : out the butt, and the switch ports claim that they are talking 10/half : when they should be talking 100/full. : I've looked at the NIC driver source, but it's non-obvious, to me anyway, : how to lock these puppies in 100/full. Any pointers? : Thanks, : Tim : -- : (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps : I have never found that criticism is ever inhibited by ignorance. : ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** : -- : To UNSUBSCRIBE, email to [EMAIL PROTECTED] : with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- *** Running Debian Linux *** * For God so loved the world that He gave his only begotten Son, * * that whoever believes in Him should not perish...John 3:16 * * W. Paul Mills * Topeka, Kansas, U.S.A. * * EMAIL= [EMAIL PROTECTED] * WWW= http://Mills-USA.com/ * * Bill, I was there several years ago, why would I want to go back? * * pgp public key on keyservers everywhere? */ --
Re: of bash and ...sbin/
Miles Bader ([EMAIL PROTECTED]) wrote: Jacob Kuntz [EMAIL PROTECTED] writes: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? Do you have a problem putting /sbin:/usr/sbin in your personal path? no, do you have a problem with a more sensible default? if not, then why do you think this isn't a more sensible default? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: glibc-compat ???
It seems we don't have such compatibility packages for Debian; what am I missing? Could one install slink's glibc2.0 in a non-obstrusive way under potato or woody? Maybe you could use alien and install the rpm? I thing potato and woody is totally commited to 2.1 Strange. If i can remember, Slink has libc5 compatibility libs. Why not glibc2.0 compatibility libs for potato, as RH-based distros have? I'm CC'ing this post to debian-devel (the right place to talk about this issue). Taupter
Re: of bash and ...sbin/
Steve Greenland ([EMAIL PROTECTED]) wrote: On 22-Mar-00, 15:59 (CST), Jacob Kuntz [EMAIL PROTECTED] wrote: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? We discussed (and argued and flamed and ...) that to death. The objection is mostly due to potential confusion (there are a lot more potential targets for command completion, and most of them are *not* what the user is looking for) and inertia, and the expectation that a user who finds value in use of traceroute or ifconfig or whatever is also a user who is capable of modifying their path. finnally! a valid argument! i submit. sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: ITP: transformiix
Transformiix is a XSLT processor written in C++. URL? I really don't remember. I've checked out the code from the mozilla CVS. The 'readme.html' of TransforMiiX is available as http://lxr.mozilla.org/mozilla/source/extensions/transformiix/docs/readme.html. Or in /usr/doc/transformiix of a woody Debian system... =)
Re: of bash and ...sbin/
For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Right. But the maintainer refuses to do the right thing. End of the thread.
Re: of bash and ...sbin/
Agreed (mostly). It is very important that Debian have things in the same place as other Linux distros, and other common Unix flavours. Otherwise, scripts from commercial software and other stuff that isn't always as portable as it should be will be spuriously broken on Debian. Lets not not go out of our way to lay traps for vendors who we are hoping will support Debian GNU/*. It seems to me that binary locations are one of those things that Unix is stuck with, even though it would be nice if we could change them. What should be done is to add /usr/sbin and /sbin to the PATH of ordinary mortal users. There is no security issue here, since they could always add it themselves if they actively wanted to cause harm. If you were setting up restricted-shell accounts, you would need to change PATH anyway, since bash is in the standard path, which kind of defeats the restricted shell, except as an anti-cluelessness measure :) You have both, /usr/bin and /usr/sbin in your PATH. You broke your setup so all the following comments you do doesn't change A THING to you. You can't discuss about where to put each thing if you don't use the split bin/sbin system... =/
Re: glibc-compat ???
On Thu, Mar 23, 2000 at 02:42:26AM -0300, Taupter wrote: Strange. If i can remember, Slink has libc5 compatibility libs. Why not glibc2.0 compatibility libs for potato, as RH-based distros have? They're both libc 6.0 -- how would ld.so know which one you wanted? Any apps which run on 6.0 and not 6.1 are broken and should be fixed. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: ITP: bnc
On Wed, Mar 22, 2000 at 08:31:16PM +0100, Marco d'Itri wrote: I'm packaging the bnc IRC bouncer. too late Marco! I did it one month ago. :-P It's sitting in Incoming (dunno why?) and there is also a slink-compiled version (I needed to run on slink). fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: blue on black is unreadable
On Wed, Mar 22, 2000 at 11:41:35PM -0400, Peter Cordes wrote:
Date: Wed, 22 Mar 2000 13:56:52 -0600
From: Steve Greenland [EMAIL PROTECTED]
To: debian-devel@lists.debian.org
Subject: Re: blue on black is unreadable
On 21-Mar-00, 20:06 (CST), Peter Cordes [EMAIL PROTECTED] wrote:
The Linux text console is readable (barely), but xterm uses and even
worse
colour for ANSI blue. (assuming black background). The fix for this
is to change the colour used by xterm for ANSI blue, instead of changing
all
apps to use a different ANSI colour escape code.
That's a neat trick for xterms,
... but it makes default midnight commander setting in a xterm wacky
(lightgray and white on bright blue...).
Thanks :)
but since even you admit that
blue-on-black is only barely readable on the text console, wouldn't it
be better to just not have default configurations use blue-on-black? (It
shouldn't be a matter of changing apps, only default configs.)
Actually, I took another look at the console. The ANSI bright-blue used by
ls for directories is actually quite easy to see. The normal blue used by
lynx is not great, but readable. I'm sure there is a way to set the colours
the kernel uses somewhere, so doing this would be the best option.
actually, there is a program doing this (ctheme), it works in userspace,
modifying VGA palette. It is really great, has many themes included, and can
modify palette on per-console basis.
I am thinking of packaging it, when I get some spare time
If you're setting up a default color scheme for an app, the basic rule
is to use light colored text on dark backgrounds, and dark colored text
on light backgrounds. The only other thing you need to know is that
neither red nor blue are light colors.
Unless the darkish colours get used as alternate background colours, they
are wasted. There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours. (jed uses blue for it's status line,
but yellow is still visible against the BLUE_COLOUR I suggested.)
and midnight commander uses blue as background.
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black? With my colour mods to make ls output visible,
could the default change to be gray90 on black? Most new users won't get
around to finding the xterm resources file for a long time, and I imagine
they would be happier with black bg xterms until they do. We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
I personally like lightgray background and black foreground in xterm, because
this way small fonts are more readable... these preferences vary a lot
between users.
--
---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Terminal I/O without NCURSES
Where Can I look for any document/tutorial about the Linux's keyboard/video/xterm low-level programming ? This is because I would like to make a my own library for managing the Linux's terminals, without using the famous ncurses libraries. I tried to watch ncurses's sources, but they are too complex for me! Thanks for all information.
Re: of bash and ...sbin/
Jacob Kuntz [EMAIL PROTECTED] writes: traceroute is deeper than ping. and that changes something? one cannot assume that because someone is not logged in as root, they are a casual user. Why not? Non-casual users can start these programs from sbin nonetheless (see FHS rationale for not making sbin off-limits to users), so why not make the safe assumption that the user is a casual one. Programs that have expert modes (dselect, fdisk, lynx, etc.) always start with it turned off. I think this is a good strategy. saying that traceroute is deeper than ping is like saying that ps is deeper than ls. It is, just on a different measure. This does not disprove my statement. FWIW, I feel the need for ps much more often than for traceroute. and since when do we try to hide problems, in the network or otherwise? Yes, in a way functionality is hidden: because it is not normally needed. Do you contest the need for novice vs. expert modes in general? that will only encourage people to run things as root. this is *not* a good idea. mtr is suid-root, so this is a moot point. -- Robbe
Re: xfce package
On Wed, 22 Mar 2000, J.H.M. Dassen (Ray) wrote: On Wed, Mar 22, 2000 at 21:19:36 +0100, Raphael Hertzog wrote: upstream source. I don't know if we should upload it to frozen or if we should remove xfce from potato and only upload the new version to woody as suggested in the bub report #60258. I'd second that suggestion. Unlike the old version, the new xfce is using a free toolkit. I already began to package the lastest (gtk based) xcfe, but I haven't finished yet; if anybody wants to take this NMU over, feel free to ask, I'll send you my current patch. Cordialement, -- Si ca sent bon : mange-le, sinon pisse dessus... [Proverbe chien]
alternatives
Dear Friends We have a /etc/alternative/editor, but not a x-editor. Wouldn't this a usefull addition for the alternative-system? best regards Michael -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL / \ o
Bug#60917: Request for NMU (console-tools)
About Bug#60917: I cannot upload a fixed version now. FIX: * replace the preinst code quoted in the report by the following (please test it first). Note that it uses evil Press RETURNs in case something is probably broken. = if [ -d /usr/local/share/keytables ] then if [ -d `readlink -f /usr/local/share/keymaps` ] then mv /usr/local/share/keytables/* /usr/local/share/keymaps rmdir /usr/local/share/keytables elif [ -e /usr/local/share/keymaps ] then echo 2 /usr/local/share/keymaps is buggy - please check it ls -ld /usr/local/share/keymaps 2 echo 2 Press RETURN to continue read else mv /usr/local/share/keytables /usr/local/share/keymaps fi elif [ -e /usr/local/share/keytables ] then echo 2 EOF /usr/local/share/keytables is not a dir. I won't try to mess with it and you will surely want to do something with it, as the new location for local keymaps is now /usr/local/share/keymaps/. Press RETURN to continue EOF read fi * add a versionned Depends on debianutils (= 1.13.1), as advertised in the readlink(1) manpage. Testing: install the package several times, in each of the following cases: 1. /usr/local/share/keytables/ is a dir and 1a. /usr/local/share/keymaps is a dir = should move subdirs 1b. /usr/local/share/keymaps is a special file (mknod(1) it) = should complain 1c. /usr/local/share/keymaps does not exist = should move dir 2. /usr/local/share/keytables/ is a special file = should complain * maybe apply the rules in Filesystem hierarchy/Site-specific programs of the policy (create and remove /usr/local dirs from postinst/prerm), but I don't know if this should really be done for potato, better leave this for woody. -- Yann.
[ man-db_2.3.15_i386.changes INSTALLED]
Hi! I recompiled man-db as it was (no change) and reuploaded. As someone made me notice, the pure rebuild had few bytes of difference, so maybe we get a different result. Can people try the upgrade from 2.3.13 ?? And can that people that got the error try to downgrade to slink version and then upgrade to the new one? This is the real upgrade that bother me. If nobody will report any problem, I'll close the bugs. fab - Forwarded message from Debian Installer [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] Date: 23 Mar 2000 12:24:17 - From: Debian Installer [EMAIL PROTECTED] To: Fabrizio Polacco [EMAIL PROTECTED] Subject: man-db_2.3.15_i386.changes INSTALLED Installing: man-db_2.3.15.tar.gz to dists/potato/main/source/doc/man-db_2.3.15.tar.gz replacing man-db_2.3.14.tar.gz man-db_2.3.15.tar.gz to dists/woody/main/source/doc/man-db_2.3.15.tar.gz replacing man-db_2.3.14.tar.gz man-db_2.3.15.dsc to dists/potato/main/source/doc/man-db_2.3.15.dsc replacing man-db_2.3.14.dsc man-db_2.3.15.dsc to dists/woody/main/source/doc/man-db_2.3.15.dsc replacing man-db_2.3.14.dsc man-db_2.3.15_i386.deb to dists/potato/main/binary-i386/doc/man-db_2.3.15.deb replacing man-db_2.3.14.deb man-db_2.3.15_i386.deb to dists/woody/main/binary-i386/doc/man-db_2.3.15.deb replacing man-db_2.3.14.deb Changes: man-db (2.3.15) frozen unstable; urgency=high . * Just recompiled, with an upgraded potato system. Let's see if this wipes away the grave installation problem listed in bugs #60339, #60399, #60411, #60515. In that case, I'll close these bugs by hand :-) Announcing to debian-devel-changes@lists.debian.org Closing bugs: If the override file requires editing, reply to this email. Thank you for your contribution to Debian GNU/Linux. - End forwarded message - -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
mail address
I am interested in becoming a Debian developer. The information in Debian Developer's Reference section 2.2 mentions that I can send in a copy of my ID to certify my identity, but it does not specify an address to send this to. Can you please give me this address? Norman Cabrera (Norm Camero is my nick-name)
ITP: mp - an e-mail pretty-printer
mp is an e-mail pretty-printer developed by Rich Burridge at Sun. He uses the brief name mp but I would be happy to consider alternative names for a Debian package if it was felt that mp could be too confusing. I have created a provisional package and uploaded it to my home directory (~bates) on master.debian.org for anyone who wants to take a look. The copyright file reads This package was debianized by Douglas Bates [EMAIL PROTECTED] on Wed, 22 Mar 2000 14:51:23 -0600. It was downloaded from http://java.sun.com/people/richb/RichApps/mp/mpdist-3.5.1.tar.gz Upstream Author(s): Rich Burridge [EMAIL PROTECTED] Copyright: GPL Version 2
Bug#60988: general: problem with ssh install due to lack of gmp2 package in frozen
Package: general Version: 2323 Severity: important Partial output of apt-get install ssh Sorry, but the following packages have unmet dependencies: ssh: Depends: gmp2 (= 2.0.2) E: Sorry, broken packages There appears to be a libgmp2 package which replaces gmp2. Apt-get does not substitute this when asked to install ssh. It does when asked to install gmp2 though. -- System Information Debian Release: 2.2 Kernel Version: Linux vulcan 2.2.13 #2 Fri Feb 11 10:55:15 GMT 2000 i686 unknown
Re: Terminal I/O without NCURSES
man console_codes The console is a VT102 [EMAIL PROTECTED] wrote: Where Can I look for any document/tutorial about the Linux's keyboard/video/xterm low-level programming ? This is because I would like to make a my own library for managing the Linux's terminals, without using the famous ncurses libraries. I tried to watch ncurses's sources, but they are too complex for me! Thanks for all information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Robin Burgener / Linux Kernel Group / Corel Corporation mailto: [EMAIL PROTECTED] 20Q, the neural-net on the Internet - http://www.20q.net
Bug#60988: general: problem with ssh install due to lack of gmp2 package in frozen
On Thu, Mar 23, 2000 at 02:43:32PM + , David Croxford wrote:
Package: general
Version: 2323
Severity: important
Partial output of
apt-get install ssh
Sorry, but the following packages have unmet dependencies:
ssh: Depends: gmp2 (= 2.0.2)
are you sure, you have the correct line for non-US? Current ssh in non-US
looks like this
apt-cache show ssh
Package: ssh
Version: 1:1.2.2-1.4
Priority: optional
Section: non-US
Maintainer: Philip Hands [EMAIL PROTECTED]
Depends: libc6 (= 2.1.2), libpam0g, libssl09, libwrap0, libz1,
libpam-modules, libwrap0 (= 7.6-1.1)
[snip]
and sources.list should have
deb http://nonus.debian.org/debian-non-US frozen/non-US main
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 08:24:42PM +0100, Robert Bihlmeyer wrote: Dylan Paul Thurston [EMAIL PROTECTED] writes: On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? traceroute is deeper than ping. It exposes things that the casual user neither sees nor cares about. Ping only measures what everybody experiences anyway: how responsive is a particular host? Without going in depth as to what traceroute and ping are (a fruitless flame war) suffice it to say that I disagree with your deeper comment. One has to draw a boundary, and on GNU systems it runs between ping and traceroute. Others do it differnently, AFAIR AIX has both in sbin. These 'boundaries' are completely arbitrary, since as pointed out earlier, Herbert Xu isn't willing to change traceroute. Perhaps we should ask Dan Quinlan? Or mtr, for that matter? That should go into sbin. I filed a wishlist item. If it is really to go in sbin, then I shall also take the suid-bit off of it, since obviously only root will be using it anyway. mtr users, relax: none of this will happen, because, first and foremost, *I* use mtr as a user. :) -- Robert Woodcock - [EMAIL PROTECTED] To the other one percent -- thanks for the passion and color! -- Jeff Bezos
Re: mail address
I am interested in becoming a Debian developer. The information in Debian Developer's Reference section 2.2 mentions that I can send in a copy of my ID to certify my identity, but it does not specify an address to send this to. You would send it to [EMAIL PROTECTED], along with the rest of your application. Be advised that Debian hasn't been processing new maintainer applications for a while now; the process is about to open up again, but I don't know that there's a specified date. See http://www.debian.org/News/weekly/1999/39/ and http://www.debian.org/News/weekly/2000/9/ Will -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | | http://www.cis.udel.edu/~lowe/ | |PGP Public Key: http://www.cis.udel.edu/~lowe/index.html#pgpkey| --
Re: mail address
Speaking of new-maintainer re-opening soon... What about those that had submit'd applications back in 1999 (I believe I sent mine in nearly 8 months ago), does anyone know if they need to be re-submit'd or will they be picking up where they stop'd processing? Respectfully, Jeremy T. Bouse Will Lowe was said to been seen saying: You would send it to [EMAIL PROTECTED], along with the rest of your application. Be advised that Debian hasn't been processing new maintainer applications for a while now; the process is about to open up again, but I don't know that there's a specified date. See http://www.debian.org/News/weekly/1999/39/ and http://www.debian.org/News/weekly/2000/9/ -- ,-, | Jeremy T. Bouse - UnderGrid Network Services, LLC - www.UnderGrid.net | | All messages from this address should be atleast PGP/GPG signed | |Public PGP/GPG fingerprint and location in headers of message| | If received unsigned (without requesting as such) DO NOT trust it! | | [EMAIL PROTECTED] - NIC Whois: JB5713 - [EMAIL PROTECTED] | `-' pgp74iRd726OM.pgp Description: PGP signature
Re: ITP: GOB [Was: Re: GOB package?]
On Tue, Mar 21, 2000 at 07:11:07PM +, Jules Bean wrote: This would be mildy convenient for me, since the next major release of balsa may require, or simply prefer, GOB, to build. And gnome-pilot seems to require GOB now... [*sigh* why not just blasted use C++] *cough* Ian
Re: glibc-compat ???
On Thu, 23 Mar 2000, Hamish Moffatt wrote: On Thu, Mar 23, 2000 at 02:42:26AM -0300, Taupter wrote: Strange. If i can remember, Slink has libc5 compatibility libs. Why not glibc2.0 compatibility libs for potato, as RH-based distros have? They're both libc 6.0 -- how would ld.so know which one you wanted? Any apps which run on 6.0 and not 6.1 are broken and should be fixed. Some things changed from 2.0 to 2.1 so that non broken binaries won't work. One I know about is stat, which is now a macro instead of a function call (breaks smbsh, even if you recompile it) Some other software doesn't work either. One I know about is IBM DB2 database. I don't know why it doesn't work, it just doesn't, and of course I don't have the source. I've thought about compatibility links, but like you said, they're both libc 6.0. Overall though, there doesn't seem to be a lot of broken stuff. -- precision of expression is more important than conformance to traditional rules
Bug#60988: general: problem with ssh install due to lack of gmp2 package in frozen
On Thu, Mar 23, 2000 at 04:40:06PM +0100, Petr Cech wrote: [snip] are you sure, you have the correct line for non-US? Current ssh in non-US looks like this Yeah, this sounds like a apt line for frozen distribution and main/contrib/non-free sections, and a typoed line for non-us still pointing to slink. Is this possible? Jordi
dnrd sighup crash fix
Here is a fix for a crash on x86 when you send dnrd a
sighup. This problem shows up for sure on Slackware 7, but should happen
everywhere. I haven't tested it extensively, but if you check the original code
it becomes obvious why it needs to be changed. The only part that concerns me is
the use of the semaphore, but I think it's needed because it's used elsewhere.
This replaces a function ineither main.c or master.c I can't remember
right now, this is not my development machine.
static int reset_master(void){
inti;
log_msg(LOG_NOTICE, "resetting master
DNS");
sem_wait(dnrd_sem);
for (i = 0; i dbc; i++)
{ free_dnsrec(dbv[i]);
}
if
(dbv) {
free(dbv); dbv =
0; }
dbc = 0; dbmax =
0;
sem_post(dnrd_sem);
return
(0);}
Becoming a Pkg Mgr.
hi, How does one become a package manager? I could probably spair enough time to look after one. j. -- Method Digital Logic Company http://www.methodlogic.net Solutions for: -Web Design-Database Programming -Office Networking -Custom Applications
NIS+ Client Support Available / libpam_unix help needed
Over the past few months (shortly after my ITP), Debian-NIS+ Client support was developed by a small group of non-Debian maintainers. I post on debian-devel, to make the effort known among the Debian developers and the SPARC users, who might work in a SUN NIS+ environment AND to ask for libpam_unix help (see below). To get access to the NIS+ client package (i386) for Debian (potato) include deb http://www.realbodo.de/ debian/ deb-src http://www.realbodo.de/ debian/ in your /etc/apt/sources.list To install your Debian system as a NIS+ client do apt-get install nisplus libpam-unix2 Then read the doc in /usr/share/doc/nisplus. The package is based on SUSE's libpam_unix2 package, because the nisplus provided from Thorsten Kukuk from SUSE) package does not work with Debian's libpam_unix. With Debian's libpam_unix the client machine must be in the admin group on the nis+ server. With libpam_unix2 there's no need for that security hole. Ben Collins is looking on the problem, but due to his many other functions in the Debian project, he is short of time. The integration of the Debian NIS+ package in the Debian distribution would proceed faster, if somebody else would be looking in the PAM problem. I think some experience with the libpam_unix implementation is required. Certainly, nis+ access would be an advantage. The packaging work was done by Michael Feger (University of Karlsruhe), testing and documentation was done by Sebastien Chaumat and Pascal Degiovanni(Ecole Normale Superieure de Lyon). Both can be reached via the debian-nis+ mailalias [EMAIL PROTECTED] If you want to be added to the alias, please send a short email to me. Thanks. Rainer. -- Rainer Dorsch Abt. Rechnerarchitektur e-mail:[EMAIL PROTECTED] Uni StuttgartTel.: 0711-7816-215
Re: NIS+ Client Support Available / libpam_unix help needed
The integration of the Debian NIS+ package in the Debian distribution would proceed faster, if somebody else would be looking in the PAM problem. I think some experience with the libpam_unix implementation is required. Certainly, nis+ access would be an advantage. Just to clarify what needs to be done. I did not want to include a module called pam_unix2.so for fear of confusion with users. What I would like to see is the NIS+ functionality from pam_unix2.so to be merged into and work seemlessly with the current pam_unix.so. Atleast this way, the changes can be merged upstream, and integration is easier (e.g. just add nisplus to the modules options in the pam config files to enable the functionality). The folks the did all the work for this need a big thank you for the work they have been doing. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: glibc-compat ???
On Thu, Mar 23, 2000 at 12:09:23PM -0500 , Eric Weigel wrote:
I've thought about compatibility links, but like you said, they're both
libc 6.0.
LD_PRELOAD
Overall though, there doesn't seem to be a lot of broken stuff.
A friend is bitching about broken aplix(sp?). Thing is, it works on RH6.1
and SuSE 6.3 , both glibc-2.1
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
Re: blue on black is unreadable
On 22-Mar-00, 21:41 (CST), Peter Cordes [EMAIL PROTECTED] wrote:
Actually, I took another look at the console. The ANSI bright-blue used by
ls for directories is actually quite easy to see. The normal blue used by
lynx is not great, but readable. I'm sure there is a way to set the colours
the kernel uses somewhere, so doing this would be the best option.
No, because you then break all my settings that use normal (dark) blue
and red as background colors.
Unless the darkish colours get used as alternate background colours, they
are wasted.
They do.
There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours.
No, you doen't use them. I use them a lot, to highlight urls and headers
in mutt, for example.
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black?
Because that's what xterms do (by default) on every other single X
implementation ever done? (Ok, that's probably an exageration...but not
completely misleading, either.)
With my colour mods to make ls output visible, could the default
change to be gray90 on black? Most new users won't get around to
finding the xterm resources file for a long time, and I imagine they
would be happier with black bg xterms until they do.
I wouldn't. A lot of people I work with wouldn't. (Many would, of
course). I, for example, find it easier to read black text on light
backgrounds in xterms. My favorite is black on blanchedAlmond. I
don't, however, think that should be Debian's global default.
(I wonder if the preference for light-on-dark vs dark-on-light depends
on ambient light conditions?)
We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
We do cater to them. We have window managers that support themes and
easy ways to change them.
We have a nice set of default colors. They are easy to modify (in the
xterm case, if you don't have the desire to mess with Xresources, -fg
and -bg work quite nicely). Are they they best possible defaults?
Probably not. But if you change them, probably for every person who you
made happier, there's another you've pissed off.
Why do so many people want to believe that their personal preferences
represent universal truth? I agree that demonstrably bad defaults
(dark-on-dark) should be changed. But the reality is that things like
color selection are such a personal-preference issue that *most* people
will eventually tweak them to their preference, and the best we can (and
should) do is use a *workable* default, and go on.
(If there is a 90% consensus that we change the xterm default to white
on black, and change the kernel definition (or whatever) of blue to
something lighter, then fine, do it. But I strongly believe that you
won't get anywhere near that much agreement.)
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: 5 days till Bug Horizon
My first debian post :) The packages involved are fetchmail, g++, gpm, kernel-image-2.2.14-ide (do we really need it? I assumed it's needed for the bootfloppies), and perl-5.005. Package: fetchmail (debian/main). Maintainer: Paul Haggart [EMAIL PROTECTED] [HELP] This package needs a new maintainer. (RB) 43139 fetchmail flushed after failed delivery 50990 fetchmail: mail was fetched and deleted from server but never sent to local MTA Is anyone looking at this one. These are both fixed in upstream 5.3.1 (and 5.3.3 is in woody). What is the recommended course of action on this - I would like to try and get involved - and personally know a maintainer who can sponsor me. Should I go for 5.3.3, 5.3.1, 5.3.4 (latest upstream) or attempting to backport the fixes in 5.2.3 (what is currently in potato) Alan
Re: Bash, Keys, Potato
On Wed, Mar 22, 2000 at 02:39:20PM +, Stuart Auchterlonie wrote: On Wed, Mar 22, 2000 at 07:35:04AM -0300, Rodrigo Castro wrote: On Wed, Mar 22, 2000 at 11:12:37AM +0100, Martijn van de Streek wrote: Hi Rodrigo! On Tue, 21 Mar 2000, Rodrigo Castro wrote: get the key displayed. It works as a dead key, waiting for any other key. When I do type other key, it beeps and I get no output on screen. I reinstalled bash, libncurses5, libc6 and already trying changing my keymap, but I wasn't sucessful. I am getting crazy. Did you look at your ~/.inputrc file? Yes. I even created a new user with no .inputrc and no $INPUTRC (no .bashrc, .bash_profile too). I don't know what kind of stuff could be in my files to screw up only letter E. The problem occurs in console and in xterm. :-( I started with no .inputrc, no /etc/profile, no /etc/inputrc and even so I had problems with letter E (upcase only). Any idea? Even with no setup, no config files, I get no success. I upgraded my libreadline4 today and it didn't work either. []'s -- Rodrigo Castro [EMAIL PROTECTED] Computer Science undergraduate student - University of Sao Paulo I do not fear computers. I fear the lack of them. -- Isaac Asimov
epochs, circular dependancies, and other miscellany
I'm looking for some help on the dpkg/apt-based centralized configuration system I'm working on. Note that this is intended for use at the site I administer, and while I'd be pleased if it proved useful to others, it isn't intended to be a general solution. So please don't flame me for doing things in a way that's non-Debian. First an overview of how I intend it to work: Clients are updated by running apt-get dselect-upgrade. Since I want to be able to do this noninteractively, I have to get around both postinst scripts that interact with the user, and dpkg's handling of conffiles. I need this now, not when potato is ready, so I have to roll my own approach to noninteractivity. My current plan is to keep a local apt repository for the machines using this system. In it I will have modified versions of all packages with conffiles or postinsts; those which don't have either will exist in their original slink versions. To modify package A: - extract the files listed in its conffiles and postinst (possibly also cron.* files, if they're not always conffiles?) - rebuild it without these files, and in addition give it a new version number, probably the same as before with a new epoch, and a Depends: local-config-base-A, local-config-A local-config-A - put the extracted files in a new package called local-config-base-A with Provides: local-config-A; give it an upstream version number corresponding to that of the original A, and a Debian revision number of 0 initially; don't create conffiles entries for any files, even if they had them in the original A - if the postinst (now belonging to local-config-base-A) is potentially interactive I manually change that - now if I like I can of course create other local-config-*-A packages that provide local-config-A and conflict with other providers The issues I'm currently trying to deal with include: * epochs not being recognized. A concrete example is provided by a test case I did with cvs; for brevity we'll call it cvs_V instead of cvs_1.10.7-1.99.slink.y2k.1. I broke it into two packages, cvs_5:V and local-config-base-cvs_V-0. When I did a dpkg --purge cvs; apt-get update; apt-get install cvs it would retrieve whichever cvs (cvs_V or cvs_5:V) was in the ftp repository listed first in sources.list. Moreover, the retrieved file doesn't have the epoch prefix. Clearly I've misunderstood the functionning of epochs or apt-get; can someone enlighten me? * circular dependancies. Continuing with the prior example, I want cvs to depend on local-config-cvs so that the package doesn't get installed without config files. On the other hand, since the postinst is now in local-config-cvs instead of cvs, local-config-cvs should depend on cvs so that the postinst is able to use the contents of cvs. Since there's no postinst to be done for cvs itself now, really what I'd like is to be able to have this circular dependancy and for dpkg not to complain about each package depending on the other's being configured. I'm currently just doing the cvs depends: local-config-cvs, since I'm not anticipating the local-config files being installed by themselves. Naturally this isn't ideal though - suggestions appreciated. * Size and Installed-Size: any tips on how to easily generate these control fields for my split packages?
Re: ITP: mp - an e-mail pretty-printer
The provisional package I uploaded to my directory on master doesn't work :-/. Turns out there is a bug in the configure script that was exposed by building a Debian package. The upstream maintainer has promised to fix it after he returns from vacation April 3. If you really want to use it before then, you should create a symbolic link of ln -s /usr/share/mpdist /usr/local/lib/mp Once the upstream sources have been fixed I will recreate the package.
Re: 5 days till Bug Horizon
On Thu, Mar 23, 2000 at 08:44:26PM +, Alan Clucas wrote: My first debian post :) The packages involved are fetchmail, g++, gpm, kernel-image-2.2.14-ide (do we really need it? I assumed it's needed for the bootfloppies), and perl-5.005. Package: fetchmail (debian/main). Maintainer: Paul Haggart [EMAIL PROTECTED] [HELP] This package needs a new maintainer. (RB) 43139 fetchmail flushed after failed delivery 50990 fetchmail: mail was fetched and deleted from server but never sent to local MTA Is anyone looking at this one. These are both fixed in upstream 5.3.1 (and 5.3.3 is in woody). What is the recommended course of action on this - I would like to try and get involved - and personally know a maintainer who can sponsor me. Should I go for 5.3.3, 5.3.1, 5.3.4 (latest upstream) or attempting to backport the fixes in 5.2.3 (what is currently in potato) This late in the game, you need to backport the fixes to the version in potato. Make a diff of the changes against the current debian source, get it checked over by some knowledgable folks, and then have at it. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: glibc-compat ???
On Thu, 23 Mar 2000, Eric Weigel wrote: On Thu, 23 Mar 2000, Hamish Moffatt wrote: On Thu, Mar 23, 2000 at 02:42:26AM -0300, Taupter wrote: Strange. If i can remember, Slink has libc5 compatibility libs. Why not glibc2.0 compatibility libs for potato, as RH-based distros have? They're both libc 6.0 -- how would ld.so know which one you wanted? Any apps which run on 6.0 and not 6.1 are broken and should be fixed. Some things changed from 2.0 to 2.1 so that non broken binaries won't work. One I know about is stat, which is now a macro instead of a function call (breaks smbsh, even if you recompile it) Some other software doesn't work either. One I know about is IBM DB2 database. I don't know why it doesn't work, it just doesn't, and of course I don't have the source. I've thought about compatibility links, but like you said, they're both libc 6.0. Overall though, there doesn't seem to be a lot of broken stuff. The other one it breaks is Oracle 8.0, and one needs to convert Redhat compatibility libraries to be able install it, and a patch from Oracle. I have heard it also broke Applixware, but I am not sure. Robert Varga
Re: glibc-compat
Date: Thu, 23 Mar 2000 17:33:29 +1100 From: Hamish Moffatt [EMAIL PROTECTED] To: debian-user@lists.debian.org, debian-devel@lists.debian.org Subject: Re: glibc-compat ??? On Thu, Mar 23, 2000 at 02:42:26AM -0300, Taupter wrote: Strange. If i can remember, Slink has libc5 compatibility libs. Why not glibc2.0 compatibility libs for potato, as RH-based distros have? They're both libc 6.0 -- how would ld.so know which one you wanted? Any apps which run on 6.0 and not 6.1 are broken and should be fixed. Is it possible to run stuff that is linked against glibc-2.0.7 (rh5.2 used that, so I imagine a lot of commercial stuff linked against that, or at least people have old commercial stuff linked against it and would rather not pay for a new version.) Can you LD_PRELOAD (an old) libc? (with a wrapper script to set LD_PRELOAD.) Is there a way to do it at all without using chroot or hacking ld.so for special cases? Obviously it is possible, but is it possible practically and usefully? -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
