Re: crons scripts should report status info in the mail
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Karl M. Hegbloom: Since the output from cron jobs is mailed anyhow, as it should be, I think that all cron scripts should report in as they are run, and that this should be made a standard. Here's why. Joey I think what we need is a more intelligent run-parts, for Joey use with the cron jobs, that examines the output of each Joey script it runs, and if there is any output, prefaces it with Joey the name of the script. So if a cron script fails with an Joey error message, you will be able to tell which script it was. I like this idea the best. I'm not that fluent in C yet, or I'd try it. -- Karl M. Hegbloom [EMAIL PROTECTED] http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Perl 5.004, perl modules, and binary compatibility
-BEGIN PGP SIGNED MESSAGE- As the official version of perl 5.004 is finally out (I must admit I haven't installed the debian package yet, but I run webservers with lots of perl CGI and can't afford to break them), I have a few questions, comments, and thoughts. 1. In building my own perl kit for other machines I maintain, I noticed the option to maintain binary module compatibility with 5.003 at the expense of a poluted namespace. I assume this option was chosen for the debian package. 2. I also assume that perl being compiled for glibc is going to end up being a flag day for all the binary compiled perl modules. May I suggest that that would be the ideal time to compile perl with a clean namespace. Perhaps upload such a version of perl into experimental to allow the perl module developers time to get new versions of their packages released. I expect that liberal useage of versioned depends would be necessary to prevent anything from actually breaking. 3. I also think that any package that provides a perl module should be labled as such in its package name. Package names like www-search and alias hardly suggest that this is a perl module I'd like to install. CGI-modules is hardly better. 4. I am also concerned about the ease of upgrading the bundled modules, especially CGI.pm and the other CGI:: modules. While I realize they are included in the upstream perl kit, the CGI modules especially are likely to be upgraded at a far greater rate than perl is. Does perl look at the site-perl directory before looking in its normal librarys? ++ | Scott K. Ellis | Argue for your limitations and | | [EMAIL PROTECTED] | sure enough, they're yours. | ||-- Illusions | ++ -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM4ECmdH31Ek1qsc9AQEXogP+OBC6N78YCVZ8i6KVGHFmySuwg/zRuLvS C1RbGL/CyQ9pX8VtjW+uNcJcIHxO+uR1uajG1C/pdPs/ZlmCC+lNXh5X+E+R3Wlb 8txLSdFXEf0IzCXKSzorLsRkHQf4Fwmg3giONRRJGRps1dV82uLedK+TSYvveCHS LRC2ar/+riU= =jT7o -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Kernel-package: Please add the '.config' file in the binary package
Hi, jwalther == jwalther [EMAIL PROTECTED] writes: Are there any objections to moving the file into /boot? jwalther Is there really any reason to take us farther away from the jwalther standard that everyone else uses? Its just one more gotcha jwalther that'll tick a newbie off when they follow their slackware jwalther friends advice, dl the kernel source, and just have at 'er jwalther like it says to in the Kernel HOWTO. Less blather this time. Yes, ther reason is that /boot contains other useful information about the kernels ensconced there, (like System.map, and psdatabase) but is missing one piece: exactly what is configured into the kernel (which can be quite important). I think that a small file is not too great a departure from the standard, and, maybe, this should have been in the standard in the first place. manoj -- People of the same trade seldom meet together, even for merriment or diversion, but the conversation ends in a conspiracy against the public, or some contrivance to raise prices. Adam Smith, _Wealth of Nations_ Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Perl 5.004, perl modules, and binary compatibility
Hi, Well, with 5.004, CGI-modules is obsolete, and so the misnaming of the CGI modules package is a solved issue ;-). (Unless. of course, there is a hew-and-cry about removing the package, I'd suggest removing CGI-modules from hamm). As for the description issue, even the one line description of CGI-modules stated that these were modules for perl 5. By just the name itself, most packages do not specify their purpose (what does perl say, pray?) If the descriptions are remiss, please file a bug report. manoj -- Life sucks, but death doesn't put out at all Thomas J. Kopp Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Perl 5.004, perl modules, and binary compatibility
On 19 May 1997, Manoj Srivastava wrote: Well, with 5.004, CGI-modules is obsolete, and so the misnaming of the CGI modules package is a solved issue ;-). (Unless. of course, there is a hew-and-cry about removing the package, I'd suggest removing CGI-modules from hamm). No real objection here. As I stated earlier, I'm concerned about such a potentially fast moving target being included in perl, but I guess the perl-porters got sick of answering questions about finding modules for CGI programming. As for the description issue, even the one line description of CGI-modules stated that these were modules for perl 5. By just the name itself, most packages do not specify their purpose (what does perl say, pray?) My main concern is that they neither bunch up on the dpkg select screen, nor is it easy to search for perl modules in dselect (I'd like to be able to find all the perl modules by searching on perl). If the descriptions are remiss, please file a bug report. Is a misnamed package a bug? I'd like to give this more thought (and solicit more comments) before rocking that boat. ++ | Scott K. Ellis | Argue for your limitations and | | [EMAIL PROTECTED] | sure enough, they're yours. | ||-- Illusions | ++ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Kernel-package: Please add the '.config' file in the binary package
On 19 May 1997, Manoj Srivastava wrote: Less blather this time. Yes, ther reason is that /boot contains other useful information about the kernels ensconced there, (like System.map, and psdatabase) but is missing one piece: exactly what is configured into the kernel (which can be quite important). You are right. No further obs from me. Just, let it be symlinked to /usr/src/linux/.config too, ok? =) I think that a small file is not too great a departure from the standard, and, maybe, this should have been in the standard in the first place. Again, you are right. From what I hear, bsd lets you configure the kernel at boot time... this is the least that we can do. SirDibos -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
smail bug? FQND not in proper format
Basically, mailx conflicts with smail. dpkg: error processing xmysql (--configure): dependency problems - leaving unconfigured Setting up smail (3.2-3) ... Error: system's FQDN hostname (citytel_prct40.citytel.net) doesn't match RFC1035 syntax; cannot configure the mail system. dpkg: error processing smail (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of at: at depends on mail-transport-agent | smail | mailx; however: Package mail-transport-agent is not installed. Package smail which provides mail-transport-agent is not configured yet. Package smail is not configured yet. Package mailx is not installed. dpkg: error processing at (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: modutils timezones xmysql smail at -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Where is the mysql package?
Im sure there used to be a mysql package. the mysql db libs are in, and xmysql front end is in the distro where the fundamental package? is it being worked on? Im positive I installed it ages ago... foolish me for uninstalling it, now its not there anymore. Is there any reason that snarf package is obsolete? I love that program, I use it to snarf lots of stuff when I cant be bothered to fire up ncftp, or when a webpage is involved and Im too lazy to boot X. If it needs a maintainer, I volunteer. If its been superseded by something better.. what? SirDibos -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White [EMAIL PROTECTED]
This document was last modified at Time-stamp: 97/05/12 19:04:03 bcwhite
*** ***
*** Release of Bo is HOLDING for CRITICAL BUGS!***
*** ***
*** There is one remaining critical bug that must be resolved before ***
*** Debian 1.3 can be released. That bug is #9020: ***
*** ***
*** fsck.ext2: can't load library 'libcom_err.so.2' ***
*** ***
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or ??? if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made stable. A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release. A
space means that the task has been completed.
Footnotes are indicated by [n] and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk *), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release or removing that package from the distribution because
they are not fixed.
Upcoming Dates
~~
May 12, 1997Bo will be released
July 1, 1997Bugs older than 6 months will be marked as overdue (will be at
least 9 months old by the time Hamm is released).
Thoughts
---
Bo (Debian 1.3)
~~~
* Fix 1 remaining release critical bugs ([EMAIL PROTECTED])
- Fix 63 remaining overdue bugs ([EMAIL PROTECTED])
Shadow password support ([EMAIL PROTECTED])
- Shared libraries should provide .shlibs files ([EMAIL PROTECTED])
- Appropriate pkgs should call install-mime in postinst ([EMAIL PROTECTED])
- Convert remaining a.out packages (???)
Boot disks should contain drivers for more systems/cards (???)
Integration of modules, kernel, boot-floppies, pcmcia (???) [1]
Include the multi-thread support patch for the Objective-C runtime lib (???)
Fix packages that break with new libc5.4
- Fix installed size entries in packages ([EMAIL PROTECTED])
- Improvements to 'dselect' ([EMAIL PROTECTED],[EMAIL PROTECTED]) [2]
Move all shared libraries into libs ([EMAIL PROTECTED]) [4]
Move interpreters out of devel ([EMAIL PROTECTED]) [4]
Add support for resolutions beyond 1280x1024 to X config utility (???) [5]
- Package grouping to simplify install ([EMAIL PROTECTED],[EMAIL PROTECTED])
general threading policy (???) [6]
Fix pkgs referencing /etc/site-start.el([EMAIL PROTECTED])[7]
- configuring so non-ASCII characters work (???) [9]
Base packages to be in new source format
- Make all web servers apply to /usr/doc/debmake/webstandard-3.0
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call update-menu in postinst ([EMAIL PROTECTED]) [11]
Hamm
* All packages are in the new package format.
* All base packages are compiled with libc6.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...).
* No a.out executables anymore.
* Much improved dpkg/dselect.
- Move config information from install scripts to cfgtool (???)
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
---
Footnotes
~
1 - Friday I used the boot floppies in the rex tree and I could load any
modules (NFS being the show stopper). In the Linux Journal review of
Debian (Nov Issue), explictly mentions this problem with 1.1 and it
hasn't been solved yet :( -- Chris Fearnley [EMAIL PROTECTED]
3 - I.e.: say I just want to install a package for a single library-- but I
also want the developer version and the static version... As it stands, I
can either su to
Unresolved Critical Bugs
9020: e2fsprogs- fsck.ext2: can't load library 'libcom_err.so.2' 9127: seyon- seyon depends on X11R6 instead of xlib6 9256: vrweb- Unresolved dependency report for vrweb 9258: sgml-tools - Unresolved dependency report for sgml-tools 9259: j1 - Unresolved dependency report for j1 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
Brian == Brian Mays [EMAIL PROTECTED] writes:
Brian rxvt (and rxvt-xpm) always exports the variable COLORTERM
Brian so that programs can check for color support.
John == John Goerzen [EMAIL PROTECTED] writes:
John Unfortunately, I know of no programs that make use of this
John variable. In fact, I believe that ncurses doesn't even use
John it.
The rxvt authors claim that programs such as JED, slrn, Midnight
Commander check this variable. I don't know since I don't use any of
these applications.
Brian As a side note, when XPM support has been compiled into
Brian rxvt (as with rxvt-xpm supplied in Debian's rxvt package),
Brian the value of COLORTERM is set to rxvt-xpm instead of
Brian rxvt.
John Which could be a bug in itself since Debian has no rxvt-xmp
John terminfo entry.
This is not a problem since ncurses uses the TERM variable and not the
COLORTERM variable.
John I would suggest that rxvt set TERM to rxvt when on a color
John display and to xterm when on a non-color display. The rxvt
John entry in terminfo already has color support; the xterm entry
John is monochrome. Since rxvt is backwards-compatible with
John xterm, this would seem to be the proper method. It would
John cause the least fuss while ensuring proper behavior in all
John situations.
John Even if this isn't done, I suggest that the default be set
John to rxvt. After all, we have the terminfo entry for it, it
John doesn't make any sense not to use it.
Observe the difference between the rxvt entry and the xterm-color
entry:
$ infocmp rxvt xterm-color
comparing rxvt to xterm-color.
comparing booleans.
comparing numbers.
comparing strings.
kend: '\EOw', '\EOe'.
khome: '\E[H', '\EO\200'.
kmous: NULL, '\E[M'.
Other than the home key, the end key, and X11 mouse support, there are
no differences between the two entries. Therefore, unless we really
care about these three features, using TERM=xterm-color is good
enough.
I think that we have two choices:
1) Strive to be totally correct:
Convince the ncurses maintainer to provide two rxvt terminfo entries:
one with color capabilities defined and one without color capability.
The rxvt program will set the TERM variable to the appropriate entry
according to the color depth of the X display.
2) Strive for compatibility:
Not all Unices have an rxvt terminfo entry. The RS6000 and SGI
machines on which I have accounts do not have an rxvt entry or an
xterm-color entry. Thus when I rlogin onto these machines from an
rxvt window, the terminal capabilities will default to those of a
dumb terminal because TERM=rxvt and TERM=xterm-color are unknown
terminal types to them.
With this mind, rxvt will set the TERM variable to xterm or
xterm-color depending on the color depth of the X display. This is
the default behavior of rxvt provided by the upstream maintainers,
so it should be consistent with rxvt version compiled on non-Debian
Unices.
Users who insist on using the rxvt terminfo entry can monitor the
COLORTERM variable. For example, they can place the following in
their .profile file:
TERM=${COLORTERM:-$TERM}
What I want to avoid is TERM=rxvt on color displays and TERM=xterm on
mono displays. I can see this leading to bug reports when the HOME
and END keys work on color displays but fail to behave the same way on
mono displays. For consistency sake, these keys should either always
work or always not work.
John I suspect that rxvt would behave properly in this case even
John if it is on a 1-bit (BW) display.
The problem is not whether rxvt does the right thing, we need to
ensure that the programs running in an rxvt terminal do the right
thing. This means that when rxvt's window is located on a monochrome
display, the programs running on that window should know that they are
on a terminal that does not have the capability to display colors.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
This is why changing the default prompt for everyone is not a good idea. You guys can't even agree on what you want the new prompt to be. And if you want my personal preference, any prompt longer than '$ ' is too long. If I want to know what directory I'm in, I just pwd. Instead of arguing back and forth about this new prompt, please do something constructive. Build a Debian 4 dummies package, which includes your favorite prompt along with all of the other nice defaults that you wish to include. Add a sentence in the package's description that says If you are new to Debian or Linux, this package comes HIGHLY RECOMMENDED. Of course, there will be some technical details with the implementation of this package that will need to be ironed out, such as how to get PS='your favorite prompt' into /etc/profile, but I'm sure that these will be minor. If you want to get fancy, you can also add to this package some useful scripts for configuring a Debian system that no Unix real man would need or want. I believe that the newbie-friendly defaults should be collected in one place and not scattered across many Debian packages. If they are in one package (or a small number of packages), it will be easier for us to define what the Debian newbie-friendly environment is and to plan what we want it to become. I especially believe that these defaults should be optional. Remember, the user should configure her system, not deconfigure it. If she must spend time and effort to rid her system of somebody else's nifty configuration, then IMO we're doing it wrong. Brian -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
Nicolás Lichtmaier [EMAIL PROTECTED] writes: Most people that adopt Linux come from DOS. Linux is expanding the UNIX users base. I come from DOS-OS/2 too. I used Slackware, and I changed because it was a mess. Current newbies that start with RH won't change to Debian, they don't need to. And those newbies learn, become `RH-gurus' and sit quietly at home waiting for a commercial corporation to handle their OS =). I also think that we should try to aim to the bigger amount of targets that we can... So I say: PS1=[\\u] \\h:\\w\\$ =D I agree with most of what you are saying; however, I think you sorta missed the point I was trying to make (which is probably my fault because I didn't make it very clearly g) My problem is not so much with changing root's default prompt on new installations; I have changed the default on my machines anyway. My problem is with going in and changing accepted Unix standards solely to be more friendly to beginners that aren't paying attention to what they are doing. IMHO, people that aren't paying attention before typing a rm -rf * don't have any business running Unix in the first place. Anybody should know that before typing rm -rf * or an equivolent, you THINK FIRST, every time. -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
The difference is that RedHat's X configurator configures not only X, but also mail, news, printers, networking, etc. It's a configurator that runs under X -- not really a configurator for XFree86. If we are wanting to go that way; fine. I have no problem with it. As long as we don't go so far as RedHat and make the X configurator the *only* configuration aide in the system. I hate the choice of either having to boot to X or find configs by hand. Mark Eichin [EMAIL PROTECTED] writes: If we want to be friendly to newbies, we can write an X configurator like RedHat; but I don't think that's what we want. I've heard rumors of this, but not seen it -- how does it differ from XF86Setup (not xf86config, which is probably what the debian old-timers think of, but the new tk-based config tool that comes with xfree86 3.2?) And what's is license? Any reason we can't bpackage it too, at least as an option? _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian X Maintainer -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
Anybody should know that before typing rm -rf * or an equivolent, you THINK FIRST, every time. The problem does not arise when you type rm the first time but after you have some confidence and you think you know what you are doing. Everybody knows what you should think first. But who does after getting used to it? --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
Oh, I see. Nevermind then -- what you're saying is that the X configurator is at the level of an X based dselect -- so that's the problem of the diety team, right? (Thus it's not something I need to be particularly concerned with.) Thanks... _Mark_ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
*** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
Hi, 2. I installed shadowing as it suggested - started installing packages merrily. I also installed and configured NIS - however, I cannot log in any in my personal account - though I can finger anyone without trouble. I deinstalled shadow by doing a shadowconfig off and that still didn't fix the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). I have got a similiar problem but have not yet got the time to look at it closely. I can log in at the text console but but at the xdm login screen. I don't have NIS installed but shadowed passwords. Cheers, Thomas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
At 09:26 AM 19/05/97 +0100, Philip Hands wrote: 2. I installed shadowing as it suggested - started installing packages merrily. I also installed and configured NIS - however, I cannot log in any in my personal account - though I can finger anyone without trouble. I deinstalled shadow by doing a shadowconfig off and that still didn't fix the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). Can you use any yp commands ? For instance does this work: ypcat passwd I can use them, but I get the standard stuff (it's a NIS slave server) locally and no user details. /usr/lib/yp/ypinit -s servername gives a whole lot of errors as well. -- Karl Ferguson, Tower Networking Pty LtdTel: +61-8-9456-[EMAIL PROTECTED] t/a STAR Online ServicesFax: +61-8-9455-2776[EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
Anybody should know that before typing rm -rf * or an equivalent, you THINK FIRST, every time. And AFTER you type it. The prompt doesn't make the slightest difference when the death knell sounds: rm: .o: No such file or directory and it dawns on you there was an extra space in the last thing you typed: rm -f * .o Argh! At least GNU rm won't do what a version of Xenix (running on a 80186 :) did to me once. In response to an attempt to to get rid of my personal defaults: # cd /home/phil # rm -rf .* It recursed upwards (..) and killed everything under /home Unix, World of Adventure --- The trick is to keep your backups up to date. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report.
Hi, 2. I installed shadowing as it suggested - started installing packages merrily. I also installed and configured NIS - however, I cannot log in any in my personal account - though I can finger anyone without trouble. I deinstalled shadow by doing a shadowconfig off and that still didn't fix the problem. I'm not sure what to put this down to, any suggestions? (I can log in as root via ssh fine). I have got a similiar problem but have not yet got the time to look at it closely. I can log in at the text console but but at the xdm login screen. I don't have NIS installed but shadowed passwords. Presumably, you installed xdm after installing shadow. shadowconfig edits /etc/init.d/xdm to switch between using xdm and xdm-shadow, so all you need to do is: shadowconfig off shadowconfig on and all should be well. Cheers, Phil. P.S. I have a feeling the NIS problem appears under 2.0.30 kernels and downgrading to 2.0.29 should fix it --- don't know why though. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
In your email to me, Christoph, you wrote: *** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. FWIW, I agree. I haven't seen anyone on the testing list report this problem, and I never saw it across roughlt 15 upgrades I've done. I think this is a dead issue... Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps The courage to imagine the otherwise is our greatest resource, adding color and suspense to all our life. - Daniel J. Boorstin ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Kernel-package: Please add the '.config' file in the binary package
On Mon, 19 May 1997 [EMAIL PROTECTED] wrote: On 19 May 1997, Manoj Srivastava wrote: Less blather this time. Yes, ther reason is that /boot contains other useful information about the kernels ensconced there, (like System.map, and psdatabase) but is missing one piece: exactly what is configured into the kernel (which can be quite important). You are right. No further obs from me. Just, let it be symlinked to /usr/src/linux/.config too, ok? =) I agree with the basic concept but shouldn't this be placed in /etc instead of /boot. /etc defines the configuration for the host after all. -- Jean Pierre -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Perl 5.004, perl modules, and binary compatibility
Scott K. Ellis [EMAIL PROTECTED] writes: My main concern is that they neither bunch up on the dpkg select screen, nor is it easy to search for perl modules in dselect (I'd like to be able to find all the perl modules by searching on perl). BTW, I maintain alias and www-search (and libwww-perl and mailtools and, heck, I think that may mean I maintain all the perl module packages now that it looks like CGI-modules is going away), and I do agree with some of your comments. At the same time, though, those names do have a certain meaning for people who are aware of them outside of debian, and thus one should be very wary of renaming someone else's module. At the same time, Graham Barr suggested to me that I rename libnet to be libnet-perl, since there was a C library by the same name. Of course, he also told me he was thinking about renaming the upstream package, and has not yet done so---in large part because of the name recognition---he's just now got people to stop looking for the separate Net:: modules. This was, of course, after Graham admitted that he hadn't been aware that they'd been packaged for Debian, which is doubly amusing, since that's what he uses. Mike. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On 19 May 1997, John Goerzen wrote: I agree with most of what you are saying; however, I think you sorta missed the point I was trying to make (which is probably my fault because I didn't make it very clearly g) =) My problem is not so much with changing root's default prompt on new installations; I have changed the default on my machines anyway. My problem is with going in and changing accepted Unix standards solely to be more friendly to beginners that aren't paying attention to what they are doing. IMHO, people that aren't paying attention before typing a rm -rf * don't have any business running Unix in the first place. Anybody should know that before typing rm -rf * or an equivolent, you THINK FIRST, every time. Of course..! I'm not saying that we should add a `Are you sure?' prompt.. =) However, we should be careful to choose _useful_ `accepted UNIX' standards. eg: the prompt $ is the standard. /bin/ash is much more standard than bash. -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On May 19, Nicolás Lichtmaier wrote On Mon, 19 May 1997, Christoph Lameter wrote: So I say: PS1=[\\u] \\h:\\w\\$ =D Too long. But better than nothing. It isn't too long...! [nick] newton:~/src/deb/lftp-0.11.1$ [nick] newton:~/src/deb/lftp-0.11.1$ [nick] newton:~/src/deb/lftp-0.11.1$ ls Or the other version: [EMAIL PROTECTED]:~/src/deb/lftp-0.11.1$ [EMAIL PROTECTED]:~/src/deb/lftp-0.11.1$ [EMAIL PROTECTED]:~/src/deb/lftp-0.11.1$ _ Note that the first is much more readable...! but it can also be : [EMAIL PROTECTED]:~/isdn/update/isdnutils-2.0.1/tools/isdnlog/contrib/xisdnload$ [EMAIL PROTECTED]:~/isdn/update/isdnutils-2.0.1/tools/isdnbutton/sample/sample2/etc/rc.d/init.d$ you see : its not a very good one... (these prompts are not constructed ! they are reality, and everytiem i have such a long prompt, i hate my prompt) regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Kernel-package: Please add the '.config' file in the binary package
Hi, Jean == Jean Pierre LeJacq [EMAIL PROTECTED] writes: Jean I agree with the basic concept but shouldn't this be placed in Jean /etc instead of /boot. /etc defines the configuration for the Jean host after all. The config file, which shall reside in the kernel-image package, is really useless unless one has the kernel sources, so arguably this is not a config file any more, but a description of the kernel image itself (coming closer to the psdatabase file itself). I expect files under /etc to be modifiable by the site admin, and if they are so modified, have some affect on the system. One may modify the config file till one is blue in the face with no affect whatsoever on the system or any program being run ;-). manoj -- Democracy is also a form of worship. It is the worship of Jackals by Jackasses. Mencken Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Unresolved Critical Bugs
On May 19, Brian C. White wrote 9259: j1 - Unresolved dependency report for j1 A fixed version of j1 is sitting in ~moth on master.debian.org and has been since last week. When I uploaded it, Incoming was not writeable, so I uploaded a copy to my home directory and sent email to Brian. As I received no response to that email, I presume that I sent it to an inactive address. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On Mon, 19 May 1997, Brian Mays wrote: This is why changing the default prompt for everyone is not a good idea. You guys can't even agree on what you want the new prompt to be. And if you want my personal preference, any prompt longer than '$ ' is too long. If I want to know what directory I'm in, I just pwd. Instead of arguing back and forth about this new prompt, please do something constructive. Build a Debian 4 dummies package, which includes your favorite prompt along with all of the other nice defaults that you wish to include. Add a sentence in the package's description that says If you are new to Debian or Linux, this package comes HIGHLY RECOMMENDED. Of course, there will be some technical details with the implementation of this package that will need to be ironed out, such as how to get PS='your favorite prompt' into /etc/profile, but I'm sure that these will be minor. If you want to get fancy, you can also add to this package some useful scripts for configuring a Debian system that no Unix real man would need or want. I believe that the newbie-friendly defaults should be collected in one place and not scattered across many Debian packages. If they are in one package (or a small number of packages), it will be easier for us to define what the Debian newbie-friendly environment is and to plan what we want it to become. I especially believe that these defaults should be optional. Remember, the user should configure her system, not deconfigure it. If she must spend time and effort to rid her system of somebody else's nifty configuration, then IMO we're doing it wrong. I think that this is the kind of thinking that is killing Debian. 1) Newbie setting doesn't mean annoying settings. 2) `real men' like you can change those settings. 3) Configuration packages is an awful idea that goes against the idea of package. A better solution would be a system setting that packages would check an install the apropiate default. 4) We aren't building a distribution only for us. Let's stop being so narrow minded... We need a little of marketing... We need to be known as an easy distribution for newbies... -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
On Tue, 20 May 1997, Nicolás Lichtmaier wrote: I think that this is the kind of thinking that is killing Debian. 1) Newbie setting doesn't mean annoying settings. 2) `real men' like you can change those settings. 3) Configuration packages is an awful idea that goes against the idea of package. A better solution would be a system setting that packages would check an install the apropiate default. 4) We aren't building a distribution only for us. Let's stop being so narrow minded... We need a little of marketing... We need to be known as an easy distribution for newbies... The problem with that approach is that many of those newbie settings are just a matter of taste. We don't want to set a thousand of those parameters in hundreths of different config files that will have to be edited to reset them. It would be easier if all those parameters could be grouped in a single config package. We may have a handful of those to choose (hint: themes). It may even be useful for localization! I don't see the reason why you don't like the idea of Config packages. Can you elaborate a little more on that, please? -- Enrique Zanardi[EMAIL PROTECTED] Dpto. Fisica Fundamental y Experimental Univ. de La Laguna -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
*** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. The bug is still open. This is a potentially serious problem. Brian ( [EMAIL PROTECTED] ) --- You can never be too good looking or too well equipped. -- Dilbert -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: install to umsdos root?
In article [EMAIL PROTECTED],
Adrian Bridgett [EMAIL PROTECTED] wrote:
I think that it would be a good idea to allow users to install to a UMSDOS
partition. I am sure there are a lot of people who would quite like to try
out Linux, but are frightened of the install process.
Imagine a future issue of PCW magazine with Debian on the cover CD. People
could try Linux without repartitioning their hard disks, and fewer would
trash their computers by installing LILO and then getting confused.
This would make a trial use similar to installing a game demo - but
probably use up less disk space :-)
Any thoughts?
I agree, however, there are some problems (apart from the poor
performance and disk space taken up by symlinks):
The UMSDOS Kernel stuff has bugs in it:
a) The pseudo-root hack (effectively) does a chroot. When it comes to
{u,re}mount the root fs (during [re]boot), the system call fails
with bad arguments. There is an quick hack to fs/super.c which
fixes this but it is probably too disgusting to be added to the
kernel source.
Another possible way of fixing UMSDOS would be re-write it (!) to
munge the superblock to get pseudo-root functionality instead; most
of the re-write would involve redoing (or removing) the /DOS code
to work with this change. Munging the superblock works for ext2 (I
tried it) but may not work for umsdos (I haven't tried it).
It is possible to hack round this problem in /etc/init.d/[re]boot
(just don't do the remounts), this would preclude fsck.umsdos (see
below) as it would need a read-only fs to work on.
b) A mangled DOS fs can kill the UMSDOS fs code when mounted as umsdos.
I even have a .zip for the interested; any process that scans a
certain directory is killed with SEGV. The mess was created when
dpkg died during an attempted install. Cause unknown.
c) rmdir on a busy file gives the wrong error value (and dpkg fails to
upgrade libc as a result). The UMSDOS author has a patch for this,
I should check to see if it has gone into 2.0.30.
d) There are documented (in the source code, where else :-) problems
with umsdos and hard links. These should not occur often but should
be tidied by fsck.umsdos. Ideally, UMSDOS should have its hard
links done in a way that works better (hard).
e) Under certain circumstances (dpkg -i ...ncurses-term...) a link
system call never returns. This is not funny; it occurs by default
during the first dselect session. Cause unknown.
The user-level UMSDOS stuff is rather lacking.
f) There is no fsck.umsdos. The functionality is mostly there with
dosfsck and umssync but it needs to be put together.
g) I don't think umssync clears up lost hard links.
I've been working on the boot-floppies package to allow UMSDOS install
to pseudo root on and off for some time now. The kernel problems
(particularly those that appear with the use of dpkg) need to be
remedied before anything else is done.
Sorry to sound so pessimistic about all this. However, if it became an
'official' aim of Debian to get UMSDOS Debian working, Jaques Gelinas
(umsdos maintainer) might be prepared to expend some effort into
getting things fixed. I don't think anyone else is interested.
On the other hand, someone may come up with a better solution than
UMSDOS, stranger things have happened.
Giuliano
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . Trouble?
e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
Hi, [This may well be orthogonal, or in addition to, the solutions discussed] Maybe we could offer some example of tips and tricks? My preffered prompt mechanism sets the xterm title to (like right now) [EMAIL PROTECTED]:~/var/tmp with a short prompt of '__ ', or the above becomes my prompt on a non-xterm. I limit the size of the dir string to 25 characters (a perl script run by my cd alias that chops leading dir components untill there is just one left, or the length requirement is satisfied). Some people seem to like this sort of a thing, and this maybe hard for a neophyte to set up. I'm sure that this forum can come up with scads of such ``real men'' examples (sorry, sue and susan) manoj -- The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay. Arthur Miller Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Have a look at the bug report. I dont know why no one has marked it as done yet. There is a file lists in the but report ending in .dpkg-tmp evidently from a crash. Dont be buerocratic about releasing 1.3. On Tue, 20 May 1997, Brian White wrote: *** *** *** Release of Bo is HOLDING for CRITICAL BUGS!*** *** *** *** There is one remaining critical bug that must be resolved before *** *** Debian 1.3 can be released. That bug is #9020: *** *** *** *** fsck.ext2: can't load library 'libcom_err.so.2' *** *** *** I have done a couple of upgrades to 1.3 and have never noticed there being a problem exept in one instance where the e2prog package was not configured due to a crash while upgrading (watchdog shutdown ...) And v 1.06 is history anyways get 1.3 released. The bug is still open. This is a potentially serious problem. Brian ( [EMAIL PROTECTED] ) --- You can never be too good looking or too well equipped. -- Dilbert --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
stumped with source package problem
Does anyone know what this error message indicates? [EMAIL PROTECTED] ~/debian/build/tmpdpkg-source -x xkobo_1.9-3.dsc dpkg-source: extracting xkobo in xkobo-1.9 patch: .dpkg-orig is not a regular file--can't patch dpkg-source: failure: patch gave error exit status 2 I can extract the sources fine by hand. I tried rebuilding the source package with dpkg-buildpackage -tc -sa and I still get the error message. -- See shy Jo. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
On Tue, 20 May 1997, Enrique Zanardi wrote: On Tue, 20 May 1997, Nicolás Lichtmaier wrote: I think that this is the kind of thinking that is killing Debian. 1) Newbie setting doesn't mean annoying settings. 2) `real men' like you can change those settings. 3) Configuration packages is an awful idea that goes against the idea of package. A better solution would be a system setting that packages would check an install the apropiate default. 4) We aren't building a distribution only for us. Let's stop being so narrow minded... We need a little of marketing... We need to be known as an easy distribution for newbies... The problem with that approach is that many of those newbie settings are just a matter of taste. We don't want to set a thousand of those parameters in hundreths of different config files that will have to be edited to reset them. Of course it's a matter of taste. But leaving everything unconfigured it's also a matter of (bad) taste. And the settings should be simple... I wouldn't recommend setting a 2-line prompt with date and ANSI codes as a default, even if I used that... It would be easier if all those parameters could be grouped in a single config package. We may have a handful of those to choose (hint: themes). It may even be useful for localization! I don't see the reason why you don't like the idea of Config packages. Can you elaborate a little more on that, please? Perhaps we need to define better what are we talking about. I see a `config package' as a package that includes/modifies other packages conffiles. Using packages for this is ignoring the concept of a package. What if you remove one of these packages? What if some programs whose files are modified are not installed? What if one of these programs is installed _after_ the config-package? Should the config-package depend on every progam it configures? config-packages will depend on changes in several packages... Maybe this requires something orthogonal to the package system. `Themes' are possible in Windows because they have a central database for settings. My opinion is: One of the main adtvantages of having a distribution is that you get configured packages, so let's to provide a great/useful/nice/easy configuration. I'd like to have LESSOPEN configured for me when I install a distribution. -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
EZ == Enrique Zanardi [EMAIL PROTECTED] writes:
EZ: The problem with that approach is that many of those newbie
EZ: settings are just a matter of taste. We don't want to set a
EZ: thousand of those parameters in hundreths of different config
EZ: files that will have to be edited to reset them.
EZ: It would be easier if all those parameters could be grouped in
EZ: a single config package. We may have a handful of those to
EZ: choose (hint: themes). It may even be useful for
EZ: localization!
1. I don't know whether I like the idea of a single config package or not
but I can see the following questions:
- Is it easy/possible to maintain single config package for many
programs?
- Isn't it better to let this work to each package maintainer because
he does probably understand it very well? I don't think there
are many (hundreds) packages which need some kind of newbie
customization. If I understand it well it should be about ten to
twenty files in `/etc/skel/'.
- On the other side wouldn't be better to let this configuration
things to one package with one maintainer (newbies manager), who
could watch newbies questions on debian.user etc. so he knows what
the *real* problems are?
2. IMO, there is no problem with settings like bash prompt customized for
newbies, if such settings are not too much annoying for many people
(they shouldn't, it's not good idea to introduce newbies to annoying
things). I think any advanced user copies his .profile, .bash*,
.xinitrc, .fvwm* or whatever soon to his new account on which he
intends to work regularly. So he is almost indifferent to these
settings.
3. BTW, to discussion about long dirs in prompt, why not to use two lines
prompt? I have in .bashrc
MACHINE=$(uname -n)
MACHINE=${MACHINE%%.*}
PS1='
$PWD
$MACHINE$ '
and I'm very satisfied with it.
Milan Zamazal
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
ObjC runtime (was: Upcoming Debian Releases)
Include the multi-thread support patch for the Objective-C runtime lib (???) According to Scott Christley [EMAIL PROTECTED] (de-facto maintainer of the gcc Objective-C runtime), the Objective-C runtime should be kept in sync with the gstep-base included in the release. bo includes gstep-base-0.2.12 and gstep-base-0.2.12 includes a patch file gcc-2.7.2.1-objc.diff, which therefore should be applied to the gcc in bo (the patch applies fine to gcc-2.7.2.2). The remaining question the thread model to be enabled in the patched objc runtime. The patched runtime can be compiled for e.g. PCthreads, LinuxThreads or no threads at all. Who is to decide this ? Gregor -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
On Mon, 19 May 1997, Mark W. Eichin wrote: Is there a web page or other document that explains what our strategy for libc6 is? I'm not talking about random comments on the list, I mean something nailed down that I can refer to... In particular, I've got a few issues to work out. 1) libgdbm -- libc6 includes libdb, and therefore gdbm is supposed to be unnecessary. If this is true, it needs to be written down, so I can point people at it -- otherwise, I need a strategy for renaming the package (since there needs to be a libgdbm.so for libc5 and a seperate one for libc6... the former isn't changing, obviously; how do we change the latter so that -lgdbm still works for users building against it? [since db can't read gdbm files, that *will* continue to happen.]) The general policy is that libc5 stuff should go in /usr/i486-linuxlibc1/lib. So that's where you put all the stuff compiled against libc5. 2) X -- a full release of X requires tk41-dev to build XF86Setup (it uses the static lib, so the end-user doesn't need it.) But tk41-dev probably won't be available for libc6 until I release X. Ooops :-) I can hand-release xlib6-dev by itself, (into experimental, perhaps?) so that someone can build the tk packages... or I can build that particular lib by hand until then (but then would still have to leave X in experimental unless I took over the package, eww.) And what *do* I name things? I'd guess that xlib6 is untouched, the version built with libc6 gets called xlib6-libc6 (eww), I release an No. xlib6 should be for libc6 (more long-term solution). Then create an xlib6-libc5. How we handle the dependencies for this, I don't know. Fix for all packages which require libc5 still, and recompile those which can work with libc6 would be the best idea. alt-xlib6-dev that replaces and provides xlib6-dev (which alt-libc5 doesn't?) and then xlib6-dev can be the new version? Am I missing anything? No, alt-xlib6-dev should _NOT_ conflict/replace/provide xlib6-dev. It should install into /usr/i486-linuxlibc1/..., or something (maybe /usr/X11R6/i486-linuxlibc1), and it should co-exist with xlib6-dev. ld.so can work out which to use. 3) can I drop the a.out-only dlltools package now? :-) No. It is needed to build a.out versions of, e.g. svgalib. Some older binary-only programs only come in a.out format (Doom, for example) :(. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Perl 5.004, perl modules, and binary compatibility
-BEGIN PGP SIGNED MESSAGE- Scott Ellis, in an immanent manifestation of deity, wrote: As the official version of perl 5.004 is finally out (I must admit I haven't installed the debian package yet, but I run webservers with lots of perl CGI and can't afford to break them), I have a few questions, comments, and thoughts. Admittedly, I only have perl 5.004 on my two development machines. I can't afford to install 5.004 on my production machines since they still run majordomo 1.94.1 which has a bug that's tickled by 5.004. 1. In building my own perl kit for other machines I maintain, I noticed the option to maintain binary module compatibility with 5.003 at the expense of a poluted namespace. I assume this option was chosen for the debian package. Definitely. I'm not interested in getting lynched right now... 2. I also assume that perl being compiled for glibc is going to end up being a flag day for all the binary compiled perl modules. May I suggest that that would be the ideal time to compile perl with a clean namespace. Perhaps upload such a version of perl into experimental to allow the perl Actually, since debian packages that provide modules go into versioned namespace, it's not as bad as that. Choosing then to go to a cleaner namespace sounds like a fine idea. BTW, perl will become perl5 and provide perl if no one objects too strongly. Brian White should like this since he asked for it a while back. The upgrade to libc6 for perl can't happen until there is a libgdbm compatible with it though since I refuse to break everyone's dbm interfaces. I'll also be able to release a libperl.so package with a cleaner namespace then. 3. I also think that any package that provides a perl module should be labled as such in its package name. Package names like www-search and alias hardly suggest that this is a perl module I'd like to install. CGI-modules is hardly better. I don't think so. This might be a good place for the bundling concept someone proposed a while back for dselect. The namespace is limited and shouldn't be cluttered with stuff that's easily readable in the description. This would be similar to calling tix, tcltk-tix. I'd have no idea other than reading the description that it's for tcl/tk... 4. I am also concerned about the ease of upgrading the bundled modules, especially CGI.pm and the other CGI:: modules. While I realize they are included in the upstream perl kit, the CGI modules especially are likely to be upgraded at a far greater rate than perl is. Does perl look at the site-perl directory before looking in its normal librarys? Yes, I expect that CGI and friends will be replaced at a quicker rate. I'll put Replaces: cgi-modules and Provides: cgi-modules in the perl package and cgi-modules can put Provides: perl in it's package. No, Perl doesn't search the site_perl directories first. You can find this out by type perl -V. This is so that multiple versions can be installed. (Important for when I start releasing the experimental packages.) This won't be a problem if cgi-modules is released as a package since it will simply overwrite the files. CGI.pm is now set up so that when you do a make install it will put it in the proper place so that the newest version will be run... Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Do you have your clothes on? I probably don't. Take yours off. Feel better. @ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI programmer and tutor. @ -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM4H5Do4wrq++1Ls5AQEbiwQAitdXJ4tTELTDeqDcSDe+raYLMDrkjl0U VADXU1TDTHKpumAG95BoVoJh+ufwnYf104XLTjgmn/0Gykom4XLPAtDovIishZ9n wj8NeihTaFS/rSgl6lVOjiDUjkjNWpzxMWm7m64Jk86OYtJHM91DGuye/2PM8GLh U0xshS3Jb3o= =YEPC -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
On Tue, 20 May 1997, Tom Lees wrote: 3) can I drop the a.out-only dlltools package now? :-) No. It is needed to build a.out versions of, e.g. svgalib. Some older binary-only programs only come in a.out format (Doom, for example) :(. Yes, it can be dropped _(; 1/ Doom comes without any source, so dlltools won't be of any use. 2/ The a.out version of the dynamic loader is not supported any more. 3/ the libc4[-dev] packages are not maintained any more. 4/ We don't provide aout-gcc anymore[1], so tools any tools related to a.out develpment are useless. Let's face it: a.out is DEAD. Debian still support a.out executables _execution_ but not a.out _development_ anymore... Cordialement, 1: gcc (2.7.2.1-6) unstable; urgency=low * No longer builds aout-gcc -- Galen Hazelwood [EMAIL PROTECTED] Mon, 3 Mar 1997 11:10:20 -0700 -- - ** Linux ** +---+ ** WAW ** - - [EMAIL PROTECTED] | RENARDIAS Vincent | [EMAIL PROTECTED] - - Debian/GNU Linux +---+ http://www.waw.com/ - - http://www.debian.org/ |WAW (33) 4 91 81 21 45 - --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Perl 5.004, perl modules, and binary compatibility
this since he asked for it a while back. The upgrade to libc6 for perl can't happen until there is a libgdbm compatible with it though since I refuse to break everyone's dbm interfaces. I'll also be able to release Great - as soon as I get some consensus on package naming, I'll try to put one out (this weekend, probably?) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
No. xlib6 should be for libc6 (more long-term solution). Then create an xlib6-libc5. How we handle the dependencies for this, I don't know. Fix But then anyone upgrading xlib6 (the 6 for x11r6, not libc6!) will end up with a libc6 version; Is that what we want to happen? alt-xlib6-dev that replaces and provides xlib6-dev (which alt-libc5 No, alt-xlib6-dev should _NOT_ conflict/replace/provide xlib6-dev. It God, these names are awful. I'm not sure I have any idea what you meant by that :-) So given the choices of: a) normal-paths libc5-xlib-dev b) alt-paths libc5-xlib-dev c) normal-paths libc6-xlib-dev You could install a+b, or b+c, but no other combination? 3) can I drop the a.out-only dlltools package now? :-) No. It is needed to build a.out versions of, e.g. svgalib. Some older binary-only programs only come in a.out format (Doom, for example) :(. Better make that policy then -- since I'm pretty sure I saw no a.out support in debian 2.0 go by earlier... Still, dlltools is up to current standards and as long as they hold, we can assume that anyone using dlltools still has libc5 installed. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
1/ Doom comes without any source, so dlltools won't be of any use. Irrelevant -- *aout-svgalib* is what needs dlltools, not doom itself. Debian still support a.out executables _execution_ but not a.out _development_ anymore... I guess I could believe that as long as the a.out development stuff gets shuffled aside into an obsolete archive -- because the whole point, for some of us, in using debian is having a system we can completely build, and we need a.out dev tools in order to build the libraries that support a.out execution... We can arrange for it all to stagnate but I'd rather see that happen in a formal manner. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ObjC runtime (was: Upcoming Debian Releases)
Gregor Hoffleit [EMAIL PROTECTED] writes: The remaining question the thread model to be enabled in the patched objc runtime. The patched runtime can be compiled for e.g. PCthreads, LinuxThreads or no threads at all. Who is to decide this ? As I understand it, Debian is trying to standardize on LinuxThreads right now, so go with that. Make sure that any libraries (static or shared) provided by the package are compiled with -D_REENTRANT. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
