[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.