Re: Sources consisting of multiple tarballs
> 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 _in_dependant. Unfortunately, > > the pm3 makefiles are setup in such a way as to require the > > bootstrap sources to be unpacked as part of the Modula 3 source > > code tree heirarchy. > > Couldn't you extract the arch dep parts in different subdirectories and move > them to the correct place in the debian/rules file just before building? > So you would put all sources in one source package. I could do that, yes. The main problem is that, as far as I can tell, there are currently only i386 sources for the arch dependant stuff at the upstream site (the address for which I've misplaced.. d'oh..) Doing things this way would entail a new source package each time a new architecture is bootstrapped. Probably the cleanest way overall, though, when all's said and done.. and no doubt Guy (or whoever's currently maintaining the FTP archive) would be happy to assist with fixing source packages and the like. Thanks for the suggestion.
Modula 3 packages
[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 really, really, really don't have time this semester to maintain them properly, though ... when November rolls around, I'll be happy to do so, but before then, I'll be flat out with honours related things (including the project... joy. Not.. ;) If anybody would be willing to maintain them properly, I'll be happy to send off a copy of the Debian files, and appropriate diffs. Otherwise, they'll probably languish in orphaned obscurity ;) Oh, yes - one other problem is that the bootstrap compiler is provided as source code. i386 assembler source, that is. [EMAIL PROTECTED] (last time I tried it - some months back) indicated that SRC M3 is not really being supported by DEC in any significant way - so it's unlikely it'll be available for the m68k, Alpha, PowerPC, MIPS, Sparc, ... ports (unless one of the other bootstrap sets can be used instead.. this might be possible for the Alpha. I don't know; I only have a 486.) Cheers, Stuart. (One time Debian developer, hoping to find the time once his course is finished to rejoin. :) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Modula-3 packages (Re: Experimental Anon-CVS Access)
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" writes: > >> We started using CVSup for the PostgreSQL project back in September. We >> got great support from the developer, John Polstra <[EMAIL PROTECTED]>, >> and it has been working well^H^H^H^H very well for us since. > >Is that the size of Modula 3 the only big problem? Yes. The other problem -- much smaller -- is that the CVSup makefiles are very FreeBSD-specific. That's easily got around, though.. they only invoke m3build for each directory. (AFAICT) >> The biggest downside is the cost of the first >> installation: ~200MB to install Modula3! (This is my recollection, >> and there may be ways to shrink that substantially.) > >That's what's holding me back on Linux - there isn't a Debian package of >Modula 3, and it looks like a big job to make one up. It is. Believe me. I've got a preliminary package virtually finished of Modula 3 -- it's working quite nicely, actually. On and off, it took me about five or six months to do it (mind you, that was in the middle of the university year, so it probably would have taken about one month otherwise.) The only thing that's really holding me back from releasing it is the problem of producing both libc5- and libc6-based shared libraries. (Oh, and as yet, I haven't compiled it against libc6.) If the general consensus is that this isn't a problem, I'll be more than happy to downgrade (currently running a sort-of-upgraded-to-hamm system :), and produce the packages. As for shrinking the ~200MB for Modula 3 -- that's easily done. I could provide (libc5-based, unfortunately) shared libraries for M3 programs -- libm3, etc. -- which require around 3 or 4MB; or CVSup can be linked statically (which dramatically reduces that overhead.) Once I've got M3 working to my satisfaction, it'll go into experimental (I _definitely_ want feedback from M3 users with regards to how I've split up the packages). When it's in the main distribution, I'll also be packaging up CVSup, which should be fairly easy. (especially in comparison to M3 :-) Problems: * University closes on Wednesday (24th December), re-opening on January 5th. * I look like starting full-time work on January 12th (assuming all goes well with various interviews, etc.. I've made it past the first interview for a job I'm rather interested in.) * I _don't_ have any Internet connection other than Monash. * My Monash accounts will be (mostly) deleted around the end of February. * I don't know if/when I'll be able to get Internet access from home. (my father's being a _real_ stick-in-the-mud in this respect -- and besides, I can't afford a second phone line right now, which, as far as my father's concerned, is a pre-requisite. Ah, the joys of living at home with the parents.. :-/ ) The first issue isn't a major hassle. Neither is the second, as I'll still be able to hop onto university machines for a while. The third and fourth issues _are_ the hassles at the moment -- I don't know if I'll be able to keep everything up-to-date. As things stand, I'm hoping that a colleague will keep open my accounts on certain systems in the library. If that's the case, it'll be a simple matter to use those systems to keep in touch until I get full connectivity through an ISP of some sort. Otherwise... I'll put copies of the debian/ directory (from the bootstrap compiler and the Modula-3 sources) on my webpage, and email debian-devel when it's accessible. Somebody else wrote, in a subsequent email message: > I think someone with programming experience and Debian package > building experience could put together a M3 package with no more > trouble than doing something like libc6... non-trivial, but not > undoable. If it's not done in two years, I'll take a shot at it. As I've already said, it's practically done. I'm happy to make my work available to those who are interested. Be warned: a lot of the work is done in a number of shell scripts that make extensive use of sed. They probably should be rewritten in Perl; I've started doing so, but since I'm also learning Perl as I go, it'll take some time. :-) Build time: I have a 486 DX4-100, with 48MB of RAM, and a fair chunk (2.1G, I think) of (IDE) hard drive. It takes around 3 to 4 hours from start to finish. (This includes all the shuffling around of files into the Debian package heirarchy, the generation of diff files, etc.) Cheers.. Merry Christmas, Happy New Year, etc. to all involved in the Debian and Gnome projects. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#16663: lyx: depends on xforms0
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 packages than I did whilst at university. The key problem is Internet access. I have several accounts, all at Monash University: * Computer center systems ([EMAIL PROTECTED], [EMAIL PROTECTED]). These will be deleted any time soon (they're staff accounts, I no longer work as a casual at Monash.) * Yoyo account ([EMAIL PROTECTED]). Should last until at least March, possibly April or May depending on the sysadmin. * Novell account ([EMAIL PROTECTED]). Will be disabled at the end of February. * Accounts on Linux systems in the library ([EMAIL PROTECTED]). Should last indefinitely (I know the sysadmin ;-) I'm intending to get myself a permanent connection to my home (yes, I'm addicted to email, amongst other things :-) When that happens, I'll be picking up again with the project: * LyX (if nobody else has taken it over. I'm _sure_ somebody said that he'd do it..) * fsp (it seems to be unwanted, unloved, ... ;-) * Modula-3 (compiles into packages just fine with libc5; there are issues to deal with under libc6.) * cvsup (once Modula-3 is working properly.) I should be back in action within a month or two. As for LyX -- the best way to proceed would probably be to package 0.11.46 or something of the sort. (0.12.0pre6, perhaps?) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Sources consisting of multiple tarballs
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 bootstrap compiler for a different platform, so the system as a whole is not dependant upon a particular platform (eg: i386 Linux.) 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 _in_dependant. Unfortunately, the pm3 makefiles are setup in such a way as to require the bootstrap sources to be unpacked as part of the Modula 3 source code tree heirarchy. I don't want to have a source package on the Debian archives that is platform dependant; that's just silly (and counterproductive: most of it will be platform independant.) Is it possible to say to dpkg that "this directory is platform dependant, that directory is platform independant, so package them up separately to save space"? Or will I have to bite the bullet and distribute one set of sources for the i386, and in the future be faced with redundant source sets for the Alpha and other platforms? Comments and suggestions are much sought after. (Status of the packaging? Um... back to square one after ditching Digital's SRC M3, due to its inability to support glibc..)
Re: /usr/local (again)
[EMAIL PROTECTED] (Bruce Perens) wrote: [snipped] >Ouch! > >What I object to is another question in the postinst. I installed several >Debian systems last week, and there were too many questions - the effect >was that you could not let the installation run unattended. What's worse, >some maintainers have placed questions in the pre-install script - and >then you get questions all during the installation instead of just at the >end. [...] Just a suggestion (and probably not a very good one): where a package needs to ask a question, perhaps it'd be appropriate to have a script postinst.questions (or some such) which can be run after all the other packages have been installed and configured? At least that way, all the questions would bombard you at once, instead of halting installation halfway through. By all means, shoot me down in flames if you want to. :-) (As an incidental aside, the reason I've got a question in the fsp postinst is that it didn't make a great deal of sense to split fsp into two packages - fspclient and fspserver, say - when the server is only about 30kB. If that is wrong, by all means let me know, and I'll correct it; it would be one way of getting rid of at least one postinst question :-)
Re: Packages to give away
Michael Meskes <[EMAIL PROTECTED]> wrote: >lyx0.10.3-1 In case of emergency, I can take over this. (I use it myself, actually ... :-)
Bug#4530: ld cannot find most shared libraries
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 programmer's manual (chapter 12) should mention that you should >install the -dev packages, if you wish to compile something, since the >links are only >contained in the -dev packages. Ah. The problem is, I'm using the XFree86 3.1.2D libraries, with the server currently at 3.1.2Ek (I think; can't remember the exact version.) These libraries _don't_ come with such symlinks, and they aren't added by ldconfig at any point. (that, as an incidental aside, is why vim 4.4 - when I get around to finishing it off, and uploading it - won't have support for X compiled in: incompatible libraries.) This behaviour is extremely annoying, especially if I have to install some other library that isn't available as a Debian package for some reason. (I don't really have the time to maintain more packages - university work and all that.) At least I can work around it. Cheers.
Bug#4594: VIM: no help, no conffiles
[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: That'll teach me not to package up something without R'ingTFM :-) >Also, /usr/doc/vim/changelog.debian.gz says: > * redirected global vimrc/gvimrc to /etc >but the package doesn't include these files at all. It should include >at least empty versions of them, as conffiles. Fair comment, I'd guess. I'll fiddle around when I get time; unfortunately, I've got lab work and assignments coming out of my ears at the moment. :-( (Ah, university...what fun.) I appreciate the bug report.
Bug#4594: VIM: no help, no conffiles
[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 them
>thoroughly! Thanks!! Outlook:
>
>960623
> Release of vim4.2 to the public
>
>So I guess the version should be 4.2-1 instead of 4.4-1?
No, 4.4 was released on Bram's ftp site a little while ago. I elected to
package it up rather than 4.2 because 4.2 has a somewhat more restrictive
copyright ("if you include it on a CD, you should send me a copy", or
words to that effect.) As far as I can tell, 4.4, although considered a
beta, is mainly bugfixes to 4.2.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
XF86 betas (Re: D68K: The next step...)
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 XF86 betas. Would it be worthwhile setting up packages for these in the contrib section? In particular, I'm kind of 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), or I'm stuck with the SVGA server. Before you ask - no, I am _not_ going to provide the source code to the betas to the world in general. Nor diffs. (I'm just trying to get 16/24bpp modes going on the cards - and getting nowhere fast, it seems. Oh well, maybe by Feb next year...) -- I'm on a low-fat, high stress diet: coffee and fingernails.
Re: XF86 betas (Re: D68K: The next step...)
> 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), or I'm stuck with > >the SVGA server. > > Not at all. Install the svga server using dselect. Put it on hold. > Get the 3.1.2E server binary, install it, adjust /etc/X11/config. > > I'm doing just this to run the current Mach64 card, since my RAMDAC > isn't supported by the non-beta 3.1.2. No problems at all. Strictly speaking, if you install the 3.1.2E server, you're supposed to install the 3.1.2D libs as well - 3.1.2D was a complete replacement for 3.1.2, and 3.1.2E is supposed to be a drop-in server replacement for the 3.1.2D server when it expired. That's what I'm carping on about. :-) -- I'm on a low-fat, high stress diet: coffee and fingernails.
Bug#4003: minor typo in dchanges
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 file name: libelf-0.5.2-1.diff.gz
should be: libelf_0.5.2-1.diff.gz
File ok: libelf_0.5.2-1.changes
2 warning(s) - hit return to continue
The problem with .tar.gz can be fixed by applying the following (trivial :)
diff.
--- dchanges.oldWed Jul 31 20:56:47 1996
+++ dchangesWed Jul 31 20:57:36 1996
@@ -477,7 +477,7 @@
if [ "$TAR_FN" = "${SOURCE}-${VERSION}.tar.gz" ]
then
stderr "WARNING: old style file name: ${TAR_FN}"
- warning " should be: ${SOURCE}_${VERSION}.deb"
+ warning " should be: ${SOURCE}_${VERSION}.tar.gz"
else
stderr "ERROR: Source file incorrectly named: $TAR_FN"
error " expected ${SOURCE}_${VERSION}.tar.gz"
unzip_5.12-13 uploaded to master
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 Description: unzip: De-archiver for .zip files Changes: Uses dpkg-name to move the new .deb file rather than manually moving it; fixed lack of multi-architecture support (Bug #3916); added a long description (Bug #3693) Files: 283be7478726af74046fc37c958e65ce 376767 non-free - unzip_5.12-13.tar.gz 61747a13a7163f0f7e9d247189e539d6 5410 non-free - unzip_5.12-13.diff.gz 3a1a2042288e6a1a3e3ae64aadbaba4d 81566 non-free extra unzip_5.12-13_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBMgQX/dancbR/eGtJAQHMJAP+Pc4mV71x3UnrutnvsuYb9I9gt7OeVFfC QGAVL0UrBbFoxH4msnwa6jpaueHN4a2NeefEzsnmmrDIRNmJcu+7y0Secbn3F7e3 l6od2hdWEghHqUTiRRsoAffctenF0g/n5PKDawaDp47u4iZmnSIVqSyEF2M5d3dJ WVFVedlI+j0= =z6hU -END PGP SIGNATURE-
zip_2.01-13 uploaded to master
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 Architecture: i386 source Description: zip: Archiver for .zip files Changes: Uses dpkg-name rather than manually moving the .deb file; added multi-architecture support (Bug #3934); added a long description (Bug #3692) Files: 212592616f41a0802ca3c213b61ff458 232659 non-free - zip_2.01-13.tar.gz 2a1d9db4160065719a8d6fa150d9ad14 5544 non-free - zip_2.01-13.diff.gz 81aa10e764b4038207772ce46b60eaae 59380 non-free extra zip_2.01-13_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBMgQYLtancbR/eGtJAQH+hQQAibLxVlr11FKerBman8PjDDbilI7AcJBf fvgoG1tiRK8HRdsUtYhInAj5Dqt794UBNIzOrrA/Ra7C1zuquDjw8fRzc1E9BMhD GfCZahwnkRiuzRF4fI8sVl6XQzwNGmNJt30hgxZN+Zy0IwcgUGnhRstjFJYCVX6t RCFW8B/qtEA= =lWdg -END PGP SIGNATURE-
vim_3.0-6 uploaded to master
Hopefully, this will be the last modifications made to vim 3.0 - version 4.2 is out (with restrictions on distribution on CDs), and 4.3 is due in a few weeks (without those restrictions). I'll be upgrading the sources to 4.3 when it's released. -BEGIN PGP SIGNED MESSAGE- Date: 02 Aug 96 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); added a "Depends" field (now depends on libc5 and ncurses3.0, as it should); corrected the permissions of postinst and prerm. Files: e0cd25093f4a8889f6f5a4a41ab9d4d3 470134 editors - vim_3.0-6.tar.gz 6c9dbcfd3e864dd448d00114408b49b0 15989 editors - vim_3.0-6.diff.gz 69ae44cfc446937a191785445c5f6bd2 20 editors optional vim_3.0-6_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBMgQYGtancbR/eGtJAQE4+AQAlU7zHAV8gLtFxwMpbGVuaOXf47ka6UNT N0pQ5br0go5WATQR6zlTsuBTzPZkZ8HPBnqqChH07LyKGRHrHPoMCXidorE380Ex zwVM9yYY8peFHyYc4BJccyQLY7WZrd1eW1K3nS0J/+ldBTtAZVUT/fMd95W+zGO/ JBCUSCIvPlk= =XlU+ -END PGP SIGNATURE-
Re: New virtual packages suggestion (make)
> 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 installed. I very much doubt that anybody, except very serious developers, would have any other version of make installed. I don't believe that this sort of a change is necessary. -- Windows is not the answer. Windows is the question. Linux is the answer. http://sunsite.unc.edu/mdw/ for all your PC software requirements. ;-)
Re: Bug#4078: lynx should be in `contrib'
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 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? If you're going to recompile it statically, I beg of you, provide a non- statically linked version too (in a separate package, perhaps). One of my major gripes about many programs is that they are larger than they need to be, because they are statically linked, and I've got the libraries installed on my system. I've only got 350MB allocated to Linux...! :-) -- Windows is not the answer. Windows is the question. Linux is the answer. http://sunsite.unc.edu/mdw/ for all your PC software requirements. ;-)
Re: CC's on this mailing list
> Dale Scheetz <[EMAIL PROTECTED]> writes: > > > In fact it would be nice if this message didn't go to you twice, but > > I don't see any easy way to avoid this, short of writing more > > functionality into the list manager. > > I may have already said this, but for those interested, gnus will > generally remove duplicates for you if you want it to. It keeps a > cache of incoming mail message ID's and can be cofigured to do > anything you want with the duplicates. I have it place them in a > separate mail group which I just trash every now and then. All very nice, but it dodges the major reason for people disliking duplicate copies of messages: they pay for their PPP link (or UUCP feed, or whatever). Identifying duplicates by their message IDs means that you have to download both messages, unless you can do the filtering at your ISP's end of the link. I'm not overly concerned personally at the moment - I'm at university, and the government pays for my feed :-) - but it's generally not good etiquette full stop. -- Windows is not the answer. Windows is the question. Linux is the answer. http://sunsite.unc.edu/mdw/ for all your PC software requirements. ;-)
Bug#4161: dev/idsn instead of isdn in MAKEDEV
> Package: base > Version: 1.1.0-14 > > the: > makedev idsn$no c 45 $no $system > makedev idsnctrl$no c 45 `math 64 + $no` $system > should read: > makedev idsn$no c 45 $no $system > makedev idsnctrl$no c 45 `math 64 + $no` $system You mean: should read: makedev isdn$no c 45 $no $system makedev [EMAIL PROTECTED] c 45 `math 64 + $no` $system perhaps? :-)
Location for libelf?
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 should go into contrib; but recent discussion on this list appears to contradict that. Anybody want to come down one way or the other? Cheers (and thanks).
Re: Uploaded: mount 2.5l-1
[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.)
fsp_2.71-3 and libelf_0.5.2-1 uploaded
I've finally got around to doing these. I'm not entirely sure that libelf belongs in devel, but since nobody has responded to my queries on this matter... shrug. Bug me if I'm wrong. -BEGIN PGP SIGNED MESSAGE- Date: 23 Aug 96 11:07 UT Format: 1.6 Distribution: unstable Urgency: Low 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 to automatically add fspd to /etc/inetd.conf - added corresponding prerm to disable fspd. :-) (thanks to Michael Meskes for his help with these) - moved fspd.conf from the examples directory to /etc - added /etc/fspd.conf to the (new :-) conffiles listing - moved /usr/doc/examples/fsp to /usr/doc/fsp/examples - added a changelog (probably not in the right format, though), - removed the changes list from the copyright information file. Files: 3b5519778f783eaffaa6a00c0e3565c5 158691 net - fsp_2.71-3.tar.gz 1348cbec478132d88556d9ab7acc0bea 17400 net - fsp_2.71-3.diff.gz 8ee57ea4d9b6337a934ee6f8df8ae14a 81032 net optional fsp_2.71-3_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBMh+t6tancbR/eGtJAQECigQAucXxtLYLm5uofQxsgpHb5M+Yw5kg8YVS 57+rdQLTwjGvVpHHAlGfe6JEkQYkCi+ItqIuajPPpKqaoK9SIhfd8Ym773s+eXb6 2QJeIrIVyMT+Z9YccUlYf+4VfPPiwCqJm/sTb7lpyIjmeBP6k/WjrJ8uwgMjHY3q TBbX4xp8H00= =mre4 -END PGP SIGNATURE- -BEGIN PGP SIGNED MESSAGE- Date: 24 Aug 96 09:01 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Stuart Lamble <[EMAIL PROTECTED]> Source: libelf Version: 0.5.2-1 Binary: libelf-dev libelf Architecture: i386 source Description: libelf-dev: an ELF object file access library (development files) libelf: an ELF object file access library Changes: New packages - added the Debian control files. Files: 8db6879839857d86c9b92188b2f8a2dd 56314 devel - libelf_0.5.2-1.tar.gz c1b1205b7dc23a4bc3a8a9c597726498 2376 devel - libelf_0.5.2-1.diff.gz 23bb5fa903aec29b20f881e60a101f98 67034 devel Optional libelf-dev_0.5.2-1_i386.deb 80d5d2fea886ebbd69d6b47de2d1d61f 51204 devel Optional libelf_0.5.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBMh+t+9ancbR/eGtJAQFphQP/XTkDNGWGeK1/cG0FyVNlBokTMBRDfbVh uPfum1aHmxmOGuD8c1Y+z8PJGPp24Dm969mQJps8d1GGlc4FUx2cmFW9Hw1sEyCr ksYx3Z4OUX62JNTkMXQ+NPGzDfhj8rCxdx6cHJPAhulnjk+BeZ9hrAIMg7MfX2Gw rts2wEk7uOw= =SJU2 -END PGP SIGNATURE-
Bug#4272: ncftp core dumping
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 Thing(tm). Fixing this is not incredibly difficult, but it _is_ tedious - I had a quick try yesterday, and ncftp definitely started core dumping with the quick and dirty fix I tried. *sighs* Anybody want to forward this bug report (with this note attached :-) to the upstream author? (the submitter was correct when he said he thought it was an ncftp bug - it most definitely is.) In the worst case, I'll submit a diff around the end of the year. (don't have time before then to even _think_ about fiddling around with code that's not mine to worry about. :-)
vim 4.2?
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 reasonable to package up 4.2, and place it in the non-free section, especially considering that 4.3 (currently in beta test) will remove that condition? It's been at least a month since I took over 3.0, and a number of people are probably getting impatient :-) Cheers.
Bug#4530: ld cannot find most shared libraries
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 libfoo.so.1.2.3 etc. - there has to be a symlink libfoo.so for libfoo to be found. Upon creating such symlinks, everything worked fine. (well, once I got rid of the /lib/libc.so => /lib/libc.so.4 link, that is :-) Oops. :) 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.)
contemplations of libelf
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 way that libc has libc4 and libc5? 2) Since libelf has a couple of header files also found in libc (which really shouldn't be there IMO, since libc doesn't implement those functions), I've added a Replaces: libc. Is this a Bad Thing(tm)? (it seemed the right thing to do when I was poking around the policy/ programmers' manual...) I'd appreciate responses; I don't want to tread on anybody's toes here...
