ALSA libraries change names (again)
This is a (belated, unfortunately) heads-up to anyone who has a package that depends on the ALSA libraries. As of the 0.4.1 release, I've switched from the odd naming scheme formerly used by the ALSA libraries (i.e. 'alsalib0.3.0', 'alsalib0.3.2', etc) because (a) new versions can't coexist with old ones (the ALSA maintainers keep [EMAIL PROTECTED] changing the kernel API) and (b) the soname doesn't contain the extra version numbers (though it could be argued that it should since the libraries are all mutually incompatible - such are the pains of software in development). Thus, if your package depended on alsalib0.3.2, it should now depend on libasound0. With luck the ALSA people will make some effort to stabilize their APIs Real Soon Now... In any case, that package name should stick around for a while, I hope. (BTW, if there is anyone out there who is active in the ALSA development effort and would like to take these packages, please contact me - I don't mind maintaining them since I use them, but I'm not very knowledgeable on the ALSA internals or the development process) -- David Huggins-Daines - [EMAIL PROTECTED] Linux system administration, C and Perl programming Information Retrieval, Database, and Web development
Re: re-orphaning ALSA
On Wed, May 26, 1999 at 12:03:44PM +0200, Wichert Akkerman wrote: > I am orphaning the ALSA package, since I don't have the time to properly > maintain a package of that complexity. I did this before and somebody I'll take it if nobody else already has. (I have sound cards at work that don't seem to work well with OSS/Free, so I need it...) > This should probably be taken by an experienced maintainer, since packaging > kernel modules is not for the faint at heard. And there are libraries > involved as well to make it even more fun.. Kernel modules are new to me, but that's half the fun, isn't it? > Please mail me if you are interested. Cc:ed to wnpp and debian-devel. Cheers -- [EMAIL PROTECTED] (wearing my Linux/m68k+Mac+Debian hat) Latest kernels/patches: http://maclinux.plcom.on.ca/pub/ pgp5L5504vnyf.pgp Description: PGP signature
Re: Intent to package: t1lib
On Sun, Jun 21, 1998 at 03:02:49AM -0500, Rob Tillotson wrote: > David Huggins-Daines <[EMAIL PROTECTED]> writes: > > Is the dependency on gsfonts | xfntscl too bogus? (It needs Type 1 fonts > > to be at all useful, and the demonstration program "xglyph" in t1lib0-bin > > will spit out rude error messages if it can't see any fonts). > > I'm just a new guy, but I think it should be downgraded to "Suggests", > if even that. > > The question is "does t1lib require these particular fonts so strongly > that the user should be forced -- or nearly so -- to install them?" I > say no, because: (lots of good reasons why the dependency is bogus) Yeah, that makes sense. I was really just thinking of xglyph - since it's got a menu entry, if someone selects it and there are no fonts visible to t1lib, it just won't appear. T1lib itself doesn't specifically need to have any fonts listed in its config file in order to start up. The script that the postinst calls to create a font database and config file is able to find any fonts that happen to be installed under /usr/X11R6/lib/X11/fonts and /usr/lib/ghostscript/fonts, which includes quite a few packages. (I suppose I could have it look under /usr/lib/texmf and /usr/share/groff, as well... any thoughts on this?) I'll just make sure it doesn't choke when it can't find any fonts at all, and remove the dependency altogether, since the package doesn't become non- useful without specific font packages. The configuration script can be run with extra arguments specifying other directories to add to the font database. Like I said, the packages are preliminary... I haven't written the man pages yet, and a few things are still in the wrong places (plus I want to convert the docs to HTML and put in a menu entry for dwww). It's good to see that someone out there does actually want these packages, though :-) I'll take that as a sign that it's okay to continue to work on the packages. Cheers -- David Huggins-Daines [EMAIL PROTECTED] http://aix2.uottawa.ca/~s1204672 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to package: t1lib
Preliminary, unofficial packages (t1lib0, t1lib0-dev, t1lib0-bin) are on my website at http://aix2.uottawa.ca/~s1204672/linux/ $ dpkg --status t1lib0 Package: t1lib0 Status: install ok installed Installed-Size: 204 Maintainer: David Huggins-Daines <[EMAIL PROTECTED]> Source: t1lib Version: 0.7-1 Depends: libc6, gsfonts | xfntscl Description: Type 1 font rasterizer library - runtime T1lib is an enhanced rasterizer for Type 1 fonts. . T1lib is based on the X11R5 font rasterizer code, but operates independently of X11. It includes many enhancements, including underlining, antialiasing, user-defined slant and extension factors, and rotation. . This package contains the shared libraries and configuration needed to run programs using T1lib. Is the dependency on gsfonts | xfntscl too bogus? (It needs Type 1 fonts to be at all useful, and the demonstration program "xglyph" in t1lib0-bin will spit out rude error messages if it can't see any fonts). The license is LGPL. I've got some other questions, but I'll ask them on debian-mentors. Cheers -- David Huggins-Daines [EMAIL PROTECTED] http://aix2.uottawa.ca/~s1204672 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to package: MacGate
MacGate is a set of user-space programs for using the Appletalk-IP decapsulation driver in the 2.1.90 and later kernels (or 2.0 kernels with the Appletalk-Suite patch). It allows a GNU/Linux system with Netatalk to act as an Appletalk-IP router. The license is GPL. I've made preliminary source and binary packages for i386, which have been uploaded to my webpage at http://aix2.uottawa.ca/~s1204672/linux/ I hope this isn't a really stupid question, but I couldn't find anything relevant in the policy manual: Is it all right to package things like this that depend on experimental or patched kernels? I assumed it should go in "extra" and included a stern warning in the Description: field of the control file that it won't work with the standard 2.0.33/2.0.34 kernel images. Should I include the kernel patch in the package, with instructions? Assuming this is all right, and noone else is doing it (I'm planning to take over an orphaned package or two, anyway), I'll apply to become an official developer... If there's anyone in the Ottawa-Hull area that can sign my PGP key for me, please contact me by personal e-mail. As an aside, I wasn't able to get these programs to link against libatalk.so without also linking with /usr/lib/libwrap.a. I'm unsure whether to file this as a bug, and if so, whether it should be a bug against libatalk1-dev (which provides libatalk.so, which is where gcc complains about missing symbols) or netbase (which provides libwrap.a, but no libwrap.so) because I honestly have no idea what libwrap.a is for :-) Cheers Dave -- David Huggins-Daines [EMAIL PROTECTED] http://aix2.uottawa.ca/~s1204672 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
