Re: majordomo and exim
On Sat, 6 Dec 1997, Vadim Vygonets wrote: On Thu, 4 Dec 1997, G John Lapeyre wrote: After several hours of effort, I have majordomo working with exim. I never even knew what the different MTA's were , much less how to use them. However, I think all the changes to the majordomo installation that I made were neccessary. I'm now trying to make majordomo working with exim. I only installed it by now, not tested yet (had to go). When I experience any difficulties, I'll inform you. I'm using exim 1.73 and majordomo 1.94.4. I ended up having so much trouble that I switched to sendmail. I received a message that the latest exim now understands -ooe . There were many other problems, and I didn't need to find out how many. I am giving up. If anyone wants a more detailed list of what I've found so far, let me know. 1. when including an address file, exim wants commas for separators. majordomo uses none. 2. exim wants a gid and uid to run 'custom' delivery processes, such as majordomo. You could use the 'local_part' variable, but this is 'majordomo' which is an alias for a pipe to a process, and not 'majordom' which is the user name with a gid and uid . I don't know a robust way to fix this, but its probably easy. 3. All of the sendmail flags in the standard majordomo config file broke exim, so I simply removed them. G John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-06
Hi! Previously Richard Braakman wrote: Wichert Akkerman [EMAIL PROTECTED]: xcdroast-0.96-1 Just a quick note to discourage non-maintainer uploads: I am still waiting for the 0.96c release of xcdroast. I've got a packaged version of the fourth beta which seems to work just fine. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wakkerma/ pgp2QZA2i6A8o.pgp Description: PGP signature
Re: crontab
In article [EMAIL PROTECTED], Steve Greenland [EMAIL PROTECTED] wrote: On 05-Dec-1997 10:32:37, Philip Hands [EMAIL PROTECTED] wrote: The fact that the three lines added here ever get seen in the output of crontab -l is a bug IMO: Actually, I got a better understanding of why and where that header was being added, and I was going to make crontab -l NOT include the header on the next release. However, the existence of scripts that do crontab -l |tail +4 make the removal a problem as well. Especially since that line is usually used in the prerm script, so an upgrade won't help.. It might be worth it to locate all the packages that do this, and file a bug report against them. You should mention that tail +4 is dangerous since the behaviour of crontab -l might change , and recommend something like: crontab -l | sed -e '/^#.*\(DO NOT EDIT\|Cron version\|installed on\).*$/d' instead. Then wait for Debian 2.2 or so, so you can be reasonably sure everybody has upgraded all those packages at least once and release a new cron.. Mike. -- Miquel van Smoorenburg | Studying to be a technomage * [EMAIL PROTECTED] | May you live in interesting times -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Can we learn something from RH 5.0?
David Engel wrote:
I only know of one real bug so far. They didn't apply the fix needed
to use the NIS module from autofs with glibc. I found that problem
Does there rpc.nfsd (or squid) leak?
--
Debian GNU/Linux 1.3 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://greathan.apana.org.au/~herbert/
PGP Key: http://greathan.apana.org.au/~herbert/pubkey.txt
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Breaking GNU standards off from autoconf
Would anyone mind particularly if I took the GNU standards.info out of autoconf and made a new package for it, and added maintain.info and tasks.info to this package? I think it is the right thing to do; autoconf is not particularly suited for this. On another note, is there a magic way to get this new package installed by default if autoconf was previously installed? Or should I just use Suggests: on the part of autoconf? -- Ben Pfaff [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
copyright infringment
I was hired and paid to take a photograph of a collage basketball team they then took the photo and mass produced thousands of copies of it and gave them away at a ballgame they were not given the negative or a copyright do I have any legal recourse ? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Can we learn something from RH 5.0?
On Sun, Dec 07, 1997 at 11:59:27AM +1100, Herbert Xu wrote: David Engel wrote: I only know of one real bug so far. They didn't apply the fix needed to use the NIS module from autofs with glibc. I found that problem Does there rpc.nfsd (or squid) leak? Wasn't that caused by glibc? If so, their's could leak. I didn't notice a patch in their .src.rpm for this particular bug. I did notice something else interesting though. It seems they use the kernel headers from a specific version (2.1.60 in their case) when building glibc just like we do. However, they still don't require, or even encourage, their users to use the same kernel headers. I guess they don't care if their users get bitten by an incompatibility. :) David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: predepends on libc6?
James Troup wrote: [EMAIL PROTECTED] (Richard Braakman) writes: The packaging manual is wrong; this is a long standing bug. Can you explain, or refer to a bug number that explains it? No. I have neither the time nor the inclination to trawl through the hundreds of bugs filed against dpkg. I grepped through my bug archive from Jul 19, and I did not find it. I assume the report will mention ldconfig somewhere. I also checked the current bug report titles on the web, and did not find it. (I did find a number of I had problems and you should run ldconfig in the postinst bugs, but never any explanation.) It's not very good to have incorrect instructions for shared libraries at a time when we're doing a massive shared-library upgrade. Most of the libraries have done long ago, and the packaging manual has been wrong since before the release of bo. So now we have to shake out the bugs. And, of course, we need new text for the packaging manual. Right now we have Tinker with the postinst until it seems to work, or copy one from a similar package. I'd like something more solid. Why is it calling ldconfig? Because it's the Right thing to do. Heh. That argument only convinces me if I already know why it's Right :-) Take a look at the postinsts for every package with a shared library. I did. But why assume they are correct? Someone reports a bug and says package should run ldconfig, maintainer says okey I'll do that. This does not mean the ldconfig is actually necessary, it may merely mask the symptoms of a bug in the packaging. You seem fond of statistics, how many *don't* run ldconfig? Of the library packages installed on my system, eight. They are comerr2g, e2fslibsg, fakeroot, ftplib, libgtk1, libmpeg1, libpaperg, and procps. If these packages are doing something wrong, then we have a problem. So far I have not had any problems with them. What does the ldconfig do, if the symlinks are already there? RTFM. Also, try it and see. I dare you to take a bo machine, rebuild hamm's bash and remove the C postinst which runs ldconfig and then install the resultant debs. I'd love to, but I have no bo machine to spare. I did R the FM, and it says that - ldconfig updates the symlinks and the cache. - ld.so searches LD_LIBRARY_PATH first, then looks in the cache file, then in the default paths /usr/lib and /lib (where libc6 lives). - as one might expect from a cache file, it is no problem for it to be corrupt or nonexistent. So, what is ldconfig doing that gzip needs? (I also looked at the source code, in case you care. And I tried moving libraries around and then running programs that depend on them. All went fine.) (Hint: it tells the dynamic linker that the library is there) The dynamic linker can see that for itself when it looks for libc.so.6. If not, there's a bug *somewhere*. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: copyright infringment
CKaduc [EMAIL PROTECTED] writes: I was hired and paid to take a photograph of a collage basketball team they then took the photo and mass produced thousands of copies of it and gave them away at a ballgame they were not given the negative or a copyright do I have any legal recourse ? I think that you should put the photo under the GNU GPL and distribute as part of the Debian system. :-) -- Ben Pfaff [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
random numbers
I just had occaison to test random number generators in my work. I also read a review paper from the physics literature on the subject. I did extensive tests (on my problem) on all four of the best Numerical Recipes generators and the linux system 'random', which is the longer period generator. Even when given the largest table size, the linux generator performed perceptibly worse than the others. When given a somewhat smaller table size, it performed abysmally. I believe the N.R. people did a good job in digging up good algorithms. What are the considerations for choosing a system random number generator? What if debian were the first unix to have a good random number generator ? (is there another?) At least I should upload GPL'd versions of the good generators (there is not much code) for people that need them . Or ? G John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: random numbers
On Sat, 6 Dec 1997, G John Lapeyre wrote: What are the considerations for choosing a system random number generator? What if debian were the first unix to have a good random number generator ? (is there another?) At least I should upload GPL'd versions of the good generators (there is not much code) for people that need them . First, does it pass a basic statistical analysis? e.g. mean, standard deviation, probability of individual number all correct, no patterns, and probably a bunch of other things I never learned about. I'm working on a final for a course that spent a large amount of time on a random generator. What were you testing? How long it took to generate a bunch of numbers? I had a hard time figuring out what you meant by worse performance. Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
On 06-Dec-1997, Manoj Srivastava [EMAIL PROTECTED] wrote: Tyson Considering most mailing lists seem to be configured to reject Tyson email that isn't From the person on the list, I find this is Tyson a pretty feeble argument. But it's the strongest argument for Tyson not munging Reply-Tos on mailing lists. Even the mail RFC (I Tyson forget the number) suggests using Reply-Tos for mailing lists. Chapter and verse, please. This may be the most valid of your arguments. Quote the RFC, and you may well have a point. RFC-822: 4.4.3. REPLY-TO / RESENT-REPLY-TO This field provides a general mechanism for indicating any mailbox(es) to which responses are to be sent. Three typical uses for this feature can be distinguished. In the first case, the author(s) may not have regular machine-based mail- boxes and therefore wish(es) to indicate an alternate machine address. In the second case, an author may wish additional persons to be made aware of, or responsible for, replies. A somewhat different use may be of some help to text message teleconferencing groups equipped with automatic distribution services: include the address of that service in the Reply- To field of all messages submitted to the teleconference; then participants can reply to conference submissions to guarantee the correct distribution of any submission of their own. Note: The Return-Path field is added by the mail transport service, at the time of final deliver. It is intended to identify a path back to the orginator of the mes- sage. The Reply-To field is added by the message originator and is intended to direct replies. It doesn't actually say mail lists, but I think this is what they meant by text message teleconferencing with automatic distribution services (it was written in 1983 ;-). This in particular addresses my concern of information leaving the list because private replies are the default. For what is essentially a technical discussion list, I'd rather have useful information recorded in the archives than in individual mail folders. Tyson With the current situation, what are the solutions to the 4 Tyson problems I outlined? -- and what is the likelihood of these Tyson solutions actually solving problems (as opposed to the spend Tyson 30 seconds pruning your headers solution, which given the Tyson number of CCs on this list, is clearly not workable). I think people should get decent mail user agents. I never have to spend time pruning CC's. (and when I use other mail user agents, I _do_ trim the headers to follow good ettiquette). I also think it is bad policy to break standards to cater to rude people (those who do not follow good net ettiquette). I accept your point that munging reply-tos is undesirable, but I'd like to mitigate the problems (particularly the messages jumping from one mailing-list to another -- this has bitten me, and it seems a number of other people). But if munging is unacceptable, I'm open to other suggestions. Simply recommending a few good mailers in the Internet of the Debian Developer's Reference talking about mailing lists (which is where it says no CCs) is a possible compromise (along with a quick explanation of the problems with the common mailers). I'd be happy to write the text for such a change and get it organized if you think this is a reasonable compromise. -- Tyson Dowd # # Linux versus Windows is a [EMAIL PROTECTED]#Win lose situation. http://www.cs.mu.oz.au/~trd # -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Brian Mays) writes: Okay. I'm building a new unstable version of rxvt with backspace set to ^H. From this point on, Debian's rxvt policy will be to use ^H as backspace by default. Couldn't you force it to ^? instead? That would be far more sensible. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: crontab
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Miquel van Smoorenburg) writes: that do this, and file a bug report against them. You should mention that tail +4 is dangerous since the behaviour of crontab -l might change , and recommend something like: crontab -l | sed -e '/^#.*\(DO NOT EDIT\|Cron version\|installed on\).*$/d' Yes, that seems like a good solution. instead. Then wait for Debian 2.2 or so, so you can be reasonably sure everybody has upgraded all those packages at least once and release a new cron. Once that is done the packages can remove the sed completely (and depend on the new cron). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: random numbers
On Sun, 7 Dec 1997, Mark Baker wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (G John Lapeyre) writes: Recipes generators and the linux system 'random', which is the longer Do you mean the library call random? No, that isn't brilliant, though if you try other unixes you'll probably find them worse. Apparently /dev/random is very good. I heard the /dev/random files were seeded with real random data from things like network IO interrupt calls and so forth. I've never seen any distribution tests on the data though. Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc5 backports problem
One problem with doing backports of libc5 packages is that dpkg-dev in bo doesn't seem to support pristine sources; it complained that the original wasn't in the .orig subdirectory. Although dpkg-dev from hamm works fine on bo since it is not libc dependent, it's still not possible to backport on a completely-bo given this factor, unless I am missing something .. That said I am working on some of mine, and they are at ftp://ftp.rising.com.au/pub/hamish/libc5 So far I have cam done, working on guavac. Most of mine are new for hamm though. hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dpkg-source problem
On Fri, Dec 05, 1997 at 11:21:36AM -0600, Manoj Srivastava wrote: Hi, Ulf == Ulf Jaenicke-Roessler [EMAIL PROTECTED] writes: Ulf Hello, Ulf when I use dpkg-source on an unchanged source tree it complains Ulf about unrepresentable changes. dpkg-buildpackage exits with an Ulf error code. Is this a bug or a feature? How can I circumvent it? Usually, this happens when a binary file (gif files, for example) has changed, diff does not know how to process that, and things fail. Could you run the command under script and provide us with the exact output? It also doesn't work with changed symlinks. Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Unidentified subject!
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 7 Dec 1997 19:27:33 +1100 Source: guavac Binary: guavac Architecture: source i386 Version: 1.0-1 Distribution: unstable Urgency: low Maintainer: Hamish Moffatt [EMAIL PROTECTED] Description: guavac - A java compiler. Changes: guavac (1.0-1) unstable; urgency=low . * Corrected broken manual page (fixes #15206) * This is version 1.0 (fixes #14930). Files: c08f9858b1b7a3d7e0ac34fe643e37b7 611 devel extra guavac_1.0-1.dsc d5456f8a90e66c5727e9a606b00fdfdd 632354 devel extra guavac_1.0.orig.tar.gz f07cbd3bbaac004ddb70051990054738 8668 devel extra guavac_1.0-1.diff.gz b994a99b4bb2f3d27b166ed0feb4663e 684302 devel extra guavac_1.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBNIphXNiYIdPvprnVAQFzsQP+N48qBDCRhouhCKE0sf9dZEr64Ybn4nC1 sP8ab9KikQ0i3GJqq3ptS1LMic45/OqRFCADVpkOyV0NP6TdzhPUf4i9ybKPNUZp 5z3a0hxve6hmLC7yk57Bq4ODRRW/Mvnix3ClfOHVdqn97yuXX1Ov4rd/yPnFeYT3 xcRNC3Nyk+M= =mBms -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package: umich-ldap / WNPP: Dermot Bradley probably not maintaining packages
Dermot - (Just caught up with the list again; my Gnus setup caught your mail to the list first and put the direct reply in the 'duplicates' bin.) As the one making the speculations about your absence, I'm extremely sorry. I didn't mean to put you in a position of explaining yourself. Some people on debian user had been sharing user-versions of mrtg; I got the wrong idea, and thought I was facilitating further packaging work . I'm much happier to see that you *are* still working on the project; do excuse me. -- Ed Donovan [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
oops
Sorry, I was having hassles with my local mail system broken reverse DNS here and accidentally resent an unstable upload announcement to debian-devel-announce instead of debian-devel-changes. :-( hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: majordomo and exim
On Sat, 6 Dec 1997, G John Lapeyre wrote: I ended up having so much trouble that I switched to sendmail. I received a message that the latest exim now understands -ooe . you mean -oee ? That means that any errors are forwarded to the sender (seems like it means the address in Sender: header). There were many other problems, and I didn't need to find out how many. I am giving up. If anyone wants a more detailed list of what I've found so far, let me know. 1. when including an address file, exim wants commas for separators. majordomo uses none. Didnb't experience it. 2. exim wants a gid and uid to run 'custom' delivery processes, such as majordomo. You could use the 'local_part' variable, but this is 'majordomo' which is an alias for a pipe to a process, and not 'majordom' which is the user name with a gid and uid . I don't know a robust way to fixthis, but its probably easy. .../majordom/wrapper must be installed setuid root. So it doesn't matter what uid you give it, I just uncommented the default user = exim. 3. All of the sendmail flags in the standard majordomo config file broke exim, so I simply removed them. Well, when I install majordomo to the end, I'll tell you what problems were there. Vadik. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
On Sun Dec 7 09:15:28 1997 + (Sekmadienis, 1997 m. gruodio 7 d. 11:15:28 +0200), Mark Baker wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Brian Mays) writes: Okay. I'm building a new unstable version of rxvt with backspace set to ^H. From this point on, Debian's rxvt policy will be to use ^H as backspace by default. Couldn't you force it to ^? instead? That would be far more sensible. Wouldn't it be better don't force people to use what they don't want? This only results in flamewars. There is lots of configuration files and convincing every application to do 'right thing' separately is quite tedious. Simple `reset' can set stty erase according to terminfo key_backspace. -- Riardas epas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 06.12.97 in [EMAIL PROTECTED]: If I set a reply-to address for the list manually, then having it munged is not just being less pleasing, it is *broken* behaviour. Why should we break perfectly standard mail processing because some mailers are broken out there? No such thing. It is pretty clear to me (after the discussion on DRUMS) that there currently is no perfectly standard Reply-To: processing; the header is used in too many incompatible ways. After much discussion, the experts seem to agree in only one point: the way Reply-To: is used for replies in _most_ programs is essentially broken. We're even considering deprecating Reply-To: completely in favour of several new headers. No decision has been reached yet, however. If your mailer is broken, protest to the author, don't ask other people to break email conventions to cater to broken mailers. There are _no_ universally accepted, useful conventions for Reply-To:. Sad but true. 822 was too imprecise in it's definition, plus current mailing lists were unknown back then. Yes, but there are times when discussion is taken off-line. You break the reply-to address, and people can no longer be reached off-line. Such gratitous breakage just for broken mailers? If you can't get your mailer to reply to From: when you want to, complain to it's programmer - it's broken. (As to From: is broken, Reply-To: was _never_ meant to fix that. From: _should_ be settable by the mail sender - read 822 if you don't believe me. Mailers (or system setups) that don't allow you to do that are _clearly_ broken. From: is not, and never has been, meant for any sort of authentication info.) electronic mail standards and convention, is none of our business. We *shoul* *not* break it. Sorry. No can do. You will always break it for someone. I think people should get decent mail user agents. There don't seem to be many that match your definition of decent. (Incidentally, that's part of why I'm still thinking about writing my own.) Maybe we should make a list. You seem to like GNUS; obviously, that's no solution for people who hate Emacs. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: gated
[EMAIL PROTECTED] (Dermot John Bradley) wrote on 06.12.97 in [EMAIL PROTECTED]: On Sat, 6 Dec 1997, Philip Hands wrote: ftp://gated.merit.edu/net-research/gated/gated-R3_5_5.inet.tar.gz (is that the right one ?) and found this in README.license THe current one is gated-3-5-8.tar.gz Please note the Gated 3.5.5 software can distributed in source or binary form to any mirror sites. The problem doesn't lie with gated itself but the licensing conditions of the OSPF code that it uses from Umich. As for putting up a package to ftp/wget the source and built it - sure, it there another package that I could look at that does something similar (maybe the netscape installer?) No compilation in there. Try compress-package_1.3-1.deb (in both bo and hamm contrib, AFAICT) for that - I don't remember many details, but it worked for me after I finally managed to locate some sources; all the given places had removed them). MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 04.12.97 in [EMAIL PROTECTED]: Personally, I still think that reply-to is a bad solution; we That's true. The problem, however, is that better solutions are next to non-existant - I sure don't consider something that only works for a very small number of mail clients a solution. At least not while discussing how to solve a current problem - it does help when designing new software :-) Why do we have a policy about CC's? Because they are evil. There seems to be fairly broad consensus on that. I like CC's; they genrally propogate to me faster. Which easily leads (for me) to actually missing them - because of duplicate suppression, they do not show up where they are expected (with the mailing list). Where is this policy stated? (I just looked into debian-policy, and /usr/doc/debian/mailing-list.txt, with no success). If indeed there is such a policy, it has been hidden quite succesfully. (I certainly don't remember this being ratified). I think I do remember it; Lars asked for no CCs on -devel, someone else asked for please to have CCs, and the resulting discussion (IIRC) had that result. Probably people forgot to write it down. The people with sad mail software and lazy fingers are penalizing the people with low bandwidth. Don't break conforming software to cater to broken software. Don't break the setup for 90% to cater to 10%. I think you are in the 10% group, here. I do agree that reply-to isn't the optimal solution. Not doing anything is very suboptimal, as well, though. The DRUMS group (doing updates to RFC 821/822) is trying to find a solution to this, but we're not there yet - and then software needs to be adapted to the new standards. I don't expect a serious installed base of anything new before 1999. (It probably will happen fast, because people like Netscape are involved in DRUMS - I expect the participants cover a large part of the market.) One serious CC: problem is that you don't know which of these CC:s are on the list (so don't need and usually don't want a CC:), and which aren't (so need a CC: to receive anything at all). Happens all the time with upstream authors. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
[EMAIL PROTECTED] (Tyson Dowd) wrote on 06.12.97 in [EMAIL PROTECTED]: Even the mail RFC (I forget the number) suggests using Reply-Tos for mailing lists. You forgot because it's not true. No such thing in any of RFC 821/822/ 1123. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 backports problem
One problem with doing backports of libc5 packages is that dpkg-dev in bo doesn't seem to support pristine sources; it complained that the original wasn't in the .orig subdirectory. Although dpkg-dev from hamm works fine on bo since it is not libc dependent, it's still not possible to backport on a completely-bo given this factor, unless I am missing something .. Hi. As far as I understand, you just told that you can use dpkg-dev from hamm to produce binary package on bo system. So, what is the problem now? I guess even earlier dpkg (from bo) can install them OK, right? Thanks. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 backports problem
On Sun, Dec 07, 1997 at 08:44:06AM -0500, Alex Yukhimets wrote: One problem with doing backports of libc5 packages is that dpkg-dev in bo doesn't seem to support pristine sources; it complained that the original wasn't in the .orig subdirectory. Although dpkg-dev from hamm works fine on bo since it is not libc dependent, it's still not possible to backport on a completely-bo given this factor, unless I am missing something .. Hi. As far as I understand, you just told that you can use dpkg-dev from hamm to produce binary package on bo system. So, what is the problem now? I guess even earlier dpkg (from bo) can install them OK, right? The only prolbem is that you cannot produce these packages on a purely bo system as some have promised/hoped. For example, Tim Sailer is offering access to a bo system for backporting, but unless it has been upgraded to dpkg from hamm then pristine sources aren't supported. hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 backports problem
Although dpkg-dev from hamm works fine on bo since it is not libc dependent, it's still not possible to backport on a completely-bo given this factor, unless I am missing something .. As far as I understand, you just told that you can use dpkg-dev from hamm to produce binary package on bo system. So, what is the problem now? I guess even earlier dpkg (from bo) can install them OK, right? The only prolbem is that you cannot produce these packages on a purely bo system as some have promised/hoped. For example, Tim Sailer is offering access to a bo system for backporting, but unless it has been upgraded to dpkg from hamm then pristine sources aren't supported. Well, I guess then libc5 machines dedicated to backporting should have dpkg-dev from hamm installed. And upload newer dpkg-dev to bo-unstable for consistency. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: predepends on libc6?
[EMAIL PROTECTED] (Richard Braakman) writes: Take a look at the postinsts for every package with a shared library. I did. But why assume they are correct? Someone reports a bug and says package should run ldconfig, maintainer says okey I'll do that. I maintain and have done non-maintainer release for several shared library packages, and I *know* it did not happen that way. And please don't judge other maintainers by your own standards, I for one, won't add gratuitous program calls to my postinsts just because someone said I should. Perhaps you would, that doesn't mean that 90% of the shared library maintainers would. I also think someone might have noticed by know if this vast majority of shared libraries were doing it wrong; don't you? You seem fond of statistics, how many *don't* run ldconfig? Of the library packages installed on my system, eight. They are comerr2g, e2fslibsg, fakeroot, ftplib, libgtk1, libmpeg1, libpaperg, and procps. IIRC, Che's knows about libgtk1 and libmpeg1 and will fix them. e2fsprogs is broken in so many ways at the moment, it doesn't surprises me in the slightest that it also fails to run ldconfig. If these packages are doing something wrong, then we have a problem. A bug, dear, the word is a bug. So far I have not had any problems with them. Others have. RTFBA (#14212). BTW, even David, the ld.so author maintainer, says the packaging manual is wrong; are you *so* confident you're right and everybody else is wrong that you're going to tell him he's wrong too? I give up. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-06
Paul Seelig [EMAIL PROTECTED] writes: Since XEmacs-20.3 has finally been released on Nov 30 it would be really nice to have this included in Debian-2.0 instead of the now obsolete XEmacs-20.2, especially since some nasty bugs have been fixed with this release. Please tell me that the conflicts (concerning ctags, I think) have been resolved and GNU Emacs and XEmacs will now peacefully coexist. Kirk Hilliard -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
On 07-Dec-1997 12:43:00, Kai Henningsen [EMAIL PROTECTED] wrote: That's true. The problem, however, is that better solutions are next to non-existant - I sure don't consider something that only works for a very small number of mail clients a solution. Reply-to-all + editing is available only with a small number of clients? I like CC's; they genrally propogate to me faster. Which easily leads (for me) to actually missing them - because of duplicate suppression, they do not show up where they are expected (with the mailing list). I agree with this -- while I usually don't actually miss it, it's not where expect it. Depending on how I'm routing mail in a given week, it may end up on a different machine. Where is this policy stated? (I just looked into debian-policy, and /usr/doc/debian/mailing-list.txt, with no success). If indeed there is such a policy, it has been hidden quite succesfully. (I certainly don't remember this being ratified). It's in 2.1 of the _Developer's Reference_, which I guess doesn't make it policy, but it is written down. Don't break the setup for 90% to cater to 10%. I think you are in the 10% group, here. I don't think the ratio is that lob-sided. I think the main argument against the Reply-To: list munging is that you're more likely to send personal mail the list, from which you can't recover. The other way, if you forget, you send list mail to an individual -- it's relatively painless to resend it to the list. steve -- Steve Greenland -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: xlib6 vs. xlib6g
Will A package I'm maintaining, rosegarden, has come out with Will dependencies on xlib6 AND xlib6g. I didn't do this by hand, I left Will the shlibs stuff in the control file. Happened to me once with an X11 package of mine. You probably have a mixed libc5/libc6 system, and/or have left an old debian/substvars around. Will I would purge xlib6 from the system, but a lot of packages I need on Will a daily basis need xlib6. No problem --- just leave the xlib6 package. Will How do I correct this? If it helps, here is what I currently have (deleted some x* entries as xearth, xlockmore, xpdf, ...) etc) ii xbase 3.3.1-2Local clients and configuration required by ii xcompat 3.1.2-4X11R5 and X11R6 a.out compatibility librarie ii xcontrib3.3.1-1XFree contributed clients. ii xfnt100 3.3.1-2100dpi fonts for X servers ii xfnt75 3.3.1-275dpi fonts for X servers ii xfntbase3.3.1-2Standard fonts for X servers ii xfntpex 3.3.1-2Minimal fonts for PEX support in X servers ii xfntscl 3.3.1-2Scalable fonts for X servers ii xlib6 3.3.1-2Shared libraries required by X clients ii xlib6g 3.3.1-2Shared libraries required by X clients ii xlib6g-dev 3.3.1-2Include files and libraries for X client dev ii xmanpages 3.3.1-2Manual pages for X developers ii xpm4.7 3.4j-0.5 X Pixmap libraries (for libc5) - runtime ii xpm4g 3.4j-0.5 X Pixmap libraries (for libc6) - runtime ii xpm4g-dev 3.4j-0.5 X Pixmap libraries (for libc6) - development ii xserver-s3 3.3.1-2X server for S3-based graphics cards -- [EMAIL PROTECTED] According to the latest official figures, http://rosebud.ml.org/~edd 43% of all statistics are totally worthless. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
On 07-Dec-1997 12:43:00, Kai Henningsen [EMAIL PROTECTED] wrote: There don't seem to be many that match your definition of decent. (Incidentally, that's part of why I'm still thinking about writing my own.) Maybe we should make a list. You seem to like GNUS; obviously, that's no solution for people who hate Emacs. Try mutt, written by Michael Elkins (who was one of the leading elm patchers) and a host of others. Very configurable, very standards compliant. Two best features for handling mailing list: it threads, based on the In-Reply-To: header, or subject if the header is missing; and it handles the Reply-To: issue by letting you specify the names of the mailing lists you deal with in the config file, and when you press the list-reply key, it hunts the From, CC, (whatever) headers to look for a list name, and replies to *only* that. Other cool stuff: lots of features for handling multiple folders, like folder-hooks which let you change configuration parameters (headers, signature file, etc) based on which folder you're reading. Color support. Great MIME support, a browse-url (select from multiple). The ability to postpone a message you're sending, so you can go look at something else and come back to the original. Keystrokes are completely configurable, and you can change the configuration depending on which menu you're looking at (index, send, attach, etc) or if you're in the internal message pager. POP3 support. It's console based (ncurses or slang), it's fast, it has great support. Highly recommended. Checkout http://www.cs.hmc.edu/~me/mutt. steve -- Steve Greenland -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package: umich-ldap / WNPP: Dermot Bradley probably not maintaining packages
On 7 Dec 1997, Ed Donovan wrote: Some people on debian user had been sharing user-versions of mrtg; I got the wrong idea, and thought I was facilitating further packaging work . I'm much happier to see that you *are* still working on the project; do excuse me. It's okay. Since I left my previous job in Feb I've not been on debian-user or debian-devel (the volume is too much to keep up with). As a result I've probably lost touch with what's happening. I see there are archives of the lists at www.debian.org so I'll monitor those in future. Dermot -- Dermot Bradley [EMAIL PROTECTED], [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: predepends on libc6?
James Troup wrote: And please don't judge other maintainers by your own standards, I for one, won't add gratuitous program calls to my postinsts just because someone said I should. Perhaps you would, that doesn't mean that 90% of the shared library maintainers would. So why did you add the call to ldconfig? So far you have not given any reasons. In fact, you seem to expect me to take your word for it, which is exactly what you object to here. I also think someone might have noticed by know if this vast majority of shared libraries were doing it wrong; don't you? Not if the call is merely unnecessary. If these packages are doing something wrong, then we have a problem. A bug, dear, the word is a bug. I am not your dear until you learn to be nice. So far I have not had any problems with them. Others have. RTFBA (#14212). Finally, the bug report number I asked for. BTW, even David, the ld.so author maintainer, says the packaging manual is wrong; are you *so* confident you're right and everybody else is wrong that you're going to tell him he's wrong too? I am not confident that I am right. I am not confident that the packaging manual is wrong. Confidence is what one has after examining the arguments, of which you have not provided any. Well, until now, I'll give you that. David Engel said: (#14212) | The policy manual is wrong. ldconfig should be called from the | postinst script. This is the only way to get the new library listed | in /etc/ld.so.cache, which is a must if the library isn't in /lib or | /usr/lib. Obviously, this does not apply to libraries which install in /lib or /usr/lib, such as libc6. I give up. So soon? We have strayed quite a way from my original question: what is it that the libc6 postinst does, that makes it necessary for gzip to pre-depend on it? (And everything else used by dpkg: textutils, sed, util-linux, update, tar, dpkg, findutils, shellutils, grep, mount, sysvutils, perl-base, elvis-tiny, hostname, login, fileutils, bash, debianutils). If libc6 could be restructured so that this is not necessary, then we can lose a whole lot of predependencies in one swoop. I do agree that gzip should get the predependency, since it doesn't make sense for it to be inconsistent with all those other packages. After all, it was only a nagging doubt. Of course, we still need new text for the packaging manual. Try as I might, I can not find a bug report to dpkg that addresses this. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
announcement lists
Now that we have email addresses for the packages (package-name@debian.org??) I'll raise something I thought about a while ago. Currently the only way that a maintainer knows about a new package is: a) they keep checking the sites b) someone tells them (often through a bug report) c) they have a program which checks for new versions at a site It would be nice to have an automated procedure so that package maintainers don't have to do this themselves. I can see two methods (and both are really needed): a) subscribe package@debian.org to the announcement lists (with a limit on the number of emails to be stored). b) be able to specify a URL which can be checked for changes - for instance: ftp://sunsite.doc.ic.ac.uk/linux/sunsite.unc-mirror/Incoming/SVGATextmode-* Am I just blathering on, or is this a workable and decent suggestion? Cheers Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Proxy server policy [was Re: gated]
On Sat, Dec 06, 1997 at 02:26:26PM -0600, [EMAIL PROTECTED] wrote: On 6 Dec, Dirk Eddelbuettel wrote: Dirk wget works for me behind a firewall at work. All it needs are the Dirk http_proxy and ftp_proxy environment variables pointing the correct Dirk proxy server. Manoj Would the installer script know how to set these variables? Does it have to ? They are exported from ~/.profile. Everyone in the worlds ~/.profile. Anyone who is going to need gated (or even know of its existance) will have no problem finding it at an ftp site listed in /usr/doc/gated (or something). Why make the package to complicated. This is one area where Windows has got a far better solution that Unix. I'm sure it's for technical regions, but I have at least ten different areas in which I set proxy servers and I'm fed up with it. We should have a standard place for these things - say: /etc/proxies http=http://www.proxy.company.com:80; ftp=ftp://ftpproxy.firewall.com; How about making this policy. I realise that most upstream packages will be harder to convert, but someone has to make a start. At least all debian originated packages can be made to use this. Thanks Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Can we learn something from RH 5.0?
On Sat, Dec 06, 1997 at 08:46:36PM -0600, David Engel wrote: On Sun, Dec 07, 1997 at 11:59:27AM +1100, Herbert Xu wrote: David Engel wrote: I only know of one real bug so far. They didn't apply the fix needed to use the NIS module from autofs with glibc. I found that problem Does there rpc.nfsd (or squid) leak? Wasn't that caused by glibc? If so, their's could leak. I didn't notice a patch in their .src.rpm for this particular bug. I still get this (with 2.0.30 and 2.1.70) using netstd 3.0-x, I have to downgrade to 2.16 for things to work. Doing a 130MB compile across NFS is great - just kill the daemon, restart it (temporary fix), download and install netstd-2.16 and watch the compile resume :-) On a related note, does anyone know how to use the kernel-based nfsd - i.e. what programs to use - I tried downloading the tar.gz mentioned in the kernel help docs, but couldn't get them to compile :-( Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
pentium specific packages
Now that ecgs has ben officially released, maybe it's time to think (again) about pentium/pro/K6/... specific packages. I think it would be good to have a section i586 which would contain pentium specific packages. I don't know how this conflict with the current dpkg* tools (such as dselect). I know that we could release packages like gzip-i586 (provides gzip). However this is far from an ideal solution. I've heard some pretty inpressive quotes regarding visible improvements when using ecgs and so it may well be used for more than just the odd package. I think we should take advantage of this, it would be a nice first if Debian can do this properly before the other distributions. Thanks Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
intention to package cftp
I'm going to package cftp (full screen FTP client) - upload on Monday :-) Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc5 backports problem
On Sun, Dec 07, 1997 at 10:12:29AM -0500, Alex Yukhimets wrote: Well, I guess then libc5 machines dedicated to backporting should have dpkg-dev from hamm installed. And upload newer dpkg-dev to bo-unstable for consistency. As well as patch from hamm, so that it is possible to unpack hamm packages. -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: predepends on libc6?
[EMAIL PROTECTED] (Richard Braakman) writes: So why did you add the call to ldconfig? Because it's necessary. Duh. As I say, try removing it from libreadline2's postinst. Why do you think the upgrade of bo - hamm is still so problematic? It's because we don't have a method for selective immediate configuration, so during upgrade of libreadline2 and libgdbm1 until ldconfig is run perl and bash are fubar. If you were right, the upgrade to bo - hamm would be much easier (and Scott would be out of a job ;-). So far you have not given any reasons. In fact, you seem to expect me to take your word for it, which is exactly what you object to here. I expect you to take the word of David Engel on it, yes. I also expect you to take into consideration the bug reports filed against packages which didn't do it. Am I lieing? Are they all lieing? Did they make those bug reports up in some big conspiracy against your precious packaging manual? I also think someone might have noticed by know if this vast majority of shared libraries were doing it wrong; don't you? Not if the call is merely unnecessary. Oh for god sakes' if you think it is, please prove me wrong. Categorically show that it is *never* necessary to run ldconfig. I dare you. BTW, even David, the ld.so author maintainer, says the packaging manual is wrong; are you *so* confident you're right and everybody else is wrong that you're going to tell him he's wrong too? I am not confident that I am right. Woo woo. I am not confident that the packaging manual is wrong. Why is it you are so obsessed with the packaging manual? Are you so convinced it's never wrong? Confidence is what one has after examining the arguments, of which you have not provided any. Oh, FFS, neither have you. What I have done is pointed you to the fact that over 90% of shared libraries do it, that many bugs have been filed against packages which didn't do it, and that the damn ld.so author and maintainer says it's the right thing to do. *You* have whined about the packaging manual saying it's not right. Now tell me, who has presented less in the way of evidence? David Engel said: (#14212) | The policy manual is wrong. ldconfig should be called from the | postinst script. This is the only way to get the new library listed | in /etc/ld.so.cache, which is a must if the library isn't in /lib or | /usr/lib. Obviously, this does not apply to libraries which install in /lib or /usr/lib, such as libc6. hilfy|18:48:39 ~ $dpkg -c /debian/hamm/hamm/binary-i386/interpreters/libguile2_1.2-3.deb [...] lrwxrwxrwx root/root 0 1997-10-30 06:48 usr/lib/libguile.so.2 - libguile.so.2.0.0 -rw-r--r-- root/root396892 1997-10-30 06:48 usr/lib/libguile.so.2.0.0 Oh really? (#14212 is against libguile2) I give up. So soon? We have strayed quite a way from my original question: what is it that the libc6 postinst does, that makes it necessary for gzip to pre-depend on it? I wasn't responding to that, I was responding to your bogus defence of the packaging manual. If libc6 could be restructured so that this is not necessary, then we can lose a whole lot of predependencies in one swoop. You're drastically missing the point (but hey, what's new). If gzip only depends on libc6 it's entirely possible for a libc6-based gzip to be unpacked *before* libc6. dpkg will then move on to the next deb to install, try to spawn gzip and fail miserably (gzip is linked with a non-existent libc6), everything falls apart rapidly from there. gzip *MUST* pre-depend on libc6. (To be more explicit (since that seems to be the order of the day), I'm imagining a situation of a person upgrading from bo to hamm doing something like this: dpkg -iEGOB gzip_1.2.4-18.deb ae_962_15.deb bc_1.04-2.deb blahdeblah libc6_2.0.5c-0.1.deb When dpkg tries to fork gzip -dc to unpack ae, it fails because libc6 isn't even unpacked yet. With a Pre-Depends this wouldn't happen, because gzip wouldn't even be unpacked before libc6 is installed (and configured, *but that's irrelevant here*) [dpkg does ordering on configuration and removal, not install] I do agree that gzip should get the predependency, since it doesn't make sense for it to be inconsistent with all those other packages. Now that is the single most lame reason I've yet to hear for a package to have a Pre-Depends:. Of course, we still need new text for the packaging manual. Try as I might, I can not find a bug report to dpkg that addresses this. Maybe there never was one, I said it was a long standing bug, not bug report. (Something you apparently missed). -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Midnight Commander orphaned?
Paul Seelig [EMAIL PROTECTED] writes: If nobody objects (i've cc'ed this message to the original maintainer Fernando Alegre [EMAIL PROTECTED]) i'd happily like to take over maintenance of this package. Do you have a libc6 setup? A package with a maintainer who can't do uploads for unstable is about as good as a package which is orphaned. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proxy server policy [was Re: gated]
On Sun, 7 Dec 1997, Adrian Bridgett wrote: This is one area where Windows has got a far better solution that Unix. I'm sure it's for technical regions, but I have at least ten different areas in which I set proxy servers and I'm fed up with it. We should have a standard place for these things - say: /etc/proxies http=http://www.proxy.company.com:80; ftp=ftp://ftpproxy.firewall.com; How about making this policy. I realise that most upstream packages will be harder to convert, but someone has to make a start. At least all debian originated packages can be made to use this. If you are going to do this then someone is going to have to decide on a format for that file. There are many different kinds of proxies out there :| Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pentium specific packages
How about a binary-pent directory with symlinks back to binary-i386 until a package is uploaded. Then we need to tell dselect(ftp) to get the packages from binary-pent instead of binary-i386. Is there an easy way to do this? (Also, if pentium clones also work with the ecgs compiled packages, maybe i586 is better than pent.) please : no symlinks to something. we have good tools (dselect, dftp), that can take care of the directory structures. symlinks only make everything bigger and confuse people. symlinks are convinient, but using dselect, dftp, deity or some other tool can be more convinient. and all these can or could work without symlinks, as the file location is listed in the Package file. andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pentium specific packages
On Sun, 7 Dec 1997, Andreas Jellinghaus wrote: How about a binary-pent directory with symlinks back to binary-i386 until a package is uploaded. Then we need to tell dselect(ftp) to get the packages from binary-pent instead of binary-i386. Is there an easy way to do this? (Also, if pentium clones also work with the ecgs compiled packages, maybe i586 is better than pent.) please : no symlinks to something. we have good tools (dselect, dftp), that can take care of the directory structures. symlinks only make everything bigger and confuse people. symlinks are convinient, but using dselect, dftp, deity or some other tool can be more convinient. and all these can or could work without symlinks, as the file location is listed in the Package file. Andreas, Can you compare: debian/dists/unstable/hamm/binary/admin/ debian/dists/unstable/hamm/binary-all/admin/ and explain how we should get rid of the symlinks in binary (which is itself a symlink to i386)? I'm basically proposing another platform which is backward compatable. Therefore, make the directory for the platform, and while we don't have a package of the new type, use the old type. However, I still haven't heard about the possibility of getting dselect's ftp to look at binary-pent or at the compatability of pentium clones. If we put everything in the same directory with different provides, etc, I feel like things will get really confusing, and defeating the purpose of having different directories for different architectures. Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
On Sun Dec 7 09:15:28 1997 + (Sekmadienis, 1997 m. gruodio 7 d. 11:15:28 +0200), Mark Baker wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Brian Mays) writes: Okay. I'm building a new unstable version of rxvt with backspace set to ^H. From this point on, Debian's rxvt policy will be to use ^H as backspace by default. Couldn't you force it to ^? instead? That would be far more sensible. Wouldn't it be better don't force people to use what they don't want? This only results in flamewars. There is lots of configuration files and convincing every application to do 'right thing' separately is quite tedious. Simple `reset' can set stty erase according to terminfo key_backspace. Sorry, but don't we keep on agreeing that the --- key generating DEL is the right thing to do ? I could have sworn that I've been in several discussions that resulted in that conclusion, with the caveat that people should be able to reverse the default easily if they feel the need, as a local configuration option. I must admit that I have got a little bored with the discussion at times, and may have skipped some of it. So if someone has a more powerful argument for ``--- generates BS'' than ``well they sound the same'' I'd like to hear it. I don't want to start a flame war, so feel free to mail me direct, and I'll summarise to the list. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-06
On Sat, Dec 6 1997 21:50 +0100 Richard Braakman writes: ... David Frey [EMAIL PROTECTED]: pax-2.1-3(Not DFSG-compliant?) Hmm. I uploaded pax a few weeks ago into non-free (this was Mark H. Colburn's version) But anyway, if I manage it to compile the Open-BSD pax, we'll have a free pax again! David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: intention to package cftp
On Sun, Dec 07, 1997 at 07:42:56PM +, James Troup wrote: Adrian Bridgett [EMAIL PROTECTED] writes: I'm going to package cftp (full screen FTP client) - upload on Monday :-) Umm, a little more information would be nice. I've only tried it for about a minute, but it basically comes up with a directory listing, which you can navigate around. The docs are in info format and I hadn't read them (and still havn't). It's a 44K deb if you want to try it :-) Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-06
David Frey wrote: On Sat, Dec 6 1997 21:50 +0100 Richard Braakman writes: David Frey [EMAIL PROTECTED]: pax-2.1-3(Not DFSG-compliant?) Hmm. I uploaded pax a few weeks ago into non-free (this was Mark H. Colburn's version) Let's see... I checked my archives, and I found an upload of pax-2.1-4 from you dated 13 Sep. Is that the one you mean? I suspect that that one was rejected, because it had Distribution: non-free as well as * recompiled for libc6. Uploads for the non-free part of unstable need a Distribution: unstable and a section non-free/foo. This one went to the old non-free. But anyway, if I manage it to compile the Open-BSD pax, we'll have a free pax again! Great :) What do you want me to put in the comment next to pax? Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
On Sun, 7 Dec 1997, Philip Hands wrote: Sorry, but don't we keep on agreeing that the --- key generating DEL is the right thing to do ? No, we don't. I could have sworn that I've been in several discussions that resulted in that conclusion, with the caveat that people should be able to reverse the default easily if they feel the need, as a local configuration option. I must admit that I have got a little bored with the discussion at times, and may have skipped some of it. So if someone has a more powerful argument for ``--- generates BS'' than ``well they sound the same'' I'd like to hear it. I started using PCs when the only choice for me was MS-DOS with probably MS-Windows 3.0 on it. Things were easy back then. The 'Backspace' key did 'Backspace' and the 'Delete' key did 'Delete', just like the letters on the keys said. A year ago I started using Linux and all of a sudden I got confronted with people who strongly believe that the 'Backspace' key should do 'Delete'. This is very, very confusing to me. Why don't you just let the keys do what is written on them? I don't want the 'A' key to generate a 'B' and I don't want my 'Backspace' key to do 'Delete'. I have a 'Delete' key for that. I just want to be able to use both the 'Backspace' key and the 'Delete' key on any VC, xterm or rxvt and I want them to do just what I expect them to do, which is the same as what they do in MS-DOS. Now, if I am seeing it totally wrong, then please explain it to me. Remco -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
