From: Charles W. <cwi...@us...> - 2009-07-17 21:16:48
|
Keith Marshall wrote: > Sure. A staticly linked bzip2 "bin" package is 36k when packed as > bzip2-*-mingw32-bin.tar.lzma, vs. 112k as bzip2-*-mingw32-bin.tar.gz, > but I was thinking more of a bootstrapping issue -- if you don't have > an lzma decompressor, how do you unpack lzma-*-mingw32-bin.tar.lzma, > so that you can then unpack bzip2-*-mingw32-bin.tar.lzma? Right. Ooops. Yeah, the xz package(s) should probably be packed as a .tar.gz. Thanks. > For the more modern compression formats, gzip may be considered the > most readily accessible format for bootstrapping. Of course, that > still leaves a bootstrap issue for gzip itself, but there seems to > be no shortage of readily available tools to handle that. Ack. -- Chuck |
From: Keith M. <kei...@us...> - 2009-07-17 17:33:14
|
On Tuesday 14 July 2009 01:47:51 Charles Wilson wrote: > > 3) I haven't currently built as a shared library. Obviously it > > is fairly trivial to do so, in which case I will most likely > > adopt the naming convention `libbz2-1.0.5-mingw32-dll-0.tar.gz' > > Sure, with two caveats: > > 1) I think the DLLVER is "1". At least, my linux box has > libbz2.la: # Version information for libbz2. > current=1 > age=0 > revision=0 > so, C-A == 1. But, by what authority does your Linux box assert that current = 1? The upstream bzip2 project doesn't use libtool, (nor indeed *any* of the autotool suite; remember, *I* undertook the autoconfiscation for my own benefit). libbz2.la implies a libtoolization, which doesn't apply for *our* package, because I didn't, (and I don't intend to), libtoolize it. This is the *first* *ever* build of bzip2, explicitly for mingw32. By the rules in the page you linked[*] to the HOWTO, that means that all of current, revision and age should be zero. In any case, I am certainly not prepared to promise compatibility, to the extent of interchangeability, with anyone else's build, (over which we have no control); surely, what matters here is that we maintain consistent evolution of DLLVER numbering for *our* releases, irrespective of what others may do. [*] I have a minor issue with the destination of that link. Had it been to a page on cygwin.com, I probably wouldn't have given it a second thought, but it is to some user's personal home directory, on a host in an unrelated domain. I have grave doubts concerning it's guaranteed longevity; (to say nothing of its inaccessibility from my office, where naive URL filtering seems to block any address which includes a tilde). Perhaps we should seek permission to host a copy of the page, in our own style, on our own site. > 2) if you add a build serial number to the other packages, you > should also add one to the dll package. Of course. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-07-17 21:13:45
Attachments:
bzip2-1.0.5-makefile.patch
bzip2.spec
|
Keith Marshall wrote: > On Tuesday 14 July 2009 01:47:51 Charles Wilson wrote: >>> 3) I haven't currently built as a shared library. Obviously it >>> is fairly trivial to do so, in which case I will most likely >>> adopt the naming convention `libbz2-1.0.5-mingw32-dll-0.tar.gz' >> Sure, with two caveats: >> >> 1) I think the DLLVER is "1". At least, my linux box has >> libbz2.la: # Version information for libbz2. >> current=1 >> age=0 >> revision=0 >> so, C-A == 1. > > But, by what authority does your Linux box assert that current = 1? > The upstream bzip2 project doesn't use libtool, (nor indeed *any* of > the autotool suite; remember, *I* undertook the autoconfiscation for > my own benefit). Huh. You're rightl I didn't think of that. As it happens, the SRPM uses ONLY libtool, not auto*. The (patched) makefile from the SRPM has $(LIB): $(OBJS) libtool --mode=link $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) -rpath $(libdir) \ -version-info 1:0:0 I think it derived from the Makefile-libbz2_so file, which (unpatched) has a SOVERSION of 1: all: $(OBJS) $(CC) -shared -Wl,-soname -Wl,libbz2.so.1.0 -o libbz2.so.1.0.4 $(OBJS) $(CC) $(CFLAGS) -o bzip2-shared bzip2.c libbz2.so.1.0.4 rm -f libbz2.so.1.0 ln -s libbz2.so.1.0.4 libbz2.so.1.0 (Note that it looks like upstream forgot to update Makefile-libbz2_so for patchlevel 1.0.5, but whatever). So, whoever did the libtoolization was just trying to preserve the same SOVERSION that Makefile-libbz2_so had. > libbz2.la implies a libtoolization, which doesn't > apply for *our* package, because I didn't, (and I don't intend to), > libtoolize it. Oh, sure. I wasn't trying to imply that you should. > This is the *first* *ever* build of bzip2, explicitly for mingw32. > By the rules in the page you linked[*] to the HOWTO, that means that > all of current, revision and age should be zero. Well, yeah...but at least on cygwin, when joining an existing, in-progress project, I usually jump in at whatever version they're already using. That way, folks familiar with, e.g. libxml on linux don't get really confused about "why is your version so old" when it really isn't -- they'd just be confused by the win32 DLLNUM not matching the linux SOVERSION. (Now, eventually you might end up breaking that ccrrespondence, if you have to change the win32 ABI for some reason. But then, the win32 DLLNUM would be *ahead* of the linux SOVERSION, so...nobody would worry about the win32 version being "too old".) > In any case, I am > certainly not prepared to promise compatibility, to the extent of > interchangeability, with anyone else's build, (over which we have no > control); surely, what matters here is that we maintain consistent > evolution of DLLVER numbering for *our* releases, irrespective of > what others may do. Yes; absolutely agreed. I guess it's just a small tweak: if you choose to, I don't think it is *wrong* to "jump in" with the initial win32 DLLNUM matching the linux SONAME. (For actual libtoolized projects, you get this for free -- unless you enjoy patching -version-info for no real purpose). BTW, for zlib, the upstream guys are *adamant* http://www.zlib.net/DLL_FAQ.txt that any binary dll named "zlib1.dll" must be binary compatible with the one they distribute; otherwise, "please use a different name". However, I think that a stock build with mingw will satisfy those requirements: * The exported symbols are exclusively defined in the source files "zlib.h" and "zlib.def", found in an official zlib source distribution. * The symbols are exported by name, not by ordinal. * The exported names are undecorated. * The calling convention of functions is "C" (CDECL). * The ZLIB1.DLL binary is linked to MSVCRT.DLL. If you like living dangerously, you can download The archive in which ZLIB1.DLL is bundled contains compiled test programs that must run with a valid build of ZLIB1.DLL. and test your zlib1.dll against those programs. Or we could use a different name. How about libz.dll/libz1.dll/libz-1.dll, to match the normal expectations for library names? > [*] I have a minor issue with the destination of that link. Had it > been to a page on cygwin.com, I probably wouldn't have given it a > second thought, but it is to some user's personal home directory, on > a host in an unrelated domain. I have grave doubts concerning it's > guaranteed longevity; (to say nothing of its inaccessibility from my > office, where naive URL filtering seems to block any address which > includes a tilde). Perhaps we should seek permission to host a copy > of the page, in our own style, on our own site. I'm sure Soren wouldn't mind. I think he still hangs out on the cygwin IRC. Alternatively, we could just point to the appropriate section of the libtool manual http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning But, it doesn't talk specifically about how that affects win32 DLL names, nor does it have Soren's step-by-step examples. However...I think most of the content -- including the examples -- of that page was taken from an email I sent to the libpng list. Original listserv died, so only remaining archive is this: ftp://ftp.simplesystems.org/pub/libpng/png-group/archives/png-implement.200207 Search the page for 'Wilson'. first hit... Soren's page was created (a) as a more permanent home than the (always difficult to find/access) png-implement mailing list archive, (b) and then he edited and pretty-htmled the result. So, I wouldn't feel bad about creating a MediaWiki page using the information from http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning and ftp://ftp.simplesystems.org/pub/libpng/png-group/archives/png-implement.200207 alone... -- Chuck |
From: Charles W. <cwi...@us...> - 2009-07-17 04:40:40
Attachments:
package-contents.tar.bz2
|
Charles Wilson wrote: > I'm gearing up to refresh some of the packages I've created in the past > for mingw and msys, especially the autotools. I've completed my initial (re)build of the -mingw32- packages. I don't anticipate any more prebuilt package sets for the -mingw32- subsystem, except three: zlib: Keith bzip2: Keith libarchive (+ bsdtar): me I'll probably need one more repackage cycle to accommodate any package name or content changes (and most likely, to accommodate the resolution of the "where should the license text go" question), but that's relatively painless. [*] What's painful is uploading 58 different tarballs to sourceforge more than once. So, I'm not gonna do that until I get agreement (or at least, acquiescence) on the whole name-n-content thing. [*] I may also add .RELEASE_NOTES files to the auto* and libtool packages, as I have done for the gettext, libintl, and xz packages. Maybe. So, here's the list of packages. The contents of each are listed in the attached file. AUTOCONF autoconf-6-1-mingw32-bin.tar.lzma autoconf-6-1-mingw32-src.tar.lzma autoconf2.1-2.13-4-mingw32-bin.tar.lzma autoconf2.1-2.13-4-mingw32-doc.tar.lzma autoconf2.1-2.13-4-mingw32-src.tar.lzma autoconf2.5-2.63-1-mingw32-bin.tar.lzma autoconf2.5-2.63-1-mingw32-doc.tar.lzma autoconf2.5-2.63-1-mingw32-src.tar.lzma AUTOMAKE automake-4-1-mingw32-bin.tar.lzma automake-4-1-mingw32-src.tar.lzma automake1.4-1.4p6-1-mingw32-bin.tar.lzma automake1.4-1.4p6-1-mingw32-doc.tar.lzma automake1.4-1.4p6-1-mingw32-src.tar.lzma automake1.5-1.5-1-mingw32-bin.tar.lzma automake1.5-1.5-1-mingw32-doc.tar.lzma automake1.5-1.5-1-mingw32-src.tar.lzma automake1.6-1.6.3-1-mingw32-bin.tar.lzma automake1.6-1.6.3-1-mingw32-doc.tar.lzma automake1.6-1.6.3-1-mingw32-src.tar.lzma automake1.7-1.7.9-1-mingw32-bin.tar.lzma automake1.7-1.7.9-1-mingw32-doc.tar.lzma automake1.7-1.7.9-1-mingw32-src.tar.lzma automake1.8-1.8.5-1-mingw32-bin.tar.lzma automake1.8-1.8.5-1-mingw32-doc.tar.lzma automake1.8-1.8.5-1-mingw32-src.tar.lzma automake1.9-1.9.6-3-mingw32-bin.tar.lzma automake1.9-1.9.6-3-mingw32-doc.tar.lzma automake1.9-1.9.6-3-mingw32-src.tar.lzma automake1.10-1.10.2-1-mingw32-bin.tar.lzma automake1.10-1.10.2-1-mingw32-doc.tar.lzma automake1.10-1.10.2-1-mingw32-src.tar.lzma automake1.11-1.11-1-mingw32-bin.tar.lzma automake1.11-1.11-1-mingw32-doc.tar.lzma automake1.11-1.11-1-mingw32-src.tar.lzma LIBTOOL libtool-2.2.7a-1-mingw32-bin.tar.lzma libtool-2.2.7a-1-mingw32-dev.tar.lzma libtool-2.2.7a-1-mingw32-doc.tar.lzma libtool-2.2.7a-1-mingw32-src.tar.lzma libltdl-2.2.7a-1-mingw32-dll-7.tar.lzma LIBICONV libiconv-1.13.1-1-mingw32-bin.tar.lzma libiconv-1.13.1-1-mingw32-dev.tar.lzma libiconv-1.13.1-1-mingw32-dll-2.tar.lzma libiconv-1.13.1-1-mingw32-doc.tar.lzma libiconv-1.13.1-1-mingw32-src.tar.lzma libcharset-1.13.1-1-mingw32-dll-1.tar.lzma GETTEXT gettext-0.17-1-mingw32-bin.tar.lzma gettext-0.17-1-mingw32-dev.tar.lzma gettext-0.17-1-mingw32-doc.tar.lzma gettext-0.17-1-mingw32-ext.tar.lzma gettext-0.17-1-mingw32-src.tar.lzma libasprintf-0.17-1-mingw32-dll-0.tar.lzma libgettextpo-0.17-1-mingw32-dll-0.tar.lzma libintl-0.17-1-mingw32-dll-8.tar.lzma XZ UTILS xz-20090714git-1-mingw32-bin.tar.lzma xz-20090714git-1-mingw32-doc.tar.lzma xz-20090714git-1-mingw32-src.tar.lzma liblzma-20090714git-1-mingw32-dev.tar.lzma liblzma-20090714git-1-mingw32-dll-1.tar.lzma The XZ utils were built from a clean git checkout created on cygwin. Thus, it had NO autogenerated files; ALL were generated using the autotools in the list above. This includes invoking autopoint to populate/initialize the po/, and intl/ directories. And...it all worked like a charm. So, the "smoke test" for the -mingw32- autotools passed with flying colors. Comments? Criticisms? -- Chuck |
From: Keith M. <kei...@us...> - 2009-07-17 17:33:16
|
On Friday 17 July 2009 05:40:27 Charles Wilson wrote: > I'll probably need one more repackage cycle to accommodate any > package name or content changes (and most likely, to accommodate > the resolution of the "where should the license text go" > question), but that's relatively painless. That seems to be the main (only?) stumbling block remaining... > What's painful is uploading 58 different tarballs to sourceforge > more than once. So, I'm not gonna do that until I get agreement (or > at least, acquiescence) on the whole name-n-content thing. Since we two seem to be the only ones with an opinion on the matter, let's assume that everyone else's silence implies tacit agreement with whatever we decide, and try to nail this. Of the alternatives suggested to date, I favour (with minor reservations as below): > Thou shalt always create a "-license" package that contains > share/doc/<PACKAGE>[-<VERSION>]/[aaaaa], where [aaaaa] represents > one or more files sufficient to convey all of the licensing and > redistribution terms appropriate for the <PACKAGE>-<VERSION> > packageset. The -license package should NOT contain additional, > non-license-related documentation. First reservation is that... > > perhaps we could adopt sh as their Component Type. > > Hmmm. Or "script"? Nah, too long. ... if "script" is too long, then surely "license" is more so. There is also a potential conflict over spelling, depending on which side of the Atlantic one learned English -- British spelling for the noun is "licence". Let's kill the two birds with a single stone, and shorten it to "lic" (reminiscent of VMS licence kits, which bore a .LIC extension, IIRC); thus, for example: foo-1.2.3-1-mingw32-lic.tar.gz Secondly, I'd lean toward: share/doc/<package>/<version>/{file ...} rather than: share/doc/<package>-<version>/{file ...} although I don't see it as a big deal, either way; (there are already precedents for the former style, set by GCC; groff does likewise). I'm also undecided whether the <version> element should be optional or mandatory; mandatory could yield greater consistency. > One thing: the -license package should be a *package* -- e.g. > > foo-1.2.3-1-mingw32-license.tar.gz contains > share/doc/foo-1.2.3/COPYING I agree. > rather than simply a file > > foo-1.2.3-1-mingw32-license.txt whose contents are the same as > the contents of the original COPYING file. I wouldn't even have considered this alternative. Ever. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-07-17 21:29:17
|
Keith Marshall wrote: > Since we two seem to be the only ones with an opinion on the matter, > let's assume that everyone else's silence implies tacit agreement > with whatever we decide, and try to nail this. G. > Of the alternatives > suggested to date, I favour (with minor reservations as below): > > On Friday 17 July 2009 05:40:27 Charles Wilson wrote: >> Thou shalt always create a "-license" package that contains >> share/doc/<PACKAGE>[-<VERSION>]/[aaaaa], where [aaaaa] represents >> one or more files sufficient to convey all of the licensing and >> redistribution terms appropriate for the <PACKAGE>-<VERSION> >> packageset. The -license package should NOT contain additional, >> non-license-related documentation. Ok. > First reservation is that... > >>> perhaps we could adopt sh as their Component Type. >> Hmmm. Or "script"? Nah, too long. ... > > if "script" is too long, then surely "license" is more so. There is > also a potential conflict over spelling, depending on which side of > the Atlantic one learned English -- British spelling for the noun > is "licence". Right. I forgot about that. > Let's kill the two birds with a single stone, and > shorten it to "lic" (reminiscent of VMS licence kits, which bore > a .LIC extension, IIRC); thus, for example: > > foo-1.2.3-1-mingw32-lic.tar.gz Wow. VMS. That takes me back. Should we embed ';1' versions on all our files? -lic is fine by me. > Secondly, I'd lean toward: > > share/doc/<package>/<version>/{file ...} > > rather than: > > share/doc/<package>-<version>/{file ...} > > although I don't see it as a big deal, either way; (there are already > precedents for the former style, set by GCC; groff does likewise). > I'm also undecided whether the <version> element should be optional > or mandatory; mandatory could yield greater consistency. OTOH, automake does share/aclocal-<version>/ share/automake-<version>/ Obviously, THAT can't be changed without a lot of work. But where we put the docs? Meh. I'm already explicitly overriding DOCDIR on all my mingwPORTs anyway, so either way doesn't bother me. You pick. >> One thing: the -license package should be a *package* -- e.g. >> >> foo-1.2.3-1-mingw32-license.tar.gz contains >> share/doc/foo-1.2.3/COPYING > > I agree. > >> rather than simply a file >> >> foo-1.2.3-1-mingw32-license.txt whose contents are the same as >> the contents of the original COPYING file. > > I wouldn't even have considered this alternative. Ever. I occurred to me that somebody might think it useful for clients to be able to click on the "license" file for any package from the FRS and see it in their browser. I wanted to head off that idea before it got any traction. Side note: I just noticed that my xz packages are illegal. $ pkginfo.exe xz-20090714git-1-mingw32-bin.tar.lzma Package Name: xz-20090714git << Oops #1 Package Version: 1 Package Build: <unspecified> Subsystem Name: mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Release Status: <unspecified> Release Reference: <unspecified> Component Type: bin Component Version: <unspecified> Archive Format: tar Compression Type lzma << Oops #2. Can we allow version numbers to be [digit]*[_alnum]*, as well as [digit]*.[digit]*[_alnum] and [digit]*.[digit]*.[digit]*[_alnum], or is that too hard? -- Chuck |
From: Charles W. <cwi...@us...> - 2009-07-22 04:40:05
Attachments:
autoconf-package-lists.tar.bz2
|
I've completed (another) rebuild cycle for the autoconf packages, to satisfy the recent packaging decisions. Each now have an associated -lic package, and the DOCDIR is share/${PKG}/${VER}/. Here's the list of packages: autoconf-6-1-mingw32-bin.tar.lzma autoconf-6-1-mingw32-lic.tar.lzma autoconf-6-1-mingw32-src.tar.lzma autoconf2.1-2.13-4-mingw32-bin.tar.lzma autoconf2.1-2.13-4-mingw32-doc.tar.lzma autoconf2.1-2.13-4-mingw32-lic.tar.lzma autoconf2.1-2.13-4-mingw32-src.tar.lzma autoconf2.5-2.63-1-mingw32-bin.tar.lzma autoconf2.5-2.63-1-mingw32-doc.tar.lzma autoconf2.5-2.63-1-mingw32-lic.tar.lzma autoconf2.5-2.63-1-mingw32-src.tar.lzma And I've attached the list of files in each package. Assuming there are no objections, I'll upload these under the following FRS structure: Package: MinGW autoconf (2.1x series) Release: autoconf2.1-2.13-4 File: ... Package: MinGW autoconf (2.5x series) Release: autoconf2.5-2.63-1 File: ... Package: MinGW autoconf (wrapper) Release: autoconf-6-1 File: ... Next up, the re-re-spin of the automake packages. I'll probably do those in two or three waves. -- Chuck |
From: Keith M. <kei...@us...> - 2009-07-22 16:54:07
|
On Wednesday 22 July 2009 05:39:28 Charles Wilson wrote: > I've completed (another) rebuild cycle for the autoconf packages, > to satisfy the recent packaging decisions. Each now have an > associated -lic package, and the DOCDIR is share/${PKG}/${VER}/. > > Here's the list of packages: > autoconf-6-1-mingw32-bin.tar.lzma > autoconf-6-1-mingw32-lic.tar.lzma > autoconf-6-1-mingw32-src.tar.lzma > > autoconf2.1-2.13-4-mingw32-bin.tar.lzma > autoconf2.1-2.13-4-mingw32-doc.tar.lzma > autoconf2.1-2.13-4-mingw32-lic.tar.lzma > autoconf2.1-2.13-4-mingw32-src.tar.lzma > > autoconf2.5-2.63-1-mingw32-bin.tar.lzma > autoconf2.5-2.63-1-mingw32-doc.tar.lzma > autoconf2.5-2.63-1-mingw32-lic.tar.lzma > autoconf2.5-2.63-1-mingw32-src.tar.lzma Thanks, Chuck. Looks good to me. I might have added an underscore in the package names, as in: autoconf_2.1-2.13... autoconf_2.5-2.63... but there's no technical reason for this; it's purely an aesthetic choice, based on an entirely personal perspective. However, it's your package set, and if you prefer to stick with what you've done already, I'll cheerfully accept your choice. > And I've attached the list of files in each package. Assuming > there are no objections, I'll upload these under the following FRS > structure: > > Package: MinGW autoconf (2.1x series) > Release: autoconf2.1-2.13-4 > File: ... > Package: MinGW autoconf (2.5x series) > Release: autoconf2.5-2.63-1 > File: ... > Package: MinGW autoconf (wrapper) > Release: autoconf-6-1 > File: ... Again I'd have added the underscore, but aside from that, it looks good. Whatever you decide, WRT underscores, be consistent; I'll go along with your choice. > Next up, the re-re-spin of the automake packages. I'll probably do > those in two or three waves. Whatever works best, for you. When you're ready, just keep them consistent with your choices above for autoconf, and go ahead with the upload, in your own time. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-07-23 04:58:49
|
Keith Marshall wrote: > Thanks, Chuck. Looks good to me. I might have added an underscore > in the package names, as in: > > autoconf_2.1-2.13... > autoconf_2.5-2.63... > > but there's no technical reason for this; it's purely an aesthetic > choice, based on an entirely personal perspective. However, it's > your package set, and if you prefer to stick with what you've done > already, I'll cheerfully accept your choice. Yeah, I was just following the pre-existing convention established by, e.g. Debian and cygwin. I'll stick with it, since I maintain the cygwin set too, it makes sense to use (similar) conventions. >> And I've attached the list of files in each package. Assuming >> there are no objections, I'll upload these under the following FRS >> structure: >> >> Package: MinGW autoconf (2.1x series) >> Release: autoconf2.1-2.13-4 >> File: ... >> Package: MinGW autoconf (2.5x series) >> Release: autoconf2.5-2.63-1 >> File: ... >> Package: MinGW autoconf (wrapper) >> Release: autoconf-6-1 >> File: ... > > Again I'd have added the underscore, but aside from that, it looks > good. Whatever you decide, WRT underscores, be consistent; I'll go > along with your choice. Ack. -- Chuck |
From: Charles W. <cwi...@us...> - 2009-07-25 17:29:33
|
Keith Marshall wrote: > On Saturday 25 July 2009 05:12:38 Charles Wilson wrote: >> Also, I'd need to rewrite the section in the Package >> Identification HOWTO that discusses the FRS organization, removing >> all references to the FRS 'Package' and 'Release' jargon. Haven't done this yet. >> Any objections? > > None at all. I just wonder how long this new design will persist, > before SF change their minds yet again, and invalidate whatever you > do today? Yeah. Good question. > BTW, have you looked at the latest user view of the "Files" page? On > my Ubuntu box, Firefox pops up a dialogue box saying: "A script on > this page is making Firefox run slowly; would you like to stop this > unresponsive script?" Of course, stopping it is fatal; the page > just becomes a garbled mess. Yep. > I do wish they would get rid of that "Newest files" garbage, at the > top of the page. It just wastes acres of space, and gets in the way > of the content the users want to see. Although, I am not sure getting rid of the "Newest files" would actually help. The page contents have *all* of the files in *every* sub-sub folder embedded in the html. It's just that after they are all downloaded, the dynamic html hides folder contents from you. I guess this to enable faster response when the user clicks on a folder, to avoid hitting the server for the content list. . . . except it does THAT, too! It's slow, but bearable, under firefox 3.0.1. Are you still using 2.x on Ubuntu? -- Chuck |
From: Keith M. <kei...@us...> - 2009-07-25 18:43:09
|
On Saturday 25 July 2009 18:29:12 Charles Wilson wrote: > It's slow, but bearable, under firefox 3.0.1. Are you still using > 2.x on Ubuntu? Nope. Firefox 3.0.11 on Ubuntu-8.04-LTS. -- Regards, Keith. |