, 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
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
Hi,
Now that the bdflush package has been replaced by update - shouldn't the
binary-arch/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
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
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
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
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:
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,
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
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
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
11 matches
Mail list logo
