I managed to pry myself away from Anarchy Online tonight to work on GEM. I've been getting somewhat obsessed with this online game which is probably a bad thing ;) Anyway, tonight I did 99% of the code for updating via the GUI interface. This puts the sparemint updater ready for a 0.1 release, and it'll make it functional and ready to switch the dev website to live. Pretty cool.
Maybe my life is boring, but I encountered what I feel to be a major problem. The new sparemint site is designed to be 100% community controlled, perhaps with a web administrator to handle db emergencies and such, but it's designed such that so long as a few people are around, sparemint can progress. Not to say Frank Naumann will disappear at any point in time, but I firmly believe bringing the community into the process will help to germinate a growth in MiNT. Because of this, one of the most complex parts of the website is the package upload section. The way this works is that a user will upload a package to a specific dir on the atari-source.com ftp server. Once they do, they will show up in a directory listing provided for the user when he hits "upload a package". Now just to make sure it picks the right ones, it asks the user to select his packages residing in this folder (rather than guessing). All packages have at least a source and binary rpm. Some packages have multiple binary rpm's. This creates an interesting management issue. Do you allow users to vote for whether or not individual portions of an upload are correct or the entire thing? I chose the entire thing, and as such, when a user uploads for instance curl, curl-devel and curl.src.rpm, the site has to make heads or tails of what the user is providing to it. The source is easy to figure out, but how do you figure out the "primary" binary package. Well that's easy just use "curl" .. the base name. "curl-devel" and "curl-docs" will be "child" packages. Simple enough until today. libungif has two binary packges. libungif-devel and libungif-progs. Do you see the problem? ;) No primary package was selected due to no package having the name "libungif" and hence two primary packages were shown! I decided that what will work best is to simply use the first package in a db return as the "primary" package and make any other packages dependent. The effect that making this kind of decision provides is that when a user logs in and sees packages to approve or disapprove, he will see one approve/disapprove option for "python", and it will show all the child packages "python-devel", "python-libs" etc.
Well today I worked a lot on SUM and during the last few days I've been attempting to get GCC compiled. Now a lot of people have succeeded in "compiling" the gcc 3.3x branch but as far as I know, nobody has produced a working g++ compiler. Now, we can't move on in sparemint without it in my opinion because there's almost certainly a few package in our current repository that are C++ or have C++ in them. In addition, this is a pretty basic foundational package - we can't move on without it.
Thus we're stuck with gcc 2.95.3 right now, and all we could really do is compile a sparemint for -m68020-60, however the gcc 2.95.3 optimizations for this are somewhat minimal I think.
Well, since SQLite3 is now compiled I started building support for it into SUM. Then I started moving some old data storage to sqlite and this started happening at a blinding pace. Before the end of the night I had client side update resolution and information displays complete. A few more days work is all it will take. Once completed, all that will really be necessary is conflict/dependency resolution but such things are not currently important to sparemint users. (Right now, they use a clever but inherently dumb perl script). This is completely important because once SUM is in a useable state I'll be able to begin the push to replace the sparemint site. Once that is done, we'll be able to build a version of sparemint specifically for gcc3.x and m68020-60. In theory, this should result in a substantial speed boost. In addition, the full recompile will work any statically linked bugs out. I also managed to cross build gcc 3.3.6 today and compile mintlib and freemint with it, which is pretty slick. We're on our way :) The lesson to be learned here is that C, without help from supporting libraries is a rather poor language to program high level applications in. I was spending all my time creating comparison functions, linked list handling, data structures, etc. In fact, it got so bad that I started looking for a way to do dependency resolution on the server via a nicer high level language, PHP. Now I can in what took me weeks before and 50+ lines of code get done with 1 single SQL statement. That's important to pushing it out the door.
Well now that the CVS Server is up, I was able to put in the new updates, which includes the port to Windom 2.x which now allows Gim to be compatible with XaAES and N.AES (for sure). I also realized I was talking to an offline nothingness the other day so I added the type of notifications that Gaim has to make sure that such a thing doesn't happen anymore. I also put in some updates for Sparemint Update Manager which includes Windom 2.x porting as well as some very tiny progress. Now that sqlite is ported to MiNT I expect once I get things setup, progress will be swift.
Today I worked on gnu gettext a bit and decided that we need the latest version of rpm and apt-rpm. With such a thing we would be able to create different sparemint repositories say for the 68060 user who wants the absolute maximum tested optimizations compiled in with gcc 3.3.3. This allows us to still maintain a sparemint archive for gcc 2.95.3 for the users with lesser systems. An interesting idea but will require some work. GTK 2.2.x is coming along but stuck on a bug.