Re: dc and bc in Important?
On Jun 23, John Goerzen wrote It seems to me that dc and bc aren't vital to the workings of a system (when I deselect them, dselect doesn't warn about any dependencies), yet they are in Important. Why? In addition to what everyone else has said about what Important Really Means, please realize that bc/dc are ideal for doing arithmetic in shell scripts. [Sure, you can use awk, just as you can use awk to replace grep -- but it's awkward.] -- Raul For most math, expr works just fine. Of course, expr is limited to integer math, but it works and is portable. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Retracting request for chos to be standard
Christoph == Christoph Lameter [EMAIL PROTECTED] writes: Christoph Lilo 2.0 has the ability to display a file before the Christoph prompt and also the ability to boot something with a Christoph single keystroke. If someone could update the lilo Christoph package and provide a decent configuration then lilo Christoph could also offer a nice menu on boot up so that newbies Christoph are no longer irritated. I'll have a look at this. Christoph Maybe lilo could also replace syslinux for the Christoph bootdisks?? As someone else already said, this would be a bad idea, since the advantage of syslinux is its DOS support. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. My wife likes chos because it offers a nice simple and friendly and obvious like Windoze type of menu that lets her use the arrow keys to move a color menu bar onto the (unmentionable OS) selection a press enter. This is very easy, and requires no domestic fighting. I took a quick glance at the lilo 2.0 user's manual last night and I wasn't convinced that the message feature was going to be a nice simple and friendly and obvious like Windoze type of replacement. chos is much better than booting Linux using loadlin from a certain unmentionable OS, (which is how I used to not freak out my wife). If the message feature of lilo 2.0 can make lilo as friendly as chos, fine, I will use it. I doubt I will be making a switch really soon though. How hard would it be to hack bzImage support into chos? That is the only real problem with chos, right? Are there any other features lacking from it that make it unusable by Debian? I can certainly attest to the fact that this is one piece of software that passes the wife test! -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
On Mon, 23 Jun 1997, Alex Yukhimets wrote: [snip] contrib. Try to run it on Lesstif and it won't work, because it will not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib. Yeah, but Lesstif was not meant to be *binary* compatible with real Motif, only *source code* compatible! Is this true? Then there would be no reason to create the motif-libs virtual packages! (The only use for them would be to allow drop-in replacements of the compiled shared library packages.) Thanks, Chris -- Christian Schwarz The reason we need virtual packages is so that we can allow people who (like myself) have gone out and bought real Motif to use it on Debian. I would be glad to throw away my Motif CD, and only use Lesstif. Last time I tried compiling Nedit against lesstif, the results were almost usable, but still disappointing. I am getting a new computer (K6-200) to replace my old 486, and I plan on compiling Nedit against the latest Lesstif again. If it works, i will upload it (and we can get it out of contrib). I still plan on compiling a statically linked version against REAL Motif though (for those who want everything to work perfectly). I don't believe Lesstif is quite ready for primetime. Regardless, since there are two versions of Motif, with different Library names that are not compatable (sure, you can recompile but they are not binary compatable), we need both motif12 and motif20 virtual packages. Lesstif should be modified to provide motif12. For other people that have commercial Motif, we need to have TWO motif dummy packages. Or one that provides both virtual packages... Just my $0.02, -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
On Sun, 22 Jun 1997, Dirk Eddelbuettel wrote: What about the motif-dummy thingie we discussed? How can I run plan having Motif and not lesstif installed? Can you make sure it doesn't Depends: on lesstif, but rather on a virtual package 'motif-libs' which lesstif, and a to-be-created-dummy package for Motif owners, would provide. Is that doable? CC'ed this to the virtual-package-list maintainer for comments. That's a good idea! AFAIK, Motif 1.x and 2.x are quite different. Shouldn't we use two different virtual package names for these major versions? (You can't use versions of a virtual package, yet.) I don't think that support for different Moitfs are needed. All known software despite of being compiled with Motif 2.0 does not use features not present in Motif 1.2 The reason for this is that big unices does not have Motif 2.0 actively shiped from the vendors yet and using Motif 2.0 features would make your application imposible to port. *When* situation changes, I don't think that anyone using Motif for i386 Linux would have Motif 1.2 (And franckly speaking, 2.0 also. By that time all vendors will be shipping 2.1 which would _hopefully_ be compiled against glibc for Linux) Alex Y. But things linked against Motif 2.0 cannot link against and run with a Motif 1.2 library. Take for example nedit-dmotif, currently in contrib. Try to run it on Lesstif and it won't work, because it will not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib. When I compiled nedit, I used a Motif 2.0 library. I agree with Chris that we should have both a motif12 and a motif20 virtual package. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New field `Entered-Date' in Packages.gz
That would be enable the WWW pages to mark the new packages with a `[NEW!]'. It look a silly feature, but I think that it would be very useful to users. Other package management utilities can take advantage of this field too... --=20 Nicol=E1s Lichtmaier.- Fine with me. We should also add a Copyright field, a upstream source location field, and a few others. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Editor wars considered harmful
Show me a computer that can boot off a cdrom... and gimme a cdrom that will boot up debian... And Ill buy it like a shot. Most modern motherboards will boot an IDE CD-ROM in the El Torrito format. The Debian Official CD will boot into the installation system. No floppies, no LOADLIN, etc. Bruce Where can I buy one? Neither CheapBytes nor Linux Systems Labs have made an Official CD yet because they are (apparently) waiting for us to release Debian 1.3.1 with Xfree86 3.3 and last I heard people didn't want 3.3 to go into stable... I know lsl has made TriLinux with 1.3, but that doesn't have ANY source and won't boot. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
On Mon, 23 Jun 1997, joost witteveen wrote: (in fakt so much, that I may be tempted to write it myself. You don't need that many changes). Well, you need to write your own version of make that looks for any attempt to run chmod, chown etc, and then fakes all the ownership and modes in the resulting tar. I'm not sure whether it's possible in general even then, what if the package tries to set the ownership of a file from within another shell script or a perl script; how can you intercept that so it works properly? With a few minor changes in the way packages are made---having tars all made as any user, and chowns done after the package is installed, either in the postinst or by dpkg first (the former would have the advantage of running on existing systems)---we could build as non-root. I like this. dpkg could set permissions on install based on a package file similar to the suidmanager approach. If we did this, we could also have a global security policy setting that could, using only dpkg, find all suid programs. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Plans for Debian 1.3.1?
Are there any plans for Debian 1.3.1? When will it happin, and what will be included? Will Xfree86 3.3 be included? I am curious because I want to buy one of the CHEAP official CDs, but I understand that the cheap cd makers are waiting for 1.3.1, which means there are no cheap CDs yet... -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
This sounds good to me. When finished, we should announce this on c.o.l.a. and try to see if the Red Had folks will adopt it as well. If we both adopt it as policy, then it will live on forever! -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- On Fri, 20 Jun 1997, Lars Wirzenius wrote: [ Please don't Cc: public replies to me. ] John Goerzen: Why are we using dotfile locking only? There are much better mechanisms (flock, etc.) that should be used instead. I can see no place where dotfile locking would work and flock-style locking would fail... NFS. Scripts that use procmail's lockfile. (If it doesn't already, the policy manual should explain the reasons behind policy. I'd check if it does, but I don't have a copy and am offline.) The current policy manual (2.1.3.3) only says: Mailboxes are locked using the username.lock lockfile convention, rather than fcntl, flock or lockf. This is buggy since it's not working over NFS. (I'm running into problems every few days since I use sendmail/procmail/pine over a NFS mounted /var/spool/mail !) That's the exact reason why I started this discussion again. AFAIK, there is at least one safe way to lock a file over NFS. The procedure is partially explained in the open(2) man page and is also implemented, for example, in your publib library. Since the procedure is not that simple, I suggested to provide a shared library that the other packages could be linked against, so that not every maintainer has to program this on his/her own (this is likely to produce new bugs!). And I suggested to produce modules for Perl/Python etc. Someone else mentioned that the UN*X (at least Linux) world is laking such a library and we should therefore build not a debian specific lib, but a new upstream library which can be used by the other distributions as well. IMHO, that's a very good idea. Note, that all programs will have to use the same locking mechanism (this has been discussed before). Thus, we should implement the simpliest available algorithm that is NFS-safe, since a few maintainers will probably need to hand-code this themselves (for example, for other programming languages, etc.). There are also tools available, that do locking, for example lockfile in the procmail package. However, calling this program with system produces IMHO too much unnecessary overhead and the source code of this program is a bit to complicated to force all our developers to implement this. IMHO, the code in publib looks very good. I suggest that we extract the necessary files and put them together in a new package, called liblockfile (or similar). This package should install a shared library liblockfile.so that contains a few necessary commands to lock/unlock/test a file. In addition, we could create a new lockfile binary (just as in procmail) that can be used by shell scripts or other programs (via system). We'll also provide modules for Perl/Python/etc. Any comments? (I feel like I presented these arguments several times now on this list, but we've not got any results so far.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
I cannot agree more. We should definatly add these fields to the .deb package format! This will involve a bit of work, but will be VERY worth it. No more licensing surprises, for instance. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- TOPIC 8: packages have to specify their source urls --- STATUS: DISCUSSION In addition to what you propose below, I think that dpkg -I should be concerned with some of that info. Specifically, three important fields are missing: Author: name and email of main upstream author (copyright holder) License: code describing license type Original-Site: site/URL at which the package is originally stored The Author field I think is important for giving due credit to whom rightfully deserves it. Some novice Debian users might think that the maintainer mentioned in dpkg -I is the author or the upstream maintainer. That is convenient for having users contact the Debian maintainer instead of bypassing them for the upstream author. However, I am convinced it is not fair for the real authors to create this confusion. Once the package is installed, users can check who the real author is, but they should be able to know it from the beginning. The License field shoud be a code taken from a list like the following: GPL LGPL BSD Artistic: we know what they are PD: public domain Freeware: free use and redistribution, according to Debian policy (this will be used only for packages which do not follow any of the types given above) Non-Free: does not comply with Debian definition of free software We could even go further and specify the type of non-free license. Common types are: packages containing sources --- Non-Commercial: free use and redistribution for non-commercial purposes Academic: free use and redistribution for academic/research purposes Non-Commercial-Academic: combination of previous types Source-Shareware: redistribution allowed, but payment for use expected Tidyware: free use, redistribution only in original form or if approved by author packages without sources Crippleware: crippled functionality, fully functional version must be purchased Demoware: time-bombed fully functional program Shareware: redistribution allowed, payment for use expected Promotional: free use for only some people or for some time only, or due to blatantly promotional reasons (like MSIE) Shyware: free use and redistribution of binaries, sources not available because author considers them still alpha. I don't think there are many more types. The precise terms should be available in the copyright file, but since most packages would fall in one of the previous categories, it would be really useful to have that shown in a concise way before installing a package. The Original-Site field could be optional, since it is not that necesary to know it in normal cases. Of course, it should always be mentioned in the README.debian file, as you propose. In summary, I think that at least the Author field should be added for ethical reasons and it would be convenient to add the License field. If you agree that this should be part of Debian policy then we should have the dpkg authors implement it. It has been proposed that all packages should include some information about where to get the upstream sources. Thus, I propose that we list all pieces of information we want to have included in the ``/usr/doc/*/README.debian'' files. If we have a consensus about this, we could include a ``good example'' for a ``/usr/doc/*/README.debian'' file. I propose that the following infos are listed in this file: - Name and email address of current Debian maintainer - specification about where to get the upstream sources - short description of all major changes to the program (for example, new command line options, changed locking mechanism, major bug fixes, etc.) - URL of ``official home page'' if there is one (optional) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: S: workaround for dpkg replaces bug
I ran into this exact problem some time ago with elvis. What I did was to create a bunch of zero byte files (think touch) and install them on top of the files from the old package. I then deleted the files in the post init script. This allowed dpkg to mark all files as removed from the old package, but marked a lot of non-existant files as part of the new package. I couldn't think of anything else that worked (except to conflict with all the old stuff). The right thing is to get dpkg fixed. I submitted a bug on this one a LONG time ago. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- the dpkg replace function works only for the first package listed. one of my package (isdnutils) replaces more than one package (vbox, isdnlog, xisdnutils). maybe someone has an idea how i can make sure, that these three packages are not installed ? (will something in preinst work ?). i have no idea what i can do, till this bug in dpkg is fixed... any help would be great. thanks, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: booting bzImage with chos
Chos is able to chain to a LILO boot block on a partition. It worked fine chaining to /dev/hdd, for example. So you can boot bzImage kernels that way until someone fixes chos. Nice program. I think it assumes that /boot is on the first drive, doesn't it? Thanks Bruce Yup. I tried to use a kernel on my second hard drive one, and it gave a error when I ran chos. As long as it is on the first hard drive, you should be fine. I don't know what it would take to snag some functionality from lilo and stick it into chos, but I guess since chos is now GPLed (YEA!!!) some of us should probably take a look. (sound of ftping source in background). -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
Also we might think about replacing lilo with chos as the standard boot loader from harddisk. lilo always is a difficulty for newbies, chos offers: - Menudriven Boot Loader (Cryptic Prompt only on demand) - Highly Customizable Color Menus. - Simple configuration in passwd style file /etc/chos.conf I fully agree, except for one thing... Last I looked, chos did not include any source code, and was in non-free. Has this changed? If it has, I completely agree, it should be the standard. It is VERY easy to use, and works VERY well. I like it. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Tri-Linux's discription
Do you know if they will be selling the Official 1.3.0 CD or the Official 1.3.1 CD with the new XFree86 3.3 release? -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Bug#4265: util-linux_2.5-5.deb: /sbin/clock Seg. faults
Package: util-linux Version: 2.5-5 /sbin/clock seg. faults. The following illustrates this problem: Dillweed# dpkg -i util-linux_2.5-5.deb (Reading database ... 15590 files and directories currently installed.) Preparing to replace util-linux (using util-linux_2.5-5.deb) ... Unpacking replacement util-linux ... Setting up util-linux (2.5-5) ... Dillweed# clock - Segmentation fault Dillweed# dpkg -i util-linux_2.5-4.deb dpkg - warning: downgrading util-linux from 2.5-5 to 2.5-4. (Reading database ... 15590 files and directories currently installed.) Preparing to replace util-linux (using util-linux_2.5-4.deb) ... Unpacking replacement util-linux ... Setting up util-linux (2.5-4) ... Dillweed# clock - Fri Aug 23 01:21:12 1996 Dillweed# I solved this by copying the binary from util-linux_2.5-4.deb over the binary from util-linux_2.5-5.deb, and everything was fine... I am using Debian 1.1, patched up to everything in the experimental distribution as of August 24, 1996, with kernel version 2.0.14 and libc.so.5.2.18 from libc5.5.2.18-10.deb. -- Erik B. Andersen Web: http://www.et.byu.edu/~andersee/ 2485 South State St. email: [EMAIL PROTECTED] Springville, Ut 84663phone: (801) 489-1231 --This message was written using 73% post-consumer electrons--
