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