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: 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: > If glib, gtk, gnome, imlib, etc used versioned symbols then yes you > -might- advoid this. > > -HOWEVER- my understanding how how versioned symbols would need to be > implemented would make this pretty much impossible for a large portion of > the libraries that compose gnome. (ie you have to provide the orignal > symbol and somehow interweave it into the new library structure) 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. > > Anyways, the wmakerconf problem can be fixed for potato by recompiling > > wmakerconf for potato with the proper libraries (and recompiling it > > every time one of it's dependent libraries breaks compatibility, which > > happens almost weekly with gtk/glib 1.1.x). > > 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. Most of the time, applications aren't affected by the particular routines that broke compatibility, so they don't fail - but that's just dumb luck. > So no matter what system you have half your apps will magically break > without warning or explanation. To make things worse the packages using > the 'new' imlib do not have a versioned dependency on the new imlib > (though it got installed so something must..) If we do conflicts, then apps won't break - but you'll usually have to de-install half of them anytime you want to use one that uses a newer, incompatible library from out of unstable. If we change the SONAME, apps won't break either, and upgrades will be easy - but we'll end up with zillions of libraries. And you can kiss binary compatibility between distributions goodbye because of the different SONAMEs (perhaps not a big deal, since we are dealing with libraries that are under development anyways). I'll have to change the SONAME on libgnome almost weekly. If we do nothing, then people using unstable will suffer from broken applications. It's less work for the maintainers, who are already overloaded. I hope versioned symbols in glibc 2.1 will stop the insanity. But I'm not sure. Cheers, - Jim
Re: Proposal for new architecture support/distribution
"Phillip R. Jaenke" <[EMAIL PROTECTED]> writes: > 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. 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. > 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. Debian already has all these applications (except for Oracle). Basically, all Debian distributions look the same, regardless of the underlying architecture - because they are built from the same set of sources. Cheers, - Jim
Re: List of bugs that *must* be fixed before releasing Slink
[EMAIL PROTECTED] (Dale E. Martin) writes: > Oscar Levi <[EMAIL PROTECTED]> writes: > > > In my opinion, this problem is not sufficient to warrant an upload at > > this time since, contrary to the bug reporters claim, it does not > > prevent the packing from functioning. It is annoying, yes. > > Interesting that it works for you. It really doesn't for me: > ~> java > Warning: can't find /usr/lib/jdk1.1/bin/../bin/checkVersions, hope that's ok > java was not found in /usr/lib/jdk1.1/bin/../bin/i686/green_threads/java > > The binary is somehow actually missing, and I've not done anything weird as > far as I know. The other folks who are saying is doesn't work have the > same problem. I _know_ the checkversions thing is another problem. I had the same problem. Reinstalling it fixed it. Cheers, - Jim
Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > On 1 Feb 1999, Jim Pick wrote: > > > > libgdk-imlib1 in slink did not seem to depend on any glib, in potato it > > > depends on a new and incompatible glib from potato BUT the soname was not > > > changed. So the instant you install this new libgdk-imlib1 ~40 apps from > > > slink silently stop working! > > > > Actually, if you look again, you will see that the soname is not the > > problem. > > Read the libtool thread. What has been done here is to recompile a library > against a different set of libraries in an incompatible way without > changing the soname Ok. You are correct. > > In fact, imlib is only being pulled in once. The problem is that glib is > > being pulled in twice (from libraries/binaries that were linked with > > The library that does this is imlib according to my investigation. Actually, it takes two libraries to create the problem (unless something was compiled wrong). Use objdump --private-headers and look at the NEEDED field: $ objdump --private-headers /usr/bin/X11/wmakerconf NEEDED libgdk_imlib.so.1 NEEDED libgtk.so.1 NEEDED libgdk.so.1 NEEDED libglib.so.1 NEEDED libXi.so.6 NEEDED libXext.so.6 NEEDED libX11.so.6 NEEDED libm.so.6 NEEDED libjpeg.so.62 NEEDED libtiff.so.3 NEEDED libgif.so.3 NEEDED libpng.so.2 NEEDED libz.so.1 NEEDED libPropList.so.0 NEEDED libnsl.so.1 NEEDED libc.so.6 $ objdump --private-headers /usr/lib/gdk_imlib.so.1 NEEDED libgmodule-1.1.so.13 NEEDED libglib-1.1.so.13 NEEDED libdl.so.2 NEEDED libc.so.6 Because wmakerconf was compiled with the old glib, and the new imlib brings in the new glib, and there are some incompatibilities, it breaks. We could change the SONAME to designate the break in compatibility. But then it wouldn't match upstream. It really isn't the upstream maintainer's fault that we released one version compiled against libglib 1.0, and one against libglib 1.1. We are going to have this problem anytime any of the dependent libraries of imlib, or gnome change. This is going to be a big problem for me, I can tell - the gnome libraries depend on so many different libraries. > > The is a clean solution for this BTW - in glibc 2.1, H.J. Lu has added > > support for symbol versioning. > > I don't know much about the symbol versioning but I highly doubt that > using glibc2.1 will have any effect on this problem with gtk. You mean glib, right? If glib used versioned symbols, the dynamic linker would be smart enough to link the symbols that use the new APIs with the newer library - and everything would be happy. > My understanding is that the library author will have to take > special steps to make versioned symbols through some magic means.. Yes, the upstream library author would have to assign a version to the symbols that had changed. It's not too hard - but it may be a problem for the upstream authors because hardly anybody has switched to glibc 2.1 yet. We'll probably be the first distribution to do it (in unstable). Symbol versioning is quite a confusing system, and there isn't much good documentation for it (outside of the documentation for Solaris). I've got a PDF file of the Solaris Linker and Libraries guide (which HJ based his work on) if anybody is interested. > > I'm not sure that it is worth the effort. We shouldn't be > > guaranteeing that applications that depend upon unstable libraries > > (ie. libglib1.1.x, libglib1.1.x, etc.) will be easily upgradeable. > > Isn't the slink imlib/gtk1 'stable'? I really don't follow their > development. If you accept that gtk 1.0.6-2 is a stable library then you > have to take steps to ensure that installing the unstable libraries do > not kill the system, it is the only nice thing to do :< They are using the same scheme as the Linux kernel - odd numbers designate the unstable development branch. Anyways, the wmakerconf problem can be fixed for potato by recompiling wmakerconf for potato with the proper libraries (and recompiling it every time one of it's dependent libraries breaks compatibility, which happens almost weekly with gtk/glib 1.1.x). Should imlib have declared it's incompatiblity? Probably. But it's going to happen every time a new gtk or glib comes out that breaks compatiblity. > > going to break - perhaps we shouldn't be releasing things that use > > libglib1.1.x and libgkt1.1.x - which are part of the development > > branch. > > That is probably a sane idea in of itself. But it's not a very popular idea. People wanted me to release Gnome 0.30 with slink even though it isn't stable yet.
Re: Debian's -rpath policy [was: What hack in ld.so?]
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > On Mon, Feb 01, 1999 at 12:19:48PM -0700, Jason Gunthorpe wrote: > > > > > In short, we have only three choices, regardless of what happens in > > > libtool: > > > > > > 1) Implement Red Hat's ugly patch in our libc5 ld.so, and thereby be > > >bugwards compatible with everybody else's Linux. > > > > > 2) Find some other way to make -rpath on Debian work for the common > > >cases (programs built by libtool included in this category). > > > > I really see no choice, if RH has patched their ld.so we simply must or > > risk being totally incompatible with a huge chunk of binaries. So we need > > to do one of the above, the most sensible is to steal RH's patch so that > > we are compatible. > > I agree. Option 1 is definitely the best. I also agree with the rest of > Gordon Matzigkeits message. Debian has done a (not so) small mistake in the > libc5->libc6 transition, and it is our responsibility to fix it. > > Note that the RH patch probably can't break much which isn't already broken. > (only if someone has system library installed somewhere else and tries to > addresse it with rpath, if I understood correctly. This should happen less > than libc5 binaries with rpath from other sources). Now to convince David Engel ... Cheers, - Jim
Re: What hack in ld.so?
Ian Lance Taylor <[EMAIL PROTECTED]> writes: >Date: Sat, 30 Jan 1999 16:52:48 -0700 (MST) >From: Jason Gunthorpe <[EMAIL PROTECTED]> > >> That's not what I'd like libtool to do. I agree there is a problem to >> be fixed, I just think that libtool is not the only piece of software >> that may have to be changed to fix it, because it is not the only >> piece of software that uses -rpath. > >libtool is however the only piece of software that we cannot easially >change. > > I don't understand the reasoning here. The libtool files that a > package will use are distributed with that package. If you are > willing to modify a package's Makefile to remove -rpath, then it ought > to be just as easy or difficult to modify the package's ltconfig file. I think that's the point - we don't want to have to modify each and every package that uses libtool. That's what we are doing now. It seems, somehow, wrong. There are valid reasons for Debian not to want -rpath. But we have to use a somewhat 'hacky' method to disable it currently. I think all we want is a somewhat cleaner method of achieving the same result. Cheers, - Jim
Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > On 1 Feb 1999, Jim Pick wrote: > > > > I somehow sense that slink/potato gtk/gnome is going to be painfull.. > > > > I agree. I'm only planning to support Gnome 0.99.x/1.0 on potato. > > Oh, I was just reminded of this on the dpkg list.. The gtk (gdk? I forget) > library packages have been internationalized but the messages directory > they use does not include the soname of the library! Thus it is impossible > to have two properly installed version of the libraries with different > sonames, this is an upstream bug of course, but it is kind of serious. Ewww. I see: fleming:/usr/share/locale/de/LC_MESSAGES$ ls WindowMaker.mo kasteroids.mo kedit.mo kmines.mo kstart.mo ark.mo kbiff.mokfax.mo kmix.moksysv.mo clisp.mo kblackbox.mokfind.mo knotes.mo ktalkd.mo control-center.mo kcalc.mokfinger.mo knu.mo ktetris.mo ee.mo kcmbell.mo kfloppy.mo konsole.mo kuser.mo enscript.mokcmdisplay.mo kfm.mo korganizer.mo kview.mo fileutils.mo kcminfo.mo kfontmanager.mo korn.mokvt.mo freetype.mokcminput.mo kfract.mokpaint.mo kwm.mo gettext.mo kcmkfm.mo kghostview.mokpanel.mo libc.mo glade.mo kcmkpanel.mokhexdit.mo kpat.molibgtop.mo gnome-core.mo kcmktalkd.mokiconedit.mo kpm.mo man-db.mo gnome-games.mo kcmkwm.mo kikbd.mo kpoker.mo mutt.mo gnome-libs.mo kcmlocale.mokjots.mo kppp.morpm.mo gnome-media.mo kcmsamba.mo klipper.mo kreversi.mosh-utils.mo gnome-utils.mo kcmsample.mokljettool.mo krn.mo sharutils.mo gnumeric.mokcmsyssound.mo klock.mo krootwm.mo tar.mo gnupg.mo kcontrol.mo klpq.mo ksame.mo tcsh grep.mokdat.mo klyx.mo kscd.motextutils.mo gtk+.mokde.mo kmahjongg.mo kshisen.mo wget.mo kab.mo kdehelp.mo kmail.mo ksirc.mo yp-tools.mo kabalone.mokdm.mo kmedia.moksmiletris.mo karchie.mo kdmconfig.mokmenuedit.mo ksnake.mo karm.mokdvi.mo kmid.mo ksnapshot.mo It looks like nobody is using SONAMEs. On my system, I see this affecting: kdelibs0g libgnome0 libgtk1.1.* libgtop0 They should be splitting the locale files into library and non-library parts as well. I'll have to raise that upstream. I don't know much about gettext though. Cheers, - Jim
Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 1 Feb 1999, Jim Pick wrote:
>
> > > And note that it links to libglib twice. Turns out this is because there
> > > is two 'gdk-imlib1' packages with the same soname but linked against
> > > different versions of glib! By my count we have 72 different package that
> > > depend on gdk-imlib1..
> >
> > I made the same mistable on my first cut of the Gnome packages. It's
> > important that
> > the higher level dependencies (ie. Gnome, WindowMaker, Enlightenment) use
> > the exact
> > same libraries when building as the libraries they depend upon (ie. imlib,
> > gtk, glib,
> > libjpeg, giflib, libtiff, etc.).
>
> Ah but the problem is much more insideous than that! This wmaker-conf was
> from slink, it was never linked against any of these new libraries. The
> problem lies in the library interdependencies.
I agree that it is insideous.
> libgdk-imlib1 in slink did not seem to depend on any glib, in potato it
> depends on a new and incompatible glib from potato BUT the soname was not
> changed. So the instant you install this new libgdk-imlib1 ~40 apps from
> slink silently stop working!
Actually, if you look again, you will see that the soname is not the
problem.
Wakko{jgg}~/work/apt#ldd `which wmakerconf `
libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x4000f000)
libgtk.so.1 => /usr/lib/libgtk.so.1 (0x40031000)
libgdk.so.1 => /usr/lib/libgdk.so.1 (0x400b3000)
libglib.so.1 => /usr/lib/libglib.so.1 (0x400cf000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x400da000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400e2000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400ee000)
libm.so.6 => /lib/libm.so.6 (0x40191000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x401aa000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x401d4000)
libgif.so.3 => /usr/lib/libgif.so.3 (0x4020a000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40211000)
libz.so.1 => /usr/lib/libz.so.1 (0x4023e000)
libPropList.so.0 => /usr/lib/libPropList.so.0 (0x4024d000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40258000)
libc.so.6 => /lib/libc.so.6 (0x4025e000)
libgmodule-1.1.so.13 => /usr/lib/libgmodule-1.1.so.13 (0x40303000)
libglib-1.1.so.13 => /usr/lib/libglib-1.1.so.13 (0x40306000)
libdl.so.2 => /lib/libdl.so.2 (0x40328000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
In fact, imlib is only being pulled in once. The problem is that glib is
being pulled in twice (from libraries/binaries that were linked with
different versions). These two versions of glib are incompatible, but
they define the same symbols. The dynamic linker is just going to link
to whichever symbol it finds first (somewhat random).
The is a clean solution for this BTW - in glibc 2.1, H.J. Lu has added
support for symbol versioning.
Until we switch to glibc 2.1, and the upstream libraries add support
for versioned symbols, this is going to be a huge problem for
libraries with unstable APIs like glib, gtk and imlib.
In the meantime, we'll just have to suffer with compatibility problems
between slink and potato. :-(
> > Does anybody have an idea about how to devise a lintian check for this
> > problem? I can think of some crude solutions, but nothing really clean.
>
> Lintian will not help this, the damage has already be done - the best you
> can do is change gdk-imlib1 to gdk-imlib1.1 and recompile all your new
> packages and be vigilant to never do this again.
And we'd have to renumber the SONAME as well (or add a conflicts,
gross). Renumbering the SONAME introduces binary incompatibility
between us and other distributions - causing grief for Dale Scheetz,
who's working with the LSB on SONAME incompatibilities.
We'd have to do that for every single library that uses an
incompatible base library in potato than what is in slink. Basically,
anything that depends on the 1.1.x (unstable) versions of glib and
gtk, and imlib too.
I'm not sure that it is worth the effort. We shouldn't be
guaranteeing that applications that depend upon unstable libraries
(ie. libglib1.1.x, libglib1.1.x, etc.) will be easily upgradeable.
We can do it - but it's an awful lot of work. If we want to guarantee
that Debian packages released into 'stable' (ie. slink) are never
going to break - perhaps we shouldn't be releasing things that use
libglib1.1.x and libgkt1.1.x - which are part of the development
branch.
My hope is that by the time potato is released, we'll have moved to
glibc 2.1, and libglib1.2.x and libgtk1.2.x. So there shouldn't be an
upgrade problem at that time.
> Oh, the other alternativ
Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> This is kinda neat, considering what we were talking about with libtool
> and all, examine this ldd output:
>
> Wakko{jgg}~/work/apt#ldd `which wmakerconf `
> libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x4000f000)
> libgtk.so.1 => /usr/lib/libgtk.so.1 (0x40031000)
> libgdk.so.1 => /usr/lib/libgdk.so.1 (0x400b3000)
> libglib.so.1 => /usr/lib/libglib.so.1 (0x400cf000)
> libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x400da000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400e2000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400ee000)
> libm.so.6 => /lib/libm.so.6 (0x40191000)
> libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x401aa000)
> libtiff.so.3 => /usr/lib/libtiff.so.3 (0x401d4000)
> libgif.so.3 => /usr/lib/libgif.so.3 (0x4020a000)
> libpng.so.2 => /usr/lib/libpng.so.2 (0x40211000)
> libz.so.1 => /usr/lib/libz.so.1 (0x4023e000)
> libPropList.so.0 => /usr/lib/libPropList.so.0 (0x4024d000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x40258000)
> libc.so.6 => /lib/libc.so.6 (0x4025e000)
> libgmodule-1.1.so.13 => /usr/lib/libgmodule-1.1.so.13 (0x40303000)
> libglib-1.1.so.13 => /usr/lib/libglib-1.1.so.13 (0x40306000)
> libdl.so.2 => /lib/libdl.so.2 (0x40328000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
>
> And note that it links to libglib twice. Turns out this is because there
> is two 'gdk-imlib1' packages with the same soname but linked against
> different versions of glib! By my count we have 72 different package that
> depend on gdk-imlib1..
I made the same mistable on my first cut of the Gnome packages. It's important
that
the higher level dependencies (ie. Gnome, WindowMaker, Enlightenment) use the
exact
same libraries when building as the libraries they depend upon (ie. imlib, gtk,
glib,
libjpeg, giflib, libtiff, etc.).
Does anybody have an idea about how to devise a lintian check for this
problem? I can think of some crude solutions, but nothing really clean.
> I somehow sense that slink/potato gtk/gnome is going to be painfull..
I agree. I'm only planning to support Gnome 0.99.x/1.0 on potato.
Cheers,
- Jim
Re: Proposal for new architecture support/distribution
"Phillip R. Jaenke" <[EMAIL PROTECTED]> writes: > A bit of history first, as it is somewhat important. For those of you who > don't know; Linux runs on PowerPC's. Yes. It does. Now, what big names do > we know that have PowerPC based systems? Let's see. Apple. Amiga. UMax. > IBM RS/6000 (RISC System series-6000 for the unacquainted ones). > > Now, which one doesn't fit the semi-standard mold? That's right; the IBM > RS/6000. There's also a great deal of diversity among the RS/6000 line. > Processors used in the RS/6000 line are the Power2, PowerPC 603, PowerPC > 603e, PowerPC 604, PowerPC 604e, PowerPC RS64 II, and the PowerPC with X5. > Currently, only the PowerPC 603e, 604, and 604e's are supported by Linux. > So, I propose Debian/RS/6000. A distribution built specifically around and > for RS/6000's. Anyone who's dealt with AIX knows that it can be more > trouble than it's worth at times. Wouldn't that make more sense as a subarchitecture of the PowerPC port. I gather that the userspace component would be the same. You'd just need work on the kernel and installation process. Or are the instruction sets somehow incompatible? Cheers, - Jim
Re: gnuserv/gnuclient problem
Amos Shapira <[EMAIL PROTECTED]> writes: > On Fri, January 29 1999, Ionutz Borcoman <[EMAIL PROTECTED]> wro > te: > |Hi, > | > |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions > |from potato I am no more able to start a gnuclient :-( Is anybody else > |experiencing this ? > > I've reported this bug with slink months ago with no response. I > still can't use gnuclient with xemacs under slink. It seems to work for me here (gnuclient.xemac20) ii xemacs20-bin20.4-13Editor and kitchen sink -- support binaries ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule binary ii xemacs20-suppor 20.4-13Editor and kitchen sink -- architecture inde ii xemacs20-suppor 20.4-13Editor and kitchen sink -- non-required libr Cheers, - Jim
Re: Call for mascot! :-)
Ben Pfaff <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Martin Bialasinski) writes: > >Hmm, with a strong enough improbability field, you will see dragons in >the sky. > > Dragons and octopi in the sky are Somebody Else's Problem. Flying Octopi? Sounds like a Detroit Red Wings game... Cheers, - Jim
Re: /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version
"Ivan E. Moore II" <[EMAIL PROTECTED]> writes: > /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version > > This happens with some of the GNOME based packages I've installed > from both slink and potatoe lately... > > Any ideas what I'm missing or what I did??? You probably have mixed some of the 0.99.x packages and the 0.30 packages. Cheers, - Jim
Re: [Fwd: [Jikes-License] Jikes Parser Generator now available i
Brent Fulgham <[EMAIL PROTECTED]> writes: > Try Japhar/Classpath: > > www.japhar.org -- free JDK (compiler, runtime, debugger, etc.) > www.classpath.org -- free implementation of the essential java libraries Plus... www.transvirtual.com -- Kaffe JIT www.mozilla.org -- ElectricalFire JIT Cheers, - Jim
Re: libtool & rpath
Hamish Moffatt <[EMAIL PROTECTED]> writes: > A package I maintain uses libtool. To remove the rpath stuff, I > apply this patch to configure.in. Actually, I sort of like the following technique better: Add the following to debian/rules right before calling "$(MAKE) all" (but after configure): sed < libtool > libtool-2 \ -e 's/^hardcode_libdir_flag_spec.*$$/hardcode_libdir_flag_spec=" -D__L IBTOOL_IS_A_FOOL__ "/' \ -e '/^archive_cmds="/s/"$$/ \\$$deplibs"/' That way, there is no need to patch configure.in and rerun autoconf. > Also, because this package (geda) includes a library, debhelper > is generating an shlibs file for it. But then the package ends up > depending on itself, because of the shlib:Depends expansion. Is there > an easy fix for that? Splitting the packages is a possibility, but > libgeda is of absolutely no use on its own yet, and I don't think there > is anything for a libgeda-dev. Try: LD_LIBRARY_PATH=debian/tmp/usr/lib dh_shlibdeps -V The LD_LIBRARY_PATH prevents ldd from linking to a library that is installed on the system, so dpkg-shlibdeps doesn't find the associated package (so there is no dependency created). Cheers, - Jim
Re: New logo strategy
Why don't we officially not have an official logo? If 5 years from now, everybody likes a certain "unofficial logo" (ie. Debian equivalent of the BSD daemon), we could go with that. Cheers, - Jim
Re: Proposal: increasing mirror security
Lalo Martins <[EMAIL PROTECTED]> writes:
> OTOH, we could just sign all packages with a same key ("the
> Debian key"); when dinstall verifies the signature and md5sum in
> the .changes file, it signs the package and updates
> Packages.pgp).
I prefer this method. Then we have less key distribution worries.
Cheers,
- Jim
Re: boot disk question/suggestion
Ossama Othman <[EMAIL PROTECTED]> writes: > Can the 2.1/2.2 kernels handle a gigabyte of memory? Yes. For more than 1GB, go to: http://humbolt.geo.uu.nl/Linux-MM/more_than_1GB.html There was a lot of discussion about this on the linux-kernel mailing list lately. > Also, I remember reading somewhere that the 2.1/2.2 kernels can > handle swap partitions greater than 128MB. Is this also true? I think so. Cheers, - Jim
Re: Help setting up Linux
Greg Hedger <[EMAIL PROTECTED]> writes: > I just installed Debian Linux - just the kernal and the core system, no > XWindows, no frills. So where can someone new to Linux (indeed Unix) > find answers to very basic questions like "how do I mount a floppy > drive," "can I read a FAT32 partition," and "why does my boot floppy get > destroyed when I try to alter boot video mode using rdev or vidmode?" debian-user@lists.debian.org is an appropriate place to ask those questions. The Linux Installation and Getting Started guide is very good: http://metalab.unc.edu/LDP/LDP/gs/gs.html To mount a floppy drive: mount /dev/fd0 /floppy (see "man mount" for details) FAT32 support has been included in the Linux kernel for quite a while. You can find this out by reading the kernel sources and documentation, or by reading the change summaries at http://linuxhq.com/ . I'm not sure why your boot floppy is getting destroyed. Cheers, - Jim
Re: Unsatisfied depends in slink main
Dale Scheetz <[EMAIL PROTECTED]> writes: > giflib3g-dev gdk-imlib-dev > giflib3g-dev imlib-dev > giflib3g-dev libfnlib-dev The full dependencies for these is more like: libungif3g-dev | giflib3g-dev Basically, the unfree giflib stuff has to be in the depends field, because it's in an "or" relationship with the equivalent free package. Cheers, - Jim
Re: Developers in Cali...
Joey Hess <[EMAIL PROTECTED]> writes: > Aaron Van Couwenberghe wrote: > > > OK, in the past week or so I've seen several people posting from > > > California. Has anyone thought of having a gathering in some semi-central > > > location? Get to know faces, sign keys, etc? > > > > I would be interested. If a convenient day were picked and the meeting were > > held somewhere near the Bay Area (Sn Francisco, Sacramento, Oakland...) I > > just might be able to come. > > Well this is jumping the gun a bit, but I intend to do just this in a couple > of weeks. I have a fair-sized mailing list (25 people, including several > developers) of debianites in the CA Bay Area. One of the things I hope > this group will do is help me get a debian booth at linuxworld together and > staffed. I'm still waiting on confirmation of the booth, but it looks like > we will get one. Once I'm sure of that, I'd like to hold a debian meeting > here. The meeting would have at least 2 purposes, maybe 3: > > 1. Get to know one another, socialize, key sign, etc. > 2. Planning for the linuxworld conference. > 3. If Joseph Carter happens to win the Project Leader election, we can >probably drag him down from Modesto to speak. > > I'm been thinking about holding it at the Coffeenet Internet Cafe in San > Fransisco, a very nice cafe which has public linux machines (running redhat, > but oh well.. ;-). Of course all this is tenative. > > If you're interested, the best thing to do is probably to get on the Bay > Area Debian mailing list: "echo | mail [EMAIL PROTECTED]" I'm thinking of making the drive down for LinuxWorld, so maybe I'll see you guys there. :-) I'll sign up on the list so I can see what you are all planning. Cheers, - Jim
Re: Intent to package cygnus-stylesheets
Adam Di Carlo <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> you wrote: > >Adam Di Carlo <[EMAIL PROTECTED]> writes: > >> >Essentially, Cygnus has forked the code. > >> > >> Huh. > > > >That might be a bit strong - I haven't really looked into the > >differences in depth. They are being maintained separately, and they > >are tracking Norm Walsh's stuff. > > After comparing the sources closely, I don't think they have > forked the sources. All the diffs in the *actual* stylesheets > are either CVS stuff changing, since they reimported norm's > stuff, or side-effects based on the fact that they regenerate > the documentation. > > This is better than I thought. It looks like cynus-stylesheets > can just *depend* on docbook stylesheets and I'll be happy and > gnome will be happy and all will be good. > > *phew*! Good to hear that. > I'll try to upload my deb within 48 hours, ok? Sounds good. Cheers, - Jim
Re: Intent to package cygnus-stylesheets
Adam Di Carlo <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> you wrote: > >Adam Di Carlo <[EMAIL PROTECTED]> writes: > >> I understand that Gnome needs db2* scripts... why do they need the Cygnus > >> stylesheets? > > > >They use them internally at Cygnus for their documentation. They are > >unsupported for outside use. > > > >Don't ask me why Gnome decided to use them. I suppose it's because > >Mark Galassi is helping out with the docs. > > Well, I hope it has a license that enables redistribution. License? You wish. :-) It's mostly Norm Walsh's stuff, but the license should be clarified for Mark's additions. > >> To be honest, there's absolutely no reason the two forks of the > >> stylesheets have to conflict. They should be able to co-exist fine. > > > >The only reason I made them conflict is because they both register > >Norm Walsh's stylesheets. > > That is evil evil evil and I can't tolerate that, no matter what > RedHat does. I'm going to have to track down Mark and slap > him into next week for doing that. I hope you don't mind if I don't > support such broken behavior in the debian package. I don't mind. Maybe he hasn't changed much... > But I'm happy to package it; it should be almost > identical in the debian/* as docbook-stylesheets. I was in a rush, so I used the same layout as Red Hat. I just copied the installation stuff out of the spec file (since there is no Makefile). I like your stuff better, but his source package is arranged differently, and I didn't want to have to debug things. > >I'm not sure how much Cygnus tweaked their > >version. It could be quite a bit since they are using it for internal > >use. Maybe there would be little difference if we used the "real" > >Norm Walsh ones instead? Unfortunately, I don't have enough time to > >experiment at the moment. > > > >I've put the package up at: > > > > ftp://ftp.jimpick.com/pub/tmp/adam/ > > > >I didn't put a lot of effort into it. I just tried to get it to work > >like the RPM does. > > I'll need someone with an 'in' on the gnome > team to tell me if my package is doing the right thing, since the > point is gnome, not mimicing the .rpm. > > This is for potato, of course, right? Yep. Cheers, - Jim
Re: Intent to package cygnus-stylesheets
Adam Di Carlo <[EMAIL PROTECTED]> writes: > >Essentially, Cygnus has forked the code. > > Huh. That might be a bit strong - I haven't really looked into the differences in depth. They are being maintained separately, and they are tracking Norm Walsh's stuff. > I understand that Gnome needs db2* scripts... why do they need the Cygnus > stylesheets? They use them internally at Cygnus for their documentation. They are unsupported for outside use. Don't ask me why Gnome decided to use them. I suppose it's because Mark Galassi is helping out with the docs. > >> Please patch from the potato docbook-stylesheets if you could. > > > >You are asking me to merge two upstream packages which have forked. > >That's a big job. People have been jumping up and down on me for > >weeks to get Gnome out. > > Maybe you could point me to the sources and I could whip it up pretty > quick. Or give me what you're working on. That would be great! > To be honest, there's absolutely no reason the two forks of the > stylesheets have to conflict. They should be able to co-exist fine. The only reason I made them conflict is because they both register Norm Walsh's stylesheets. I'm not sure how much Cygnus tweaked their version. It could be quite a bit since they are using it for internal use. Maybe there would be little difference if we used the "real" Norm Walsh ones instead? Unfortunately, I don't have enough time to experiment at the moment. I've put the package up at: ftp://ftp.jimpick.com/pub/tmp/adam/ I didn't put a lot of effort into it. I just tried to get it to work like the RPM does. Cheers, - Jim
Re: Intent to package cygnus-stylesheets
Adam Di Carlo <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> you wrote: > >Soon, I'm going to upload a "cygnus-stylesheets" package. It's > >basically the same thing as the docbook-stylesheets package, but it > >has some modifications and additional hacks that Mark Galassi has > >added. > > > >This package is based on the same source as what the Red Hat people > >are using. The Gnome project documentation uses this package - that > >is why I had to make it. > > I thought they needed this db2* scriptage. The db2* scripts kinda > suck if you ask me (and not comment from upstream on my specific > technical arguments why they suck) but I'm happy to include them. > Please just patch! The Cygnus stylesheets differ by much more than just db2* scripts. On the Norm Walsh portion of the tree (only about half the package), diffstat says: 376 files changed, 50652 insertions, 735 deletions Essentially, Cygnus has forked the code. > >As soon as I upload it, I'd like to put it up for adoption. > > Ick. Slash-n-burn? I don't have time to maintain it. > >Perhaps it can be merged with docbook-stylesheets? Right now, it's > >set up to conflict with that package. The packaging is relatively > >crude in comparison, because I needed to get it out in a hurry. > > I'd rather if you just sent me patches. That would seem easier for all > than creating a package then abandoning it. Obsolete pacakges tend > to pile up on users' boxes. > > Please patch from the potato docbook-stylesheets if you could. You are asking me to merge two upstream packages which have forked. That's a big job. People have been jumping up and down on me for weeks to get Gnome out. Cheers, - Jim
Intent to package cygnus-stylesheets
Hi, Soon, I'm going to upload a "cygnus-stylesheets" package. It's basically the same thing as the docbook-stylesheets package, but it has some modifications and additional hacks that Mark Galassi has added. This package is based on the same source as what the Red Hat people are using. The Gnome project documentation uses this package - that is why I had to make it. As soon as I upload it, I'd like to put it up for adoption. Perhaps it can be merged with docbook-stylesheets? Right now, it's set up to conflict with that package. The packaging is relatively crude in comparison, because I needed to get it out in a hurry. Cheers, - Jim
Re: libpng & gnome & slink
Havoc Pennington <[EMAIL PROTECTED]> writes: > On Mon, 18 Jan 1999, Stephen Crowley wrote: > > > On Mon, Jan 18, 1999 at 09:14:14AM -0500, Brian Almeida wrote: > > > On Mon, Jan 18, 1999 at 03:03:26PM +0100, Sven LUTHER wrote: > > > > and how the unfortunate of us who already have upgraded to 1.0.2 can > > > > downgrade, > > > > i see the 1.0.1 package nowhere ... > > > !find libpng2 hamm > > > bma: um, dists/hamm/hamm/binary-i386/libs/libpng2_1.0.0-0.1.deb > > > > > > > what about latest gnome packages ? (0.99.3), is nobody packaging them ? > > > Stephen Crowley (aka Crow-) is. > > > > > > > Well, I was going to...but then jpick said just to wait til he's ready with > > them. Who knows when that will be? For now you can get them from > > http://master.debian.org/~crow/gnome but they aren't official so don't bug > > me if they don't work ;) (sorry, i already erased the .diff.gz's) > > > > Why don't you guys work together or something? There are debian > directories in Gnome CVS, it would be nice to keep those up a la the Gtk > debian directories are so people can make their own packages. Stephen if > you don't have a Gnome CVS account that's no problem to fix. Gnome is > *huge*, and Jim is already doing tons of other stuff. It needs to be > packaged ASAP, so it can get some beta testing in the short time before > 1.0, and then any post-1.0 bugfix releases will need packaging in a timely > manner. There have been RPMs for all the .99 Gnome releases, and the > Debian users are feeling the tarball pain. > > Lots of other packages are waiting on this. For example, it's hard for me > to get any testing on Gnome-Apt until those Gnome packages are ready, > Mitch can't even package it yet. > > If nothing else, let's put Stephen's unofficial packages on ftp.gnome.org > with the RPMs, perhaps? Hold on. I should have an upload ready in the next few hours. I've been working on them for days. (I was cut off from the 'net all weekend due to a hardware failure) Cheers, - Jim
Re: Emacs addon packages--compile upon install?
[EMAIL PROTECTED] (Ben Pfaff) writes: > This morning I uploaded a version of w3-el that doesn't compile upon > installation--instead, there are separate precompiled packages for > Emacs 19 and Emacs 20, plus a shared documentation package. I see > this as a better way to go than forcing the end-user to have to sit > through a long compile (it can take 15-30 minutes for w3-el to compile > on an older machine). > > I am trying to remember the rationale we had for making Emacs' addon > packages compile when they install themselves, and I can't remember > it. Perhaps you can remind me. > > Unless there's a really good reason, I think it might be better > strategy to more towards something closer to the w3-el model, i.e., > one binary package for each Emacs version: for instance, bbdb-e19, > bbdb-e20, bbdb-x19, bbdb-x20. There could be a bbdb-common or > bbdb-doc for shared files. > > Comments? I agree that waiting for the large add-on packages to compile during installation is very aggravating. At the same time, it puts a lot of load on the maintainers to build so many byte-compiled versions. How about a hybrid approach? ie. for bbdb bbdb-el - source package bbdb-auto- compiles for each emacs when installed bbdb-common - common files bbdb-doc - documentation (optionally) bbdb-e19 - for emacs 19 bbdb-e20 - for emacs 20 bbdb-x19 - for xemacs 19 bbdb-x20 - for xemacs 20 What would be really nice is if the pre-byte-compiled versions could be built separately from the main source. That way, they could be prepared by somebody other than the primary maintainer (using an automated package building script, similar to the "make-kpkg" approach). Small emacs add-on packages wouldn't need the pre-byte-compiled packages. But it would be very nice for larger packages, such as bbdb, gnus, w3, etc. Cheers, - Jim
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
Havoc Pennington <[EMAIL PROTECTED]> writes: > On Fri, 16 Oct 1998, Craig Sanders wrote: > > > > maybe a compromise would be to leave the packages in slink, make sure > > the Description: field highlights their alpha status, and automatically > > close all non-packaging bugs (and forward them upstream if it makes > > sense to do so). > > > > I hope this is what Jim decides to do... we really want people to try out > the Gnome software, even though it's alpha. Red Hat ships it for that > reason... bug reports can go upstream, or just be ignored if they've > already been fixed in more recent Gnome versions or Jim doesn't have > time... I was just asking people's opinions as I was unsure what the criteria for putting things into "stable" was. Most people seem to be in favour of putting Gnome into stable, mostly for marketability reasons, so I guess I'm OK with that. However, I don't want to make the stable release look bad - so I think I'll do a bit more work on the packages to make them a bit more newbie-friendly. > If it's helpful, in the future Gnome could have a GUI splashscreen that > says ALPHA in big red letters. ;-) I think we need something like that. There are quite a few Gnome programs that are fairly stable, and are going to maintain compatibility (for file formats, and such) going forward. On the other hand, I'm sure lots of Gnome programs are going to be breaking forward-compatibility, as they are still under heavy development. We'll probably still get people using stable who will see "alpha", ignore it, and get burnt. If that's OK with everybody, I don't see a problem with Gnome in stable. > Alpha releases could even expire after 90 days or something... boy, > would we get flamed for that. ;-) That's an awful idea. :-) Cheers, - Jim
Re: Gnome 0.30 fix?
Chris McKillop <[EMAIL PROTECTED]> writes: > Quick One... > > I know that the gnome 0.30 deb files are alittle messed up, > but I don't remeber every seeing a "fix" to the segv problems. Was > it a gtk/gdk problem with 1.0.x vs 1.1.x? I am trying to get eeyes > to work and not having much luck...nor any of the other gnome apps > in gnome-base. I have the same problem here. I spent a little time trying to debug it, but never finished due to a lack of time. It might have something to do with gtk and themes, but I'm not sure. If anybody can send me a patch, I'd be eternally grateful. Cheers, - Jim
Re: Removing Packages in Slink for Debian 2.1
Brian White <[EMAIL PROTECTED]> writes: > Okay, everybody... It's that time again. I've gone through the bug logs > and made my list of packages to keep/remove should they still have > release-critical (i.e. critical, grave, or important) bugs at ship time. What do you think we should do with the Gnome stuff? The Gnome 0.30 stuff is still under rather heavy development. The current packages in Slink are pretty much alpha-quality. Lots of things don't work. It sounds like there will probably be a 1.0 release coming up in a few months that will be thoroughly tested and stable. I'm not sure if it's a good idea to release them as a part of a "stable" distribution, as they really aren't. There aren't any guarantees that the stuff that runs today is going to run tomorrow. Cheers, - Jim
Re: Upcoming 2.1 Release Architectures
Brian White <[EMAIL PROTECTED]> writes: > Could I get some official word on which architectures wish to be included > in the 2.1 release of Debian? Thanks! ARM is nowhere near being release ready (we just started). Cheers, - Jim
Re: [TECH-CONTACTS] Debian
Andrew Howell <[EMAIL PROTECTED]> writes: > On Tue, Oct 06, 1998 at 11:49:26PM +0800, Stephen Darragh wrote: > > Is there any way to get Debian to rebuild or repair a corrupted > > package information database (e.g. on beldin)? > > Not that I know of unfortunately. I'll ask on debian-devel as this is > something I've wanted a few times as well. > > Any ideas Debian guys? :) Because the package database is just a bunch of text files, the package database is pretty easy to fix. You can edit/delete files that are obviously corrupt (ie. /var/lib/dpkg/status), and use "dpkg -i" (possibly with --force- options) to reinstall any packages that are messed up. Of course, it's probably a good idea to make a backup before messing around with such things. :-) Cheers, - Jim
Re: Imlib NMU
Brian Almeida <[EMAIL PROTECTED]> writes: > > libjpeg6b is broken and shouldn't be used by any new packages. It > > doesn't respect the upstream maintainers choice of soname, namely > > libjpeg.so.62, and hence makes Debian incompatible with Red Hat. > > (RedHat does use the the upstream soname.) Until somebody gets around > > to releasing a "libjpeg62" package, we should stick with libjpeg6a. > Oooh. Interesting snag. So. We need to make a joint decision. I talked > to Jim Pick last night about putting 6b in slink, and get it in before the > freeze. However this makes me edgy. Jim, Chris? Your opinions? Maybe we > should just leave it at 6a...even Chris admits that 6b has not been tested. > I don't want to break every Imlib dependent package totally a week and half > before the freeze. Let's do something compatible with Red Hat (unless there are good reasons not to). Synchronizing SONAMEs is one of the goals of the LSB. If we are going to switch to libjpeg62 - let's do so before the freeze. Cheers, - Jim
Re: what's after slink
Kenneth Scharf <[EMAIL PROTECTED]> writes: > After you freeze slink, what will be then name of the new 'unstable' > release (debian 2.2 or 3.0 that is). If "Bug's Life" is any good, maybe we could snarf names from there... Cheers, - Jim
Re: gnome again
Rob Browning <[EMAIL PROTECTED]> writes: > Jim Pick <[EMAIL PROTECTED]> writes: > > > I should probably add that to the README - and maybe a note to try > > running "panel" to get to all the other applications. Anything else I > > should put into the README? > > I don't know about the README, but I just noticed that after I > installed libgnome0, the hello programs died with shared lib problems > until I ran ldconfig. > > I don't know if policy's been updated, but contrary to what it used to > say you need a call in one of the install scripts (the postinst, I > believe). Strange. The released version of libgnome0 has a call to ldconfig in the postinst. I put it in there because lintian was nice enough to complain. Perhaps you were using the pre-release one I put out a week and a half ago? Unfortunately, I didn't increment the version number from the pre-release to the released ones. Cheers, - Jim pgpHOWoVIHy4Z.pgp Description: PGP signature
Re: gnome again
"Meskes, Michael" <[EMAIL PROTECTED]> writes: > Okay, I tried starting icewm and then some gnome applets resp. some of > the desktop tools. But they all seg fault. And I get a message that > imlib is lacking the file in /usr/etc. Do I have to set an environment > variable? > > I think we should add a README explaining how to use gnome to the > packages. That doesn't happen to me. Which version of imlib are you using? You shouldn't have to configure anything to use the gnome applications - it should just work. If it doesn't, then there are some bugs I need to fix. Oh! One thing I forgot to mention in my announcement was that if you were using gnome 0.12 -- you really need to remove your ~/.gnome directory and start off fresh. I suspect that is where you might be having some problems. I should probably add that to the README - and maybe a note to try running "panel" to get to all the other applications. Anything else I should put into the README? Cheers, - Jim pgpysJiBsjR6M.pgp Description: PGP signature
Re: New gnome packages
Michael Meskes <[EMAIL PROTECTED]> writes: > Am I correct that we currently do not have a complete desktop with gnome? > Since there is no wm yet, it's pretty difficult to judge it. This is a Gnome FAQ item. Gnome is not meant to have a single window manager. In it's final form, it will work with any window manager. There is the beginnings of a specification for what needs to be done to a window manager for it to be Gnome compliant. I suspect that icewm, scwm, and enlightenment will be gnome-compliant window managers, as their developers are also gnome developers. > Also it seems some libraries/binaries are compiled with debug flags set. For > intance I got this when using gnome-terminal: > > ** WARNING **: gnome_message_box_set_modal is deprecated. > > $ [l,1,1] > [s,1,1] > ,1,1] > [e,1,1] > [x,1,1] > [i,1,1] > [t,1,1] > ,1,1] > errno = 0, saverrno = 5 > out of data on read The first part of that is a failed assertion -- basically, it means the underlying API was changed. The rest of it looks like a bug. The Gnome 0.20 release is essentially a snapshot release (alpha quality at that), and it has not undergone a rigourous testing cycle upstream. So I'm expecting lots of bugs like this. I wouldn't go to great lengths trying to report bugs like this, as they have probably already been corrected upstream, as Gnome is under very active development. I've mentioned that it is alpha-quality code in the README, and it's definitely not ready for general consumption (ie. the stable Debian release) > Finally there is one incorrect dependency. gnome-utils depend on > libobgtk0 but there is only libobgtk1 Oops. My mistake. I'll upload a fixed version right away. In the meantime, using dpkg --force-depends should work. Cheers, - Jim pgpYSmD1vHTiz.pgp Description: PGP signature
Gnome .debs released
Hi, I've uploaded the Gnome 0.20 Debian packages to incoming on master.debian.org (also available at http://www.jimpick.com/ ) I had some problems with the gnome-admin package, so I didn't finish it. I will be travelling for 4 days, and I will figure it out when I am back. I also did not package the new mc (Midnight Commander) - I'm not the maintainer for that package anyways. These packages are linked against libungif. Theoretically, they should work with libgif as well, but the libgif package is missing a couple of symlinks - so use libungif (or create the symlinks). Anybody that installed the unofficial pre-release .debs I put out last week will probably need to install these .debs by hand (instead of relying on dselect) - because I didn't increment the version number. Cheers, - Jim pgpDFoWKU02SH.pgp Description: PGP signature
ANNOUNCE: Debian NetWinder Porting Project
Hi, I'm helping to organize an effort to port Debian GNU/Linux to run on the new Corel NetWinder NCs ( http://www.corelcomputer.com/ ). Debian GNU/Linux is the largest Linux distribution, with over 1500 packages and ports to Intel, Alpha, m68k, PowerPC and Sparc. It is being developer entirely by over 300 volunteers on the internet. If you are a Debian developer, and are interested in contributing to this effort, please contact me, and I will add you to the list. We are also collecting a list of people who would like to acquire NetWinder hardware to develop on. For more information on the project, here's the web page: http://master.debian.org/~jim/netwinder.html More information on Debian is available at: http://www.debian.org/ Cheers, - Jim pgpeytu24GzNe.pgp Description: PGP signature
Re: [Fwd: Debian Netwinders]
Jim Pick <[EMAIL PROTECTED]> writes: > As for the machines, he says the developers versions are the > top-of-the-line model, with a 3.1 GB hard drive and 64 MB of RAM. I > think they are based on a 233MHz StrongARM. ^^ Oops, make that a 275MHz StrongARM. I found the specs at: http://www.netwinder.org/specs.html Hardware Specs Processor * StrongARM (SA110) 275 MHz, delivering over 260 Mips Flash Memory * 1 MB, provides diskless booting capabilities, expanded security and configuration capabilities Memory * 16, 32 and 64 MB SDRAM (10 nanosecond) Hard Drive * Drives are available from 1 to 3 GB in a 2.5" slimline form factor Connectivity * Two ethernet ports, one 10BaseT and one 10/100BaseT * EPP/ECP port * IrDA port - commercial and electronics grade * Serial port Video * 2 MB accelerated SVGA video capable of 1600 x 1280 in 256 colors 1024x768 in 16 bit Multimedia * Full duplex 16 bit stereo sound card (44100Hz sampling) * Built in microphone/speaker * NTSC/PAL (composite video in/out) * Onboard capture and playback * Telephony Support (drool) This could be fun. :-) Cheers, - Jim pgpbVSVKWU3G1.pgp Description: PGP signature
Re: [Fwd: Debian Netwinders]
Behan Webster <[EMAIL PROTECTED]> writes: > Looks like you guys can talk to Chris or San directly about Netwinder > development if you wish. I just phoned Chris Herrnberger (the OCLUG guy), and quizzed him. He says Corel has loaned OCLUG ten Netwinders for development purposes. If we want to get going on development right away, he's even got a spare one that he could mail to us right away! What he wants to know from us is: 1) Who we are and what we want to do. 2) How many of us are going to do work on the port. 3) How many machines do we need/want. I'm going to send him an email answering at least the first question. He's going into Corel Computer tomorrow to talk to San Mehat, so he'd like to take some of that information in with him. I guess I sort of volunteered to be the point person for the porting effort, so if you are interested, please contact me, and I'll add you to the list. Tell me if you are interested in buying a machine for your own use as well. If you are interested, you should also go to www.netwinder.org, and sign up there to get on the developers list. He says they are swamped with applications right now, so it may take several days to get processed. As for the machines, he says the developers versions are the top-of-the-line model, with a 3.1 GB hard drive and 64 MB of RAM. I think they are based on a 233MHz StrongARM. They haven't settled on the discounted price for developers, but it should be between $700-$1100 CDN ($490-$770 US). He says Corel wants to get as many machines out into the hands of developers as possible. I asked when they are going into production, and he said that they are in production right now - but they are waiting for FCC approval. They don't have a problem with supply. He also said that there are going to be various cheaper configurations, and that the price will drop. Cheers, - Jim pgpQgNu6TQhbo.pgp Description: PGP signature
Re: Corel Network Computer Port
Behan Webster <[EMAIL PROTECTED]> writes: > I also have an offer from one of Brian's friends (he was lent one of the > Netwinders). He is willing to give a few people accounts on his > Netwinder. He just has a few security concerns to address first (he's > got to pick up a hub to connect the Netwinder to his 10base2 home > network and then setup some firewall rules to protect the rest of his > network). I'm not sure, but I might be able to talk him into giving a > few people root access on it too. What would be cool is if we could convince him to have two partitions - one for Red Hat and one for Debian. :-) Of course, if I can get my own, that would be better. Cheers, - Jim pgpnuKAxUYJbC.pgp Description: PGP signature
Re: Corel Network Computer Port
Steve Dunham <[EMAIL PROTECTED]> writes: > When/if they are ready and Corel doesn't want to sell them directly, > someone like varesearch or linuxmall could be convinced to become > resellers. (Or even Red Hat would be interesting...) Even non-traditional channels could resell them (as long as they could hire support). It's not like a traditional PC - there's nothing to configure, they come in a box. Small ISPs could sell nice little preconfigured Gnome boxes to people who want a PC for surfing the net. Cheers, - Jim pgp16yXws1msq.pgp Description: PGP signature
Re: Corel Network Computer Port
Behan Webster <[EMAIL PROTECTED]> writes: > They are only giving discounts to OCLUG members, but since I'm in OCLUG, > I could probably approach the appropriate people to do some enquiries. > I wouldn't hold your breath though. OCLUG is very RedHat based. I've talked to some of the Corel guys on the phone before, and they seemed very reasonable and open-minded. Basically, nobody has sold Corel on the potential of OEM vendors using Debian. They've just been listening to Red Hat and their convincing story of how they are making megabucks, and the sales channel that is already in place there. > As far as I know Corel Computer Corp is making a bank of Netwinders > available to the net. You have to setup login permissions through > OCLUG. I'll make some enquiries... That might be useful for bootstrapping Debian. :-) > How many developpers are we talking here? Last I heard they were > looking for a few good hackers, especially kernel hackers. They still > have kernel features that they would like to see implemented too. Maybe > I'm opening a pandora's box here, but which Debian Developpers are > interested in getting access to or buying a netwinder, etc? (Last I > heard Corel is thinking of $1000 (CDN I think) per netwinder). Sign me up - I can come up with $1000 CDN no problem. Cheers, - Jim pgpayrKmX3ttG.pgp Description: PGP signature
Re: Corel Network Computer Port
Steve Dunham <[EMAIL PROTECTED]> writes: > > I bet we could brow-beat Corel into donating a few boxes. I heard > > they go as cheap as $300 US for a diskless configuration. > > It's all just rumors, I've heard nothing back from them. We might > have to brow-beat them into selling boxes. You could also try touching base with the Ottawa-Carleton LUG. http://www.oclug.on.ca/ They're pretty plugged into Corel. We've got a few developers in Ottawa (Brian White, Behan Webster, ???) - we might be able to ask them to do some footwork if need be. Cheers, - Jim pgptE4xWMPkoX.pgp Description: PGP signature
Re: Corel Network Computer Port
Joel Klecker <[EMAIL PROTECTED]> writes: > At 21:20 -0700 1998-06-05, Steve Dunham wrote: > >Does anyone have any definite information on the Corel Network > >computers? Is anyone else interested in doing a Debian port? > > Vincent Renardias is apparently working on an arm port of Debian (In bug > #21327 against ftp.debian.org, he asks for a binary-arm section). This is > the processor that the Corel NCs are based on, right? Yep. The source is available at www.netwinder.org I bet we could brow-beat Corel into donating a few boxes. I heard they go as cheap as $300 US for a diskless configuration. I'd love to get one to play with. :-) Cheers, - Jim pgpgAfrQbmAvH.pgp Description: PGP signature
Debian Gnome anxiety cure
Pre-release .debs (still under construction). 24 of 'em, more to come. ftp://ftp.jimpick.com/pub/debian/testing/ Be fore-warned - they've hardly been tested. Also, the imlib packages aren't the real ones - they're just quick hacks so I could compile the rest. Sean Perry <[EMAIL PROTECTED]> is working on real libungif and imlib packages. Those will need to be released before I can upload real Gnome packages to master.debian.org (in a day or two, hopefully). Have fun. And don't bombard me with feedback just yet. I'm still in the phase of just getting something released. Cheers, - Jim pgpQmpY9mZ1MK.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
> > What news servers besides slrn support reading news directly from the news > > spool w/o a news server? > > tin (rather than tin -r or rtin). Gnus (in emacs). Cheers, - Jim pgppKPgXPsA90.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
John Labovitz <[EMAIL PROTECTED]> writes: > Jim Pick <[EMAIL PROTECTED]> said: > > > The whole exim package is about 500k, which only takes 5 minutes or so > > to download via modem - so I'd probably stick with that (unless > > something better comes along). MTA choices are easy, because there is > > very little user-visible stuff involved. > > have you looked at ssmtp? i just took a quick look at the source, and > it seems that it's *extremely* simple -- sounds like a good one for a > send-only MTA. I haven't looked at it. It's only 15k! That would be a really good choice if it actually does the job. :-) Cheers, - Jim pgpfQROkXt0Ry.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
Hamish Moffatt <[EMAIL PROTECTED]> writes: > I think smail or exim would do fine. I'm in love with exim myself. :-) The whole exim package is about 500k, which only takes 5 minutes or so to download via modem - so I'd probably stick with that (unless something better comes along). MTA choices are easy, because there is very little user-visible stuff involved. The choice of a single MUA will be much more contentious. Cheers, - Jim pgpQamcOAgCHt.pgp Description: PGP signature
Re: Time to say goodbye...
Christian Schwarz <[EMAIL PROTECTED]> writes: > The discussions of the last days have shown me clearly, that I can't > implement my ideas WRT policy/QA anymore. > Therefore, I've decided to leave the Debian project. Sorry to see you leave. I must admit, I've been entirely negligent in following the policy discussions - due to lack of time, I've skipped them entirely. Instead, I've been relying on you to form a consensus and write them up into official policy. I suspect that most of the other "older" maintainers are the same way - they've skipped the policy discussions altogether - which would explain your perceived lack of support. I discovered about a year ago that the policy discussions are very draining and mostly negative, and seldom go anywhere. The only people who get anything accomplished in Debian are the people who actually do packaging and coding (although having a policy editor role is still important). I don't know how you held out for so long. Perhaps, instead of leaving Debian completely, try this -- just resign as the Policy guy first, and continue as a regular developer. I think you'll find it to be much more relaxed and enjoyable. This project is infamous for letting people "burn out" unnecessarily. Cheers, - Jim pgprDA7ghvuct.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
Drake Diedrich <[EMAIL PROTECTED]> writes: > On 1 May 1998, Jim Pick wrote: > > > I'd like to see more people announce that they want to develop their > > own "subset" Linux distributions based on Debian. I'd be willing to > > collaborate on tools to make this easier. > >Interesting. I'm starting up an ISP with a Debian focus, and planning > to produce configuration-packages which will be added into the local > Debian mirror, producing a (barely) derivative Linux distribution. > I suspect many consultants and ISPs will begin doing this. I worry about > name collisions in real derivatives though. >We may need some new policies with respect to derivatives, so we avoid > clashes. Off the top of my head: > 1) Derivatives are allocated a subdirectory in /opt by Debian. As far as people developing local packages to add on to Debian (which is not really what I am planning) - I don't think additional policy is needed for that, because they are "local" packages, so it is a matter of "local" policy. Cheers, - Jim pgps2YHr5ndAl.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
Mark Baker <[EMAIL PROTECTED]> writes: > On Fri, May 01, 1998 at 11:10:39PM -0700, Jim Pick wrote: > > > - targetted towards desktop use only, no server apps, just a few games > > > > - minimal size - optimized for installation via 28.8k modem via FTP, > >which will be the primary distribution mechanism (not CD). > > These don't seem consistent to me. If people are the wrong side of a dialup > link, they need to have a local MTA (actually most people ought to have that > even if they're not, although the configuration is significantly simpler if > they're on a permanent fast network connection and so don't need local > mailboxes) and a local news server. Oh yes, it will have an MTA. When I said "no servers", I meant stuff like web servers, SQL databases, etc - stuff you might find on an Internet server or LAN server. In reality, there will dozens of "servers" for personal use. I'm going to use CORBA-based stuff wherever I can, so all those objects could technically be considered to be "servers" as well. > Other than that, it sounds good---not for me, and probably not for the > majority of Debian's existing users, of course, but for people who want a > simple desktop OS that's easier to use than Windows. And existing Debian users don't have to choose, because I'm not leaving Debian, and I'll put the same stuff into Debian (as long as it fits policy). :-) Cheers, - Jim pgpBw0vmkieOE.pgp Description: PGP signature
Yet another Linux distribution! :-)
Hi all, I read with interest Bruce's post that he wants to work on another Linux distribution. :-) As long as we are talking "pie in the sky" stuff, I thought I'd let loose with the news that I am also developing an alternative Linux distribution. I've sort of hinted about it on several of my webpages anyways. I've had this idea for two years (at least), but it's just lately that I have actually started to work on it. Here are my plans: - mid/late-1999 for first release (codename: Skaha) - I'm not rushing things. :-) - it will be a strict subset of Debian (and will include support for upgrading to full Debian distribution via apt) - basically, Debian is the "upstream" distribution, and this would be a "downstream distribution" - dpkg based - probably using apt (perhaps with an additional front-end) - targetted towards desktop use only, no server apps, just a few games - minimal size - optimized for installation via 28.8k modem via FTP, which will be the primary distribution mechanism (not CD). - slickest, easiest install in the business - self-hosting (it has everything needed to compile itself) - 100% open source / DFSG compliant (no non-free or contrib packages) - minimal set of install options: 1) console only (with base application set) 2) X11 user (primarily Gnome/Gtk based, I hope) Includes base application set, with: one window manager, one editor, one file manager, one email/news program, several web browsers (with one front end), one documentation system, several scripting languages The following application sets can be chosen (preliminary): 2a) graphics - Gimp, 3D apps 2b) publishing - TeX, SGML, etc. 2c) small business - GnuCash, Inventory, Taxes 2d) CAD/Robotics/Control Systems 3) Developer - all tools and libraries required to make distribution self hosting. - sysadmin (and users) can use apt to install additional packages from Debian distribution. - initial distribution will be i386 GNU/Linux, localized for Canada and the USA. Beyond that, I may attempt a Cygnus GNU/Win32 hosted distribution, and maybe ever a GNU Hurd based one. - very strong technical direction. As little duplication as possible in terms of applications and libraries. Everything will be document-centric, and tutorial driven. There will be a single document model. It will be another Linux distribution - but it will also be a strict subset of stuff inside Debian. It will be promoted as such. It will not have an "open" development model as Debian has. Actually, initially, it will only have one developer (me). If my consulting business improves, I might consider paying people to help me out with it. I don't want any volunteers however, as that would lessen my control (anybody volunteering for Debian will be helping me out anyways). Most of the work I do will be "open" though, because it will appear in Debian first. The best way to think of this project of mine is basically as "Debian + editorial control". Or you might think of it as a "Jim's hobby project" -- a customized "hot rod" GNU/Linux. If it turns out well, I'll consider marketing it commercially (it should be marketable). I will offer a consulting service that consists of customizing the distribution for clients with "stylesheets" and "themes". I imagine that many local ISPs might want to offer their own customized version of Linux to their local small business clients and home users. As it will be "Open Source", other more-commercial distributions such as Red Hat, Caldera and SuSe can steal stuff with no complaints from me. The driving motivation for doing this isn't commercial though - it's basically a "soapbox" for me to express what I think should be in an OS, and what shouldn't. My point of view is that most of the code that a user really needs has been written already - most of the work needed to build a really nice OS doesn't consist of writing more code (too many free software projects are going down this road). Mostly, it's just a packaging/integration and documentation job to make the current codebase more digestable. Debian already does a lot of this, but this will be focused in a way Debian can't be. I plan to develop some documentation and live tutorial technology which will go far beyond what any free software app currently has. The whole system will be keyed off of the documentation - rather than leaving it as an afterthought. Much of the work I'm going to put into preparing documents and metadata for LinuxHQ and dwww will also go into this new system. The release schedule will vary dramatically from Debian's. There will be stable and development branches. There will be a new stable release approximately every two months (built from packages from the Debian unstable distribution, but tested). Security bugs will
Re: on forming a new Linux Distributionx
[EMAIL PROTECTED] (Bruce Perens) writes: > From: Raul Miller <[EMAIL PROTECTED]> > > For what it's worth, GIF support is doable with free software, just not > > compressed gifs. [gif supports a variety of compression mechanisms, > > including "none".] > > The patent expires in August. > > Bruce No it doesn't. Here's the patent: http://patents.uspto.gov/cgi-bin/ilink4?INDEX+0+4464650+F Note the date it was granted - Aug. 7, 1984 Add 17 years, and it expires August 7, 2001. Correct me if I'm wrong. (I think they've changed the rules to be 20 years from initial filing date as of 1995 - but this is an older patent) Here's the Unisys position: http://www.unisys.com/LeadStory/lzwfaq.html (no mention of the date) Cheers, - Jim pgpQsgYpNxkyt.pgp Description: PGP signature
Re: Gnome debs?
David Welton <[EMAIL PROTECTED]> writes: > > GNOME is currently not very stable and things are changing very > > rapidly. Jim Pick is the GNOME guy for Debian. Give it a few more > > weeks and I think you will see more. I've got most of the packaging for gnome 0.13 done. Unfortunately, the gdk_imlib 1.1 stuff wrecked things - gnome 0.13 required a newer version (which was only available in CVS). Everything would build, but most of the binaries would not run. Raster released gdk_imlib 1.2 a few days ago, so I may be able to release some gnome stuff that works sometime this week. > The thing I was wondering about is getting support in their build > scripts for debs. Every morning they get some rpm's generated > automatically. I was wondering if it might be feasible to do this > to make some debs too, or if it would be just a waste of time:-/ I was thinking of building snapshot Gnome packages from the CVS that I might update weekly from here. I thought about doing it daily, but that would be too much work. My thought was to put this in a non-standard location (ie. under /opt) so that they wouldn't interfere with released versions of Gtk, Gnome, etc. The debian/rules will be different for the snapshot packages than the released ones - so I'll have to figure out a scheme to work around that. Perhaps the Red Hat labs guys would be willing to build the .debs too. Even if they were willing to do that - they might not be the best choice to do it, as they wouldn't be testing the .debs. Once I get the packages built, I'm going to see if I can get the "debian" directories put into the Gnome CVS. Cheers, - Jim pgpGsDUPMAxSS.pgp Description: PGP signature
Re: /tmp exploits
Ian Jackson <[EMAIL PROTECTED]> writes: > We should modify our libc so that opening a file in /tmp or /var/tmp - > determined by simple string comparison of the filename passed to > open(2) - fails if O_CREAT is specified without O_EXCL. > > We should do this in slink. That way almost any program with a /tmp > security hole will stop working straight away and _have_ to be fixed. That seems pretty extreme. If we are going to do something like that - couldn't we just get rid of /tmp altogether? Cheers, - Jim pgpmnJk9VgFPx.pgp Description: PGP signature
Re: intent to package jstation
Stephen Zander <[EMAIL PROTECTED]> writes: > Bummer! I can't help here unfortunately (I'm a jdk source licencee) but > I thought Jim Pick had expressed an intention of persuing free JVM > implementations. > > Jim? I'm freeing up the rest of this week, so I will be able to work on all my Debian stuff I've had on hold for awhile. I wouldn't hold your breath for a totally free Java implementation yet - both Kaffe and Japhar depend on the non-free Sun class library. Some work has been done on a free class library (kore) - but this hasn't been integrated into either kaffe or japhar at this point (except for an older version of kaffe). Cheers, - Jim pgpT0uNziyXhv.pgp Description: PGP signature
Re: jdk1.1-runtime
Corey Miller <[EMAIL PROTECTED]> writes: > When I try to install jdk1.1-dev (I want to install JavaICQ, which > makes use of the jdk), it says that it depends on jdk1.1-runtime. I was > wondering where I could find this package? I looked in incoming, frozen, > unstable, and even used the package search utility on www.debian.org. > Thanks for you help, It got nuked when hamm was frozen (source is still in project/orphaned, I think, but the binary is gonzo) Stephen Zander <[EMAIL PROTECTED]> is working on uploading jdk1.1.5 - so I didn't bother with fixing 1.1.3. You can still get it from: ftp://ftp.jimpick.com/pub/debian/pkgs-old/jdk1.1/1.1.3.v2-1 Sorry for any inconvenience. Cheers, - Jim pgpAKlUEDo85e.pgp Description: PGP signature
Re: Number of Maintainers
Brian Bassett <[EMAIL PROTECTED]> writes: > After both Manoj Srivastava and Bob Hilliard pointed out to me the faults > in using the Maintainers file for determining the number of maintainers, I > have decided to use the Debian PGP keyring. After deleting duplicate keys, > the keyring says that there are 313 developers, making Q 8.85 and K 5. > > Brian You know what would be cool - if the www.debian.org homepage had a running count of the number of maintainers! That's Debian's biggest selling point, as far as I'm concerned. Cheers, - Jim pgpKezikvA920.pgp Description: PGP signature
Re: Guile question: What was bug #14213???
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: > The changelog lists only a bug number, with no description of what > the bugs were. They are no longer in the bug tracking system. You are hitting on one of my pet peeves - we should have a perpetual bug archive for closed bugs. > Can you explain why you couldn't compile with threads or dynamic > linking? It was a co-ordination issue with the Gnome package - I don't think Gnome would compile when threads were included. I didn't know what to do to make it work (when using guile) - and there is no documentation. I think thread support and dynamic-linking in 1.2 are experimental - so I think it's fair to leave it out. Everything seems to work when those are left out. I assume Guile 1.3 will be a big improvement. > I'm putting together a guile-core snapshot package, perhaps > for release if I feel like I have it under control. It will come > with the guile-scsh too, I hope. That should be good for gnome. :-) Cool. Say, if you are going to to do that, do you want to take over the guile package? You can have it, as there should only be one guile maintainer, IMHO. > I've Cc'd debian-devel to show others what can happen when we don't > put proper detail into the changelogs. The bug number alone is no > good; the tracking system purges them after a period of time, so the > only record is in the changelog or CVS logs (which are more difficult > for others to get at, obviously.) I don't think the changelog is the place to give full-blown bug descriptions. They can be very hard to describe at times. A little hint as to what the bug was in this place would have been nice - but I'm not sure I could have described what the bug was in under ten lines of description. > > guile (1.2-3) unstable; urgency=low > > * Removed --with-threads and --enable-dynamic-linking options > (should fix #14213, 14214 - Thanks John Goerzen) > * Added ldconfig to postinst > Fixes Bug #41212 - Thanks Jogn Goerzen > > -- Jim Pick <[EMAIL PROTECTED]> Wed, 29 Oct 1997 22:27:48 -0800 Hmmm - I can't remember the details of #14213, #14214 - I should have a copy on my machine, but I think I must have filed in into the wrong mail folder. :-( > karlheg, who aspires to understand the implementation of Scheme someday. Read the Wizard book (SICP). :-) Cheers, - Jim pgpgJxiwU2N1z.pgp Description: PGP signature
dwww Missing-in-action
Sorry, For those holding their breath... I had system problems this weekend. I'll have dwww ready next weekend. Cheers, - Jim pgpFTRhdIqcvr.pgp Description: PGP signature
Re: Bleeding edge FTP repository updated to glibc2 + egcs.
Paul Seelig <[EMAIL PROTECTED]> writes: > Has anybody already noted this here? [ Cut - Posting about Yggdrasil packages - RPM/deb/slackware/yggdrasil from common source ] Looks interesting! I wonder if they are proposing a new source packaging format - or if they are building all the binary packages from an unpacked tree. Judging by the contents of their build.log and install.log files, it seems they just have one huge FreeBSD-style "make world" happening. I looked at one of the SRPMs, and saw no Debian stuff. I don't think they have a source packaging format. Too bad. But they must have all the source in place to do multiple binary packages... they just haven't put it up yet. I'd like to see a common source packaging format that could be used to generate any type of binary package. I'd advocate using such a source format for Debian - because then we could help organize people who want to do 'contrib' packages for other distributions - and as a spin-off, reduce some of the duplicated work in the free software community. It would also be an excellent step towards a unified binary packaging format. Whether or not we want to deal with 'outsiders' is another matter altogether. We might get distracted somewhat from our Debian integration work if we are trying to produce portable packages. Also, I'm not sure if our one maintainer per source package system is flexible enough to deal with supporting multiple architectures, languages, and multiple distributions too. I don't think it would be too much work rigging the ability to generate RPMs into our package building process, or to use Red Hat 'spec' files with dpkg-dev. Someday I'm gonna figure out how to do that. Cheers, - Jim pgpOYsfsTWRG8.pgp Description: PGP signature
The next dwww (was Re: Financial support)
> > Look for an updated dwww package and a new "kaffe+kore" package this week > > > Yuhuu! > > Is it the version with the "big step forward", you promised some time ago? Unfortunately, not. It's more of a "fix as many of the 40 bugs as possible" release. It'll be a little step forward, setting the stage for the "big step forward" release in a month or so. Don't expect much new for the next release, except support for the index on multiple heirarchial pages (I haven't tried menu's support for that yet), and maybe support for .dhelp files too. The "big step forward" release should have much better support for a wider range of meta-data, a DSSSL-based menu building system (yes, yet another menu building system), better search capabilities, and an extensible architecture. I've got some additional plans that go beyond that release too. (oh yeah, since Brian is still cc'd to this - I should mention that I'd like to do a pgsql package too, now that we have an updated postgresql package again) Cheers, - Jim pgpr6gOMexbxY.pgp Description: PGP signature
Re: dhelp 0.2 - a online help system
[EMAIL PROTECTED] writes: > I like it but... I like it too. > 1) How about dwww? (Yes, I know dwww needs a web server...) I think I'll add support for .dhelp files to dwww too. > 2) I really dont like to have 2/3/... methods of building indexes > of documentation installed in the debian system. What about integrating > all that stuff? (menu, dwww, dhelp, etc...) I agree - we should eventually have only have one index. I've been working on yet another way of building an index, but I'm been very slow working on it. > 3) The policy says the preferred doc format is HTML (fine) but > it says nothing about how to access it. Any ideas before we poor > developer have to write a dozen of different conf files to support > all that new help systems? (menu entries, .dwww-index, .dhelp, etc...) I'd consider all documentation menu systems "experimental" at this point, so I wouldn't worry about it yet. Just support a particular menu style if you feel like playing with it. FWIW, the menu system I'm working on was going to be SGML/DSSSL based, so Marco's .dhelp menu format is perfect for that. I'll be able to use the .dhelp format as input. Short term (in the next few days), I'm also going to enhance the dwww menu-package based menus. I'll see if I can write a .dhelp to "menu" converter. That way, package authors can write a single .dhelp file, and support all the menu-building packages (dhelp, menu, and dwww-next-generation). The next dwww should be ready by Sunday, at least. Cheers, - Jim pgpI4G57nF7q9.pgp Description: PGP signature
Re: Financial support
> Pardon me for a nosy question. Does Debian have any money flowing in > from users that is used to compensate full-time Debian developers? Debian does solicit donations to Bruce Peren's "Software in the Public Interest, Inc." non-profit to help defray costs (like Internic fees, etc.). Here's a list of the donations so far: http://www.buoy.com/debian/misc/donations.pl Unfortunately, there is no record of outflows there. I imagine that SPI will have to do an annual report eventually where all that info is public. SPI is in the business of giving out "grants". Most notably, they have committed $1000 to the Gnome project (www.gnome.org). I'm not sure what the Miguel and the other Gnomers are going to do with the money, but it is a nice token of political support. Personally, I have no problem spending business time to contribute to Debian - it's a good image/reputation builder. I do have to keep myself in check to make sure I don't "overcommit" my time to the project though. Look for an updated dwww package and a new "kaffe+kore" package this week from me. Cheers, - Jim pgpfxZDfPhuUF.pgp Description: PGP signature
Re: slib and Debian ?
[ Sorry for the exploding cc: list - this is a Debian packaging issue, so please limit the follow-ups to debian-devel. ] Mark Galassi <[EMAIL PROTECTED]> writes: > Jim> Perhaps I should declare a dependency on the slib package, > > Absolutely not! It would be a great loss if Guile were *forced* to > depend on slib. > > Guile is an embeddable library implementing R4RS Scheme, and is quite > useful as that, even without slib. > > That's why I suggested that both Guile and slib try to create the > catalog, that way the one that is installed last will do the creating. > > [by the way, I think that creating the catalog at run time instead of > install time is really non-robust, but we are stuck with what Aubrey > gives us in his otherwise awesome slib] OK. I agree that declaring a dependency isn't really good. I was just being lazy, hoping nobody would call me on it. The code for 'registering' slib with guile ought to be in the slib package (I'm not the maintainer of that package, Rob Browning is). It might go into a 'slibconfig' script. Of course, there are quite a few different Scheme packages other than guile that might also work with slib - so that makes things a bit ugly for Rob. When guile (or another Scheme) is installed on a system that also has slib, it could call the proposed 'slibconfig' script from the slib package. Here's a possible slibconfig script with support for Guile in it: #! /bin/sh if [ -d /usr/share/guile ]; then (cd /usr/share/guile guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" ) fi This would be called from the postinst of slib and guile. Rob, if you think this is a good idea, I could make a non-maintainer release of slib (only supporting guile) -- or I could wait for you to make a release. Cheers, - Jim pgpKiPEyrxfOf.pgp Description: PGP signature
Re: Mail delivery failed: returning message to sender (fwd)
> I don't know if this is a bug with procmail(3.10.7-1.5), exim (1.81-1), or > me, so I thought I would ask. I recently switched to exim from smail on my > hamm (currently as up to date as possible) which unfortunately bounced all > of my mail. It seems that exim doesn't like the mail filter pipe used by > procmail in my .forward. The error message is below whivh also includes a > copy of my .forward. Any ideas what is wrong? It seems to me that somehow > the blank assigned to IFS is not being passed properly. Any help is > gratefully appreciated. Cheers. This .forward file worked for me for procmail on exim: "|/usr/bin/procmail USER=jimtest" It took a bit of trial and error to figure that one out. I'm not sure what -Qf- does, you might want to add that too. Hope that helps... Cheers, - Jim pgpEHPfM3508V.pgp Description: PGP signature
Re: ldconfig warnings
> Yes, it is discussed in the Debian Packaging Manual, section 12. > See: > /usr/doc/dpkg/packaging.html/ch-sharedlibs.html > > You should just go ahead and file bugs against packages which don't > include the .so link as part of the package. If I understand this correctly, there is no need to use ldconfig in the postinst script, correct? ie. A quick survey of the packages on my system: $ grep 'ldconfig' /var/lib/dpkg/info/*|wc -l 112 And I've only got around 400 packages installed (and not too many libraries) - so I think we've got a serious problem. We ought not to release 2.0 in this state. The shared library thing has always confused me a bit because I tend to pick these things up by example - but if everybody's doing it wrong... Should I file bug reports? What severity? Or am I unduly alarmed? Cheers, - Jim pgp1PX1WUmeaj.pgp Description: PGP signature
ldconfig warnings
Hi, This is a minor annoyance, but it always bothers me. When upgrading or reconfiguring, I chronically end up with "orphaned" lines in /etc/ld.so.conf. ie. Currently, on my main Pentium system... ldconfig: warning: can't open /usr/X11R6/lib/libgtk.so.1.0 (No such file or directory), skipping ldconfig: warning: can't open /usr/X11R6/lib/libgdk.so.1.0 (No such file or directory), skipping ldconfig: warning: can't open /usr/openwin/lib/libgtk.so.1.0 (No such file or directory), skipping ldconfig: warning: can't open /usr/openwin/lib/libgdk.so.1.0 (No such file or directory), skipping Currently, on my 386 system... ldconfig: warning: can't open /usr/local/lib (No such file or directory), skipping ldconfig: warning: can't open /usr/lib/i486-linuxaout/libdb.so.1 (No such file or directory), skipping ldconfig: warning: can't open /usr/lib/libpthread.so (No such file or directory), skipping ldconfig: warning: can't open /usr/lib/libjpeg.so.6a (No such file or directory), skipping It's easy enough to fix, just edit the /etc/ld.so.conf file and remove the offending "orphaned" lines. Anyways, I'm sure this is a chronic annoying problem everyone is experiencing. Is the cause is due to incorrect packaging of the shared libraries? I'm not sure. I'm just wondering if there is a way of automatically cleaning up after those (buggy?) packages are long gone... Or perhaps we need to enforce policy a bit better. If somebody could explain what exactly is going wrong in these packages - ie. what policy are they violating? Or is it dpkg's fault? Cheers, - Jim pgpxieJE6BPVo.pgp Description: PGP signature
Re: Thread safe X libs?
[EMAIL PROTECTED] (Mark W. Eichin) writes: > > Check out the forwarded message below. I get the same error using > > Debian unstable. Does this mean that Red Hat has thread-safe X libs > > and we don't? > > Well, I wouldn't mistake that for a bug report... no indication of > *what* is producing the error, why it would have *anything* to do with > the thread-safe libraries, or that it actually *does* work on RH5. If > the program was built with libc5, it's unlikely to be able to be > thread safe. > > If you could perhaps come up with a *real* demonstration, and an > indication of what release you tested it against, it might actually > mean something... or at least it would give me a starting point to > look for the problem. Every X release for a long time has been built > _REENTRANT, and the 3.3.1 libs are built with some threading options > turned on (I'd have to look at the config files to see what, though.) It wasn't intended to be a bug report. I'm not expecting anybody to debug the problem. I just had the same runtime error as the other guy (I compiled on my hamm system), and I didn't know if I should buy into Elliot Lee's explanation of the cause. I was just looking for confirmation that Debian has thread-safe X libs. So I can now tell Elliot that there is a real bug somewhere, and it's not the fault of not having thread safe libs. I'll move the discussion back to the Gnome list now. If Debian has thread-safe X libs (as you say, and as I thought), then the problem needs some deeper debugging. If it turns out that Red Hat has set up their X differently than Debian, I'll get back to you. Thanks for the quick response. Cheers, - Jim pgp3ZflUtDMZs.pgp Description: PGP signature
Thread safe X libs?
Check out the forwarded message below. I get the same error using Debian unstable. Does this mean that Red Hat has thread-safe X libs and we don't? Cheers, - Jim --- Begin Message --- On Tue, 9 Dec 1997, Sascha Ziemann wrote: > [EMAIL PROTECTED]:/home/szi$ phaser_chess > warning -- no way to trap SIGPIPE. > > ** ERROR **: an x io error occurred > IOT trap/Abort You probably don't have thread-safe X libraries. An easy way to get them is to install RHL 5.0... -- Elliot http://www.redhat.com/ "They don't let my code go into shipping products," Gates said. "They haven't done that for eight years." (at the 1997 PDC) --- End Message --- pgpaJ5myB5NRh.pgp Description: PGP signature
Re: going to package e
Raul Miller <[EMAIL PROTECTED]> writes: > I intend to package the beta enlightenment window manager, imlib, and > the default themes. If anyone wants to do it instead, I'll happily > fall back to kibitz mode -- let me know. Lalo Martins <[EMAIL PROTECTED]> did a package of beta 12, back in August, but he didn't upload it since he was waiting for developer status. I wonder what happened? Did we lose another one? Anyways, his old package is at: ftp://ftp.mandrake.net/pub/enlightenment/debian-deb/ For some reason, there's no source packages. Cheers, - Jim pgpsJbx6HUNhZ.pgp Description: PGP signature
Re: Debian GNU/Linux Logo chosen
> The logo I chose is > > http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/profile/si02.html Good choice. You forgot to give some credit to the artist (Simon?) though. Do you think SPI should trademark it? What sort of licensing do you think would be best? What does the original artist think? In order to use the BSD daemon (ie. on product packaging, literature, T-Shirts, etc.) you need express written permission from Marshall Kirk McKusick. http://www.freebsd.org/daemon.html Conversely, the Linux penguin by Larry Ewing was included in the kernel source - so I imagine that means it is covered by the GPL. Actually, Larry grants permission to use/modify it on his web page. http://www.isc.tamu.edu/~lewing/linux/ Cheers, - Jim pgpt0YgkOvQE5.pgp Description: PGP signature
Re: Vision of new installation method using webserver
Sounds slick. It wouldn't be too hard to do. It would be slick to have some more network smarts (like DHCP, and dialup to an ISP) on the boot disks (or some variant thereof). As for configuration via the web - check out the GPL'd Java telnet applet I've got installed on my webserver (http://www.jimpick.com/telnet/) - a simple solution would be to put that on the install disks, along with a small web server and some CGI scripts to do the initial configuration - and bingo, you can configure the machine from any Netscape or Internet Explorer machine than can talk HTTP, FTP, and Telnet to it. (of course, firewalls can be a pain) Cheers, - Jim pgpdEqCFsa6KB.pgp Description: PGP signature
debian-non-US mirrors (was Re: debmake)
> I couldnt help but notice that there are no Canadian or even American > (South or Central) mirrors of debian with the non-us category. Actually, I do have one on my server (in Canada): ftp://ftp.jimpick.com/pub/mirrors/debian-non-US/ Canada doesn't have a NSA-like organization that has to protect it's turf - so the regulations are pretty loose. The only thing not permitted is re-exporting crypto stuff that was illegally exported from the US, AFAIK. Cheers, - Jim pgpn5L0mKxfq1.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> Hi, > > Also, 11M may not be a typical install. I get a far higher number: > __> du -s /usr/doc > 92026 /usr/doc > > Uncompressing this is very likely to annoy me. 11M was for my old 386 box (no X installed) - I'm only using about 200M total on that system. That works out to about 5% of the disk space. The system is quite ancient, but it works great as a Linux machine. If you've 92M of documentation - you probably have a much larger disk - but the % of space dedicated to documentation is probably still around 5%. (My development system has 123M of docs out of a 2GB filesystem - 6.1%) I think you'll find that if we compromise, and store most of the documents in compressed format, except for the HTML documents, your overall disk consumption will not increase by much (as a percentage of the overall disk usage) - maybe the percentage of disk space used for documentation would increase to 7-8% at the most. I'd gladly buy more disk space in order to install more documentation only packages (if they were available). Buying disks to store on-line documentation (even fully uncompressed) is a bargain compared to buying off-line books from Tim O'Reilly and company. Cheers, - Jim pgpxbuMEWh7i2.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> > I just did a "du -s /usr/doc" on my 386DX/33 (8MB RAM, 2-200MB HD) - and > > it only has 11MB of docs installed. So uncompressing those isn't going > > to kill me - I'm sure most other people using old hardware have similar > > usage. > > > > Who objects? > > I do. > text/html/ps usually compress very well. > Uncompressing them will probably take something like 3 to 5 times more. > (The smallest machine on which I have debian has a 80 MB HD) Ok, I did some more testing. /usr/doc (with compressed files): 11.072 MB /usr/doc (totally uncompressed): 25.915 MB I was going to check out what size it would be if I uncompressed all the .html.gz files, but there were none - so it makes no difference. The type of packages that typically will include lots of HTML documentation are packages for developers (like the Java JDK docs) which typically will not be installed on an old 386 or 486 being used as a router or low-volume web/e-mail server. I'd prefer compressing man pages and text files - but not HTML documents. It's a fair compromise - and it doesn't impact the disk space requirement on my fairly typical low-end 386 installation by a single byte. Makes you sort of wonder why everyone is so excited... :-) Cheers, -Jim pgpj3MW1K1qbk.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> I only advocated this as a compromise. I am for #1. And I would go further > and abolish all compression everywhere. Compression should only be done if > its transparent for all apps (e2compr or zlib?). I have seen so many > broken packages because of manpage compression etc etc. The clean solution > would be to stop this once and for all. I'm with you on this. :-) I just did a "du -s /usr/doc" on my 386DX/33 (8MB RAM, 2-200MB HD) - and it only has 11MB of docs installed. So uncompressing those isn't going to kill me - I'm sure most other people using old hardware have similar usage. Who objects? Cheers, - Jim pgpiEuZGm0yLn.pgp Description: PGP signature
Re: Sub-categorizing the /usr/doc directory.
One complication I can think of - dselect and the ftp sites have the concept of "overrides", where Guy can change the section a package is assigned to. This wouldn't be reflected in the /usr/doc directory - of course, this might not really matter. Cheers, - Jim pgpkROZcuIbKB.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> >You can't fix the browsers, because we don't have the source for important > >browsers like netscape. > > You mean the Debian Project caving in and changing its standards because > some non free product cannot be changed? Where is our commitment to free > software? We shouldn't be changing the way browsers work. Most browsers follow the HTTP/1.0 or 1.1 standard - including Netscape - and I don't think it's smart to develop a "debian-specific" HTTP protocol extension -- that's what you are suggesting, in essence. (or maybe you just mean modifying the behaviour on file:/ URL's - I guess there isn't really a defined standard protocol for handling that sort of thing - it's highly browser dependent. We shouldn't be using that feature if it's so undefined - maybe you want to draft an RFC or a W3C standard? ) I really only see two possible outcomes to this debate: 1) Store HTML files uncompressed and don't munge the links - all web browsers will work, no web server required - wasteful of disk space (particularily for large documentation packages, like the Java JDK docs, or info-style "books") - note that these types of documents tend to be monolithic, so they could be put into separate optional documentation packages - the system administrator could use a compressed filesystem like e2compr to conserve disk space 2) Store HTML files compressed and munge the links with a tool like fixhrefgz - Lynx and Netscape work with no web server required (I think) - other web browsers will work, if they use a web server such as boa, or a web server and dwww - currently, at least on my system, not a single documentation package with .html.gz files has had the links fixed so that it works when browsing directly from the filesystem (and I maintain two of those packages, oops - even worse the jdk1.1 docs have compressed and uncompressed files - arrrgh) - it's extra work for the developers, and error prone too - I think Lars was advocating this, and I was too Christoph seems to be advocating: 3) Store HTML files compressed, and don't munge the links - Lynx (and others) might work without a web server if they were modified - Netscape wouldn't work without a web server - other web browsers will work, if they use a web server such as boa, or a web server and dwww I was advocating solution #2 - but after looking at the current state of the documentation - I think I'm going to switch to solution #1 - storing uncompressed HTML files. We're not really talking about a large amount of disk space on the base system, unless the user installs documentation packages such as the Java JDK docs. Plus - hard disks are cheap - I just bought a 5GB drive for $600 CDN. And dwww will probably evolve to make it easy to view the documentation that is installed on a remote system (on the Internet or via an Intranet). Plus, finally, it's the simplest solution. Cheers, - Jim pgpKgSu5NTiUZ.pgp Description: PGP signature
Re: Documentation stuff
Karl wrote: > > Can't apache do that? I think there's a mod-rewrite that will do > > what we need. Though I suppose not everyone runs apache... You tell > > me and we'll both know. I think it's a good idea to have a > > light-weight server that can launch from xinetd. I wrote: > The only way to straighten out the links is to change the contents of > the web page. dwww does this (sort of). I think mod-rewrite only > works on the requested URL, not the URL's in the document. So I > don't think Apache can do this by itself. I just looked at the mod-rewrite web page - it looks like it does rewrite the documents - pretty powerful stuff. Sorry if I misinformed anyone... Cheers, - Jim pgp58VFG49WhH.pgp Description: PGP signature
Re: Documentation stuff
> I really want the glimpse searching that TkMan has, but within the
> XEmacs interface. `dwww' has it, but for some reason it does not find
> as many manual entries as Tkman does for the same search. I wonder
> why? Perhaps a generalized perl script (or pull the tcl out of tkman
> that does it?) could do the search, and spit out the links for XEmacs
> or dwww to parse and display?
I'm changing the way dwww is put together, so any type of searching
can be added. The way searching works right now isn't great. Remember,
dwww is still a work in progress.
> I'm using W3 now, so html isn't that bad an option. I can still have
> almost everything inside the editor interface that way. I really love
> having `webster-www' bound to {f2}, so I can look up a word in a
> really nifty fashion.
Once dwww matures a bit, it would be nice to have an emacs interface
to it (via w3-el). That should be easy to do.
> It occured to me today that it would be good to have an rfc index,
> too. Maybe it would have the 's link through a cgi script
> that would check for a local copy, then go get a remote one if the
> local one's not around? Perhaps it could cache them?
I'm going to build a dwww-dev package which will make it easy to
build indexes for specific packages that work with dwww and it's
upcoming documentation menu. It's going to work just like you say.
> I've got the doc-rfc package installed. `dwww' might call on a
> module for searching that someday, perhaps.
Perhaps sooner than you think. :-)
> Gee, maybe HTML should support alternative URL's? The first try to
> the local copy, if that's not there, then call out to a server on the
> net. There could be style variables in the markup to set
> up the base directories/servers.
We had the exact same discussion on the debian-doc mailing list.
> Jim> 4) HTML documentation, if it exists, should be gzipped. Lynx
> Jim> and Netscape can handle the compressed files, provided that
> Jim> the links are straightened out using a tool like fixhrefgz.
>
> Can't apache do that? I think there's a mod-rewrite that will do
> what we need. Though I suppose not everyone runs apache... You tell
> me and we'll both know. I think it's a good idea to have a
> light-weight server that can launch from xinetd.
The only way to straighten out the links is to change the contents of
the web page. dwww does this (sort of). I think mod-rewrite only
works on the requested URL, not the URL's in the document. So I
don't think Apache can do this by itself.
Anyways, I think using a tool like fixhrefgz to fix the links in the
source document is required if we compress docs, since it's a nice
capability of being able to surf the documents straight off the
hard drive, without using a web server.
As for this lightweight server stuff - I tried all the web servers
when I was testing dwww - and Apache was probably the least resource
intensive and the fastest. Of course, it was the most configurable
too - maybe that's why it's called a "heavyweight".
Cheers,
- Jim
pgpjsk2Ig1HH6.pgp
Description: PGP signature
Re: fixhrefgz - tool for converting anchors to gzipped files
[ I hate to wade into this, but ] > >However, as you surely know, this does not work without web server, since > >the browsers are not looking for "foo.html.gz" if "foo.html" is > >referenced. > > Yes. But if you change the references then the web-serverws will no longer > do on the fly decompression. They will serve the links as .gz which is not > universally supported by web-browsers not under Debians control. For cases where people want to use a web browser that doesn't grok gzip, we could use dwww (I think). > >Thus, we are considering changing the "href's" to "foo.html.gz" and fix > >the browsers, where possible, to uncompress the file on-the-fly. If the > >browser cannot be fixed (for example, if we don't have the source code) we > >could probably offer a simple web server (e.g. boa) to do this > >automatically. > > Please think about this. > > You are proposing that a web-server is supposed to be searching through > the .html code it serves and replace all links referring to .html.gz by > .html links? dwww does this - it's not trivial. This is definitely not the job of a web server. So here's my stand: - let's munch up the links to point to ".html.gz" files. Ugly, I know, and a bit of work, but then we don't need to force people to install a web server. I think it's pretty important that we don't force people to run stuff they don't want. - we should compress html, because lots of people (like me) are using Debian on machines with almost no hard drive. - Lynx and Netscape work with the compressed links (correct me if I'm wrong), and we could use a web server/dwww combination to allow other browsers to work too. - all the documentation isn't going to be HTML anyways - just "book-like" stuff. So what's the big deal anyways. No need to start a flame-war. - the other option would be to leave HTML full uncompressed, which would be easiest Cheers, - Jim pgp18O0coF5QA.pgp Description: PGP signature
Documentation stuff
Hi! Sorry for being absent from most of the conversation, and not getting my latest release of dwww out... - I was working in Vancouver last week, came back, got sick, one of my main modems burnt out (lightning?), I replaced it, upgraded my server, messed up PPP, didn't configure the modem correctly, clients calling me up giving me more work, etc, etc, etc... - so I'm way behind schedule on dwww. Here's my ideas for the documentation stuff: 1) a web server, dwww, etc. should be optional - not a core part of the system. I hope to fix up dwww so that it is much faster, powerful, nice, etc. - but the HTML documentation should be browseable without having all this stuff installed. dwww is meant to integrate the existing documentation formats for convenience, but not replace all of them. 2) All the documentation should be viewable via HTML if dwww is installed - but it shouldn't be necessary to have HTML versions of something that is already in info or man format. If there is an HTML version that looks better, by all means include it (if it's small, put it in the same package, otherwise use a separate package). 3) I'd recommend using something like Debiandoc-SGML for documentation written directly for Debian. But this should be optional. I like it because it will work nicely with dwww (and without), plus it is fairly consistent, and can be converted to multiple formats. We discussed some nice enhancements for it on the debian-doc mailing list which should work quite nicely. Oh yeah, we still need separate /usr/doc//README files, and man pages too... HTML shouldn't be used to replace these. HTML shouldn't be used to replace info files shipped with GNU software either. 4) HTML documentation, if it exists, should be gzipped. Lynx and Netscape can handle the compressed files, provided that the links are straightened out using a tool like fixhrefgz. I was going to stick that tool into a "dwww-dev" package + possibly some other ones. (I've got a few Debian installations on 386's and 486's with less than 150MB of disk total) - I'm going to experiment with straightening out the jdk1.1 documentation... e2compr isn't really an option, in my opinion, since it restricts the portability of the entire system. 5) It would be nice if Diety could install just documentation, or just the binaries, and no documentation. 6) dwww will let us serve documentation directly off of an external site, so it would be nice to have a way of installing the packages with no documentation at all. 7) Cacheing - I'm going to split the cacheing in dwww into a separate package. That way, it should be easy to improve it, not use it, or use something like squid instead. That's it for now... Cheers, - Jim pgpw3ccz7lJlO.pgp Description: PGP signature
Re: Moving away from MD5
Thomas Koenig wrote: > I think we should start moving away from MD5 as our main hash function. > An attractive alternative would be RIPEMD-160. > http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html This is probably a good thing to agree to do, before Klee redesigns dpkg to handle verification and other things (I think he's in California doing contract work right now). One drawback is that it is 3 times as slow - and I assume that the output of the hash function is going to take 25% more bytes to represent it. Is there an equivalent of the md5sum program for it? Sound like a good idea to me, but I'm no expert on crypto. Cheers, - Jim pgpQV4UJ6Zh2Y.pgp Description: PGP signature
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
> I have some computers up running in that challenge and I could easily > contribute there output to the debian group, if we are going to have > one. > > So will we have one, or will we do it each one by himself? It's up to you - nobody's really organized anything. Some people are already running for [EMAIL PROTECTED] It's sort of fun watching the team stats move up the chart if the team is large enough. As I understand it, the Bovine RC5 challenge is just a continuation of the zero.genx.net effort that was discontinued earlier (same clients, different servers). I'll probably release the "rc5-bovine" package with a default for the [EMAIL PROTECTED] team, but that can be easily changed (just like the previous "des-solnet" package). I know that this is against Bruce's wishes - but hey, it's not like we're organizing a mutiny or anything (although Bruce seemed to take it that way last time). :-) Cheers, - Jim pgpPzqjWq0teT.pgp Description: PGP signature
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
> People did complain that we were promoting Debian to the > detriment of Linux. Yes - but remember, some of the people participating in these contests were acting pretty infantile. Instead of focusing on solving the problem, they want their team to be at the top of the list at all costs, including 'spamming' the servers to increase their odds. The people who wrote to you complaining about the fact that there was a [EMAIL PROTECTED] team were just trying to get people to join their team - so they could get some more "nerd glory" or something. I'm surprised that you've taken them so seriously, and that you think they even reflect the sentiments of even a fraction of the Linux community. This is such a small thing -- nobody cares. If you were to take a poll of Linux people about this, they'd overwhelmingly vote for 'go away, I don't care'. BTW, in case you didn't notice - we do compete with the other Linux distributions every day -- for the honour of having our system installed on users computers. But, I do agree that we shouldn't be competing against the wishes of the Linux community at large. In summary: Why the hell do we have to be so damn politically correct? I'm mostly in this for fun. :-) Cheers, - Jim pgp36FYtOOWOR.pgp Description: PGP signature
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
> > I suggest to use [EMAIL PROTECTED] as common identifier for Debian > > friends. In case we get the money (why should we ?) I suggest to pass > > 50% to Linux International and keep 50% for Debian. > > Please use an address at Linux International, not one in the Debian > domain. It is not our policy to compete with other Linux distributions. > If we are to join this challenge, it should be for all Linux, not for > Debian alone. > > > Thanks > > Bruce That's silly, Bruce... I get the impression that you've been hoodwinked into thinking there is an "official Linux team" - there ain't - there's a linuxnet.org team, organized by those IRC guys. The odds of winning any of these contests (even with a strong team) is something like 1 in 10,000 - so the objective isn't to win - it's just to compete. Your argument is sort of like saying we shouldn't buy a lottery ticket and write "Debian" on it, because someone else bought a lottery ticket and wrote "Linux" on it - and they might be offended if we won. Having teams makes it a bit more fun. Having 1 team (ie. a Linux team) sort of kills the competition aspect of it all. So I'm still in favour of using the [EMAIL PROTECTED] address, even though that address is just an auto-responder. Once I get my experimental dwww release out (hopefully tomorrow), I'll package up an "rc5-bovine" package to replace the "des-solnet" package. Cheers, - Jim pgpj8KA8GlAA8.pgp Description: PGP signature
Gone for a week
I'm going to be away from my computer for approximately a week, while I travel to Vancouver and Nanaimo (B.C., Canada) on business. I probably won't be able to fetch my mail. Unfortunately, I slipped behind schedule for a few things - so I won't be uploading the "experimental" version of dwww today, as I promised. Also, I haven't had time to do the Debian 1.3 Release FAQ - does anyone else want to take that over? If not, I'll pick it up again when I get back next week. Also, if new clients for the des-solnet package come out - please feel free to package them up (so we don't fall out of 1st place). If anybody really, really wants to talk to me - just call my pager number (listed on my home page). Cheers, - Jim pgpzGzi7St7wK.pgp Description: PGP signature
Re: Status of Debian Policy
> > All packages that provide HTML documentation should register these > > documents to the menu system, too. Check out section section 4.1, `Web > > servers and applications' for details. > > Is that as well as registering with dwww? I'm changing the way documents register themselves with dwww (again). Hopefully, I'll get enough accomplished so that I can upload something to experimental today. I wouldn't encourage anybody to register their documents with dwww just yet, since it's all going to change. Hopefully, I'll get past the prototype stage in the next month or so, and there will be a standard supported way of registering documents with dwww. Cheers, - Jim pgpiSxdDQz1vZ.pgp Description: PGP signature
Re: New package notices via bug tracking system.
> Joey Hess <[EMAIL PROTECTED]> writes: > > The real reason I'm replying to this: I wonder what the other developers > > think about bug reports that just say a new version is available (as opposed > > to, a new version is available, and fixes this nasty bug). > I think it's a good idea. I don't always notice when a new version of > one of my packages is released, and the bug system makes a nice > reminder once I've been notified. > > -- > Rob Me too. The "bug" system is sort of a mis-nomer, it's also great for feature requests and notifying that a new version is available. People shouldn't interpret the number of bugs against a package as an indication of its quality -- they could all just be requests for enhancements. Cheers, - Jim pgp3GWMc2QuE0.pgp Description: PGP signature
Re: jdk1.1 - no dynamic Motif linkage package
> Jim, > > why didn't you upload shared Motif library version of jdk1.1-runtime? > I just wonder if there is any reason for that. > > Thanks. > > Alex Y. The jdk1.1-runtime package can be used either way - read the /usr/doc/jdk1.1/README.linux.gz file for details. You can use a shared Motif library with it if you set the DYN_JAVA variable. I haven't tested that, since I don't own Motif. Cheers, - Jim pgpHVdvHhHvko.pgp Description: PGP signature
Re: Postgres95/PostgreSQL
John Goerzen wrote: > Back in March, Siggy had indicated that he would be taking over > PostgreSQL development (the Postgres95 package currently in Debian is > now very out-of-date). I e-mailed him about this and got no response. Back on May 7, Siggy posted the following: > Hi all, > > after losing almost everything (including backup tapes) in a house fire > on April 2, I finally I find the time to read my email on a friend's > machine. With a backlog of more than 7000 messages I can answer only > to the most urgent ones. > > As things are going, I will need another 2 weeks before being able to > work on Debian again - too late for the release I assume. > > If there are urgent changes pending, will anybody kindly upload a > non-maintainer release for the following packages: > > postgres95 > mgetty > hwtools > linux86 > > Thanks > Siggy So it looks like he's probably still recovering his system > So...is anybody out there planning to take over PostgreSQL? If not, I > can take a look at it. If it will require a tremendous amount of > time, I probably won't be able to do it; otherwise, I can give it a > try. That would be great. I really need it here too. I even sent an e-mail message to Emanuele Pucciarelli (who's listed as the previous maintainer) saying I'd be willing to take it over. Of course, I'd rather not do that, since it's a pretty large package, and would take quite a bit of effort. PostgreSQL 6.1 should be coming out in a few days. It looks good. :-) Cheers, - Jim pgpQ0GwzNIGNm.pgp Description: PGP signature
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> Regarding the assignment of copyright, I took that out of the draft > document. Yay! I knew you were a good guy! :-) Cheers, - Jim pgptBXGtMKzg2.pgp Description: PGP signature
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> Well, it's fine for the author to _require_ that modifications in the > program be returned to the author. It's just not acceptable for the > author to not allow modifications to be distributed. I don't think we should accept licenses that require modifications to be returned to the author, or require assigning the copyright for modifications to the license holder. That's my (strong) opinion. There needs to be more debate. Cheers, - Jim pgpkkuccPIOcW.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
> On Jun 2, Jim Pick wrote > > Just so you understand why I'm so interested - I'm working on porting dpkg > > to cygwin32. > > Porting or re-implementing? If it's a port, dpkg is already under > gpl, so cygwin32 being under gpl shouldn't be an issue. [Even if > it wasn't, I don't understand how a gpl'd dll could be considered > a problem.] That's true. I was just thinking about all the packages that use it. It's worth doing, even if Cygnus doesn't want to LGPL their license. At least we could port the 1000+ packages in the main distribution. The non-free stuff would be questionable. Let's kill this thread - I made my point - ie. "just 'cause it's GPL'd doesn't automatically make it as 'free' as humanly possible". When I actually get dpkg to work, we can start up a new mailing list, and continue the discussion there. Cheers, - Jim pgpClFc3F4Yxq.pgp Description: PGP signature
