Re: SLIP not working?
Karl Ferguson writes: Hi Everyone... I've compiled SLIP into the kernel (2.0.10), however I get this following message in /var/log/daemon.log: Aug 1 10:30:49 orion /sliplogin[319]: attaching slip unit sl0 for karl Aug 1 10:30:49 orion /sliplogin[319]: /etc/slip.login sl0 9600 319 203.22.233.3 203.15.138.211 compressed Aug 1 10:30:50 orion modprobe: Can't locate module net-pf-4 Aug 1 10:20:51 orion modprobe: Can't locate module net-pf-5 Of course, slip just doesn't seem to work at all. My question is, where are these modules it can't locate - and if I can find them, will it fix this problem? Any help appreciated. You can edit /etc/mod.conf (from memory) to get rid of those modprobe warnings, but it shouldn't actually affect SLIP working, They are just an alias for particular network procotols I think. I've had those warnings for many kernels and SLIP still works for me (just couldn't be bothered fixing the file, was waiting for some debian thing to do it for me :)) Andrew -- Of course...lager...the only thing that can kill a vindaloo. -- Lister, fighting the vindaloo monster in Red Dwarf `DNA' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: XF86 betas (Re: D68K: The next step...)
In message [EMAIL PROTECTED], Mr Stuart Lamble writes: annoyed that if I want support for my W32p (revision A), I have to go to 3.1.2E - and it's not available for Debian. Net result: either I have proper support for my card, and can't install new X-based packages (dpkg barfs at the postinst and configuration stages), or I'm stuck with the SVGA server. Not at all. Install the svga server using dselect. Put it on hold. Get the 3.1.2E server binary, install it, adjust /etc/X11/config. I'm doing just this to run the current Mach64 card, since my RAMDAC isn't supported by the non-beta 3.1.2. No problems at all. Mike. -- Don't let me make you unhappy by failing to be contrary enough
Re: f2c-960717-0 uploaded to master
Right, I know that lapack-linux website too. Note gcc-2.7.0 and g77-0.5.17 were used, more recent ones are available. g77 got better with 0.5.18, but also slower (according to some very casual measurements I did on one piece of code). Also, Jacob Schiotz doesn't say anything about compiler versions. It would be good if someone had some time to redo these and some others benchmarks. -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
Re: POSIX 1387.2 (package-management)
On Wed, 31 Jul 1996, Dale Scheetz wrote: On Tue, 30 Jul 1996, Michael Gaertner wrote: Ever heard of this standard for unix-package-management? How should we deal with this? How does one get a copy? I can not help you - to get this you have to be a groupmember or you must pay for it. I am curious who in the debian-community had the chance to read this. (So by now you know I had no chance to read it) To point you how to obtain the draft - here are some links: http://stdsbbs.ieee.org/products/NumStat/NumStat11.html http://stdsbbs.ieee.org/products/press/catalog/it.html price: $72.00, 320 Pages ISBN 1-55937-537-X and as I found out there is also a correlated document bei X/Open extending P1387.2: http://xoweb.xopen.co.uk/public/pubs/catalog/p429.htm price: $70, 429 Pages ISBN 1-85912-121-7 I think some sponsors are needed !!! Michael Gaertner [EMAIL PROTECTED] Tel/Fax +49-761-32684
Re: Name clash in prospective package
I think it would be better to change the name of the Mercury Compiler to something like mercc. The reasons are: 1) Minimal disturbance to current debian users. They now use mc to launch Midnight Comander. 2) Seniority (?). Midnight Commander took the name first (within Debian, I don't know which program is older). 3) Compatibility with other Linux distributions. They usually include the Midnight Commander (and they call it mc). 4) Popularity. Midnight Commander is more popular among Linux users than Mercury Compiler. More people in this community use mc to mean the former. 5) Personal preference :-) (This point is questionable, I know). Cheers, Fernando.
Re: Overwriting include files
Mr Stuart Lamble writes: Ok. There is a library available, libelf (currently version 0.5.2), which is required by a program I was idly toying about with (Eli). I'm contemplating packaging up Eli, which would imply packaging up libelf as well. Go ahead and package libelf. It's been on my todo list for a long time, but with my current backlog, I'll probably never get to it. However, libelf comes with a couple of #include files - libelf.h and nlist.h (I think) - which are also included in libc-dev; in the case of libelf.h, this isn't a problem (the two are identical in content), but nlist.h has a couple of things in it that (IIRC) are #if 0'd out. What would be the procedure for saying to dpkg, These files will conflict with those in another package, but it's ok to overwrite them? Or would I have to use a preinst/postrm script to rename them? Shift their location? Something else I haven't thought of? Replaces: is the proper dpkg mechanism for doing this, but please don't use it. Linc5 does not appear to need either nlist.h or libelf.h. Hopefully, H.J. Lu can confirm this. If this is the case, then the headers should probably be removed from libc. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: Quasi-free development tools
In article [EMAIL PROTECTED] Rob Browning [EMAIL PROTECTED] writes: Leland Olds [EMAIL PROTECTED] writes: (Do we have anything the links to motif?) mosaic (NCSA Mosaic) does. I only provided a statically linked version yet. When I package a released version of Mosaic I should create both versions. Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/
Re: Name clash in prospective package
Not completely alone---I'd prefer prompting about /usr/local. Why? Because /usr/local on all our machines here (not just debian) is an nfs-mounted directory, and typically mounted readonly or root-squash so that I know nothing on the client machines is going to be able to diddle with it. Prompting about /usr/local is one of the little things packages could do that make life easier on those of us that try to maintain large numbers of debian machines. Should this be solved by moving all /usr/local dir structure to the postinst prerm scripts and be created there after prompting the installer? Erick
XF86 betas (Re: D68K: The next step...)
llucius wrote: Actually, I've not gotten to The Next Step yet anyway. I finally bit the bullet and downloaded XFree86 (whew!), compiled it, and am now going through all the X related packages. Speaking of X, as a member of the beta team (XFree86), I have access to the source code for the XF86 betas. Would it be worthwhile setting up packages for these in the contrib section? In particular, I'm kind of annoyed that if I want support for my W32p (revision A), I have to go to 3.1.2E - and it's not available for Debian. Net result: either I have proper support for my card, and can't install new X-based packages (dpkg barfs at the postinst and configuration stages), or I'm stuck with the SVGA server. Before you ask - no, I am _not_ going to provide the source code to the betas to the world in general. Nor diffs. (I'm just trying to get 16/24bpp modes going on the cards - and getting nowhere fast, it seems. Oh well, maybe by Feb next year...) -- I'm on a low-fat, high stress diet: coffee and fingernails.
Re: Perl vs Python vs ....
Dan Stromberg wrote: For this reason we decided that Perl would be on our base disks, and that packages could use it (well, the subset that's on the base disks) in their preinst/postrm. Packages which want something else must Depend on it and may only use it in their postinst/prerm. There's clearly a place for a stronger scripting language, despite the argument posed above. It's just very sad that it should be perl. perl really fits into many people's stereotypes of unix as inherently cryptic monster, very neatly. I'm sure C and Assembler fit cryptic too. Just think how much further advanced the computer industry would be if neither of those had ever been invented. (that's sarcasm, by the way) There is no point having a religious war over this; this decision was taken a long time ago and can't be changed now, even if we wanted to. This is rhetoric. It could be changed and you know it. What I mean to say is, I really dislike can't when what's meant is won't. Of course it can be changed. Anything can be changed! What he was saying, and this is obvious to anyone not specifically trying to play with words, was that it was NOT WORTH THE TROUBLE to change even if we wanted to. I daresay that a linux distribution (or the Hurd, or *BSD, or...) that doesn't fall into the perl trap, should have a brighter future. Oh, give it up! Perl is a fine language. Its powerful and is quite easy to write nice clean code with. It's just not _enforced_ that you write nice clean code. It's also very easy to garbage code, but that isn't enforced, either. As for the truth of your comment... Language syntax and symantics have little to do with a language's success; it's how easy it is to write useful programs with. An operating system's success is due primarily to the amount of software available for it. (Don't believe me? Look at MS-Dos!) Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: New virtual package names.
Well, it's been a while, so lets add: imap-client and imap-server to the virtual package names list. Sure thing. I'm not familiar with imap though, so could you give me a description for these to go in the list? On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). What would it be used for? Are there packages that depend on having an editor, or for which it would be appropriate to recommend one (and have any old editor serve the purpose)? If so, no problem... Warwick Warwick Harveyemail: [EMAIL PROTECTED] Department of Computer Sciencephone: +61-3-9287-9171 University of Melbourne fax: +61-3-9348-1184 Parkville, Victoria, AUSTRALIA 3052 web: http://www.cs.mu.OZ.AU/~warwick
sudo_1.4.4-1
-BEGIN PGP SIGNED MESSAGE- Date: 02 Aug 96 09:09 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Michael Meskes [EMAIL PROTECTED] Source: sudo Version: 1.4.4-1 Binary: sudo Architecture: i386 source Description: sudo: Provides limited super user privileges to specific users. Changes: sudo (1.4.4-1): * New upstream version Files: ac1ac335828d5d44b2886d99d2162480 186284 admin - sudo_1.4.4-1.tar.gz 8bea2ce0293df4b36a0011f4e3d38ecd 15695 admin - sudo_1.4.4-1.diff.gz aa42470a2fde50d77a33fe421b7d8f60 53544 admin optional sudo_1.4.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgHF1ipaNcQEtuj1AQFnkwQAt+6mm7vlB8y3WNbLCrwgl8Se8jLX70KI xb2MZr75cp6gnaXPL7x1HTuekVxvgIp8tsvDsUpTWbji+Clx8UYJAvl8TqGAdssK DmHyiAA9x7pp+EzaQN+HH2k+QZMFD26CinGROEvbq5lJuL8K32w0MNQ8FDx/Au3a znW6Ic7jJww= =1YAw -END PGP SIGNATURE- -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Re: Perl vs Python vs ....
I'm sure C and Assembler fit cryptic too. Just think how much further advanced the computer industry would be if neither of those had ever been invented. And how much further would the industry be, if C had been typesafe (or if some other, typesafe language had been used)? The expertise in language design existed at the time, but C didn't have it. There were typesafe languages in the time of C: Pascal, Modula, etc. Where did they go? They didn't go anywhere because they aren't useful in real applications. Have you ever tried to write a dynamic skip-list in pascal? And yet, C was adopted as a major standard - because the people who knew better, didn't bother to speak up. No. It became a major standard because it does the job. C++ is the same way, and so is Perl. They're not the prettiest, but they do the job in an easy and efficient way. That's not to say that a lot hasn't been accomplished in C - obviously. But we could have done a lot more, if such a simple thing hadn't been put off until ANSI. Also, the code I maintained on my first job, probably would've been a LOT cleaner - many of you are probably in the same boat. I really hated roaming around fixing somebody else's stray pointer references. True, but it's more likely that much of the existing code would not have been written at all or would not be as functional. Maintaing poorly structured code is hard, but not as hard as maintaining code that was kludged to get around limitations in the language. As for the truth of your comment... Language syntax and symantics have little to do with a language's success; it's how easy it is to write useful programs with. An operating system's success is due primarily to the amount of software available for it. (Don't believe me? Look at MS-Dos!) Yes, yes, yes, and No, no, no. A language's success is typically 95% who backs it, and 5% how good it is. With the masses, that is. I disagree here, and MS-Dos is a great example. It's not who backs it, but what. Dos was backed by tonnes of software. That's why it's still here. Dos does the job; or did until fairly recently. However, for a group that knows what it's doing, it should be 5% who backs it, and 95% how good it is. So it -should- be for debian. The debian project is in a more than adequate position, to set a more-positive direction for the unix industry. Yes! Now define good. Good is how useful it is, not how how nicely it's designed. Perl _is_ useful. Sure, there are other things, even better things, in many ways. But perl is a standard and following a standard is also good in many ways. I provides for a lot, even if it lacks in others. Don't get me wrong here, I abhor doing things because that's the way they've always been done! Right now, the pros of perl (good user base, almost standard on all unicies, powerful) outweighs the pros of a better language that fewer people know and isn't as common. The cost of changing must also be weighed and affects the decision even if it alone is not sufficient reason. One way to do that, is to hang onto /bin/sh until something like guile is ready. Guile is a neat idea, I'll admit. It's almost like a high-level I-code interpreter, except the I-code is scheme. Done correctly, it could make for a fairly painless conversion and still allow people to write in the language of their choice, changing to better ones at their own pace. It's a while out, though. Still, good, now is better than perfect, later. Another way to do that, is to move beyond perl to something like python or ML (metalanguage) - right now. It wouldn't take much at all. But what is the cost of that move? How many people have to be retrained? What are the advantages? Do the advantages outweigh the costs? Once the inertia's there, it's hard to change it. In fact, many people will become angry with you if you do. But it's often very worthwhile to take a step back, and look at the long-term ramifications of a decision. People, in general, hate change. I personally have nothing against changing the supported base language if I thought it would gain something significant. Convince me of that and I'll argue your side without hesitation. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: XF86 betas (Re: D68K: The next step...)
Mr Stuart Lamble writes: annoyed that if I want support for my W32p (revision A), I have to go to 3.1.2E - and it's not available for Debian. Net result: either I have proper support for my card, and can't install new X-based packages (dpkg barfs at the postinst and configuration stages), or I'm stuck with the SVGA server. Not at all. Install the svga server using dselect. Put it on hold. Get the 3.1.2E server binary, install it, adjust /etc/X11/config. I'm doing just this to run the current Mach64 card, since my RAMDAC isn't supported by the non-beta 3.1.2. No problems at all. Strictly speaking, if you install the 3.1.2E server, you're supposed to install the 3.1.2D libs as well - 3.1.2D was a complete replacement for 3.1.2, and 3.1.2E is supposed to be a drop-in server replacement for the 3.1.2D server when it expired. That's what I'm carping on about. :-) -- I'm on a low-fat, high stress diet: coffee and fingernails.
Re: Perl vs Python vs ....
Brian C. White wrote: Dan Stromberg wrote: There's clearly a place for a stronger scripting language, despite the argument posed above. It's just very sad that it should be perl. perl really fits into many people's stereotypes of unix as inherently cryptic monster, very neatly. I'm sure C and Assembler fit cryptic too. Just think how much further advanced the computer industry would be if neither of those had ever been invented. (that's sarcasm, by the way) And how much further would the industry be, if C had been typesafe (or if some other, typesafe language had been used)? The expertise in language design existed at the time, but C didn't have it. And yet, C was adopted as a major standard - because the people who knew better, didn't bother to speak up. That's not to say that a lot hasn't been accomplished in C - obviously. But we could have done a lot more, if such a simple thing hadn't been put off until ANSI. Also, the code I maintained on my first job, probably would've been a LOT cleaner - many of you are probably in the same boat. I really hated roaming around fixing somebody else's stray pointer references. In fact, I'm pretty sure I recall either K or R, saying that lint should have been just another pass of cc, instead of a separate program. That's a very small design-decision, but it's had a _H_U_G_E impact, for more people than a wanna think about. The choice of a languages is a rather larger decision. There is no point having a religious war over this; this decision was taken a long time ago and can't be changed now, even if we wanted to. This is rhetoric. It could be changed and you know it. What I mean to say is, I really dislike can't when what's meant is won't. I daresay that a linux distribution (or the Hurd, or *BSD, or...) that doesn't fall into the perl trap, should have a brighter future. Oh, give it up! Perl is a fine language. Its powerful and is quite easy to write nice clean code with. It's just not _enforced_ that you write assembler is powerful, and quite easy to write nice clean code with. It was hot stuff at its inception. sendmail is powerful, and quite easy to write nice clean header munging and mail routing with. It was hot stuff at its inception. perl is powerful, and quite easy to write nice clean small-scale scripts with. It was pretty old-news, at its inception. nice clean code. It's also very easy to garbage code, but that isn't enforced, either. As for the truth of your comment... Language syntax and symantics have little to do with a language's success; it's how easy it is to write useful programs with. An operating system's success is due primarily to the amount of software available for it. (Don't believe me? Look at MS-Dos!) Yes, yes, yes, and No, no, no. A language's success is typically 95% who backs it, and 5% how good it is. With the masses, that is. However, for a group that knows what it's doing, it should be 5% who backs it, and 95% how good it is. So it -should- be for debian. The debian project is in a more than adequate position, to set a more-positive direction for the unix industry. One way to do that, is to hang onto /bin/sh until something like guile is ready. Another way to do that, is to move beyond perl to something like python or ML (metalanguage) - right now. It wouldn't take much at all. Once the inertia's there, it's hard to change it. In fact, many people will become angry with you if you do. But it's often very worthwhile to take a step back, and look at the long-term ramifications of a decision.
Bug#3998: xemacs problems
Package: xemacs, xemacs-support, xemacs-widget Version 19.14-1 1) xemacs overwrites files from package emacs without having a 'replaces' line. 2) xemacs is not configured because it depends on xemacs-support which conflicts with emacs. Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Bug#3999: nfs module fails to load
Package: kernel Version: 2.0.6 I recently updated from debian 1.1 - kernel version 2.0.0 - to 1.1.3 by installing the new package in base/kernel-image-2.0.6_2.0.6-0.deb (plus the updated dpkg and kbd). Rebooting the machine showed that all was working apart from the nfs module failing to load with lots of undefined symbol errors. Rebuilding the nfs module from base/kernel-source-2.0.6_2.0.6-0.deb and replacing the existing one in /lib/modules fixed the problem. Andy. ++ | Dr Andy Wood, Database Administrator | | British Antarctic Survey | | High Cross, Madingley Road+--+ | Cambridge, CB3 0ET, UK|[EMAIL PROTECTED] | | +44 (0) 1223 361188|[EMAIL PROTECTED] | +-|[EMAIL PROTECTED] | +--+
Bug#4002: base wipes out utmp wtmp
Package: base
Version: 1.1.0-14
The installation of this package wipes out the file /var/run/utmp and
creates /var/run/wtmp which really should be in /var/log.
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
A. B = True B. A = False
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
PGP Key: [EMAIL PROTECTED] or any other key sites
Bug#4000: emacs can't initialize x window
Package: emacs Version: 19.31-2 I load hilit19.el in my .emacs but when not under X this error occurs. Loading hilit19... Error in init file: error: X windows are not in use or not initialized Erick
Bug#4001: w segfaults on empty utmp
Package: procps Version: 1.01a-1 This isn't really a problem as utmp usually should not be empty but still w should not segfault. The reason I stepped on this is because the base package wipes out the utmp file.
Bug#4004: procinfo breaks without modules
Package: syslinux Version: 1.20-0 On a kernel without module support: $ procinfo can't open file /proc/modules: No such file or directory -- Shields, CrossLink.
Bug#3901: dotlock should be setgid mail
A couple of days ago, Lars mentioned I suggest staying with rwxrwxrwt. with respect to the permissions for /var/spool/mail. Mine is: drwxrwsr-t 2 mail mail 1024 Jul 31 13:08 /var/spool/mail/ I couldn't find the debian package that installed this directory, so I couldn't figure out if these permissions were right, whatever that means. So, a) can someone tell me what package/file/script does install /var/spool/mail? (I'd use this info to find out why my search method failed.) b) Are those permissions right? c) Lars, what did you mean by saying staying with rwxrwxrwt? Regards, Susan Kleinmann [EMAIL PROTECTED]
Bug#4003: minor typo in dchanges
Package: dchanges
Version: 3.4
If dchanges finds an old style file name, it gives the following messages:
Deb file ok: libelf-dev_0.5.2-1_i386.deb
Deb file ok: libelf_0.5.2-1_i386.deb
WARNING: old style file name: libelf-0.5.2-1.tar.gz
should be: libelf_0.5.2-1.deb
WARNING: old style file name: libelf-0.5.2-1.diff.gz
should be: libelf_0.5.2-1.diff.gz
File ok: libelf_0.5.2-1.changes
2 warning(s) - hit return to continue
The problem with .tar.gz can be fixed by applying the following (trivial :)
diff.
--- dchanges.oldWed Jul 31 20:56:47 1996
+++ dchangesWed Jul 31 20:57:36 1996
@@ -477,7 +477,7 @@
if [ $TAR_FN = ${SOURCE}-${VERSION}.tar.gz ]
then
stderr WARNING: old style file name: ${TAR_FN}
- warning should be: ${SOURCE}_${VERSION}.deb
+ warning should be: ${SOURCE}_${VERSION}.tar.gz
else
stderr ERROR: Source file incorrectly named: $TAR_FN
error expected ${SOURCE}_${VERSION}.tar.gz
Bug#3996: rdate.8 refers to adjtime(2)
Package: netstd Version: 2.05-1 It should refer to adjtimex(2), I believe.
Bug#3984: NIS writes error message to STDERR
You (Brian C. White) wrote: Package: nis Version: 1.20-1 I having problems with cron reporting the following error should the NIS server be unavailable. yp_first: clnt_call: RPC: Remote system error This is very annoying as I will get mail every minute or two when cron tries to execute at-run. This is also causing a problem with gnats as it thinks the mail is a bug report and starts processing it. I assume it is NIS doing this since cron works fine without NIS installed. This should be handled more gracefully. A background utility like this should be sending errors via syslog or something instead of writing to STDOUT or STDERR. This is a bug in the library; the library routines print this (they shouldn't ofcourse). Heeemmm can anybody tell me how to redirect a bug report to another package, libc5 in particular? Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Bug#3989: `w' produces corrupted output
Package: procps Version: 1.01a-1 -chiark:~ w 2:13pm up 17 days, 12:23, 12 users, load average: 0.31, 0.20, 0.14 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT richard ttyp0mojave.elmail.co 9:24am 26.00s 0.65s 0.65s -bash pjb1008 ttyp2ash.eng:0.0 10:00am 12:37 1.50s 1.24s -bash ian ttyp1:0.0 11:22am 2:51m 1:36 0.63s xclock ian ttyp3:0.0 11:22am 2:51m 0.14s 0.14s bash ian ttyp7:0.0 11:23am 1.00s 0.54s 0.25s w matthew ttyp8puffball.atml.co 11:30am 2:43m 0.36s 0.36s bash kat ttypamtcsf.mt.ic.ac.u 12:07pm 1:19m 0.82s 0.51s trn stevettypbtheron.cl.cam.ac 12:31pm 1:27 13.01s 12.80s pine stevettypctheron.cl.cam.ac 12:32pm 0.00s 0.49s 0.22s ftp ftp.mcc.ac. ian ttypd:0.0 2:09pm 11.00s 0.10s 0.09s rlogin localhos ijackson ttypelocalhost 2:09pm 11.00s 0.37s 0.37s /bin/bash root ttypf:0.0 2:09pm 3:30 0.24s 0.24s bash -chiark:~ And, from one of my users: chiark:richard$ w 2:09pm up 17 days, 12:19, 13 users, load average: 0.29, 0.18, 0.14 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT richard ttyp0mojave.elmail.co 9:24am 0.00s 1.08s 0.60s w pjb1008 ttyp2ash.eng:0.0 10:00am 8:38 1.50s 1.24s -bash ian ttyp1:0.0 11:22am 2:47m 1:36 0.61s xclock ian ttyp3:0.0 11:22am 2:47m 0.14s 0.14s bash ian ttyp7:0.0 11:23am 9.00s 0.26s 0.26s bash matthew ttyp8puffball.atml.co 11:30am 2:39m 0.36s 0.36s bash ian ttyp9:0.0 2:09pm 30.00s 0.13s 0.13s trn kat ttypamtcsf.mt.ic.ac.u 12:07pm 1:15m 0.82s 0.51s trn stevettypbtheron.cl.cam.ac 12:31pm 35:58 12.20s 11.99s pine stevettypctheron.cl.cam.ac 12:32pm 1:37m 0.22s 0.22s bash ian ttypd:0.0 2:09pm 22.00s 0.10s 0.09s rlogin localhos ijackson ttypelocalhost 2:09pm 22.00s 0.46s 0.09s mailx root ttypf:0.0 2:09pm 1.00s 0.18s 0.17s bash chiark:richard$ As he says, it's also not clear what units the idle times 8:38 and 35:58 are supposed to be. Ian.
Bug#3994: ae won't deinstall
Package: base Version: 1.1.0-14 I'd like to be able to remove `ae', but it won't deinstall. It should be possible to remove ANY package if I really want to. I don't like it when I'm treated like a child by the packaging system.
Bug#3990: xdm-errors location not what FSSTND says
Package: xbase Version: 3.1.2-9 FSSTND R1.2 writes in chap. 5.3.5 to place xdm-errors in /var/lib/xdm/. This is not the location xdm-errors get logged by default in above package. Suggestion: change /etc/X11/xdm/xdm-config in line DisplayManager.errorLogFile: to DisplayManager.errorLogFile: /var/lib/xdm/xdm-errors Michael Gaertner [EMAIL PROTECTED] Tel/Fax +49-761-32684
Bug#3986: inconsistency between base and sysvinit packages!
You (Carlos Carvalho) wrote: The newer base packages create /dev/tty* with permission rw-rw. This causes an error when you try to open an xterm/rxvt window. They quit with couldn't open a pseudo-terminal msg. I don't know whose fault it is. However, the newest sysvinit has this command in the boot script: chmod 666 /dev/tty[pqrs]* So there seems to be a disagreement between the maintainers, no? I think that /dev/ttyp* and /dev/pty* should be 666, otherwise every program using ptys would have to be setuid or setgid at least. While on the subject of /dev, Bruce, could you include more tty devices? The base package has isdn devices, soundblaster devices etc. but only ttyS0..3 are included. I happened to install a FourPort yesterday and had to make them by hand (tty4..7). The /etc/rc.boot/0setserial does indeed reference those ports but it doesn't print an error message if they're missing. Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Bug#3991: dselect has confusing and bizarre interface
Package: dselect Version: 1.12.2 dselect is more complicated than it needs to be. Anyone who has used the package selector for RedHat can understand why people like it so much. I like having a versatile interface such as the one dselect offers, but it shouldn't be so incompatible keystroke-wise with other common interfaces. 1. A consistent key should be chosen for the `quit' function, to exit the current task. It's `q' here, space there, and enter there. Space and enter should do something else. In most applications, such as `dialog' enter selects, it doesn't quit. Space is also usually a selection or toggle options, but never exit. It's really bizarre and confusing that space and enter would do these things. 2. A consistent key(s) should be chosen for the `help'. I suggest F1 and Ctrl-h throughout. (Like DOS or Emacs) 3. Using `/' for search forward makes me want to use `?' to search in reverse. I hit it often enough to get really frustrated. (`?' in `less' and `vi') 4. `/' should remember the last search instead of requiring a separate keystroke, `\'. (`/' in `less' and `vi') 5. The package list browser should not start in help mode. There is a reason that Emacs has an inhibit-startup-message variable. 6. The EIOM columns are not very intuitive. Remove the short description (or move it over) since a long one is displayed below and extend these toggles such that they are understandable.
Bug#3995: perl docs are unreadable
Package: perl Version: 5.003-2 /usr/doc/examples/perl total 32 drwxr-xr-x 6 root root 1024 Jul 23 02:09 . drwxr-xr-x 27 root root 1024 Jul 26 12:13 .. -r--r- 1 root root 192 Jul 1 14:23 ADB.gz -r--r- 1 root root 567 Jul 1 14:23 README.gz -r--r- 1 root root 466 Jul 1 14:23 changes.gz -r-xr-x--x 1 root root 347 Jul 1 14:23 client.gz -r-xr-x--x 1 root root 309 Jul 1 14:23 down.gz -r--r- 1 root root 348 Jul 1 14:23 dus.gz -r--r- 1 root root 681 Jul 1 14:23 findcp.gz -r--r- 1 root root 357 Jul 1 14:23 findtar.gz drwxr-x--x 2 root root 1024 Jul 23 02:09 g -r--r- 1 root root 1179 Jul 1 14:23 muck.gz -r--r- 1 root root 423 Jul 1 14:23 muck.man.gz -r--r- 1 root root 530 Jul 1 14:23 myrup.gz -r--r- 1 root root 289 Jul 1 14:23 nih.gz -r--r- 1 root root 1134 Jul 1 14:23 relink.gz -r-xr-x--x 1 root root 1002 Jul 1 14:23 rename.gz -r--r- 1 root root 169 Jul 1 14:23 rmfrom.gz drwxr-x--x 2 root root 1024 Jul 23 02:09 scan -r-xr-x--x 1 root root 321 Jul 1 14:23 server.gz -r--r- 1 root root 424 Jul 1 14:23 shmkill.gz drwxr-x--x 2 root root 1024 Jul 23 02:09 sysvipc -r--r- 1 root root 421 Jul 1 14:23 travesty.gz -r-xr-x--x 1 root root 1538 Jul 1 14:23 unuc.gz -r--r- 1 root root 303 Jul 1 14:23 uudecode.gz drwxr-x--x 2 root root 1024 Jul 23 02:09 van -r--r- 1 root root 324 Jul 1 14:23 who.gz -r-xr-x--x 1 root root 1479 Jul 1 14:23 wrapsuid.gz
Bug#3993: users can't umount user mounts
Package: mount Version: 2.5j-1 The transcript should explain the problem pretty well. I believe the problem is the different between the options line in the fstab and the options listed by `mount', but I haven't had any time to examine the problem further. There is also a 2.5k version of mount. [quinlan:~]$ cat /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass /dev/sda1 / ext2defaults0 1 /dev/sda2 noneswapsw 0 0 /dev/sda3 /dosvfatdefaults0 2 proc/proc procdefaults0 0 /dev/sda4 /local ext2defaults0 2 /dev/cdrom /cd iso9660 ro,user,noauto 0 0 [quinlan:~]$ df Filesystem 1024-blocks Used Available Capacity Mounted on /dev/sda1 498900 129148 343985 27% / /dev/sda43053225 347526 2547789 12% /local /dev/sda3 453288 40448 412840 9% /dos [quinlan:~]$ mount /cd [quinlan:~]$ df Filesystem 1024-blocks Used Available Capacity Mounted on /dev/sda1 498900 129164 343969 27% / /dev/sda43053225 347534 2547781 12% /local /dev/sda3 453288 40448 412840 9% /dos /dev/sbpcd0 388856 3888560100% /cd [quinlan:~]$ mount /dev/sda1 on / type ext2 (rw) /proc on /proc type proc (rw) /dev/sda4 on /local type ext2 (rw) /dev/sda3 on /dos type vfat (rw) /dev/sbpcd0 on /cd type iso9660 (ro,noexec,nosuid,nodev) [quinlan:~]$ umount /cd umount: /cd mount disagrees with the fstab [quinlan:~]$ sudo umount /cd
Re: New virtual packages suggestion (make)
Brian C. White [EMAIL PROTECTED] wrote: I propose to add the following virtual packages: - gnu-makeuseful for packages like kernel-package and my new compress-package (not yet released) that *need* a GNU make to be used. Do we have (or expect to have) more than one package that provides make? Otherwise, I don't see the use. Actually, changing the name of the make package to gnumake might not be too bad of an idea. There are several versions of make around. While I see little reason for other versions of make, Debian has several instances of redundant packages. I mean, why bother with any other editors when emacs is available? runs away laughing before he gets lynched You could make a case for virtual package make, instead. I like this idea. It seems to me that having GNU Make's package name being gmake, and having it provide make (with pmake doing the same), is the better way to do it. Manoj, as GNU Make maintainer, do you have anything to say on the issue? Warwick Warwick Harveyemail: [EMAIL PROTECTED] Department of Computer Sciencephone: +61-3-9287-9171 University of Melbourne fax: +61-3-9348-1184 Parkville, Victoria, AUSTRALIA 3052 web: http://www.cs.mu.OZ.AU/~warwick
Re: Name clash in prospective package
It seems obvious from the responses I've had, that one of the programs needs to be renamed (no other solutions were presented, and, frankly, I can't really think of one that won't cause problems). If we assume this is the case, it is fairly obvious which one should be renamed: the Mercury one. Mercury's mc probably isn't often invoked by the average Mercury user - it's normally called by the automated build tools that come with it. This means that many users won't notice the change anyway. For anyone who's interested, the new name will be merc (chosen by consultation with the Mercury authors). Warwick Warwick Harveyemail: [EMAIL PROTECTED] Department of Computer Sciencephone: +61-3-9287-9171 University of Melbourne fax: +61-3-9348-1184 Parkville, Victoria, AUSTRALIA 3052 web: http://www.cs.mu.OZ.AU/~warwick
Re: Perl vs Python vs ....
You (Dan Stromberg) wrote: Ian Jackson wrote: sh is not suitable for many of the things Perl gets used for - consider update-inetd, update-info c. Actually, a /bin/sh script to add inetd.conf entries, and another to remove entries keyed off the service field, was unmentionably simple to code, and has proved quite reliable in (lots of) practice. Come on. update-rc.d is a sh script, and on my Pentium133 it takes 10 (ten!) seconds to run. That's unacceptable. I rewrote it in perl, line-by-line so without optimizing it and it now runs in 0.1 secs or so. _Speed_ is also important. Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Bug#4005: Resubmitting Bug#3875, Lynx *.deb problem.
Package: lynx Version: 2.5 and 2.4-FM-960316 OS: Debian 1.1, 17 JUN 96, with dpkg 1.2.11elf Bug: Lynx thinks *.deb files are text/plain, rather than binary. Therefor downloads corrupt *.deb files. -- NOTE: Please close Bug#3875 and substitute this bug report for it. Reason: evidently the bug tracking software is MIME ignorant. So the attached files for Bug#3875 are gibberish. This bug report uses no attached files. It does contain the same info, though. -- The included files refer to a session through my Internet access provider running Lynx 2.5, but lynx_2.4-FM-960316-1.deb has identical behavior. The first file is a reply from Ian Jackson. It may be helpful. The second file is a capture of a session. EM == From [EMAIL PROTECTED] Jul 18 04:34:31 1996 Date: Tue, 16 Jul 96 02:33 BST From: Ian Jackson [EMAIL PROTECTED] To: Eddie Maddox [EMAIL PROTECTED] Subject: Re: dpkg bug: TEXT/PLAIN 1.1 *.deb ENTRIES ON MIRRORS!!! Eddie Maddox writes (Re: dpkg bug: TEXT/PLAIN 1.1 *.deb ENTRIES ON MIRRORS!!!): On Tue, 9 Jul 1996, Ian Jackson wrote: ... If the latter then you probably downloaded the files in text mode or TRUE! and... something. ^! The Debian MIRRORS all (I checked five, 1.1 and 1.1 updates dirs) have directory designators of text/plain for the .deb files! You have fundamentally misunderstood the nature of FTP. FTP doesn't carry a `designator' or any such thing. You must be using some brain-damaged Web browser to download the files, and it is pretending to you that FTP is just like HTTP. HTTP has a Content-Type field in the reply from the server. FTP just has filenames, and your browser is probably guessing the type from the filename - incorrectly. Use a real FTP client and say `binary' at it. Or perhaps you're downloading the files from someone's HTTP server, which has been badly set up, so that it doesn't know that .deb files should be application/x-debian-binary. Ian. == C This is the University of Minnesota General Modem Pool Service. To connect to a host, enter its name (for example, maroon.tc.umn.edu). Use of this service is subject to University policy. To obtain a copy of that policy, please call the E-Mail Help Line at 626-7676. You can also use Gopher or FTP to connect to the host mail.unet.umn.edu where you will find the file dialup-policy in the directory unet. If you should have questions about your E-Mail account, questions about using your SLIP software or this service, please call the E-Mail Help Line at 626-7676 or the Microcomputer Help Line at 626-4276 (9:00 am to 4:00 pm Monday through Friday). If you suspect a hardware malfunction on the network, please call Telecommunications Repair at 625-0006 (24 hours a day). Additional connections to the campus network are available at 626-1920. Network access on 626-1920 requires that you enter a valid account name and password. For further information about this verified network access, please call the E-Mail Help Line at 626-7676 or the Microcomputer Help Line at 626-427. accessgold.tc.umn.edu Trying GOLD.TC.UMN.EDU (128.101.115.11)... Open UNIX(r) System V Release 4.0 (gold.tc.umn.edu) This system is for the use of authorized account holders only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of routine system maintenance, the activities of authorized account holders may also be monitored. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence gathered to law enforcement officials. login: maddo005 Password: Last login: Wed Jul 17 03:45:03 from access.nts.umn.e Terminal recognized as vt100 (DEC VT100) Sun Microsystems Inc. SunOS 5.4 Generic July 1994 NOTICE (1996-07-11): The maroon.tc.umn.edu system will be down between 0630 and 0730 on Wednesday, July 17th, for software maintenance. --- Press any key to continue --- * * Central Computing Services Interactive Mail Shell * * Please send comments to [EMAIL PROTECTED]* * Account Owner: Eddie Maddox (maddo005) 1. Electronic Mail (No mail)[Mailer: pine] 2. U of MN Phone Book
uploaded babel 3.6-4 to master
-BEGIN PGP SIGNED MESSAGE- Date: 02 Aug 96 11:49 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Erick Branderhorst [EMAIL PROTECTED] Source: babel Version: 3.6-4 Binary: babel Architecture: all source Description: babel: Support for multilingual typesetting with (La)TeX Changes: Fri Aug 2 13:21:27 1996 Erick Branderhorst [EMAIL PROTECTED] . * debian.rules: changed for processing in subdir babel * added latin1.sty: Michael Meskens requested . Files: 0d6abb3892494441f87ece9d26e798a0 307234 tex - babel-3.6-4.tar.gz 929afba5d8fbcdecec54893aa49fa0f6 6132 tex - babel-3.6-4.diff.gz b5893d05aaf4fa5215ffa0d73cbb7201 304894 tex optional babel_3.6-4_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgHrVOKGUa6t6e7lAQGOFQP/ckzAr+Du3M21lvUciq4kVIwRkRIjr959 EHUTMz1DFSlZAwygT/9ghGRTbvcSdc75N5vZ8+Ll1QRxXRn7FFLKBOAUsHyLCyxA dWS+hsmgT4OgvsnElmBXSebM0htGsOt65XvvqO2xHo7T8tMENjw0aK19EnAzbOK6 p5eK9qJEsQo= =mM5l -END PGP SIGNATURE-
fileutils 3.13 on master
-BEGIN PGP SIGNED MESSAGE- Date: 02 Aug 96 11:32 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Erick Branderhorst [EMAIL PROTECTED] Source: fileutils Version: 3.13-3 Binary: fileutils Architecture: i386 source Description: fileutils: GNU file management utilities. Changes: Fri Aug 2 11:24:59 1996 Erick Branderhorst [EMAIL PROTECTED] . * man/ls.1: modified pieces about --color. * debian.color-ls: proper documented how to activate colors * debian.rules: manpages are compressed now. * debian.control: conflicts color-ls from now on * configure.in: ALL_LINGUAS added nl and updated nl.po . Files: 39e276c0aa1107cdde2035cd2fa34bd2 627461 base - fileutils-3.13-3.tar.gz a2a03fc850ec6d2d62590e33681a19fc 33193 base - fileutils-3.13-3.diff.gz 580c8938a07ce45778f45ab05033f8f1 287602 base required fileutils_3.13-3_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgHnW+KGUa6t6e7lAQEIrAP/SbukSsF1d+naoq2gWQyO7T+G/irKBTQj EYcQNAHvIoBNzuERKQRCukpwY+gavrfiLFjEsr0gRrTMXJELeBpv1B7Blrms8u02 UEauYPn+Gdu2RCVvdF0289whdgugK9dEycPliJ0OgMkbiP6N3ZXTUpyKvqvEZw8/ Gt33smPQxjg= =hfL6 -END PGP SIGNATURE-
Re: Bug#3987: octave needs libg++
On Thu, 1 Aug 1996, marc hoffmann wrote: Package: Octave Version: 1.1.1-3 After installing octave it won't run and giving a message like: can't find /lib/libg++ (I don't remember exactly). After installing libg++27 elf version (version 2.7.1-2), everything worked fine. Octave had no dependancies on libg++ in dselect, so this may be the reason. This has already been fixed in a later version. The current version in unstable is 1.1.1-6 and has all proper dependancies, including libg++27. I will mark this as done... Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
gmp-1.3.2-3 uploaded to master.
This fixes the architectural problems in the source. Date: 02 Aug 96 13:36 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Dale Scheetz [EMAIL PROTECTED] Source: gmp Version: 1.3.2-3 Binary: gmp Architecture: i386 source Description: gmp: Multiprecision arithmetic library Changes: This fixes the architecture bug. Files: 6b6fe1f601808a3e336b059a9a475f8d 112480 devel - gmp-1.3.2-3.tar.gz d6ee86b01bf560bd2f4e576f649e 4610 devel - gmp-1.3.2-3.diff.gz 2b098bc133af9e4b6f3bfe485ab5c1cf 61740 devel Standard gmp_1.3.2-3_i386.deb Later, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?
Guy Maor: I don't think we should move the copyright file. Most people don't ever need to look at them, so it's simpler if they're out of the way. aolI agree, because of this, and because there are packages that only have and need a copyright file, but not their own directory below /usr/doc./aol I do, however, think we should move the examples directory. I've aolI agree./aol -- Lars Wirzenius [EMAIL PROTECTED] http://www.iki.fi/liw/ Please don't Cc: me when replying to my message on a mailing list. pgp0H3vuN5Y9o.pgp Description: PGP signature
Re: New virtual package names.
Warwick HARVEY: Are there packages that depend on having an editor, Without trying, I think of vipw, vigr, mail, elm, rcs (and thus cvs), trn, tin, and nn. I grant that all but vipw and vigr can be used without an editor -- if you only read mail and news and never check anything in. I don't have an opinion on whether an editor virtual package is needed, though. -- Lars Wirzenius [EMAIL PROTECTED] http://www.iki.fi/liw/ Please don't Cc: me when replying to my message on a mailing list. pgpbetymPqikJ.pgp Description: PGP signature
Bug#4000: emacs can't initialize x window
Erick Package: emacs Erick Version: 19.31-2 Erick Erick I load hilit19.el in my .emacs but when not under X this error Erick occurs. Erick Erick Loading hilit19... Error in init file: error: X windows are not in Erick use or not initialized That is your fault, not emacs. Start is like this: ;; hilit conditional on color (if (x-display-color-p) (require 'hilit19)) Nice number for the bug report, though :-) -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
Bug#3997: perl examples should be visible in /usr/doc/perl
There should be a link or note in /usr/doc/perl about /usr/doc/examples/perl. This is standard on debian, I don't see why a link is needed. Erick
Bug#3994: ae won't deinstall
I'd like to be able to remove `ae', but it won't deinstall. I can do it: dpkg --force-remove-essential --remove ae It should be possible to remove ANY package if I really want to. But you have to do a little extra for it. I don't like it when I'm treated like a child by the packaging system. You aren't, it is assumed that you have more cynapsis running than a child to come with something like --force-remove-essential (:-), but I presume that you did want to do from dselect and I don't know if that can be done. Erick
Re: New virtual package names.
On Fri, 2 Aug 1996, Warwick HARVEY wrote: On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). What would it be used for? Are there packages that depend on having an editor, or for which it would be appropriate to recommend one (and have any old editor serve the purpose)? If so, no problem... Here is a better reason: -- paste begins -- From [EMAIL PROTECTED] Fri Aug 2 11:09:03 1996 Date: Thu, 1 Aug 1996 12:34:51 -0400 From: Daniel Quinlan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#3994: ae won't deinstall Resent-Date: Fri, 02 Aug 1996 11:03:06 GMT Resent-From: Daniel Quinlan [EMAIL PROTECTED] Resent-To: debian-devel@lists.debian.org Resent-cc: Bruce Perens [EMAIL PROTECTED] Package: base Version: 1.1.0-14 I'd like to be able to remove `ae', but it won't deinstall. It should be possible to remove ANY package if I really want to. I don't like it when I'm treated like a child by the packaging system. -- paste ends --- So, if the base packages include a depends: editor and ae provides: editor as well as vi, joe, emacs, and others. Then, as long as some package that provides editor is installed, ae can be removed without difficulty. (Actually I think the above problem is aleviated by removing ESSENTIAL from ae, but the editor provides helps maintain the existance of some editor on the system) Later, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
conffiles question
I 'm busy with mflib and thought that it might be useful to have the weekly script run daily by cron because a daily run will have a bigger chance to be run on systems which are on and off (like mine at home). Therefore I would need to remove the conffigurationfile /etc/cron.weekly/mflib from the package and put a new one into the package named /etc/cron.daily/mflib. How can this be done? Erick
Re: uploaded babel 3.6-4 to master
Erick * added latin1.sty: Michael Meskens requested
See the documentation in /usr/doc/latex/ltnews0[23].tex.gz, this is no longer
needed since about last June.
I used to use latin1, but now prefer
\usepackage[latin1]{inputenc} % Umlaute
--
Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
Re: libident-0.17-2 uploaded to master.
This fixes the description bug. Date: 02 Aug 96 13:34 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Dale Scheetz [EMAIL PROTECTED] Source: libident Version: 0.17-2 Binary: libident Architecture: i386 source Description: libident: a simple RFC1413 client library Changes: This fixes the description bug. Files: 4f93e73c78e5ac64f2469071f8c96a1a 11108 Devel - libident-0.17-2.tar.gz 32e767d33dd03f1488b621962ce9b8bd 5326 Devel - libident-0.17-2.diff.gz a2dc533fd4d8be4a0d1da582764647fd 11424 Devel extra libident_0.17-2_i386.deb Later, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
diff-2.7-11 uploaded to master.
This repairs the architecture bug reported against this package. Date: 02 Aug 96 16:44 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Dale Scheetz [EMAIL PROTECTED] Source: diff Version: 2.7-11 Binary: diff Architecture: i386 source Description: diff: File comparison utilities Changes: This fixes the architectural packaging problems. Files: 9f103db0b611916a179a6345645b9e8c 325250 base - diff-2.7-11.tar.gz 26a72637a3e39ae38cd37f5ac21aff43 15459 base - diff-2.7-11.diff.gz 1fb4c594031e41c9bc478ff8fe74a21b 183654 base extra diff_2.7-11_i386.deb Later, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Bug#4006: Fileutils has /usr/libexec directory
Package: fileutils Version: 3.13-2 The fileutils package has an empty /usr/libexec directory in the .deb file. I don't think the FSSTND supports libexec yet, so the directory should be removed. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
elm problems
I just tried to build elm from the debian source package with the thought that I might be able to maintain it. So far the verdict is not in. The build target in debian.rules is really very simple: make make documentation touch build However, if I try debian.rules build I get: make make[1]: Entering directory `/Debian/pkgwork/elm/elm-2.4pl25' cd lib; /usr/bin/pmake -w all /usr/bin/pmake: illegal option -- w usage: make [-eiknqrst] [-D variable] [-d flags] [-f makefile ] [-I directory] [-j max_jobs] [variable=value] make[1]: *** [all] Error 2 make[1]: Leaving directory `/Debian/pkgwork/elm/elm-2.4pl25' make: *** [build] Error 2 When I enter the commands by hand, at the prompt everything works fine! In both cases the command issued is the same but execution from the prompt looks like: cd lib; /usr/bin/pmake - all and everything runs fine... :-S Any pointers would be appreciated, Dwarf -- aka Dale Scheetz Phone: 1 (904) 877-0257 Flexible Software Fax: NONE Black Creek Critters e-mail: [EMAIL PROTECTED] If you don't see what you want, just ask --
Re: Perl vs Python vs ....
I'm sure C and Assembler fit cryptic too. Just think how much further advanced the computer industry would be if neither of those had ever been invented. As to assembler, there are lots of _very_ different styles of writing it; there is no one Assembler language. It's quite impossible to say anything general about it. No it's not. Assembler is low-level crunching. It's unstructured, typeless, and unportable. If you want portable asm, go to C. This wasn't about style. It's about cryptic. Good and bad style is possible in any language. As to C, while the language does miss some very crucial features and does make it relatively easy to write cryptic programs, the language itself is quite clean and orthogonal. Parsing C code, for example, does not have any of the quirks that parsing, say, FORTRAN or -surprise!- Perl has. Perl's syntax is quite straightforward for a human. It is, however, a language of side-effects. This is what can make it difficult to follow. It's also what gives it part of its power. I still have trouble figuring out how to write _readable_ programs in Perl. Funny, I don't. Sorry, but I disagree very much. Perl is an powerful and effective language. It is neither fine nor even clean; it is _very_ ugly. And while some variants of code are indeed easy to write in a clean way, lots of others aren't. You can't get rid of dependencies on $_, for example. In that aspect it's a lot more like assembler than like any high-level language. There are very, very few places you _must_ use $_. Writing clean code is no more difficult than in any other language. It's just easy in perl to write things poorly. I put this blame on the programmer, though, not the language. As for the truth of your comment... Language syntax and symantics have little to do with a language's success; it's how easy it is to write useful programs with. An operating system's success is due primarily to the amount of software available for it. (Don't believe me? Look at MS-Dos!) It doesn't depend on the easy factor, either. Look at MS-DOS, indeed - for a very long time, all the utilities were completely written in assembler. (Somehow, this didn't make them small and fast.) This point totally escapes me. Dos, like C and Perl is/was successful because of the amount of software available for it. It doesn't matter what the software was written in. Like anything else, success of languages is mainly an advertizing thing. And there can be no doubt that Perl has won that one. (So has C++, which shouldn't have either, based on any technical merits.) I wouldn't call it avertising, but I think I know what you're saying. These languages were advertised by other users because they worked. They did the job better than the other choices. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Name clash in prospective package
BCW == Brian C White [EMAIL PROTECTED] wrote: BCW I don't see a problem with packages creating directories and BCW other necessary framework in /usr/local. In some cases, this can BCW be quite complex and without which it isn't possible for there to BCW be local extensions. Besides, it let the users know where to put their local elisp code, Perl modules, etc. ECL. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] Instituto de Fisica da Universidade de Sao Paulo Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
Bug#4008: CVS texinfo docs won't format correctly with TeX
Package: cvs
Version: 1.8.1-1
The initial format fails because it can't find the file `CVSvn.texi'.
(760) tex cvs.texinfo
This is TeX, Version 3.1415 (C version 6.1)
(cvs.texinfo
Hyphenation patterns for british, english, french, german, spanish, loaded.
(/usr/lib/texmf/tex/misc/texinfo.tex Loading texinfo package [Version 2.151]:
Basics, fonts, page headings, tables, indexing, sectioning, toc printing,
environments, defuns, cross reference, and turning on texinfo input
format.)kpathsea: Running MakeTeXTeX cvs.aux
kpathsea: Running MakeTeXTeX CVSvn.texi
! I can't find file `CVSvn.texi'.
to be read again
@endgroup
l.25 @include CVSvn.texi
Please type another input file name:
(/usr/lib/texmf/tex/latex/tools/.tex) [1] [2]
[...]
Output written on cvs.dvi (118 pages, 325624 bytes).
Transcript written on cvs.log.
The result has some glitches (I assume because of the missing file),
but it's passable. However, any subsequent attempt to reformat the
doc fails unless you delete all the auxillary files in the dir and
start from scratch.
(765) tex cvs.texinfo
[...]
! I can't find file `CVSvn.texi'.
to be read again
@endgroup
l.25 @include CVSvn.texi
Please type another input file name:
(/usr/lib/texmf/tex/latex/tools/.tex) [1] [2] (About this manual) [1] Chapter1
[2] [3] Chapter2 [4] [5] Chapter3 [6] [7] [8] Chapter4 [9] [10] [11] [12]
[13] [14] [15] [16] [17] Chapter5 [18] [19] [20] Chapter6 [21] [22] [23]
[24] [25] [26] [27] [28] [29] Chapter7 [30] [31] [32] [33] [34] Chapter8
[35] [36] [37] [38] Chapter9 [39] [40] Chapter10 [41] [42] Chapter11 [43]
[44] [45] Chapter12 [46] [47] Chapter13 [48] [49] Chapter14 [50] Chapter15
[51] [52]
! Undefined control sequence.
@Xlog-title -log---Print out @rlog
@ information for files
@refx [EMAIL PROTECTED] @fi @else @csname [EMAIL PROTECTED]
@fi #2
@xrefX ...efx [EMAIL PROTECTED] [EMAIL PROTECTED]
],@space @turnoffactive @p...
l.3452 use the @code{cvs log} command (@pxref{log}
).[... more nastiness deleted
...]
Not a big deal, but I thought I should mention it.
--
Rob
Bug#4007: identd doesn't seem to be correctly configured
Package: netstd Version: 2.05-1 The configuration of identd in inetd.conf is incorrect. The incorrect line is: ident stream tcp nowait nobody /usr/sbin/identdidentd -i with the correct line being: authstream tcp nowait nobody /usr/sbin/identdidentd -i -- Scott K. Ellis [EMAIL PROTECTED] Argue for your limitations Systems Administrator, Anexis Inc. and sure enough, Business Web Presence Hosting they're yours. http://www.anexis.com/ -- Illusions
