Re: locale errors
-BEGIN PGP MESSAGE- Version: 2.6.3 owGFU1FoHFUUTdGiHRDUDz/Mh7dISAK7m92k2W2imybpbm1aW6ONSCUwfTt7Z/eR mfeW995ks/VDBJUWIRaqIOiHP6WC+FcQwUqp2g+L9ENBahXpT0Hqlyjoh+K9M0m7 1VDfwsybfe+ee8+5554cePue7QMTZx8/9sng0T1fXj2TbNvWHb934NQH62/MXfn0 tx9O/HhudXfxwfDb0Y+vvqPe+/Ds2LO/PpqrPX/gr+250+5CcOPSY6/g4NhS/feH qpevv3Xim2tHTvy0cuWJwYvvf3/p5Nd/PhJ+d+7c05/tL7/28O4DZ/wd9Ru1N1// 6uc/vjgfXL95/vQD1/acuvzLrpd3zn2+fvbV6O/1597Nv3Tz6IWP7oPG/TYsliYn SpMDtJ5RUKrAgYReU1OVHMyjgsVQhCF0jXY47XkzsCLk7Eo7toUuWheKCFWhiTBy UEjYj0pJ1bKoRilAOrTTFDADMdoVtLNOd2zPOozTgEMyaAuM4FB6OApZCtBcQqFY LkxVQCp4MqjW6kOi6g91qrfih6JqfeHwkSV65KcqxXKpUioRid0v5seLE7MoFV2S qtCfbyarJH3MwGG9E47qBAKhlHaQWIRINoJJCHTckRE2oYMmgq50bWjxCUQ6IKp2 J7wgpINQGxAbWHxchlU0VlLtOsxChWoC0p891yZFwLZ1EjWhgRBKhSBaguq7XdFS W1qQNsfhgU6MxRwI6BjdiDAGhcJEPRAWLBqpE8tb1xYOREMnVL6LOwzmMTEHBkUU 9QqwiUq10NMmrC3BpKSOJaSRIPRhGCGwUBjGXGBBCMVhFEFodExZEJrSBolldqO5 lFdfcIxCWcA1Ebiox5FUVT7fRzyWrbYDFrmrzQpTYnl6Bc9bYgJUnTMJsW0Qj0iu YJqRCW2yz4F0wzZFaGlGdJo2ILqi56GwMmW6QAZF6Arl+JhU5up42xar9AGZDaDb RoPQ0CRA1m5i42X9o2wtI2LLClALcE1al2NQQ8MgFUHd7keqYCo6a4wwzhhGGIkW YqFkJ4mE22DRlGFISRXJkwOrQYbQI+Mx6pZ1NKTKgNL+OtNjFv8CZUmghY6K1cYk HYdN0vOIjGXERslxEqqcx4CcsJEiMzDZj1ycg/+SHk7HwCP541uC9iOUt0CYvAsC NxhprgQpzs1zRq5KEW2KaJlXKNcyR1FMb5gSWSfpyf0zOqH/pfImINbKtS2TIpzU VOSaplZcX2oXNiE4GSMXDiImWVQom8huIBU9q2Pk610GpwknFTtZEymOrC5bbByr o8TxCIvQoUmBS4UJmqaIbIaeReeIOCXu0uR6dbPqefm8twNg8alFWEwakQzgIPam ecJbBNAVEeHMhvr4cYmFgFXp0iQVsJl4WdC+9GLHkL2mYW4S5uZhfBIqNajMwb4a 7KrBvjrAfB3GS7CrAuUiFPdCbS+UKzBVJ4z/WT4tD/K0qtV8HvwtL43RD5Zvfab3 +Xp+xB/1fQZJcdLNxvWxZVjecSdKHrC5wZf8S40glRkqReIYH5bplcWmKRnH56++ 5CnQBswdemWFVXlRkD/GkX7OzyB8Ahjz03Ubrq8g6xK2gu1X/y5r2d9cVCh4/wA= =juyy -END PGP MESSAGE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
Damn, pinepgp is screwing up auto signatures. Sorry. === On 17 Jun 1997, Ben Pfaff wrote: [EMAIL PROTECTED] (Kai Henningsen) writes: [EMAIL PROTECTED] (Michael Meskes) wrote on 17.06.97 in [EMAIL PROTECTED]: No! You cannot use libc5 compiled perl with glibc locales! Wait for a libc6 version of perl and everything should be fine again. This is, of course, a problem nearly as serious as that about utmp. Not really. This is an issue only with `unstable' (as far as I can tell from the discussion), and `unstable' means exactly that--everything might not work properly. That is true, but like the utmp problem, it's not going to go away by itself. If we want to be able to have a system where both libc5 and libc6 programs can coexist, we run into a problem with utmp. The 2 libraries manipulate utmp differently, so if you run both libc5 and libc6 binaries that try to manipulate utmp, it gets corrupted. Similarly, if we install libc5 locale files, libc6 programs can't use them. If we install libc6 locale files, libc5 programs can't use them. These are not trivial problems to fix, and they'll still be around in 3 months if nothing is done in the mean time. I am confident that someone will come up with an elligant solution after the 1.3 release settles down. Erv -- PGP Public Key: finger [EMAIL PROTECTED] PGP Fingerprint: A5 AB 25 7D 7A FD 4D FE BE 21 47 60 0C DC 67 9E ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [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] .
Re: Debian target audience
On Jun 16, Alex Yukhimets wrote I am sorry to say, but you are wrong. Even on this list there were several postings regarding this matter. There are several known problems and who knows how many unknown. You just can't afford to experiment with production system this way. Anyway, I could take some burden on myself to compile libc5 counterparts, but on my 486DX2/66 with 2k/sec connection it would take years. Well, if it really is a production machine (people yell if it goes down, etc.) shouldn't it be tracking stable instead of unstable anyways? I don't think that kind of change (libc5 - libc6) can't be made without some amount of instability and experimenting well, unless we get only perfect developpers who recompile all their packages for libc6 at the same time. :) Christian pgpBkarpSIaRQ.pgp Description: PGP signature
Re: GNU stow
On Jun 17, Charles Briscoe-Smith wrote [snip] Finally, I'm looking at GSPreview (similar to ghostview) and UPS (the graphical debugger) with a view to packaging them. Anyone else working on these already? If memory serves, UPS is listed in Sven Packages Wanted FAQ. And I believe it's listed in the packages someone should do section, (as opposed to the packages someone is working on section). You might want to check for yourself, though. Christian pgpaOSTCg7aNg.pgp Description: PGP signature
Re: Debian target audience
On Jun 16, Alex Yukhimets wrote I am sorry to say, but you are wrong. Even on this list there were several postings regarding this matter. There are several known problems and who knows how many unknown. You just can't afford to experiment with production system this way. Anyway, I could take some burden on myself to compile libc5 counterparts, but on my 486DX2/66 with 2k/sec connection it would take years. Well, if it really is a production machine (people yell if it goes down, etc.) shouldn't it be tracking stable instead of unstable anyways? I don't think that kind of change (libc5 - libc6) can't be made without some amount of instability and experimenting well, unless we get only perfect developpers who recompile all their packages for libc6 at the same time. :) Christian Very good point, I can't agree more. That's what we expect from the hamm release: ALL packages recompiled with libc6. The only problem that commercial software won't be recompiled (or at least upgraded -- $$ issue) by that time. And of course, that would prevent to install hamm. Which means that I would be in situation equivalent of using rex NOW. What answer would I get on the bug report against rex package? -- It was fixed long time ago, upgrade to ...3.45-5.deb from bo. And it is fine, 'cause bo and rex are based on libc5, but if I'll be using bo at the time hamm is released I wouldn't have this possibility. That's why I would really encourage Debian community to behave more like respectable commercial distribution and give customer a choice: to install libc6 hamm OR have at least some support for bo while hamm is stable. Thank you. Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Taking my leave/Packages available
It is with great regret that I must give up my involvement with Debian. Between the large volumes of list mail every day and the other commitments in my life, I never seem to have proper time to devote to my packages or other projects of mine that have been on the back burner forever. Therefore, effective immediately, the following packages are available: svgalib (svgalib1, svgalib1-bin, svgalib1-dev, aout-svgalib which probably doesn't need any further updates) zgv xscreensaver xcolorsel pdksh With the exception of svgalib, there's not a lot to the packaging (and svgalib is pretty much dead so the only real changes are minor packaging tweaks), so there's not a lot of work involved. I will remain a loyal Debian user, however, and encourage the rest of you to keep up the good work :) -Larry -- Larry Daffner| Linux: Unleash the workstation in your PC! [EMAIL PROTECTED] / http://web2.airmail.net/vizzie/ One macine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man. --Elbert Hubbard -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
-BEGIN PGP SIGNED MESSAGE- Christian Schwarz [EMAIL PROTECTED] writes: On 15 Jun 1997, Ardo van Rangelrooij wrote: I have another policy issue which is related to topic 11 (see below). The current layout of Info entries in the main Info menu (in the file /usr/info/dir) looks rather messy. I found the following descrepencies: - not all packages are placed in an appropriate section - the descriptions are not formatted consequently - some sections are somewhat large (this is personal) - some descriptions are somewhat large (this is personal too) I believe we can do better. Therefor, I propose an extension/change to Section 3.2.3 of the Debian Policy Manual: Great! Thanks for the proposal. A few points though... - During install of an Info documents you MUST specify a section. Preferably use the section the package belongs to in the Debian distribution. As a starting point the dir file in the base-files package could already contain these sections, albeit empty. We could also use a different, sometimes more logical grouping. E.g., I'm using the following sections for the development packages: - compilers - linkers - interpreters - generators (i.e. bison, flex, gperf, etc.) - libraries - development tools (i.e. make, gdb, etc.) - internals (i.e. gdb-internals, stabs, etc.) If the Info doc has a lot of subentries, make a separate section for it, as has been done for the GNU file, text, shell, and shar utilities. I suggest that we define several sections which should be used. If someone has an info file which does not fit anywhere, he has to ask on debian-devel for it and it will eventually be added to the Policy Manual. I completely agree! The current structure (of packages installed on my system) is: Miscellaneous Development Document Preparation Information Emacs Programming teTeX Graphics Games General Commands Note, that only Miscellaneous has a colon (:) after it. This should be changed... On my system there's also Networking, Communication, and Console utilities. This made me think about using the package organization in the distribution as a starting point. Note, that AFAIK install-info automatically removes empty sections from the info dir. I think this is actually very good. I don't want to have all those empty section in the dir file of the base system. The removal of empty sections can be controlled by command line options (see the man page for an excellent explanation). I agree empty sections don't look good. - Start the description at a to-be-determined fixed position, e.g. first line at position 41 and second and subsequent lines at position 43. This unclutters the layout, but the positions should be such to leave enough room for a short, one-line, to-the-point decription. Can't we simply change install-info to do this automatically? This would make it a lot easier... I was thinking the same and see three possibilities to handle this: 1. using install-info directly with correct command line options 2. using a script (implicit call of install-info using the default positions, possibly with override if absolutely necessary) 3. hard-coded in install-info (i.e. change current defaults values) Option 3 is the most easiest, since it only requires the Info package maintainer to handle things. Options 1 and 2 require all packages containing an Info file to be updated, either to call the script or to change the currently used command line. Option 2 is in fact the soft-coded version of option 3. Initially, I would say we go for option 3, since I assume the Info package is not that often affected by a new upstream version. However, handling the empty section removal may make option 2 more suitable, unless we hard code that in install-info itself too. - Instead of using the upstream provided description, provide an own one-line one which fits on the same line as the menu entry. A three line description for awk may be nice but clutters the layout, e.g. Correct. (For example, the Make entry is _way_ too long.) In the light of topic 11 the above may be not that important anymore, but if we plan to keep Info docs around (I have not heard otherwise yet) I believe we should discuss the above. I'm sure the info docs will be available in the future! The question of topic 11 was which format the .deb's should ship: - only info; html in extra .deb - only html; info in extra .deb - html _and_ info I was also wondering whether we plan to organize the documentation under dwww in a way similar to the Info docs (sectioning, layout, etc.). Anybody some thoughts on this? I think Jim was working on such an enhancement for dwww. We should ask him when his is back. Cheers, Chris
Re: hamm and dftp
On 17 Jun 1997, Kai Henningsen wrote: [EMAIL PROTECTED] (Douglas L Stewart) wrote on 16.06.97 in [EMAIL PROTECTED]: Is there a dftp.conf setup I can use that doesn't require me to do some sed work on the packages file? The paths are wrong for the mirrors in the one that's on the servers now. The paths in the Packages file certainly should not be wrong. What problem do you see? dists/unstable/main/binary-i386/admin/at_3.1.7-2.deb (3.1.7-2 vs 3.1.7-1) Here's my dftp.conf: ### # # Sample 'dftp' configuration file. See 'dftp --help' for more information. # # All settings made here can be overridden in the ~/.dftprc file or with # command-line settings. # # These settings mimic some of the internal defaults of 'dftp' include:hamm,contrib,non-free exclude: ftpsite:ftp.debian.org ftpdir: /debian/hamm -douglas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: locale errors
I wonder whether it's difficult to fix that. If I recall correctly most of the locale code in libc5 is from glibc anyway. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Erv Walter [SMTP:[EMAIL PROTECTED] Sent: Wednesday, June 18, 1997 1:55 AM To:Ben Pfaff Cc:Die Adresse des Empfängers ist unbekannt. Subject: Re: locale errors Damn, pinepgp is screwing up auto signatures. Sorry. === On 17 Jun 1997, Ben Pfaff wrote: [EMAIL PROTECTED] (Kai Henningsen) writes: [EMAIL PROTECTED] (Michael Meskes) wrote on 17.06.97 in [EMAIL PROTECTED]: No! You cannot use libc5 compiled perl with glibc locales! Wait for a libc6 version of perl and everything should be fine again. This is, of course, a problem nearly as serious as that about utmp. Not really. This is an issue only with `unstable' (as far as I can tell from the discussion), and `unstable' means exactly that--everything might not work properly. That is true, but like the utmp problem, it's not going to go away by itself. If we want to be able to have a system where both libc5 and libc6 programs can coexist, we run into a problem with utmp. The 2 libraries manipulate utmp differently, so if you run both libc5 and libc6 binaries that try to manipulate utmp, it gets corrupted. Similarly, if we install libc5 locale files, libc6 programs can't use them. If we install libc6 locale files, libc5 programs can't use them. These are not trivial problems to fix, and they'll still be around in 3 months if nothing is done in the mean time. I am confident that someone will come up with an elligant solution after the 1.3 release settles down. Erv -- PGP Public Key: finger [EMAIL PROTECTED] PGP Fingerprint: A5 AB 25 7D 7A FD 4D FE BE 21 47 60 0C DC 67 9E ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [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] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Obsolete package CGI-modules (hamm)
On 17 Jun 1997, Manoj Srivastava wrote: Hi, Scott == Scott K Ellis [EMAIL PROTECTED] writes: Scott Umm, actually perl5 only includes CGI.pm, and CGI::Apache, Scott Carp, Fast, Push, and Switch. The libs from CGI-modules are Scott NOT included. So we do still need a cgi-modules package, Scott although perhaps in a renamed and cleaned up state Scott (perl-cgi-modules), here's your chance to fix the Scott capitilization :) Oh, I see that now. I'll in that case continue to provide cgi modules, though I'll wait until there is a naming policy in effect for CPAN modules (lib-perl-cgi-modules?) I don't expect a Perl Module Policy to show up very soon, since there are lots of other changes we have to make to the Policy Manual now and the short discussion about the Perl stuff showed me, that we'll have to spend more time on this. So I suggest, you name the package according to the current (implicit) policy, namely libcgi-perl I may also then see if we need a lib-perl-cgi-pm package (depends on how frequently CGI.pm is updated relative to Perl itself) This would be called libcgi-pm-perl then. Cheers, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking my leave/Packages available
In article [EMAIL PROTECTED], Larry 'Daffy' Daffner [EMAIL PROTECTED] writes: svgalib (svgalib1, svgalib1-bin, svgalib1-dev, aout-svgalib which probably doesn't need any further updates) zgv I don't want those because I avoid svgalib and everything to do with it. xcolorsel pdksh I'll take these two though. However I don't use pdksh myself so if someone who uses it regularly wants it that might be better.
Re: Taking my leave/Packages available
On Jun 17, Larry 'Daffy' Daffner wrote svgalib (svgalib1, svgalib1-bin, svgalib1-dev, aout-svgalib which probably doesn't need any further updates) zgv I'll take zgv, and I'm quite happy to have the svgalib ones too if nobody else wants them. Cheers, E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- The illusion is deep, it's as deep as the night, I can tell by your tears you remember it all. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
checker libs with debugging symbols
Is there a reason for the checker libraries to come with debugging symbols? I haven't used checker yet, so I don't know. But I assume that the libraries without debugging symbols would work. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Awful problem with dpkg
Hi: Trying to upgrade the machine of a colegue, I found and awful problem with dpkg I haven't managed to deal with. Apparently, the package database got corrupted somehow, preventing me from upgrading any package. For example, if I try to upgrade libc5 with dpkg -i libc5_5.4.23-6.deb I get (Reading database ... 15789 files and directories currently installed.) Preparing to replace libc5 5.4.20-1 (using libc5_5.4.23-6.deb) ... dpkg: failed to open package info file `/var/lib/dpkg/updates/07' for reading: No such file or directory dpkg: error processing libc5_5.4.23-6.deb (--install): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: libc5_5.4.23-6.deb Even more, upgrading dpkg doesn't work at all: (Reading database ... 15789 files and directories currently installed.) Preparing to replace dpkg 1.4.0.7 (using dpkg_1.4.0.8.deb) ... dpkg: failed to open package info file `/var/lib/dpkg/updates/07' for reading: No such file or directory dpkg: error processing dpkg_1.4.0.8.deb (--install): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: dpkg_1.4.0.8.deb Any clues on what may be happening? Regards, M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
Hi, This discussion seems to keep getting side tracked with ``program X does not support feature Y'' type statements. In the case of qmail at least, I'd just like to emphasise that every feature that I've wanted (or seen asked for on the qmail list), that is not explicitly included in qmail, can be reasonably easily implemented with other OS tools, and minor qmail configuration changes. I take this as an indication that the design of qmail is fundamentally correct, and that the inclusion of these features into qmail itself would in fact just be creeping featureism. The same goes for the claimed denial of service attack, which is really only a configuration/documentation problem. Admittedly, qmail would benefit from a few more HOWTO type documents, but that is where Debian can come in, with packages for ezmlm, maildir2smtp and uucp4qmail for instance, and things in /usr/doc/qmail/examples. Also admittedly, Dan Bernstein (djb) has a tendency to be rather blunt when writing to people with whom he disagrees, but this doesn't make any difference to the quality of qmail --- if anything it protects qmail from un-needed patches. I think we should seriously consider using qmail as our default MTA. It's only real weakness lies in it's documentation, and that should be reasonably easy to fix. I think we should also consider switching to Maildir/ format for mail drops, since it seems to be the only way for delivering mail securely over NFS. Cheers, Phil. P.S. people who want to try qmail should probably get hold of version 1.01 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Santiago Vila Doncel [EMAIL PROTECTED] wrote: On Mon, 16 Jun 1997, Brian C. White wrote: August 31, 1997 All packages depending on libc4 or libc5 will be removed. This is too much strong. I would suggest to make their associated bug (the one saying it's still libc5) almost-critical instead. How about this: Have the policy dictate that no packages may be compiled against libc4/5, and then move any packages that don't comply with the policy to 'contrib'. I believe that one of the reasons for having 'contrib' is to contain packages that we -could- distribute, but which don't fully comply with Debian policy? Simply to get the package back into the main distribution might be enough incentive to get packages rebuilt against libc6. Any obscure packages that missed getting rebuilt would end up under contrib. In fact, just moving libc4 and 5 to contrib would force any depending packages to go in contrib, too, without having to change policy. --Charles Briscoe-Smith White pages entry, with PGP key: URL:http://alethea.ukc.ac.uk/wp?95cpb4 PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
Chris Fearnley [EMAIL PROTECTED] writes: If I might speculate on my winning sendmail configuration strategy: ignore the irrelevant (like rule sets). Say you have three users who have accounts on your system, but their primary accounts are elsewhere. Now you want their email headers to be rewritten by *sendmail* to appear to come from their other provider so that it will be correct no matter what email client they use. This took me quite a while to figure out in sendmail. It requires (as far as I could tell) rewrite rules at just the right places to catch the relevant cases, both their fully qualified address, and their abbrevated local address. (I hear now there's a way to get sendmail to use a database for this, but I haven't gotten that to work yet.) Hence I would appreciate it if the MTA debate could focus on design criteria other than ease of configuration. I'm more interested in performance and design considerations that impact on security and the ability to configure (flexibility). Ease of configuration can directly impact the likelihood that the program will be set up properly, and hence be secure. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
Philip Hands wrote: I think we should seriously consider using qmail as our default MTA. It's only real weakness lies in it's documentation, and that should be reasonably easy to fix. AFAIK, qmail is highly antisocial WRT the number of connections it forces on a recipient host. This is not something I'd like to see as Debian default. -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
I think we should also consider switching to Maildir/ format for mail drops, since it seems to be the only way for delivering mail securely over NFS. I think we should try to stick with solutions that work with both Maildir and central spool directories, since otherwise it is difficult to maintain compatibility and interoperability with other Unix systems. This is especially important for my debian machines, as I have to keep them well integrated with SunOS 4.1.3, Solaris, and Irix machines in a way that is more-or-less seamless to my users. -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: inetd question
On Jun 17, Michael Meskes wrote: Yes, I use a proxy and both proxy and www-client run on the same machine. But it appears the ident calls came from my firewall where I run a http-gw. You're absolutely right that I should get rid of that traffic. There is no need for the firewall to ask identd on a local machine. But it should ask identd for connections from outside. Can I configure tcpd so that it only ask outside machines? Currently I have ALL:@@ALL in my /etc/hosts.allow file. Would it suffice to add a line http-gw: [EMAIL PROTECTED] Our local network is 172.26.0.0. I guess the following things would help: - replace ALL:@@ALL by ALL:ALL (no ident lookups by default) or maybe ALL EXCEPT http-gw:@@ALL (lookups for every service except http-gw) or - http-gw:172.26. @@ALL (or http-gw:172.26. [EMAIL PROTECTED]) This line would allow access from 172.26.x.x without ident lookup. Every other address would cause an ident lookup. or - use ipfwadm to protect the ident port Thanks, Peter -- Peter Tobias [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 3C -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Wed, 18 Jun 1997, Charles Briscoe-Smith wrote: How about this: Have the policy dictate that no packages may be compiled against libc4/5, and then move any packages that don't comply with the policy to 'contrib'. I believe that one of the reasons for having 'contrib' is to contain packages that we -could- distribute, but which don't fully comply with Debian policy? I like this solution the best of all the migration suggestions. This keeps us from removing perfectly good libc5 packages, but makes it clear that they are no longer part of the main distribution. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Corel Wordperfect and Java Office
On Sun, 15 Jun 1997, Raul Miller wrote: On Jun 6, Colin R. Telmer wrote I just noticed that Corel is just in the process porting Wordperfect 7 to Linux and the following is on the web page http://www.sdcorp.com/wplinux7.htm: Certified Operating Systems RedHat 2.0.18 Slackware 2.0.25 OpenLinux 1.0 Should we try to get Debian in there? Seems like a good idea to me. What's involved? Not much considering they use their own installation program, not .rpm as I previously thought. As long as the instalation conforms to the FSSTND it should work fine on debian. Shaya -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
-BEGIN PGP SIGNED MESSAGE- On Wed, 18 Jun 1997, Philip Hands wrote: I think we should also consider switching to Maildir/ format for mail drops, since it seems to be the only way for delivering mail securely over NFS. procmail does also deliver mail securely over NFS. (At least this is what the documentation says, I have not tested it personally). -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBM6gSBiqK7IlOjMLFAQFKggP/QG+9uhNoOaqizlBfN8SoB+dTd/TLp1AG 7xu5sfQle6jqWPuls2NGqIL3j40ScW+KrkQjRVsUd/NxzdVMFulalBOiaPFsKSXw waupV5tm4KhEHFSEeBpVUBvTSEka3CR4ia5xGBVl2cqZAXB+KpFBgKKiQdloTfM8 +yc9wJfApXs= =ff5x -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
XEmacs maintainer gone???!!
I just sent a message to [EMAIL PROTECTED] This transforms (correctly) into [EMAIL PROTECTED] scsn.net reports that there is no dres user on their system. Does this mean that the maintainer for XEMacs is gone? -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
I think we should also consider switching to Maildir/ format for mail drops, since it seems to be the only way for delivering mail securely over NFS. I think we should try to stick with solutions that work with both Maildir and central spool directories, since otherwise it is difficult to maintain compatibility and interoperability with other Unix systems. Agreed. qmail's default delivery method is specified on the command line (ver = 1.01), so this would be a simple configuration option. ``deliver'' could be used for central spool delivery, just as it is for sendmail. I wasn't saying that Maildir/ should be the only option, but since it is (or seems to be) the only secure option, why not make it the default for people who don't know the difference. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
Philip Hands wrote: I think we should seriously consider using qmail as our default MTA. It's only real weakness lies in it's documentation, and that should be reasonably easy to fix. AFAIK, qmail is highly antisocial WRT the number of connections it forces on a recipient host. This seems to be overstating the case somewhat. The default behaviour is to allow up to 20 (configurable) outgoing SMTP connections at a time. Since these will normally not all be to one host, this does not seem excessive. Of course, if you configure qmail to send all your outbound mail to a single machine (i.e. your ISP's mail server) then this would mean 20 connections, but in this situation you should be using serialmail (maildir2smtp), which would only open a single smtp session. I agree that if you just get the qmail sources and install them, without putting any effort into making sure the configuration is appropriate for your setup, that it can be sub-optimal. If on the other hand you consider qmail, and its ancillary packages as a whole, this is not the case. The debian packaging system gives us a major advantage here, in that we can have qmail suggest the other packages (serialmail, rmail etc) and have the post-installs set up an optimal configuration for the user. The package maintainers obviously need to keep up to speed on what the bes configuration might be, but the users shouldn't need to worry (unless they want to do something complicated). The problems that people (including me) have when moving to qmail seem to arise mostly from thinking that the optional extras are optional --- whereas you are likely to _require_ one or two of them. The documentation doesn't help here, because it basically says ``Just compile and Go'', but as I said before, that's something we could help to remedy. Once you realise that you need to ad some extra bits, you can set up a MTA that is properly tailored to your needs. This modular approach is what makes Unix great, and also works rather nicely for an MTA once you get used to it. IMHO Monolithic, all encompassing, MTA's are really against the spirit of Unix, and also tend to spawn security problems. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ftp problems to master
Hello! Currently it is impossible to ftp to master (even when logged in at master). All connections on port 21 are rejected. Could someone please look at it? Thanks, Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: Virtual Package Name List (was bug #10676)
-BEGIN PGP SIGNED MESSAGE-
Hi folks!
On Wed, 18 Jun 1997, Igor Grobman wrote (cf. bug #10676):
Package: debian-policy
Version: 2.1.3.3
X11R6 virtual package is not marked obsolete in virtual packages list. I
got bitten by this one when packaging dotfile generator. I suspect there
are some more unmarked virtual packages there, because only one package is
marked obsolete.
Oops! Thanks for pointing that out! I had just had a look at the complete
list and discovered lots of obsolete virtual packages. Thus, I want to
revise the whole list now.
Is it true, that the following virtual packages MAY NOT be used anymore?
X11R5 XFree86 R5, including base system (obsolete)
xR5shlibXFree86 R5 shared library only
X11R6 XFree86 R6, including base system
xR6shlibXFree86 R6 shared library only
xlibraries XFree86 R6 shared library or stub library
These packages are not being used currently. I suggest to remove this from
the list:
compressAnything that provides a true BSD compress command
sgmls An SGML parser which produces output compatible
with James Clark's sgmls and nsgmls parsers
There are now a packages called emacs and inews. Thus, I suggest to
remove these entries:
emacs Anything that provides the emacs editor
inews /usr/bin/inews - local or remote news poster
There is a virtual package imap-client which is suggested by imap-4
(Suggests: pine | imap-client) but no package seems to provide it. Thus, I
suggest to remove this entry, too:
imap-client Any mail reader capable of accessing remote mail
folders using the IMAP protocol (e.g. Pine)
I'd also like to remove the following, IMHO obsolete section:
Names of superseded packages Provided by the current ones:
--
gs_x, gs_svga, gs_both Provided by Ghostscript (gs). Use gs.
xpmR6 Provided by xpm. Use xpm.
So here is how the whole list would look like:
X Windows:
- --
xserver Any X server (used by other X packages)
Miscellaneous:
- --
libc.so.4 An a.out shared C library, version 4.x.x.
info-browserSomething that can browser GNU Info files
kernel-source Kernel source code
kernel-headers Kernel header files (linux/*.h, asm/*.h)
kernel-imageKernel image (vmlinuz, System.map, modules)
httpd Any HTTP server
postscript-viewer Anything that can display Postscript files
postscript-preview Any preprocessor that creates Postscript output
www-browser Something that can browse html files
awk Anything providing suitable /usr/bin/{awk,nawk}
c-shell Anything providing a suitable /usr/bin/csh
pdf-viewer Anything that can display PDF files
pdf-preview Any preprocessor that creates PDF output
wordlistAnything that provides /usr/dict/words
dotfile-module Anything that provides a module for the
Dotfile Generator
ups-monitor Anything that is capable of controlling an UPS
tcl-interpreter Anything that provides /usr/bin/tclsh
tk-interpreter Anything that provides /usr/bin/wish
News and Mail:
- --
mail-transport-agentMail transport agents (Smail, Sendmail, c)
mail-reader Mail user agents (Pine, Elm, mailx, c)
news-transport-system Local news system (INN, C News or B News)
news-reader Any news reader (trn, tin, c)
pgp A version of PGP (International or US)
imap-server Any IMAP mail server
- --
The following packages seem to be wrong:
ucbmpeg_play (2.3_patched-2) Recommends: X11R6
ucbmpeg (1r2-2) Recommends: X11R6
And what about xcompat?
Package: xcompat
Provides: X11R5, xr5shlib, aout-x11r6lib, X11R6
- --
Please tell me what you think of it. If there are no objections, these
changes will be incorporated into the next release of the Policy Manual.
Thanks,
Chris
- -- _,, Christian Schwarz
/ o \__ [EMAIL PROTECTED], [EMAIL PROTECTED],
! ___; [EMAIL PROTECTED], [EMAIL PROTECTED]
\ /
\\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
\ / http://fatman.mathematik.tu-muenchen.de/~schwarz/
- -.-.,---,-,-..---,-,-.,.-.-
DIE ENTE BLEIBT DRAUSSEN!
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
iQCVAwUBM6gdjk4c72jvRVaFAQFPjAQAjwlni+gFcW6M2lzgLsInbYPTPwxxdjp9
Ud7CPNWX/aESxXFiJqIjNZefEygKc+oa2ACCFv2RnZDgQheAwczwjWF5699rUtiG
Re: File Locking
Karl, thanks for the nice summary! On 16 Jun 1997, Karl M. Hegbloom wrote: [snip] mis en place: I know that there are several stand-alone programs for handling file-locking, and that the `procmail' package has a fairly good setup for that. INND apparently does as well; as does `mgetty-fax'. `lockfile' -- procmail `shlock' -- innd `newslock' -- mgetty-fax There is also: publib-0.26/liw/lockfile/* ** Publib looks like it might already be the library needing to be created that was mentioned earlier... or at least a very good start. Thanks for pointing that out! I just had a look at publib and the lockfile.c is really very concrete. (There is no documentation, though :-( ) If we choose to go with publib, someone would have to change the static lib into a shared one, but this is quite easy. [snip] Q: Who will do the work? This is really a good question. Don't we have a volunteer here on debian-devel? I am doubtful of my own ability to be of much help... I'd like to see what gets done by the programmer though. If you are intrested in doing it, we don't care if you have experience or not :-) I'd really like to have some people start working on this. I don't have much experience on this but I would try to get a first version running--unless noone else volunteers. Someone pointed out that it would be good to maintain this library as a new upstream library (non-debian specific) so that others can use it too (on other distributions or systems). Of course, we'd need a good upstream maintainer for that. So, if someone is intrested to help, please contact me! Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian-Policy Manual
On Sun, 15 Jun 1997, David Frey wrote: My comments on Christian's proposal (which is very good, thank you christian): TOPIC 1: policy for user and group ids (uids, gids) Wouldn't it be better to start the user uid range with 100 as most other Unices do? Sorry, but I don't get your point. The range from 100-999 is defined to be for local use of the sysadmin. However, packages can get dynamically UIDs in this range by calling `adduser --system', but only if the sysadmin has allowed this through the `/etc/adduser.conf' file. Or did I got your question wrong? Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
On Jun 18, Rob Browning wrote Say you have three users who have accounts on your system, but their primary accounts are elsewhere. Now you want their email headers to be rewritten by *sendmail* to appear to come from their other provider so that it will be correct no matter what email client they use. ... (I hear now there's a way to get sendmail to use a database for this, but I haven't gotten that to work yet.) This was something I worked with some time ago, when I was a sendmail guru. It's called userdb, is poorly documented in the bat book, and rarely documented elsewhere from the sendmail distribution proper. However, it *is* designed for precisely this problem. If anybody's still interested, I could dig up my old notes on how to do it. I remember you *do* need to have Berkeley's libdb active, though. qmail does this *much* better, BTW, which is part of the reason I moved to it. -- Graham Hughes [EMAIL PROTECTED] MIME PGP mail OK. (define pgp-fingerprint E9 B7 5F A0 F8 88 9E 1E 7C 62 D9 88 E1 03 29 5B) (require 'stddisclaim) pgpAGYr4FOmt0.pgp Description: PGP signature
leap second
The time is out of joint, o 'cursed spite. The U.S. National Institute of Standards and Technology will set it right on June 30, at one second before midnight UTC, by adding a leap second. Systems that run on POSIX time will ignore this. The effect is that they will consider the difference between the epoch and now to be 22 seconds less than it really is. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New packages: libcgi-perl and libcgi-pm-perl
Hi, Since perl 5.004 comes with CGI.pm and some stuff from CGI-modules, I took the liberty of removing CGI-modules. It has sice been pointed out to me that not all the libs in CGI-modules have been incorporated, so there is still some added value to that. There is also some value in having separate packages, since the CGI stuff may be upgraded faster than Perl itself. I am planning on releasing new packages libcgi-perl and libcgi-pm-perl, which shall conflict/replace CGI-modules and also replace: perl (since they replace some files there. Any objections? manoj -- Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off. Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
From: Thomas Koenig [EMAIL PROTECTED] AFAIK, qmail is highly antisocial WRT the number of connections it forces on a recipient host. It hasn't had this problem for several revisions. It limits the number of connections it tries to one system so that it won't hang a bunch of mail delivery daemons waiting for one down host. As far as I can tell, exim is a good choice for a system that supports a lot of users (because it reduces the overhead of delivery with mail filters on the local system). Qmail is good for a server or other special-purpose system. We run the list server and the bug system on qmail. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re^2: Debian's mail daemons
Am 16.06.97 schrieb efraim # argh.org ... Moin Alexander! AK sendmail: too complicated That's wrong. It's very easy to configure sendmail with the m4 scripts for a leaf site. And professionell system adminstrators will use sendmail because it's the standard MTA. And you should remember that the most Linux distributions use sendmail as MTA. In my opinion Debian should use sendmail as standard MTA. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re^2: Debian's mail daemons
Am 16.06.97 schrieb efraim # argh.org ... Moin Alexander! AK sendmail: too complicated That's wrong. It's very easy to configure sendmail with the m4 scripts for a leaf site. And professionell system adminstrators will use sendmail because it's the standard MTA. And you should remember that the most Linux distributions use sendmail as MTA. In my opinion Debian should use sendmail as standard MTA. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: File Locking
Christian == Christian Schwarz [EMAIL PROTECTED] writes:
Christian Karl, thanks for the nice summary!
You're welcome. :-)
Christian On 16 Jun 1997, Karl M. Hegbloom wrote:
** Publib looks like it might already be the library needing to
be created that was mentioned earlier... or at least a very
good start.
Christian Thanks for pointing that out! I just had a look at
Christian publib and the lockfile.c is really very
Christian concrete. (There is no documentation, though :-( )
No documentation? Sure there is. There's a manual page for every
function in the libc, and if you've got Emacs or XEmacs, and
`libc-mode', you can look up the docs in the TeXinfo with a few
keypushes. To read a manual page, just type {M-x man ENTER} and the
name of the manual you want. It defaults to the word the cursor was
on.
I wonder, should it utilize libuuid in some way? (I've a lot of
reading to do...) It seems that what should happen is that when a
lockfile is made, inside it should be the `sysid' of the computer
creating the lock, as well as the PID of the process on that computer.
I think the real way is for the `flock' structure, (through
fcntl.h) to contain a l_sysid field. With that, the kernel will
have a place to keep track of which machine holds the lock on a file.
It should be supported by the kernel-level nfs system, so that a
normal `flock', `fcntl', or `lockf' will work across nfs, without the
need for a dotfile kludge-hammer. I really need to read a lot more
about this type of thing. I've a feeling it will built into the next
major kernel release.
Christian If we choose to go with publib, someone would have to
Christian change the static lib into a shared one, but this is
Christian quite easy.
Ok.. Lars Wirzenius [EMAIL PROTECTED] is the author and maintainer of
publib. Lars, are you reading us?
Christian [snip]
Q: Who will do the work?
Christian This is really a good question. Don't we have a
Christian volunteer here on debian-devel?
I am doubtful of my own ability to be of much help... I'd like
to see what gets done by the programmer though.
Christian If you are intrested in doing it, we don't care if you
Christian have experience or not :-)
Ok, I'll try. I can learn as we go. I know how to use XEmacs and CVS
a little bit. (That's what I've been wasting my time on, instead of
doing math homework or ...)
Christian I'd really like to have some people start working on
Christian this. I don't have much experience on this but I would
Christian try to get a first version running--unless noone else
Christian volunteers.
Lars Wirzenius? What are your plans for publib?
I just saw the upload announcement for the latest `procmail' and
`smartlist' packages, and see that they have both just been GPL'd.
That means we can utilize the locking and `robustness' code from them,
methinks...
So, mainly, we need to put together a quick `liblockfile.so', and
then create a perl interface to it? Hmmm. I wonder if SWIG would do
that easily enough?
Well... I need to get out of the mailbox for a while, and spend the
day reading source code. (and I have a Scheme assignment to finish
today also.)
--
Karl M. Hegbloom [EMAIL PROTECTED]
http://www.inetarena.com/~karlheg
Portland, OR USA
Debian GNU 1.3 Linux 2.1.36 AMD K5 PR-133
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#10676: RFC: Virtual Package Name List (was bug #10676)
In article [EMAIL PROTECTED], Christian Schwarz [EMAIL PROTECTED] writes: There is a virtual package imap-client which is suggested by imap-4 (Suggests: pine | imap-client) but no package seems to provide it. Thus, I suggest to remove this entry, too: imap-client Any mail reader capable of accessing remote mail folders using the IMAP protocol (e.g. Pine) No, leave it. There are other imap clients (I didn't know about this package: I'll have to add it to TkRat). Without it, we'll just have suggests: pine, which is silly when any other imap client is just as good. I suggest we keep it, and file bugs against pine, tkrat and any others, and then remove the Suggests: pine from imap-4. Otherwise, everything you say that I know enough about to comment on looks fine.
