Re: ftp+rcp: Connection refused
> Gerd Bavendiek <[EMAIL PROTECTED]> writes: > I just installed a Debian 1.1 System using latest packages. Everything > went fine, but one problem remains: > I can ftp TO the new system. I cannot ftp FROM my new system, named > koko. > [ ... ] > Connection refused > [ ... ] My guess is that the new machine (koko) is not in the older machines /etc/hosts files, or equivalently, not in your name server's database. Some ftp daemons will refuse connections from anonymous IP addresses (ie. IP addresses for which a machine name cannot be found). -- Steve Preston ([EMAIL PROTECTED])
Re: regular (aka bsd) compress distribution?
> I don't want anyone to risk anything, I just don't believe that the > problem is so serious because nobody else seems to care about it. > If it is - better move the distribution outside the US now, it only > gets worse. Not only something that was in the public domain may be > patented, you can also get in trouble if there is a four-letter word > in some package. It is very unfortunate that most Linux distributions > come from the US, and users around the world have to live with such > silly restrictions. And the free world is only 100ms away... Whoa, there! Moving outside the U.S. does _not_ make you immune to either patents or copyrights! There are huge international agreements to stop just this (and rightly so). Sure, you can find countries that don't have such an agreement with the USA, but that still doesn't make it ethical. Second, LZW was _never_ public domain. It was "publicly disclosed", as that is what a patent is (all details released to the public). Unisys just never bothered to enforce their rights before. > they often come without a C compiler. And it's more than just compress > - also various programs using the GIF format, which are non-free in > Debian for just this reason. Yes, there are better formats than GIF, > but GIF is unfortunately still the widely used standard. Actually, only the "Welche (sp?) compression improvement" is patented. Lempel-Zip is public domain, as are LZ and LZW decompression methods. GIF has always been copyright by Compuserve, but it isn't patented (it is, after all, as specific instance as opposed to a specific implementation). GIF decoders are not exposed to the patent, though they can be affected by Compuserve's copyright. > Proposal: not necessarily before the 1.1 release, but perhaps one of > the many non-US Debian mirror sites could become the primary site. > Now we can maintain the full international distribution, and remove > certain packages (compress, GIF, PGP, ssh, ...) only from CD-ROMs > sold in the US. This way we can keep everyone reasonably happy. You might get away with it, but that doesn't make it right. Note: I'm not saying that compress should not be distributed; that depends on the restrictions Unisys puts on it. All I'm saying is that trying to bend the rules is wrong. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: netscape*.deb installation problem
> When I dpkg -iGBE netsc*.deb, I get the message that Netscape wants to > see the archive netscape*.tar.gz in /tmp. Nothing further seems to > happen. The obvious thing to try was to cd /tmp, then run dpkg, but > alas, no joy:-( > > What's the story? Because Netscape will not allow redistribution of their work, the Debian version is just an installer that requires the original distribution from Netscape. Try anonymous ftp to ftp[2-9].netscape.com to get the requested archive. If you're looking for the beta version of 3.0, then you'll have to wait a few days until I upload the version for the beta-4 release. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: regular (aka bsd) compress distribution?
> they often come without a C compiler. And it's more than just compress Often? Solaris is the only unix I know of that doesn't come with a compiler that can build gzip. (Note I did not say a C compiler -- HP/UX ships with a toy for building kernel config files, that is still enough to build gzip.) And for solaris, you can get binaries of gcc on the net or on Sun's demo-ware cdrom. SGI may be similar - but I'm pretty sure they ship gzip (along with gcc, in the stack of cdroms you get with the machine.) If you mean non-unix platforms, well, there are DOS, Windows, and MacOS gzip's available free. I'm sure there's an amiga one on the Fish disks, if not I'll bug Fred :-) What did I miss? If you *really* want a CP/M gzip (given that there isn't a CP/M "compress" either, though there is a *different* lzw based tool) I can give it a shot, but I'll need some convincing :-) I think that gzip handles things quite well - read the old format, but don't write it, so we can bring old data forward. PNG will take a little longer to catch on, but it's getting there. The compression technique used in gzip is now an RFC (issued last week, RFC1950, RFC1951, and RFC1952.) Consider also: why does debian need to be in the business of helping unisys make money? Anyone running linux who needs to read compressed data can already do so, via gzip. If they need to generate lzw-compressed data, *even if there is a package* they need to talk to Unisys about licensing, and can build the package themselves. We don't need to make it easy; we can instead make it easy for people to *avoid* the problem. And would people stop using "X11 fonts" as an example? Or do I have to actually post patches to make xfs use gzip or zlib [zlib is the *free*, non-gpl'ed, compression library using the algorithm; see RFC1950 for a pointer to the source.] (Sorry to rant like this; I just don't like seeing fellow debian developers get flamed for already doing what I consider the right thing, and flamed for spurious reasons - I haven't seen a reason posted yet that the above doesn't refute, nor have I seen a refutation of the above arguments...) _Mark_
Re: regular (aka bsd) compress distribution?
> If it is - better move the distribution outside the US now, it only > gets worse. Not only something that was in the public domain may be > patented, you can also get in trouble if there is a four-letter word > in some package. It is very unfortunate that most Linux distributions > come from the US, and users around the world have to live with such > silly restrictions. And the free world is only 100ms away... This is why we moved the mailing list out of the U.S. > Proposal: not necessarily before the 1.1 release, but perhaps one of > the many non-US Debian mirror sites could become the primary site. At the very least we should have an outside-of-US site for some components now. At one time I think we distributed PGP from Cambridge. Bruce
Re: regular (aka bsd) compress distribution?
On Fri, 24 May 1996, Marek Michalkiewicz wrote: > Bruce Perens: > > this situation is that it's lawsuit bait for me to distribute patented > > software without a license. If you look on Unisys web page, they say > > yes you definitely need a license. Red Hat could have one for all I know. > > I'm not suggesting that we do anything illegal. If Red Hat can have > a license, maybe we could have one too. I've sent a question to > [EMAIL PROTECTED] about this - we'll see... [SNIP] > Proposal: not necessarily before the 1.1 release, but perhaps one of > the many non-US Debian mirror sites could become the primary site. > Now we can maintain the full international distribution, and remove > certain packages (compress, GIF, PGP, ssh, ...) only from CD-ROMs > sold in the US. This way we can keep everyone reasonably happy. If you really want this utility, why not make your own Debian add-on package and distribute it yourself? I like the fact that Debian strives to be a distribution free of restrictive copyrights. Syrus. -- Syrus Nemat-Nasser <[EMAIL PROTECTED]>UCSD Physics Dept.
ftp+rcp: Connection refused
Hi, I just installed a Debian 1.1 System using latest packages. Everything went fine, but one problem remains: I can ftp TO the new system. I cannot ftp FROM my new system, named koko. So being on koko and doing: ftp zaza gives me: ftp: connect: Connection refused strace gives me: ipc_subcall ... ERRNO 111 Connection refused Similar goes for rcp. koko is part of a LAN. Most of the packages I could install by mounting a NFS-Filesystem. I'm afraid, solution might be obvious, but right now I have no idea. Any help apreciated ... Gerd
Re: more trouble with 1.1 upgrade
Ian Jackson said:
> Scott Barker writes ("Re: more trouble with 1.1 upgrade"):
> > ok. So what happens when I install the new cron, and /usr/bin/savelog isn't
> > in
> > it? Won't dpkg remove it, since /usr/bin/savelog has been removed from
> > /var/lib/dpkg/info/base.list?
>
> Err, bugger. I knew this --force-replaces thing was a bad idea.
>
> If you do this you'll have to reinstall bsdutils, but there's nothing
> really that can be done about it.
>
> cron needs to be fixed.
That's what I thought. Just thought I'd mention the problem. Perhaps when cron
is fixed, the bsdutils package should be bumped up a version, so that dselect
will automagically re-install it. Or maybe the cron postinst script should
spit out a message letting the user know that bsdutils should be updated.
--
Scott Barker
Linux Consultant
[EMAIL PROTECTED]
http://www.cuug.ab.ca:8001/~barkers/ (under construction)
[ I try to reply to all e-mail within 5 days. If you don't ]
[ get a response by then, I probably didn't get your e-mail ]
[ (we have a sometimes sporadic connection to the internet) ]
"Though we travel the world over to find the beautiful, we must carry it with
us or we find it not."
- Ralph Waldo Emerson
Re: netscape*.deb installation problem
> When I dpkg -iGBE netsc*.deb, I get the message that Netscape wants to > see the archive netscape*.tar.gz in /tmp. Nothing further seems to > happen. The obvious thing to try was to cd /tmp, then run dpkg, but > alas, no joy:-( > > What's the story? The story is available via "dpkg --info netscape*deb": Netscape (pronounced "Mozilla") is a graphical World-Wide-Web browser with many features. It supports advanced features of HTML and new technologies such as "Java" from Sun Microsystems. . Netscape Communications Corporation does not allow redistribution of their software. Therefore, this package requires the user to fetch the netscape archive seperately and place it in the directory pointed to by the TMPDIR environment variable (or /tmp if TMPDIR not defined) before attempting to install this package. You can get the linux-i486 packages via anonymous ftp from "ftp[1-9].netscape.com". . Do NOT try to install any version of Netscape other than Atlas-b3 with this package! . Netscape Communications Corporation does not support the Linux release in the slightest, even for paying customers. It has been made available purely as a courtesy, so please do not send them questions about Linux. . This installer package has been placed in the public domain! Ray
Re: regular (aka bsd) compress distribution?
Marek Michalkiewicz says: > Red Hat, Slackware, FreeBSD, ... all have compress as part of the > standard distribution. I don't think they all would do something > that is against the law. Maybe something is wrong with the Debian's > interpretation of the patent? Infomagic's December cut of Linux sites had to remove stuff from Slackware. Just because it is in another distrib doesn't make it so. The algorithm compress uses is copyrighted and including it without permission would be IMHO playing with fire. Considering gzip does such a good job, it hardly seems worth the risk to include compress/uncompress. If we did, I think it'd have to go in non-free and we would, as Marek suggests, have to ask Unisys. > Too bad dpkg can't (yet) install RPMs. It would be nice to be able > to buy a 5 CD set with both Debian and Red Hat, install Debian, then > install the missing non-free-in-Debian-free-everywhere-else packages > from the Red Hat CD. It shouldn't be impossible - most differences > I've seen so far between these distributions are in startup scripts. > And commercial software will ship as RPMs soon... .deb and .rpm files are more than just fancy .tgz files. What you suggest would require that .deb file dependencies be able to track .rpm files and that dpkg know, perhaps via an index file, what .deb files the .rpms depend on. Of course, the rpm-s would never be maintained for us and their contents could change without warning. In effect, the rpms would be worse than orphaned .deb packages. If orphaned packages are only barely supported by Debian, rpm-s will likely never be. It would be far less effort for us to just package those items as .deb files (if we have a maintainer for it). If you really want to install an rpm, get the Red Hat package maintenance system. But be warned, you can damage your existing system. I wouldn't do it. Oly
Re: dpkg-ftp troubles
In message <[EMAIL PROTECTED]>, Joe Reinhardt writes: >I am having trouble with dpkg-ftp 1.4.0. I repeatedly get this error >when trying to install: You should upgrade to 1.4.1, though, if what you have is truly 1.4.0 They shouldn't affect anything. Unless they're adversely affecting your installation, you can probably ignore them. Mike. -- "Don't let me make you unhappy by failing to be contrary enough"
Re: sysklogd problem
Both of your problems are caused by the named pipe /dev/xconsole filling up, which is a known problem. I get the same behaviour here on my machine. I suspect named pauses for so long because it has a relatively large amount of logging to report, and hence is most likely to be the process which causes the pipe to fill. There's no way to make the pipe buffers bigger, as it's set at one page by the kernel. Well, I suppose the kernel could be changed - the source is there after all! Could the syslogd and xbase maintainers comment on why the /dev/xconsole pipe is being used instead of the traditional TakeConsole/GiveConsole scripts run by xdm? Is there a pressing reason? Kenny. > > Hello, Im having a slight problem with the newest sysklogd from the > unstable tree. I upgraded to 1.3-2 and now My named pipe /dev/xconsole > doesnt work from boot (I have to HUP the syslogd to make it start logging > to /dev/xconsole) > > The permissions on /dev/xconsole are > > prw-r--r-- 1 root root0 Apr 13 10:10 /dev/xconsole > > The line from the syslog.conf that entails the named pipe > /dev/xconsole is > > auth.*;daemon.*;mail.*;news.crit;news.err;news.notice;*.=debug;*.=info; > *.=notice;*.=warn;cron.none |/dev/xconsole > > > I looked through the /usr/doc/base/sysklogd and there wasnt anything > that really pertained to this, so anyway, Im at a loss. > > Also, My named used to startup quick at boot (even though I wasnt > actually connected to the network) and now it has to wait to time out to > continue to the next step in the init sequnece. This is a tad annoying > and I wondered if there were any way to stop it (I hadn't looked at the > manpage as of yet for that, mebye there is a command line option). > Anyway, thanks alot. > | <[EMAIL PROTECTED]> "http://www.glg.ed.ac.uk/~kenny"; | | Portuguese/English/French Translations/Teaching by Native Portuguese | | <[EMAIL PROTECTED]> "http://www.nsl.co.uk/tls"; |
netscape*.deb installation problem
When I dpkg -iGBE netsc*.deb, I get the message that Netscape wants to see the archive netscape*.tar.gz in /tmp. Nothing further seems to happen. The obvious thing to try was to cd /tmp, then run dpkg, but alas, no joy:-( What's the story? tia, kai -- Life is hard and then you die.
Re: regular (aka bsd) compress distribution?
Bruce Perens: > this situation is that it's lawsuit bait for me to distribute patented > software without a license. If you look on Unisys web page, they say > yes you definitely need a license. Red Hat could have one for all I know. I'm not suggesting that we do anything illegal. If Red Hat can have a license, maybe we could have one too. I've sent a question to [EMAIL PROTECTED] about this - we'll see... > You guys don't pay for Debian. Do I owe it to you to risk my home and all > I own just because you want an obsolete Unix utility? I don't want anyone to risk anything, I just don't believe that the problem is so serious because nobody else seems to care about it. If it is - better move the distribution outside the US now, it only gets worse. Not only something that was in the public domain may be patented, you can also get in trouble if there is a four-letter word in some package. It is very unfortunate that most Linux distributions come from the US, and users around the world have to live with such silly restrictions. And the free world is only 100ms away... compress may be obsolete, but it's still the standard. Files produced by gzip can't be uncompressed on systems which come with compress but without gzip. It is not always possible to compile gzip on them - they often come without a C compiler. And it's more than just compress - also various programs using the GIF format, which are non-free in Debian for just this reason. Yes, there are better formats than GIF, but GIF is unfortunately still the widely used standard. Proposal: not necessarily before the 1.1 release, but perhaps one of the many non-US Debian mirror sites could become the primary site. Now we can maintain the full international distribution, and remove certain packages (compress, GIF, PGP, ssh, ...) only from CD-ROMs sold in the US. This way we can keep everyone reasonably happy. Regards, Marek
Re: Compiling the kernel..
Hi, >>"Craig" == Craig Sanders <[EMAIL PROTECTED]> writes: (Thanks, Craig, for answering this) I am merely clarifying a few minor points in an excellent tutorial, To paraphrase what Craig said: : simplest way is to download "kernel_source-x.x.x.deb", use dpkg to : install it, and then: : 1. cd /usr/src/linux : 2. configure the kernel with: : make config : -or- : make menuconfig : -or- : make xconfig At this point you are done: debian.rules takes care of the rest. Just say: 3. ./debian.rules kernel_image Also, once a .config file exists, it is never overwritten by debian.rules -- It is even propogated by ./debian.rules kernel_source All this information is also in the file /usr/src/linux/debian.README in the newer kernels. manoj ps. Please remember Craigs warnings about installing a kernel with the same version as a previously installed kernel. If you absolutely have to, remember to manually clean /lib/modules/version-number-of-image-being-installed/* manually before installing the new kernel-image, and reboot soon afterwards, re-running lilo as necessary, of course (or otherwise ensuring that you can boot with the new image). -- God must love the common man; He made so many of them. Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 <[EMAIL PROTECTED]> http://www.pilgrim.umass.edu/%7Esrivasta/>
Re: dpkg-ftp troubles
Try replacing cmpvers in /usr/lib/dpkg/methods/ftp/install with the
following function. While the maintainer has not yet blessed this
change, it seems to work for me.
# compare two versions (taken from dpkg docs)
sub cmpvers {
($a,$b) = @_;
my ($cm, $ad, $bd);
if( defined($a) && !defined($b)) { return 1; }
if(!defined($a) && !defined($b)) { return 0; }
if(!defined($a) && defined($b)) { return -1; }
do {
$a =~ s/^\D*//; $ad= $&; $ad =~ s/\W/ /g;
$b =~ s/^\D*//; $bd= $&; $bd =~ s/\W/ /g;
$cm = $ad cmp $bd; return $cm if $cm;
$a =~ s/^\d*//; $ad= $&;
$b =~ s/^\d*//; $bd= $&;
$cm = $ad cmp $bd; return $cm if $cm;
} while (length($a) && length($b));
return length($a) cmp length($b);
}
> "Joe" == Joe Reinhardt <[EMAIL PROTECTED]> writes:
> I am having trouble with dpkg-ftp 1.4.0. I repeatedly get this error
> when trying to install:
> Processing status file...
> Processing Package files...
> unstable...
> Argument "" isn't numeric in ncmp at /usr/lib/dpkg/methods/ftp/install
> line 99,
> chunk 1441 (#1)
> Argument "" isn't numeric in ncmp at /usr/lib/dpkg/methods/ftp/install
> line 99, chunk 1441.
> non-free...
> contrib...
> Any ideas?
> --
> Joe ReinhardtDivision of Physiologic Imaging
> [EMAIL PROTECTED] Department of Radiology, JPP-3960
> Telephone: 319-353-7258 University of Iowa College of Medicine
> FAX: 319-356-1503 200 Hawkins Drive, Iowa City, IA 52242
~/.saves-6702-hostname.domainname
Hello. Does somone know how to avoid long lists of emacs-savings like that in the subject line? They seem to be created only if the emacs is invoced on the local machine but not if started remotely via telnet etc. The saves-files contain files visited with that emacs-session. Thanks. -- Uni Wuppertal, FB Elektrotechnik, Tel/Fax: (0202) 439 - 3009 Andreas Wehler; email: [EMAIL PROTECTED]
Re: really old bugs
Scott Barker writes ("really old bugs"):
...
> The mirror at debian.org is severely out of date. The mirror maintainer seems
> to know this, as there is a message there saying so. I was wondering if this
> was going to be corrected soon?
No, but it may be corrected eventually :-). We're working on it.
> More importantly, I see bugs still listed (at the primary site) as outstanding
> which are over a year old! I can't imagine many of them are *actually* still
> not solved after that long. Is anything done to periodically clean obsolete
> bugs out of the list? (Yes, I am offering to be the bug-cleaner-outer, if
> someone is needed for the task).
Steve Greenland is doing a reasonably good job of chasing up
maintainers with old bugs, finding packages whose maintainers have
disappeared, &c, but I imagine he could probably do with some help.
If you like you could just go through the old bugs trying to sort them
out. This means you need to try to find out if the bug still exists;
if it does still exist you need to fix it yourself or get the
maintainer to fix it - be polite ! - or if the maintainer is too busy
or gone away announce that they are and ask for a volunteer either to
fix the bug or to take over the package.
If it doesn't exist you need to send a message to the person who
reported it, CC the bug tracking system at [EMAIL PROTECTED],
with the right subject line (Bug#), and probably CC the
maintainer of the package, saying why you think the bug no longer
exists. The copy to debian-bugs-done will, with the right Subject
line, close the bug report.
Ian.
sysklogd problem
Hello, Im having a slight problem with the newest sysklogd from the unstable tree. I upgraded to 1.3-2 and now My named pipe /dev/xconsole doesnt work from boot (I have to HUP the syslogd to make it start logging to /dev/xconsole) The permissions on /dev/xconsole are prw-r--r-- 1 root root0 Apr 13 10:10 /dev/xconsole The line from the syslog.conf that entails the named pipe /dev/xconsole is auth.*;daemon.*;mail.*;news.crit;news.err;news.notice;*.=debug;*.=info; *.=notice;*.=warn;cron.none |/dev/xconsole I looked through the /usr/doc/base/sysklogd and there wasnt anything that really pertained to this, so anyway, Im at a loss. Also, My named used to startup quick at boot (even though I wasnt actually connected to the network) and now it has to wait to time out to continue to the next step in the init sequnece. This is a tad annoying and I wondered if there were any way to stop it (I hadn't looked at the manpage as of yet for that, mebye there is a command line option). Anyway, thanks alot.
Re: regular (aka bsd) compress distribution?
> Red Hat, Slackware, FreeBSD, ... all have compress as part of the > standard distribution. I don't think they all would do something > that is against the law. Maybe something is wrong with the Debian's > interpretation of the patent? I want to explain my position on this yet another time. I have a house and some other assets that I would probably lose if I had to defend myself from a law suit, and I'd probably lose those assets just from the cost of defense, even if I won the lawsuit. My reading of this situation is that it's lawsuit bait for me to distribute patented software without a license. If you look on Unisys web page, they say yes you definitely need a license. Red Hat could have one for all I know. You guys don't pay for Debian. Do I owe it to you to risk my home and all I own just because you want an obsolete Unix utility? Thanks Bruce Perens
Re: Compiling the kernel..
Craig Sanders writes: > > > On Thu, 23 May 1996 [EMAIL PROTECTED] wrote: > > > I tried the procedure you (and a couple of others) suggested. I currently > > have debian 0.93R6 installed and am trying to compile the kernel from > > devel/source-1.3.64-0.deb > > You've got the wrong kernel version. These instructions only apply to > recent kernel versions, 1.3.97 or later. > > > I also tried doing "make zImage" I get > > gcc -D__KERNEL__ -I/usr/src/linux-1.3.64/include -Wall -Wstrict-prototypes > > -O2 -fomit-frame-pointer -fno-strength-reduce -pipe -m486 -malign-loops=2 > > -malign-jumps=2 -malign-functions=2 -DCPU=586 > > -DNFS_ROOT="\"/tftpboot/%s\"" -c -o init/main.o init/main> > .c > > cc1: Invalid option `align-loops=2' > > cc1: Invalid option `align-jumps=2' > > cc1: Invalid option `align-functions=2' > > make: *** [init/main.o] Error 1 > > > > I do have gcc version 2.6.3 so I don't think that should be a problem. > > Any ideas? > > No idea. As a wild guess i'd suspect that maybe you're trying to compile > an ELF kernel with an a.out only gcc. This is a possibility. I will look into that further. > > If this is the case, then you can 'make config' again to de-select the > "compile kernel as ELF?" option and recompile...or you can upgrade to > ELF. > > Dale Scheetz ([EMAIL PROTECTED]) has written some good notes on how to > upgrade from 0.93r6 to 1.1 - he posts them semi-regularly to the debian > mailing lists - if you follow them to the point of updating to ELF ld.so > and libc5, then you can upgrade to the latest gcc and libc5-dev, then > you can compile an ELF kernel. > > Note, you may need to first compile an a.out kernel with ELF binary support > built in (NOT as a module - ld.so won't let you upgrade to the latest > version if ELF support is not in the kernel), reboot on that, and then do > the upgrade as written by Dale. > > > > I'd suggest upgrading to the beta 1.1, keeping track of (and reporting) > any bugs which affect you and upgrading only the packages affected as > fixes come out. When 1.1 goes from beta to release status, do a full > upgrade again. > > Debian 1.1 might still be called 'unstable', but that refers more to the > fact that packages are being upgraded every day with new versions. As far > as functionality goes, it's at least as stable and reliable as 0.93r6. > > The hard part is doing the initial upgrade from 0.93r6 to 1.1 - you've > got to take that slowly and carefully. As I mentioned, Dale has written > some very good instructions on how to do this. If you think about what > you're doing and pause for a second before hitting the enter key you > wont run into any trouble. After that, subsequent upgrades will be no > hassle at all - it's just the switch from a.out to ELF which makes the > upgrade a little dangerous if performed without thought. Is doing a slow upgrade from 0.93R6 to 1.1 a better idea than trying a clean installation of 1.1? I actually tried doing a complete wipe of my hard disk and installing 1.1 from scratch. Unfortunately, the packages at that time for lib5-dev, cpp, and gcc kept conflicting with each other and dselect would not allow me to install them (even though dselect suggested that I should be able to install thing properly). So, I wiped my hard drive and installed 0.93R6 which went without any problems. Have installation problems been reported for lib5-dev that have recently been fixed? Richard.. - Richard Dansereau Email: [EMAIL PROTECTED] Home page: http://pobox.com/~rdanse Electrical and Computer Engineering - University of Manitoba - Canada -
dpkg-ftp troubles
I am having trouble with dpkg-ftp 1.4.0. I repeatedly get this error when trying to install: Processing status file... Processing Package files... unstable... Argument "" isn't numeric in ncmp at /usr/lib/dpkg/methods/ftp/install line 99, chunk 1441 (#1) Argument "" isn't numeric in ncmp at /usr/lib/dpkg/methods/ftp/install line 99, chunk 1441. non-free... contrib... Any ideas? -- Joe ReinhardtDivision of Physiologic Imaging [EMAIL PROTECTED] Department of Radiology, JPP-3960 Telephone: 319-353-7258 University of Iowa College of Medicine FAX: 319-356-1503 200 Hawkins Drive, Iowa City, IA 52242
Re: more trouble with 1.1 upgrade
Scott Barker writes ("Re: more trouble with 1.1 upgrade"):
> Ian Jackson said:
> > Yes. cron needs to have savelog removed.
>
> ok. So what happens when I install the new cron, and /usr/bin/savelog isn't in
> it? Won't dpkg remove it, since /usr/bin/savelog has been removed from
> /var/lib/dpkg/info/base.list?
Err, bugger. I knew this --force-replaces thing was a bad idea.
If you do this you'll have to reinstall bsdutils, but there's nothing
really that can be done about it.
cron needs to be fixed.
Ian.
Re: Compiling the kernel..
Craig Sanders writes: > > > On Wed, 22 May 1996 [EMAIL PROTECTED] wrote: > > > This appears to contain the standard kernel release source tree but > > has a number of additional things (such as a nifty Tcl/Tk GUI for > > kernel configurations). > > "make xconfig" and "make menuconfig" are a standard part of the linux > kernel now...has been for most of the 1.3.x series kernels. > > > What is the procedure I should take to compile a kernel under debian > > and to take into account loadable modules, etc.? > > > > Also, if I want to get newer kernel releases is there a way to > > integrate it in with the additional Debian changes for /usr/src/linux? > > simplest way is to download "kernel_source-x.x.x.deb", use dpkg to > install it, and then: > > 1. cd /usr/src/linux > > 2. configure the kernel with: > >make config > -or- >make menuconfig > -or- >make xconfig > > 3. make dep ; make clean # this step may not be necessary. i'm not > # sure if debian.rules already does it or not. > # it can't hurt to do it, though...only takes a > # few minutes. > > 4. touch stamp-configure # if you don't do this, then debian.rules > # will overwrite your config with the standard > # debian kernel_image package config. > > 5. build the kernel image package: > > ./debian.rules kernel_image > > > This procedure will create a kernel_image-x.x.x.i386.deb package in > /usr/src, which can be installed with dpkg just like any other package. > reboot to run the new kernel. > > > > NOTE: if you are recompiling a kernel which is already installed, you > will probably want to rm -rf /lib/modules/x.x.x BEFORE you install the > new kernel. Otherwise that modules directory will be full of old junk > from the last compile. > > If you are currently running that version of the kernel, and using those > modules (i.e. with kerneld or modprobe) then you really should reboot as > soon as you've installed the new version > > procedure is: > > 1. build kernel version x.x.x > 2. rm -rf /lib/modules/x.x.x > 3. dpkg -i kernel_image.x.x.x.deb > 4. reboot > > Craig > I tried the procedure you (and a couple of others) suggested. I currently have debian 0.93R6 installed and am trying to compile the kernel from devel/source-1.3.64-0.deb Unfortunately, when I run "./debian.rules kernel_image" I get make: *** No rule to make target `kernel_image'. Stop. Am I doing something wrong? I also tried doing "make zImage" I get gcc -D__KERNEL__ -I/usr/src/linux-1.3.64/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -pipe -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -DNFS_ROOT="\"/tftpboot/%s\"" -c -o init/main.o init/main.c cc1: Invalid option `align-loops=2' cc1: Invalid option `align-jumps=2' cc1: Invalid option `align-functions=2' make: *** [init/main.o] Error 1 I do have gcc version 2.6.3 so I don't think that should be a problem. Any ideas? Richard.. - Richard Dansereau Email: [EMAIL PROTECTED] Home page: http://pobox.com/~rdanse Electrical and Computer Engineering - University of Manitoba - Canada -
dselect - please help test before full-internet beta
(Please note crosspost, and reply only to the appropriate list.) The dselect in dpkg 1.2.x has had several changes made to it which I hope will make it more powerful, less likely to encourage users to use it in ways which will seriously damage their system[1], and easier to see what's going on and what dselect will do. This has involved some reorganisation of internal code, though, and it's likely that I've introduced some bugs, some of which will be rather on the frequently-triggered side for a full-internet beta and for the subsequent full release. I'd therefore appreciate it if people who don't feel that dselect is altogether a bad thing would try it out - in particular, go into the selection screen and play with things to see if anything unusual happens. The rest of this message explains how your testing can be most useful: Make sure you're running the latest released version (currently 1.2.2; new versions will be announced on debian-changes). You'll probably want to reuse the `update available packages' option from the main menu after upgrading to 1.2.1 or later, as previous versions tended to record packages as available even if they weren't. Make sure that you have coredumps enabled (`ulimit -c unlimited') and that your current directory is writeable; if you get a coredump please gzip -9 and uuencode it and mail it to me at the address above (don't use Pine's attach file feature). Please _don't_ ask before sending it, unless the resulting message is larger than 5Mb. Run dselect inside `script'. If you get unexpected behaviour (eg, dependency screens that you think are a mistake) then it is especially important that you tell me *lots* about what was going on. Ideally I'd like to know what states the packages were in before you started (for example, by snatching a copy of /var/lib/dpkg/status as soon as the odd thing has happened and before dselect has had a chance to write the updates to it). I'll certainly want a copy of your /var/lib/dpkg/available, and any screenshots, session transcripts, comments about which keys you pressed, copies of /var/lib/dpkg/status immediately before and after running dselect &c would be very welcome. If you can reproduce a problem on demand then it would be especially useful for you to keep copies of your /var/lib/dpkg/available and status files for me; running dselect with the -D debugging option and sending me the (large) output would be good too (gzip -9 and uuencode it - and don't use Pine's attach file option). If you're reporting what appears to be a problem with dependency handling it would be helpful if you would try to fully understand what the dependencies &c of the packages in question mean, so that you're sure that dselect is wrong and you are right :-). If you would like to play around with the selection screen and then restore your previous settings you can safely do so by taking a copy of your /var/lib/dpkg/status before you enter dselect, go to the package selection display and play about, quit dselect and then restore your /var/lib/dpkg/status. Don't restore a copy of your /var/lib/dpkg/status which you took before an operation which actually tried to install, configure or remove packages, though ! Alternatively you can put status and available in a directory, and create an empty `updates' directory as a subdir there, and use --admindir to run with non-live data. I don't know how reliable this is - testing is welcome :-). Bugs reports about the display handling are also welcome, but somewhat less so unless they're critical. I know of three bugs that appear to be the fault of ncurses: (a) the bottom status line isn't filled across to the right correctly and often appears corrupted, (b) the arrow keys don't work after using the search facility, and (c) stretching the xterm window vertically triggers a display bug which is fixed by shrinking the window or resizing it horizontally. There is no need to report bugs you found to debian-bugs - simply mail them to me here. I won't forget about them, and if I can't deal with them straight away I'll file the bug. Suggestions for minor improvements to eg descriptive strings &c that don't involve code reorganisation are also welcome, but be prepared for me to disagree with you :-). There will be *no* further code reorganisation in dselect/dpkg before the release of Debian 1.1. Even then I'll still have had plenty of suggestions for what to do in respect of user interface improvements &c, so please don't send any more. If I have some free time I'll think about working on the novice mode user interface - If I do I'll initially write this as a `branch' off the main source code, I think, and integrate it later. If other people want to write different interfaces to dselect, competitors to parts of it, or whatever, that's fine by me; if they seem clueful I'll try to give them assistance and information. Thanks, Ian. [1] eg by hitting `-' on many packages (which means and has always meant `re
Re: Compiling the kernel..
On Thu, 23 May 1996 [EMAIL PROTECTED] wrote: > > The hard part is doing the initial upgrade from 0.93r6 to 1.1 - > > Is doing a slow upgrade from 0.93R6 to 1.1 a better idea than trying a > clean installation of 1.1? that depends on whether or not you've got data and config files you want to keep. Also, being able to upgrade without reformatting is one of the main benefits of debian - the upgrade from a.out to 1.1 is documented and tested well enough now that it's reasonably safe. (i say 'reasonably safe' as a disclaimer against truly astounding acts of creative incompetence :-) I've done both clean installations of beta 1.1 and upgrades from 0.93r6 several times on several different machines over the last few months. Both work fine. I'd say upgrading is easier because you don't have to make floppies. > I actually tried doing a complete wipe of my hard disk and installing > 1.1 from scratch. Unfortunately, the packages at that time for > lib5-dev, cpp, and gcc kept conflicting with each other and dselect > would not allow me to install them (even though dselect suggested that > I should be able to install thing properly). So, I wiped my hard > drive and installed 0.93R6 which went without any problems. Have > installation problems been reported for lib5-dev that have recently > been fixed? Version numbers for libc5 and libc5-dev are very important. They've got to match exactly. e.g. you can't install libc5-5.2.18-3 and libc5-dev-5.2.18-5, they must both be -5 versions. I ran into this one myself when I upgraded, and couldn't figure out what was going on until i noticed that the version numbers were slightly different. Make sure your copies of the .deb packages are up to date before starting the upgrade procedure. Easiest way to do this is to install the mirror package and mirror your local debian mirror site (configure mirror to exclude the source directories if you dont want them and also the non-i386 binary directories...i.e. get only non-free/, contrib/, and unstable/binary-i386) if you don't want to run mirror, just ftp what you need manually. This is a lot more work than setting up mirror to do what you want. Craig
Re: SCSI tape not detected
On Thu, 23 May 1996, Pino Smith wrote: > I have SCSI disks and they are detected as is the CD drive (SCSI as > well), so I assume I have SCSI support in the kernel. It looks more > like the kernel does not know there could be a SCSI tape. SCSI support, SCSI _disk_ support, SCSI _cdrom_ support, SCSI _generic_ support, SCSI _tape_ support and SCSI _controller_ support are all discrete units. You _MUST_ check whether this is so. Look at /usr/src/linux/.config and check whether CONFIG_CHR_DEV_ST is set to "y" or "m". If it is "n", then you have NO SCSI tape support. ---MAV (finger for PGP signature block) Marc A. Volovic ([EMAIL PROTECTED]) Linguists do it cunningly
Re: Compiling the kernel..
On Thu, 23 May 1996 [EMAIL PROTECTED] wrote: > I tried the procedure you (and a couple of others) suggested. I currently > have debian 0.93R6 installed and am trying to compile the kernel from > devel/source-1.3.64-0.deb You've got the wrong kernel version. These instructions only apply to recent kernel versions, 1.3.97 or later. > I also tried doing "make zImage" I get > gcc -D__KERNEL__ -I/usr/src/linux-1.3.64/include -Wall -Wstrict-prototypes > -O2 -fomit-frame-pointer -fno-strength-reduce -pipe -m486 -malign-loops=2 > -malign-jumps=2 -malign-functions=2 -DCPU=586 -DNFS_ROOT="\"/tftpboot/%s\"" > -c -o init/main.o init/main .c > cc1: Invalid option `align-loops=2' > cc1: Invalid option `align-jumps=2' > cc1: Invalid option `align-functions=2' > make: *** [init/main.o] Error 1 > > I do have gcc version 2.6.3 so I don't think that should be a problem. > Any ideas? No idea. As a wild guess i'd suspect that maybe you're trying to compile an ELF kernel with an a.out only gcc. If this is the case, then you can 'make config' again to de-select the "compile kernel as ELF?" option and recompile...or you can upgrade to ELF. Dale Scheetz ([EMAIL PROTECTED]) has written some good notes on how to upgrade from 0.93r6 to 1.1 - he posts them semi-regularly to the debian mailing lists - if you follow them to the point of updating to ELF ld.so and libc5, then you can upgrade to the latest gcc and libc5-dev, then you can compile an ELF kernel. Note, you may need to first compile an a.out kernel with ELF binary support built in (NOT as a module - ld.so won't let you upgrade to the latest version if ELF support is not in the kernel), reboot on that, and then do the upgrade as written by Dale. I'd suggest upgrading to the beta 1.1, keeping track of (and reporting) any bugs which affect you and upgrading only the packages affected as fixes come out. When 1.1 goes from beta to release status, do a full upgrade again. Debian 1.1 might still be called 'unstable', but that refers more to the fact that packages are being upgraded every day with new versions. As far as functionality goes, it's at least as stable and reliable as 0.93r6. The hard part is doing the initial upgrade from 0.93r6 to 1.1 - you've got to take that slowly and carefully. As I mentioned, Dale has written some very good instructions on how to do this. If you think about what you're doing and pause for a second before hitting the enter key you wont run into any trouble. After that, subsequent upgrades will be no hassle at all - it's just the switch from a.out to ELF which makes the upgrade a little dangerous if performed without thought. Craig
Re: regular (aka bsd) compress distribution?
Bruce Perens: > I'd be happy to see someone make a "compress" package and > distribute it _from_their_own_site_ . If you can do that, please > go ahead. We'll put a note in the main archive that you distribute > it so that people can find it. I guess that simply uploading it to sunsite or tsx-11 would work just fine. Nobody but Debian has problems with distributing compress... Red Hat, Slackware, FreeBSD, ... all have compress as part of the standard distribution. I don't think they all would do something that is against the law. Maybe something is wrong with the Debian's interpretation of the patent? Instead of debating, maybe we can just ask Unisys about this? I know gzip is better but, unlike compress, gzip is still not shipped with every UN*X system. compress is also used for X fonts. Does anyone know how to contact someone from Unisys who can give authoritative answer that Debian may (or may not) distribute compress? Too bad dpkg can't (yet) install RPMs. It would be nice to be able to buy a 5 CD set with both Debian and Red Hat, install Debian, then install the missing non-free-in-Debian-free-everywhere-else packages from the Red Hat CD. It shouldn't be impossible - most differences I've seen so far between these distributions are in startup scripts. And commercial software will ship as RPMs soon... Marek
really old bugs
I just went perusing the bug lists and noticed two things: The mirror at debian.org is severely out of date. The mirror maintainer seems to know this, as there is a message there saying so. I was wondering if this was going to be corrected soon? More importantly, I see bugs still listed (at the primary site) as outstanding which are over a year old! I can't imagine many of them are *actually* still not solved after that long. Is anything done to periodically clean obsolete bugs out of the list? (Yes, I am offering to be the bug-cleaner-outer, if someone is needed for the task). -- Scott Barker Linux Consultant [EMAIL PROTECTED] http://www.cuug.ab.ca:8001/~barkers/ (under construction) [ I try to reply to all e-mail within 5 days. If you don't ] [ get a response by then, I probably didn't get your e-mail ] [ (we have a sometimes sporadic connection to the internet) ] "The mark of an immature man is that he wants to die nobly for a cause, while the mark of a mature man is that he wants to live humbly for one." - William Stekel
