Re: Neat gtk/gdk-imlib pain
On 1 Feb 1999, Jim Pick wrote: > I'm not sure if you need to provide the original symbol - I think > ld.so is smart enough to pull the appropriate symbols from the > appropriate libraries (providing their symbol maps were set up > correctly). There's at least 50 pages of documentation explaining all > the various details - I don't pretend to understand it. I think it's > one of those things you can only figure out by doing it. It is not something I would hold my breath on, I don't think it is likely, but hey, might work. > > There are currently 72 things that link against imlib. I suspect that > > about half were linked with the 'old' imlib and half with the 'new' imlib. > > That's to be expected. The current situation demands that all those > apps should be rebuilt everytime gtk or glib breaks compatibility. But they are stable releases using the stable gtk stuff - it seems crazy to just abandon them. I can see how you'd not want to deal with inter-relations between the various devel libraries, but ignoring the stable stuff is a Bad Idea (TM) You certainly have to deal with it when you release the new stable GTK so you might as well work it out in the devel releases. Ideally the devel GTK/etc -should- co-exist with the stable stuff, if it doesn't then I think that is a serious problem. I can tolerate apps from potato breaking left and right, but old apps from slink? Bleck. Jason
Re: Neat gtk/gdk-imlib pain
Hi! > Jason Gunthorpe writes: >> There is apparantly an EGCS patch called libapi, available in the >> Debian egcs package, which is supposed to implement the above. >> Adopting and improving this patch would definitely solve your >> GNOME problems, Jim. JG> Can you give us some pointers? This sounds like a good thing for JG> the gnome people to adopt upstream as well.. Damn. It's not a generalized solution like I was hoping it would be. This reminds me of a time when I said to myself... ``Damn. All I want to do is build some shared libraries, but every shared library-supporting package I've seen has its own mechanism, and none of them is clearly better than the others. I bet I could write a little shell script'' I guess it's up to me again (or whoever else feels like doing the dirty work) to figure out a way to fix this bugger. ;) -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/) [Unfortunately, www.fig.org is broken. Please stay tuned for details.]
Re: Neat gtk/gdk-imlib pain
> > There is apparantly an EGCS patch called libapi, available in the > > Debian egcs package, which is supposed to implement the above. > > Adopting and improving this patch would definitely solve your GNOME > > problems, Jim. > > Can you give us some pointers? This sounds like a good thing for the gnome > people to adopt upstream as well.. It's in the egcs package. # DP: Patch to include the c++ compiler interface, the libstdc++ version # DP: and the libc version in the libstdc++ soname. (From H.J. Lu) It's why the libstdc++ libs look like: libstdc++-2-libc6.0-1-2.9.0.so SONAME libstdc++-libc6.1-1.so.2 The only problem is, for libgnome, the library might end up looking like: libgnomeui-31-esd0-glib1.1.3-gtk1.1.3-imlib1.so Gawd knows what I'd name the package as. It's just a variation on the bumping the soname idea. We'd still have the problem where we'd get a huge explosion in the number of libraries hanging around. Cheers, - Jim
Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > > > There are currently 72 things that link against imlib. I suspect that > > > about half were linked with the 'old' imlib and half with the 'new' imlib. > > > > That's to be expected. The current situation demands that all those > > apps should be rebuilt everytime gtk or glib breaks compatibility. > > But they are stable releases using the stable gtk stuff - it seems crazy > to just abandon them. I can see how you'd not want to deal with > inter-relations between the various devel libraries, but ignoring the > stable stuff is a Bad Idea (TM) True. What I'm most concerned about is a clean upgrade path from the released slink to the released potato. I don't imagine that we'll be releasing any gtk/glib 1.1.x stuff in potato. We'll have moved on to the stable gtk/glib 1.2.x by then, and glib 1.0.x will be a distant memory. > You certainly have to deal with it when you release the new stable GTK so > you might as well work it out in the devel releases. You are right, of course. I still don't know what to do about it though. > Ideally the devel GTK/etc -should- co-exist with the stable stuff, if it > doesn't then I think that is a serious problem. I can tolerate apps from > potato breaking left and right, but old apps from slink? Bleck. I'm becoming more convinced of the need for symbol versioning. When are we switching to glibc 2.1 in potato? It's due to be released in a few weeks (if that). I guess I could do some experimenting on the ARM port... Cheers, - Jim
Re: x11amp
On Mon, Feb 01, 1999 at 10:47:25PM +0100, Josip Rodin wrote: > > The fact that they hold *a* patent does not put Debian in any sort of > > jeopardy. If anything, it would be the authors; Debian is complying with > > GPL completely. > > Well, yes, but we still have to abide by the patent laws, don't we? It would probably be wise to do so, within reason. (Keep in mind that it may be technically illegal to use .gif for anything without paying Unisys, but since they gave us their 'blessing' by saying they'd only charge for commercial packages, we're OK and would not be sued.) However, nobody has ever demonstrated that 1) that patent is valid anywhere in the world, 2) that they hold a patent that applies to playing MP3s, and 3) that such patent has been vigorously defended such that courts would side in their favor. Note also that if we really were under such patent restrictions, it would not be legal to distribute even in non-free. Merely the *threat* of legal action, which would ultimately be unsucessful from their perspective, can not and should not influence Debian policy. > > The licensing terms are not vague: it's GPL. That's about as solid as you > > can get. > > Yes, but the patents and other restrictions fsck up. I have yet to see that there are any applicable patents here. > > documentation anywhere that indicated that x11amp uses any mpg123 code. > > (Where are you looking?) Since it's released as GPL, it's free. OK, I'll grant you that on these grounds, perhaps contrib.
Re: Proposal for new architecture support/distribution
On Mon, Feb 01, 1999 at 04:37:50PM -0500, Phillip R. Jaenke wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Mon, 1 Feb 1999, Daniel Jacobowitz wrote: > > > Unless I'm severely mistaken, the userland for all lines of Power* CPUs > > should be identical, minus a few hardware-related programs. The major > > portion of the work is kernel; if you can get them to boot, we'll > > gladly support the installation process. > > Unfortunately, this does not hold true for all userland programs. ie; > mpg123. Allow me to show you a little snippet from it's source tree. > > - -rw--- 1 5285 5030 4717 Nov 8 1997 decode.c > - -rw--- 1 5285 5030 5070 Nov 8 1997 decode_2to1.c > - -rw-r--r-- 1 5285 5010 6528 Dec 2 11:54 decode_3dnow.s > - -rw--- 1 5285 5030 5445 Nov 8 1997 decode_4to1.c > - -rw--- 1 5285 5010 5778 Dec 2 11:54 decode_i386.c > - -rw-r--r-- 1 5285 5010 6984 Nov 19 05:42 decode_i486.c > - -rw--- 1 5285 5030 5150 Aug 23 1997 decode_i586.s > - -rw--- 1 5285 5030 6120 Nov 2 17:42 decode_ntom.c But assembler for one powerpc should work on another. If it doesn't, then it should be fixed. We have a working mpg123. > As I stated in my original email, the information should not be too > difficult, seeing as how IBM has now joined Linux International. I don't > believe they'll be too argumentative or difficult with giving us the > information required for the PowerPC RS64 II and the Power2 processor. Processor is not the issue. That should be public information. They ARE the same architecture. On Mon, Feb 01, 1999 at 05:32:43PM -0500, Phillip R. Jaenke wrote: > Kernel and hardware incompatibilities can lead to binary > incompatibilities. Plus, IIRC, the current PowerPC distributions are all > compiled for UP. As I said, most RS/6000's are SMP. And a multi-threaded > application will still work on a UP system, of course. Another reason is > due to the almost totally commercial use of the RS/6000. Unlike your > standard Linux distribution, to actually make headway in the RS/6000 > arena, it would require a focus more on applications that are used in the > server market; ie, Apache, SSL webservers, NFS, Samba, and commercial > applications such as Oracle, etc, providing an 'official' distribution for > the RS/6000 convinces them to port to said distribution. I'm confused. Different kernels should _never_ harm userland compatibility. Only the kernel should ever need to know the difference between UP and SMP. Plus, why do you claim that the server market is not the Linux focus? We go much deeper into the server market than the workstation one. Dan /\ /\ | Daniel Jacobowitz|__| CMU, CS class of 2002 | | Debian GNU/Linux Developer__ Part-Time Systems Programmer | | [EMAIL PROTECTED] | |[EMAIL PROTECTED] | \/ \/
News site for Free Software people?
[Please don't follow up in debian-devel; I'm not subscribed to this one and also it's not the right place for this discussion. I'm only bringing it up there because more people read it, but people there who want to follow the thread may subscribe to debian-publicity which is the correct place] I'm growing more dissatisfied with Slashdot everyday. Interesting news articles are getting sparser, comments rarely don't turn into flamewars (and the number of comments that directly oppose the concept of Free Software itself is disturbingly big and increasing), and even the polls are getting more and more dull. Now Rob is a very fine person but I don't think Slashdot is serving my purposes anymore, and I've seen a lot of comments from people who feel the same. Anyone reading this is interested in somehow helping with setting up a brand-new online news service, explicitly commited with Free Software? I'd specially love this place to have any kind of support from Debian and GNU, even if it's only a link somewhere in their homepages. In case this project really happens, it's open to discussion whether it should use Slash or something entirely different; personally, I don't see too much of a reason to store online news and discussion in a SQL database, and even if there are such reasons this project should of course use a free server (not mysql). []s, |alo + -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the web page Debian GNU/Linux --http://www.debian.org
Serious Debian website problems
OK, I've written on both of these topics before, and nothing has happened for months, so I'm writing here. First, Debian's list archives will most likely die a horrible death on January 1, 2000. That's right, folks; lists-archives is not year-2000 compliant. Not only will dates in indexes appear wrong, but after some testing yesterday, I believe the whole thing will blow up. I have fixed my private lists-archives to have such compliance (I've also fixed a lot of other bugs in it), but nobody has been interested in the patches, so... Secondly, whenever you search for something in the mailinglist archives on www.debian.org, you get back a page of results. Click on any result, and you get a 404 error. This has been broken for literally months; I reported it a long time back, have prodded people since then, and nothing has been done. Can somebody with the power please fix this?
[Fwd] Uploaded pam 0.66-1 (source i386 all) to master
Just in case anyone missed this on the changes mail list, and so I can explain some of the changes, what I have done and why. First off, my goals were: 1) Upgrade to the latest version 2) Close as many bugs as possible (closed 10 or so that were lingering but already fixed, and actually closed ~22 with this release). 3) Start working towards making this actually usable in the base installation. 4) Get a FAQ/HOWTO complete for developers to use in implementing pam in their packages (coming soon) The upgrade to the latest version went fine, you will note that the 0.6x releases are pre. I'm hoping that this is released or atleast rather stable by the time potato releases. Going through the bug reports took most of the time, but I've cleared out all but 4 bugs with this upload, and those I will have fixed by the next upload, I want this setup tested well before then though. The modules have been moved from /lib/security to /lib/security.0, where '0' is the soname of the library. There is a script included with the runtime package that allows preinst and prerm scripts to link /lib/security with the proper /lib/security.? directory. This was only because update-alternatives doesn't work on directories, but serves the same purpose. This should not break anything of the packages that depend on libpam (samba, and netatalk). I'de like those maintainers feedback on how well it works. I took the shadow package and did a test compile with libpam support builtin to check out the setup. Everything works well (only passwd really has pam support right now it seems), even md5 password support. I then installed cracklib and the libpam0g-cracklib package and setup passwd to use this as the primary password mechanism with pam_pwdb as the secondary. This also worked well, with the exception of a small glitch I will look into. Couple of comments I would like help with: 1) Should pam_pwdb be the default in the base installation or are the pam_unix_*.so modules ok for this (pam_pwdb depends on libpwdb) ? 2) One of the bug reports claims that pam_lastlog.so should make a call to a wtmp function, a) is this really what it should do, if it is then b) where is a sample setup I can look at to implement this. thanks, Ben (who wants potato PAMified) -BEGIN PGP SIGNED MESSAGE- Format: 1.6 Date: Wed, 20 Jan 1999 07:09:15 -0500 Source: pam Binary: libpam0g-dbg libpam-runtime libpam-doc libpam0g-dev libpam0g-modules libpam0g-cracklib libpam0g Architecture: source i386 all Version: 0.66-1 Distribution: unstable Urgency: low Maintainer: Ben Collins <[EMAIL PROTECTED]> Description: libpam-doc - Documentation of PAM libpam-runtime - Runtime support for the PAM library libpam0g - Pluggable Authentication Modules library libpam0g-cracklib - PAM module to enable cracklib support. libpam0g-dbg - Static library with debugging symbols for libpam libpam0g-dev - Development files for PAM libpam0g-modules - Pluggable Authentication Modules for PAM Closes: 7725 10234 10406 10941 12210 14533 16882 25915 28075 30862 31191 31548 Changes: pam (0.66-1) unstable; urgency=low . * New maintainer * New upstream release. closes: #16882, #30862, #7725 * Created a better split of the main lib and the runtime to kill the circular dependencies and make it possible to have two .so version of the library installed for upgrades. closes: #10234, #10406, #12210, bug #14291, #15528, #15529, #20660, #25330, #29868, #31088, #31128, bug #9131, #9919. * Harcoded modules directory prefixed with the .so version, and used alternatives to create the symlink to the 'default' modules directory. libpam will use the full path when specified, but use the versioned modules directory for relative names. * Put libpam0g-cracklib modules back in (own package). This means that cracklib support is _not_ in the static libpam.a, also cracklib support is _not_ in pam_unix_passwd.o, but only in pam_cracklib.so by itself. * Fixed a few typos in the source causing compile errors * Fixed source #include's so that pam _didn't_ have to be installed in order to compile the source ( changed from <> to "" ) * Removed empty directories from built packages * Opted not to build examples, only going to put *.c files in examples directory for libpam0g-dev * Moved *.sgml files for modules into their own directory (looks like that is what the original maintainer wanted to do, but it didn't go) * Moved doc build to arch-indep build in rules so that it doesn't get built when specifying -B with debuild/dpkg-buildpackage. * Moved `touch .quiet...' to build-stamp in order to have -B builds not ask about pam.conf * Split out non-standard modules to their own package, so as to make the base install smaller (planning for base inclusion here) * Created small manpage for pwdb_chkpwd. closes: #10941 * The Copright file in /usr/doc/*/ was already named
RE: Serious Debian website problems
On 02-Feb-99 John Goerzen wrote: > OK, I've written on both of these topics before, and nothing has happened > for months, so I'm writing here. > > First, Debian's list archives will most likely die a horrible death on > January 1, 2000. That's right, folks; lists-archives is not year-2000 > compliant. Not only will dates in indexes appear wrong, but after some > testing yesterday, I believe the whole thing will blow up. I have fixed my > private lists-archives to have such compliance (I've also fixed a lot of > other bugs in it), but nobody has been interested in the patches, so... > > Secondly, whenever you search for something in the mailinglist archives on > www.debian.org, you get back a page of results. Click on any result, and > you get a 404 error. This has been broken for literally months; I reported > it a long time back, have prodded people since then, and nothing has been > done. This and other issues dealing with the mailing list archives are being addressed. There's been recent messages on -www about there (where most of the web related stuff is discussed). We're looking at a few systems that would 1) reduce the number and/or size of files to make mirroring easier 2) make indices of -devel and -user (and others) easier to handle 3) not have a problem with mime encoded pgp signed messages from wichert ;) It will not (hopefully) take into the year 2000. In the meantime... -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html <>< * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * <[EMAIL PROTECTED]> * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * <[EMAIL PROTECTED]> * G++>G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = pgp0pcPDcWJ5N.pgp Description: PGP signature
Re: Proposal for new architecture support/distribution
-BEGIN PGP SIGNED MESSAGE- On Mon, 1 Feb 1999, Daniel Jacobowitz wrote: > But assembler for one powerpc should work on another. If it doesn't, > then it should be fixed. We have a working mpg123. Indeed, but it won't work on an RS64 II, or a Power2. > Processor is not the issue. That should be public information. They > ARE the same architecture. Incorrect assumption. The PowerPC RS64 II is not the same as a Power2 is not the same as a PowerPC With X5 Cache is not the same as a PowerPC (603,603e,604,604e). Comparing the PowerPC RS64II purely on the architectural level with a PowerPC 604e, is akin to comparing an UltraSPARC II to a PentiumII. > I'm confused. Different kernels should _never_ harm userland > compatibility. Only the kernel should ever need to know the difference > between UP and SMP. It's not the userland/kernel that I'm most worried about; more the userland applications themselves. If a multi-threaded application is compiled UP, then in most cases, it will not take advantage of an SMP system, at least in my experience. > Plus, why do you claim that the server market is not the Linux focus? > We go much deeper into the server market than the workstation one. Perhaps I should have been a bit more specific. We all know that Linux is, to put it bluntly, blowing NT out of the water left and right. However, I personally don't see much headway at all being made into the workgroup server and database server markets. The world knows for cold hard fact that Apache is the most popular and most widely used web server on earth. However, I personally don't know of any *real* statistics proving what is the most popular database on earth. (SQL is not an answer, folks. SQL is the language; not the engine.) Furthermore, we have Samba, we have NFS, we have Coda, we even have NCP. I honestly cannot say I have seen a Linux system acting as a fileserver, or a workgroup server of any sort, in the sense of handling user logins and home directories, as well as applications. Proxy servers don't count. (I stopped counting Linux proxy servers *long* ago. They're everywhere.) Now, moving on to what Jim brought up. On Mon, 1 Feb 1999, Jim Pick wrote: > You'd have a separate RS/6000 kernel which would be compiled for SMP. > This should have no impact on the existing PPC userspace. > > The userspace stuff shouldn't care if it's running on UP or > SMP. Remember, i386 supports UP and SMP with one userspace. This is defintely a valid point. As I stated, I'm more concerned about userspace applications. Furthermore, let us not forget that there are other things that simply *must* be done to the kernel to make it run acceptably on RS/6000 systems that are PPC (603,603e,604,604e) based. > Debian already has all these applications (except for Oracle). *grin* I don't think getting Oracle in on things could be too incredibly difficult, with some finegaling and negotiating. > Basically, all Debian distributions look the same, regardless of the > underlying architecture - because they are built from the same set of > sources. This is a very strong point. One that I had to think long and hard on. And it led me down a new train of thought. First off; I'm going to have to stick by a seperate RS/6000 distribution due to the kernel work that must be done, and possibly other userland work that I honestly don't believe any one of us can anticipate anywhere near accurately alone. Furthermore, the name alone will likely bring along further supporters, especially IBM, who will likely make donations to Debian, in the form of hardware and funding. We all know that this is what keeps things going, therefore, it cannot be a Bad Thing(tm). ;) Therefore, I propose that we begin work on Debian for the RS/6000. The distribution will be no different from any other distribution, except for the architectural differences. Depending on how things are done, we may have to subdivide it by architecture, ie; Debian-PPC, Debian-PPC64, Debian-PPCX5, Debian-POWER2. Personally, that's about the *last* thing I'd like to see. Much more work, and possibly more confusion. So, I propose that we start simple. UP to 8 way SMP RS/6000's, based on the PowerPC (603,603e,604,604e), with PCI/ISA only. While this may sound like it's cutting out many RS/6000's, it really cuts out very few. What I would like to see is a stable Debian-RS/6000 for machines meeting the above requirements first, before we delve into the unknown. In this day and age, it's easier to get backing when you already have it working. Secondly; I propose the beginnings of a Debian offshoot. Now, something tells me that this will be met with a great deal of resistance (from the people who brought you vrms.deb;), but I believe it may be in all of our best interests, to further garner market approval and acceptance of Linux. Debian for Business. The only difference is in the packages, and install methods. I am totally opposed to the route that RedHat has followed, char
Re: Neat gtk/gdk-imlib pain
On 1 Feb 1999, Jim Pick wrote: > > Ideally the devel GTK/etc -should- co-exist with the stable stuff, if it > > doesn't then I think that is a serious problem. I can tolerate apps from > > potato breaking left and right, but old apps from slink? Bleck. > > I'm becoming more convinced of the need for symbol versioning. I'd be pleasently surprised if versioning could fix the gtk/glib/gnome problems, but I think it's role is more to deal with minor corrective drift that whole scale mutually incompatible changes. I mean if gtk1.1 and gtk1.0 are not even source compatible it is crazy to think symbol versioning will do anything to help them. > When are we switching to glibc 2.1 in potato? It's due to be released > in a few weeks (if that). I guess I could do some experimenting on > the ARM port... I think Joel is saying 'As soon as possible' Jason
Re: Debian booth at LinuxTag '99?
FYI: I have sent in two abstracts for talks at the Linux Tag, one of them is about Debian GNU. Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists.
Re: x11amp
On Mon, Feb 01, 1999 at 10:50:01PM +0100, Josip Rodin wrote: > On Mon, Feb 01, 1999 at 03:30:41PM -0600, Stephen Crowley wrote: > > > But that is not the reason why my first guess was non-free. It was > > > the fact that mpg123 is in non-free, and x11amp is (according to > > > the docs) based on it. > > > > I already have it packaged. It uses plugins for the decoder so I think > > x11amp can go in contrib and libmpg123.so can be moved into x11amp-nonfree. > > Great! > But please wait with the upload, we still don't know for certain > does the libmpg123.so break mpg123 licence. Yeah i am waiting, for now I got it at http://www.wf.net/~stephenc/x11amp /---\ |Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] | |Debian GNU/Linux http://www.debian.org | |GPG Key http://va.debain.org/~crow/public.key | \--- 8A8B 3B82 6EA7 CF4E 01A5 5B21 B378 981D D2E1 0D85 /
Re: Proposal for new architecture support/distribution
On Mon, Feb 01, 1999 at 07:54:41PM -0500, Phillip R. Jaenke wrote: > I honestly cannot say I have seen a Linux system acting as a fileserver, > or a workgroup server of any sort, in the sense of handling user logins > and home directories, as well as applications. I have. The trouble is that Samba isn't poised to replace NT in this area since most organizations (needing Samba) already have an NT domain and aren't prepared to abandon it. Note that they chose NT in the first place. BTW, there is some speculation that Samba isn't *really* faster than NT on the same hardware. I haven't heard doubts as to the greater stability of the underlying OS. > > Basically, all Debian distributions look the same, regardless of the > > underlying architecture - because they are built from the same set of > > sources. > [deletia] > Secondly; I propose the beginnings of a Debian offshoot. Now, something > tells me that this will be met with a great deal of resistance (from the > people who brought you vrms.deb;), but I believe it may be in all of our > best interests, to further garner market approval and acceptance of Linux. No one is going to tell you that you can't do XZY with Debian...as long as you abide by the licenses. Making Debian more appealing and accessible to suit-wearers is a clear and positive intent. I don't see any reason for there to be an 'offshoot' project since there is nothing to leave behind. In other words, we can improve existing configuration management, add new architectures, and support commercial apps (as debs) without doing anything different than we already do. What's to resist?
Re: [Waaaaay Off-Topic] Bring out your dead!
On Sun, Jan 31, 1999 at 03:02:10PM -0800, Joseph Carter wrote: > On Sun, Jan 31, 1999 at 01:50:28PM +0100, Wichert Akkerman wrote: > > We could then have conversations like this with our users: > > > > CART DRIVER: Bring out your dead! > > LARGE MAN: Here's one! > > CART DRIVER: Ninepence. > > BODY:I'm not dead! > > I'm waiting for someone not to know where that's from... I'm your man. Sounds British, though... Monty Python? -- Robert Donn "IBM don't make nonstandard things. People just cloned them wrong." -- Tim Foster pgpFnqyXMlBlg.pgp Description: PGP signature
