Re: Potato now stable
Bas Zoetekouw [EMAIL PROTECTED] writes: I personally would like having hardware detection stuff in woody. Wouldn't it be great to have to install procedure ask you something like hi dude, I've detected that you've got a ne2000 NIC in your computer. Shall I load the appropriate module?? (and the same for video, sound, scsi, etc.) I noticed the other day that recent versions of RedHat use something called Kudzu (sp?) to do this. When I took out the network card, it warned me that some hardware was missing, and offered to change some things to compensate. Has anyone has looked into porting this to Debian?
Re: policy changes toward Non-Interactive installation
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey I read your entire message and could not find any examples Joey of things that debconf cannot handle correctly, except of Joey course for conffile change prompting, which it was never Joey designed to do. I think something needs to be done to address this issue. Yes, you can force dpkg to always use the old file, but then this will break applications which require the new file to be installed. -- Brian May [EMAIL PROTECTED]
Re: Intent To Split: netbase
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony ifconfig is a required file for /sbin according the the FHS Anthony section 3.10 as distributed in the debian-policy package. I think that some people are espousing non-compliance with the standards. Is that what we want to do? Steve OK, how about moving everything into /bin except what FHS Steve specifically says should be in /sbin? Section 3.10[0] Steve identifies the following specifically to be located in /sbin: Sounds like a cop out. We are acknowledging that we can no longer come to a consensus on this, and we are punting on this. Actually, it may be closer to saying we really don't like sbin, and we move everything out of there, except that we also want to be FHS compliant, and let just tose programs stay in. I think we should either a) categorize the programs, by extending the reasoning of the FHS, and I have not yet lost hope of our ability to reach a rough consensus, b) decide that the sbin idea is silly, and that's that (we can symlink /sbin to /bin) I think we may be truthfully accused of losing touch with the generic user out there. Most of the discusion here (and, I confess, my knee jerk reactions), have dealt with the issue with opinions on what works for us -- even though developers are rarely a decent sampling of the unwashed masses. My experience has been that most users, even most linux users, are not what the industry terms ``power users'' (most of these folks just call the sys admin when things go wrong). The defaults should be designed around them, not us, since power users shall always tweak the system defaults anyway. manoj stepping off the soap box -- A good teacher has been defined as one who makes himself progressively unnecessary. -- Thomas J. Carruthers Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: policy changes toward Non-Interactive installation
On Tue, Aug 15, 2000 at 08:26:50PM -0700, Joey Hess wrote: Anthony Towns wrote: Basically, I'd like to be able to insist that I'm *never* asked a question as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg just get on with installing everything else, although it probably won't at the moment) than get asked a question. That's do-able. Once debconf knows to run postinsts in full noninteractive mode, critical questions that are thus not asked at all, and which do not have their return code caught, will simply cause the postinst to terminate with a nonzero return code. (I think this is better than making _all_ questions terminate it, which is not doable anyway, and also because if a postinst asks a priority low question, say, then that is by definition a question that the noninteractive mode can supply a reasonable answer to.) Well, no, that's not what I want either: I like seeing every question that the postinst thinks I might need to know about. I just want to see them in blocks, preferably beforehand, but at the end if that's the way it has to be. I don't think we've got any examples of non-critical questions that need to be outside the .config though, do we? Something bad happened, and You need to stick a floppy in don't strike me as things that should just be ignored. I'll be happy to implement a debconf/non-interactive-foo (should apply to all maintainer scripts save config, not just postinst, so I need a better name), if people think it will be generally useful. non-interactive-install, perhaps? -maintainer-scripts? However, I presonally feel your specific case of the floppy prompting would be better served by: a) Making the question of low priority. or b) Making the question be asked only once, and this value used by all future kernel packges you install. Or adding a question, do you ever want to make a boot floppy? Especially b. I'm curious about your opinion of an option (c): make a separate mk-boot-floppy script that can be run outside of the postinst after the install. This is the same as what Manoj suggested for realplayer. A bad thing is that, alone, it's not really automatic, you could install the kernel and forget to make a boot-floppy, or you could install realplayer and forget to do what's necessary to actually, well, install realplayer. I think it's more `user-friendly' in general though: realplayer can be annoying the way it is at the moment, and I might change my mind and what a boot floppy later. Ways of getting around the `not really automatic' problem might be: * ask a question in the .config whether you want the program to be run in postinst * always run the programs after dpkg's finished, like update-menus * send a reminder email to root Note that this means the program probably can't really use debconf to do its stuff if it's separate, ie, we'd suddenly be back to boring text prompts and such. Or maybe it's reasonable for some non-maintainer-scripts to use debconf, I suspect it's actually possible at the moment. Having it as a separate program run after dpkg has finished would let you have non-interactive maintainer scripts for all the examples I've seen, I think. Yes, I realise this won't be implemented by the end of the week. :) Oh. Actually... I imagine that if we ever get post-dpkg-run hooks, they'll be invoked something like: run-after-dpkg /usr/bin/update-menus and be run through sort | uniq or something before being called. It might be possible to just implement run-after-dpkg to just run immediately for the moment. Or to re-enable interactive-postinsts, run it, and disable it. Ripping out the logic from update-menus and implementing it as run-after-dpkg could probably work pretty easily too, but wouldn't leave us with anywhere for stdio to happen, afaict [0]. Cheers, aj [0] Although a Unix domain socket could help here ;) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgp4P3wsStd8j.pgp Description: PGP signature
Re: policy changes toward Non-Interactive installation
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony To clarify a little: I want to be able to answer the Anthony questions up front, do the install and have it work. If I've This is not somethign anyone can argue with. Anthony made a mistake (like not put a file where I said I did Anthony maybe), I don't mind if it dies and leaves that package to Anthony be configured later or something. I don't want it to pause Anthony and leave the rest of the system unconfigured, though. This is your system, and you should be able to set the defaults that way (/etc/kernel-img.conf -- set do_symlink=NO clobber_modules=YES, do_boot_enable=NO), and you shall never be asked anything by the postinst. Of course, you are then responsible for ensuring your new kernel is booted, but hey, you can't have everything. But other people may have other choices, and I'll fight tooth and nail against any policy changes that leave them out in the cold just cause some people like non-interactive installs. Anthony This is just for my system, I don't really care that much how it works Anthony for other people. Hmm. Not an attitude I can afford to take, I don't think, as package maintainer ;-) Anthony If we go through the `N' questions above, we have: .XXXN6) failure, retry? .XXXN7) failure, you have formatted floppy? .XXXN9) Failure writing floppy, retry? .XXXN 10) failure, hit return when youhave new floppy .XXXN 16) Failure writing mbr, do this manually, hit return Anthony ...failure cases, which I want to address as late as possible, rather Anthony than as soon as possible. (The realplayer question is mainly a failure Anthony question too, iirc) Pardon me, I think I don't understand. So, writing the floppy failed, and you want me to just stop doing what I was doing, leaving you with an unbootable system? I am not happy with not offering the user a chance to change the floppy, or quit formatting and going woth a preformatted floppy, or going to lilo instead. If you arrive at these questions, you have asked stuff to be done, and I can't really defer the failure case handling. Sure, I can say that if you asked things to be done, and ignore error recovery, you are responsible for the consequences, but unless that point is driven home, the reputation for rock solid installs may suffer. However, I have no objection in principle to allowing people the *option* of silent installs. My objection is to making silent install the *only* option. .XXXN5) Insert floppy, hit return .XX.?4) do I need to format the floppy? .XXXN8) you have floppy, hit return when ready Anthony ...questions needing a temporary change in hardware. I'd answer no, Anthony I don't want to have a floppy initially, or perhaps want to run Anthony /usr/lib/kernel-2.2.17/make-floppy or something after my install's Anthony completed. Yup. But these questions will still be asked for people who have not set these defaults, and these ned be asked at run time. .XX.N 14) Install boot block on partition detected at runtime Anthony You can detect stuff at runtime from within the .config too; Anthony you should be able to this before the package is actually Anthony installed. At worst, you can say no, don't try to detect it Anthony and annoy me later: this is what it should be. okay? trust Anthony me Easy. Just set up an /etc/lilo.conf (SILO,MILO whatever) and this questioh shan't be asked. But there are people who have not yet done it, and this section is for them. N 15) Install mbr root disk .XX.N 17) make that partition active? Anthony And hence you should be able to ask these beforehand too, I think. Same here. Anthony Basically, I'd like to be able to insist that I'm *never* Anthony asked a question as part of a postinst. I'd rather the Anthony postinst fail (and I'd rather Apt/Dpkg just get on with Anthony installing everything else, although it probably won't at Anthony the moment) than get asked a question. I wuld not object to having such a mode if explicitly asked for. But I refuse to support what happens if you do so. As long as turning this option on is an admittance of responsibility for install failures and their consequences, fine. Anthony would be tidier. For the moment, though, as long as I *can* Anthony say no, I don't want a floppy made and end up with a Anthony non-interactive postinst, I'm happy. I would be happy to work towards this, as long as there is no attempt to outlaw any installation phase interaction. And as long as it is understood that people who ask for a non-interactive install willy-nilly do it at their own risk. manoj -- panic: kernel trap (ignored) Manoj Srivastava [EMAIL
Re: How many CDs in potato?
On Tue, Aug 15, 2000 at 04:58:19PM -0400, Buddha Buck [EMAIL PROTECTED] spake forth: Why would a package be in contrib if it didn't depend on non-free? I thought that that was the current definition of contrib: DFSG-free, but requires something from outside of main (e.g., contrib or non-free). A dependency on non-us will also land a package in contrib. -- Mike Markley [EMAIL PROTECTED] PGP: 0xA9592D4D 62 A7 11 E2 23 AD 4F 57 27 05 1A 76 56 92 D5 F6 GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 The only solution is ... a balance of power. We arm our side with exactly that much more. A balance of power -- the trickiest, most difficult, dirtiest game of them all. But the only one that preserves both sides. - Kirk, A Private Little War, stardate 4211.8
Re: ITP: Moscow ML - An implementation of standard ML.
Don't do that. Moscow ML was my first package when I joined and I had to learn that there are license problems. To be precise it is based on Caml Light which is not GPLed (read: has further restrictions) therefore you can't link GPL-code against it. We can't distribute binaries of that :(( Have you contacted the authors? I don't quite remember. I think I contacted inria (they hold the Caml copyright) about changing that but to no extent. I am not sure if changing the MoSML license would help - at least it has to go to non-free then. I did not want to maintain a non-free package at that time so I gave up on it. The MosML could add to the license: As an exception to the GNU GPL, you may distribute this software linked to CAML.
compaq iPaq
[ Please reply to debian-arm and me (I'm not on that list). Posted to -devel to pick up any interested people who arn't on -arm. ] For those who don't know, the iPaq is a ARM-based pocket computer near the size of a palm pilot, that runs linux[1], including X. It has 32 MB of ram, and 16 MB of flash memory. I've seen several of them at LinuxWorld, and they look like really sweet little boxes. I was thinking about buying one, and started thinking about what I'd do with it (mostly reading email to keep up with the ever expanding demands of Debian Weekly News), and got to thinking about distributions. I don't think I could use another distribution (right now, it's something they put together custom), on a computer, even if it's just a handheld. I NEED Debian. On the other hand, fitting a full debian install on 16 MB of flash is daunting[2]. If this were done, it might make more sense to provide some way for dpkg to install files onto the iPaq, without storing all the cruft like /var/lib/dpkg/* there, and keep that on a desktop box instead. I also have a lot of other committements in Debian, and not a lot of time to work on something like this. So I'm just posting a feeler, to see if anyone else has thought about this, or is interested. -- see shy jo [1] http://www.handhelds.org/Compaq/ [2] [EMAIL PROTECTED]:/var/lib/dpkg/infodu 14M . -- Ok, this is a little unrelaistic, but you get the idea. It eats about 2 mb on a much more minimal install.
Re: kernel-image with the same version
Hi, Atsuhito == Atsuhito Kohda [EMAIL PROTECTED] writes: Atsuhito I installed recently potato from scratch. Rescue disk installed Atsuhito kernel 2.2.17 and I rebuild kernel-image with kerne-source 2.2.17 Atsuhito so the version of kernel was same for both. Umm. This should not happen. Since /lib/modules/2.2.17 shall be clobbered with the new modules. If the modules were the same, you should have been warned on install. Atsuhito When I installed kernel-image-2.2.17*.deb which I rebuild Atsuhito then /vmlinuz and /vmlinuz.old were created but both Atsuhito pointed to the same /boot/vmlinuz-2.2.17. This means no Atsuhito back-up of old kernel was retained. If the modules were actually clobbered, you may not have a bootable old image left. Indeed, you shall not, since there is only one /boot/vmlinuz-2.2.17 Atsuhito In my case, new kernel seemed to work fine so there was no problem, Atsuhito I guessed, but this might cause problems. Atsuhito Is this inevitable or I am missing something? I think something is missing. If you replace a kernel with the same version, you end up with one /boot/vmlinuz-$VERSION, and one /lib/modules/$VERSION. You can move the /boot/vmlinuz-* around, but the kernel shall still look in the same old place for its modules. manoj -- Sendmail can safely be made setuid to root. Eric Allman, Sendmail Install Operation Guide Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: compaq iPaq
It's been pointed out that emdebian (http://www.emdebian.org/) is essentilly an effort to do just this. -- see shy jo
Re: compaq iPaq
On Tue, 15 Aug 2000, Joey Hess wrote: It's been pointed out that emdebian (http://www.emdebian.org/) is essentilly an effort to do just this. It is? I use their stuff and the main focus is cross compilers and cross environments for debian, not really shrinking and porting debian proper. That it is, it is more tools for embedded development rather than an embedded operating system. Jason
Re: Intent To Split: netbase
I proposed using symlinks for programs in */sbin to enable normal users to see them in their default path, but now I think this is a bit messy. (For instance, /sbin/ifconfig - /bin/ifconfig, lots of these would be ad hoc) For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. That way, filesystem standard compliance is not disturbed, and the users have those programs in their path by default. Thanks, __ Eray Ozkural
Re: compaq iPaq
Jason Gunthorpe wrote: It is? I use their stuff and the main focus is cross compilers and cross environments for debian, not really shrinking and porting debian proper. Well right now that's true, but it does seem to have grand goals of shrinking Debian to a few MB and so on. -- see shy jo
Re: debian at work, how to make packages
On 13 Aug 2000 at 18:20 (+0200), Allan Jacobsen wrote: | Hi | | I have been using debian for more than 4 years now and I have | finaly talked my boss into trying debian instead of redhat | for our servers, that we install in hotels all over europe. | I have been reading most of the dokumentation on making .deb | pakages, but most of it is how to package foreign source that | anyone should be able to recompile. | Our buildtree is totally incompatible with this, so I have been | looking for a few simple scripts to package the bin and conf | files to make a usable deb package. | I read somewhere that I could unpack a deb my using | ar x package.deb, and the format looks reasonably simple | with the 3 files, where data.tar.gz should be untared in / | and the control files and scripts are in control.tar.gz | Does any of you have some suggestions ? take a look at: http://www.debian.org/doc/maint-guide/ I can't comment on its suitability to a newbie-packager, because I'm just now reading it too, but it looks like a fairly low-overhead tutorial from a cursory glance. hth. brent -- Damon Brent Vernero _ _ _ Cracker Jack® Surprise Certified _o /\_ _ \\o (_)\__/o (_) [EMAIL PROTECTED]_ \_ _(_) (_)/_\_| \ _|/' \/ [EMAIL PROTECTED] (_)(_) (_)(_) (_)(_)' _\o_
Re: Potato now stable
Thus spake Colin Walters ([EMAIL PROTECTED]): I noticed the other day that recent versions of RedHat use something called Kudzu (sp?) to do this. When I took out the network card, it warned me that some hardware was missing, and offered to change some things to compensate. Has anyone has looked into porting this to Debian? Currently, in Debian it is being used by sndconfig. It was written specifically for Redhat though and does some things (like editing /etc/conf.modules, linking devices in /dev/) which are probably not desirable in Debian. The detection part can probably be used, though. Mandrake, too, includes a hardware detection libarary (libdetect). Some time ago, Dan Helfman [EMAIL PROTECTED] (Cc'ed him), was busy packaging it. Dan, have you had any luck yet adapting it to Debian? When a hardware detection library is available, I think I'm going to rewrite sndconfig specifically for Debian instead of editing the Redhat package. Maybe a more general program, which can detect and configure various kinds of hardware, should be created though. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| | [EMAIL PROTECTED] | Pablo Picasso | +---+ pgpeTr3UwO5cT.pgp Description: PGP signature
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 05:07:25PM -0400, Decklin Foster wrote: Steve Bowman writes: OK, how about moving everything into /bin except what FHS specifically says should be in /sbin? snip list from FHS 3.10 I very much like this idea. Does anyone have objections? I don't object. I still think a few of those tools could profitably be placed in (/usr)?/bin, but this is at least another step closer to the elimination of a useless artifact of the old days. -- G. Branden Robinson | Debian GNU/Linux| Never attribute to malice that which can [EMAIL PROTECTED] | be adequately explained by stupidity. http://www.debian.org/~branden/ | pgpxXbDoKJWY4.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 07:32:32AM +1000, Herbert Xu wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote: But I thought one of the main complaints was that /usr/sbin wasn't in the PATH. Generally, maintainer scripts, and programs meant to be run by root, run as root. If a program expects to use some tool that only root would use, it should expect to be running as root. So you do agree with me that it is better to leave traceroute in /usr/sbin? Uh, no. My remarks above in fact strong imply the opposite conclusion. (However, I don't think traceroute is the strongest candidate for a program that gets run from inside a script.) -- G. Branden Robinson |Communism is just one step on the long Debian GNU/Linux|road from capitalism to capitalism. [EMAIL PROTECTED] |-- Russian saying http://www.debian.org/~branden/ | pgp4XPWzEfaJx.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 12:39:15PM +1000, Anthony Towns wrote: On Wed, Aug 16, 2000 at 01:12:58AM +0300, Eray Ozkural wrote: I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. ifconfig is a required file for /sbin according the the FHS section 3.10 as distributed in the debian-policy package. Well, keep in mind that Debian has committed itself to FHS-compatibility, not FHS-compliance. This means that we are free to have symlinks standing between a pathname and the inode. -- G. Branden Robinson | Debian GNU/Linux| Music is the brandy of the damned. [EMAIL PROTECTED] | -- George Bernard Shaw http://www.debian.org/~branden/ | pgpxK72VpIVS1.pgp Description: PGP signature
Re: Intent To Split: netbase
[Followups to debian-policy, please] On Tue, Aug 15, 2000 at 11:22:11PM -0500, Manoj Srivastava wrote: I think that some people are espousing non-compliance with the standards. Is that what we want to do? The FHS exhaustively explains the difference between compatibility and compliance. I note that the Debian policy manual says that all installed files and directories must comply with the FHS, rather than must be compatible with the FHS. Let this message serve as policy proposal that we change the wording of section 3.1.1 from must comply to must be compatible. This change needs to be made irrespective of any consensus (or lack thereof) on the issue moving binaries from (/usr)?/sbin to (/usr)?/bin, because we continue to carry around relics of non-FHS-compliance (such as /var/state) that may take quite some time to dislodge. (Witness the /usr/share/doc migration.) Furthermore, the footnote following the URL of the FHS should probably be deleted, since FHS 2.1 is no longer in draft status. Steve OK, how about moving everything into /bin except what FHS Steve specifically says should be in /sbin? Section 3.10[0] Steve identifies the following specifically to be located in /sbin: Sounds like a cop out. We are acknowledging that we can no longer come to a consensus on this, and we are punting on this. Actually, it may be closer to saying we really don't like sbin, and we move everything out of there, except that we also want to be FHS compliant, and let just tose programs stay in. I can agree with either interpretation, though I disagree with your characterization of the former as a cop out. The traceroute argument comes up over and over again. The defenders of the status quo have no defense for the inconsistency between having one traceroute tool in sbin and a different one in bin. Rather than having one of the programs move, they just tell people to change their $PATH. This does not indicate to me the slightest motivation to extend the reasoning of the FHS. The FHS team has given themselves a mandate to sort these issues out. Let them. Why should we argue about whether a certain binary goes in one directory or the other when it's a much bigger part of their mission statement to make that decision than ours? FHS is an open standards group, more to the point, so Debian developers who feel passionately about such things can join it and carry on their flamewars there. I think we should either a) categorize the programs, by extending the reasoning of the FHS, and I have not yet lost hope of our ability to reach a rough consensus, I think it's the FHS's job to delimit its own reasoning. There are places where it defers to vendors. b) decide that the sbin idea is silly, and that's that (we can symlink /sbin to /bin) Well, that's my personal feeling, but I don't think one needs to feel this way to know that the appropriate place for traceroute is not sbin. I think we may be truthfully accused of losing touch with the generic user out there. I think the generic user neither knows nor cares about the distinction between bin and sbin. There's also no reason to fence him off from harmless and even useful commands. Quoting the FHS: Deciding what things go into sbin directories is simple: If a normal (not a system administrator) user will ever run it directly, then it should be placed in one of the bin directories. Ordinary users should not have to place any of the sbin directories in their path. Note: For example, files such as chfn which users only occasionally use should still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and should live in /bin for that reason. -- G. Branden Robinson |Software engineering: that part of Debian GNU/Linux|computer science which is too difficult [EMAIL PROTECTED] |for the computer scientist. http://www.debian.org/~branden/ | pgpjfu0lVrcA4.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 09:23:11AM +0300, Eray Ozkural wrote: For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. I think if someone has to do such a thing, then: a) they forgot to su root; or b) they don't know they need privleges to use the command in question; or c) the command doesn't belong in sbin anyway. -- G. Branden Robinson | When dogma enters the brain, all Debian GNU/Linux| intellectual activity ceases. [EMAIL PROTECTED] | -- Robert Anton Wilson http://www.debian.org/~branden/ | pgpZM7E8ILttb.pgp Description: PGP signature
Re: kernel-image with the same version
From: Manoj Srivastava [EMAIL PROTECTED] Subject: Re: kernel-image with the same version Date: 16 Aug 2000 00:31:48 -0500 Atsuhito I installed recently potato from scratch. Rescue disk installed Atsuhito kernel 2.2.17 and I rebuild kernel-image with kerne-source 2.2.17 Atsuhito so the version of kernel was same for both. Umm. This should not happen. Since /lib/modules/2.2.17 shall be clobbered with the new modules. If the modules were the same, you should have been warned on install. Yes, of course I moved /lib/modules/2.2.17 to 2.2.17-old before I installed kernel-image-2.2.17*.deb so there was no warning on installation. Atsuhito When I installed kernel-image-2.2.17*.deb which I rebuild Atsuhito then /vmlinuz and /vmlinuz.old were created but both Atsuhito pointed to the same /boot/vmlinuz-2.2.17. This means no Atsuhito back-up of old kernel was retained. If the modules were actually clobbered, you may not have a bootable old image left. Indeed, you shall not, since there is only one /boot/vmlinuz-2.2.17 As I expalined above, the modules were not clobbered, but there was only one /boot/vmlinuz-2.2.17 and both /vmlinuz and /vmlunuz.old were linked to this /boot/vmlinuz-2.2.17. I wanted to ask how to avoid this problem... I think something is missing. If you replace a kernel with the same version, you end up with one /boot/vmlinuz-$VERSION, and one /lib/modules/$VERSION. You can move the /boot/vmlinuz-* around, but the kernel shall still look in the same old place for its modules. Yes it might be so. But if one install with the current rescue disk of potato then the kernel installed is of 2.2.17 and the provided kernel-source of the latest version is of 2.2.17 so if one wants to rebuild the kernel (and generally one wants to!) then one encounters the same situation, at least for a while. Best Regards, 2000.8.16 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: How many CDs in potato?
On Tue, Aug 15, 2000 at 04:58:19PM -0400, Buddha Buck wrote: Why would a package be in contrib if it didn't depend on non-free? I thought that that was the current definition of contrib: DFSG-free, but requires something from outside of main (e.g., contrib or non-free). It could depend on a non-free thing that isn't packaged at all. See, for instance, xtrs. -- G. Branden Robinson |The greatest productive force is human Debian GNU/Linux|selfishness. [EMAIL PROTECTED] |-- Robert Heinlein http://www.debian.org/~branden/ | pgp7KlOz9xXPV.pgp Description: PGP signature
Re: kernel-image with the same version
From: Ben Collins [EMAIL PROTECTED] Subject: Re: kernel-image with the same version Date: Tue, 15 Aug 2000 18:54:29 -0400 Edit /etc/kernel-img.conf and add this line: reverse_symlink := yes Okay I will try later. BTW, /etc/kernel-img.conf might be /etc/kernel-pkg.conf Thanks for your kind advice. Best Regards, 2000.8.16 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: Intel Assembly error
On Tue, Aug 15, 2000 at 04:44:37PM -0700, Richard Hecker wrote:
I ran into a compiler error that I do not recognize. Instead of
spinning my wheels further with this, I was hoping someone familiar
with Intel assembly language on this list could shed some light on
what is happening here. As can be seen from the comments, it is
an ancient line that was lifted from the kernel. For this reason
I am including the output from gcc -v.
gcc -o 6x86_reg 6x86_reg.c
6x86_reg.c: In function `delay':
6x86_reg.c:86: Invalid `asm' statement:
6x86_reg.c:86: fixed or forbidden register 0 (ax) was spilled for class
AREG.
--- routine in the C source file ---
/* the original bogomips code from the Linux kernel */
static __inline__ void delay(int loops)
{
__asm__(.align 2,0x90\n1:\tdecl %0\n\tjns 1b: :a (loops):ax);
}
I am not an assembly guru on any architecture, but here's what I think this
means. Please be warned that these could be the ravings of a deranged
lunatic.
The AX register is an old 16-bit register from 8086 days. When you're
running in 32-bit mode, as all Linux systems do, the register should be
accessed by its 32-bit name, EAX.
I think at some point gcc (or gas) used to automatically convert such
misreferences. There's a whole slew of register names on the IA32 from the
old 16-bit days that have a 32-bit version with the E prepended.
(I think, in some contexts, you can actually use the 16-bit register names
to fetch the low-order 16 bits out of the actual 32-bit register.)
Hopefully someone who has actual knowledge will be able to answer your
question. Maybe Randolph Chung, who works for Intel? :)
--
G. Branden Robinson |A committee is a life form with six or
Debian GNU/Linux|more legs and no brain.
[EMAIL PROTECTED] |-- Robert Heinlein
http://www.debian.org/~branden/ |
pgpSuAivy5wCg.pgp
Description: PGP signature
Re: How many CDs in potato?
On Tue, 15 Aug 2000, Mike Markley wrote: On Tue, Aug 15, 2000 at 04:58:19PM -0400, Buddha Buck [EMAIL PROTECTED] spake forth: Why would a package be in contrib if it didn't depend on non-free? I thought that that was the current definition of contrib: DFSG-free, but requires something from outside of main (e.g., contrib or non-free). A dependency on non-us will also land a package in contrib. I think there was a proposal to change that, so that packages which depend on packages in non-US/main remain in non-US/main.
Re: Intel Assembly error
On Wed 16 Aug 2000, Branden Robinson wrote: I am not an assembly guru on any architecture, but here's what I think this means. Please be warned that these could be the ravings of a deranged lunatic. Ditto. The AX register is an old 16-bit register from 8086 days. When you're running in 32-bit mode, as all Linux systems do, the register should be accessed by its 32-bit name, EAX. Actually, I believe they are separate entities. I think at some point gcc (or gas) used to automatically convert such misreferences. There's a whole slew of register names on the IA32 from the old 16-bit days that have a 32-bit version with the E prepended. (I think, in some contexts, you can actually use the 16-bit register names to fetch the low-order 16 bits out of the actual 32-bit register.) No, you have AH to access the high 16 bits of EAX, and AL for the low 16 bits of EAX. Or was that the high 8 bits of AX etc... Apart from that, using assembler is evil (if there isn't a C language alternative) because then your source will never run on anything besides the processor the assembler code is written for. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
ITP: freeswan
I intent to package freeswan (currently version 1.5) and have already taken the freeswan 1.3 package from Tommi Virtanen and the freeswan 1.5 package from Aaron Johnson. I will merge those with my own package and hope to get something that can be uploaded into woody in the next 2 weeks. Since I live in Austria, uploading to non-US should be no problem and will be accepted by the freeswan project members (they do not accept any contribution from people living in the US). Please CC me in replies, I am currently not subsribed to debian-devel. best greets, Rene
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
Quoting the FHS:
Deciding what things go into sbin directories is simple: If a normal
(not a system administrator) user will ever run it directly, then it
should be placed in one of the bin directories. Ordinary users should
not have to place any of the sbin directories in their path.
Note: For example, files such as chfn which users only occasionally use
should still be placed in /usr/bin. ping, although it is absolutely
necessary for root (network recovery and diagnosis) is often used by
users and should live in /bin for that reason.
Well, the FHS is contradicting itself here. On one hand, it says that
ifconfig is required to be in /sbin, on the other, according to this
paragraph, since a user could ocassionally wish to run ifconfig to list
the interfaces, it has to be in /bin. Someone should bring this up on
the FHS list.
Blindly following a contradictory standard is only going to get us into
trouble later on.
Just to rephrase my main reason for not moving traceroute, it's a tool that
is in the same category as ping/ifconfig/route, i.e., it's a network
diagnostic tool. On Linux, ping has traditionally been in /bin while the
other three have always lived in /sbin and /usr/sbin, respectively. Unless
there is a very good reason (for the convenience of users who should really
be changing their PATH variable is not good enough IMHO), we shouldn't move
these things around as LOCAL scripts may depend on them.
Now if a later version of the FHS unequivocally stated that all these tools
should be in /bin or /usr/bin, and as a project we decide to do that, then
we can carry out such a change in a way not dissimilar to how things were
moved around when the FSSTND first came about.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: compaq iPaq
On Wed 16 Aug, Jason Gunthorpe wrote: On Tue, 15 Aug 2000, Joey Hess wrote: It's been pointed out that emdebian (http://www.emdebian.org/) is essentilly an effort to do just this. [shrink debian to fit handhelds] It is? I use their stuff and the main focus is cross compilers and cross environments for debian, not really shrinking and porting debian proper. That it is, it is more tools for embedded development rather than an embedded operating system. We (emdebian) want to do both these things. The latter is what is urgent right now for developers of 'funky handhelds', but the former is also needed for those handhelds to be of much use beyond specific vertical applications. http://www.handhelds.org/ (the compaq research lab, who did the port to the ipaq) is encouraging development of small-platform linux software. Emdebian intends to use the resulting good stuff to produce a proper small-device distro. The needs of genuinely embedded devices and general-purpose handheld computers are not quite the same, but the restrictions are similar so we hope that a distro can be produced that covers both these areas. It's an interesting area. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Re: Intel Assembly error
Branden Robinson [EMAIL PROTECTED] wrote:
/* the original bogomips code from the Linux kernel */
static __inline__ void delay(int loops)
{
__asm__(.align 2,0x90\n1:\tdecl %0\n\tjns 1b: :a (loops):ax);
}
You can either read the GCC FAQ or the GCC info on the details of this
problem.
But in order to add some signal to this message, the above line should be
rewritten as
int bradon;
__asm__(.align 2,0x90\n1:\tdecl %0\n\tjns 1b
: =a (=brandon): 0 (loops));
I am not an assembly guru on any architecture, but here's what I think this
means. Please be warned that these could be the ravings of a deranged
lunatic.
Which they are, as usual.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intel Assembly error
Herbert Xu [EMAIL PROTECTED] wrote:
int bradon;
__asm__(.align 2,0x90\n1:\tdecl %0\n\tjns 1b
: =a (=brandon): 0 (loops));
Make that
int brandon;
__asm__ __volatile__(.align 2,0x90\n1:\tdecl %0\n\tjns 1b
: =a (brandon): 0 (loops));
Oh, and you should probably upgrade your kernel as this is ancient.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PROPOSED 2000/08/16] Free pkgs depending on non-US should go into non-US/{main,contrib}
Package: debian-policy Severity: wishlist On Wed, Aug 16, 2000 at 10:25:28AM +0200, Santiago Vila wrote: On Tue, 15 Aug 2000, Mike Markley wrote: A dependency on non-us will also land a package in contrib. I think there was a proposal to change that, so that packages which depend on packages in non-US/main remain in non-US/main. Actually, there doesn't seem to be such a proposal; there just seems to be your (accepted) proposal to make both main and non-US/main part of the Debian distribution. So, let's fix that. The principle: packages that are DFSG-free, depend on packages in non-US/main, but are otherwise candidates for main should go into non-US/main also. That way they're still a part of the official distribution, but they don't come up as uninstallables for the poor deprived US folks. Here's a sample wording change. It incorporates the accepted change from #62946. It's not entirely clear where contrib packages that don't include crypto, but Depend: on software that does (from non-US/*) would go in the following, probably. --- policy.text.origWed Aug 16 19:29:04 2000 +++ policy.text Wed Aug 16 20:00:31 2000 @@ -196,9 +196,11 @@ but not every package we want to make accessible is _free_ in our sense (see Debian Free Software Guidelines, below), or may be imported/exported without restrictions. Thus, the archive is split - into the sections _main_, _non-us_, _non-free_, and _contrib_. + into the sections _main_, _non-US/main_, _contrib_, _non-US/contrib_, + _non-free_, and _non-US/non-free_. - The _main_ section forms the _Debian GNU/Linux distribution_. + The _main_ and _non-US/main_ sections form the _Debian GNU/Linux + distribution_. Packages in the other sections are not considered as part of the Debian distribution, though we support their use, and we provide @@ -282,46 +284,54 @@ The ``GPL,'' ``BSD,'' and ``Artistic'' licenses are examples of licenses that we consider _free_. -2.1.2. The main section +2.1.2. The main and non-US/main sections + - Every package in main must comply with the DFSG (Debian Free - Software Guidelines). + Every package in main and non-US/main must comply with the DFSG + (Debian Free Software Guidelines). In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package may not declare a Depends or - Recommends relationship on a non-main package), + Recommends, or Build-Depends relationship on a non-main + package), * must not be so buggy that we refuse to support them, * must meet all policy requirements presented in this manual. + + Similarly, the packages in non-US/main +* must not require a package outside of main or non-US/main + for compilation or execution, +* must not be so buggy that we refuse to support them, +* must meet all policy requirements presented in this manual. -2.1.3. The contrib section --- +2.1.3. The contrib and non-US/contrib sections +-- - Every package in contrib must comply with the DFSG. + Every package in contrib and non-US/contrib must comply with + the DFSG. - Examples of packages which would be included in contrib are -* free packages which require contrib, non-free, or non-US + Examples of packages which would be included in contrib or + non-US/contrib are +* free packages which require contrib or non-free packages or packages which are not in our archive at all for compilation or execution, * wrapper packages or other sorts of free accessories for non-free programs, -2.1.4. The non-free section +2.1.4. The non-free and non-US/non-free sections + - `Non-free' contains packages which are not compliant with the DFSG or - which are encumbered by patents or other legal issues that make their - distribution problematic. + Packages must be placed in non-free or non-US/non-free if they + are not compliant with the DFSG or are encumbered by patents or + other legal issues that make their distribution problematic. - All packages in `non-free' must be electronically distributable across - international borders. - -2.1.5. The non-us server - +2.1.5. The non-US sections +-- Some programs with cryptographic program code must be stored on the - non-us server because of export restrictions of the U.S. + non-US server because of export restrictions of the U.S. Such + programs must be distributed in the appropriate non-US section, + either non-US/main, non-US/contrib
Re: Intent To Split: netbase
FHS discuss people: where should traceroute go? Tradition dictates /usr/sbin, the FHS seems to indicate /usr/bin would be more appropriate. On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Blindly following a contradictory standard is only going to get us into trouble later on. Just to rephrase my main reason for not moving traceroute, it's a tool that is in the same category as ping/ifconfig/route, i.e., it's a network diagnostic tool. `ifconfig' and `ping' aren't really in the same category, though. ifconfig (like route, mount, and like modprobe or lsmod) acts on local hardware, whereas ping (like traceroute, and arguably telnet or nc) is commonly used as a tool to investigate distant sites. Toying with local stuff is the system administrator's playground, by definition, but investigating remote hosts is a reasonable thing to expect both admins and users to do. This seems to me to match at least the spirit of the FHS's definition of sbin: ] Deciding what things go into sbin directories is simple: If a normal ] (not a system administrator) user will ever run it directly, then it ] should be placed in one of the bin directories. Ordinary users should ] not have to place any of the sbin directories in their path. This definition is really quite poor if you put too much emphasis on the ever. swapon, for example, is clearly a tool for the admin, but a user might decide one day to run it just see which version of the program is installed on the system. mount, and ifconfig are less extreme versions of the same thing: a normal user can't use it to actually *do* anything, just to find out something about the way the system's setup, which is something of an admin task. ping and traceroute, by contrast are almost completely as useful for a normal user as root. On Linux, ping has traditionally been in /bin while the other three have always lived in /sbin and /usr/sbin, respectively. This is probably enough reason for the FHS to explicitly state where traceroute should go, since /usr/sbin seems in conflict with the earlier definition of sbin. Unless there is a very good reason (for the convenience of users who should really be changing their PATH variable is not good enough IMHO), we shouldn't move these things around as LOCAL scripts may depend on them. Similarly for /var/mail, /usr/lib/sendmail, /usr/doc, and so on, albeit perhaps to a lesser extent. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpLlDTenK12w.pgp Description: PGP signature
Embedded Debian (was: compaq iPaq)
Wookey [mailto:[EMAIL PROTECTED] wrote: On Wed 16 Aug, Jason Gunthorpe wrote: On Tue, 15 Aug 2000, Joey Hess wrote: It's been pointed out that emdebian (http://www.emdebian.org/) is essentilly an effort to do just this. [shrink debian to fit handhelds] It is? I use their stuff and the main focus is cross compilers and cross environments for debian, not really shrinking and porting debian proper. That it is, it is more tools for embedded development rather than an embedded operating system. We (emdebian) want to do both these things. The latter is what is urgent right now for developers of 'funky handhelds', but the former is also needed for those handhelds to be of much use beyond specific vertical applications. http://www.handhelds.org/ (the compaq research lab, who did the port to the ipaq) is encouraging development of small-platform linux software. Emdebian intends to use the resulting good stuff to produce a proper small-device distro. The needs of genuinely embedded devices and general-purpose handheld computers are not quite the same, but the restrictions are similar so we hope that a distro can be produced that covers both these areas. It's an interesting area. Emdebian *has* been focussed on cross tools so far, but that's about to change. Right now, I'm working on the 'shrinking Debian' problem, and I think I've come up with an interesting solution. I'll be making an initial release within the next week or so, but until then I'll give you a short rundown. The problem can be split into two subproblems: 1. Specification of the system (i.e. binaries, libs, utilities to include, network configuration, username/password configuration, etc...) 2. Generation of the system. 1. Specification The kernel has a specification (configuration) tool. Why not use the same tool to specify the operating system? One advantage of this approach is that you can build an operating system tightly coupled to the kernel. For example, if you've built a kernel without modules support, then you shouldn't offer the user the chance to include module utilities in the operating system that goes with it. If you haven't enabled SCSI, then why should you have /dev/sd* etc. on your filesystem. Etc, Etc. The following screenshots are a prototype of what I mean. I'm basing the work I'm doing on CML2, Eric Raymond's next generation kernel configuration system (see http://www.tuxedo.org/~esr/kbuild). Please keep in mind that the following menus have been slapped together with very little thought in order to build a prototype: === Network Configuration (netcfg) User Configuration (usrcfg) Editors(editors) Shells (shells) BSD Utilities (bsdutils) Debian Utilities (debianutils) Diff Utilities(diff) EXT2 Filesystem Programs (e2fsprogs) Floppy Disk Utilities (fdutils) File Utilities (fileutils) Find Utilities (findutils) Grep (grep) GNU Zip Utilities (gzip) Login Utilities (login) Kernel Module Utilities (module) Mount Utilities (mount) Network Utilities (netbase) Password Utilities (passwd) /proc Utilities (procps) Shell Utilities (shellutils) Debugging Utilities (sysdebug) System V Init (sysvinit) TCP Wrappers (tcpd) === === Network Configuration 192.168. Host IP Address (OS_HOST_IP) emdebian Host Name (OS_HOST_NAME) 255.255. Netmask (e.g. 255.255.255.0) (OS_NETMASK) nowhere. Host
Re: Embedded Debian (was: compaq iPaq)
2. Generation - I can imagine many different ways of building the operating system image. The one I'll be working on initially is a Snarf 'n' Pick implementation. Basically it will work by snarfing Debian packages and picking subsets of files from the packages. To my understanding, boot-floppies works in a similar way to create rescue disks. Thoughts? Frank, I think the OS-builder app is a great idea. Would its raw material be pre-compiled debian binary packages or would it be able to build the system from source. Unless there were separate embedded .debs, I don't know that the standard binaries would be compact enough to support limited memory/storage environments. Take busybox. Based on the build instructions, the app would modify busybox.def.h and build the binary to contain only the commands/features that were necessary. In many cases, the standard .debs would probably be fine, but in some cases you would need more control over the build. An added benefit would be if the OS-builder were modular and extensible enough to not only configure which packages are to used but to configure the packages themselves. Lets say you were including apache (more likely boa!), you would be able to specify the initial document root and other essential variables. -mdf Matthew D. Franz[EMAIL PROTECTED] Trinux: A Linux Security Toolkit http://trinux.sourceforge.net
Re: Menu hierarchie for different users and general user settings
On Wed, 19 Jul 2000, Andreas Tille wrote: interesting one for this kind of user. So I wonder if there could be installed a mechanism in the menu system which serves the following functionality: 1. list menuitems of all installed software (the state we have now) for the experienced user [...] This together with internationalisation seems to be a very difficult goal. I would prefer to have language and more important advantage of a user not as fixed values but values that can be modified by user in the menu. A very convenient way would to have the normal all-and-every-thing menu as standards and user-definable changes on a per user basis. Perhaps a file like --- GENERAL type child GENERAL language german INCLUDE xzy/exclude-non-free RENAME_ITEM games Spielchen EXCLUDE_ITEM games/uvw INCLUDE_ITEM Format wie in bisherigen Menues --- Where GENERAL ist just a kind of include /usr/lib/menus/stencil/$where/$what and could be easily changed by a little programm. (Or even the programm making the wm-configs out of this could have a --temp-override language xzy, which could presented in a little menuitem.) It's advantage would be a very convenient way for the user to change. It's disadvantage would be the enourmous amount of time to recompile all user-settings when the main-menu-database changes. Hochachtungsvoll, Bernhard R. Link
RE: Embedded Debian (was: compaq iPaq)
Matthew Franz wrote: Frank, I think the OS-builder app is a great idea. Would its raw material be pre-compiled debian binary packages or would My first pass at this will be based on snarfing pre-compiled binary packages. Simply QD, but probably useful to a lot of people. it be able to build the system from source. Unless there were separate I think building from source is a valid next step... embedded .debs, I don't know that the standard binaries would be compact enough to support limited memory/storage environments. Take busybox. Based on the build instructions, the app would modify busybox.def.h and build the binary to contain only the commands/features that were necessary. In many cases, the standard .debs would probably be fine, but in some cases you would need more control over the build. One of my thoughts was to have something like a Use Busybox Whereever Possible config option. If this is set, then for each utility chosen by the user, if there is a busybox implementation for this utility, use that instead of the 'standard' version. An added benefit would be if the OS-builder were modular and extensible enough to not only configure which packages are to used but to configure the packages themselves. Lets say you were including apache (more likely boa!), you would be able to specify the initial document root and other essential variables. Yup! -Frank. ___ Emdebian-discuss mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/emdebian-discuss
Re: Embedded Debian (was: compaq iPaq)
On Wed, 16 Aug 2000, Matthew Franz wrote: Would its raw material be pre-compiled debian binary packages or would it be able to build the system from source. Unless there were separate embedded .debs, I don't know that the standard binaries would be compact enough to support limited memory/storage environments. Take busybox. Based on the build instructions, the app would modify busybox.def.h and build the binary to contain only the commands/features that were necessary. In many cases, the standard .debs would probably be fine, but in some cases you would need more control over the build. For the most part, I think there is enough flexibility within Debian to pick and choose the smallest tools that will do the job from among the binary packages. Where Debian currently falls short, we can create -tiny versions of packages as needed. Most useful optimizations that can be done at compile time can also be used to create binary packages to save people the time and bother of compiling it themselves. Busybox, however, is a special case. Looking at the boot-floppies package in Debian, busybox is compiled specifically for boot floppies, and no mechanism is provided for hand-picking components. So I agree that some sort of configuration at compile-time would be a useful. Is busybox used anywhere else in Debian? It's curious that busybox isn't packaged separately. Ben -- nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED] Debian http://www.debian.org [EMAIL PROTECTED] [ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] [ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
RE: Embedded Debian (was: compaq iPaq)
Hi Ben, Ben Armstrong wrote: anywhere else in Debian? It's curious that busybox isn't packaged separately. Actually, a few weeks ago Erik Anderson wrote to tell me: FYI, I just uploaded busybox_0.45-1_i386.deb busybox-static_0.45-1_i386.deb busybox_0.45-1_i386.changes busybox_0.45-1.dsc busybox_0.45-1.tar.gz to ftp-master, where it is now sitting in incoming. -Frank.
Re: Menu hierarchie for different users and general user settings
On Wed, 16 Aug 2000, Bernhard R. Link wrote: This together with internationalisation seems to be a very difficult goal. Yes! Fully agreed! We have (at least) two parameters which characterize a user: prefered language and knowledge state While we could guess that the prefered language is no subject of change and so it might be defined once per new user which is introduced top a system (may be with an additional alternative to fall back) the state of the users knowledge is changing. I would prefer to have language and more important advantage of a user not as fixed values but values that can be modified by user in the menu. So a user has to be enabled to change his menus regarding to his knowledge about the system. The problem is that in general a (bloody) beginner will not know, how to do that - and there's the problem. I really don't have any slightest idea how to solve this problem. May be we should start at first with the language problem because this not as tricky as the other one. (Well, it's solved for *other* OSes and so we could solve it for sure ;-).) The problem of overloaded menus for beginners isn't solved in other systems, but may be somebody will have a clever idea, if there is a request for such a thing. That's why I expressed my idea, really knowing that it wouldn't be solved in the next years. A very convenient way would to have the normal all-and-every-thing menu as standards and user-definable changes on a per user basis. In principle yes, it's a first state, but it requires work of the system administrator for those users, which aren't able to do this stuff. It's disadvantage would be the enourmous amount of time to recompile all user-settings when the main-menu-database changes. Yes, that's a problem, but computers are going to be faster every time and I think it will take some time until we finish this. Kind regards Andreas.
Re: Intent To Split: netbase
On 15-Aug-00, 17:12 (CDT), Eray Ozkural [EMAIL PROTECTED] wrote: I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. I can see that typing 'sudo ifconfig' might be easier than '/sbin/ifconfig', depending on how one's fingers are wired. What I cannot figure out is why typing 'ln -s /sbin/ifconfig ~/bin' *once* is not easier than either... Steve
Woody goals: data section and science section
Now that potato is out, it would be nice to finally create the proposed data and science sections. Just a reminder.
Re: Potato now stable
On Wed, 16 Aug 2000, Bas Zoetekouw wrote: Has anyone has looked into porting this [Kudzu] to Debian? Mandrake, too, includes a hardware detection libarary (libdetect). Some time ago, Dan Helfman [EMAIL PROTECTED] (Cc'ed him), was busy packaging it. Dan, have you had any luck yet adapting it to Debian? I recall reading a few months ago about a plan to merge ALL of the existing hardware detection routines into one lump, in order to consolidate work and effort. The proposal was met with acceptance by many (if not all) of the major developers (Mandrake, Redhat, Suse, Turbo) You might want to do a search on LWN (www.lwn.net) or Linuxtoday, or elsewhere. I did a quick look and didn't find it, but I know I read about it. please post if you do find a link to it.
Re: Menu hierarchie for different users and general user settings
On Wed, 16 Aug 2000, Andreas Tille wrote: The problem of overloaded menus for beginners isn't solved in other systems, but may be somebody will have a clever idea, if there is a request for such a thing. That's why I expressed my idea, really knowing that it wouldn't be solved in the next years. What about a simple menu menu-style in the root of the menu, in which one will find language and style. Under style there will be Entries expert, advanged , normal , beginner , child, gamer. When one clicks on this, a little script is started, which only makes a sed with s/^( |\t)*global( |\t)style.*$/GLOBAL STYLE gamer/ and then runs the program to recreate the users menu out of the global menu and the local file, now containing an other style-include-file. (Or even better, it only runs this programm mit parameter style=expert and this program changes the file and recreates users menu). This way users can easily switch their style (and also easy switch it back), and advanged users can by the same means customize their menu however they want to. (As the local file is only a list of let this away,rename this,add this and include files with the global only beeing special and easy to change forms of include-files) A very convenient way would to have the normal all-and-every-thing menu as standards and user-definable changes on a per user basis. In principle yes, it's a first state, but it requires work of the system administrator for those users, which aren't able to do this stuff. I think when plans to modulise adduser come true, it would be easy to add an point that only echo GLOBAL style xyz $CREATEDHOMEDIR/.mymenu and a echo GLOBAL language xyz $CREATEDHOMEDIR/.mymenu And switching langauge anyone should be able to do. It's disadvantage would be the enourmous amount of time to recompile all user-settings when the main-menu-database changes. Yes, that's a problem, but computers are going to be faster every time and I think it will take some time until we finish this. I think the proposed way could already be done now. I think when there is consens what to do, even a worse programmer like me would need one and a half week maximum for it. And so long would need any change in the main-menu-database, because the menu-creater would not only to be run once per wm but one per wm times one per user. (On an old 386 perhaps two and a half week :-) Hochachtungsvoll, Bernhard R. Link
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 09:23:11AM +0300, Eray Ozkural wrote: For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. On Wed, Aug 16, 2000 at 02:42:37AM -0500, Branden Robinson wrote: I think if someone has to do such a thing, then: a) they forgot to su root; or b) they don't know they need privleges to use the command in question; or c) the command doesn't belong in sbin anyway. While I agree with your thinking, I think you've left out a case: d) they don't know about an alternative command which is already in their path. [For example: netstat -er gives the same information as route.] While I'm on this subject, I should mention: the man page for the netstat in netbase 3.18-1 claimed: netstat -ei will print a table or a single interface entry just like ifconfig does. This is true for the netstat in net-tools 1.57-1, but was blatantly false for the netstat that came with netbase. Strangely, the manpage in net-tools doesn't document this behavior (nor the netstat -er behavior). I wonder if this new lack of documentation should be considered a bug? -- Raul
Re: Potato now stable
I recall reading a few months ago about a plan to merge ALL of the existing hardware detection routines into one lump, in order to consolidate work and effort. The proposal was met with acceptance by many (if not all) of the major developers (Mandrake, Redhat, Suse, Turbo) please post if you do find a link to it. reply to my own request: It was on this list I saw it (gee, how nice), and Dan Shearer ([EMAIL PROTECTED]) was organizing it. Wichert replied to his request for help and said he'd love to see this happen, and pointed Dan to boot-floppies as the group to work with for Debian. Dan replied with a long post quoting his plan and more. the thread was in May 2000, http://www.debian.org/List-Archives/debian-boot-0005/msg00471.html starts the thread and http://www.debian.org/List-Archives/debian-boot-0005/msg00482.html contains Dan's proposal
Re: Non-US Incoming
Previously Michael Sobolev wrote: Is it possible to access this for non-developers? No. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpr1t588qiNV.pgp Description: PGP signature
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 12:18:14PM -0700, Steve Bowman wrote: OK, how about moving everything into /bin except what FHS specifically says should be in /sbin? Section 3.10[0] identifies the following specifically to be located in /sbin: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. (The Hurd has a symlink from /usr to /, this way everything is in /bin and /sbin, this doesn't violate the FHS either). For those few remaining executables, people can make a symlink, change their PATH, create an alias, or type /sbin/ first. Of these, probably only ifconfig and route are used by many non-root users (although Joey's got a point). I think it makes sense to go the full nine miles if you start heading this direction. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Potato now stable
On Aug 16, Bas Zoetekouw wrote: Mandrake, too, includes a hardware detection libarary (libdetect). Some time ago, Dan Helfman [EMAIL PROTECTED] (Cc'ed him), was busy packaging it. Dan, have you had any luck yet adapting it to Debian? Dan has reasonably up-to-date packages of libdetect and HardDrake (Lothar) at http://torsion.org/witten/debian. I uploaded an earlier release of libdetect to Incoming as Dan's sponsor, but it's been languishing there for weeks. Chris
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 02:34:26PM +0200, Marcus Brinkmann wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. This has nasty implications with the current implementation of dpkg, given that /sbin is currently a real directory on debian systems. -- Raul
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Well, the FHS is contradicting itself here. On one hand, it says that ifconfig is required to be in /sbin, on the other, according to this paragraph, since a user could ocassionally wish to run ifconfig to list the interfaces, it has to be in /bin. Someone should bring this up on the FHS list. I agree with that much. Blindly following a contradictory standard is only going to get us into trouble later on. Blindly following your fiat declarations about traceroute are getting us into trouble now. Just to rephrase my main reason for not moving traceroute, it's a tool that is in the same category as ping/ifconfig/route, i.e., it's a network diagnostic tool. On Linux, ping has traditionally been in /bin while the other three have always lived in /sbin and /usr/sbin, respectively. You can have consistency or you can have tradition. You can't have both, so cut it out. Either move ping or move traceroute. Incidentally, if one wants to argue by analogy, traceroute is more similar to ping than it is to ifconfig or route, because both traceroute and ping actually send ICMP packets out over the interface, and neither ifconfig nor route do. Under such reasoning, traceroute uncontrovertibly belongs in bin, since the FHS explicitly says ping should go in bin. Unless there is a very good reason (for the convenience of users who should really be changing their PATH variable is not good enough IMHO), we shouldn't move these things around as LOCAL scripts may depend on them. LOCAL scripts should do things the right way. I.e., not depend on the exact installed pathname of a program that should be in the $PATH. (Yes, I think unprivileged scripts wanting to call traceroute should add /usr/sbin to their $PATH. The fact that they have to do this is evidence of the breakage you have caused, not a defense for leaving things as they are.) Now if a later version of the FHS unequivocally stated that all these tools should be in /bin or /usr/bin, and as a project we decide to do that, then we can carry out such a change in a way not dissimilar to how things were moved around when the FSSTND first came about. I see. So you'll stonewall on each and every command in sbin you maintain until the FHS explicitly decrees that they move to bin. This is unacceptable, and is why I argued elsewhere for a Debian policy that removes these decisions from discretion of the package maintainer; thanks to you, we've seen that package maintainers can't be trusted with this discretion. -- G. Branden Robinson | Debian GNU/Linux| The noble soul has reverence for itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://www.debian.org/~branden/ | pgpJHmyE6qhZQ.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 08:34:09PM +1000, Anthony Towns wrote: This definition is really quite poor if you put too much emphasis on the ever. swapon, for example, is clearly a tool for the admin, but a user might decide one day to run it just see which version of the program is installed on the system. Well, let's not get carried away. That's a diagnostic on the tool itself and tells you nothing about the system. If all an unprivileged user of a command can do with a program is get help, the version info, its license, and similar bits of info, I don't think it qualifies for /usr. After all, such things can be (and often are) in the program's manual page, and we don't leave section 8 out of users' MANPATHs. Contrariwise, you can't read ifconfig's manpage to find out what interfaces are currently up on your system. -- G. Branden Robinson | It doesn't matter what you are doing, Debian GNU/Linux| emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://www.debian.org/~branden/ | pgp04rduXVXM6.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 10:53:51AM -0400, Raul Miller wrote: On Wed, Aug 16, 2000 at 02:42:37AM -0500, Branden Robinson wrote: I think if someone has to do such a thing, then: a) they forgot to su root; or b) they don't know they need privleges to use the command in question; or c) the command doesn't belong in sbin anyway. While I agree with your thinking, I think you've left out a case: d) they don't know about an alternative command which is already in their path. [For example: netstat -er gives the same information as route.] I don't think it's feasible for a standards body or a package maintainer to make case-by-decisions on the location of a tool based upon the functionality of every other tool that might provide that functionality. This would lead to an unstable environment, where the presence of route in bin would justified if and only if nothing else could show you the routing tables. This would also differ on a system-by-system basis as users have different packages installed. Should route go into bin for users that (somehow) don't have netstat installed, but sbin for users that do? It makes no sense. In other words, I think the choice of directory should be controlled by factors intrinsic, not extrinsic, to the program in question. -- G. Branden Robinson | One man's magic is another man's Debian GNU/Linux| engineering. Supernatural is a [EMAIL PROTECTED] | null word. http://www.debian.org/~branden/ | -- Robert Heinlein pgp2D6FPqj4VQ.pgp Description: PGP signature
Re: Intent To Split: netbase
Marcus Brinkmann ([EMAIL PROTECTED]) wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. (The Hurd has a symlink from /usr to /, this way everything is in /bin and /sbin, this doesn't violate the FHS either). i'm no expert on capabilites, but won't their addition null the need for sbin directories? i mean, you could have a uid that can bring up interfaces, but not halt the machine. or even, halt the machine but not alter partition tables. also, i don't know how comitted debian is to using capabilites. either way, 'insmod asbestos_underware'. -- jacob kuntz [EMAIL PROTECTED] [EMAIL PROTECTED] underworld.net/~jake
Re: Potato now stable
On Wed, Aug 16, 2000 at 08:46:38AM +0200, Bas Zoetekouw wrote: Thus spake Colin Walters ([EMAIL PROTECTED]): I noticed the other day that recent versions of RedHat use something called Kudzu (sp?) to do this. When I took out the network card, it warned me that some hardware was missing, and offered to change some things to compensate. Has anyone has looked into porting this to Debian? Currently, in Debian it is being used by sndconfig. It was written specifically for Redhat though and does some things (like editing /etc/conf.modules, linking devices in /dev/) which are probably not desirable in Debian. The detection part can probably be used, though. Mandrake, too, includes a hardware detection libarary (libdetect). Some time ago, Dan Helfman [EMAIL PROTECTED] (Cc'ed him), was busy packaging it. Dan, have you had any luck yet adapting it to Debian? Yup, libdetect required very little in the way of modification and works fairly well on Debian. Harddrake (formerly Lothar) is the GUI and console interface for libdetect. It handles autodetection and configuration. Harddrake did require some modifications to work with Debian's modutils, and those patches have now been integrated into the upstream source. When a hardware detection library is available, I think I'm going to rewrite sndconfig specifically for Debian instead of editing the Redhat package. Maybe a more general program, which can detect and configure various kinds of hardware, should be created though. You might try playing with Harddrake to see if it suits Debian's needs for this sort of thing. It has both Gtk and Newt interfaces. And by the way, Harddrake also has a kudzu mode that can be called from boot scripts. I haven't tried it out yet, but it's intended to do much the same thing as Redhat's kudzu. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| | [EMAIL PROTECTED] | Pablo Picasso | +---+ -- Dan Helfman UCLA Linux Users Group: http://www.linux.ucla.edu My GnuPG key: http://torsion.org/witten/public-key.txt
build dependencies
It would be cool if packages had better support for build dependencies so its easier/more reliable to build from source. There would probably have to be a set of source base packages defined somewhere that are required as a base for building, but not a base for regular usage as base is currently defined. Better support for building from source could be very handy as the number of architectures increases. Maybe we could even have support in the installer to build from source, that way if the source was distributed with a minimal amount of binary packages for each architecture everything else could be built on the fly. Not ideal, but good if a user wants to experiment on a second architecture. Glenn
Re: build dependencies
On 2817T040155+1000, bug1 wrote: It would be cool if packages had better support for build dependencies so its easier/more reliable to build from source. Specifically? There would probably have to be a set of source base packages defined somewhere that are required as a base for building Why source packages? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Debian entry out to date in Distribution HOWTO
Hi all, Translating the Distribution-HOWTO, I noticed that the Debian Linux (sic) entry in this HOWTO was seriously out to date since it hasn't been modified since July 1998, when hamm was released ! Furthermore, it talks about Debian Linux instead of Debian GNU/Linux. I know this HOWTO is generally out to date (there was a Yggdrasil entry until this year !), but that would be good for Debian to offer a correct and up to date information to the newbies who reads the HOWTOs. We all know that the beginners who reads the HOWTOs before installing Linux will finish anyway by using Debian :) So, if anyone is volunteer, please read the section Submissions to this document before contacting Eric S. Raymond -- aka esr -- mailto:[EMAIL PROTECTED]. Thanks in advance, -- mmenal
Re: build dependencies
bug1 wrote: It would be cool if packages had better support for build dependencies so its easier/more reliable to build from source. Something like this? Source: gri Section: math Priority: optional Maintainer: Peter S Galbraith [EMAIL PROTECTED] Build-Depends: debhelper, netcdfg-dev, tetex-bin, texinfo Build-Depends-Indep: debhelper, tetex-bin, texinfo, imagemagick, info, gs, gsfon ts Standards-Version: 3.1.1 There would probably have to be a set of source base packages defined somewhere that are required as a base for building, but not a base for regular usage as base is currently defined. Something like this? http://www.debian.org/Packages/unstable/devel/build-essential.html Better support for building from source could be very handy as the number of architectures increases. Maybe we could even have support in the installer to build from source, Something like this? # apt-get source --compile gri Or have I missed something? Peter
Re: Intent To Split: netbase
Perhaps not. But a traceroute in /usr/bin would satisfy more people than a traceroute in /usr/sbin. Traceroute is a diagnostic command. As such it isn't general use. When a user or administrator is using it it is because of unusual conditions. My opinion is to leave it in /usr/sbin. Let them type a few extra characters, or add the sbin directories to their path. The same can be said of ping, but ping existed before the bin/sbin split. As such there is legacy code that expects it to be there. If one really wants it in the general users path, then run a symbolic link back to the original from the appropriate bin directory. -- | Bryan Andersen | [EMAIL PROTECTED] | http://softail.visi.com | | Buzzwords are like annoying little flies that deserve to be swatted. | | -Bryan Andersen|
Problem with apt on slink systems
Hi I've just noticed a problem, when I wanted to install a package on an old slink system. [EMAIL PROTECTED]:~# grep ^[^#] /etc/apt/sources.list deb ftp://ftp.rfc822.org/debian slink main contrib non-free deb-src ftp://ftp.rfc822.org/debian slink main contrib non-free deb ftp://source.rfc822.org/debian-non-US slink non-US deb-src ftp://source.rfc822.org/debian-non-US slink non-US deb http://security.debian.org slink updates [EMAIL PROTECTED]:~# apt-get install zsh [... Everything fine here ...] Get:1 ftp://ftp.rfc822.org slink/main zsh 3.1.2-10 [591kB] Err ftp://ftp.rfc822.org slink/main zsh 3.1.2-10 Unable to fetch file, server said '/debian/dists/stable/main/binary-i386/shells/zsh_3.1.2-10.deb: No such file or directory ' Failed to fetch ftp://ftp.rfc822.org/debian/dists/stable/main/binary-i386/shells/zsh_3.1.2-10.deb Unable to fetch file, server said '/debian/dists/stable/main/binary-i386/shells/zsh_3.1.2-10.deb: No such file or directory ' E: Unable to fetch some archives, maybe try with --fix-missing? Where the heck the word 'stable' comes from? I removed my hole /var/state/apt/ and I do not know where it comes from. Hardcoded anywhere perhaps? Or did I miss something grave? MfG/Regards, Alexander -- Alexander Reelsen http://joker.rhwd.de [EMAIL PROTECTED] GnuPG: pub 1024D/F0D7313C sub 2048g/6AA2EDDB [EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E 7C88 EE9C CBD1 F0D7 313C Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO
Re: Problem with apt on slink systems
[EMAIL PROTECTED]:~# grep ^[^#] /etc/apt/sources.list [snip] [EMAIL PROTECTED]:~# apt-get install zsh [snip] Where the heck the word 'stable' comes from? I removed my hole /var/state/apt/ and I do not know where it comes from. Hardcoded anywhere perhaps? Or did I miss something grave? Did you 'apt-get update'? I'm not an apt-get internals expert but perhaps it cached the 'real' paths to the ftp/http locations instead of the symlinked ones so they are now all out of whack. Which makes me think - is it still possible to apt-get a slink update now it's fallen off the stable/frozen/unstable chain? Dave
Re: Problem with apt on slink systems
On Wed, Aug 16, 2000 at 12:53:03PM -0700, dsb3 wrote: Where the heck the word 'stable' comes from? I removed my hole /var/state/apt/ and I do not know where it comes from. Hardcoded anywhere perhaps? Or did I miss something grave? Did you 'apt-get update'? Yeah. I'm not an apt-get internals expert but perhaps it cached the 'real' paths to the ftp/http locations instead of the symlinked ones so they are now all out of whack. Which makes me think - is it still possible to apt-get a slink update now it's fallen off the stable/frozen/unstable chain? As addition: I checked the ftp and it is ok, the symlink is ok, the package is there in the slink tree, but still stable is requested. A friend of mine has the same problem with his slink, seems to be reproducable. MfG/Regards, Alexander -- Alexander Reelsen http://joker.rhwd.de [EMAIL PROTECTED] GnuPG: pub 1024D/F0D7313C sub 2048g/6AA2EDDB [EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E 7C88 EE9C CBD1 F0D7 313C Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO
Re: Problem with apt on slink systems
On Wed, 16 Aug 2000, Alexander Reelsen wrote: Where the heck the word 'stable' comes from? I removed my hole /var/state/apt/ and I do not know where it comes from. Hardcoded anywhere perhaps? Or did I miss something grave? The slink package files have this inside.. That needs to be changed by us. Jason
RE: Embedded Debian (was: compaq iPaq)
Ag, evil. If you plan to use busybox upgrade to .46 there are some serious problems with .45 in regards to tar and nfs. On Wed, 16 Aug 2000, Frank Smith wrote: Hi Ben, Ben Armstrong wrote: anywhere else in Debian? It's curious that busybox isn't packaged separately. Actually, a few weeks ago Erik Anderson wrote to tell me: FYI, I just uploaded busybox_0.45-1_i386.deb busybox-static_0.45-1_i386.deb busybox_0.45-1_i386.changes busybox_0.45-1.dsc busybox_0.45-1.tar.gz to ftp-master, where it is now sitting in incoming. -Frank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 12:31:47 -0500 (+), Branden Robinson wrote: On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Well, the FHS is contradicting itself here. On one hand, it says that ifconfig is required to be in /sbin, on the other, according to this paragraph, since a user could ocassionally wish to run ifconfig to list the interfaces, it has to be in /bin. Someone should bring this up on the FHS list. I agree with that much. [snip] What so wrong with user tools in */bin and sysadmin tools in */sbin. As an advanced user, I always put /sbin and /usr/sbin in my PATH, whatever the unix I'm on. People who know about ifconfig should know enough to add /sbin and /usr/sbin to their PATH IMO. Adrian email: [EMAIL PROTECTED] Windows NT - Unix in beta-testing. PGP key available on public key servers Debian GNU/Linux -*- because I'm allergic to Prozac -*- www.debian.org
Re: ITP: Moscow ML - An implementation of standard
Torsten Landschoff said: I don't quite remember. I think I contacted inria (they hold the Caml copyright) about changing that but to no extent. I am not sure if changing the MoSML license would help - at least it has to go to non-free then. I did not want to maintain a non-free package at that time so I gave up on it. They changed the license on OCaml to the QPL recently. It's not GPL compatible, and it's not the nicest license in the world, but it is a free license the Moscow ML people could work with.
Re: Intent To Split: netbase
On Wed, 16 Aug 2000, Anthony Towns wrote: FHS discuss people: where should traceroute go? Tradition dictates /usr/sbin, the FHS seems to indicate /usr/bin would be more appropriate. [analysis] IMHO, the deciding factor should be whether traceroute is installed setuid root. If traceroute is *not* installed setuid, then normal users cannot do anything useful with it except perhaps get usage information (which is already covered in the man page). Therefore, putting a non-setuid traceroute binary in /usr/bin is pointless; it should go in /usr/sbin because it is only useful to root. If traceroute *is* installed setuid, then implicitly, it is intended for non-root users to run. Otherwise, there would be no need to install it setuid. Therefore, if a setuid traceroute binary exists on the system, it should be in /usr/bin. I suppose one could argue that a setuid traceroute binary could be intended for non-root system accounts to run (i.e., still not be intended for all regular users), but personally, I think that would be a stretch. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA
Re: Embedded Debian (was: compaq iPaq)
Quoting Ben Armstrong [EMAIL PROTECTED]: sort of configuration at compile-time would be a useful. Is busybox used anywhere else in Debian? It's curious that busybox isn't packaged separately. debian developer and author/maintainer of busybox hat on For woody, we are creating a new section of the Debian archive for the debian-installer (new name for the boot floppies). BusyBox will be a stand-alone package in that section (actually, there are two busybox packages -- busybox and busybox-static, which is statically linked with everything turned on for rescuing your system when it is hosed). To build .debs of busybox, grab the source (either from CVS on opensource.lineo.com, or from released tarballs) just run 'dpkg-buildpackage' and it'll build. Next week as we start ramping up for woody, the new archive section will probably be showing up on mirrors and busybox .debs will be there. The source code in the boot floppies CVS tree is out of date, since we froze it quite a while ago, and has a number of bugs (none release critical, but some a bit annoying) that are fixed in the latest and greatest... -Erik -- Erik B. Andersen Web:http://www.xmission.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons--
Re: Installing packages without manpages and docs
On Mon, 7 Aug 2000 17:53:30 +0200, Paul Slootman [EMAIL PROTECTED] wrote: On Mon 07 Aug 2000, Marc Haber wrote: Is there any way to make apt-get stop installing packages' man pages and documentation? I never actually tried that, but would symlinking No. That's bad. Anyway, I can stop searching now, thanks. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Office Suite for Debian Linux
Dear Debian Linux, I am familiar with you operating system and wanted to contact you. I represent VirtualTek Corp. here in Seattle, WA., http://joydesk.com. Our flagship product, Joydesk, is a web-based PIM application (email, calendar, address book, message board and task list), designed specifically for Linux platform. It is also designed with the SME and SOHO market niche in mind, to set up an instant Intranet solution. When available, I would like to contact you, as we will be in your area towards the end of September. If you would not have any objection, I would like briefly stop by your offices to show a quick demonstration of Joydesk and discuss potential OEM/bundling opportunities with your distribution, if it may present itself. Thank you for your time, and I look forward to your response. Best Regards, Sam Sim Business Development VirtualTek Corporation Ridgewood Corporate Center Building E, Suite 201 170 120th Ave. NE Bellevue, WA 98005 v: 425.450.9494 x 16 f: 206.374.2856 c: 206.852.9954 Enabling a Wireless World. http://joydesk.com
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 12:40:42PM -0500, Branden Robinson wrote: In other words, I think the choice of directory should be controlled by factors intrinsic, not extrinsic, to the program in question. I think this is a reasonable viewpoint. -- Raul
Unofficial packages for Postaci
Hi, I've preapared a deb package for postaci. Postaci is a PHP based POP3 e-mail client that stores e-mail in virtual MySQL tables. It supports English, German, French, Turkish and is also fully MIME compatible. I cannot upload the packages because I'm not an official developer. I will be glad if someone test this package. The address is: deb ftp://bilmuh.ege.edu.tr/pub/debian/dists/potato binary-all/ Murat Demirten Ege University Computer Engineering
Re: Office Suite for Debian Linux
Hello Sam, Debian is an effort driven by volunteers. Our focus is free software, although we also provide ftp space for non-free software which can be distributed in debian format at no cost, if there is a volunteer to maintain it for Debian. On Wed, Aug 16, 2000 at 04:01:00PM -0700, Sam Sim wrote: I am familiar with you operating system and wanted to contact you. I represent VirtualTek Corp. here in Seattle, WA., http://joydesk.com. Our flagship product, Joydesk, is a web-based PIM application (email, calendar, address book, message board and task list), designed specifically for Linux platform. I visited your web site and could not find out any information regarding the license under which you distribute joydesk. Debian, as a volunteer effort driven by a community, does not promise to ship any software package, but if there is a volunteer to package it for Debian, and it is free software, nobody will prevent its inclusion into Debian. Our definition of free is strong, and can be found at http://www.debian.org/social_contract#guidelines We request the source code and everyones right to modify and distribute modified versions as source code and binaries. Even if you have no free license for your software, a volunteer might want to package it for the non-free area of the ftp archive, but less likely so. Note that in any case non-free software can not be part of the Debian GNU/Linux distribution, and there must not be a royalty for a copy of your software. When available, I would like to contact you, as we will be in your area towards the end of September. Debian is spread all over the world, and there is no authority you can contact about this matter. There are no offices. The best way to make sure your software gets included into Debian is 1. Give it a free software license, 2. Have some employee join Debian and package your software for Debian. The second step might not be necessary if your software is interesting enough for a volunteer who already is or wants to become a Debian maintainer to package it for you. I hope this email sheds some light on the issue you are facing. The free software community is not organized like a company, and Debian is a non-commercial volunteer effort right at the heart of the movement. Please understand that we can not accommodate ourselve to your corporate needs, but we will be happy to not stand in your way if you want to contribute to our efforts. Thank you, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Bug#69271: general: why not a praise tracking system?
Package: general Version: 2816 Severity: wishlist Hi, Debian has for years maintained an excellent bug tracking system. What I am missing is a praise tracking system. It would operate similarly to the b.t.s.; users could: - send mail to [EMAIL PROTECTED] to have their recognition for a debian package registered and forwarded to the maintainer involved. - visit http://praise.debian.org/package to inspect appraisals submitted for package. - use a command-line tool /usr/bin/praise to facilitate the process of giving praise to debian packages. - send acknowledgements and append their own success stories to active appraisals in the a.t.s. to [EMAIL PROTECTED] - send mail to [EMAIL PROTECTED] and change various praise control fields. Cheers, Joost PS: I was really just reading /usr/bin/bug, trying to figure out how to submit bugs in helixcode to their b.t.s. Then I found the pieces of code that handle /usr/share/bug/* customization files to be included by debian packages. This is really nice work, and I felt like telling so the bug maintainer. Then I figured that while there is an excellent infrastructure for bug tracking, there is no such thing whatsoever for praise tracking. -- System Information Debian Release: woody Kernel Version: Linux calypso 2.2.14 #1 Fri Jan 7 20:24:30 CET 2000 i586 unknown
Linux Users Forum and Awards Presentations - 30 Oct 2000 - Wash. D.C. AWARDS... EXHIBIT AND SPONSOR OPPORTUNITIES
To:debian-devel@lists.debian.org First Annual Linux User's Training Conference And Awards Presentation New Enterprise Solutions Through Linux October 30, 2000 Ronald Reagan Building and International Trade Center 1300 Pennsylvania Avenue Washington D.C. Atrium Ballroom PLEASE PASS THIS TO YOUR SALES EXECUTIVE RESPONSIBLE FOR SALES TO THE U.S. GOVERNMENT. THIS IS A PREMIER OPPORTUNITY FOR YOUR COMPANY TO EXHIBIT AND SHOWCASE YOUR LINUX PRODUCTS AND SERVICES. GO TO OUR WEB SITE. WE ARE VERY SUCCESSFUL AT PRODUCING EVENTS THAT SERVE THE INTERESTS OF GOVERNMENT AND INDUSTRY. Event Sponsors: * CIS Global * Aronson, Fetridge, Weigle * INPUT ... new sponsors to be announced. Purpose of Conference: Twenty-six percent (26%) of federal installations have reported use of the Linux operating system in their organization, as reported by IDC. IDC also estimates that most of the government's sophisticated, back-office computers will be running Linux by 2002. Just when agencies are turning to enterprise-wide solutions and mainframe class applications, the Linux operating system offers a new and exciting alternative. This will be a one-day conference that will present agency plans and strategies for deploying new and innovative Linux applications. The conference will focus on those Linux applications that are in the early or test bed stage AND will likely evolve into enterprise-level deployments. Who Should Attend: * Government technical managers * Agency executives * Program managers * Agency e-commerce planners * Companies with Linux related products and services * Government executives responsible for enterprise applications * Military command and control officers What Attendees Will Learn: * Where and how Linux is being used * New plans for enterprise applications * Innovative ideas and strategies * New opportunities for Linux products and services * Agency plans for new and innovative enterprise applications Recognizing Technical Achievement: Also at this conference, awards will be presented to those U.S. government organizations that have taken a technology leadership role in developing innovative Linux Applications. Award categories to be considered: * Innovative applications * Enterprise-wide applications * Military Command and Control * Electronic Commerce * Science and Research * Mobile Office and Portable Applications * Management and Leadership Candidate projects will be submitted to a joint industry-government team for evaluation and selection. The winners will receive recognition at the event, with their agency, and in the press. Members of the evaluation team include: * INPUT Federal * Federal Executive Review Panel * Mr. Art Chantker, President, The Potomac Forum Ltd., Chair Please survey your agency and department. If your organization has one --or more -- Linux applications in the early stages of evaluation, planning, test, or deployment -- tell us about your project and the team running it. Initially we only need a max of 1 page summary of the project and a point of contact at the team so that we can obtain additional information as needed. Closing date for submission of your candidate project teams is 7 September 2000. How to submit your project for consideration: Outline for Candidate Submission 1. Name of project, Department/Agency. Phone, email and web site contact information for Team/Project Leader and team members. 2. Brief description of the project. Focus on the application, reason for selection of Linux. Status. 3. Potential Impact. If the project or test is successful, describe the magnitude of the deployment and impact on the project and/or government enterprise. 4. Contractor(s) supporting the project (if any) and Point of Contact The First Annual Federal Users Training Conference will also highlight the new and exciting applications that are in place today and are in development. Exhibits, demonstrations and presentations will allow federal users to become informed of new Linux products and services. Agency presentations will focus on projects in the early stages that will provide innovative enterprise-level applications. Leaders will be recognized for their contributions and technology innovation. Please respond today with your candidates. Submit your candidates by email or fax to: Federal Linux Users Forum Market*Access International Suite 810 5454 Wisconsin Avenue Chevy Chase, Maryland 20815 Phone: 301-652-0810 FAX: 301-652-0914 Email: [EMAIL PROTECTED] Potomac Forum Ltd and Market*Access are independent organizations not associated or supported by any Linux supplier or manufacturer. See our current list of sponsors and find out how you can become one! Government training forms and credit cards accepted. The registration fee for this important training conference is: Government Credit Card or Check in Advance: $295.00 Government Training Forms/Purchase Order: $345.00
Re: Bug tracking system and testing distribution Re: Potato now stable
Christoph Martin wrote: We have a problem with the bug tracking system as long as we can't really find out to which versions of a package a bug really applies. We only mosttimes have the version of the packages where a problem showed up. But we don't know if the bug was introduced with this version or also applies to older ones. And in the case of different distributions, if the bug was reported eg. for frozen we don't know if it also exists in newer versions which are allready in unstable. This is also a problem if a bug which is in one distribution (like frozen or stable) gets fixed in another (unstable). Another issue is, that some bugs only appear in special architectures (like hurd, or powerpc). We really need a way to specify exactly to which version a version applies. As long as we don't have this feature we can't really get the testing distribution to work. Well this is why bug reproducability is so important. I don't see how a magic bullet to fix this issue is at all possible though. -- see shy jo
Re: policy changes toward Non-Interactive installation
Brian May wrote: Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve Which reminds me, what sort of security is enabled in Steve debconf? Can any user read the values from the database, or Steve is it limited to root? Not sure about this (on my system only root can read /var/lib/debconf), however: Steve An attempt to use db_get as a regular user, but only Steve because the current backend tries to write a temporary file Steve to var/lib/debconf (I think) (line 229 in ConfigDb.pm, Steve potato version). not sure how well temp files are managed. Belive it or not, I know how to safely manage temp files and protect sensitive information with unix permissions. I was told though, for the purpose of Heimdal-kdc, to put it in the postinst directory. This means it doesn't have to get stored in the database. ie the postinst script does a db_get followed by a db_set. I told you this because you stressed it was very very important. Really sheer paranoia though. -- see shy jo
Re: policy changes toward Non-Interactive installation
Brian May wrote: Just curious, why does realplayer have to do it in the postinst script? Actually, I was misremembering -- it used to do that but I removed it. As another example though, look at heimdal-kdc, which needs to ask for the password, which must be kept as secure as possible. I think we decided it was woth it from a paranoia standpoint to ask for this passowrd in the same program that used it. Debconf should handle passwords safely though. -- see shy jo
Re: Intent To Split: netbase
Branden Robinson wrote: To be frank I'm not distressed by the thought of lots of programs moving from sbin to bin, or even the elimination of sbin altogether. Perhaps it would be neat to move back to what sbin was orginially used for -- static binaries. Erik Andrerson has a whole slew of them (busybox et al) that are just looking for a home. -- see shy jo
Re: Intent To Split: netbase
Manoj Srivastava wrote: Hmm. Lets step back here, and take a deep breath. What we need to consider is whether the underlying principle is desirable -- does it make sense to have two separate path components? The rationale was that for the common user, there are programs that are not used very often, and may not even work when invoked, and thus tend to only confuse the uninitiated, and annoy enerally by messing up command comletion. The question that seems to want to be raised is whether this is true? Are people really confused more by having extra commands available, or are they confused by _not_ havingcertain commands present? Sounds fine to me. The irony is, of course, that the people generally making such decisions (like this forum) are rarely a decent sampling of the user base, or the hypothetical Joe user. Maybe we should ask our users then? As to mount telling us what is mounted, so does df, and cat /etc/mtab. again, not enough to move mount; unless one is being contrary. I dont follow this. 'echo *' can tell me what files are in a directory; a system without ls in path is still broken. I don't see how mount is much different. Regular users *often* want to mount/unmount/check mount status of removable media. And it's in /bin now, so isn't this a red herring anyway? -- see shy jo
Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote: Actually, this is a particular irritant. Why does it have to be done in the postinst? Why can't I have /usr/sbin/inst-realplayer? So I can download and install at my leaisure, and I do not have to reinstall realplayer installer to get a new copy? Or have the stupid thing want to connect out every time there is a minor upgrade to the installer? The package is intended to enforce two invarients: 1) If it is installed, realplayer is installed. 2) If it is installed and current, the current version of realplayer is installed. If you don't want to download realplayer right now, why are you installing the package? If you don't want to upgrade realplayer right now, why don't you put it on hold? The package system allows the things that annoy you to be worked around in a consistent way. -- see shy jo
Bug#69271: general: why not a praise tracking system?
Joost == Joost Kooij [EMAIL PROTECTED] writes: Joost What I am missing is a praise tracking system. It would Joost operate similarly to the b.t.s.; users could: Joost - send mail to [EMAIL PROTECTED] to have their Joost recognition for a debian package registered and forwarded Joost to the maintainer involved. - visit Joost http://praise.debian.org/package to inspect appraisals Joost submitted for package. - use a command-line tool Joost /usr/bin/praise to facilitate the process of giving praise Joost to debian packages. - send acknowledgements and append Joost their own success stories to active appraisals in the Joost a.t.s. to [EMAIL PROTECTED] - send mail to Joost [EMAIL PROTECTED] and change various praise control Joost fields. Sounds like a good idea, eg to help motivate maintainers fix bugs. Submit a bug to the BTS with severity: praise? [ when are you going to fix the 10 bugs against your package? oh, sorry they are praise bugs ;-) ] Or, redesign the BTS so it can better handle the growing number of applications (WNPP,praise tracking,etc) (eg fields specific to each application, instead of using the title for this purpose)? Or an alternative I haven't specified. -- Brian May [EMAIL PROTECTED]
Re: Intent To Split: netbase
On 16-Aug-00, 12:31 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: Blindly following your fiat declarations about traceroute are getting us into trouble now. What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. The constitution clearly says that maintainers have control over their packages. We have agreed that we'll follow Debian policy. Given the lack of policy on this particular topic, Herbert is perfectly within his rights to determine the location of traceroute, unless overridden by the technical committee. Since I've yet to see a truly technical reason to move it, I hope the committee won't interfere. Yes, if we were starting from scratch, it probably makes more sense to put it in bin, but it's simply not that big a deal. FWIW, I hope that policy won't take this up...detailing the /sbin - /bin location of explicit programs is bound to be an exersize in frustration. Steve
Bug#69271: general: why not a praise tracking system?
Joost What I am missing is a praise tracking system. It would Joost operate similarly to the b.t.s.; users could: Sounds like a good idea, eg to help motivate maintainers fix bugs. I think it would be good just to alert people to real well done packages (for instance, excellent debconf script, etc) to help teach new maintainers, or to find the best of a bunch of similar packages (there are HOW many Tetris clones? :) ) Submit a bug to the BTS with severity: praise? Why not? I don't think we need more than 2 or 3 levels of praise: recommended, exceptional, outstanding [ when are you going to fix the 10 bugs against your package? oh, sorry they are praise bugs ;-) ] The bug tracking can ignore bugs of that level (if normal bugs are 1-10, these would negative numbers of severity) Or, redesign the BTS so it can better handle the growing number of applications (WNPP,praise tracking,etc) (eg fields specific to each application, instead of using the title for this purpose)? Agreed. Makes LOTS of sense to start planning this now... BTS changes (for origin, etc etc,) can all be done over time, including this major change. Letting a maintainer know you really like their work is good feedback, and we should encourage that. Developers who don't want to hear or see praise can always filter it out (maybe even a setting in BTS: don't praise me, praise me digested, praise me all the time) the name of bugtracking software can be symlinked to 'praise' and detect what it's running as, to remove the complaint nature of the 'bug' and turn it into compliment
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
Incidentally, if one wants to argue by analogy, traceroute is more similar
to ping than it is to ifconfig or route, because both traceroute and ping
actually send ICMP packets out over the interface, and neither ifconfig nor
Hmm, I didn't know that traceroute sent ICMP packets by default. Are you
sure you are talking about /usr/sbin/traceroute?
Anyway, from my personal experience,
ifconfig/route/ping/traceroute/snmpnetstat are often used together to
diagnose problems (or just waste time and bandwidth).
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
I propose gazillion packages (LONG)
First I'd like to tell, that I don't subscribe to debian-devel, but I can read its archives from WWW. And I am not a Debian developer. I propose these packages to be added to Debian GNU/Linux. I have proposed them once before, but they are not yet added. ** Varkon: Personally I do not use CAD-software, but this is so ueber-cool thing that I just can't help informing you all about this: A CAD-software called Varkon is now available under the terms of GNU GPL. It would be nice to make it available as Debian-pacakge. http://slashdot.org/articles/99/03/08/0917217.shtml http://linuxtoday.com/stories/3841.html http://www.varkon.com/ Somebody was packaging this package, but haven't heard about it then. * * * http://www.electriceditor.com/ The Electric VLSI Design System is a complete Electronic Design Automation (EDA) system that has a long history. Electric can handle many forms of circuit design. And now it is under the terms of GNU GPL! I don't think, that I would need this program, but others might be very interested. * * * This company called BeOpen has some cool free pieces of software for programming. And they seems to be GPL'ed http://www.BeOpen.com/ OO-Browser is already packaged, but not that InfoDock. I'd like to use them, when I learn more programming. AFAIK If you download InfoDock, it has OO-Browser and Hyperbole included. And if you download OO-Browser, it has Hyperbole included. * * * http://www.wwdsi.com/saint/index.html Saint has been developed from SATAN. It seems, that it is not free software. But feel free to debate about it in a mailing-list called debian-legal. I use this software myself, and I really like it. * * * COPS - security tools for unix. Available in many security-related ftp-sites, for example: http://www.fish.com/cops/ * * * Titan: http://www.fish.com/titan/ Security analysis program. * * * The Coroner's Toolkit (TCT): http://www.fish.com/tct/ The Coroner's Toolkit (TCT) is a collection of tools that are either oriented towards gathering or analyzing forensic data on a Unix system. * * * Here is some other security tools, you might be interested: http://freshmeat.net/appindex/console/firewall-and-security.html http://www.opensec.net/ http://www.cert.org/other_sources/tool_sources.html * * * WCD: http://www.xs4all.nl/~waterlan/ KCD: http://www-scf.usc.edu/~lerdsuwa/util/kcd.html They are both Norton Chance Directory-clones and licenced under GNU GPL. I use them both myself and can't decide, which one to choose. * * * NDIR: http://www.Informatik.Uni-Oldenburg.DE/~mw/software/ndir.html Extended and advanced ls-replacement. Not unlike already-packaged limo. I use them both myself and can't decide, which one to choose. * * * XMLTerm http://xmlterm.com/ XMLterm - A graphical command line interface. If you don't understand, check out those screenshots. * * * rpl: http://www.laffeycomputer.com/rpl.html rpl is a UN*X text replacement utility. It will replace strings with new strings in multiple text files. It can scan directories recursively and replace strings in all files found. I use this software myself, and I really like it. * * * http://www.cpt.univ-mrs.fr/~penne/Zsid/ Yes, we have that xsidplay, but it uses qt-libraries, and therefore it is not in main-directory. Zsid is under GNU GPL. I would actually use this program. * * * gASQL: http://malerba.linuxave.net/ Gnome-front-end for PostgreSQL. GPL'd. * * * Gnome-db: http://www.gnome.org/gnome-db/ Needed by gASQL. * * * Who's Afraid of C++? - the WWW version http://www.steveheller.com/whos/ Review on Slashdot: http://slashdot.org/article.pl?sid=00/06/09/2153222mode=thread Other On-Line Books of Steve heller: http://www.steveheller.com/ But I can't find any licence information. * * * Toolkit for Conceptual Modeling (TCM) http://wwwhome.cs.utwente.nl/~tcm/index.html A little bit like Gnome DIA. Can be used as CASE-tool. * * * Cacheprof http://www.cacheprof.org/ * * * asp2php http://asp2php.naken.cc/ Convert asp to php. Licence: GPL * * * GVD, the GNU Visual Debugger http://gtkada.eu.org/gvd/gvd.html * * * UNIX Bourne Shell Programming http://www.torget.se/users/d/Devlin/shell/index.html http://www.torget.se/users/d/Devlin/shell/shell.zip * * * Open Inventor http://oss.sgi.com/projects/inventor/ Open InventorTM is an object-oriented 3D toolkit offering a comprehensive solution to interactive graphics programming problems. It presents a programming model based on a 3D scene database that dramatically simplifies graphics programming. It includes a rich set of objects such as cubes, polygons, text, materials, cameras, lights, trackballs, handle boxes, 3D viewers, and editors that speed up your programming time and extend your 3D programming capabilities. Licence: GNU LGPL. * * * OpenSource-programs of Applix Inc. Linux Palm Desktop Applix SHELF Linux Stoctracker
Is dh_installxfonts okay?
I am not sure and I am afraid I might misunderstand something but I wish to know... Several xfonts-* packages seem to fail removing fonts.dir/alias on removing or purging. The postrm of them has for currentdir in $fontdirs; do longdir=/usr/lib/X11/fonts/$currentdir if [ -d $longdir ]; then for file in fonts.dir fonts.alias; do rm -f $file done and I wondered rm -f $file should be something like rm -f $longdir/$file? What do I misunderstand at all? And one more question. Some packages do not add their entry (FontPath /usr/X11R6/lib/X11/fonts/.../) to /etc/X11/XF86Config , for example xfonts-cyrillic, xfonts-naga10 etc., is this okay? Thanks in advance, 2000.8.17 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: Office Suite for Debian Linux
Sam Sim wrote: Dear Debian Linux, I am familiar with you operating system and wanted to contact you. Wow. How familiar can he be? we will be in your area towards the end of September. I would like briefly stop by your offices
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 01:18:39PM -0400, Raul Miller wrote: On Wed, Aug 16, 2000 at 02:34:26PM +0200, Marcus Brinkmann wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. This has nasty implications with the current implementation of dpkg, given that /sbin is currently a real directory on debian systems. Are you sure? I believe this bug's been fixed in the dpkg in potato. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpRP0rn32KE9.pgp Description: PGP signature
