Re: DFSG: list restrictions, not freedoms
On Mon, Jan 25, 1999 at 03:44:04PM -0800, Chris Waters wrote: Rather than attempt to list all the freedoms that Debian guarantees, why not list the *restrictions* on freedom that we do allow, and say that any other restrictions violate our guidelines. I like your idea - I wonde what it would look like when fleshed out a bit more... It might be more susceptible to loopholes, though... -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote: If we must back out /var/mail (for no good technical reason that I can determine), then at the very least I think we should state that there that for all compliant distributions, /var/mail *MUST* be a valid way of reaching the spool directory (i.e., there should be a symlink there, or where the spool directory actually lives) If you include this change, will using ~/Mailbox violate the FHS? Does it already? Should it? Should we require symlinks from /var/mail/$USER to ~$USER/Mailbox? Switching a single one-user system to ~/Mailbox is easy, btw. Switching a single multi-user system to ~/Mailbox is likely to cause a certain amount of pain. Distributing applications to millions of people, some of whom use one convention, and some of whom use another, is surely asking for trouble. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ Computers are the tools of the devil. It is as simple as that. There is no monotheism strong enough that it cannot be shaken by Unix or any Microsoft product. The devil is real. He lives inside C programs. -- [EMAIL PROTECTED]
Re: filters: Licence problems
On Mon, Jan 25, 1999 at 11:18:05AM -0600, Marcelo E. Magallon wrote: On Sun, Jan 24, 1999 at 11:43:33PM -0500, Avery Pennarun wrote: [ interesting solution to exercise 1, which I'm not quoting to avoid rule (2), but I have to comply with anyway because I want this message to make its way to debian-devel, or debian-humour if it existed ] According to rule (0) you have to comply with (1), (2) and (3). From the text of rule (3), which I won't quote because of the previously expressed reasons, it seems as if it will always hold because the messages have to make it somehow to the lists and (3) doesn't say which DN has to be a FQDN so it applies to each and every one of them. [...] Excellent analyse! *lol* some people must be even more bored than me ... This mail would be cross posted to debian-humou^Hr, if it'd exist. (this gives me some nice ideas for rules about cross posting...) Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: filters: Licence problems
On Sun, Jan 24, 1999 at 08:13:14PM -0500, Raul Miller wrote: Ben Pfaff [EMAIL PROTECTED] wrote: Depends on the cat :-) Indeed. Now all we need is a way of petting /bin/cat, and we can automate payment. This one is easy. Install this as your cron job: grep straying /bin/cat; touch /bin/cat; free /bin/cat Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote: If we must back out /var/mail (for no good technical reason that I can determine), then at the very least I think we should state that there that for all compliant distributions, /var/mail *MUST* be a valid way of reaching the spool directory (i.e., there should be a symlink there, or where the spool directory actually lives) If you include this change, will using ~/Mailbox violate the FHS? Does it already? Should it? Should we require symlinks from /var/mail/$USER to ~$USER/Mailbox? Switching a single one-user system to ~/Mailbox is easy, btw. Switching a single multi-user system to ~/Mailbox is likely to cause a certain amount of pain. Distributing applications to millions of people, some of whom use one convention, and some of whom use another, is surely asking for trouble. ~/Mailbox systems are inherently local-setup anyway; they're going to need their own applications, unless they have the symlinks (I think there are special daemons to create link farms like that using a virtual NFS server.) -hpa
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
but I haven't heard any technical reasons besides, Moving spool directories is hard. When I and others have pointed out that moving the spool directory isn't required; just a symlink, I have heard dead silence. So the lack of technical discussion, but just a stony-silence No! is rather disappointing as far as I'm concerned. One simple one - I want my mail on the spool disk. Its in the grows randomly, mostly crap, doesnt cause hassle if it fills for a while category I have no problem with a both paths must one work one or more may be a symlink. At that point however the FHS should mandate one which may be a symlink only. Right now everyone uses /var/spool/mail whats the technical reason for using /var/mail that is good enough to justify the change ?
Re: Proposal: increasing mirror security
On Mon, 25 Jan 1999, Wichert Akkerman wrote: If people really want to be able to verify package integrity we might as well go the whole way. Ian Jackson posted (1.5 years ago I think) a proposal that would secure the complete stage from building a package to distribution on the mirrors. You might want to look that up in the list archives. I found what looks like the thread in reference on Feb 97: http://www.debian.org/Lists-Archives/debian-devel-9702/threads.html However, 1) half the month (and thead) is missing, and 2) it seems to detail getting the package into the mirror with little concern once it's there. I have a bit of faith in pgp signing the packages and uploading them. I'm a bit more concerned once it's there since users don't see these pgp signatures. If the package.gz file was signed, we would be pretty good, but apt and dselect can't handle that kind of change. So I'm proposing the file be signed but the signature being kept in a separate file. For the mirror maintainers, this involves: pgp -sab Packages mv Packages.asc Packages.pgp # or maybe we don't need this Thanks, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
One simple one - I want my mail on the spool disk. Its in the grows randomly, mostly crap, doesnt cause hassle if it fills for a while category That, I believe, is not the majority opinion. At most industrial sites, mail spool overflow is a major crisis. I have no problem with a both paths must one work one or more may be a symlink. At that point however the FHS should mandate one which may be a symlink only. Right now everyone uses /var/spool/mail whats the technical reason for using /var/mail that is good enough to justify the change ? 1. Interoperability with other systems. 2. Disk space management. -hpa
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
1. Interoperability with other systems. 10+ million Linux boxes use /var/spool/mail. Its also a spurious claim. All existing tools assume linux uses /var/spool/mail. Other systems even sharing via NFS dont get problems with this /var/spool usage 2. Disk space management. We've proved between us that both views are held here. This therefore is a rather spurious claim. A (maybe) symlink called /var/spool/mail that points somewhere arbitary is all that is needed for this issue. The FHS need say nothing else Your arguments don't IMHO hold water, nor in fact anything else
New logo strategy
Before I'm going to confuse people: I didn't mean to start the whole voting procedure this soon; I should have worded that better. After asking around a bit and seeing the reactions here it looks like most people would like to see a new logo. The license is also troublesome (and very hard to find on the webpage btw). I agree with James Treacy's observation that we will probably need two logos: one logo with a liberal license that people can just freely, and another, more restricted logo for things like official CD's and so. To phrase this in another way: we will have a logo that everyone can slap onto their webpage, t-shirts, posters, etc., and a logo that can be used for `official' products, like CD's made using our own iso-images. It would be very interesting to see what logo-sets people would come up with. Now we have to decide on how to choose the new logo. An obvious source would be a gimp-contest. That has already produced very nice results for other projects before. As has been demonstrated earlier it does not work if all developers have to choose amongst all submissions. Unless someone objects within 24 hours, I'll ask the gimp people about starting a contest. The final formal vote will also have `further discussion' and the current logo if you don't like the gimp-contest idea. To select the winner we should form a small group of developers to select a top-10 from all submissions and use those as the other options for the official vote. If people want to be in this group please drop me a note, otherwise I'll make a couple of suggestions myself (no, I'm not going to suggest myself). Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpmtTV1nXyx4.pgp Description: PGP signature
Debian booth at linuxworld, volenteers wanted
I just received confirmation that LinuxCentral is funding a booth at the LinuxWorld expo for debian. I'll be organizing it and I'm still looking for more volenteers to help man the booth so let me know if you'll be attending LinuxWorld. I'm also looking for a source to donate some CD's to give out, if anyone can give me any pointers. Also, today's the last day to register for free admission to the LinuxWorld show floor. -- see shy jo
RE: DFSG: list restrictions, not freedoms
Have you been looking at the current draft floating around? (latest revision is at: http://master.debian.org/~gecko/dfsg.text). It does that in part. It starts by listing the freedoms and then lists the acceptable restrictions. On 25-Jan-99 Chris Waters wrote: Rather than attempt to list all the freedoms that Debian guarantees, why not list the *restrictions* on freedom that we do allow, and say that any other restrictions violate our guidelines. -- = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = pgp2qU81Wfhk9.pgp Description: PGP signature
Re: Debian booth at linuxworld, volenteers wanted
Joey Hess [EMAIL PROTECTED] writes: I just received confirmation that LinuxCentral is funding a booth at the LinuxWorld expo for debian. I'll be organizing it and I'm still looking for more volenteers to help man the booth so let me know if you'll be attending LinuxWorld. Call me ignorant if you like, but when/where is it? Thanks, Dale -- +- pgp key available --+ | Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer| | [EMAIL PROTECTED]|http://www.clifton-labs.com | +--+
Re: Debian booth at linuxworld, volenteers wanted
On Mon, Jan 25, 1999 at 05:12:28PM -0800, Joey Hess wrote: I just received confirmation that LinuxCentral is funding a booth at the LinuxWorld expo for debian. I'll be organizing it and I'm still looking for more volenteers to help man the booth so let me know if you'll be attending LinuxWorld. I'm also looking for a source to donate some CD's to give out, if anyone can give me any pointers. I'll be there Tuesday to help out with the booth, and maybe stop by a bit Wednesday. Thursday I'm not sure about - it may depend on work, what I think of the conference, what my boss thinks, etc.. Ciao, -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
Re: Debian booth at linuxworld, volenteers wanted
Dale E. Martin wrote: Joey Hess [EMAIL PROTECTED] writes: I just received confirmation that LinuxCentral is funding a booth at the LinuxWorld expo for debian. I'll be organizing it and I'm still looking for more volenteers to help man the booth so let me know if you'll be attending LinuxWorld. Call me ignorant if you like, but when/where is it? Oh, it's in San Jose California, March 1-4th. More info at http://www.linuxworldexpo.com/ -- see shy jo
Re: Debian booth at linuxworld, volenteers wanted
On 25 Jan 1999, Dale E. Martin wrote: Joey Hess [EMAIL PROTECTED] writes: I just received confirmation that LinuxCentral is funding a booth at the LinuxWorld expo for debian. I'll be organizing it and I'm still looking for more volenteers to help man the booth so let me know if you'll be attending LinuxWorld. Call me ignorant if you like, but when/where is it? San Jose, CA. Why can't we have one in the UK? Matthew -- Elen sila lumenn' omentielvo [EMAIL PROTECTED], Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: Debian booth at linuxworld, volenteers wanted
On Mon, Jan 25, 1999 at 08:28:40PM -0500, Dale E. Martin wrote: Joey Hess [EMAIL PROTECTED] writes: I just received confirmation that LinuxCentral is funding a booth at the LinuxWorld expo for debian. I'll be organizing it and I'm still looking for more volenteers to help man the booth so let me know if you'll be attending LinuxWorld. Call me ignorant if you like, but when/where is it? San Jose - www.linuxworldexpo.com Ciao, -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
Alan Cox writes: 2. Disk space management. We've proved between us that both views are held here. This therefore is a rather spurious claim. A (maybe) symlink called /var/spool/mail that points somewhere arbitary is all that is needed for this issue. The FHS need say nothing else I have to agree with Alan on this. Disc space management is a sysadmin issue. Anyone who cares about protecting the mail spool from overfill *from other spools* (like the printer) is going to have to deal with is issue properly. That means putting /var/mail on a separate FS from /var/spool. As soon as you do that, I can't see any advantage to mandating /var/mail instead of /var/spool/mail. If you have a separate FS for mail, the choice boils down to a fer characters in /etc/fstab. Given that the default RedHat install dumps everything in one FS under / I don't see any practical benefit (from the disc space management point of view) of /var/mail over /var/spool/mail. Anyone who wishes to set up their system sanely is going to put /var and /tmp elsewhere anyway, so at that point they can decide whether they want another FS for mail. On big networks like the one we have here, it matters not, because the mail spool is on a central fileserver anyway. Again, the choice is a few characters in /etc/fstab. Although for Linux there a problem with NFS locking, but let's pretend they have been fixed for the sake of this discussion :-/ Regards, Richard
Re: New logo strategy
I'd like to thank Wichert for taking on this thankless task. I'd also like to ask that we set strict criteria for what constitutes a logo. I don't feel like going back through the archives, but the criteria I remember off the top of my head are: Works in B+W (the official version may, of course, be in color) Works both with and without text at the bottom (Debian GNU/Linux). You can ignore this point if Debian is an integral part of the logo. Not too detailed so it works in low resolution. I have the feeling I missed something important. If so, I'm sure someone will point out my oversight. :) Jay Treacy
Re: New logo strategy
On 25-Jan-99, 19:06 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote: I agree with James Treacy's observation that we will probably need two logos: one logo with a liberal license that people can just freely, and another, more restricted logo for things like official CD's and so. To phrase this in another way: we will have a logo that everyone can slap onto their webpage, t-shirts, posters, etc., and a logo that can be used for `official' products, like CD's made using our own iso-images. Sorry, I think this is a bad idea: 1. We have to agree on *two* logos :-). 2. Far more importantly, it fractures the identity of the logo, which is one of the major points of *having* a logo. 3. It's creates a first-class and second-class logo. Quite honestly, I think the logo for a organization built on and around free software ought to be free. Get a great logo, license it quite liberally, and stand back. If a few losers misuse it, what's the big deal? It's enough that the official CD images can be labeled Debian Official CD's, they don't need a separate logo. Other than that, I like your ideas of how to progress. Except that I like the chicken: it's simple, slightly elegant, and a great logo. And come on, who could really confuse it with a chicken? Steve
debhelper /usr/bin/passwd
Hi guys, I just updated my potato system. The only two packages that were being updated were debhelper and egcs-docs. I got a warning from dpkg that debhelper (it seemed) was trying to overwrite /usr/bin/passwd. Due to all of the trojan rumours flying around, I got a little scared. Also, I couldn't see why debhelper would want to overwrite /usr/bin/passwd. Any ideas? Is this something I should worry about? Thanks, -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Why /var/www? (Was: Where does 'www-data' come from?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why is the www data under /var/www, while ftpd's stuff is under /home/ftp? Ain't ftp probably more `var'iable than www data (incoming!)? I personally thing either the ftp hierarchy should go to /var/ftp, or the www data should move to /home/www (the latter I'd prefer). Bye, J - -- Jürgen A. Erhard eMail: [EMAIL PROTECTED] phone: (GERMANY) 0721 27326 My WebHome: http://members.tripod.com/~Juergen_Erhard Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories? -- Michael K. Johnson -BEGIN PGP SIGNATURE- Version: GnuPG v0.9.2 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjatDd8ACgkQ+EdE6uFQHp+bDgCfWXaJQPS2QTVBm2RKXuDszgAX dTQAn3ISOQaMYNF68rrbDAS9zohfbLlp =omRI -END PGP SIGNATURE-
Re: Why /var/www? (Was: Where does 'www-data' come from?)
Quoting Juergen A. Erhard ([EMAIL PROTECTED]): I personally thing either the ftp hierarchy should go to /var/ftp, or the www data should move to /home/www (the latter I'd prefer). /home/(ftp|www) is just plain ugly. (It's a real pain when you're trying to share nfs home dirs between web servers, for example.) I use /var/ftp on my own system (well, actually /var/local/ftp...) Mike Stone
Re: New logo strategy
Why don't we officially not have an official logo? If 5 years from now, everybody likes a certain unofficial logo (ie. Debian equivalent of the BSD daemon), we could go with that. Cheers, - Jim
Re: debhelper /usr/bin/passwd
In foo.debian-devel, you wrote: Hi guys, I just updated my potato system. The only two packages that were being updated were debhelper and egcs-docs. I got a warning from dpkg that debhelper (it seemed) was trying to overwrite /usr/bin/passwd. Due to all of the trojan rumours flying around, I got a little scared. Also, I couldn't see why debhelper would want to overwrite /usr/bin/passwd. Any ideas? Is this something I should worry about? Could you please post the version(s) you have and which mirror you got it from? The /usr/bin/passwd file should be owned by the 'passwd' package [bash]$ dpkg -S /usr/bin/passwd passwd: /usr/bin/passwd Also, the debhelper package should not overwrite /usr/bin/passwd... [bash]$ dpkg --listfiles debhelper |grep /usr/bin/ /usr/bin/dh_builddeb /usr/bin/dh_clean /usr/bin/dh_compress /usr/bin/dh_du /usr/bin/dh_fixperms /usr/bin/dh_gencontrol /usr/bin/dh_installchangelogs /usr/bin/dh_installcron /usr/bin/dh_installdeb /usr/bin/dh_installdebfiles /usr/bin/dh_installdirs /usr/bin/dh_installdocs /usr/bin/dh_installexamples /usr/bin/dh_installinit /usr/bin/dh_installmanpages /usr/bin/dh_installmenu /usr/bin/dh_makeshlibs /usr/bin/dh_md5sums /usr/bin/dh_movefiles /usr/bin/dh_shlibdeps /usr/bin/dh_strip /usr/bin/dh_suidregister /usr/bin/dh_testdir /usr/bin/dh_testroot /usr/bin/dh_testversion /usr/bin/dh_undocumented /usr/bin/dh_debstd /usr/bin/dh_installemacsen /usr/bin/dh_installwm /usr/bin/dh_link /usr/bin/dh_listpackages [bash]$ dpkg --status debhelper |egrep '^Version' Version: 1.2.27 [bash]$ dpkg --status passwd |egrep '^Version' Version: 980403-0.3 [bash]$ egrep '^deb' /etc/apt/sources.list deb http://http.us.debian.org/debian unstable main contrib non-free
Re: debhelper /usr/bin/passwd
Hi Mitch, Could you please post the version(s) you have and which mirror you got it from? Sure! chsh and chfn were also in debhelper! I got debhelper using dselect/apt. Here is all the info you requested: % cat /etc/apt/sources.list deb http://http.us.debian.org/debian unstable main contrib non-free deb http://non-us.debian.org/debian-non-US unstable non-US % dpkg -l debhelper ii debhelper 1.2.28 helper programs for debian/rules % dpkg --listfiles debhelper | grep /usr/bin/ /usr/bin/dh_builddeb /usr/bin/dh_clean /usr/bin/dh_compress /usr/bin/dh_du /usr/bin/dh_fixperms /usr/bin/dh_gencontrol /usr/bin/dh_installchangelogs /usr/bin/dh_installcron /usr/bin/dh_installdeb /usr/bin/dh_installdebfiles /usr/bin/dh_installdirs /usr/bin/dh_installdocs /usr/bin/dh_installexamples /usr/bin/dh_installinit /usr/bin/dh_installmanpages /usr/bin/dh_installmenu /usr/bin/dh_makeshlibs /usr/bin/dh_md5sums /usr/bin/dh_movefiles /usr/bin/dh_shlibdeps /usr/bin/dh_strip /usr/bin/dh_suidregister /usr/bin/dh_testdir /usr/bin/dh_testroot /usr/bin/dh_testversion /usr/bin/dh_undocumented /usr/bin/dh_debstd /usr/bin/dh_installemacsen /usr/bin/dh_installwm /usr/bin/dh_link /usr/bin/dh_listpackages /usr/bin/passwd /usr/bin/chsh /usr/bin/chfn Okay, I think we can be pretty sure the last three entries don't belong there. What do you think is the problem? Thanks, -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: New logo strategy
On 25-Jan-99, 21:11 (CST), Steve Greenland [EMAIL PROTECTED] wrote: 3. It's creates a first-class and second-class logo. It creates, of course. I just love looking like an illiterate boob in front of several thousand people... Steve
linux 2.2.0: System is 666kB
-BEGIN PGP SIGNED MESSAGE- Hm, now theres a worrisome compile message. :-) Anyway, for you early adopters, I've made source and debs available at: ftp.netgod.net/linux/v2.2 Heres the checksums: ca629746d5baa1f3024a780312c96e28 kernel-doc-2.2.0_2.2.0-1_all.deb 40d6ddb94ac0c0239a2a5b16818cbbdb kernel-headers-2.2.0_2.2.0-1_i386.deb 9079f07787cdeba5649b8daa651746ea kernel-image-2.2.0-i686_2.2.0-1_i386.deb 2be1baad527126c18d73f93f709758e1 kernel-source-2.2.0_2.2.0-1.diff.gz 35fa180e872cd6180ae0cab22730938f kernel-source-2.2.0_2.2.0-1.dsc 98354d9bbe92ded9bdf3255b41319e19 kernel-source-2.2.0_2.2.0-1_all.deb be94a0187a3ac4ad41442f967ddb11c3 kernel-source-2.2.0_2.2.0.orig.tar.gz - - PGP E4 70 6E 59 80 6A F5 78 63 32 BC FB 7A 08 53 4C __ _Debian GNU Johnie Ingram [EMAIL PROTECTED] mm mm / /(_)_ __ _ ___ __netgod irc.debian.org mm mm / / | | '_ \| | | \ \/ / m m m / /__| | | | | |_| |Yes, I'm Linus, and I am your God. mm mm \/_|_| |_|\__,_/_/\_\ -- Linus, keynote address, Expo 98 GO BLUE -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: latin1 iQCVAwUBNq1GthCswmGWXGp9AQGvqwP9G+9Fly7F61WBtBohQ8Rm3dhICZaMxikJ 7XL4wBrFvgXaW2HHAVSMgoK3QJMKbHYCsOvYHGqQF+OvC7XySgNxmSCG6/3kwnUd 7OVnWma6giQEhJ2lYVeQZXx/y9aNQkm/I48jDJwvGPRJ95smTUvjmkRsY/Yl9Zq7 7UKSeLnYQaU= =LEbq -END PGP SIGNATURE-
Re: debhelper /usr/bin/passwd
The $1E6 question is now (a) why debhelper has symlinks pointing passwd/ chfn/chsh to sysdb-wrapper, and (b) where sysdb-wrapper comes from. --Jeff
Re: debhelper /usr/bin/passwd
Ossama Othman wrote: Hi Mitch, Could you please post the version(s) you have and which mirror you got it from? Sure! chsh and chfn were also in debhelper! I got debhelper using dselect/apt. Here is all the info you requested: % cat /etc/apt/sources.list deb http://http.us.debian.org/debian unstable main contrib non-free deb http://non-us.debian.org/debian-non-US unstable non-US % dpkg -l debhelper ii debhelper 1.2.28 helper programs for debian/rules % dpkg --listfiles debhelper | grep /usr/bin/ /usr/bin/dh_builddeb /usr/bin/dh_clean /usr/bin/dh_compress /usr/bin/dh_du /usr/bin/dh_fixperms /usr/bin/dh_gencontrol /usr/bin/dh_installchangelogs /usr/bin/dh_installcron /usr/bin/dh_installdeb /usr/bin/dh_installdebfiles /usr/bin/dh_installdirs /usr/bin/dh_installdocs /usr/bin/dh_installexamples /usr/bin/dh_installinit /usr/bin/dh_installmanpages /usr/bin/dh_installmenu /usr/bin/dh_makeshlibs /usr/bin/dh_md5sums /usr/bin/dh_movefiles /usr/bin/dh_shlibdeps /usr/bin/dh_strip /usr/bin/dh_suidregister /usr/bin/dh_testdir /usr/bin/dh_testroot /usr/bin/dh_testversion /usr/bin/dh_undocumented /usr/bin/dh_debstd /usr/bin/dh_installemacsen /usr/bin/dh_installwm /usr/bin/dh_link /usr/bin/dh_listpackages /usr/bin/passwd /usr/bin/chsh /usr/bin/chfn Okay, I think we can be pretty sure the last three entries don't belong there. What do you think is the problem? Well, I got the deb and source and dsc from the mirror you pointed out, and it _does_ have these files as symlinks in them pointing to sysdb-wrapper. It doesn't look like a trojan (this weeks hot topic) because his pgp sig matches the md5sum of the tarfile, and the tarfile reproduces the symlinks in the resulting deb. So, I would just treat it as a bug. Please file a critical bug report against this package, or let me know if you don't and I will file it. I would downgrade your debhelper to 1.2.27 and reinstall the passwd package. Thanks for finding this bug. -Mitch pgpUf3EhA37to.pgp Description: PGP signature
WARNING: Re: debhelper /usr/bin/passwd
Good greif. I'm sorry about this snafu. You weren't hit by an exploit
attempt, just by a debhelper package I managed to leave some junk in. This
is fixed in version 1.2.29, and it only affected version 1.2.28.
Background:
Yesterday I fixed a bug in dh_link, bug #23255. That bug concerns a
different package that diverts /usr/bin/{passwd,chsh,chfn}, and needed to
set up some symlinks from sysdb-wrapper to them using dh_link. As I tested
dh_link, I created a debian/links file that generated those 3 symlinks. And
then I forgot to remove it and when debhelper built, it happily made the 3
symlinks in the binary package.
I'd say installing debhelper 1.2.28 with --force-conflicts is a _very_ bad
idea. So long as you don't force things dpkg won't let it install all the
way or remove /usr/bin/{passwd,chsh,chfn}. As I said, I've verified that
1.2.29 doesn't have this problem. If you install debhelper 1.2.29 and find
yourself missing /usr/bin/{passwd,chsh,chfn}, you'll have to reinstall
passwd.deb to get them back.
Ossama Othman wrote:
Hi Mitch,
Could you please post the version(s) you have and which mirror you
got it from?
Sure! chsh and chfn were also in debhelper! I got debhelper using
dselect/apt. Here is all the info you requested:
% cat /etc/apt/sources.list
deb http://http.us.debian.org/debian unstable main contrib non-free
deb http://non-us.debian.org/debian-non-US unstable non-US
% dpkg -l debhelper
ii debhelper 1.2.28 helper programs for debian/rules
% dpkg --listfiles debhelper | grep /usr/bin/
/usr/bin/dh_builddeb
/usr/bin/dh_clean
/usr/bin/dh_compress
/usr/bin/dh_du
/usr/bin/dh_fixperms
/usr/bin/dh_gencontrol
/usr/bin/dh_installchangelogs
/usr/bin/dh_installcron
/usr/bin/dh_installdeb
/usr/bin/dh_installdebfiles
/usr/bin/dh_installdirs
/usr/bin/dh_installdocs
/usr/bin/dh_installexamples
/usr/bin/dh_installinit
/usr/bin/dh_installmanpages
/usr/bin/dh_installmenu
/usr/bin/dh_makeshlibs
/usr/bin/dh_md5sums
/usr/bin/dh_movefiles
/usr/bin/dh_shlibdeps
/usr/bin/dh_strip
/usr/bin/dh_suidregister
/usr/bin/dh_testdir
/usr/bin/dh_testroot
/usr/bin/dh_testversion
/usr/bin/dh_undocumented
/usr/bin/dh_debstd
/usr/bin/dh_installemacsen
/usr/bin/dh_installwm
/usr/bin/dh_link
/usr/bin/dh_listpackages
/usr/bin/passwd
/usr/bin/chsh
/usr/bin/chfn
Okay, I think we can be pretty sure the last three entries don't belong
there. What do you think is the problem?
Thanks,
-Ossama
__
Ossama Othman [EMAIL PROTECTED]
58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
see shy jo
Re: debhelper /usr/bin/passwd
Hi Mitch, It doesn't look like a trojan (this weeks hot topic) because his pgp sig matches the md5sum of the tarfile, and the tarfile reproduces the symlinks in the resulting deb. Great! That's good to know. So, I would just treat it as a bug. Please file a critical bug report against this package, or let me know if you don't and I will file it. Okay, I'll do it right now. I would downgrade your debhelper to 1.2.27 and reinstall the passwd package. Thanks for finding this bug. No problem. I am glad that I was able to help. Thanks, -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: WARNING: Re: debhelper /usr/bin/passwd
Hi Joey, Thanks! I won't file that bug report now. :) -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: debhelper /usr/bin/passwd
In foo.debian-devel, I wrote: Well, I got the deb and source and dsc from the mirror you pointed out, and it _does_ have these files as symlinks in them pointing to sysdb-wrapper. It doesn't look like a trojan (this weeks hot topic) because his pgp sig matches the md5sum of the tarfile, and the tarfile reproduces the symlinks in the resulting deb. So, I would just treat it as a bug. Please file a critical bug report against this package, or let me know if you don't and I will file it. I would downgrade your debhelper to 1.2.27 and reinstall the passwd package. Thanks for finding this bug. John Goezen has uploaded an NMU of the package, I assume he already filed the bug, so feel free to ignore. -Mitch
Re: WARNING: Re: debhelper /usr/bin/passwd
Joey Hess wrote: I'd say installing debhelper 1.2.28 with --force-conflicts is a _very_ bad idea. Unfortunatly, it looks like the current version of dpkg has --force-overwrite (which is what I meant to say above) enabled by default. And so anyone who ran dselect in the past 24 hours and upgraded from unstable has probably beeen bitten by this bad package. -- see shy jo
RE: New logo strategy
-BEGIN PGP SIGNED MESSAGE- On 26-Jan-99 Wichert Akkerman wrote: [snipped the original] I'm all for this, lock stock and barrel. To select the winner we should form a small group of developers to select a top-10 from all submissions and use those as the other options for the official vote. If people want to be in this group please drop me a note, otherwise I'll make a couple of suggestions myself (no, I'm not going to suggest myself). I will suggest you, then. Since you got the ball rolling, you have an interest in see it done. I think you should be one of those to decide on the final contestant logos. - -- = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNq1cwbbps1lIfUYBAQHABgQAip5iRKEf1ziM1LSDf+UluM+XfYltdPZM Z1rUebHXuHxhXQ6SgdBestZdgS+oDt/V5traZczLUFGQuZUhHjdevKoEYNJcbd1r +FuFBaFe+e1MPIVXXTsjLogcK8ziUFsp9zCfAts8PXyB3WUjgJwiavLMX4w8tpxv Z4IdSIgrZOo= =EB95 -END PGP SIGNATURE-
skkinput sigsegvs applications
Package: skkinput (BVersion: 2.01-1 (B (BHi, (B (BI try to use skkinput in my gtk application. Everything's OK with the (Bexception of this: (B- if skkinput is open when I close my application, then my application (Bsigsegvs. If the skkinput has no windows opened, than my application (Bexits normally. (B (BAny ideas ? (B (Bgtk/glib: 1.1.13 (Bdebian: potato (B (BIonutz (B (BPS: I will post this to bug tracking system though I don't know if this (Bshould be done for Debian or Debian-Jp. I'll post it for Debian bug (Btracking system. If wrong, please tell me where should I post this !
Re: New logo strategy
-BEGIN PGP SIGNED MESSAGE- On 26-Jan-99 James A. Treacy wrote: I'd like to thank Wichert for taking on this thankless task. I'd also like to ask that we set strict criteria for what constitutes a logo. I don't feel like going back through the archives, but the criteria I remember off the top of my head are: Works in B+W (the official version may, of course, be in color) Works both with and without text at the bottom (Debian GNU/Linux). You can ignore this point if Debian is an integral part of the logo. Not too detailed so it works in low resolution. I have the feeling I missed something important. If so, I'm sure someone will point out my oversight. :) Easily scaleable would be nice... - -- = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNq1debbps1lIfUYBAQEJdQP/cTVhiP8G8Yh0V/gTl0/yTw2/Celh3NKO gKqVwyP4nU8RX7BTLGRPQQQg7ybZ+8FUbsmnVYB5eVYMPc9429CVWN0pwYhFSu3Y wbpauN7gYqdY1QeJdPZRWNBYThjF6s0fOFD0ZXm0vjT3lIyXrYQusbljGxt8R3lW 5ro6vFEHUN4= =atgs -END PGP SIGNATURE-
Re: the Great X Reorganization, package splits, and renaming
On Mon, Jan 25, 1999 at 02:18:56PM +0100, Santiago Vila wrote: On Mon, 25 Jan 1999, Branden Robinson wrote: You have yet to explain what will BREAK if people continue to use the old font packages. Not in the future, RIGHT NOW. Oh, you have yet to explain why a clock bomb is *not* a bad thing. Surely, it will exploit, but not now ;-) But it won't. I agree with Branden on this point. What's the problem, other than that you think someday it will explode? I think it won't. Who wins? My guess is that by the time potato is released, some kind soul will have implemented package renaming in dpkg. In that case, all future releases of Debian will have the problem solved. In slink, there's no problem other than your supposed time bomb, the existence of which is arguable at best. I propose a solution (which is the only *viable* solution, since we can't guarantee that dpkg will be changed), and you say it's uglier than the hell. It is ugly. Twiddling with dpkg in the xbase package (tell dpkg to select all xfonts packages corresponding to the installed xfnt packages) kind of appeals to me, but I'll respect Branden if he doesn't want to try it, particularly while slink is in deep freeze. (Specifically: we could do it sort of like the menu package does, postponing the activity until after dpkg releases its lock. It won't fix things immediately, but the changes will show up next time through dselect.) It would compound the error to reverse the name change. Yup. Very sorry for posting a me too message, but I thought it might be needed. (I suspect that the infamous Debian silent majority effect is kicking in again.) Have fun, Avery
Re: New logo strategy
On Mon, Jan 25, 1999 at 09:11:47PM -0600, Steve Greenland wrote: On 25-Jan-99, 19:06 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote: I agree with James Treacy's observation that we will probably need two logos: one logo with a liberal license that people can just freely, and another, more restricted logo for things like official CD's and so. To phrase this in another way: we will have a logo that everyone can slap onto their webpage, t-shirts, posters, etc., and a logo that can be used for `official' products, like CD's made using our own iso-images. Sorry, I think this is a bad idea: 1. We have to agree on *two* logos :-). It's actually a good idea, and solves quite a few problems with the licensing issues. The liberal logo is something cool-looking that says Debian in some way, that everyone can plaster all over CD's, books, web pages, and so on. The restricted logo is more like a certification -- think Intel Inside and Yes! It works with Netware here. Visions of little swirlies. It would only be allowed to appear on official merchandise that is certified to really be Debian, like official CD's. This one is probably black and white, and quite simple, and says something like Certified Debian. Notice how Novell's logo is quite different from the Yes! logo, and how Intel Inside is very different from Intel's logo. And guys, when worrying about licensing issues, remember that unless we get these things trademarked, anyone who produces a rather similar looking certification graphic will be free to use it wherever they want. You can only use copyright law to sublicense the _exact_ image file and derived works, NOT similar-looking art. (But if it uses the word Debian it's probably covered under other trademarks. IANAL.) Have fun, Avery
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
From: Alan Cox [EMAIL PROTECTED] Date: Tue, 26 Jan 1999 00:15:37 + (GMT) but I haven't heard any technical reasons besides, Moving spool directories is hard. When I and others have pointed out that moving the spool directory isn't required; just a symlink, I have heard dead silence. So the lack of technical discussion, but just a stony-silence No! is rather disappointing as far as I'm concerned. One simple one - I want my mail on the spool disk. Its in the grows randomly, mostly crap, doesnt cause hassle if it fills for a while category But I don't think the FHS should be specifying the actual location of the files at all. True, the FHS should not cause too much pain for the certain obvious and common partition layouts, but once we enter the realm of server systems, there's no guarantee where the mountpoints might end up falling. For example, I might want the mail files on /u1, and the printer spool files in /u2 --- in which case there will probably a number of symlinks in /var and /var/spool. The only thing that really matters is what pathnames applications can count upon to work. Given that the rest of the world is moving to /var/mail, I think it would be good for us to start a gradual migration to /var/mail. The extra symlink doesn't cost anything, and gradually moving applications over to use /var/mail really doesn't cost much either. - Ted
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Mon, Jan 25, 1999 at 07:09:34PM -0500, Kragen Sitaker wrote: If we must back out /var/mail (for no good technical reason that I can determine), then at the very least I think we should state that there that for all compliant distributions, /var/mail *MUST* be a valid way of reaching the spool directory (i.e., there should be a symlink there, or where the spool directory actually lives) If you include this change, will using ~/Mailbox violate the FHS? Does it already? Should it? Should we require symlinks from /var/mail/$USER to ~$USER/Mailbox? I still want to know what /var/mail gains us over /var/spool/mail. I've asked many times of many people and all I have gotten back is that it's an issue of style or that mail isn't a spool (which I disagreed with).. I am curious for the answer to this, so far I have heard /var/mail is good and we all know it's good but the dists don't agree. So I ask in front of all of everybody in the hopes that maybe the answer will make sense, what technical reason is there for change now? If you want my opinion as I am SURE everybody does, /var/anything/mail is probably a bad plan from a least privileges standpoint. Qmail users are not the only people out there with ~/Mailbox setups and there are good reasons why, starting with security. The only argument against this I have ever seen is that not all mail users have home directories. While my machine is single-user and this isn't a problem for me, I have seen a few solutions to it. Switching a single one-user system to ~/Mailbox is easy, btw. Switching a single multi-user system to ~/Mailbox is likely to cause a certain amount of pain. Distributing applications to millions of people, some of whom use one convention, and some of whom use another, is surely asking for trouble. And then you have people who use MH or Maildir instead of traditional mbox. The only way to REALLY deal with it sanely is to read $MAIL and see what it says, I suspect. -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
unsibscribe
Hello , Best regards, Dmitry mailto:[EMAIL PROTECTED]
Re: New logo strategy
On Mon, 25 Jan 1999, James A. Treacy wrote: I'd like to thank Wichert for taking on this thankless task. I'd also like to ask that we set strict criteria for what constitutes a logo. I don't feel like going back through the archives, but the criteria I remember off the top of my head are: Works in B+W (the official version may, of course, be in color) Works both with and without text at the bottom (Debian GNU/Linux). You can ignore this point if Debian is an integral part of the logo. Not too detailed so it works in low resolution. I have the feeling I missed something important. If so, I'm sure someone will point out my oversight. :) It should also not be linux-specific (this is my suggestion) - we do have debian GNU/Hurd you know :) Matthew -- Elen sila lumenn' omentielvo [EMAIL PROTECTED], Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: I'm a concerned about slink. specifically jdk1.1, idraw, and xaw-wrappers
Dale E. Martin wrote Then I tried to use idraw, which I've used in the past a _bunch_ of times. It keeps segmentation faulting on me, and so I went to look at bugs.debian.org and the bug report about this is over 100 days old. ... and it is solved now :) Actually I have to say, if I would have been the one who was supposed to fix the bug, it would have taken me another hundred days, and probably I would have lost my last hair upon this ... But luckily, the upstream maintainer found the problem, which was related to the egcs c++ compiler. On another point, there is no other distribution which is featuring idraw, drawtool, flipbook and the InterViews library together with all the vector drawing libraries and Unidraw within ivtools. Just dropping that package because it was (temporarily) not possible to draw arrows seemed not appropriate to me .. Guenter
Re: Debian logo its license
On Sun, Jan 24, 1999 at 07:26:19AM -, Robert Woodcock wrote: Avery Pennarun wrote: What if someone gets hold of the Linux kernel and uses it to guide nuclear missiles? (Well, at least they have to share their changes with us :)) Only if they distribute the control systems : You've forgotten something. The military act as if they are above any laws. (If they cared about obeying laws, they would be disarming nuclear weapons under their international treaty obligations) Sorry to be political. Andrew
Re: Release notes for slink
On Thu, Jan 14, 1999 at 04:20:51PM +, Robert Woodcock wrote: Many of you are painfully aware that there are some issues in slink that are impractical to correct before release. snip xbase - xbase twm xterm xbase-clients xdm xf86setup How about adding that the xvidtune program is in the xf86setup package? Some users may be confident enough about their X configuration not to bother installing xf86setup, and then miss xvidtune. Andrew
Re: dpkg port to HP-UX
In article [EMAIL PROTECTED] you wrote: Hmmm. swinstall (HP-UX native I think) seems to support dependencies. It's pretty ugly though and I don't know if there's a command line version. Yes, you can drive swinstall from the command line. It's not pretty, but it works. Unfortunately, there's no real equivalent to debhelper for SD... and it could sorely use the help... :-) Bdale
Intend to package gnat-glade
GLADE is the implementation of the Distributed Systems Annex for GNAT, the GNU Ada95 compiler. Since there already is a GLADE (a Gtk GUI builder), I will call the package gnat-glade since this is really a GNAT add-on. Sam -- Samuel Tardieu -- [EMAIL PROTECTED]
Re: dpkg port to HP-UX
On Tue, Jan 26, 1999 at 02:22:13AM -0700, Bdale Garbee wrote: In article [EMAIL PROTECTED] you wrote: Hmmm. swinstall (HP-UX native I think) seems to support dependencies. It's pretty ugly though and I don't know if there's a command line version. Yes, you can drive swinstall from the command line. It's not pretty, but it works. Unfortunately, there's no real equivalent to debhelper for SD... and it could sorely use the help... :-) I'm yet to experience the pleasure of building a package for HP-UX; fortunately, it's quite likely that I'll manage to avoid it completely. :-) Hamish -- Hamish Moffatt VK3TYD [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
Re: Reality check! [was: Re: Debian goes big business?]
On Tue, Jan 26, 1999 at 09:33:16AM +1100, Craig Sanders wrote: hamm was released with a pre-selections wrapper, where you could chose certain sets of pre-selected packages. it works, but could use some improvement and probably needs to be updated for slink - there's a good place for you to expend your energy if you care about this. I has been updated for slink months ago (thanks to Stephane Bortzmeyer). Now we are just polishing the lists for the non-i386 architectures. Thanks, -- Enrique Zanardi[EMAIL PROTECTED]
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
At least that way applications that want to use the same dirctory as the vast majority of other Unix systems will work without needing a special case for Linux. However, I would much rather see us adopt the full, correct solution, rather than this half-measure. How can changing from /var/spool/mail to /var/mail be a full solution for the next years to come? Many people think that the mail-dir solution that e.g. qmail and mutt support is the real solution for the future. Maybe future Linux distributions want to ship that as a default? They couldn't be compliant with this standard even though they use a more modern mail-storing setup. The change from /var/spool/mail can be done on any system with an ln -s spool/mail /var/mail. Why mix up all Linux users instead of keeping this a local solution anybody can do? So maybe any standard should not say something about the mail spool dir? Florian La Roche
Re: linux 2.2.0: System is 666kB
On Mon, Jan 25, 1999 at 11:39:07PM -0500, Johnie Ingram wrote: Hm, now theres a worrisome compile message. :-) Anyway, for you early adopters, I've made source and debs available at: What about uploading everything but the kernel-image package for Slink, now that Bryan has said he will accept them? (BTW, is kernel-headers still needed? libc6-dev ships with a full set of headers, doesn't it?) -- Enrique Zanardi[EMAIL PROTECTED]
Re: linux 2.2.0: System is 666kB
Enrique Zanardi wrote: (BTW, is kernel-headers still needed? libc6-dev ships with a full set of headers, doesn't it?) Right, but those are for 2.0.36 and the ones that come with 2.1/2.2 are different (and yes, I need those new ones thus I have to manually edit the things in /usr/include everytime that libc6-dev gets upgraded). -Remco
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
The keyboard of Kragen Sitaker emitted at some point in time: On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote: If we must back out /var/mail (for no good technical reason that I can determine), then at the very least I think we should state that there that for all compliant distributions, /var/mail *MUST* be a valid way of reaching the spool directory (i.e., there should be a symlink there, or where the spool directory actually lives) If you include this change, will using ~/Mailbox violate the FHS? Does it already? Should it? Should we require symlinks from /var/mail/$USER to ~$USER/Mailbox? Hmm, and a mandatory symlink form $LOGNAME/Mailbox to /var/mail/$LOGNAME, and we will have established FHS compliant systems as those where email won't work any more. N.B. your phrasing was not POSIX compliant, tut, tut, tut. A good example how technically simple and conceptually irrelevant changes (from USER to LOGNAME) are still extremely dificult to achieve in practice. Switching a single one-user system to ~/Mailbox is easy, btw. Switching a single multi-user system to ~/Mailbox is likely to cause a certain amount of pain. Pain of no real benefit to the end user, as long as it works. Distributing applications to millions of people, some of whom use one convention, and some of whom use another, is surely asking for trouble. Yes, it is. arguing about it will make mpore pain. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
But I don't think the FHS should be specifying the actual location of the files at all. True, the FHS should not cause too much pain for the Ok good we agree on this The only thing that really matters is what pathnames applications can count upon to work. Given that the rest of the world is moving to Right now every package you build for linux assumes /var/spool/mail. I dont actually care what the rest of the world is doing. From a rather brutal point of view _we_ are becoming the rest of the world. /var/mail, I think it would be good for us to start a gradual migration to /var/mail. The extra symlink doesn't cost anything, and gradually moving applications over to use /var/mail really doesn't cost much either. By the time we migrate to /var/mail and annoy alll the vendors - netscape, applix, zmail and the like the old style unix mail format will be dying. It seems to be pain for the sake of it. If all the Linux vendors already used /var/mail and you said lets use /var/spool/mail I'd be equally opposed.
Re: getting kernel 2.2 into slink
[EMAIL PROTECTED] wrote: I think it would be great for Debian to get 2.2 in to slink, even if it is priority extra. I agree it should be included. We can change the priority so it's not automatically installed and warn people that it is experimental/might break things in dselect's description. -- Regards,| Debian GNU/ __ o http://www.debian.org . |/ / _ _ _ _ _ __ __ Randy | / /__ / / / \// //_// \ \/ / ([EMAIL PROTECTED]) | // /_/ /_/\/ /___/ /_/\_\ http://www.golgotha.net | because lockups should only be for convicts.
Re: the Great X Reorganization, package splits, and renaming
On Tue, 26 Jan 1999, Avery Pennarun wrote: On Mon, Jan 25, 1999 at 02:18:56PM +0100, Santiago Vila wrote: On Mon, 25 Jan 1999, Branden Robinson wrote: You have yet to explain what will BREAK if people continue to use the old font packages. Not in the future, RIGHT NOW. Oh, you have yet to explain why a clock bomb is *not* a bad thing. Surely, it will exploit, but not now ;-) But it won't. I agree with Branden on this point. What's the problem, other than that you think someday it will explode? I think it won't. Who wins? Maybe I didn't explain well: Can you *guarantee* that the package now called xfonts-base will *always* have the same functionality and will always be *identical* to the one called xfntbase in hamm? Can you *guarantee* that the package now called xlib6g-static will *always* have the same functionality and will always be *identical* to the one called xslibg in hamm? I don't think you can, unless you have a crystal ball. My guess is that by the time potato is released, some kind soul will have implemented package renaming in dpkg. But then it could be too late. Sorry but this is vaporware. It is not wise at all to rely on features that have not been implemented yet. As Joseph Carter says: Show me the code or get out of my way. BTW: I see a contradiction here... If you and Branden are so sure that package ranaming will be implemented in dpkg for potato, why does not Branden just postpone all the package renamings to potato to do it the right way? Frankly, I'm very suprised how low do you value the userfriendliness of the system, the smoothness of the upgrades and the overall quality of Debian. I can't accept I create a problem today and will fix it tomorrow or worse problem? what's the problem?. Upgrading a system from hamm to slink should make the system to be in the same state as if slink had been installed from scratch. Otherwise, Debian will become just a W95 clone very soon (have you ever asked yourself why people reinstall W95 so often?). -- 771ffa7eca98abefb0b0a12f36d4dc17 (a truly random sig)
Re: LSH (GPL'd SSH)
On Mon, Jan 25, 1999 at 16:49:57 -0500, Ben Collins wrote: NOTE: For those that are on the ball, they do seem to be considering removing idea from the base source and having it as a seperate module (similar to GnuPG's approach). Another freeness issue (albeit a relatively minor one) is that currently lsh requires scsh (which is non-free) for the generation of include files (they are pregenerated in the tarball; the scsh scripts are needed only for development). It would be nice if someone could modify them to work with a free Scheme implementation (say Guile), or reimplement them in another free scripting language (perl, python etc.). Ray -- Tevens ben ik van mening dat Nederland overdekt dient te worden.
Re: xxgdb should get pulled
On Fri, Jan 22, 1999 at 16:34:58 -0500, Daniel Martin wrote: [my rant deleted] I have yet to learn how to navigate this area, and am often surprised at how strongly an offhand comment is taken. Smilies might have helped. In this case, your comment really triggered me. I seldomly flame, but in this case, I felt it was justified. I'm looking closely at Code Medic now. (Though I'm surprised it isn't already on the wnpp list) The problem with Code Medic is that it is fit for contrib at best; I don't recall its license, but it depends on a GUI library that's non-free (not for commercial use IIRC). Ray -- Tevens ben ik van mening dat Nederland overdekt dient te worden.
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Mon, Jan 25, 1999 at 10:33:27PM -0800, Joseph Carter wrote: On Mon, Jan 25, 1999 at 07:09:34PM -0500, Kragen Sitaker wrote: If we must back out /var/mail (for no good technical reason that I can determine), then at the very least I think we should state that there that for all compliant distributions, /var/mail *MUST* be a valid way of reaching the spool directory (i.e., there should be a symlink there, or where the spool directory actually lives) If you include this change, will using ~/Mailbox violate the FHS? Does it already? Should it? Should we require symlinks from /var/mail/$USER to ~$USER/Mailbox? I still want to know what /var/mail gains us over /var/spool/mail. I've asked many times of many people and all I have gotten back is that it's an issue of style or that mail isn't a spool (which I disagreed with).. I am curious for the answer to this, so far I have heard /var/mail is good and we all know it's good but the dists don't agree. So I ask in front of all of everybody in the hopes that maybe the answer will make sense, what technical reason is there for change now? marketing b/s boots on I'll give you one solid reason, uniformity across unix platforms is a must have if unix, especially free unices, are going to succesfully dominate the market. Sun/AIX/HP-UX/OSF/SCO are not going to change, but we could prove our willingess and ability to ensure these uniformities. marketing b/s boots off If you want my opinion as I am SURE everybody does, /var/anything/mail is probably a bad plan from a least privileges standpoint. Qmail users are not the only people out there with ~/Mailbox setups and there are good reasons why, starting with security. The only argument against this I have ever seen is that not all mail users have home directories. While my machine is single-user and this isn't a problem for me, I have seen a few solutions to it. I don't see a connection between /var/spool/mail or /var/mail and home directories or priviliedges. IOW, how does one lend itself better to the task at hand? Since there is no real concrete reason to use /var/mail over /var/spool/mail except for meeting a standard filesystem concept (which is, uh, what we are trying to do) then maybe people need to look at it from that stand point instead what's better about it. We could put mail in /usr/var/mymail/whereIwantit/ and it would work just as well as far as the system is concerned. What we need to decide is, do we want to go with the standard, or make a new standard simply because we don't want to change? -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: New logo strategy
I agree with James Treacy's observation that we will probably need two logos: one logo with a liberal license that people can just freely, and another, more restricted logo for things like official CD's and so. This seems like a logical solution. Having the official Debian logo could perhaps be more generic, thus used to deal with the issue of what happens if Debian eventually becomes largely a hurd distribution or takes some other unknown directional turn in the future. One question I had was out of the two options you list above, which category do you see our present logo falling into: the liberal license or the official logo? Or would this new logo contest be used to choose logos for both categories? -- Regards,| Why would anyone want to run an operating . | system that is open source and is developed Randy | by hundreds of hackers worldwide? Find out ([EMAIL PROTECTED]) | why at http://www.golgotha.net/why-linux/
Re: LSH (GPL'd SSH)
On Tue, Jan 26, 1999 at 12:50:52PM +0100, J.H.M. Dassen wrote: On Mon, Jan 25, 1999 at 16:49:57 -0500, Ben Collins wrote: NOTE: For those that are on the ball, they do seem to be considering removing idea from the base source and having it as a seperate module (similar to GnuPG's approach). Another freeness issue (albeit a relatively minor one) is that currently lsh requires scsh (which is non-free) for the generation of include files (they are pregenerated in the tarball; the scsh scripts are needed only for development). It would be nice if someone could modify them to work with a free Scheme implementation (say Guile), or reimplement them in another free scripting language (perl, python etc.). Good point, I saw that, but forgot about it. The TODO/TASKLIST mentions and idea about using Guile, so that would seem the best way to go. -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: New logo strategy
On Mon, 25 Jan 1999, Steve Greenland wrote: On 25-Jan-99, 19:06 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote: I agree with James Treacy's observation that we will probably need two logos: one logo with a liberal license that people can just freely, and another, more restricted logo for things like official CD's and so. To phrase this in another way: we will have a logo that everyone can slap onto their webpage, t-shirts, posters, etc., and a logo that can be used for `official' products, like CD's made using our own iso-images. Sorry, I think this is a bad idea: 1. We have to agree on *two* logos :-). 2. Far more importantly, it fractures the identity of the logo, which is one of the major points of *having* a logo. 3. It creates a first-class and second-class logo. Nah. A 'submission' to the contest is a pair of logos. Linked to each stylistically, one of them says 'official' or something. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
I'll give you one solid reason, uniformity across unix platforms is a must have if unix, especially free unices, are going to succesfully If we are in marketing mode let me point out we are not Unix in the first place and that C:\ is the standard I don't see a connection between /var/spool/mail or /var/mail and home directories or priviliedges. IOW, how does one lend itself better to the task at hand? Modern mail systems dont use a mail spool in general. Or when they do they use a format different to tradition well as far as the system is concerned. What we need to decide is, do we want to go with the standard, or make a new standard simply because we don't want to change? Is the purpose of the FHS to make Linux run after and blindly copy things from Unix platforms or to provide a best Linux platform ? Alan
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Tue, Jan 26, 1999 at 07:19:20AM -0500, Ben Collins wrote: marketing b/s boots on I'll give you one solid reason, uniformity across unix platforms is a must have if unix, especially free unices, are going to succesfully dominate the market. Sun/AIX/HP-UX/OSF/SCO are not going to change, but we could prove our willingess and ability to ensure these uniformities. marketing b/s boots off Mail spool location is really the least of the problems in inter-UNIX compatibility. Why do you think autoconf-generated configure scripts check so many things? Application vendors probably shouldn't hardcode ANY location. On one system I use at the university where I study, email is kept in ~/.inbox. Vendors need to make things configurable anyway to support configurations like that. Hamish -- Hamish Moffatt VK3TYD [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
Re: the Great X Reorganization, package splits, and renaming
On Tue, Jan 26, 1999 at 12:42:18PM +0100, Santiago Vila wrote: Upgrading a system from hamm to slink should make the system to be in the same state as if slink had been installed from scratch. Indeed. All of my systems have remnants of base and timezone remaining. (Actually I just discovered that one of my systems has deinstalled timezone and no timezones at all). Otherwise, Debian will become just a W95 clone very soon (have you ever asked yourself why people reinstall W95 so often?). Yes, I just reinstalled mine last week, because it can't handle any decent sized hardware upgrade without reinstallation. Today I nearly reinstalled NT, just because it's so damn slow after much use. Hamish -- Hamish Moffatt VK3TYD [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
Re: linux 2.2.0: System is 666kB
Thanks for the binary but... when trying to boot with it the kernel uncompreses, gives the message booting kernel and then stops. My machine is a cyrex 686 200. Does the binary only work for intell chips? I noticed that specific suport for non intell chips is a feature of 2.2.0. I guess this means I have to compile my own for now then. Maybe a plain old fashioned i386 binary Thanks for the effort anyway Pete Johnie Ingram wrote: -BEGIN PGP SIGNED MESSAGE- Hm, now theres a worrisome compile message. :-) Anyway, for you early adopters, I've made source and debs available at: ftp.netgod.net/linux/v2.2 Heres the checksums: ca629746d5baa1f3024a780312c96e28 kernel-doc-2.2.0_2.2.0-1_all.deb 40d6ddb94ac0c0239a2a5b16818cbbdb kernel-headers-2.2.0_2.2.0-1_i386.deb 9079f07787cdeba5649b8daa651746ea kernel-image-2.2.0-i686_2.2.0-1_i386.deb 2be1baad527126c18d73f93f709758e1 kernel-source-2.2.0_2.2.0-1.diff.gz 35fa180e872cd6180ae0cab22730938f kernel-source-2.2.0_2.2.0-1.dsc 98354d9bbe92ded9bdf3255b41319e19 kernel-source-2.2.0_2.2.0-1_all.deb be94a0187a3ac4ad41442f967ddb11c3 kernel-source-2.2.0_2.2.0.orig.tar.gz - - PGP E4 70 6E 59 80 6A F5 78 63 32 BC FB 7A 08 53 4C __ _Debian GNU Johnie Ingram [EMAIL PROTECTED] mm mm / /(_)_ __ _ ___ __netgod irc.debian.org mm mm / / | | '_ \| | | \ \/ / m m m / /__| | | | | |_| |Yes, I'm Linus, and I am your God. mm mm \/_|_| |_|\__,_/_/\_\ -- Linus, keynote address, Expo 98 GO BLUE -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: latin1 iQCVAwUBNq1GthCswmGWXGp9AQGvqwP9G+9Fly7F61WBtBohQ8Rm3dhICZaMxikJ 7XL4wBrFvgXaW2HHAVSMgoK3QJMKbHYCsOvYHGqQF+OvC7XySgNxmSCG6/3kwnUd 7OVnWma6giQEhJ2lYVeQZXx/y9aNQkm/I48jDJwvGPRJ95smTUvjmkRsY/Yl9Zq7 7UKSeLnYQaU= =LEbq -END PGP SIGNATURE- -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: new snapshot
[I am cross-posting this to debian-devel and to the plplot mailing lists.] Hi Geoffrey, Thanks for the announcement of this much awaited new snapshot of PLplot. Being the maintainer of both plplot and octave-plplot packages for Debian GNU/Linux, I would like to add some comments to your message: GF == Geoffrey Furnish [EMAIL PROTECTED] writes: GF I have put up a new snapshot on dino.ph.utexas.edu. You can get it GF via anonymous ftp to dino.ph.utexas.edu. The new snapshot is GF plplot/snapshots/plplot-990122.tar.gz GF [...] GF I just want to assure people that PLplot is not dead [...] In GF short, PLplot is in a very real sense of the word, a healthy, GF thriving tool, that is helping many researchers around the world, GF do their job. [...] My intention in making the Debian packages for Debian was exactly to increase the visibility of the PLplot project. I am particularly interested in seeing PLplot replacing GNUplot for Octave. At any rate, it is a very nice package for general scientific plotting. Unfortunately, it is not possible to include your new snapshot in the upcoming Debian release (2.1), because we are now at the deep freeze stage. Anyway, I think that will not have enough free time in the near future (say, until March) to generate the packages. If any Debian developer is interested in this work, she/he should feel free to do a non-maintainer release of the packages. Any modifications in the autoconf files needed for Debian will be contributed back to the PLplot project. Cheers, and keep up the good work, -- Rafael Laboissiere -- Debian Developer Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael
libtool rpath
A package I maintain uses libtool. To remove the rpath stuff, I
apply this patch to configure.in. Now lintian tells me that the executables
have rpath set too! Is there an easy way to fix that?
Also, because this package (geda) includes a library, debhelper
is generating an shlibs file for it. But then the package ends up
depending on itself, because of the shlib:Depends expansion. Is there
an easy fix for that? Splitting the packages is a possibility, but
libgeda is of absolutely no use on its own yet, and I don't think there
is anything for a libgeda-dev.
thanks,
Hamish
--- geda-19981117.orig/configure.in
+++ geda-19981117/configure.in
@@ -35,6 +35,19 @@
dnl Initialize libtool
AM_PROG_LIBTOOL
+# Turn around -rpath and -lc problems with libtool 1.0c
+# This define should be improbable enough to not conflict with anything
+case ${host} in
+ *-pc-linux-gnu)
+AC_MSG_RESULT([Fixing libtool for -rpath problems.])
+sed libtool libtool-2 \
+ -e 's/^hardcode_libdir_flag_spec.*$/hardcode_libdir_flag_spec=
-D__LIBTOOL_IS_A_FOOL__ /' \
+ -e '/^archive_cmds=/s/$/ \\$deplibs/'
+mv libtool-2 libtool
+chmod 755 libtool
+ ;;
+esac
+
dnl Initialize maintainer mode
AM_MAINTAINER_MODE
--
Hamish Moffatt VK3TYD [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
Re: New logo strategy
Previously Steve Greenland wrote: 1. We have to agree on *two* logos :-). No, we have to agree on a *set* of logos: we simply request that each submission consists of two logos. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpRfS7epuT9U.pgp Description: PGP signature
Re: libtool rpath
On Wed, 27 Jan 1999, Hamish Moffatt wrote: A package I maintain uses libtool. To remove the rpath stuff, I apply this patch to configure.in. Now lintian tells me that the executables have rpath set too! Is there an easy way to fix that? Also, because this package (geda) includes a library, debhelper is generating an shlibs file for it. But then the package ends up depending on itself, because of the shlib:Depends expansion. Is there an easy fix for that? Splitting the packages is a possibility, but libgeda is of absolutely no use on its own yet, and I don't think there is anything for a libgeda-dev. I have found this in the policy: 4.3 Shared libraries Packages involving shared libraries should be split up into several binary packages. This suggests that the split is mandated by policy. -- 76d7bdb03d71ca6f1ed20d2f430c2567 (a truly random sig)
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Tue, Jan 26, 1999 at 01:27:13PM +, Alan Cox wrote: I'll give you one solid reason, uniformity across unix platforms is a must have if unix, especially free unices, are going to succesfully If we are in marketing mode let me point out we are not Unix in the first place and that C:\ is the standard s/Unix/Unix-Like/ for clarification. I don't see a connection between /var/spool/mail or /var/mail and home directories or priviliedges. IOW, how does one lend itself better to the task at hand? Modern mail systems dont use a mail spool in general. Or when they do they use a format different to tradition Obviously every admin and 'modern' mail system is going to want to do things their way. Our goal is hopefully to put standard on where it _should_ be and where the default system should have it. What the admin or third party mail systems do after that is completely beyond the scope of the distributions. If our contention is that we cannot forsee what will become of future mailing systems then maybe we should be arguing whether or not we should have a standard or should we have a scope of acceptible implementations. well as far as the system is concerned. What we need to decide is, do we want to go with the standard, or make a new standard simply because we don't want to change? Is the purpose of the FHS to make Linux run after and blindly copy things from Unix platforms or to provide a best Linux platform ? The same could be argued for both sides of this double-edged sword. Not everyone is going to be pleased with the outcome, right now I'd say the opinions are split even. We can either stick with what we have to suit our definiton of a mail spool, or to please the cross-platform admins, go with the old tradition to have a uniform setup. Where is the compromise here that we need? -- --- - - --- - - - --- Ben Collins [EMAIL PROTECTED] Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
[HERT] ANNOUNCE: linux auditd daemon 1.10
Greetings, We have just released auditd version 1.10 for linux. Auditd is part of the linux kernel auditing toolkit. It will capture auditing trails created by the kernel audit ing facility from /proc/audit, filter them, and save them in specific log files. For the moment, auditd only sup ports the -t option, which enables audit trails timestamp ing. Other command line options will probably be imple mented in the next releases to add more flexibility to the package. Comments, suggestions, and critics are welcome. http://www.hert.org/projects/linux/auditd/auditd.tar.gz ftp://ftp.hert.org/pub/linux/auditd/auditd.tar.gz PGP signatures: http://www.hert.org/projects/linux/auditd/auditd.tar.gz.asc ftp://ftp.hert.org/pub/linux/auditd/auditd.tar.gz.asc PGP key: http://www.hert.org/HERT_PGP.key ftp://ftp.hert.org/pub/HERT_PGP.key MD5sum: ae160eb8d50ff3e87a11d27434af48d0 auditd-1.10.tar.gz here is the README file: LINUX AUDIT Daemon: MANDATORY AUDITING FOR LINUX by Marcus Wolf [EMAIL PROTECTED], Promisc Security Copyright (C) 1999 Hacker Emergency Response Team http://www.hert.org/linux/auditd Audit Daemon is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. Audit Daemon is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU CC; see the file COPYING. If not, write to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. INSTALLATION # vi Makefile # vi audit.h # make # make install # ./kpatch # cd /usr/src/linux # make zlilo # echo /usr/sbin/auditd /etc/init/rc.daemons # reboot INFORMATION o /proc/audit This is where the kernel audit facility sends its raw trails information. It is in ascii format, but you may have problems converting network byte order addresses to nd ips manually. :) o /sbin/auditd [-t] The audit daemon captures audit trails from /proc/audit, filters them following its filtering rules, formats them, and outputs them to a log file. The -t option will force auditd to apply timestamps to the audit trails. o /etc/security/audit.conf The audit configuration file keeps the auditd filtering rules. It enable the administrator to filter trails by flag, uid, and pid. - Multiple flags can be specified on a single line; - Only one pid can be specified by line; - Only one uid can be specified by line; - Both flags, uids and pids can be replaced by a '*' mask; NOTES/BUGS/TODO - The next release will probably include audit trails routing to other hosts (similar to syslogd), and piping to commands; - If you find any bug, please contact me at: Markus Wolf [EMAIL PROTECTED] pgpJV7uJ5lzoF.pgp Description: PGP signature
Re: New logo strategy
Jules Bean [EMAIL PROTECTED] writes: On Mon, 25 Jan 1999, Steve Greenland wrote: On 25-Jan-99, 19:06 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote: I agree with James Treacy's observation that we will probably need two logos: one logo with a liberal license that people can just freely, and another, more restricted logo for things like official CD's and so. To phrase this in another way: we will have a logo that everyone can slap onto their webpage, t-shirts, posters, etc., and a logo that can be used for `official' products, like CD's made using our own iso-images. Sorry, I think this is a bad idea: 1. We have to agree on *two* logos :-). 2. Far more importantly, it fractures the identity of the logo, which is one of the major points of *having* a logo. 3. It creates a first-class and second-class logo. Nah. A 'submission' to the contest is a pair of logos. Linked to each stylistically, one of them says 'official' or something. Or, we could have a contest to decide a basic logo and then design a variation on the theme ourselves for the official logo. Actually, I kind of liked cap'n blue eye; then again, I also liked the platypus more than a penguin. Actually, hmmm - a Debian platypus... If we are going to have a gimp.org done contest, I would like to see that the rules allow people to use things that are not gimp, but that are DFSG free software. I find the command-line pnm tools very useful in manipulating images, and it would be nice if I could use them. It would also be nice if I could use xpaint, or something else that allows me to draw simple straight lines and ellipses - freehand drawing with the mouse is very difficult.
Intend to package simulpic
Source: simulpic
Section: otherosfs
Priority: optional
Maintainer: Samuel Tardieu [EMAIL PROTECTED]
Standards-Version: 2.4.0.0
Package: simulpic
Architecture: any
Depends: ${shlibs:Depends}
Description: Microchip PIC device simulator
This software allows to simulate the execution of any program on a Microchip
family microcontroller device.
--
Samuel Tardieu -- [EMAIL PROTECTED]
Debian logo contest, step 2
I just got word back from Sven Riedel, the guy in charge of organizing gimp contests. He was happy with our request, and was willing to organize the whole thing. The contest will start in februari, after the current contest (dreams) ends. Details and submissions will be at the usual site: http://contest.gimp.org/ . Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgp8afAJShCZn.pgp Description: PGP signature
FreeHow to check for free space in perl?
I am trying to write a perl script that needs to make some calculation based on free space in several partitions. What's the best method for checking the free space in a file system using perl? Without using backticks and unix commands, is there any better mean to do it? -- Eduardo Marcel MacanCore Technologies Informatica LTDA [EMAIL PROTECTED] Suporte e Desenvolvimento Unix/Linux. [EMAIL PROTECTED] Debian GNU/Linux Developer Visite-nos em http://thecore.com.br
Re: libtool rpath
Santiago Vila [EMAIL PROTECTED] writes: On Wed, 27 Jan 1999, Hamish Moffatt wrote: an easy fix for that? Splitting the packages is a possibility, but libgeda is of absolutely no use on its own yet, and I don't think there is anything for a libgeda-dev. I have found this in the policy: 4.3 Shared libraries Packages involving shared libraries should be split up into several binary packages. This suggests that the split is mandated by policy. Actually, I think this section of policy should be reviewed. There are some limited situations (and this is one) where there is no point to have a separate shared library package, but it does make sense to compile a program with shared libraries. Martin.
Re: New logo strategy
On Tue, 26 Jan 1999, Daniel Martin wrote: If we are going to have a gimp.org done contest, I would like to see that the rules allow people to use things that are not gimp, but that are DFSG free software. I find the command-line pnm tools very useful in manipulating images, and it would be nice if I could use them. It would also be nice if I could use xpaint, or something else that allows me to draw simple straight lines and ellipses - freehand drawing with the mouse is very difficult. Whilst I have no objections to such a change in rules, I am baffled that anyone could prefer xpaint to gimp, even for drawing straight lines and ellipses. Try fiddling with the selection tools, and the 'path' or 'pen' tool. (And use layers lots..) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Need a check for suid applications
reassign 28850 general thanks This bug is now fixed in gettext_0.10.35-7. However, somebody should check that every suid application in slink which is statically linked against gettext is recompiled with the new gettext. (Maybe doing gettextize -f -c). Thanks. -- 6525d3e1b6548dd210c536bf09bde00b (a truly random sig)
Re: Debian logo contest, step 2
On Tue, 26 Jan 1999, Wichert Akkerman wrote: I just got word back from Sven Riedel, the guy in charge of organizing gimp contests. He was happy with our request, and was willing to organize the whole thing. The contest will start in februari, after the current contest (dreams) ends. Details and submissions will be at the usual site: http://contest.gimp.org/ . What exactly has been asked for? Matthew -- Elen sila lumenn' omentielvo [EMAIL PROTECTED], Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
Hi, Ted == Theodore Y Ts'o [EMAIL PROTECTED] writes: Ted I keep hearing people claim that distribution folks are saying ick, Ted but I haven't heard any technical reasons besides, Moving spool Ted directories is hard. Fine. Here are a few. I, and a number of other sysadmins, have a partition for /var, and mount /var/spool on it. The understanding has always been that */spool/ directories contain data that may grow unpredictably. If I use log rotation, and purge old logs regularly, /var remains a more or less static in size, apart from the spool directories. One has little control over the size of the spool directories. So, one puts the spool directory on another partition. This has been standard practice in OS's derived from BSD, I think (I know we used to do it on Ultrix, in the good old days). Another factor is wehen the spool directories are used for USENET or mail, there are a large number of small files with a high turnover; one some file systems one may tweak parameters to make the file system better suited for spools. (This is certainly less true for mail than for news, but still) I have generally put large partitions for spool, and prefer not to have an overfull spool partition bring down the system. Ted When I and others have pointed out that moving the spool Ted directory isn't required; just a symlink, I have heard dead Ted silence. So the lack of technical discussion, but just a Ted stony-silence No! is rather disappointing as far as I'm Ted concerned. I have no objections to a compatibility link in /var/mail, or to modifying code to look in both places. Ted I think we should require that new applications use /var/mail, Ted and that backwards compatibility symlinks should exist. While the new FHS is trying for conformance with other unices, we should also consider rtadition (traditionally, /var/spool/mail has been the location for Linux boxes) Why can't we get compatibility with the so called other unices just by putting in a sym link in /var/mail, and leaving the spool directory where it is? Ted If we must back out /var/mail (for no good technical reason that I can Ted determine), then at the very least I think we should state that there Ted that for all compliant distributions, /var/mail *MUST* be a valid way of Ted reaching the spool directory (i.e., there should be a symlink there, or Ted where the spool directory actually lives) and that it be permissible for Ted applications to use /var/mail to find the mail directory (but that Ted applications that want to keep using /var/spool/mail would not be Ted considered obsolete). I think this is a reasonable compromise. Ted At least that way applications that want to use the same dirctory as the Ted vast majority of other Unix systems will work without needing a special Ted case for Linux. However, I would much rather see us adopt the full, Ted correct solution, rather than this half-measure. This is the first rationale I have seen for actually going to /var/mail, other than ``those other unices do it'', and I think a symlink shall address all those concerns quite well. I suppose there sould also be an argument that the mail spool is not really a spool, but a message queue still qualifies for being on the spool partition. (trying to move my mail spool directory to /var/mail may well fail on some of my machines due to file system getting overfull) I have not being following the FHS list, so these opinions may well be un informed. manoj -- +#if defined(__alpha__) defined(CONFIG_PCI) /* The meaning of life, the universe, and everything. Plus this makes the year come out right. */ year -= 42; +#endif (From the patch for 1.3.2: (kernel/time.c), submitted by Marcus Meissner) Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Debian booth at linuxworld, volenteers wanted
Joey Hess [EMAIL PROTECTED] writes: Oh, it's in San Jose California, March 1-4th. Thanks. Then I can't volunteer, although I frequently seem to find myself in San Jose :-) Later, Dale -- +- pgp key available --+ | Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer| | [EMAIL PROTECTED]|http://www.clifton-labs.com | +--+
Re: the Great X Reorganization, package splits, and renaming
On Tue, Jan 26, 1999 at 12:42:18PM +0100, Santiago Vila wrote: Can you *guarantee* that the package now called xfonts-base will *always* have the same functionality and will always be *identical* to the one called xfntbase in hamm? Can you *guarantee* that the package now called xlib6g-static will *always* have the same functionality and will always be *identical* to the one called xslibg in hamm? I don't think you can, unless you have a crystal ball. I don't have to. If and when a package has non-practically-identical contents (I fear not qualifying it, for I'm sure you'd file a critical bug against xfntbase for not having the same changelog.Debian as xfonts-base) from its predecessor, if dpkg/apt have not implemented brains sufficient to account for package renaming, I will implement your ham-fisted solution, *for the affected package(s) only*. I did this very thing for xbase. But then it could be too late. Sorry but this is vaporware. If changes in the font and static library packages haven't happened by the time potato is released, it still doesn't matter, for the same reasons it doesn't matter now. It is not wise at all to rely on features that have not been implemented yet. As Joseph Carter says: Show me the code or get out of my way. I'm not relying upon them. Hamm and older systems upgrading to slink break in no particular fashion because of the existence of the new packages. BTW: I see a contradiction here... If you and Branden are so sure that package ranaming will be implemented in dpkg for potato, why does not Branden just postpone all the package renamings to potato to do it the right way? Because it's too late. They've already been renamed. If I had appreciated the difficulties this would have caused me four months ago when I first drafted my proposal, I would have renamed only two packages -- xbase and xfntbig. I would have let the rest wait for more support infrastructure from our packaging system. I was much less aware of dpkg's limitations at the time. The X Strike Force webpage has been up for almost a year, and has contained detailed plans of the X reorganization as long as I've had them. Only now do you seem to be concerned. Frankly, I'm very suprised how low do you value the userfriendliness of the system, the smoothness of the upgrades and the overall quality of Debian. I can't accept I create a problem today and will fix it tomorrow or worse problem? what's the problem?. Yes, I'm certain if one tallies up all the outstanding bug reports I've managed to fix in X, some of the new functionality I've managed to develop, and Marcus Brinkmann's XF86Config diagnostic tool, one could easily reach the conclusion that I don't give a damn about the user friendliness, smooth upgrades, or overall quality of Debian. Upgrading a system from hamm to slink should make the system to be in the same state as if slink had been installed from scratch. Otherwise, Debian will become just a W95 clone very soon (have you ever asked yourself why people reinstall W95 so often?). This is a straw-man argument. Isolate one criterion -- if we don't meet that by YOUR standard, we're no better than Windows 95. Are you a university student? I suggest a course in critical thinking. I reiterate my challenge. Demonstrate to me a manner in which a hamm system upgraded to slink, which keeps the old X font and static library packages, will be broken. What programs will break? What statically-linked X clients will they be unable to build, or in what manner will these clients differ from their counterparts build with xlib6(g)-static? What fonts from the xfnt* packages will they be missing out on if they don't install the corresponding xfonts*- package? I've levelled this challenge before, and you've only been able to reply with more flamage and illogic. I told you, demonstrate a significant practical, functional drawback to leaving the old packages in place and I will implement the bizarre pseudo-packages. These are the practical, important considerations. I, too, would like people's systems to be rid of the old packages. But I'm not going to pervert the packaging system to do it without some more cause to do so. -- G. Branden Robinson |Convictions are more dangerous enemies Debian GNU/Linux |of truth than lies. [EMAIL PROTECTED] |-- Friedrich Nietzsche cartoon.ecn.purdue.edu/~branden/ | pgpZYWSzabHyb.pgp Description: PGP signature
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
This is getting WAY out of hand here. How about this:
The mail spool MUST be accessible through /var/mail AND /var/spool/mail,
and spool files MUST take the form /var/{spool/}mail/$LOGNAME. Either
/var/mail or /var/spool/mail, or both, MAY be symbolic links to another
directory. It is RECOMMENDED that /var/mail be the actual directory and
/var/spool/mail be the symbolic link. At some point use of /var/spool/mail
may become deprecated.
+-++
| Jakob 'sparky' Kaivo| [EMAIL PROTECTED] |
| NoDomainName Networks |http://www.nodomainname.net |
| AtDot E-mail Services | http://www.atdot.org |
+-++
Re: I'm a concerned about slink. specifically jdk1.1, idraw, and xaw-wrappers
Guenter Geiger [EMAIL PROTECTED] writes: ... and it is solved now :) Actually I have to say, if I would have been the one who was supposed to fix the bug, it would have taken me another hundred days, and probably I would have lost my last hair upon this ... But luckily, the upstream maintainer found the problem, which was related to the egcs c++ compiler. On another point, there is no other distribution which is featuring idraw, drawtool, flipbook and the InterViews library together with all the vector drawing libraries and Unidraw within ivtools. Just dropping that package because it was (temporarily) not possible to draw arrows seemed not appropriate to me .. Thanks for chasing this bug down. I realize that idraw is ancient and probably old news, but I _do_ use it frequently as I like that it generates/reads(its own subset of) postscript. Arrows seem to be in most anything that I want to draw, so that was limiting its usefulness to me significantly. :-) Later, Dale -- +- pgp key available --+ | Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer| | [EMAIL PROTECTED]|http://www.clifton-labs.com | +--+
Re: New logo strategy
Jules Bean [EMAIL PROTECTED] wrote: Whilst I have no objections to such a change in rules, I am baffled that anyone could prefer xpaint to gimp, even for drawing straight lines and ellipses. gimp won't run on smaller machines. Also, there's Rick Hohensee's caligraphic patch for (if I recall correctly) xpaint. [Or is there a calligraphic module for the gimp?] -- Raul
Processed: Need a check for suid applications
Processing commands for [EMAIL PROTECTED]: reassign 28850 general Bug#28850: gettext: security problem when used in setuid programs Bug reassigned from package `gettext, libc6' to `general'. thanks Stopping processing here. Please contact me if you need assistance. Ian Jackson (administrator, Debian bugs database)
Way, way off-topic was: Re: Debian logo its license
Andrew writes: You've forgotten something. The military act as if they are above any laws. (If they cared about obeying laws, they would be disarming nuclear weapons under their international treaty obligations) On the contrary. The military, at least in the US and the UK, act in accordance with the laws of their respective nations, which require them to obey the civilian governments. It is those governments, not the military, that are signatories to treaties (not that I know of any that require nuclear disarmament). -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
What's needed for kernel 2.2
Will some guru tell us what critical packages we need to update in order to use 2.2 ? kerneld is replaced by something else, etc. I guess that if I'm asking that means I should wait for a proper Debian upgrade. Or does kernel-image-2.2.0-i686_2.2.0-1_i386.deb have all the dependencies sorted out? Thanks! -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
Re: New logo strategy
On 26-Jan-99 Randy Edwards wrote: One question I had was out of the two options you list above, which category do you see our present logo falling into: the liberal license or the official logo? Or would this new logo contest be used to choose logos for both categories? Because of the current (but expired) logo license, it would fall under the official logo but the contest would offer suggestions for both. -- = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = pgpHNmIVuwtBY.pgp Description: PGP signature
Re: Why /var/www? (Was: Where does 'www-data' come from?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 25 Jan 1999 22:23:34 -0500, Michael Stone wrote: /home/(ftp|www) is just plain ugly. (It's a real pain when you're trying to share nfs home dirs between web servers, for example.) I use /var/ftp on my own system (well, actually /var/local/ftp...) Personally I put them where I have drive space and symlink /ftp and /www to them. Major services generally get a root entry from me. Some people think it is ugly but there is some purity in cd'ing to /www/somebusinesssite/ - -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your ICQ: 5107343 | main connection to the switchboard of souls. - ---+- -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc iQA/AwUBNq36rXpf7K2LbpnFEQICfwCdGzgKpPOJd/Utw4c3FmfKNj5meisAn1U7 Y5uwtBmP8jYMUYGaut4BZxql =aGZI -END PGP SIGNATURE-
Licenses for non-software works, and the definition of software, and , the new DFSG
Hi, In response to an issue on -legal, I am reopening the debate on how free those parts of debian which are not software (or not precisely software) should be. IMO, this debate should be conducted on -policy, and I ask all replies to this message to trim the CC: line. This issue was discussed in length on policy last year. One such thread is 'Free Software Needs Free Documentation', which begins at http://www.debian.org/Lists-Archives/debian-policy-9808/msg00042.html Another thread 'Start for a discussion about free documentation in Debian' begins with http://www.debian.org/Lists-Archives/debian-policy-9808/msg00052.html Four or five other threads follow - please use the list-archives browser if you have a web browser capable of it. Being biased, I like the summary I gave in http://www.debian.org/Lists-Archives/debian-policy-9808/msg00254.html *Please*, if you have strong views on this subject, at least skim the above threads, and those which follow on related issues, before entering the debate. It was very drawn out last time. It is an important issue, and I don't think we should vote on a new DFSG which doesn't address it. Allow me to summarise some points of fact and some points of view: 1) Technical documentation should be 'free' in the GPL sense. This was widely held by all participants in the debate. 2) 'Artistic works' need not be free. This suggested to us the creation of a new section in debian, 'verbatim', in which works in certain classes could be distributed. The line between documentation and 'works of art' may not be clear, and there may be a mixture in one document. 3) Licenses are generally not free This is more or less a fact, actually. The GPL does not give the permission to modify, notwithstanding the fact that some other licenses are very clearly derived works. 4) Some good, 'free' software has non-free documentation This poses a dilemma for our principles. Our conclusions, IMO, should be included either in the new DFSG, if we accept it, or incorporated into the current, if not. Jules ..putting on flame suit... /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Way, way off-topic was: Re: Debian logo its license
On Tue, Jan 26, 1999 at 10:33:30AM -0600, John Hasler wrote: You've forgotten something. The military act as if they are above any laws. (If they cared about obeying laws, they would be disarming nuclear weapons under their international treaty obligations) On the contrary. The military, at least in the US and the UK, act in accordance with the laws of their respective nations, which require them to obey the civilian governments. It is those governments, not the military, that are signatories to treaties (not that I know of any that require nuclear disarmament). Just keep telling yourself that.. = -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: What's needed for kernel 2.2
Peter S Galbraith wrote: Will some guru tell us what critical packages we need to update in order to use 2.2 ? I'm not a guru I guess, but I can cutpaste something from linux/Documentation/Changes: - Kernel modules 2.1.121 ; insmod -V - Gnu C 2.7.2.3 ; gcc --version - Binutils 2.8.1.0.23; ld -v - Linux libc5 C Library 5.4.46; ls -l /lib/libc.so.* - Linux libc6 C Library 2.0.7pre6 ; ls -l /lib/libc.so.* - Dynamic Linker (ld.so) 1.9.9 ; ldd --version or ldd -v - Linux C++ Library 2.7.2.8 ; ls -l /usr/lib/libg++.so.* - Procps 1.2.9 ; ps --version - Procinfo 15; procinfo -v - Psmisc 17; pstree -V - Net-tools 1.49 ; hostname -V - Loadlin1.6a - Sh-utils 1.16 ; basename --v - Autofs 3.1.1 ; automount --version - NFS2.2beta37 ; showmount --version - Bash 1.14.7; bash -version - Ncpfs 2.2.0 ; ncpmount -v - Pcmcia-cs 3.0.6 ; cardmgr -V - PPP2.3.5 ; pppd -v - Util-linux 2.9 ; chsh -v Those are in these Debian packages: modutils, gcc, binutils, libc5, libc6, ldso, procps, sysutils, psmisc, hostname, loadlin, shellutils, autofs, nfs-server, bash, ncpfs, pcmcia-cs, ppp, util-linux. If you get the versions of these packages that are in the currently frozen Debian distribution (slink), then they'll suffice. HTH, -Remco
Re: the Great X Reorganization, package splits, and renaming
Branden Robinson: [...] Only now do you seem to be concerned. No, this has been a frequently asked question for some time in debian-user. I should probably add it to the Debian FAQ. Please, note that I'm not blaming you for not having thought about this problem *in advance*. I just want to see it solved in *whatever* way. [...] Upgrading a system from hamm to slink should make the system to be in the same state as if slink had been installed from scratch. Otherwise, Debian will become just a W95 clone very soon (have you ever asked yourself why people reinstall W95 so often?). This is a straw-man argument. Isolate one criterion -- if we don't meet that by YOUR standard, we're no better than Windows 95. The W95 case was just an example. The upgrade *should* be smooth. This is not my criterion, it is one of the things that Debian has promised to our users, and it is something the users expect from us. [...] I reiterate my challenge. Demonstrate to me a manner in which a hamm system upgraded to slink, which keeps the old X font and static library packages, will be broken. Well, I have already said that the fact that the harm is not immediate does not mean that it is less broken. However, if you want something immediate, here it is: dselect will show the old packages as being obsolete. This will cause a lot of confusion, a lot of questions to answer and a lot of time lost for everybody. And of course a lot of fear about Debian, since people will think that we change names gratuitously without a good reason to do so, and more important, without implementing a good renaming mechanism *first* in dpkg. Are you trying to tell me that it is *better* that the X packages do *not* upgrade automatically? (I hope not). Put it simply: You have, as X maintainer, the right to rename the packages as you want. However, once they are renamed, we have a problem, they do not upgrade automatically, as everybody expects. Then we have two choices: 1. Do whatever we can with existing tools so that the X packages are effectively automatically upgraded. 2. Do nothing. Is your word final in that you are not convinced that we should make whatever is needed to ensure that the X packages are automatically upgraded, as the rest of the system is? [ Maybe I should post an intent to package message then and stop this discussion ]. Thanks. -- a378a07a477f4abbab1735772121291f (a truly random sig)
Re: What's needed for kernel 2.2
Peter S Galbraith wrote: modutils, gcc, binutils, libc5, libc6, ldso, procps, sysutils, psmisc, hostname, loadlin, shellutils, autofs, nfs-server, bash, ncpfs, pcmcia-cs, ppp, util-linux. If you get the versions of these packages that are in the currently frozen Debian distribution (slink), then they'll suffice. Great! Thanks! Knowing slink pacakages are enough is great news! I just discovered, unfortunately, that you need the util-linux package from potato (unstable). Rest of the things in slink are fine with 2.2.0!! Apologies, -Remco
Re: the Great X Reorganization, package splits, and renaming
On Tue, 26 Jan 1999, Branden Robinson wrote: I reiterate my challenge. Demonstrate to me a manner in which a hamm system upgraded to slink, which keeps the old X font and static library packages, will be broken. I hope you will agree that sometimes we have to think about the future. With the current state of things, a Debian system which is upgraded by dselect from hamm to slink, from slink to potato, from potato to potato+1, and from potato+1 to potato+2 may have, say, X version 5.5, and xfonts version 3.3.2.3-2. Do you think this may be of any good? Don't you agree that we should try to avoid it? -- 83835090bf2dd62c42b79e7cf5db4081 (a truly random sig)
Intent to package: pcd2html
Hello I would like to package my self written script system pcd2html which creates commented HTML pages from a Kodak Photo CD using user supplied options for convert from ImageMagick and describing text. Informations are available at http://www.physik.uni-halle.de/~e2od5/debian/pcd2html.html The result of this script system can be shown at http://www.physik.uni-halle.de/~e2od5/island/pcd_1998 which presents 104 shots from two holidays in Iceland. Hope that pcd2html will be useful for you and may be you will enjoy the images, too. Kind regards Andreas.
