Re: Debian GNU/Linux: Best of the Web! (fwd)
Nicol?s Lichtmaier <[EMAIL PROTECTED]> wrote: : Are we really that good?? =) :-) Probably they are grateful to us because they use Debian on their own systems? E.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DFMR
Anyone wishing to be on the DFMR (Deb Freshmeat Repository) team should email [EMAIL PROTECTED] with the subject DFMR. I understand Freshmeat has _one_ person managing the RPM repository... -- Robert S. Edmonds Debian Developer (http://www.debian.org) mailto:[EMAIL PROTECTED] http://edmonds.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/passwd : which software does support this ?
On 21 Apr 1998, Guy Maor wrote: > Remco Blaakmeer <[EMAIL PROTECTED]> writes: > > > If shadow-login is the only program that supports these fields, they are > > useless. If a user had a value "pri=5", he would only have to do something > > like > > echo 'command' | at now > > to get 'command' executed at normal priority. > > Yes, it's not very effective. It's meant to be used with restricted > shells like rbash I guess. I am not really a programer, but I wonder how hard it would be to put support for these fields in all programs like login, xdm, cron, at and anything I am forgetting. Could this be done? RemcoA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/passwd : which software does support this ?
On Tue, 21 Apr 1998, matthew.r.pavlovich.1 wrote: > xdm-shadow is already available. Yes, and I am using it. But the question is, does it support the "pri=", "umask=" and "ulimit=" fields in /etc/passwd? And do cron and at also know about these fields? If cron and at don't know about them and don't support them they're practically useless, like I said before. Remco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /tmp exploits
-BEGIN PGP SIGNED MESSAGE- I think you are missing th epoin there somewhat. I belive the original intent was NOT to modify libc so that /tmp exploits are impossible as a be-all and end-all solution The idea was to modify libc so that anything which used /tmp in blatantly unsafe ways (I subscribe to BUGTRAQ and I have noticed allot of recent exploits and things involvce /tmp) The reason behind doing this is so that thos programs which use /tmp unsafely break automatically... That way they can be fixed As it is now...dozens of programs you use every day without thinking (or maybe just the few you seldom use) could use /tmp unsafely without ever being noticed unless you watch fo rit. Making wrappers to allow programs to work and setting weird flags is only a small solution if you fix the program itself, then you have a larger one (ie. what about filesystems that don't support chattr +X?) and the fix can be sent around to the rest of the community (outside of Debian) and close security holes before they are even known to be exploitable ok..maybe all of that wasn't the original intent of the idea...but that would be the effect personally I prefer that idea to making kernel patches or changeing the nature of /tmp itself of course... I personally agree with what some others said... this "Hacked" libc (or whatever is used) should not make it into a production releace... IMHO it should only be used to identify and fix problems it shouldn't be "standard" for normal users to use - -Steve On Tue, 21 Apr 1998 [EMAIL PROTECTED] wrote: > > On Mon, Apr 20, 1998 at 11:47:20PM -0700, Guy Maor wrote: > >> Modifying libc to catch common security goals is a laudable goal, but > >> such a libc should go to experimental. > > This may be a stupid question, but *what* /tmp exploit are we trying > to fix? > > I ask solely because /tmp should already have some special attributes > set. Is this exploit something which is already solved by existing > permission flags? Is it something that could be solved by a new > permission flag? > > How about this is as second proposal: modify libc, ext2fs and chattr > to support a new extended attribute: > > chattr +X > > This flag is only meaningful for directories. (The same bit could be > used for other purposes for files; perhaps we could reuse an existing > bit?) > > If this is set, its immediate children will force O_EXCL if O_CREAT is > set. This is slightly different from the first proposal, since "broken" > code would still work *unless* an entry with the same name already > existed. > > Since you aren't using a string comparison all of the problems associated > with it disappear. You could even walk the tree and set this bit on > *every* directory. Since it's controlled by a standard mechanism, it's > easy to write wrapper functions, when necessary, for suitably privileged > users. > > Finally, since there is a workaround (chattr(); broken(); chattr();) > we can reasonably define this bit to apply to *all* users, including > root. If you don't want it at all, don't set the bit. If you do want > it but have broken applications, use wrappers. > > Bear Giles > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNT1Ajnxvn0zebBV9AQGsMgQAlJ14mamwp7dM2mELwga/MH4xNV6J1boV yAYICWyIREWn1tLhPPzsLzaVncTMS0VzSZaiy/Pf773hdii8ZSc5oLBf61JXNO4M p/3FriiWibxeoVp0f2DLFHna55zjMYlVaWIghzXYVTDL8jVlzhOMOfz5lbv4nF9U +rwdUZ6alVU= =L5qN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Didn't upload apache 1.3b6-1 (source i386) to master
Well this is the Big One: the final release of apache 1.3.x for hamm, closing all but wishlist Bugs. Technical difficulties delay the upload, but this gives us more time to find problems in the packaging before its approved for inclusion. You can find it at: ftp://ftp1.us.debian.org/debian/local As usual I'll be on irc.debian.org. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Tue, 21 Apr 1998 21:03:52 -0400 Source: apache Binary: apache-doc apache-dev apache Architecture: source i386 all Version: 1.3b6-1 Distribution: frozen unstable Urgency: low Maintainer: Johnie Ingram <[EMAIL PROTECTED]> Description: apache - Versatile, high-performance HTTP server apache-dev - Apache webserver development kit apache-doc - Apache documentation Changes: apache (1.3b6-1) frozen unstable; urgency=low, closes=20438 20569 18187 18768 18188 17350 15344 17517 18310 16146 15693 19169 18098 18553 19616 . * New upstream version, release candidate for 1.3.0. * The dynamic loading that Debian has done for years is now officially supported. * Better support for HTTP/1.1-style virtual hosts. * A number of bugfixes and internal performance enhancements. * The configuration program now adds all features with LoadModule directives, and in the order recommended for Debian by Lars Eilebrecht of the Apache Group (fixing mystifying stuff like #19169). * Install scripts no longer attempt to edit /etc/passwd directly, which wasn't reliable anyway (#18588). * Added text to make it clearer that "corrected" paths are not saved to the config files until the very end (#18187). * Standard configuration no longer stores icons in /usr/doc (#18188, #15344), but asks before correcting icon directory Alias and cgi-bin ScriptAlias (#18187). * The apachectl script now uses correct paths (#19616). * Uses better regular expression in init.d from Nicholas Lichtmaier. * It is now possible to backspace during the selection of Y or N within apacheconfig (#18310), which also fixes operation on sparc. * Configuration program no longer attempts to reconfigure a correctly-configured configuration during an upgrade (#17350, #18768, #18187). * Binds to port 80 even without an explicit Port directive (#18553). * The cron.daily script now correctly parses the obsolete and insecure Group number "#-1" in httpd.conf (#16146, #15693). * Fixed details of logfile locations in apache manpage (#20438). * The init.d script now uses the "graceful restart" reload method. * Closes #20569: log files listed multiple times are only aged once. * Updated initial site webpage. * Added yet more debhelperization, eliminating lintian errors. * Updated to Standards-Version 2.4.1.0. * Closes #18098 -- there is no demand for a 1.2.6 package, and only this 1.3.x has been tested in hamm). * Closes #18128 -- the postinst should not offer an inetd option, as the Apache Group has made it clear this "does not work propery -- avoid if at all possible.". * Demotes #20655 to severity fixed (apache no longer needs the non-free mysql.h header to compile, mod_so replaces mod_dl, and dpkg-dev 1.4.0.22 can extract the source package). Files: 85b13fc21e6d6c5b21d11917c69a4000 642 web optional apache_1.3b6-1.dsc f58db5a72656a36605934fbcb215c154 1156677 web optional apache_1.3b6.orig.tar.gz 029c27e0628b643faf3b2fd106662092 68849 web optional apache_1.3b6-1.diff.gz 0dc94165a073bbbcd090c1c430a79684 432406 web optional apache-doc_1.3b6-1_all.deb 01295b939894184a5fc87ea219ee9685 134594 web extra apache-dev_1.3b6-1_all.deb 5bc8022dd2d9162e46bbf6adbfaa10e6 465310 web optional apache_1.3b6-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: latin1 iQCVAwUBNT1DjBCswmGWXGp9AQGDEQP/QglXHCIzA+L3hE/TLyg1xrUv+1hUmBpF X0bG/R2beDKC5kagezNoT19yecKEZHeWuQeFz3bvXVSoH+GBU/+XOtw0KLCIZJeZ J7Y+jX/Phu0KCWZVVwafvJVnTpULu7NRk8modfBEpwwmQez1ygWWM89oHFHN6tSY 5jauNMBd/xI= =gm1A -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Linux: Best of the Web! (fwd)
Eloy A. Paris wrote: > Nicol?s Lichtmaier <[EMAIL PROTECTED]> wrote: > : Are we really that good?? =) > Probably they are grateful to us because they use Debian on their own > systems? The Minig Co? Not likely. I did a little bit of part time work for them and was even offered a job a year and half back. I refused to take it up because they were Gung Ho about NT. For one of my projects for them I actually compiled a program on NT using Cygnus (?)'s GCC for NT. You should have seen the look on The Chief NT Rah Rah person's face. S. -- "Will write code for stock options." Sudhakar C13n Indentured Slave http://people.netscape.com/thaths/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: master status
Hi Mark... What about using soft-raid1/5? there are working raid-L0145 patches for 2.0.xx... when a drive in the array fails the others continue working (well, if all drives in the raid array fail you are lost, but that only happens at debian-release-time :) Just my 0.02 cents ;-) On Tuesday, April 21 1998, at 10:51:20, m* wrote: : again sorry for the delay, but we actually had two disks ( Micropolis : 9GBs ) that : failed with one of those being the backup. very unfortunate as well as : unnerving. Regards, -- Roberto Lumbreras [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] & pgp 143BE391 Lander Internet, Madrid-Spain-UE; http://www.lander.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Linux: Best of the Web! (fwd)
On Tue, 21 Apr 1998, Sudhakar Chandrasekharan wrote: > The Minig Co? Not likely. I did a little bit of part time work for them > and was even offered a job a year and half back. I refused to take it up > because they were Gung Ho about NT. For one of my projects for them I Yeah, it really looks like the bulk of the site is MS worship. But they have a linux zealot doing the linux corner. I don't know what he uses, seems pretty careful though. eg, there is a preamble to the list of news groups warning about interrupting work. Which reminds me , there is too much non-essential crap on this list ... (!) John Lapeyre <[EMAIL PROTECTED]> Tucson,AZ http://www.physics.arizona.edu/~lapeyre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
Yo- I would like suggestions and input on how to "sell" Debian in the sense of Debian versus RedHat, FreeBSD, or any other distribution. I will attempt to persuade a small committee of faculty to install Debian on a yet to be purchased machine. The machine is an experiment at my university to see if a select group of students can successfully administer a machine. I have my own views of why Debian is better and honestly I love it to death but the marketing and X-based configuration of RedHat seem to be weighing against me. I am also aware of a notion that FreeBSD is somewhat more "secure" than linux which I must also combat. Please suggest the best hardware configuration for a machine that will host thousands of users and be up 24/7. I suspect that an i386 machine would be most suitable only because I am unaware of the stability or availability of Alpha/Sparc ports and due to the lesser price of i386 hardware. Please point me towards any information that might help me get Debian on such an important machine at my university. The machine that am I asking for advice in building is a replacement machine for the machine in which this e-mail is being created. I am sorry if this message seems somewhat convoluded but I feel very strongly about having Debian an the operating system on this computer. I lack the advanced programming skills(I receive my degree in Finance in a few months) to be a Debian developer but I sincerely desire to help promote and help the Debian project. On a side note, with whom do I need to correspond with to discuss the use of the Debian logo and name? If anyone was wondering, I attend the University of North Texas located in Denton, Texas (30miles north of Dallas/Ft.Worth). It is the 3rd largest university in Texas. Please feel free to reply directly to me or to the list! Thanks again, -Ian _ Ian K. Setford [EMAIL PROTECTED] [EMAIL PROTECTED] H: 940.566.0461 Pgr: 817.901.0255 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
^^Please read above message^^
It's late. I forgot the subject. Geez. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
Richard Braakman wrote: > > I've added the "if binary executable, use strings on it" to lessopen. I > > could see marginal use for looking at the raw executable, so if anyone > > has any objections, speak up before Saturday Night (-0800Z) or file a > > bug against less and I'll take it out. (cc'ing debian-devel for a wider > > audience) > > This seems like a bad idea. "strings" is not the obvious information > to provide about an executable. (Consider size, objdump, od, hexdump, > et cetera). > > I only use "strings" when I pipe through grep. When I use less it's > just as easy to search the file directly. > > I would also find it disorienting to less a binary executable and get > a long list of identifiers. I _expect_ a screen full of garbage, and > that "/lib/ld-linux.so.2" in a particular position :-) Chiming in a little late -- I agree with Richard 100%. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
Joey Hess wrote: > > > > This seems like a bad idea. "strings" is not the obvious information > > to provide about an executable. (Consider size, objdump, od, hexdump, > > et cetera). > > > > I only use "strings" when I pipe through grep. When I use less it's > > just as easy to search the file directly. > > I would also find it disorienting to less a binary executable and get > > a long list of identifiers. I _expect_ a screen full of garbage, and > > that "/lib/ld-linux.so.2" in a particular position :-) What would be the use of looking at a screen full of control characters? I can see prepending the output of strings with other useful stuff, though; how about this: replace in lesspipe.sh if [ "$FILE1" = "Linux/i386" -o "$FILE2" = "Linux/i386" \ -o "$FILE1" = "ELF" -o "$FILE2" = "ELF" ]; then strings $1 fi ;; with: if [ "$FILE1" = "Linux/i386" -o "$FILE2" = "Linux/i386" \ -o "$FILE1" = "ELF" -o "$FILE2" = "ELF" ]; then file $1; echo -e "\nsize:"; size $1; echo -e "\nldd:"; ldd $1; echo -e "\nstrings:"; strings $1; fi ;; This produces, on my system, a very pretty screenful of useful info. After all, if I am just looking for instances of a var, I can use grep as mentioned above. But this set of commands gives me a lot of useful stuff with only command. Carl -- [EMAIL PROTECTED] The sun's not eternal That's why there's the blues... -- Ginsburg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xpenguin (formerly known as xteddy)
On Sat, 18 Apr 1998, Alex Romosan wrote: > >Why dont u make a debian PAckage out of it? You can do one PAckage > >xteddy with an additonal command-line parameter to select the > >personality shown. > > somebody else (Andreas Tille <[EMAIL PROTECTED]>) has already > expressed interest in packaging xteddy. i can share the pixmaps with > him though. Yesterday I wrote some code to make xteddy able to show *any* pixmap. This is done by calling xteddy -F So if you would send me your penguin pixmaps I will include them in my Debian package which will come out in about two or three weeks (please give me time; I'm very busy this days ...) in slink (because it is too late for hamm). Regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary-CD exceeds 650 MB -- any solution?
Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > but for symlinks pointing to something excluded from mirroring, > it should download the file. this way i could burn a complete hamm... I turned the hamm->bo symlinks into files a few days ago. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first proposal for a new maintainer policy
Apologies are due for my not trimming the crossposting before; I meant to, but I forgot to. As I understand things, there should be no crossposting amongst the debian mailing lists. If I make further comment, therefore, I will be careful to trim the mail distribution to one of them only, and send a message like this one to let possibly interested others know where the thread went. I am making a comment; I'm choosing debian-policy as the list. See it there. -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bzip2 X
Bdale Garbee <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> you wrote: > : fast. Its not agood solution, so thats why I asked here about > : integrating bzip2 support into gzip. > > Points well taken. You're just asking in the wrong place. You should take > this up with the gzip upstream maintainer. It is not a Debian packaging > issue, it is a request for a fundamental change in the functionality provided > by gzip. If bzip2 algorithm support were to show up in a future gzip release > I'd be as happy as the next guy. Supose we have bzip2 support in gzip, then we need several changes. Source and deb formats should then be changed to allow for bziped files. > If the gzip upstream maintainer doesn't fold in bzip2, then the right solution > is for this to be handled by applications like dpkg-source... not by having > the Debian gzip functionality diverge from the FSF gzip. gzip would only diverge by having the additional feature that it can decompress bzip2 streams. It would be fully compatible otherwise. I'm going to send a patch to the upstream maintainer probably today, that integrates bzip2 decompression. If he doesn't like it, bzip2 could be enhanced to understand gzip decomression for non-bzip2 files. People who wont to use bzip instead of gzip by default could then just replace gzip. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deb + tar + bzip2 suggestion
[EMAIL PROTECTED] (Erv Walter) writes: > In article <[EMAIL PROTECTED]> you wrote: > > Sorry for the late reply - catching up. > > > IMHO speed is always relevant, and so is memory usage. This is the trap > > Micro$oft > > and Apple have fallen into. Just because the hardware is capable of running > > faster > > is no excuse for sloppy coding. I'm not saying everything should be written > > in assembly > > language and optimized, but horsepower is not a substitute either. > > Memory usage is important, but the useage time is short in this > sense. Speed is important too, but the extra 30 seconds it takes to > uncompress somethis is made up for in this case by the 5 minutes saved > in downloading. This, of course, is only true if you have a slow link > to the internet, but I think that that is true for a majority of > people. > > Erv Nobody (so I hope) wants to 100% replace gzip with bzip (which would be possible anyway). Only stuff that greatly benefits from it should be changed (thats extremly large and time and memory consuming stuff like X sources). >From that point of view memory should be that much of a problem. Think about how much memory X needs, esspezially for compilation. People, who unpack the X source, should have a large enough maschine to run bzip2 nicely. Anyway, bzip2 runs with 2.5 MB ram, which is nothing compared to what X needs to compile. The speed is also relative low. Whats 30 seconds decompression more to 20 MB download saved on a 14.4 modem connection? Whats 30 seconds compared to 20 hours of compilation? On fast maschines the decompression time is not that much more and on slow maschines uncompressing something like X sourcen takes more than 30 minutes. If someone waits 30 minutes for decompression he will not sit there and wait, he will do something else in parallel and then waiting 35 minutes is not a big problem. I like the suggestion to have signed tar files instead of signed gz files. The tar files could be compressed any way one likes and it could still be checkt for correctness. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Modula-3
Do we have a modula-3 compiler? I thought about packaging cvsup. Since postgresql is distributed via cvsup I use it anyway and I'd like to get rid of that local precompiled libc5 version I use right now. But packaging modula-3 compiler seems like a lot of work. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Modula-3
On Wed, Apr 22, 1998 at 02:34:51PM +0200, Michael Meskes wrote: > Do we have a modula-3 compiler? I thought about packaging cvsup. Since > postgresql is distributed via cvsup I use it anyway and I'd like to get rid > of that local precompiled libc5 version I use right now. But packaging > modula-3 compiler seems like a lot of work. Not as far as I know. There was a positing about this in February on debian-devel or debian-private. There's an address given from the group who has ported it to something. I don't have it handy, sorry, I only have a note, reminding me that s/o should take a look at it... Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Upgrading Debian 1.3.1r6 to frozen
-BEGIN PGP SIGNED MESSAGE- Hi there, I somewhere read that you need more beta testing of frozen, so I updated my system yesterday. Here's my report: System: P100, 64 MB RAM, IBM 4,3 GB (DCAA), Quantum 1,2 GB (Fireball), Fritz! ISDN, Spea Mercury P64 OS: WinNT and Debian 1.3.1r6 The debian System was updated regulary, from 1.1 (?) on. Steps: 1) Made 2 CDs from ftp.de.debian.org, 04/21/98, one containing the main stuff, the other containing non-free, contrib and non-US 2) Used autoup.sh to upgrade safely to libc6 3) Used dselect with the "main" CD to upgrade Used dselect with "non-free, contrib, non-US" CD to upgrade 4) Rebooted. aka 1): How do you plan to create CDs? It was a bit messy when dselect first only updates the list of the "main" packages and complained because many of the old non-free etc. packages were missing some library after updating the list of available packages: xtar-dmotif, xtetris, tgif, gs-aladdin, xwpick, xpdf, xsnow were looking for "elf-x11r6lib" which was no more longer available. This let me end up in the dependency conflict situation we all like so much ;-) aka 2): I used: autoup.sh,v 0.23 1998/03/26 15:31:10 for upgarding safely . I guess a newer version exists, but I was not able to find it (very slow connection yesterday, some servers unavailable). The process went fine (there were some warnings/errors but at the end everything seemed to be ok). What I missed here were the last lines of the autoup.sh-file displayed (about rebooting and recreation of wtmp/utmp). Does dpkg really depend on libstdc++ ? aka 3): I do not know if my autoup.sh-script was outdated, but the first thing (after more or less resolving all dependency problems) I ran into was trouble with slang. It was the first package dselect wanted to install (lines wrapped): : Looking for part 1 of slang0.99.38 ... /cdrom/debian/stable/\ binary-i386/libs/slang0.99.38_0.99.38-2.18.deb : Running dpkg -iB for slang0.99.38 ... : dpkg: regarding .../slang0.99.38_0.99.38-2.18.deb containing\ slang0.99.38: : slang0.99.38 conflicts with slang0.99.34 (<< 0.99.38-2.3) : slang0.99.34 (version 0.99.38-2) is installed. : dpkg: error processing /cdrom/debian/stable/binary-i386/libs/\ slang0.99.38_0.99.38-2.18.deb (--install): : conflicting packages - not installing slang0.99.38 After that, dselect did not work any more, I had to deinstall slang0.99.34 and the install slang0.99.38 by hand. Then dselect was fine again... Then there were many small problems like: Unpacking doc-base (from .../doc/doc-base_0.5.deb) ... /var/lib/dpkg/tmp.ci/preinst: `cleanup-old-bug': not a valid identifier libcompfaceg1 conflicts with compface (<= 89.11.11-10) compface (version 89.11.11-9) is installed. libgpmg1 conflicts with libgpm1 (<< 1.12-3) libgpm1 (version 1.10-6) is installed. The wu-ftpd error (manpage ftpd). but most of them disappeared after the second or third run of "Install". The biggest problems I had were: e2fsprogs, e2fslibsg, quota: Completely broken dependency scheme. quota wants e2fslibsg, e2fsprogs providesit, quota doesn't want e2fsprogs provided version and so on. There were other packages involved in this, too, but most of them suddenly installed fine. quota didn't. I now have e2fsprogs installed and quota with --force-depends. Did not yet check if it works. emacs20, emacs19, emacs, emacsec-common, elib: What the heck are you doing here? It is absolutely unclear which to install!? I first tried emacs20/emacsen-common/elib but ran into trouble when byte-compiling elib. Then I tried emacs (there is no emacs19 package although some other(s?) depends on it), but emacsen-common and elib do not like him. This is, at least, a "tricky thing"... I now have emacs-19.34 installed, but pcl-cvs is not working because of the missing elib. The package emacsen-common suggests that it is common for all emacs. Why doesn't it like mine? There has to be some more explanation. The small infos to emacs and emacs20 were: "GNU Emacs is the extensible self-documenting text editor." Thanks for that, but I knew it before. What I would like to have is some suggestion which to install (and why). Suggestion: What dselect really needs is some more control over the priority of packages and the installation order. The problem is as follows: I have a debian 1.3.1r6 System with package A, version x, installed. Now I upgrade to frozen (2.0) and would like to have a package B which depends on A, version y > x! The new package A, which is to be installed _after_ B, has the required version number, but when B gets to be installed, dselect barfs about the wrong version number of A (it only knows x!) and does not install B. Later, when it gets to A, A
l3 - MPEG Layer 3 encoder
Hi! Who maintains frozen? l3 (non-free) has expired. The author (Fraunhofer Institut IIS) has released a new version called mp3encdemo, but this version is limited to 30s of music (so it#s not longer useful) :(((. So please remove my l3 package from frozen. Thanks. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
autoconf problem
Hello,
when building the packages I want to maintain I need to define
some PATH-variables for pixmaps and libraries.
What would be the appropriate way to do that?
In the case of xteddy, I have to tell xteddy, where to look for
the pixmaps (my version can load not only xteddy but any pixmap
which is given in some strict rules).
I tried autoconf. My configure.in contains the lines
...
AC_DEFINE_UNQUOTED(PIXMAP_PATH, "${prefix}/include/X11/pixmaps")
...
This should produce in the resulting Makefile
DEFS = -DPIXMAP_PATH=\"${prefix}/include/X11/pixmaps\" \
but if configure is invoked without any arguments
DEFS = -DPIXMAP_PATH=\"NONE/include/X11/pixmaps\"
and if a prefix was given (configure --prefix=/usr)
DEFS = -DPIXMAP_PATH=\"/usr/include/X11/pixmaps\"
Is there another way to tell programs where to look for pixmaps
or libraries. Is there a library which handles such problems
(I want to do the following: at first search the files in "." than
in the path defined by PIXMAP_PATH, may be it is reasonable to
use an environment variable for further searchpath. This is a
common problem in my opinion so that there might be some ready
to use functions in a library.)
Regards
Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: l3 - MPEG Layer 3 encoder
-BEGIN PGP SIGNED MESSAGE- > Who maintains frozen? l3 (non-free) has expired. The author (Fraunhofer > Institut IIS) has released a new version called mp3encdemo, but this > version is limited to 30s of music (so it#s not longer useful) :(((. Well, you're in luck. A bunch of us from the linux-smp list are hacking on the dist10 mpeg audio encoder/decoder in the hopes of producing something l3enc-equivalent or better. (Read: slink ought to have a good, free mp3 encoder in it ...) A policy question, in general: many of the people who wrote this software either didn't leave an email address for contacting them, or their email bounces. It would be nice to release this software under some sort of license, but it's currently only marked with a "it's not our fault if it breaks anything" notice and nothing more. Anything we can do short of rewriting the whole thing, or is there a "proper" way to re-release something without being able to find the original authors? Andy -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNT4ANHT0BN7Y/oDVAQG+CAP/Xamrk2UVHsLotbaARqhFw66LfNpEmdJY CSK8LO1H9kkkSmJpvMwMJImZi3dYTaLV9SzUtpmcIKrIhsOJqxXr+8Hw/+tgeECs 8+F/rd5EkwiN57pr56zIP1VybUwtr8DeD5fRrDthSfIbnOG8Oe5lLk34ZM62n7BP csU+szmUKzg= =IESy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconf problem
Andreas Tille <[EMAIL PROTECTED]> writes: > Hello, > > Is there another way to tell programs where to look for pixmaps > or libraries. Is there a library which handles such problems > (I want to do the following: at first search the files in "." than > in the path defined by PIXMAP_PATH, may be it is reasonable to > use an environment variable for further searchpath. This is a > common problem in my opinion so that there might be some ready > to use functions in a library.) Do you look at ~/ ? Maybe ~/.tedy.xpm should be used if present. :) May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: l3 - MPEG Layer 3 encoder
[EMAIL PROTECTED] (Marco Budde) writes: > Who maintains frozen? l3 (non-free) has expired. The author > (Fraunhofer Institut IIS) has released a new version called > mp3encdemo, but this version is limited to 30s of music (so it#s not > longer useful) :(((. > > So please remove my l3 package from frozen. Thanks. File a bug against ftp.debian.org. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: weird utmp/perl problem
On 21 Apr 1998 08:55:51 -0700, [EMAIL PROTECTED] (Karl M. Hegbloom) said: > >> It's just a silly bug. It calls that code from some scripts which >> have fd0 dup'd elsewhere, so isatty(0) is false and getlogin() fails. > > Will someone please fix it? It's really annoying. Is it in the bug > sys? The bug is in libc6. getlogin() is supposed to work even if isatty(0) is false. It is bug #17528. -- Roderick Schertler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconf problem
On 22 Apr 1998, Brederlow wrote: > Do you look at ~/ ? Maybe ~/.tedy.xpm should be used if present. :) That seems me a little bit oversized. To make it more clear what I want to do: xteddy needs four files: NAME_bw.xbm -> gray if libXpm isn't available NAME_color.xpm -> the nice Teddy if NAME==xteddy NAME_icon.xbm -> an icon NAME_mask.xbm -> the mask shape My new version of xteddy can be called via xteddy -F ... If no `-F` parameter is given name equals to xteddy. You have to place this four files for one pixmap to show instead of xteddy 1. in the current directory 2. in the directory defined via PIXMAP_PATH at compile time May be it makes sense to look for a further PATH to overwrite PIXMAP_PATH at runtime via environment variable. --- Do you think that this makes sense? How to get the PIXMAP_PATH right, if no --prefix option was given when invoking configure? (This was the initial question which is importand for other packages which I intend to package, too.) Which is the appropriate directory for such kind of files after FNS (to make the package right for slink)? Regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconf problem
--On Wed, Apr 22, 1998 5:23 pm +0200 "Andreas Tille" <[EMAIL PROTECTED]> wrote: > On 22 Apr 1998, Brederlow wrote: > >> Do you look at ~/ ? Maybe ~/.tedy.xpm should be used if present. :) > That seems me a little bit oversized. To make it more clear what I want to > do: > > xteddy needs four files: > NAME_bw.xbm -> gray if libXpm isn't available > NAME_color.xpm -> the nice Teddy if NAME==xteddy > NAME_icon.xbm -> an icon > NAME_mask.xbm -> the mask shape > > My new version of xteddy can be called via > > xteddy -F ... > > If no `-F` parameter is given name equals to xteddy. You have to place > this four files for one pixmap to show instead of xteddy OK. This doesn't answer your question, but as an additional feature request, how about if no -F is given, use argv[0]. So a hard link to xpenguin gets the debian chap, etc... > 1. in the current directory > 2. in the directory defined via PIXMAP_PATH at compile time > May be it makes sense to look for a further PATH to overwrite PIXMAP_PATH > at runtime via environment variable. --- Do you think that this makes > sense? > > How to get the PIXMAP_PATH right, if no --prefix option was given > when invoking configure? (This was the initial question which is > importand for other packages which I intend to package, too.) What does debian's automatic make supply for --prefix? Nothing? Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | 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. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconf problem
On Wed, 22 Apr 1998, Jules Bean wrote: > OK. This doesn't answer your question, but as an additional feature > request, how about if no -F is given, use argv[0]. So a hard link to > xpenguin gets the debian chap, etc... That's a good idea. I'll do that. > What does debian's automatic make supply for --prefix? Nothing? No, it is /usr or /usr/X11R6 and so my problem would occure when building the Debian package, but I think it isn't a good solution when supporting the plain source. Regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/passwd : which software does support this ?
Remco Blaakmeer <[EMAIL PROTECTED]> wrote: > I am not really a programer, but I wonder how hard it would be to put > support for these fields in all programs like login, xdm, cron, at and > anything I am forgetting. Could this be done? The difficulty isn't so much making the change, once (though that can be a problem), but making the change every time something comes from the original source, changed. Sometimes this isn't much of a problem (maybe the source has been stable for the last 11 years and needs a new caretaker anyways, or maybe the original author is receptive to changes). Other times it can be a real pain (maybe the source needs to run on 100 different operating systems and the upstream maintainer isn't interested in code that breaks 50 of those). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
> What would be the use of looking at a screen full of control characters? Because when I look at a binary with less, I *mean* to do that... usually to look for corruption (blocks of nulls) or things like *short* strings or strings not in the text section, that "strings" *won't find*. > mentioned above. But this set of commands gives me a lot of useful stuff > with only command. Sure -- but it should be a *different* command than less... Mostly I'm being lazy, of course - I haven't needed to know how to disable lesspipe for my own use; if this gets added, I will. Someone else may have to judge if this is a useful thing for naive users... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Vim @ bzip2
Hi all there! During reading the bzip2 thread, because there is no bzip2 support (at least until bzip2 is integrated in gzip), I added folowing in vimrc: augroup bzip2 " Remove all bzip2 autocommands au! " Enable editing of bzipped files " read: set binary mode before reading the file " uncompress text in buffer after reading " write: compress file after writing " append: uncompress file, append, compress file autocmd BufReadPre,FileReadPre*.bz2 set bin autocmd BufReadPost,FileReadPost *.bz2 set cmdheight=2|'[,']!bunzip2 autocmd BufReadPost,FileReadPost *.bz2 set cmdheight=1 nobin|execute ":doautocmd BufReadPost " . %:r autocmd BufWritePost,FileWritePost*.bz2 !mv :r autocmd BufWritePost,FileWritePost*.bz2 !bzip2 :r autocmd FileAppendPre *.bz2 !bunzip2 autocmd FileAppendPre *.bz2 !mv :r autocmd FileAppendPost*.bz2 !mv :r autocmd FileAppendPost*.bz2 !bzip2 -9 --repetitive-best :r augroup END So I'm posting it here so anyone can use it and eventually include it into distribution. Patching less in this style is IMHO also good thing, will the maintainer do this? P.S. Is something wrong with this: *.tar.gz|*.tgz|*.tar.Z) tar tzvf $1 ;; *.gz|*.Z|*.z) gzip -dc $1 ;; +*.tar.bz2|*.tbz2) +tar tIvf $1 ;; + +*.bz2) +if [ -x /usr/bin/bunzip2]; then bunzip2 -c $1; else echo "No bunzip2 available"; fi ;; + *.tar) tar tvf $1 ;; in /usr/bin/lessfile, or is error in something else (prints compressed garbage on bzipped files) Ax -- Vaclav Hula [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~ax -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
> What would be the use of looking at a screen full of control characters? Because when I look at a binary with less, I *mean* to do that... usually to look for corruption (blocks of nulls) or things like *short* strings or strings not in the text section, that "strings" *won't find*. No kidding. I do the same thing quite often myself, generally when I'm debugging a low-level tool. However, you can get around this, if lesspipe is `too smart', by simply doing `cat binary|less' instead of `less binary'. So I think the default should be to give some sort of useful display for a binary file, although a display from `strings' is not my idea of `useful'. OTOH, the output of `objdump' or `nm -s' might often be useful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg-perl should predepend on perl?
I installed a debian hamm system yesterday and noticed a problem involving dpkg-perl. After installing the base system from disks, I ran dselect to install some more packages. On the first installation run however, dpkg-perl was the first package installed, and it failed because perl was not yet installed. dpkg-perl was installed first since some other packages pre-depend on it. Furthermore, the failed installation of dpkg-perl left dselect in an unusable state until I installed perl separately with dpkg. This is broken, and I believe release-critical, yet the solution isn't easy. Arguably dselect should ensure dependencies of packages that need to be pre-depended upon are fulfilled. However I think the simplest solution would be to make dpkg-perl predepend on perl. Does anyone else have a view on this? Martin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
On Wed, Apr 22, 1998 at 01:17:27PM -0400, Ben Pfaff wrote: >> What would be the use of looking at a screen full of control characters? > >Because when I look at a binary with less, I *mean* to do >that... usually to look for corruption (blocks of nulls) or things >like *short* strings or strings not in the text section, that >"strings" *won't find*. > > No kidding. I do the same thing quite often myself, generally when > I'm debugging a low-level tool. However, you can get around this, if > lesspipe is `too smart', by simply doing `cat binary|less' instead of > `less binary'. One of the things I like about Linux, and Unix in general, is that it doesn't try to be smart where you don't expect it to. I think that if users want to see 'nm' or strings or whatever, they can do those things. nm binary | less, or whatever.. Let's leave the default alone:-> Ciao, -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconf problem
Andreas Tille <[EMAIL PROTECTED]> writes: > On 22 Apr 1998, Brederlow wrote: > > > Do you look at ~/ ? Maybe ~/.tedy.xpm should be used if present. :) > That seems me a little bit oversized. To make it more clear what I want to > do: > > xteddy needs four files: > NAME_bw.xbm -> gray if libXpm isn't available > NAME_color.xpm -> the nice Teddy if NAME==xteddy > NAME_icon.xbm -> an icon > NAME_mask.xbm -> the mask shape > > My new version of xteddy can be called via > > xteddy -F ... > > If no `-F` parameter is given name equals to xteddy. You have to place You should take $0 (the 0 parameter), which equals to the programm name as if no name is given. That way one can have a xteddy programm for the teddy and a xpenguin (link to xteddy) for the penguin. The same binary can thus be reused. Thats how gzip, gunzip and zcat work (as well as others). > this four files for one pixmap to show instead of xteddy > 1. in the current directory > 2. in the directory defined via PIXMAP_PATH at compile time > May be it makes sense to look for a further PATH to overwrite PIXMAP_PATH > at runtime via environment variable. --- Do you think that this makes > sense? The users home should be added to that list. I would place my private tedy there and I dont want to cd there just to start teddy. > How to get the PIXMAP_PATH right, if no --prefix option was given > when invoking configure? (This was the initial question which is > importand for other packages which I intend to package, too.) I don't know. In all I did so far the --prefix wasnt used for some paths and when no prefix was given /usr/local/ was default. > Which is the appropriate directory for such kind of files after > FNS (to make the package right for slink)? No clue again, I'm just starting to read the policy file while I'm aplying for a maintainer key. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconf problem
"Jules Bean" <[EMAIL PROTECTED]> writes: > --On Wed, Apr 22, 1998 5:23 pm +0200 "Andreas Tille" > <[EMAIL PROTECTED]> wrote: > OK. This doesn't answer your question, but as an additional feature > request, how about if no -F is given, use argv[0]. So a hard link to > xpenguin gets the debian chap, etc... A softlink would do. You can try it with gzip, gunzip, unzip and zcat. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-perl should predepend on perl?
On Thu, Apr 23, 1998 at 04:54:37AM +1000, Martin Mitchell wrote: > I installed a debian hamm system yesterday and noticed a problem involving > dpkg-perl. After installing the base system from disks, I ran dselect > to install some more packages. On the first installation run however, > dpkg-perl was the first package installed, and it failed because perl > was not yet installed. dpkg-perl was installed first since some other > packages pre-depend on it. Furthermore, the failed installation of > dpkg-perl left dselect in an unusable state until I installed perl > separately with dpkg. > > This is broken, and I believe release-critical, yet the solution isn't > easy. Arguably dselect should ensure dependencies of packages that need > to be pre-depended upon are fulfilled. However I think the simplest > solution would be to make dpkg-perl predepend on perl. Does anyone else > have a view on this? Wouldn't it be enough to make dpkg-perl predepend on perl-base instead of the whole perl? Or does it need some functionality not provided in perl-base? -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vim @ bzip2
Vaclav Hula <[EMAIL PROTECTED]> writes: > Hi all there! Hi > P.S. Is something wrong with this: > >*.tar.gz|*.tgz|*.tar.Z) > tar tzvf $1 ;; > > *.gz|*.Z|*.z) > gzip -dc $1 ;; > > +*.tar.bz2|*.tbz2) > +tar tIvf $1 ;; Tar forks to bzip2, so that should be present. > + > +*.bz2) > +if [ -x /usr/bin/bunzip2]; then bunzip2 -c $1; else echo "No > bunzip2 available"; fi ;; Try "bzip2 -d" as a fallback to bunzip2. > + > *.tar) > tar tvf $1 ;; > > in /usr/bin/lessfile, or is error in something else (prints compressed > garbage on bzipped files) May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Yet another install doc update.
I have fixed yet some more little mistakes, and enhanced the install doc some more. This time, I mostly had to include the suggestions from other people. Thanks to Ben Gertzfield, Bob Hilliard and Jim Van Zandt (and I know I am forgetting someone) for their contributions. I think this is very close to final. Please take a look at it, and see if there are still some things missing. Thanks. -- Proudly running Debian Linux! Linux vs. Windows is a no-Win situation Igor Grobman [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
fakeroot and eg++
I seem to be experiencing problems with builds under the fakeroot environment not creating setuid/gid flags correctly. This may be related to the fact that I have installed eg++ and libstdc++-2.8, while the current fakeroot (0.0-11) is still built with libstdc++-2.7.2. Trying to rebuild fakeroot from the sources fails because the include file "String" is not available. Since I got the impression that eg++ was the standard environment for hamm, I am a bit surprised that this hasn't come up yet. Jens -- Anyone got a sig to let? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lists archives outside debian.org
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Martin Schulze) writes: > On Thu, Apr 16, 1998 at 12:58:08PM +0200, [EMAIL PROTECTED] wrote: >> I think it would be useful to archive the Debian lists there too (in >> addition to our www.debian.org archive). > > Do others have an oppinion on it, too, or is it just Ray and Marco? Debian-private should not be archived by a third party. I'm undecided about the others. -- ||k || Steve Kostecke| Debian GNU/Linux ||__|| [EMAIL PROTECTED]| The OpenSource Operating System |/__\| http://kostecke.home.ml.org | http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
David Welton wrote: > One of the things I like about Linux, and Unix in general, is that it > doesn't try to be smart where you don't expect it to. But when you say, 'less binfile', what do you expect it to do? I had thought that the idea of lesspipe is to have less give you more useful information when you use it on different types of files-- gzip for gz files, tar -t for tar files, groff for manpages, etc... If I _wanted_ to look at the raw data of a gzipped file, I could do it. But how often do I want to do that? Having less display a plethora of information about an executable ( file, size, ldd, strings, etc) seems to me to be more useful for everyday use than having less show me the raw data. If, as you say, the more common case is that you want to look at the raw data of an executable, then I withdraw my claim. However, I think that the majority of users would find well-readable information more useful. Carl -- [EMAIL PROTECTED] The sun's not eternal That's why there's the blues... -- Ginsburg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
On Wed, Apr 22, 1998 at 04:15:51PM -0400, Carl Mummert wrote: > David Welton wrote: > > One of the things I like about Linux, and Unix in general, is that it > > doesn't try to be smart where you don't expect it to. > > But when you say, 'less binfile', what do you expect it to do? Show me the contents of the file. If I want to interpret those contents before I see them, then I'll pipe them. If not, then I expect it to do little else. > I had thought that the idea of lesspipe is to have less give you more > useful information when you use it on different types of files-- gzip for > gz files, tar -t for tar files, groff for manpages, etc... If I _wanted_ > to look at the raw data of a gzipped file, I could do it. But how often > do I want to do that? It sounds like a handy little program, maybe we should give it a different name, like 'nless' or something similiar. We already have a zless, so, why not build on that and just use a different name. Or is there something that I am missing because of my late entry into the discussion (sorry)? Thanks, -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lists archives outside debian.org
On Wed, Apr 22, 1998 at 04:15:04PM -0300, Steve Kostecke wrote: > Debian-private should not be archived by a third party. I'm undecided > about the others. Debian-private is out of discussion. It must not be archived outside of active developers - that's the case atm. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
David Welton wrote: > zless, so, why not build on that and just use a different name. Or is > there something that I am missing because of my late entry into the > discussion (sorry)? Background: when 'less' runs, it looks for an environment var called "LESSOPEN" If it finds one, it uses the value to spawn a process from which less will display the standard output. The usual usage of this is to automatically unzip .gz files, so you don't have to do so by hand. Another common use is to run tar -t on tar files so that you see the list of files inside, insead of contral characters The general question is, how much do we want this lessopen program to do? The specific queston is, what should it do with binaries? The old solution was to run strings on the binaries, which was less than acceptable. Several people rightly complained about that. The new question is, which is better: a lot of info about the binary file, or the contents? I have been convinced that there is some utility in looking at the raw files; I also see some utility in information about the files. However, since the lessopen program is only a shell script, I think the best solution may be to leave binaries alone and allow users to add entries for them if the users so wish. Carl -- [EMAIL PROTECTED] The sun's not eternal That's why there's the blues... -- Ginsburg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
master status
Only a few files were corrupted in the crash. I'll fix everything up this evening (in about 5 hours) and turn ftp access on again. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/bin/sh has no man page.
/bin/sh is provided by bash, but doesn't come with its own man page. How does one determine the differences between sh and bash? Is there some documentation that I have missed? Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
Igor Grobman <[EMAIL PROTECTED]> writes: > Anyway, could you explain to me how this advertising clause is so > harmful? http://www.oryxsoft.com/rms/rms-bsd-license.html> -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
>>Anyway, could you explain to me how this advertising clause is so harmful? > > See http://www.gnu.org/philosophy/bsd.html. Ok, this helps. I am still at a loss why we mention BSD as one of the "free" licenses in DFSG, and have no mention of this problem there. I'll try to contact Moxa about this problem, but I doubt a successful outcome, since I think they really want to get some publicity out of making their software free one way or another. Am I correct that this clause doesn't make software really non-free (DFSG definition) ? Or am I missing something obvious in DFSG? Thanks. -- Proudly running Debian Linux! Linux vs. Windows is a no-Win situation Igor Grobman [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > Urk! It's the Obnoxious BSD Advertising Clause, back to haunt us. > > Including the OBSDAC would make Moxa non-free. Say _what_? I do *not* think so. (Hint: look at glibc's copyright file) -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: elvis package
In article <[EMAIL PROTECTED]> you write: >On Fri, 17 Apr 1998, Martin Schulze wrote: > >> This might look confusing but the situation is different as >> the author of vile is aware of the unfreeness and distributes >> new parts under the GPL. >> >> "the bulk of vile _cannot_ be covered by the GPL due to murky origins and >> previous copyrights. however, the code that i have written (and i suspect >> this is true of contributions made by others as well) was written to be >> published, and to be shared with others. please respect this. see the top >> of main.c for the restrictions put on the original MicroEMACS code upon >> which vile was based." [...] > >I am not a license expert, but from the GPL I understand that if you make >modifications to a program and you put the modifications under GPL, you >have to put the entire program under GPL, no matter what the original >license was. If the license of the original program doesn't allow this, >you get an undistributable program. > >Can any license expert comment on this? I'm not a licence expert either, but I have seen lots of discussion about the effects of various licences both here and on usenet. ;-) I'm pretty sure that a program must be either entirely GPLed, or contain no GPLed parts. The only way around this would be to separate the GPLed and non-GPLable code into separate programs with a well-defined, documented interface, and even then it would likely still be controvercial. The whole point of the GPL is to ensure that you can't integrate non-GPLed parts into GPLed programs or vice-versa. There was some discussion about a related issue on gnu.misc.discuss when the NPL was being drafted. RMS wanted a clause in the NPL to allow NPLed code to be converted to GPLed. This didn't materialise, thus it's now illegal to incorporate GPLed code into Mozilla and distribute the result. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /bin/sh has no man page.
> "Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: Dale> /bin/sh is provided by bash, but doesn't come with its own Dale> man page. How does one determine the differences between sh Dale> and bash? On my system /bin/sh -> bash, so I guess there aren't many. Of course I could have just put both feet in my mouth too -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: elvis package
Charles Briscoe-Smith <[EMAIL PROTECTED]> wrote: > I'm pretty sure that a program must be either entirely GPLed, > or contain no GPLed parts. More precisely, the non-gpled parts must not have terms which prevent compliance with the gpled parts. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
In article <[EMAIL PROTECTED]> igor wrote: > >I intend to package up Moxa radius, a fully-featured radius server package. >It has some of the features that are not available in any of freely available >radius's that debian contains, such as proxy support. I found it accidentally >on the net, and at that point it had no license at all. I contacted the >authers, and convinced them Free Software is The Way (tm). This is a first >one for me, so I am very proud of myself ;-). You can find it at >ftp.moxa.com/drivers/cn2000/radius.2.2.tar.Z . I am not sure if that one has >a new license yet, but here it is: > >/* = > * Copyright (c) 1998 Moxa Technologies Corp, LTD. All rights reserved. [...] > * 3. All advertising materials mentioning features or use of this > *software must display the following acknowledgment: > *"This product includes software developed by the Moxa Technologies > *Corp, LTD. for use in the Moxa RADIUS Server (http://www.moxa.com/)." Urk! It's the Obnoxious BSD Advertising Clause, back to haunt us. Including the OBSDAC would make Moxa non-free. Please educate them about that, too, and suggest they use an XFree86-like licence rather than this BSD-like one. Thanks, -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
> In article <[EMAIL PROTECTED]> igor wrote: >a new license yet, but here it is: > > > >/* = > > * Copyright (c) 1998 Moxa Technologies Corp, LTD. All rights reserved. > [...] > > * 3. All advertising materials mentioning features or use of this > > *software must display the following acknowledgment: > > *"This product includes software developed by the Moxa Technologies > > *Corp, LTD. for use in the Moxa RADIUS Server (http://www.moxa.com/)." > > Urk! It's the Obnoxious BSD Advertising Clause, back to haunt us. > > Including the OBSDAC would make Moxa non-free. Please educate them > about that, too, and suggest they use an XFree86-like licence rather > than this BSD-like one. I don't understand. We haven't declared all BSD software non-free yet, have we? How come moxa doesn't fit the bill. It has the exact same clause. I seem to remember a long discussion on -devel, but didn't we conclude that this BSD clause doesn't make software non-free? Anyway, could you explain to me how this advertising clause is so harmful? Thanks. -- Proudly running Debian Linux! Linux vs. Windows is a no-Win situation Igor Grobman [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /bin/sh has no man page.
On Wed, Apr 22, 1998 at 04:30:42PM -0700, Stephen Zander wrote: > > "Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> /bin/sh is provided by bash, but doesn't come with its own > Dale> man page. How does one determine the differences between sh > Dale> and bash? > > On my system /bin/sh -> bash, so I guess there aren't many. > > Of course I could have just put both feet in my mouth too Thing is that bash behaves different if called as sh or bash. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
Carl Mummert <[EMAIL PROTECTED]> wrote: > But when you say, 'less binfile', what do you expect it to do? Pretty much the same thing view binfile does. Note also that the real problem lesspipe was designed for would be better addressed by a compressed file system. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Modula-3
On Wed, Apr 22, 1998 at 02:42:37PM +0200, Martin Schulze wrote: > On Wed, Apr 22, 1998 at 02:34:51PM +0200, Michael Meskes wrote: > > Do we have a modula-3 compiler? I thought about packaging cvsup. Since > > postgresql is distributed via cvsup I use it anyway and I'd like to get rid > > of that local precompiled libc5 version I use right now. But packaging > > modula-3 compiler seems like a lot of work. > > Not as far as I know. There was a positing about this in February > on debian-devel or debian-private. There's an address given from > the group who has ported it to something. I don't have it handy, > sorry, I only have a note, reminding me that s/o should take a > look at it... Stuart Lamble <[EMAIL PROTECTED]> was working on packaging the SRC Modula-3 (I think), but he had been very very busy (?) and for some time he didn't (or still doesn't?) have access to the Internet. AFAIK, there are three alternative Modula-3 distributions that we could choose to package: * DEC SRC Modula-3 3.6 * Cambridge Modula-3 (cam3) - Richard Watts <[EMAIL PROTECTED]> * École Polytechnique de Montréal Modula-3 (pm3) - Michel Dagenais <[EMAIL PROTECTED]> http://m3.polymtl.ca/dagenais/home/home.html http://m3.polymtl.ca/ (?) CAM3 and PM3 are both based on SRC M3 3.6 (?) and have been reported to work on Red Hat 5.0 (glibc2) AFAIK. :-) I recommend that we go with either PM3 or CAM3. (I would prefer PM3 myself because it is a Product of Canada. :-) For more information about Modula-3, check out: http://www.w3.org/ Cheers, Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED] University of Alberta, Canada [EMAIL PROTECTED] Keep smiling! *^_^* Come visit Our Lady of Victory Camp -- http://olvc.home.ml.org/ or http://www.ualberta.ca/~foka/OLVC/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
