Re: netpbm status?
Hi, Chris Lawrence wrote: [actually, this is what Susan wrote a while back] > Hi Chris -- > I actually saw a couple of files that I thought I might add to netpbm, > i.e., some that were tag-alongs that were developed after the 1994 release. > I'm planning on > a) putting them all into netpbm, and > b) separating netpbm into a free and non-free part. > > Right now, I'm waiting on Frank Neumann to get back from South America > so he can tell me if he's willing to release the 7 programs he wrote > under the GPL. Wow, I was to South America? Interesting to know. :-) > (Plus, I'm plugging away at the FAQ.) > > I'll let you know when I get back to nepbm -- it'll probably be toward > the end of April, since Frank won't be back til mid-April. I in fact answered Susan's mail very delayed, and when I did, I allowed her to use my little programs for Debian (they could have been GPLed all the time, but I really didn't know better when I hacked them up). I also pointed Susan to a collegue of mine, Ingo Wilken, who is sort-of trying to maintain netpbm since it was abandoned by this swedish guy whose names escapes me at the moment..anyway, Ingo wants to release a new netpbm some day, and I believe it will help quite a lot if people push him a bit.. that's at least what I have been doing for the last 8 weeks, without much success so far. :-} Frank -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: binary-alpha and binary-sparc directories
Hi, Ian Jackson wrote: > As Matt Bailey suggests, I think separate Incoming directories is a > better solution. I'm from the m68k section, and although it's kind of you to set up the directories for our uploads, I believe the main development of Debian/m68k is going to be done with the german ftp server at Mainz. I can't speak for the other sites here in Europe, but at least from Oldenburg (where I am) ftp.debian.org is almost unreachable (have been up to 30 hops). Also, most active developers seem to come from Europe, so they will probably agree with me. Of course this does not mean the entire tree won't get mirrored to ftp.debian.org once we have something usable. But for now I guess ftp.uni-mainz.de is the better choice for us (especially when seeing this message at ftp.debian.org all the time: 530-You are currently user 150 out of a possible 150 in your class. [..] 530 User ftp access denied. (which, btw, is funny - the count is off by one :-) > > It seems to me that packages will need a primary maintainer, who > > would be responsible for the source package, and an architecture > > specific maintainer for each supported binary package. One person > > could act in all capacities, of course, but I'd expect that at least > > some packages would have different maintainers for the different > > architectures. Ok, so what should we do? I made a few attempts at just unpacking some packages from base/ and blindly doing make -f debian.rules binaryon my Amiga, and only very few packages ran out of the box. I hope the changes will only be minor in most cases, and so it would be best for us (m68k) if we could just contact the current "x86" maintainer of a package if it needs changes. That would mean digging out his name/E-Mail out of the Packages file, right? Are there any serious reasons why this cannot be done? (except, of course, for more work for the primary maintainer). > > The way I see this working, architecture-specific maintainers with > > the ability to address architecture-specific bug reports and do > > architecture-specific testing would feed architecture-specific > > fixes and patches to the primary package maintainer. Primary > > package maintainers having, say, a sparc would install alpha > > or i386 patches blindly, relying on the testing done by the > > alpha and i386 maintainers, and issue a package revision update. > > Yes. Sounds ok to me. Architecture-specific bugs for m68k will be discussed in our own debian-m68k mailing list, and if a package maintainer discovers a real problem that is architecture-independent, he would have to cooperate with the primary maintainer (where I'd like to see the corresponding person from the x86 staff to take this over). Comments? Frank
curses/ncurses
Hi, short question about usage of curses/ncurses in Debian: If I see it correctly, the old curses library is still the "default" curses library, while libncurses (which is only built static) is only an add-on. I thought I had heard about plans to fully replace bsd-curses with ncurses - is this going to happen, or is the ncurses API still changing too fast to be of use for that purpose? (Note that newer libc versions (5.2.16) come without libcurses, libdbm, libgdbm and libtermcap). I was only wondering against what curses lib I should link e.g. ae (my current system isn't yet Debian - I have to bootstrap myself :) Frank
Bug#3985: Wrong parameter type in src/getfd.c
Package: kbd
Version: 0.91-3
I wondered why the 'loadkeys' program didn't work as expected on m68k,
and then I found a little bug in src/getfd.c: It determines the keyboard
type via an ioctl (KDGKBTYPE) which returns a char on the kernel side, but
is put into a 'long' variable. This just happens to work on i386, but breaks
on m68k due to the endianess. Below is a patch.
Frank
Debian-1.1, libc5.2.18, kernel 2.0.8.
PS: Checking for just one explicit keyboard type (KB_101) is not good
either, but that will be fixed later.
--- cut here ---
*** src/getfd.c.origThu Aug 1 00:30:13 MET DST 1996
--- src/getfd.c Thu Aug 1 00:30:23 MET DST 1996
***
*** 14,20
static int
is_a_console(int fd) {
! long arg;
arg = 0;
return (ioctl(fd, KDGKBTYPE, &arg) == 0 && arg == KB_101);
--- 14,20
static int
is_a_console(int fd) {
! unsigned char arg;
arg = 0;
return (ioctl(fd, KDGKBTYPE, &arg) == 0 && arg == KB_101);
Bug#3951: kernel-image-2.0.7-0 postinst looks for /bin/perl
Hi, Graham William wrote: > Package: kernel-image > Version: 2.0.7-0 > > The postinst and prerm scripts of kernel-image have as their first > line: > > #! /bin/perl > > My vanilla installation of Debian 1.1 seems to have perl only in > /usr/bin/perl. I noticed this too, after having built a base.tar.gz for Debian on m68k. The bug is not in kernel-headers, but in boot-floppies, which failed to create the link for the base system. boot-floppies-1.1.1.10 fixed it. The bug report should be closed (I won't do that, I'm not the maintainer ;-), but a new base should probably be built. Frank (running a pretty usable 'rex' Debian/m68k for a week now)
Re: Bug#4078: lynx should be in `contrib'
Hi, Michael Meskes wrote: > I'd like to ask the other developers what they think. While I see th elogic > behind your approach I still think LyX should be an official part of Debian. > > What happens if I recompile it statically? Would it go into the standard > tree then? Being a Debian/m68k user, my opinion is: _Each_ package that is in the standard tree should be compilable for all platforms (ok, there are packages where this does not exactly make sense, like base/mbr on an Amiga, but you get the idea). This also means that for all those packages AND the packages they depend on sources have to be available. LyX requires XForms. XForms is currently not available for m68k (I've started talking to the author, but this might take a while). Even IF we once have XForms for m68k, nobody still has the sources. So I'd say: Both XForms and LyX go into non-free. Compiling/linking LyX statically doesn't change this point, IMHO. Frank
Re: xforms for both architectures!
Hi, Michael Meskes wrote: > Could anyone with an m68k machine please check if the packages work? There's > no real change to the i386 version except the maintainer. I did so - shouldn't the runtime version depend on elf-x11r6lib? DEBIAN/control: Package: xforms Version: 0.81-3 Architecture: m68k Depends: libc5 (>= 5.2.18) Regards, Frank
Newer version of gdb and binutils?
Hi, there have been newer versions of these two programs out for some time now: gdb-4.16 (current in Debian: 4.15) binutils-2.7 (current in Debian: 2.6) David, are you working on debianizing the newer versions? I'm pretty much interested in a newer binutils, because the current Debian version does not generate correct code for the 68060 processor (like the current 2.0.18 kernel on accelerated m68k machines). A patch to gdb-4.16 has also been made available by Andreas Schwab to make it compile on m68k. If you want, I can send it to you. Thanks, Frank
Incorrect filename in m68k archive
Hi, there is one file in the rex/binary-m68k archive which has a wrong name (base/tar_1.11.8-5_m68k.deb, where the _m68k is wrong). This is probably so because it was moved in manually instead of being checked in by Guy's scripts. Is it ok to manually rename this file, or will that cause some other listings (Packages?) to become inconsistent with what's in the archive? Frank
Diffs-only for XFree?
Hi, I noticed that in the rex/source archive there is currently only the complete XFree-3.1.2 source tree. Are there any means to get ahold of just the Debian specific diffs for it, even if they are quite a lot? We need to get X11 for m68k debianized, but having to extract the changes that were made from the complete source tree myself is..somewhat dumb if there is another way. Thanks, Frank
Re: Diffs-only for XFree?
Hi, Steve Early wrote: [Debian diffs for X11 source tree] > Debian-specific diffs were hard to produce under the old scheme of > things because of the strange way in which the upstream source was > packaged. The version of the X packages that I will release in the new > source packaging format ought to be a lot more usable. Ok, sounds good - any estimations on the release date of this repackaged version? Do you want to wait for the stable 3.1.2 release first? > I assume you don't use XFree86 itself on the m68k platforms, and you > just want to look at the packaging style? Well, I do - for a while our m68k X11 system was just a pile of .bin.tar.gz archives plus large diffs, but Geert Uytterhoeven (m68k hacker) has joined the XFree86 team some months ago, and the current XFree-3.1.2 beta releases (where are we? -G?) contain m68k changes, and the binary distributions also come with complete m68k binaries. We don't use the PC-ish VGA/SVGA etc. drivers, but a different concept (the kernel based framebuffer device driver). Anyway - 'our' X11 is also XFree86 now (although the m68k changes are under a new directory which is nicely named 'xfree68'. :-) Once you convert the XFree86 source tree to the new source format, adding the architecture changes for m68k shouldn't be too hard, I think. Frank
Remove bdflush*.deb?
Hi, Now that the bdflush package has been replaced by update - shouldn't the binary-/base/bdflush*.deb files be removed for all architectures? Or are they still need for reasons I fail to see? Frank (Remember there is no 'bdflush' source package, neither is there an 'update' source package - they get created from util-linux).
Re: Remove bdflush*.deb?
Hi, Dominik Kubla wrote: > Just to put things straight: > * update was replaced by bdflush > * bdflush is now obsolete because of the kflushd kernel process I _was_ wrong in thinking update and bdflush had no source packages of their own (thanks, Guy), but I'm pretty sure I'm not wrong in thinking it's the other way around (update replacing bdflush :-). Why would otherwise the update* files have a much newer stamp date and be uploaded in the new source format? Oh well, what the heck, Frank
Bug#4523: strace gives strange 'umoven: I/O error' messages
Package: strace
Version: 3.1-2
When tracing programs, I sometimes see messages like this:
[..]
mprotect(0x8000, 20797, PROT_READ|PROT_EXEC) = 0
mprotect(0xc0008000, 386288, PROT_READ|PROT_EXEC) = 0
mprotect(0xc000, 15787, PROT_READ|PROT_EXEC) = 0
open(ptrace: umoven: I/O error
^
I only tried this on m68k, but I heard it also happens on i386. Andreas
Schwab suggested a fix, which at least works for me; I hope it will also
work for anyone else:
--- strace-3.1/util.c.~1~ Tue May 21 05:32:23 1996
+++ strace-3.1/util.c Tue Sep 3 14:24:00 1996
@@ -604,7 +604,7 @@
int len;
char *laddr;
{
-#ifndef SUNOS4
+#if !defined (SUNOS4) && !defined (LINUX)
return umoven(tcp, addr, len, laddr);
#else /* SUNOS4 */
int pid = tcp->pid;
Greetings,
Frank
