[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] New Freemint CVS Build



Vincent Rivière wrote:
Mark Duckworth wrote:
> Got my autobuilder/uploader fixed up.  New freemint kernel build at:
> http://storage.atari-source.org:8000/atari/cvs_builds/

Wow, that's nice !
So now we can test the latest kernel (all variants !) without having to compile it. Automated builds are definitely the right way to do.

1) I guess you didn't install binutils 2.19.1 on your build box, because there are some garbage bytes at the end of the kernel executables. Do you plan to use them soon ?

I didn't get it installed on my falcon yet.  I'll do that.
2) I see that the FreeMiNT kernel executables contain debug information, so they are very big. Is it by design ?

Yes, it's for developers.  You can strip them.
3) mintlib-cmpsrc : Accurding to your readme, I expected to find the file libc.a inside it (and probably a bunch of .o files). But it is not here. Did something went wrong ?

It broke ;)  I'll work on it
Now some dreams ;-)

1) Automating the rebuild of all SpareMiNT packages in one pass. So when a new version of binutils, GCC, or MiNTLib is out, we can recompile everything with them, and get up-to date binaries with the bugfixes of all libraries. It could be easy, because building a binary RPM from a source RPM is an automated process. I remember you advertised something like this some monthes ago, but it wasn't online...

http://dev.sparemint.org This was my dream and I got very close. This site is dynamically generated PHP based on packages. If you see there are different repositories. It's a way of expanding the flexibility of our currently static world. THe idea was to have 6 different build farm aranym instances (I have 2 now) who will build uploaded src.rpm files. This is all done and working for standard and standard-testing though the build farm daemons are down because people are currently using bf1 and bf2 as sandboxes (David working on pkgsrc, etc). Make an account on dev.sparemint.org there and you can see the most recent build output (which was years ago), but you can see the idea.

The process is:
1. The user wants to contribute to sparemint. They create a spec and build an RPM on their system. After this process pkgname.src.rpm is generated.
2. The user uploads pkgname.src.rpm via the web interface.
3. The system extracts the RPM and gleans package info and adds it to the database. 4. The system submits the src.rpm to the different build farm instances who generate a 68000 version, a version built with gcc4, a version built for 68060, etc. 5. When each instance succeeds the package is then added to %reponame%-testing. 6. Users who subscribe to testing using the sparemint update manager GEM/TOS program will receive the new version and test. 7. Once a package is tested a user (other than the uploader) will vote via the web interface that the package seems to work okay. 8. Once two other users vote the package is moved to the standard repository and normal non-developers will receive the update via sparemint update manager.

Every part of this system is finished but rough... It needs work but it's more or less done. Back when I wrote all this I Didn't have the "polish" skills I do today as a professional software developer. If the interest is there, I'll revisit each one of these things and make them work well.

You can see that based on this system, it wouldn't be much of a stretch to instruct the build farm daemon to rebuild all of sparemint package by package.
2) Automating the build of a ready-to-use bundle, including ARAnyM, EmuTOS, SpareMiNT... So everyday, any end user could get everything and test test the new features without having to do complicated configurations...

Well this is possible but a nightmare nonetheless ;)
Dreams, dreams... but nothing impossible here.