Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 02:05:58PM -0500, Bryan Andersen wrote: Traceroute is a diagnostic command. As such it isn't general use. This distinction between sbin and bin is nowhere defined as having anything to do with 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. Traceroute's been around a long, long time as well. If one really wants it in the general users path, then run a symbolic link back to the original from the appropriate bin directory. This is a lousy fix. | Buzzwords are like annoying little flies that deserve to be swatted. | | -Bryan Andersen| He who quotes himself in his own .signature files likely has no esteem for the views of anyone else, past, present, or future. -me -- G. Branden Robinson |The errors of great men are venerable Debian GNU/Linux|because they are more fruitful than the [EMAIL PROTECTED] |truths of little men. http://www.debian.org/~branden/ |-- Friedrich Nietzsche pgpjs2gLQLPu9.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote: 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. Obviously you haven't typed the actual path to traceroute in quite a while. 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. There is policy on this topic. We say we will comply with the FHS. (We should probably say we will be compatible instead, else our distribution is literally riddled with FHS violations.) 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. Which is why I argued elsewhere to leave this ball in FHS's court. But if we insist on ignoring FHS, we need to have a policy of our own that is more rational than wherever the package maintainer feels like putting it. -- G. Branden Robinson | I've made up my mind. Don't try to Debian GNU/Linux| confuse me with the facts. [EMAIL PROTECTED] | -- Indiana Senator Earl Landgrebe http://www.debian.org/~branden/ | pgpFAkxXeJjmq.pgp Description: PGP signature
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 09:34:51AM +1000, Herbert Xu wrote: Hmm, I didn't know that traceroute sent ICMP packets by default. Are you sure you are talking about /usr/sbin/traceroute? Point taken. It had been a while since I read the manpage; it uses regular IP packets and manipulates the TTL field. Anyway, from my personal experience, ifconfig/route/ping/traceroute/snmpnetstat are often used together to diagnose problems (or just waste time and bandwidth). Tons of people use ping and traceroute without needing to invoke ifconfig, route, or any form of netstat tool; for instance, when diagnosing routing problems farther away than the interface card in the local machine. If this practice sounds foreign to you, then you either live on a more reliable Internet than I do or are much more indifferent to network problems. -- G. Branden Robinson | A great work of art has never caused any Debian GNU/Linux| social problems. Social problems are [EMAIL PROTECTED] | caused by those trying to protect http://www.debian.org/~branden/ | society from great works of art. pgpQcwGEYM3NT.pgp Description: PGP signature
Re: I propose gazillion packages (LONG)
On Thu, Aug 17, 2000 at 04:34:08AM +0300, Juhapekka Tolvanen wrote: I propose these packages to be added to Debian GNU/Linux. I have proposed them once before, but they are not yet added. I propose you start working on packaging them. -- G. Branden Robinson |Somebody once asked me if I thought sex Debian GNU/Linux|was dirty. I said, It is if you're [EMAIL PROTECTED] |doing it right. http://www.debian.org/~branden/ |-- Woody Allen pgp2iCpG5Z3dG.pgp Description: PGP signature
Re: Is dh_installxfonts okay?
On Thu, Aug 17, 2000 at 10:52:55AM +0900, Atsuhito Kohda wrote: 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? You are correct. My original implementation was messed up in this respect and the person who wrote dh_installxfonts copied my mistake. This problem in fixed in the XFree86 xfonts-* packages but not, apparently, in dh_installxfonts. What do I misunderstand at all? Nothing yet. :) 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? See version 3.2 of the Debian Policy Manual for an explanation of why packages don't need to edit the XF86Config file. -- 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/ | pgpYKi6nP0kSn.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
Anyway, from my personal experience,
ifconfig/route/ping/traceroute/snmpnetstat are often used together to
diagnose problems (or just waste time and bandwidth).
Tons of people use ping and traceroute without needing to invoke ifconfig,
route, or any form of netstat tool; for instance, when diagnosing routing
snmpnetstat will show the routing table of routers that export it
through SNMP. My point is that route in this case is simply a
special case of snpmnetstat.
--
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
ITP ITU: gconf
Hello. I've packaged GNOME GConf and I'm maintaining it. My package is based on Vincent's Quick dirty gconf package :P I'm intent to upload, if Vincent won't do it. Description: GConf is a configuration database system, functionally similar to the Windows registry but lots better. :-) It's being written for the GNOME desktop but does not require GNOME; configure should notice if GNOME is not installed and compile the basic GConf library anyway. -- Takuo Kitame [EMAIL PROTECTED]
Re: Bug tracking system and testing distribution Re: Potato now stable
Joey Hess writes: 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. So, what is the policy to do with a package for the testing distribution, if there is an important bug? Do you remove the package unconditionaly or do you try investigate (like in the rc buglist) if the bug really applies? C
Re: I propose gazillion packages (LONG)
On Thu, 17 Aug 2000 04:34:08 +0300 (EEST) JT == Juhapekka Tolvanen [EMAIL PROTECTED] wrote... JT First I'd like to tell, that I don't subscribe to debian-devel, but I can JT read its archives from WWW. And I am not a Debian developer. JT I propose these packages to be added to Debian GNU/Linux. I have proposed them JT once before, but they are not yet added. [...] JT Gnome-db: JT http://www.gnome.org/gnome-db/ It's already in Debian (woody). Regards. -- Takuo Kitame [EMAIL PROTECTED]
Re: Office Suite for Debian Linux
On Wed 16 Aug 2000, Peter S Galbraith wrote: Sam Sim wrote: Dear Debian Linux, I am familiar with you operating system and wanted to contact you. Wow. How familiar can he be? Yeah, just what I was thinking. we will be in your area towards the end of September. I would like briefly stop by your offices I wonder how he's going to be in dozens of countries across the world towards the end of September :-) This is so clearly a standard ploy to attract business; if someone responds, he goes to where ever the offices happen to be. Should this be considered spam? As far as I'm concerned, it's unsollicited commercial email, thus spam. 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/
Re: I propose gazillion packages (LONG)
On Thu 17 Aug 2000, Juhapekka Tolvanen wrote: I propose these packages to be added to Debian GNU/Linux. I have proposed them once before, but they are not yet added. I think you should research a bit better. On browsing your list, I saw at least two packages that I already have installed: boxes and deroff. I'm sure there are more. But otherwise, some are probably good suggestions. 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/
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: 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. Any user who has a legitimate reason to run ifconfig is a system administrator, and thus should have /sbin and /usr/sbin in his path. A user who is running ifconfig out of curiosity is not a systems administrator, and does not need to have it in his path. --Adam
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 03:27:12AM -0400, Adam McKenna wrote: Any user who has a legitimate reason to run ifconfig is a system administrator, and thus should have /sbin and /usr/sbin in his path. Facilities like /etc/login.defs do discriminate to this fine degree. They know two kinds of user, the ordinary kind and root. They set the path accordingly. With growing attention on capabilities, et al, are we going to tell all Debian users that we only support system administrators who have root? This seems short-sighted and contrary to trends in Unix system administration. A user who is running ifconfig out of curiosity is not a systems administrator, and does not need to have it in his path. How do you define curiosity? Running commands at random, or trying to diagnose a problem so as to send an intelligent problem report to the responsible personnel? -- 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/ | pgpVx4PJy5k5e.pgp Description: PGP signature
Re: Bug tracking system and testing distribution Re: Potato now stable
Christoph Martin wrote: So, what is the policy to do with a package for the testing distribution, if there is an important bug? Do you remove the package unconditionaly or do you try investigate (like in the rc buglist) if the bug really applies? Well if I were AJ I would just mechanically assume critical bugs are really critical, placing the onus on the package maintainer or any other interested parties to correct the status if it happens to be wrong. -- see shy jo
Re: Is dh_installxfonts okay?
Branden Robinson wrote: You are correct. My original implementation was messed up in this respect and the person who wrote dh_installxfonts copied my mistake. This problem in fixed in the XFree86 xfonts-* packages but not, apparently, in dh_installxfonts. It is now. -- see shy jo
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 02:38:55AM -0500, Branden Robinson wrote: On Thu, Aug 17, 2000 at 03:27:12AM -0400, Adam McKenna wrote: Any user who has a legitimate reason to run ifconfig is a system administrator, and thus should have /sbin and /usr/sbin in his path. Facilities like /etc/login.defs do discriminate to this fine degree. Do you mean, do not discriminate? They know two kinds of user, the ordinary kind and root. They set the path accordingly. It's called .bash_profile. With growing attention on capabilities, et al, are we going to tell all Debian users that we only support system administrators who have root? This seems short-sighted and contrary to trends in Unix system administration. Branden, you have a fantastic ability for rewording other people's statements. I suppose we should tell Debian users that only users who know how to modify their PATH will be able to run binaries in /sbin and /usr/sbin without typing the full path. A user who is running ifconfig out of curiosity is not a systems administrator, and does not need to have it in his path. How do you define curiosity? Running commands at random, or trying to diagnose a problem so as to send an intelligent problem report to the responsible personnel? I don't want anyone who doesn't know how to modify his path troubleshooting a system I admin. They're likely to misdiagnose the problem, overreact to the problem, or perhaps even assume a problem where none exists. At an old job, we once had a user complaining that his network wasn't working because he couldn't ping www.microsoft.com, not knowing that microsoft blocks ICMP echo requests. --Adam
ITP: tct (The coroner's toolkit)
Package: tct Priority: optional Section: web Description: The coroner's toolkit A set of low-level (read dangerous) tools which can be used to help reconstruct a partial event log after a break-in, and to retrieve deleted files. Usually you need to have installed it before you need to restore a file. Homepage: http://www.fish.com/tct License: Parts are IBM Public License v1 (http://www.fish.com/tct/LICENSE) and the rest is a very slightly-modified BSD license (http://www.fish.com/tct/COPYRIGHT). If it transpires that this mix of licenses is incompatible with Debian (main) I shall withdraw my ITP. I'm in the NM queue -- would anybody be so good as to sponsor me for this? Thanks, Andrew Stribblehill Systems Programmer, IT Service, University of Durham, England
Re: ITP: freeswan
On Wed, Aug 16, 2000 at 11:17:36AM +0200, Rene Mayrhofer wrote: 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. Sounds good. Can you bug upstream to include support for other authentication methods eg SecureID? I'm stuck with a Windows IPsec client until SecureID is supported. KAME (on BSD) doesn't appear to do it either. thanks, Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: ITP: freeswan
Hamish Moffatt wrote: Sounds good. Can you bug upstream to include support for other authentication methods eg SecureID? I'm stuck with a Windows IPsec client until SecureID is supported. KAME (on BSD) doesn't appear to do it either. SecureID is really in another layer of authentication. Freeswan is about authenticating hosts (among other things), not authentication of processes or people. Cheers, Remco
Yet Another Debian logo buttons
Hello. I've influenced by Mr. Craig Small's and created yet another Debian logo buttons. (csmall's are at http://www.debian.org/~csmall/). I put mine at http://www.debian.org/~kitame/ How about this? Thanks. -- Takuo Kitame [EMAIL PROTECTED]
Broken bootable SPARC CD#1, and why this happened
I've gotten reports that the ISO for CD#1 on sparc is completely broken. Although the packages and dist files are there, the CD will not boot, since almost none of the boot1 files are on the image. Now I could blame this on Phil, who created the images, but that wouldn't be right, since he can't be expected to know what a bootable sparc image looks like, nor does he even have a sparc to test this on. I could blame myself, but the fact is the image was not created right (it needs to be done as either root, or under fakeroot, which requires the *entire* process be done in a single session, not multiple fakeroot incantations, which might be the cause here), and I could not have been expected to download 650megs over my 33.6k modem within the few hours timeframe that these things were created and distributed under. I could blame... Well, you get the point. I don't want to place blame. I just don't want to see this shit happen again. Here's what I want to see next time (2.2 r1): 1) First of all I think the CD's themselves need a sub revision. Obviously if we were to create a new CD image set just for sparc, we can't call it 2.2 r0 since there wouldn't be any way to designate it from the original broken ones. We can't call it 2.2 r1, since it really isn't, and the dist hasn't changed, just the image. So maybe the CD's need to be labeled like 2.2 r0 cdv0 (for CD Revision), and in this case we could have made 2.2 r0 cdv1 for sparc to fix this. 2) Next time we create some very important images, I think one person needs to be designated responsible for testing images prior to release. This requires one of the following: a) The person download them, burn them, and test an install or two. Verify certain points (maybe a checklist...). b) If the designated person cannot do this, they can opt to pay for images to be shipped to them (Phil, is this too much to ask a volunteer? :), then test them. We have to remember, vendors are burning these CD's almost as soon as we make them available. WE are costing them money when we fuck up, and it isn't thre fault because they expect these things to work when we make them available. 3) After each arch is tested, that arch is released, independent of the other archs. That way we don't slow up everyone else because of slow testers. 4) From here, things should be handled a lot better AFA mirroring (before being made world readable to the public), but I'll leave that to the debian-cd folks to decide how to make that better. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
RTP: xlHtml
It's a converter XLS-HTML, XLS is used by some proprietery software from the Dark Side... http://www.xlhtml.org/xlHtml-0.2.7.2.tar.gz Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. Please always Cc to me when replying to me on the lists.
Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 06:31:04AM -0400, Ben Collins wrote: Well, you get the point. I don't want to place blame. I just don't want to see this shit happen again. Here's what I want to see next time (2.2 r1): Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. YMMV. 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 pgp2uoHRX1qJO.pgp Description: PGP signature
Re: Broken bootable SPARC CD#1, and why this happened
Ben Collins [EMAIL PROTECTED] writes: I could blame myself, but the fact is the image was not created right (it needs to be done as either root, or under fakeroot, which requires the *entire* process be done in a single session, not multiple fakeroot incantations, which might be the cause here), and I could not have been expected to download 650megs over my 33.6k modem within the few hours timeframe that these things were created and distributed under. A couple if nits to pick: Firstly, I did build them under fakeroot. (admittedly there were some images that I forgot to do that for for a while, but they were not linked to the 2.2_rev0 tree IIRC, and if they were, they certainly were not accompanied by a signed MD5SUMS file). Are we talking about the ones that match the signed MD5SUM? Secondly, if you'd downloaded the TC3 images, you should have been able to rsync the new image in about 2 hours (or possibly less) over a 33.6k modem. If the official CDs really are broken, then I imagine the TC3 ones were too. Is that the case? How come we didn't spot that? If we did spot that, and it passed me by, then I'm sorry, but knowledge like this needs to be encapsulated in debian-cd, so my near infinite capacity to screw things up gets little room for manoeuvre. We need a root check for sparc builds in the debian-cd Makefile so that it screams about not being able to make bootable CDs (because I'm afraid expecting me to remember details like that is just going to mean this keeps happening, because this stuff generally gets done too late at night) Other than that, I agree with you. Cheers, Phil.
Re: ITP ITU: gconf
On Thu, 17 Aug 2000, Takuo KITAME wrote: Hello. I've packaged GNOME GConf and I'm maintaining it. My package is based on Vincent's Quick dirty gconf package :P I'm intent to upload, if Vincent won't do it. Please go ahead ;) Hint: gconf-0.8 is needed by the preview version of Nautilus ;) Cordialement, -- Les politiciens, c'est comme les couches bébés; il faut les changer régulièrement, et ce, pour les mêmes raisons!
Bug#69314: general: pdksh on cdimage.debian.org binary-i386-2.iso seems corrupt.
Package: general Version: 2817 Severity: important I rsynced binary-i386-2.iso from cdimage.debian.org and the ISO image itself passes the MD5SUMS check; this proves that the problem I discovered is something everybody will encounter when they get their CDs from CD distributors who burn Debian CD using the official CD image from that site. PDKSH dists/potato/main/binary-i386/shells/pdksh_5.2.14-1.deb does not pass md5sum test with the md5sum.txt on the CD. I compared it with a copy I obtained from Debian package mirrors, and it seems to be corrupt -- System Information Debian Release: 2.2 Kernel Version: Linux siamese 2.2.17pre16-RAID.ss.e820-1f92bf0 #1 Thu Aug 10 23:20:35 PDT 2000 i586 unknown
ITP: frontbase
Yes, I know it's totally non-free and binary only, but I like database systems. :-) http://www.frontbase.com Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: ITP ITU: gconf
In article [EMAIL PROTECTED], VR == Vincent Renardias [EMAIL PROTECTED] wrote... VR On Thu, 17 Aug 2000, Takuo KITAME wrote: Hello. I've packaged GNOME GConf and I'm maintaining it. My package is based on Vincent's Quick dirty gconf package :P I'm intent to upload, if Vincent won't do it. VR Please go ahead ;) Thanks. Well, How about gnome-vfs and w3c-libwww ? VR Hint: gconf-0.8 is needed by the preview version of Nautilus ;) Yes I know. also gnome-vfs and w3c-libwww are needed. -- Takuo Kitame [EMAIL PROTECTED]
Implementing testing (was: Re: Potato now stable)
Hello world, So, on -devel-announce, I mentioned: * New testing distribution This is a (mostly finished) project that will allow us to test out distribution by making it sludgey rather than frozen: that is, a new distribution is added between stable and unstable, that is regularly and automatically updated with new packages from unstable when they've had a little testing and now new RC bugs. (Anthony Towns; debian-devel) It's basically ready to be stuck in the archive now, as far as I can tell, but since it's not exactly a trivial change, it's probably time to discuss it a bit more. The basic idea, simplified immensely, is to address this problem: * Testing updates to frozen is suboptimal: updates go into incoming, wait there for a while, get added to frozen, we discover they introduce as many release critical bugs as they solve, rinse, repeat. The wait for a while part is particularly suboptimal, but without it, it's not really a freeze. The current way we do things is basically to build a new package, hope it works as advertised, and let people test it. If it doesn't work, we repeat as many times as necessary, or eventually just throw the package out. A better way to handle this, which I suspect everyone's just spontaneoulsy reinvented as the read the above, is to try to keep around a previous version of the package that was usable. That way if the new packages don't work, we can just keep the old one rather than having to throw it out entirely. That, essentially, is the point of the testing distribution: to contain a consistent set of the most recent believed-to-be-reliable packages. Some subheadings follow. Why call it testing? One thing that the freeze is really bad at is fixing normal bugs. The point of packages in testing is not that they should be perfect or bug-free, just that they should be usable. There's a lot of difference between what we'd like to release (0 bugs, many many features) and what we'll accept for release (~0.005 RC bugs :), and this is really where beta testing should fit in. It also sorts nicely compared to stable and unstable :) What does acceptable for release mean? For one thing, it means the packages are all consistent: if libgtk1.2.7 is in the distribution, none of the packages should be depending on libgtk1.2.8. For another, it means packages shouldn't have any release critical bugs. It also means a package should be at the same version across all architectures it's present in [0]. It also means the maintainer of the package should be relatively happy with it. It means the package shouldn't have any release critical bugs: that is, no security holes [1] (critical or grave), the package shouldn't crash your system (critical), it should be usable for someone on the planet at least (grave), and it shouldn't violate policy too severely, by having incorrect dependencies, or no copyright, eg [2] (important). Note that what I'm writing here is what I think's best, and what's implemented. If there's an objectively better way of doing things, well, that's why I'm posting. [3] Okay. So the next question you're probably asking yourselves is how does it work. Well, you don't have to ask yourself, you can ask me. Here's a summary. Archive Layout ~~ As package pools aren't close to being rolled out, I'm opting for as minor a change as possible (which isn't really very minor). So instead of two distributions, stable and unstable, we have three distributions, stable, testing and unstable. As usual packages get uploaded via dinstall to unstable, broken and buggy however they might be. Eventually, by some automated process yet to be described, they eventually get added to the testing distribution. After some amount of time testing gets frozen, fixed, and released (the theory being that this will be easier than freezing unstable, fixing it, and releasing). So basically we'd have: unstable-- bleeding edge, broken, etc testing -- leading edge, maybe buggy, but working stable -- static, usable, going out of date Automated Process? ~~ So pretty much all the policy is encoded in some automated process which updates testing. It works at the moment, basically as follows: 1. First, it loads up all the Sources and Packages files in testing and unstable. 2. It compares and contrasts them, working out what source packages are new in unstable. 3. For each of these new source packages it checks: a. That the package has had two weeks of testing, or it's a medium or high urgency package (and has had either one week, or three days of testing). b. That each binary
Re: policy changes toward Non-Interactive installation
On Tue, Aug 15, 2000 at 07:19:09AM -0700, Joey Hess wrote: If you don't want to download realplayer right now, why are you installing the package? E.g., you might have a slow network connection and want to deal with the download later. (So you can finish installing everything else without pausing for an hour to download realplayer.) -- Mike Stone pgpSna8qGpmGP.pgp Description: PGP signature
Re: I propose gazillion packages (LONG)
On 17 Aug 2000, Juhapekka Tolvanen [EMAIL PROTECTED] wrote: 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. I think this is a good idea. Thanks for the pointer, I might do an ITP on this in the next time... Let's see how it turns out (actually I'm a bit stressed at my work). Get back to me on this topic in some weeks time, if you don't hear anything. Gnome-db: http://www.gnome.org/gnome-db/ Needed by gASQL. Already packed. It's package-names are a bit strange to me, though: [EMAIL PROTECTED]:~ grep-available -FSource -sPackage gnome-db Package: libgda-dev Package: libgda0 Have fun! Alfie -- (1) Everything depends. (2) Nothing is always. (3) Everything is sometimes.
Re: ITP ITU: gconf
On Thu, 17 Aug 2000, Takuo KITAME wrote: In article [EMAIL PROTECTED], VR == Vincent Renardias [EMAIL PROTECTED] wrote... VR On Thu, 17 Aug 2000, Takuo KITAME wrote: Hello. I've packaged GNOME GConf and I'm maintaining it. My package is based on Vincent's Quick dirty gconf package :P I'm intent to upload, if Vincent won't do it. VR Please go ahead ;) Thanks. Well, How about gnome-vfs and w3c-libwww ? I'll upload a new gnome-vfs package as soon as you've uploaded gconf-0.8 (the package is ready, it's just waiting for a decent version of gconf). As for w3c-libwww, I'm not sure... I have a package ready, but it's really a old and unmaintained software and I just hope the Nautilus developpers will remove the dependency on it (as the Evolution developpers just did). Cordialement, -- Les politiciens, c'est comme les couches bébés; il faut les changer régulièrement, et ce, pour les mêmes raisons!
Re: I propose gazillion packages (LONG)
On Thu, Aug 17, 2000 at 04:34:08AM +0300, Juhapekka Tolvanen wrote: 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. Stephan Helma packaged varkon under my sponsorship, but license problems at that time prevented it from getting included in potato. He probably will (cc'ing him) revive the efforts, now that its source is (almost) fully released. Gopal. -- Gopal Narayanan [EMAIL PROTECTED] [EMAIL PROTECTED] Debian GNU/Linux Developer Dept. of Astronomy, University of Massachusetts, Amherst
Re: Intent To Split: netbase
On Thu, 17 Aug 2000, Herbert Xu wrote: snmpnetstat will show the routing table of routers that export it through SNMP. My point is that route in this case is simply a special case of snpmnetstat. Most routers have a security arrangement so that the information is not public. Jason
Re: Broken bootable SPARC CD#1, and why this happened
Hi, a side note, but I think an important one. Ben Collins wrote: We have to remember, vendors are burning these CD's almost as soon as we make them available. WE are costing them money when we fuck up, and it isn't thre fault because they expect these things to work when we make them available. Uh, it is entirely their fault if they don't test what they ship prior to shipping. Debian is not making guarantees about the usuability of the stuff we distribute. This said, I think you have good ideas how to improve the process. Thanks, Marcus
Re: ITP: Moscow ML - An implementation of standard ML.
Le 2000-08-16 01:55:59 -0300, Nicolás Lichtmaier écrivait : 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. As far as I remember, Objective CAML, which is supposed to be an advanced version of CAML light, has been moved to LGPL. But I don't think the CAML light licence has changed. -- Jean-Philippe Guérard
Re: Broken bootable SPARC CD#1, and why this happened
Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil.
WG: Broken bootable SPARC CD#1, and why this happened
Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Philip Hands [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:11 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: Re: Broken bootable SPARC CD#1, and why this happened Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: ITP: Moscow ML - An implementation of standard ML.
Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:02 An: Nicolás Lichtmaier Cc: Torsten Landschoff; debian-devel@lists.debian.org Betreff: Re: ITP: Moscow ML - An implementation of standard ML. Le 2000-08-16 01:55:59 -0300, Nicolás Lichtmaier écrivait : 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. As far as I remember, Objective CAML, which is supposed to be an advanced version of CAML light, has been moved to LGPL. But I don't think the CAML light licence has changed. -- Jean-Philippe Guérard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: Broken bootable SPARC CD#1, and why this happened
Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:36 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: WG: Broken bootable SPARC CD#1, and why this happened Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:Philip Hands [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:11 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff:Re: Broken bootable SPARC CD#1, and why this happened Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: ITP: Moscow ML - An implementation of standard ML.
Not For me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:37 An: debian-devel@lists.debian.org Betreff: WG: ITP: Moscow ML - An implementation of standard ML. Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:[EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:02 An: Nicolás Lichtmaier Cc: Torsten Landschoff; debian-devel@lists.debian.org Betreff:Re: ITP: Moscow ML - An implementation of standard ML. Le 2000-08-16 01:55:59 -0300, Nicolás Lichtmaier écrivait : 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. As far as I remember, Objective CAML, which is supposed to be an advanced version of CAML light, has been moved to LGPL. But I don't think the CAML light licence has changed. -- Jean-Philippe Guérard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent To Split: netbase
On 16-Aug-00, 23:43 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote: What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. Obviously you haven't typed the actual path to traceroute in quite a while. Exactly. I put /sbin in my path and stopped worrying about it. There is policy on this topic. We say we will comply with the FHS. (We should probably say we will be compatible instead, else our distribution is literally riddled with FHS violations.) I think the location of traceroute is ambiguous. (I also agree that the FHS is itself confused on this topic, as has been pointed out elsewhere.) Steve
WG: Broken bootable SPARC CD#1, and why this happened
Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:41 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: WG: Broken bootable SPARC CD#1, and why this happened Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:[EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:36 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff:WG: Broken bootable SPARC CD#1, and why this happened Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Philip Hands [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:11 An: debian-cd@lists.debian.org; debian-devel@lists.debian.org Betreff: Re: Broken bootable SPARC CD#1, and why this happened Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). I know it's been a pain in the arse, but I think I actually made the right decision in leaving it as it was for the duration. Admittedly, open died the moment I started building CDs, but once rebooted (unfortunately 8 hours later, waiting for someone to fsck /), it's actually stood up to the load reasonably well all things considered (2 30 minute outages), whereas we could have done a panic replacement with untested hardware, and found ourselves without anything. Anyway, once it's plugged into it's 100Mbit LAN, and is an Athlon 650, rather than a P166, these problems should be behind us, with a bit of luck. Another thing that would help is getting this stuff more automated and common. While boot-floppies and kernels and cd images are all being made by one or two people who know how to tweak the settings correctly, we're going to keep having problems like this. Much better, IMO, to setup cdimage.debian.org (or similar) to build a new set of CDs once a week, automatically, ideally straight from debian-cd.deb. Nice idea, but it's taken until very recently to get the scripts into this state, with constant feedback -- if we were unable to tweak the scripts to make them work, they'd never work as well as they do. And then we find that they still don't work ;-) More directly though, we should be able to very easily setup some automated tests to make sure this doesn't happen again. After building the CDs, mount them over loopback and checking device files have correct ownerships and permissions, or check that various packages in base are all on CD#1, or similar. Now this is a very good idea. The more checking and testing we can offload from volunteers onto machines, the better. We can always get more machines, getting more people with the requisite clues and free time is much harder. It's almost impossible to remember all the little things that might go wrong as well, so encapsulating that knowledge in a regression test suit is definitely the way to go. The fact that the CDs always need to be built in the early hours doesn't help. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: floppy disk
Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:41 An: debian-alpha@lists.debian.org Betreff: WG: floppy disk Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:[EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:38 An: debian-alpha@lists.debian.org Betreff:WG: floppy disk Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Marcus Williams [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 16:33 An: Andrew MacNamara; debian-alpha@lists.debian.org Betreff: RE: floppy disk If the light is on continuously it usually means you've put the floppy cable the wrong way round - it doesnt break anything in itself, but the OS wont be able to use it. If it doesnt work the other way round it still could be a broken cable or controller - not much help really but at least you can tell whether you've got the cable around the right way :-) Marcus -- M J Williams @ work - Quintic Ltd, Cambridge, UK mailto:[EMAIL PROTECTED] -- http://www.onq2.com -Original Message- From: Andrew MacNamara [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2000 3:13 PM To: debian-alpha@lists.debian.org Subject: floppy disk [snip] When I put it in one way, the drive light never comes on at all. When I put it in the other way, the drive light comes on when the system boots up, and it stays on -- it never goes off. [snip] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: Netscape Probs
Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:41 An: debian-alpha@lists.debian.org Betreff: WG: Netscape Probs Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:[EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:37 An: debian-alpha@lists.debian.org Betreff:WG: Netscape Probs Not for me Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Paul Slootman [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 16:57 An: debian-alpha@lists.debian.org Betreff: Re: Netscape Probs On Sat 15 Aug 2020, Steve Hiller wrote: run netscape I get... /usr/bin/netscape: /usr/lib/netscape/netscape-navigator: No such file or directory even though the file exists. I have tried just running the netscape-navigator binary file but I get the same no such file or dir message. Oh ya. This is on a You *do* have the Digital Unix (or whatever it's called this month) shared libraries installed? 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WG: ITP: Moscow ML - An implementation of standard ML.
Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:42 An: debian-devel@lists.debian.org Betreff: WG: ITP: Moscow ML - An implementation of standard ML. Not For me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von:[EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am:Donnerstag, 17. August 2000 17:37 An: debian-devel@lists.debian.org Betreff:WG: ITP: Moscow ML - An implementation of standard ML. Not for me... Mit freundlichen Grüßen Annette Schweigardt AOK BD Heidenheim Gesundheitszentrum Daimlerstraße 6 89518 Heidenheim Tel: (07321) 314 250 Fax: (07321) 314 252 EMail: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Gesendet am: Donnerstag, 17. August 2000 17:02 An: Nicolás Lichtmaier Cc: Torsten Landschoff; debian-devel@lists.debian.org Betreff: Re: ITP: Moscow ML - An implementation of standard ML. Le 2000-08-16 01:55:59 -0300, Nicolás Lichtmaier écrivait : 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. As far as I remember, Objective CAML, which is supposed to be an advanced version of CAML light, has been moved to LGPL. But I don't think the CAML light licence has changed. -- Jean-Philippe Guérard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy changes toward Non-Interactive installation
On 16-Aug-00, 02:11 (CDT), Joey Hess [EMAIL PROTECTED] wrote: Belive it or not, I know how to safely manage temp files and protect sensitive information with unix permissions. I know you do, Joey, but my concern is that since the permission violation occurs in the backend, when the backend gets replaced by something else that the security by be inadvertently dropped. Would it make sense for the front-end(s) check the effective userid and refuse to run if it's not 0? Steve
Re: WG: Broken bootable SPARC CD#1, and why this happened
[EMAIL PROTECTED] writes: Not for me... Life is nice isn't it? (And then stop sending this Not for me-answers all the time or something bad could happend) -- Peter
Re: Intent To Split: netbase
Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Marcus We can put everything in /bin and make /sbin a link to /bin. Marcus This way the utilities the FHS liste can be found in /sbin, Marcus but there physical place is elsewhere. This does not violate Marcus the standard. I still think there is merit in having a separate path component for things that are not very useful when I do not have my sysadmin hat on. Indeed, there are a number of machines on which I do not have priviledges, and there is a special division for admins who take strong exeption to things being mucked around behind their backs. On these machines I do not need ifconfig -- and I know where to get them should I need them for diagnostics -- I just pick the phone and call someone to have the problem resolved. I think there is a large contingent of users out there who are not even part time sysadmins. Why is it so hard for sysadmins and part tiem sysadmins to enhance their path? I think that FHS compliance, and uniformity with other Linux distributions is important as well. manoj -- Engineering: How will this work? Science: Why will this work? Management: When will this work? Liberal Arts: Do you want fries with that? 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: Intent To Split: netbase
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 14.08.00 in [EMAIL PROTECTED]: John == John Goerzen [EMAIL PROTECTED] writes: No real reason? Only one package can listen in on port 25, and John There is no real reason that all must listen on port 25. Then you and I have very different opinions on what a working MTA is. Indeed, the SMTP RFC's differ with your opinion as well AFAIK most MTAs can be convinced to use a different port. I wonder why that is? I know that Exim has support to talk to a SMTP server on an arbitrary port. I see no reason to assume other MTAs can't do the same. I wonder why that is? I have a machine running two different Exim konfigurations at the same time, one not involving listening on any port. Separate spools, separate logs. I wonder why one of those couldn't be a different MTA? As for NNTP, you've heard of port nntps? And then there's the option of running server-to-server NNTP on arbitrary ports. John These aren't real reasons at all. Given that, you have a curious definition of ``real''. Unfortunately, I do not think I find your definition of real very interesting. His seems to be about the same as mine. Your real reasons boil down to I don't know why you'd want to do that, which is a piss-poor reason for *anything*. One should optimize for the most common case. I think people The rule should be: make easy things easy, and make hard things possible. who can maneuver around the port numbers can also recompile or use dpkg -x effectively. There's a rather big difference between putting demon_smtp_port=1234 into a config and those other options. I am unsure that the results are quite worth the effort that needs be expended. One rather common case with MTAs is switching from one to another with a non-empty spool. Rather hard when they don't coexist peacefully. You don't even need alternate ports for that - only the new MTA needs to actually run a SMTP listener, the old one only needs a queue runner. MfG Kai
Re: Intent To Split: netbase
[EMAIL PROTECTED] (Adrian Bridgett) wrote on 16.08.00 in [EMAIL PROTECTED]: 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. Nothing, if the definition of user tools matches the FHS /bin - /sbin distinction, which says that if users ever run the thing, it belongs in /bin. As an advanced user, I always put /sbin and /usr/sbin in my PATH, whatever the unix I'm on. And the FHS *explicitely* says you shouldn't have to. People who know about ifconfig should know enough to add /sbin and /usr/sbin to their PATH IMO. And the FHS *explicitely* says they shouldn't have to. MfG Kai
Re: Intent To Split: netbase
[EMAIL PROTECTED] (Jacob Kuntz) wrote on 15.08.00 in [EMAIL PROTECTED]: Clint Adams ([EMAIL PROTECTED]) wrote: No real reason? Only one package can listen in on port 25, and Only one package can listen on port 25 of one IP. It is possible to have multiple packages listening on different ports or different IPs. hadn't thought of that. but once again, is there any benefit to that at all? will the efort required by the maintainers to get this working properly (including reading bug reports) ever balance against the tiny number of people that would use this feature? anyone that has a reason can certianly set this up themselves. *Is* there significant effort needed from the maintainers? At least for the case of Exim, I suspect the effort reduces to a trivial edit of debian/control iff you accept that people installing more than one MTA have to create a sane configuration manually. And I suspect it's not really different for other MTAs. MfG Kai
Re: Potato now stable
[EMAIL PROTECTED] (Jason Gunthorpe) wrote on 14.08.00 in [EMAIL PROTECTED]: On Mon, 14 Aug 2000, Joey Hess wrote: You know, if apt could only support Reccommends, task packages could be I don't care for this much, it breaks the model that apt-get follows, it Well, I'd *very very much* like apt-get to be able to do *something* with Recommends: and Suggests:. Currently, I either have to go to dselect just to see what Recommends: I'm missing, or else do some pretty incredible shell pipelines to handle Suggests: with apt-get. Not good. Now I can certainly accept that it'd be a bad thing to change apt-get's default behaviour, but that doesn't mean some reasonable support could not be done with some command line switches. I think the interesting functionality would be as follows: for (A) Recommends: or (B) Recommends:+Suggests:, for (i) a list of packages given on the command line or (ii) all installed packages, or (iii) all newly-to-install-or-upgrade packages (that is, recursively including packages which would be installed by a Recommends:/ Suggests:), list and optionally install those packages, the same way you'd do with extra Depends:. MfG Kai
Re: Intent To Split: netbase
Joey == Joey Hess [EMAIL PROTECTED] writes: 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. Joey I dont follow this. 'echo *' can tell me what files are in a directory; Joey a system without ls in path is still broken. You are missing the point. The point is not that if *any* arcane alternative exists we should move a program out of /bin; the pooint is that if a progrom in sbin has a usage that a normal user _may_ find interesting is not enough reason to move it out of sbin, espescially if there are other mehtods of accomplishing the same using programs already in /bin. Joey I don't see how mount is much different. Regular users *often* Joey want to mount/unmount/check mount status of removable Joey media. And it's in /bin now, so isn't this a red herring Joey anyway? We are trying to determine rationale, and thus even things that are in their appropriate place in the file system are fair game for analysis. The point I was making is that trying to find mounted file systems is not the reason to move mount out of /sbin. The user mountable removeable media, on the other hand, is an excellent reasdon, and thus mount is in /bin. The /bin vs /sbin distinction is purely about avoiding inconvenience and/or confusion for the normal user. The sole thing accomplished by putting some things in /sbin rather than /bin is that if you don't put /sbin in your path, you won't see those things. I myself, probably like most people on this list, rarely notice the distinction since I do have /sbin and /usr/sbin in my path. But the idea is that the average user won't have /sbin or /usr/sbin in their path, and so the programs in those directories can have simple names for the convenience of those who do use them, without an average user either accidentally running one because it has a simple name they confused with something else, or getting a lot of confusing possibilities in a command completion list. The things that we do put in /sbin, for the same reasons, we expect that the average user will not use them and might be confused by encountering them. For example, mkfs and fsck and so forth are in /sbin. Anyone can use these, on a file or on a device they have permissions for. It's not that we expect only root to use these, but that we expect anyone who wanted to use them to probably know enough about the system to be root (or at least enough more than the average user that they can handle putting /sbin in their path). manoj -- The sooner all the animals are extinct, the sooner we'll find their money. Ed Bluestone 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: Intent To Split: netbase
On Thu, Aug 17, 2000 at 10:42:57AM -0500, Steve Greenland wrote: On 16-Aug-00, 23:43 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote: What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. Obviously you haven't typed the actual path to traceroute in quite a while. Exactly. I put /sbin in my path and stopped worrying about it. Well, technically, no, you didn't. You put something else in your path and stopped worrying about it. -- G. Branden Robinson |Convictions are more dangerous enemies Debian GNU/Linux|of truth than lies. [EMAIL PROTECTED] |-- Friedrich Nietzsche http://www.debian.org/~branden/ | pgpuPRn5hpt6n.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden There is policy on this topic. We say we will comply with Branden the FHS. (We should probably say we will be compatible Branden instead, else our distribution is literally riddled with FHS Branden violations.) Should we not rather make an attempt to get rid of some of those incompatibilities, rather than throwing our hands in disgust and punting on it before we even start? manoj -- Depends on how you define always. :-) Larry Wall in [EMAIL PROTECTED] 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: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Well, keep in mind that Debian has committed itself to Branden FHS-compatibility, not FHS-compliance. This means that we Branden are free to have symlinks standing between a pathname and Branden the inode. We have? That's news to me. == sect1 headingLinux File system Structure/heading p The location of all installed files and directories must comply with the Linux File system Hierarchy Standard (FHS). The latest version of this document can be found alongside this manual or on url id=http://www.pathname.com/fhs/;.footnote pThe Debian distribution currently distributes a draft version of FHS 2.1 because several significant details have changed between the currently released 2.0 version and the to-be-released 2.1 version./p /footnote Specific questions about following the standard may be asked on prgndebian-devel/prgn, or referred to Daniel Quinlan, the FHS coordinator, at email[EMAIL PROTECTED]/email./p/sect1 == You could have fooled me ;-) manoj -- The most delightful day after the one on which you buy a cottage in the country is the one on which you resell it. Brecheux 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: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 04:10:53PM +0100, Philip Hands wrote: Anthony Towns aj@azure.humbug.org.au writes: Well, one thing that'd help would be having a cdimage.debian.org that doesn't crash all the time. That's the main reason we didn't have any time at all to check things, or for Phil to double check things with you as to how things should be done when the first sparc images didn't work. I'm working on it -- open's getting a full body transplant on Tuesday (or thereabouts). Can I ask why the box was so unreliable? We tout our distribution, and Linux presents itself generally, as a rock-solid stable operating system. Why all the crashes? Bad hardware? -- 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/ | pgpzsikaaDBzo.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden On Wed, Aug 16, 2000 at 10:53:51AM -0400, Raul Miller wrote: 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.] Branden I don't think it's feasible for a standards body or a Branden package maintainer to make case-by-decisions on the location Branden of a tool based upon the functionality of every other tool Branden that might provide that functionality. Taken to extremes, no. Branden This would lead to an unstable environment, where the Branden presence of route in bin would justified if and only if Branden nothing else could show you the routing tables. This would I think I disagree here. Instead of laying down the law like this, I would rather leave things fuzzy, and rely on common sense; just because route provides routing information shoul not be enough to move it out of sbin (I am sure one can come up with some reason for moving every single probgram out of sbin, and thus lose all the benefits of the split). Branden also differ on a system-by-system basis as users have Branden different packages installed. Should route go into bin for Branden users that (somehow) don't have netstat installed, but sbin Branden for users that do? It makes no sense. route is in sbin. period. If people wat to see the current routing status, they have two options: a) add /sbin to your path, or type in the full path name b) install netstat. You can't please veryone all the time. In attempting to please the semi-sysadmin power user you are going to remove a feature that benefits the absolute novice. Any semi-sysadmin/power user types should also be knowledegable enough to modify their path variables. Or create an alias. Or a symlink. Indeed, if you use it often enough, _do_ change the path. But do not assume that what is good for you is good for everyone else. Branden In other words, I think the choice of directory should be Branden controlled by factors intrinsic, not extrinsic, to the Branden program in question. To a point. But I think making this an absolute rule is going too far. manoj -- I saw a subliminal advertising executive, but only for a second. Steven Wright 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: Intent To Split: netbase
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. I think it should be in /usr/bin, certainly if it is setuid. So should ping, and mount and umount. It is most annoying if you insert a floppy or cd-rom as a user, read it through a well-known automount point such as /misc/cdrom, and then cannot extract it anymore because: /misc/cdrom is not in /etc/fstab and you are not root - the error message that umount spits out on Linux when a non-root user tries umount and the filesystem does not have the user attribute in /etc/fstab, par force because /misc/cdrom was not listed at all. ifconfig is also necessary for users: A user types telnet blahblah, the system dials out, acquires an IP address, and then the user will want to set the DISPLAY variable on the remote system. If that remote system does not discover automatically, then ifconfig is one way to find out. Many tasks that were traditionally reserved for the administrator are no longer so, or not in all cases. If Linux (Unix) wants to make an impact on end user systems, it has to cater for users which: o know little about how to administrate a Linux system o do not want to know o pay $50 call-out charge for a system administrator o pay $1 a minute for telephone support Such a callout charge may be acceptable if you switch on the system and it tells you the filesystem is corrupt, you should check it. But to extract a CD-Rom ? Would you buy a washing machine where you need to call out an electrician to switch it on ? I know rebooting is a dirty word in the Linux and Unix community, but anything that can with good probability be achieved by rebooting or power-cycling the machine should not require a system administrator. The appropriate commands should have a setuid mode that prevents some of the more obvious ways to create havoc - such as ping fretting on non-root requestetd flood pings. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk * voice: +4420-7594-6912 (day) * fax: +4420-7594-6958 * snail: Thomas Sippel - Dau * Linux Services Manager * Imperial College of Science, Technology and Medicine * The Center for Computing Services * Exhibition Road * Kensington SW7 2BX * Great Britain
Re: Intent To Split: netbase
Kai == Kai Henningsen [EMAIL PROTECTED] writes: Kai AFAIK most MTAs can be convinced to use a different port. I Kai wonder why that is? You are missing the point. How often do these things have to be done? How difficult is it to install two different MTA's as things stand? Kai I know that Exim has support to talk to a SMTP server on an Kai arbitrary port. I see no reason to assume other MTAs can't do Kai the same. I wonder why that is? If you do not know, I do not think you should really be participating in this discussion. If you do know, you perhsaps should not be participating here with this inflamatory stance either. Kai I have a machine running two different Exim konfigurations at Kai the same time, one not involving listening on any port. Separate Kai spools, separate logs. I wonder why one of those couldn't be a Kai different MTA? And how commohn a practice do you think that is? Kai As for NNTP, you've heard of port nntps? And then there's the Kai option of running server-to-server NNTP on arbitrary ports. How common is this? John These aren't real reasons at all. Given that, you have a curious definition of ``real''. Unfortunately, I do not think I find your definition of real very interesting. Kai His seems to be about the same as mine. Your real reasons boil Kai down to I don't know why you'd want to do that, which is a Kai piss-poor reason for *anything*. Bullshit. You have totally missed the point of my message, and have the gall to come in with a cendescending flammage that is ill condusive to any further discussion. Until you show you have the basic understanding of what is called the common case, I have nothing to say to you. manoj and we were too having a reasoably sane discussion until now -- I don't think I'm gonna agree with that. Way too much visual confusion... Larry Wall in [EMAIL PROTECTED] 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: Intent To Split: netbase
Kai == Kai Henningsen [EMAIL PROTECTED] writes: Kai Nothing, if the definition of user tools matches the FHS /bin - /sbin Kai distinction, which says that if users ever run the thing, it belongs in Kai /bin. I think there is a modicum on common sense expetced to be applied here. If a user ever runs fsck, halt, lilo, or any other program in /sbin, should they automatcally move out of there? (note there is not mention of succesfully run). This is a fuzzy are, unfortunately for rules lawyers, and one is supposed to use common sense, a feeling of how often an ordinary user may use a program, whether they really need to, are they wearing a sysadmin hat, and cater to the views of newbies. I also do not think it is going to be possible to please all the people all the time. As an advanced user, I always put /sbin and /usr/sbin in my PATH, whatever the unix I'm on. Kai And the FHS *explicitely* says you shouldn't have to. Umm, I think he is defining himself not to be the common user, and the FHS explicitly says he should. People who know about ifconfig should know enough to add /sbin and /usr/sbin to their PATH IMO. Kai And the FHS *explicitely* says they shouldn't have to. Not quite. (or else quote chapter and verses where the FHS explicitly says anyone who knows about ifconfig does not have to pout /sbin and /usr/sbin in their path (you do know what explicit means, don't you?) manoj == See, this actually runs for me as a user: __ /sbin/lilo -h usage: lilo [ -C config_file ] -q [ -m map_file ] [ -v ... ] lilo [ -C config_file ] [ -b boot_device ] [ -c ] [ -l | -L ] [ -i boot_sector ] [ -m map_file ] [ -d delay ] [ -v ... ] [ -t ] [ -s save_file | -S save_file ] [ -P fix | -P ignore ] [ -r root_dir ] [ -w ] lilo [ -C config_file ] [ -m map_file ] -R [ word ... ] lilo [ -C config_file ] -I name [ options ] lilo [ -C config_file ] [ -s save_file ] -u | -U [ boot_device ] lilo -V == -- If we see the light at the end of the tunnel, it's the light of an oncoming train. Robert Lowell 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: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:39:23AM -0500, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Well, keep in mind that Debian has committed itself to Branden FHS-compatibility, not FHS-compliance. This means that we Branden are free to have symlinks standing between a pathname and Branden the inode. We have? That's news to me. [...] You could have fooled me ;-) Yes, at the time I posted this I misremembered a proposed policy amendement as an accepted one. I think if you catch up on debian-policy you'll see that I have corrected my error. -- G. Branden Robinson |There's nothing an agnostic can't do Debian GNU/Linux|if he doesn't know whether he believes [EMAIL PROTECTED] |in it or not. http://www.debian.org/~branden/ |-- Graham Chapman pgp65zGXR1omP.pgp Description: PGP signature
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:35:31AM -0500, Manoj Srivastava wrote: Should we not rather make an attempt to get rid of some of those incompatibilities, rather than throwing our hands in disgust and punting on it before we even start? Have fun hacking apt. -- G. Branden Robinson |Any man who does not realize that he is Debian GNU/Linux|half an animal is only half a man. [EMAIL PROTECTED] |-- Thornton Wilder http://www.debian.org/~branden/ | pgpumd8nxXlkU.pgp Description: PGP signature
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:48:06AM -0500, Manoj Srivastava wrote: (I am sure one can come up with some reason for moving every single probgram out of sbin, and thus lose all the benefits of the split). Could you remind me what these benefits are again? Pretend for a moment that the FHS doesn't exist and it's entirely up to us. What exactly DO we gain by having some binaries segregated off into sbin? route is in sbin. period. This begs the question. If people wat to see the current routing status, they have two options: a) add /sbin to your path, or type in the full path name b) install netstat. So why isn't netstat in sbin? You can't please veryone all the time. In attempting to please the semi-sysadmin power user you are going to remove a feature that benefits the absolute novice. Again, please tell me what these benefits are. Do you have anything approaching quantifiable data or a testable hypothesis? Any semi-sysadmin/power user types should also be knowledegable enough to modify their path variables. Or create an alias. Or a symlink. Indeed, if you use it often enough, _do_ change the path. But do not assume that what is good for you is good for everyone else. I think a set of rational and intuitive grounds for determining what goes into sbin is good for everyone. ping is in bin, traceroute is in sbin; netstat is in bin, route is in sbin... Branden In other words, I think the choice of directory should be Branden controlled by factors intrinsic, not extrinsic, to the Branden program in question. To a point. But I think making this an absolute rule is going too far. Please identify the extrinsic factors that you think trump the characteristics of the actual program. -- G. Branden Robinson | Religion is something left over from the Debian GNU/Linux| infancy of our intelligence; it will [EMAIL PROTECTED] | fade away as we adopt reason and science http://www.debian.org/~branden/ | as our guidelines. -- Bertrand Russell pgpNSWbbjN139.pgp Description: PGP signature
Re: policy changes toward Non-Interactive installation
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey The package is intended to enforce two invarients: Joey 1) If it is installed, realplayer is installed. Joey 2) If it is installed and current, the current version of realplayer is Joeyinstalled. Right. I just do nt see these invariants being very useful. I would much rather have a mk-realplayer package that helps me create a realplayer-blah.deb; and the invariants are then natural and not artificially imposed. When that realplayer.deb is installed, realplayer is installed (duh), and the version of that package tells me what version I have installed. I can then move the .deb to my local apt-able tree, and all other machines in my environemnt can just install this. the ml-realplayer does not have to be upgrade every time realplayer changes. I can install an older verison of real player if I wish (getting it off a CD, or something). Joey If you don't want to download realplayer right now, why are you Joey installing the package? It is not useful hectoring the user when they report a percieved problem. Perhaps I have a local mirro updated overnight, (with a slow modem, that is the only way to go) and I do not want to wait for a huge realplayer tar ball to download now. Perhaps I did not undertand that I would need a network connection now. Perhaps I had instlled realplayer before, and am happy with it, but I am upgrading my laptop on the plane off my mirror, and do not have a connection. Having realplayer break is not nice. Joey If you don't want to upgrade realplayer right now, why don't Joey you put it on hold? If we can make it so that people do not have to put thigs on hold, would that not be an improvement? Joey The package system allows the things that annoy you to be Joey worked around in a consistent way. Fine. I prefer to remove this annoyance, though. Consider this an ITP for mk-realplayer. I'll probably steal your code rather than re-invent the wheel. Since your package is not really the realplayer binary, I am asking you to rename it to something else, so the package that mk-realplayer creates would not interfere with your installer. manoj -- Then there was the Formosan bartender named Taiwan-On. 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: Broken bootable SPARC CD#1, and why this happened
On Thu, 17 Aug 2000, Ben Collins wrote: I've gotten reports that the ISO for CD#1 on sparc is completely broken. Although the packages and dist files are there, the CD will not boot, since almost none of the boot1 files are on the image. I'd hardly call this completely broken. I guess you can still do upgrades. And I hope there are other possibilities to start the install system besides booting from the CD. [Please tell me the easiest option, or a precise location in some document, to refer to on the cdimage.d.o webpages.] 1) First of all I think the CD's themselves need a sub revision. Obviously if we were to create a new CD image set just for sparc, we can't call it 2.2 r0 since there wouldn't be any way to designate it from the original broken ones. We can't call it 2.2 r1, since it really isn't, and the dist hasn't changed, just the image. So maybe the CD's need to be labeled like 2.2 r0 cdv0 (for CD Revision), and in this case we could have made 2.2 r0 cdv1 for sparc to fix this. Oh please!! Unlike some people like you to believe, there exist no revisions other than CD revisions. There are no FTP revisions. FTP changes _much_ more than the CDs due to many security fixes. An FTP revision indicates the state of the FTP archive whenever new CDs were made (or whenever some people think CDs could be made). About 90% of the time the FTP archive does not any longer match the CDs it is claiming to match. If we counted FTP revisions, 2.1 would be at revision 30 or something. So, a 2.2 r1 revision for new Sparc CDs would be the logical choice. However, I can understand that we would then want a complete series of all architectures, which isn't necessary at this point. Therefore, I'd strongly suggest we'd call it 2.2 r0.1 or maybe better 2.2 r0.5 (I hope we won't need a 0.6 then..) 2) Next time we create some very important images, I think one person needs to be designated responsible for testing images prior to release. This requires one of the following: a) The person download them, burn them, and test an install or two. Verify certain points (maybe a checklist...). b) If the designated person cannot do this, they can opt to pay for images to be shipped to them (Phil, is this too much to ask a volunteer? :), then test them. We have to remember, vendors are burning these CD's almost as soon as we make them available. WE are costing them money when we fuck up, and it isn't thre fault because they expect these things to work when we make them available. I do agree, but... I think you'll have some trouble finding testers for !=i386 who can a-priori say they'll be available whenever the release manager thinks the distro is ready. And then making images takes time, testing them takes time, shipping may take even more time (count at least 4 days for any international shipping unless you want to pay really much). 3) After each arch is tested, that arch is released, independent of the other archs. That way we don't slow up everyone else because of slow testers. Do you want to officially release a distro, say woody, _before_ the CD images are available, or _after_ the images are available? I've personally always opted for the latter. But that would mean the slowest tester is/feels responsible for all the delay. How to handle that? Regards, Anne Bezemer
ITP: w3c-libwww (was: ITP ITU: gconf)
On Thu, 17 Aug 2000 12:59:34 + (GMT) VR == Vincent Renardias [EMAIL PROTECTED] wrote... Well, How about gnome-vfs and w3c-libwww ? VR I'll upload a new gnome-vfs package as soon as you've uploaded gconf-0.8 VR (the package is ready, it's just waiting for a decent version of gconf). Nice. VR As for w3c-libwww, I'm not sure... I have a package ready, but it's really VR a old and unmaintained software and I just hope the Nautilus developpers VR will remove the dependency on it (as the Evolution developpers just did). Humm. But just now, nautilus depends on libwww... I'll upload my libwww package soon. But in near future, if nautilus removed dependency on it, I'll orphan it maybe. ITP: w3c-libwww Package: libwww0, libwww-dev Description: The W3C-WWW library. Libwww is a highly modular, general-purpose client side Web API written in C for Unix and Windows (Win32). It's well suited for both small and large applications, like browser/editors, robots, batch tools, etc. Pluggable modules provided with libwww include complete HTTP/1.1 (with caching, pipelining, PUT, POST, Digest Authentication, deflate, etc), MySQL logging, FTP, HTML/4, XML (expat), RDF (SiRPAC), and much more. The purpose of libwww is to serve as a testbed for protocol experiments. Regards, -- Takuo Kitame [EMAIL PROTECTED]
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 06:54:24AM -0700, Joey Hess wrote: 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? Greetings from a lurking user, me user-hat=on I startef using debian about 3 years ago. One of the first things that I really liked was bash tab completion. I had to guess at commands because I didn't know what they were named but, I guessed that the functionality should be there. One of my first modifications was to add directories of most(all?) executables to my path. I find it _very annoying_ to NOT get tab completion on commands that I now know exist when I am on another system. me user-hat=off me sys-admin-hat=on I now get paid for my knowledge of Gnu/Linux (more specifically Debian). and the majority of the people that I set up systems for are either CS students who need to know as much as possible or simple users of services like email, http, ftp, samba, etc.. Either way, having everything available is prefered. On machines that users shouldn't have these commands I simply don't give them user accounts. On less critical machines, whocares what they do to it, they will learn judicious use eventually. The *evil* user is an extremly rare animal in my arena (academia), at least so far protector-talisman=on. :-) me sys-admin-hat=off Hopefully this info is usefull to this debate, if not I apologize. By the way, kudos to everyone on yet another excellent release of Debian! -- Frisco Rose By any other name, I would smell the same E.O.U. Stud. [EMAIL PROTECTED] [EMAIL PROTECTED] Physics Mathematics Computer Science If all the ipv6 addresses were distributed evenly across the planets surface, there would be roughly 423,354,243,695,259,002,656 per square inch. And, no, I don't know what this has to do with anything.
Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 07:43:48PM +0200, J.A. Bezemer wrote: On Thu, 17 Aug 2000, Ben Collins wrote: I've gotten reports that the ISO for CD#1 on sparc is completely broken. Although the packages and dist files are there, the CD will not boot, since almost none of the boot1 files are on the image. I'd hardly call this completely broken. I guess you can still do upgrades. And I hope there are other possibilities to start the install system besides booting from the CD. [Please tell me the easiest option, or a precise location in some document, to refer to on the cdimage.d.o webpages.] Obviously, any install option that != CD would apply there. Atleast, that would be obvious to me. 1) First of all I think the CD's themselves need a sub revision. Obviously if we were to create a new CD image set just for sparc, we can't call it 2.2 r0 since there wouldn't be any way to designate it from the original broken ones. We can't call it 2.2 r1, since it really isn't, and the dist hasn't changed, just the image. So maybe the CD's need to be labeled like 2.2 r0 cdv0 (for CD Revision), and in this case we could have made 2.2 r0 cdv1 for sparc to fix this. Oh please!! Unlike some people like you to believe, there exist no revisions other than CD revisions. There are no FTP revisions. FTP changes _much_ more than the CDs due to many security fixes. An FTP revision indicates the state of the FTP archive whenever new CDs were made (or whenever some people think CDs could be made). About 90% of the time the FTP archive does not any longer match the CDs it is claiming to match. If we counted FTP revisions, 2.1 would be at revision 30 or something. So, a 2.2 r1 revision for new Sparc CDs would be the logical choice. However, I can understand that we would then want a complete series of all architectures, which isn't necessary at this point. Therefore, I'd strongly suggest we'd call it 2.2 r0.1 or maybe better 2.2 r0.5 (I hope we won't need a 0.6 then..) WTF is the difference? Nothing but a naming scheme. It's still a change, either way you do it, why do you want to nitpick the mechanism? 2) Next time we create some very important images, I think one person needs to be designated responsible for testing images prior to release. This requires one of the following: a) The person download them, burn them, and test an install or two. Verify certain points (maybe a checklist...). b) If the designated person cannot do this, they can opt to pay for images to be shipped to them (Phil, is this too much to ask a volunteer? :), then test them. We have to remember, vendors are burning these CD's almost as soon as we make them available. WE are costing them money when we fuck up, and it isn't thre fault because they expect these things to work when we make them available. I do agree, but... I think you'll have some trouble finding testers for !=i386 who can a-priori say they'll be available whenever the release manager thinks the distro is ready. And then making images takes time, testing them takes time, shipping may take even more time (count at least 4 days for any international shipping unless you want to pay really much). IMO, well worth it to avoid any future problems of this kind. Or is quality second priority, and meeting release dates first? 3) After each arch is tested, that arch is released, independent of the other archs. That way we don't slow up everyone else because of slow testers. Do you want to officially release a distro, say woody, _before_ the CD images are available, or _after_ the images are available? I've personally always opted for the latter. But that would mean the slowest tester is/feels responsible for all the delay. How to handle that? Uh, the official release CD images were not created until after the symlink change. The distribution is released not the CD images. They come after. The testing and release of those needs some time, irregardless of the distribution timeline. We can't opt for hey we released CD's the same DAY!, over dist is released, ISO's are coming soon after some testing. Quality, quality, qualitynot superficial release dates. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
ITP: gopher, gopherd, gopherindex
Hi, I intend to package up the gopher suite from UMN, together with my patches to it. Note: they have informed me it will be GPL'd shortly.
Re: kernel-image with the same version
Hi, To recap: a) potato install installed 2.2.17. You now want a new kernel b) You moved /lib/modules/2.2.17 to 2.2.17-old c) you installed your own version of 2.2.17 d) You now have one /boot/vmlinuz-2.2.17, and both /vmlinuz and /vmlinuz.old link to it. There is o real way of avoiding this. Even if you moved /boot/vmlinuz-2.2.17 to /boot/vmlinuz-2.2.17.old, that kernel may not be bootable after step (c) since it shall continue to look for its modules in /lib/modules/2.2.17 (which are totally different set of modules). In these situations I download and create a 2.2.16 version, test and ensure that works, and then install my 2.2.17 version. I know this is suboptimal, but until we can tell a kernel-image at boot time where to find it's modules, that's the best we can do. manoj -- Humor in the Court: Q: ...any suggestions as to what prevented this from being a murder trial instead of an attempted murder trial? A: The victim lived. 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: ITP: gopher, gopherd, gopherindex
On Thu, Aug 17, 2000 at 01:30:29PM -0500, John Goerzen wrote: I intend to package up the gopher suite from UMN, together with my patches to it. Note: they have informed me it will be GPL'd shortly. URL and actual license? -- Christian Surchi | [EMAIL PROTECTED] | [EMAIL PROTECTED] FLUG: http://www.firenze.linux.it | Debian GNU/Linux: http://www.debian.org - http://www.firenze.linux.it/~csurchi -- A boy gets to be a man when a man is needed.-- John Steinbeck
Re: kernel-image with the same version
Atsuhito == Atsuhito Kohda [EMAIL PROTECTED] writes: Atsuhito From: Ben Collins [EMAIL PROTECTED] Atsuhito Subject: Re: kernel-image with the same version Atsuhito Date: Tue, 15 Aug 2000 18:54:29 -0400 Edit /etc/kernel-img.conf and add this line: reverse_symlink := yes Atsuhito Okay I will try later. BTW, /etc/kernel-img.conf might Atsuhito be /etc/kernel-pkg.conf Umm, /etc/kernel-pkg.conf is what is looked at when one is creating the kernel-image.deb; /etc/kernel-img.conf is looked at on the system the kenel-image is being installed on. Two different files. manoj -- QOTD: When she hauled ass, it took three trips. 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: Broken bootable SPARC CD#1, and why this happened
Ben Collins [EMAIL PROTECTED] writes: WTF is the difference? Nothing but a naming scheme. It's still a change, either way you do it, why do you want to nitpick the mechanism? Personally, I'd favour doing something that makes it as clear as possible that it was a CD production SNAFU, and that hence the sparc images are exactly the same revision as all the other ones, just that we had to have two (or in fact three, but we'll forget about that) runs at making the images. The FTP archive is not being updated by one jot in between the CD build runs, so when I make another set of sparc (and perhaps alpha) they will still be CDs of Debian 2.2 rev0, not rev0.1, not rev0.5, not rev1. On that basis, I'll call the directory on cdimage.d.o: 2.2_rev0_cdrev1 I'm not certain what I'll put on the CDs themselves, because I need to check the size issues, but if it will fit, I'll go for something like: 2.2 r0 CDr1 2.2 r0 (1) 2.2 r0.1 and if it's likely to cause the slightest problem, I'll not bother changing the version at all on the CD. All right? (I'm not overly bothered if that's not all right, given that there's probably not time to discuss it further before I do it). Cheers, Phil.
mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:26:17AM -0500, Manoj Srivastava wrote: The things that we do put in /sbin, for the same reasons, we expect that the average user will not use them and might be confused by encountering them. For example, mkfs and fsck and so forth are in /sbin. Anyone can use these, on a file or on a device they have permissions for. It's not that we expect only root to use these, but that we expect anyone who wanted to use them to probably know enough about the system to be root (or at least enough more than the average user that they can handle putting /sbin in their path). There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs And note that one can burn any filesystem on a CD (if you are allowed to access the CD writer). 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: Broken bootable SPARC CD#1, and why this happened
On 17 Aug 2000, Philip Hands wrote: Ben Collins [EMAIL PROTECTED] writes: WTF is the difference? Nothing but a naming scheme. It's still a change, either way you do it, why do you want to nitpick the mechanism? Personally, I'd favour doing something that makes it as clear as possible that it was a CD production SNAFU, and that hence the sparc images are exactly the same revision as all the other ones, just that we had to have two (or in fact three, but we'll forget about that) runs at making the images. The FTP archive is not being updated by one jot in between the CD build runs, so when I make another set of sparc (and perhaps alpha) they will still be CDs of Debian 2.2 rev0, not rev0.1, not rev0.5, not rev1. On that basis, I'll call the directory on cdimage.d.o: 2.2_rev0_cdrev1 I'm not certain what I'll put on the CDs themselves, because I need to check the size issues, but if it will fit, I'll go for something like: 2.2 r0 CDr1 2.2 r0 (1) 2.2 r0.1 and if it's likely to cause the slightest problem, I'll not bother changing the version at all on the CD. All right? (I'm not overly bothered if that's not all right, given that there's probably not time to discuss it further before I do it). Okay; I think r0.1 will be the only thing fitting nicely in the disklabel (32 bytes), as powerpc-sparc=2 ;-) (And then hope that powerpc doesn't need a second set...) Regards, Anne Bezemer
Re: I propose gazillion packages (LONG)
On 00-08-17 Juhapekka Tolvanen wrote: AIDE: http://www.cs.tut.fi/~rammer/aide.html |[EMAIL PROTECTED] apt-cache show aide |Package: aide |Version: 0.7-6 |[...] |Maintainer: Mike Markley [EMAIL PROTECTED] boxes: http://www6.informatik.uni-erlangen.de/~tsjensen/boxes/ |[EMAIL PROTECTED] apt-cache show boxes |Package: boxes |Version: 1.0.1-1 |[...] |Maintainer: KELEMEN Peter [EMAIL PROTECTED] QuickList: http://www.quicklist.org/ |[EMAIL PROTECTED] apt-cache show quicklist |Package: quicklist |Version: 0.8.6-2 |[...] |Maintainer: Bradley Bell [EMAIL PROTECTED] Artistic Style: http://astyle.sourceforge.net/ |[EMAIL PROTECTED] apt-cache show astyle |Package: astyle |Version: 1.11.6-1 |[...] |Maintainer: Sean 'Shaleh' Perry [EMAIL PROTECTED] deroff: http://www.moria.de/~michael/deroff/ |[EMAIL PROTECTED] apt-cache show deroff |Package: deroff |Version: 1.1-2 |[...] |Maintainer: David Frey [EMAIL PROTECTED] mp3_check: http://mp3check.sourceforge.net/ |[EMAIL PROTECTED] apt-cache show mp3check |Package: mp3check |Version: 1.97-1 |[...] |Maintainer: Norbert Tretkowski [EMAIL PROTECTED] So, may I suggest that in the future you first check which software is already packaged for debian? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Pg7FzA5FF.pgp Description: PGP signature
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, 17 Aug 2000, Marcus Brinkmann wrote: On Thu, Aug 17, 2000 at 11:26:17AM -0500, Manoj Srivastava wrote: The things that we do put in /sbin, for the same reasons, we expect that the average user will not use them and might be confused by encountering them. For example, mkfs and fsck and so forth are in /sbin. Anyone can use these, on a file or on a device they have permissions for. It's not that we expect only root to use these, but that we expect anyone who wanted to use them to probably know enough about the system to be root (or at least enough more than the average user that they can handle putting /sbin in their path). There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. The reason that mkisofs is not in /sbin is because /sbin should be reserved for things the core OS needs to have all of the time on the root partition. If you start putting mkisofs and the like in /sbin, then you have the problem of / growing over time. If you put mke2fs in /usr, then you're going to wish that you hadn't one day. I'm not sure that I understand this entire thread. Much of where files go is based on history/tradition, and like it or not, most of Linux/Debian's heritage is based on how the various Unices have solved certain problems over the past 25 years or so. Change is good, but only when folks understand why they're changing things, insted of being too lazy to add something to their PATH or learn where (and *why*) commands are where they are. (Sorry, this really isn't intended to flame anyone, but it seems that -devel gets off on the weirdest tangents sometimes.) tony [EMAIL PROTECTED] | Time after time we lose sight of the way. http://www.debian.org | Our causes can't see their effects. | (Neil Peart)
Re: kernel-image with the same version
On Thu, Aug 17, 2000 at 01:44:24PM -0500, Manoj Srivastava wrote: Hi, To recap: a) potato install installed 2.2.17. You now want a new kernel b) You moved /lib/modules/2.2.17 to 2.2.17-old c) you installed your own version of 2.2.17 d) You now have one /boot/vmlinuz-2.2.17, and both /vmlinuz and /vmlinuz.old link to it. There is o real way of avoiding this. Even if you moved However, there _is_ a way to avoid this. You can create different Flavours of the same kernel which may be named 2.2.17-1, 2.2.17-2, and so on. Read about this in /usr/share/doc/kernal-package/Flavours.gz However you need some handwork to patch the toplevel Makefile, but after that you can generate different kernel-flavours with make-kpkg --falvour=... ... or even make FLAVOUR=... Ingo -- I am the ILOVEGNU signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License.
Subpackaging (Was: Potato now stable)
Drake Diedrich [EMAIL PROTECTED] wrote: Under the Irix packaging system (quite nice UI except that it has to handle Irix packages..) packages exist in a hierarchy, with lowest level packages quite fine grained. For example: I fw_bzip2 02/28/2000 bzip2-0.9.0c Compress/decompress files I fw_bzip2.man 02/28/2000 bzip2-0.9.0c man pages I fw_bzip2.man.bzip2 02/28/2000 bzip2-0.9.0c man pages I fw_bzip2.man.info02/28/2000 bzip2-0.9.0c info pages I fw_bzip2.man.relnotes 02/28/2000 bzip2-0.9.0c Release Notes I fw_bzip2.sw 02/28/2000 bzip2-0.9.0c execution only env I fw_bzip2.sw.bzip202/28/2000 bzip2-0.9.0c execution only env I fw_bzip2.sw.hdr 02/28/2000 bzip2-0.9.0c header files I fw_bzip2.sw.lib 02/28/2000 bzip2-0.9.0c shared libraries I fw_bzip2.sw6402/28/2000 bzip2-0.9.0c 64-bit execution only env I fw_bzip2.sw64.lib02/28/2000 bzip2-0.9.0c 64-bit shared libs This looks cool. I like it. How about a little brainstorming to pick some categories that could be used in debian. Possible layout ~~~ control.tar.gzpackage system stuff, depends, postinst, etc signatures.tar.gz signatures for each part of the package binary/*.tar.gz arch-dependent data and programs for each arch data.tar.gz arch-independent data and programs doc.tar.gzdocs not in packages below (includes copyright) doc/html.tar.gz html format doc/ps.tar.gz postscript format doc/dvi.tar.gzdvi format doc/text.tar.gz text format doc/man.tar.gzman pages doc/info.tar.gz info pages doc/examples.tar.gz /usr/share/doc/examples/* locale/*/gettext.tar.gz gettext translations locale/*/doc/html.tar.gz html translations locale/*/doc/ps.tar.gzpostscript translations locale/*/doc/dvi.tar.gz dvi translations locale/*/doc/text.tar.gz text translations locale/*/doc/man.tar.gz manpage translations locale/*/doc/info.tar.gz info translations source/original.tar.gzupstream source source/debian.diff.gz debian diff copyright copy of copyright or symlink to common-licence Packages could be made available for each $(ARCH), including packages optimised for subarchs. The locale support is sorted by locale, rather than by file format, so that ftp users can more easily just download their locale, by downloading the directory for their locale. All the parts of the package would be optional apart from the control.tar.gz, in that way it would be possible to build task packages with no filesystem, just a copyright notice with the package on the mirror. How would it be implemented? My recommendation would be one directory per package. Each subpackage could just be part of a .tar.gz file. Having the binary dependent parts listed here would imply that the package locate could change from looking like this: dists/unstable/main/binary-*/admin/at_3.1.8-10.deb to looking like this: dists/main/admin/at/* apt, dselect and friends would be changed so that when a package was selected the default set of subpackages would be installed to match the current behaviour. When a package is selected all of the subpackages would be selected except for the binaries and the source. Only the binary of the current arch would be installed. The user could selected a more detailed screen in dselect, or use command line switches with apt-get to select the subpackages to be installed or not installed. What use would this be? ~~~ * Disk space Machines with small hard drives could have packages installed without docs or translations. Single-user systems could save space by only installing translations for languages that were needed. Docs could be installed in preferred formats only. A set of binaries built could be built with -Os passed to gcc and with extra build options turned off to try and make them as small as possible. This would be like the *-tiny packages now, but without needing to replicate the docs and man pages. Some space would be saved on the server because man pages and friends would not be stored for each arch. For an even more compact system each executable and library in the package could be split into a separate subpackage, but means we tend to lose some of the benefits of the packaging system, and just have a load of files. The Gnome applets could be packaged as one package, called gnome-applets, but within that package there is one .tar.gz for each applet. By default all the applets are installed, but the user can select with more details the exact binaries they want. If some modules are not selected this would save space on an install, during install and save bandwidth when downloading. An alternative would be to include all the applets in one .tar.gz and selective not install binaries. This would save space in the installed form, but would not save
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, 17 Aug 2000, Marcus Brinkmann wrote: There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs tony mancill wrote: I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. Sure. I _think_ Marcus was simply arguing that one command is in a `bin' directory and the other in an `sbin' directory (regardless of the `usr' issue).
Web Page needs updated
Hello all, I was going to submit a bug reprt but I wasn't sure which virtual package the web page was listed under. The main Debian web page still points to the slink info under Distribution - Installation Instructions I am assuming that this is incorrect as potato is now stable. Will someone please check this out and submit a bug if needed? Thanks -- Frisco Rose By any other name, I would smell the same E.O.U. Student [EMAIL PROTECTED] (541) 962-2987
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 04:15:17PM -0400, Peter S Galbraith wrote: On Thu, 17 Aug 2000, Marcus Brinkmann wrote: There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs tony mancill wrote: I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. Sure. I _think_ Marcus was simply arguing that one command is in a `bin' directory and the other in an `sbin' directory (regardless of the `usr' issue). Peter is correct. mke2fs could be in /bin without conflicting with what Tony (rightfully) said. 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: Subpackaging (Was: Potato now stable)
Edward Betts writes: Possible layout ~~~ snippage I like the plan a lot. some thoughts: doc/examples.tar.gz /usr/share/doc/examples/* locale/*/gettext.tar.gz gettext translations I wonder if the default docs should not go in a locale/ subdir for the proper language (English for most of what exists now). I know very little about i18b so I won't comment on the implementation. This does have this advantages of: (a) not appearing to be English-centric (b) allowing for a package whose upstream docs are entirely in a different language (while most non-English-speaking authors also know some English or are fluent in it, many may not). doc.tar.gzdocs not in packages below (includes copyright) copyright copy of copyright or symlink to common-licence I don't really get the reason for duplicating copyright. See below. dists/unstable/main/binary-*/admin/at_3.1.8-10.deb to looking like this: dists/main/admin/at/* This is good. Something I brought up before was moving the package metadata (except for a list of timestamps) from a monolithic Packages file to where the individual packages are, which would be even easier here. Does anyone have any comments on that? The user could selected a more detailed screen in dselect, or use command line switches with apt-get to select the subpackages to be installed or not installed. As well as /etc/apt/apt.conf options (for example, a systemwide default of no documentation). For an even more compact system each executable and library in the package could be split into a separate subpackage, but means we tend to lose some of the benefits of the packaging system, and just have a load of files. This is probably overkill. We are breaking the rules on copyright at the moment. We distribute binaries licensed under the GPL without a copy of the GPL. I disagree. We distribute base-files on the same server. Packages that provide the same documentation in different formats do not always include the same documents in the different formats, but instead different documents are included in different formats. An example might be useful: Not: README, README.html and README.ps But: README, manual.html and specification.ps IMHO, doc-$FORMAT should only apply if the same documentation is built in different formats. There should be one 'doc' tarball for documentation which comes in a single format, and 'doc-*' or 'doc/*' for the multiple case (and then none of those files should be in the base 'doc'.) What happens when a user selects to install binary-i386 and binary-m68k packages? I don't see a reason to allow this; is there one? -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Bug#33993: general: Should log all the boot messages
Cesar Eduardo Barros [EMAIL PROTECTED] writes: Package: general Version: N/A Severity: wishlist There are too many boot messages, and they sometimes scroll too fast. It would be nice to log all the output from the boot scripts. Huh? does dmesg not do what you want? -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Re: ITP: gopher, gopherd, gopherindex
I'll post such when the change takes place, which should occur in a matter of a few days. Christian Surchi [EMAIL PROTECTED] writes: On Thu, Aug 17, 2000 at 01:30:29PM -0500, John Goerzen wrote: I intend to package up the gopher suite from UMN, together with my patches to it. Note: they have informed me it will be GPL'd shortly. URL and actual license? -- Christian Surchi | [EMAIL PROTECTED] | [EMAIL PROTECTED] FLUG: http://www.firenze.linux.it | Debian GNU/Linux: http://www.debian.org - http://www.firenze.linux.it/~csurchi -- A boy gets to be a man when a man is needed. -- John Steinbeck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen [EMAIL PROTECTED] www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include std_disclaimer.h [EMAIL PROTECTED]
Re: Bug#33993: general: Should log all the boot messages
Decklin Foster [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Cesar Eduardo Barros [EMAIL PROTECTED] writes: There are too many boot messages, and they sometimes scroll too fast. It would be nice to log all the output from the boot scripts. Huh? does dmesg not do what you want? dmesg doesn't log the output from init.d scripts. (I usually recommend Ctrl-S (stop output) and Ctrl-Q (restart output).) -- Colin Watson [EMAIL PROTECTED]
Bug#33993: general: Should log all the boot messages
On Thu, 17 Aug 2000, Decklin Foster wrote: Cesar Eduardo Barros [EMAIL PROTECTED] writes: Package: general Version: N/A Severity: wishlist There are too many boot messages, and they sometimes scroll too fast. It would be nice to log all the output from the boot scripts. Huh? does dmesg not do what you want? dmesg only is for kernel messages. The entire userland (like starting daemons etc.) is not covered by it. IIRC a few months ago someone had a patch agains init (or something else) that would log the entire startup. I don't know what its current status is but it seemed like a really nice idea at that time. yours, peter -- PGP encrypted messages preferred. http://www.cosy.sbg.ac.at/~ppalfrad/ [please CC me on lists]
Re: I propose gazillion packages (LONG)
XMLTerm http://xmlterm.com/ XMLterm - A graphical command line interface. If you don't understand, check out those screenshots. This is merely a compoenent in mozilla, I believe the debs I created include it... http://master.debian.org/~frb/mozilla Frank aka Myth pgpAD5jnkVGDT.pgp Description: PGP signature
ITP: transarc/IBM AFS
package: wnpp severity: normal IBM announced at LinuxWorld the Open AFS release of AFS under the IPL; relevant URLs include http://oss.software.ibm.com/developerworks/opensource/ http://www.transarc.com AFS is the Andrew File System, as originally done at CMU and spun off to Transarc which is mostly owned by IBM. It has critical features like volume migration, cryptographic security, access control lists, and an online backup/cloning system that makes consistent backups possible. (It is the filesystem of choice at large educational institutions.) If you're familiar with CODA, this is the commercialized predecessor; if you're familiar with Arla, this is the thing with which it is compatible. The source itself is supposed to be released in September 2000, that is of course critical for this ITP. _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian Package Maintainer
Nautilus Debian Package
Hi. I've built Nautilus 0.1.0 release package. (for woody) Just now, it depends on some Incoming packages such as gtkhtml or gconf. So, I put also some needed packages medusa, w3c-libwww, gconf and gnome-vfs. I'm intent to upload nautilus, medusa and w3c-libwww to Debian main stream. gconf was uploaded already. gnome-vfs will be uploaded by Vincent Renardias. You can get it with apt-get. deb http://www.debian.org/~kitame/gnome/release ./ Thanks. -- Takuo KITAME / [EMAIL PROTECTED]
Re: Office Suite for Debian Linux
On Thu, Aug 17, 2000 at 09:07:09AM +0200, Paul Slootman [EMAIL PROTECTED] spake forth: I wonder how he's going to be in dozens of countries across the world towards the end of September :-) This is so clearly a standard ploy to attract business; if someone responds, he goes to where ever the offices happen to be. Should this be considered spam? As far as I'm concerned, it's unsollicited commercial email, thus spam. Perhaps. Or perhaps, as the sender told me in an email after I explained the distributed non-commercial nature of Debian in a gentler way, he simply thought our offices were in California. Wonder what could've led to such a silly belief... Registrant: Software in the Public Interest, Inc. (DEBIAN6-DOM) PO Box 273 Tracy, CA 95378-0273 US Domain Name: DEBIAN.ORG Hmm. :) I hate spam. I hate spammers. And I probably think that this company's software is crap, and it probably has a standard closed EULA clickthru-type license. But I think we may be jumping to conclusions about this guy's intentions... -- 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 You can't have everything... where would you put it? - Steven Wright
Re: Subpackaging (Was: Potato now stable)
Decklin Foster [EMAIL PROTECTED] wrote: I like the plan a lot. some thoughts: Glade to hear it. I wonder if the default docs should not go in a locale/ subdir for the proper language (English for most of what exists now). I know very little about i18b so I won't comment on the implementation. This does have this advantages of: (a) not appearing to be English-centric (b) allowing for a package whose upstream docs are entirely in a different language (while most non-English-speaking authors also know some English or are fluent in it, many may not). Yes, this could work. We are breaking the rules on copyright at the moment. We distribute binaries licensed under the GPL without a copy of the GPL. I disagree. We distribute base-files on the same server. You are right, I am probably trying to fix a problem that is not there. Feel free to ignore the bit of copyrights. Packages that provide the same documentation in different formats do not always include the same documents in the different formats, but instead different documents are included in different formats. An example might be useful: Not: README, README.html and README.ps But: README, manual.html and specification.ps IMHO, doc-$FORMAT should only apply if the same documentation is built in different formats. There should be one 'doc' tarball for documentation which comes in a single format, and 'doc-*' or 'doc/*' for the multiple case (and then none of those files should be in the base 'doc'.) That was about what I was thinking. What happens when a user selects to install binary-i386 and binary-m68k packages? I don't see a reason to allow this; is there one? No probably not. I was thinking it would be cool to build a server on an i386, and then decide to upgrade to Alpha. You can get ATX Alpha boards these days, in terms of hardware you just need to replace the m/b and chip; it would be cool if you could take a debian install, tell apt that you were about to change the processor from i386 to alpha and it automatically changed all the binaries. This is probably not very likely to happen, and if it could be written to be supported by my suggested layout, then it could probably be handled by the current layout. Just remove all the binary packages and install the new ones from the new arch. This is all a bit side tracked, and does not give a reason for wanting binaries from two archs installed at once. Oh! I have thought of a reason! Something to do with a network server that supplies /usr/bin for a load of machines, and they are different archs. Probably far-fetched, and the package management system should not be used for something this complicated. -- Don't worry -- shop.
Re: Subpackaging (Was: Potato now stable)
Edward Betts [EMAIL PROTECTED] wrote: How would it be implemented? My recommendation would be one directory per package. Each subpackage could just be part of a .tar.gz file. Having the binary dependent parts listed here would imply that the package locate could change from looking like this: dists/unstable/main/binary-*/admin/at_3.1.8-10.deb to looking like this: dists/main/admin/at/* I thought of another problem. Versions. Are they in the control.tar.gz for each subpackage? Or is there a small control file in each subpackage that contains the info? Another thought. Should signatures be in a single .tar.gz, like I suggested, or should they be in each .tar.gz If they are the single .tar.gz, then translators would have to get it updated when releasing a new version of a translation. -- Don't worry -- shop.
Re: WG: Broken bootable SPARC CD#1, and why this happened
Peter Makholm [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Not for me... Life is nice isn't it? (And then stop sending this Not for me-answers all the time or something bad could happend) I would guess thats a mial loop, like an away message. MfG Goswin
Re: kernel-image with the same version
From: Manoj Srivastava [EMAIL PROTECTED] Subject: Re: kernel-image with the same version Date: 17 Aug 2000 13:44:24 -0500 To recap: a) potato install installed 2.2.17. You now want a new kernel b) You moved /lib/modules/2.2.17 to 2.2.17-old c) you installed your own version of 2.2.17 d) You now have one /boot/vmlinuz-2.2.17, and both /vmlinuz and /vmlinuz.old link to it. Yes, these are exactly the problem I encountered. There is o real way of avoiding this. Even if you moved /boot/vmlinuz-2.2.17 to /boot/vmlinuz-2.2.17.old, that kernel may not be bootable after step (c) since it shall continue to look for its modules in /lib/modules/2.2.17 (which are totally different set of modules). In these situations I download and create a 2.2.16 version, test and ensure that works, and then install my 2.2.17 version. I know this is suboptimal, but until we can tell a kernel-image at boot time where to find it's modules, that's the best we can do. I see, I got your ponts. A rather complicated but safe enough methods! Thanks for your suggestion. Best Regards, 2000.8.18 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: kernel-image with the same version
From: Manoj Srivastava [EMAIL PROTECTED] Subject: Re: kernel-image with the same version Date: 17 Aug 2000 13:50:13 -0500 Atsuhito Okay I will try later. BTW, /etc/kernel-img.conf might Atsuhito be /etc/kernel-pkg.conf Umm, /etc/kernel-pkg.conf is what is looked at when one is creating the kernel-image.deb; /etc/kernel-img.conf is looked at on the system the kenel-image is being installed on. Two different files. Yes, I first searched kernel-* file in /etc and found only kernel-pkg.conf so I misunderstood that the mentioned file should be this one. But afterward I read through /usr/share/doc/kernel-package/README.gz and found that /etc/kernel-pkg.conf is related with make-kpkg command but I missed the comment on /etc/kernel-img.conf which was written just after the comment on kernel-pkg.conf. Thanks for your comment. Best Regards, 2000.8.18 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: Web Page needs updated
On Thu, Aug 17, 2000 at 01:31:51PM -0700, esoR ocsirF wrote: Hello all, I was going to submit a bug reprt but I wasn't sure which virtual package the web page was listed under. The main Debian web page still points to the slink info under Distribution - Installation Instructions It has been changed to point to /releases/stable/. The change will be visible after the next mirror update tomorrow. -- James (Jay) Treacy [EMAIL PROTECTED]
Re: WG: Broken bootable SPARC CD#1, and why this happened
On Fri, Aug 18, 2000 at 02:39:26AM +0200, [EMAIL PROTECTED] wrote: Peter Makholm [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Not for me... Life is nice isn't it? (And then stop sending this Not for me-answers all the time or something bad could happend) I would guess thats a mial loop, like an away message. Except that one of the messages had a capital 'F' in 'For'... -- - mdz
