Re: netpbm status?

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? In

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 ft

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 go

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

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 bui

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 us

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: m6

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 doe

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 othe

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 m

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 ou

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 - th

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 thin

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 ^^