On Sat, Oct 10, 1998 at 01:56:06PM +1000, Stuart Lamble wrote:
The bootstrap compiler is distributed (mostly) as assembler
source, so they're clearly platform dependant. The sources
for the rest of the system are distributed as Modula 3 source
code, so they're clearly platform
Simple (conceptually) problem:
I'm working on packaging the pm3 Modula 3 distribution for
Debian, and have run into a problem. There are two tarballs
that are available for this: the bootstrap compiler, and the
sources for the rest of the system. Once M3 is up and running,
you can generate a
In a private email to me, Gergely Madarasz wrote:
Btw, I just see the note in the changelog that you dont have time to
maintain lyx... i could take it over.
Well, that note was accurate at the time I wrote it. :-) I'm about to
start full-time work, so I should have more time to maintain Debian
For those on debian-devel: this started with a discussion about various
CVS access methods for those on the Gnome mailing list. It then got
slightly sidetracked to discuss Modula 3 (CVSup is written in M3.)
Jim Pick [EMAIL PROTECTED] wrote:
Thomas G. Lockhart lockhart@alumni.caltech.edu writes:
[please cc any responses to me.]
Is anybody busy working on these? I ask because I'm fairly close to
(hopefully :) creating a working set of rules/control files/etc. for
compiling SRC Modula-3, and associated programs. If all goes well, I
should have them finished within a week or two.
I
[EMAIL PROTECTED] (Wichert Akkerman) wrote:
[EMAIL PROTECTED] (J.H.M.Dassen) wrote:
Package: vim
Version: 4.4-1
From the vim development pages:
Latest News
So - which is the latest beta? Please read the (latest) announcement so you
know what the new features are! Test them all and test
Well, after a lot of fiddling and hacking and threatening of dpkg, I finally
managed to get libelf compiling with 2.1.1.0 compliant sources. Before I
upload it, though, I want a few things cleared up:
1) Should I rename the package to libelf0 (Replaces: and Conflicts: libelf)
in the same
[EMAIL PROTECTED] (J.H.M.Dassen) wrote:
Package: vim
Version: 4.4-1
/usr/doc/vim/vim_tips.txt.gz explains how to make vim function with
compressed helpfiles (which are gzipped as per the guidelines)
in the section Compressing the help files.
However, this vim package doesn't use this tip:
David Frey [EMAIL PROTECTED] wrote:
This is (IMO) a bug in the upstream sources. (I'm not sure whether this
is confined to certain directories or not, especially since libc doesn't
have this problem.)
This is the way ELF-ld functions at the moment (as far as I understand it).
IMO the
Package: ldso
Version: 1.8.2-1
I've recently had problems linking programs non-statically with (e.g.) the
X11 libraries, etc. Static libraries are fine, shared have problems. Upon
investigation, and discussion with a friend, it appears that ld cannot find
files of the form:
libfoo.so.1
Michael Meskes [EMAIL PROTECTED] wrote:
lyx0.10.3-1
In case of emergency, I can take over this. (I use it myself, actually ... :-)
I've received a few emails since I took over vim, asking if vim 4.2
has yet been packaged in debian format. The stock response has been
that, since 4.2 introduced a condition - distribute vim on a CD-ROM,
and you should/must send me a copy of that CD-ROM - I decided not to.
Would it perhaps be
It didn't core dump on me, but it _did_ start going into an infinite
loop when the xterm reached around 180 columns. On investigation, the
problem appears to be the typedef:
typedef string char[160];
If the xterm is wider than around 160 characters, overruns start to
occur. This is Not a Good
Maintainer: Stuart Lamble [EMAIL PROTECTED]
Source: fsp
Version: 2.71-3
Binary: fsp
Architecture: i386 source
Description:
fsp: An alternative to anonymous FTP
Changes:
- Fixed a typo in fhostcmd.1 (c/o Michael Meskes)
- all man pages are now compressed with gzip -9
- added postinst script
[snipped]
Urgency: Low
^^^
Where a security fix is involved, shouldn't the urgency be a little bit
higher than low? (especially where the problem affects many systems.)
Ok, I've fiddled around, and have reached the stage where I can upload
libelf to master. The one question I have is: should it go into contrib,
or devel? Currently, the library is considered to be in alpha stages -
it's definitely usable, but there you are.
I seem to recall that alpha stuff
Michael Meskes wrote:
Ian Jackson writes:
No, because packages which depend on contrib packages must go in
contrib too.
Hmm, that wasn't what was said a while ago when we moved xforms.
I'd like to ask the other developers what they think. While I see th elogic
behind your approach I
The problem with this approach is that it breaks everything that assumes
that make is the GNU make - for instance, the kernel. And probably several
debian.rules files.
It would probably be a fair assumption to say that make, under Linux, is
GNU make: the average user would have this
Hmm. Forgot to mention that there's a new maintainer. Oh, well.
-BEGIN PGP SIGNED MESSAGE-
Date: 03 Aug 96 09:31 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Stuart Lamble [EMAIL PROTECTED]
Source: unzip
Version: 5.12-13
Binary: unzip
Architecture: i386 source
Another one that I forgot to mention the new maintainer in...oh, well,
put it down to a late night. :-)
-BEGIN PGP SIGNED MESSAGE-
Date: 03 Aug 96 09:37 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Stuart Lamble [EMAIL PROTECTED]
Source: zip
Version: 2.01-13
Binary: zip
07:30 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Stuart Lamble [EMAIL PROTECTED]
Source: vim
Version: 3.0-6
Binary: vim
Architecture: i386 source
Description:
vim: VI iMproved - enhanced vi editor
Changes:
New maintainer; fixed lack of multi-architecture support (Bug #3924
llucius wrote:
Actually, I've not gotten to The Next Step yet anyway. I finally bit
the bullet and downloaded XFree86 (whew!), compiled it, and am now going
through all the X related packages.
Speaking of X, as a member of the beta team (XFree86), I have access to
the source code for the
Mr Stuart Lamble writes:
annoyed that if I want support for my W32p (revision A), I have to go
to 3.1.2E - and it's not available for Debian. Net result: either I
have proper support for my card, and can't install new X-based packages
(dpkg barfs at the postinst and configuration stages
Package: dchanges
Version: 3.4
If dchanges finds an old style file name, it gives the following messages:
Deb file ok: libelf-dev_0.5.2-1_i386.deb
Deb file ok: libelf_0.5.2-1_i386.deb
WARNING: old style file name: libelf-0.5.2-1.tar.gz
should be: libelf_0.5.2-1.deb
WARNING: old style
24 matches
Mail list logo