Page 2 of 3

Re: RPMint Distribution

Posted: Fri Mar 15, 2019 2:21 am
by b0br
susher wrote:Ah, I see the permissions on the files in the ftp.earth.ox.ac.uk anonymous FTP site had their permissions too strict (due to a security lock-down on all accounts last year). Thanks for pointing this out. Everything's available again now!

Have a look in ftp://ftp.earth.ox.ac.uk/pub/mintos/
Naice, well played (^_^)

Re: RPMint Distribution

Posted: Mon May 06, 2019 7:09 pm
by mikro
susher wrote:Slightly off topic... Here's my original MiNTOS web page. (My TT is alive again.) https://www.earth.ox.ac.uk/~steve/mintos.html
Btw: maybe it will surprise you but your /sbin/init from MiNTOS 1.4.1 from 1995 (!) is still in use! (thanks to SpareMiNT/EasyMiNT distributions). Just recently I did a small research about it: https://sourceforge.net/p/freemint/mail ... e/36657989. Even in our Atari world there isn't many tools which are in use for such a long time. :) (can think of only about other tools from that package - shutdown, reboot, ...)

Re: RPMint Distribution

Posted: Wed May 08, 2019 9:25 pm
by susher
:-)

Re: RPMint Distribution

Posted: Thu May 23, 2019 3:21 am
by piku
Happy days, I now have 2 working Coldfire evaluation boards as well as a working Firebee. My falcon is sadly very unreliable but I have ARAnyM. Time now to spend time developing instead of fixing systems!

Re: RPMint Distribution

Posted: Thu Nov 28, 2019 8:20 pm
by stormy
piku wrote:Happy days, I now have 2 working Coldfire evaluation boards as well as a working Firebee. My falcon is sadly very unreliable but I have ARAnyM. Time now to spend time developing instead of fixing systems!
Did you see this? http://www.atari-forum.com/viewtopic.php?t=37116

I hope this helps your project...

Re: RPMint Distribution

Posted: Sat Nov 30, 2019 4:30 am
by neanderthal
So yeah,any ideas about it?,just thinking about the fact that site show the typical apache start or something ;)

Re: RPMint Distribution

Posted: Mon Dec 23, 2019 3:56 pm
by piku
neanderthal wrote:So yeah,any ideas about it?,just thinking about the fact that site show the typical apache start or something ;)
The road to hell is paved with good intentions.... More vaporware by me. I don't know why I post! I seriously intended to get moving on this and I did but I don't have anything publishable. I have nothing but trouble with keeping hardware going.

Re: RPMint Distribution

Posted: Wed Dec 25, 2019 12:31 pm
by marcello
What about cross compiling ? It would solve the flaky hardware problem :)
Everything I use in ST Mint was crosscompiled, and works fine.

I don't know if it possible to crossbuilds rpms but it's possible for debian packages: https://unix.stackexchange.com/question ... an-package

there is a good overview of compilers here from 2013, I don't think the landscape have changed that much in between:
http://www.atari-forum.com/viewtopic.ph ... 76#p225859

Re: RPMint Distribution

Posted: Sat Apr 18, 2020 12:59 pm
by stormy
piku wrote:Happy days, I now have 2 working Coldfire evaluation boards as well as a working Firebee. My falcon is sadly very unreliable but I have ARAnyM. Time now to spend time developing instead of fixing systems!
Hi Piku, I was wondering if you might consider opening an RPMint discord development channel, as the task you're undertaking is large and you could get more support this way I think? For instance I am part of the sgi.sh Discord community who are creating a new RPM system for Irix and they work very efficiently by having conversations in Discord and then submitting code together to github.

Perhaps you could invite the maintainers and contributors to the mint kernel.

Just an idea!

Re: RPMint Distribution

Posted: Sat Apr 18, 2020 4:43 pm
by piku
I could but to be honest I only get enough time to work on it sporadically. For a long time not at all but now I am working on it again. I've been really held back by the requirements of newer packages. I'm having to learn C programming much better as the kernel and mintlib needs extended to support some newer features. For instance some software needs meson to build instead of make and meson requires a later version of python than we have. Later version of Python requires mintlib features that we don't have. So it's a big job. I'll start uploading packages I've made though. I've taken the time to bugfix coreutils (df didn't work properly) and some other things. Really I probably need to divert and work on the website and autobuild system so that I can start working on a reliable repeatable build system.

Re: RPMint Distribution

Posted: Sat Apr 18, 2020 5:26 pm
by neanderthal
df is fixed?,,nice,sort of use it now and then and noticed the odd drive 'skipping'. So where will these packs be uploaded?

Re: RPMint Distribution

Posted: Sat Apr 18, 2020 5:59 pm
by piku
I will setup something shortly on rpmint.com

Re: RPMint Distribution

Posted: Sat Apr 18, 2020 6:05 pm
by neanderthal
piku wrote:I will setup something shortly on rpmint.com
Perfect :)

Re: RPMint Distribution

Posted: Sun Apr 19, 2020 6:02 am
by ThorstenOtto
piku wrote:For instance some software needs meson to build instead of make and meson requires a later version of python than we have. Later version of Python requires mintlib features that we don't have.
Python 2.7.14 and 3.6.4 are already available at http://tho-otto.de/crossmint.php Not everything works (modules that require shared libraries to be loaded for example), but that is something you can't easily fix.

Re: RPMint Distribution

Posted: Sun Apr 19, 2020 7:07 am
by mikro
ThorstenOtto wrote:Python 2.7.14 and 3.6.4 are already available at http://tho-otto.de/crossmint.php Not everything works (modules that require shared libraries to be loaded for example), but that is something you can't easily fix.
Is there a reason why the shared libraries couldn't be emulated with yours? I have seen done it with libdld (prehistoric) and ldg, so maybe third time's a treat?

Re: RPMint Distribution

Posted: Sun Apr 19, 2020 7:58 am
by ThorstenOtto
The sharedlibs that i made are custom versions of some commonly used ones like zlib and png. But python and (also perl) sometimes wants to load arbitrary, precompiled libraries, which for example contain interface code to some other libraries. That simply cannot be done without real shared library support. Beside that, a lot of those libraries (like glib and gtk) won't be available for atari, anyway.

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 3:07 am
by piku
Oh thanks for the heads up about Python 3.6.4. That definitely helps a lot! Also I setup a discord server.. https://discord.gg/BB9pPfZ

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 3:16 am
by piku
The good news is that I was solving the missing clock_gettime the same way you did. At least that means I wasn't going crazy ;)

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 3:25 am
by piku
ThorstenOtto wrote:The sharedlibs that i made are custom versions of some commonly used ones like zlib and png. But python and (also perl) sometimes wants to load arbitrary, precompiled libraries, which for example contain interface code to some other libraries. That simply cannot be done without real shared library support. Beside that, a lot of those libraries (like glib and gtk) won't be available for atari, anyway.
I see that you've built a lot of unexpected software including later versions of RPM. Do you have an eventual goal for all your work other than posting it on your page? I'd hate to duplicate effort or even compete. If you don't mind I will definitely use your patches to build RPMs and skip the work on my end.

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 6:03 am
by ThorstenOtto
piku wrote: Also I setup a discord server.
Sorry, but i'm not going to support a company who claims to deliver free software, but whose only purpose is to collect private data so they can spam you with advertisements.

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 6:14 am
by ThorstenOtto
I see that you've built a lot of unexpected software including later versions of RPM.
IIRC that was a bit incomplete. The binaries should work, but the default scripts and macros need some tweaking.
Do you have an eventual goal for all your work other than posting it on your page?
Not yet. I once thought about building real RPMs, but never got to it.
If you don't mind I will definitely use your patches to build RPMs.
That's perfectly fine. If you have success with it, i might even consider to remove those packages that are available as RPM, and support that instead.

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 12:57 pm
by piku
Thanks, also I kind of prefer IRC as well now that I've gotten my feet wet with discord. Why bother with discord and then have no native client that can connect to it. Not sure why I didn't think of that. I'm going to say #rpmint on freenode will be the official place.

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 4:15 pm
by stormy
FYI you guys might not be aware but there is an excellent open source discord client called 'Ripcord', actively developed. Its interface is minimalistic and similar to a nice IRC client, I personally would not use discord if it was not for this client:

https://cancel.fm/ripcord/

The main advantage to using Discord over IRC (even tho I am a firm IRC believer) is that it is difficult to attract new and helpful developers to projects on IRC, where as on Discord it is a lot more accessible to people. Just from my experience in the SGI developer channels, which has both Discord and a bridged IRC, 99% of users are solely in discord, and only about 5 (including me) are in the bridged IRC.

Take from my experience what you will...

Re: RPMint Distribution

Posted: Tue Apr 21, 2020 4:55 pm
by piku
stormy wrote:FYI you guys might not be aware but there is an excellent open source discord client called 'Ripcord', actively developed. Its interface is minimalistic and similar to a nice IRC client, I personally would not use discord if it was not for this client:

https://cancel.fm/ripcord/

The main advantage to using Discord over IRC (even tho I am a firm IRC believer) is that it is difficult to attract new and helpful developers to projects on IRC, where as on Discord it is a lot more accessible to people. Just from my experience in the SGI developer channels, which has both Discord and a bridged IRC, 99% of users are solely in discord, and only about 5 (including me) are in the bridged IRC.

Take from my experience what you will...
To be fair I think the number of developers we will attract to this effort is probably in the single digits. I like the idea of using something that has a native client to the platform. Anyway, the discord is there too still and I am still signed into that as well. And actually my preferred way to communicate is a vanilla mailing list like freemint and emutos have.

Re: RPMint Distribution

Posted: Wed Apr 22, 2020 4:37 pm
by paulwratt
Thanks Piku for starting this project, I too have been looking at something similar (many times) in the past, and I am building RPi server to do it now (saving for 10-12Tb sata => usb drive atm), my eventual solution will be RPi cross-build farm (16+) and public interface to upload random build projects, including .deb's & .rpm

Recap of thread (alot of this info came from AFROS-update work from 2009+):

init, bash & sh
to speed up `init` (and anything that uses `bash`, like `make`) and reduce failures due to memory limits, a MiNT installation needs to be set up to run with the cut down versions of both 'bash' & 'sh' (no internals, no completion, no history, non-interactive) as default, whereas your desktop link is to `bash.full`, the version that has everything.

this means a very much expanded '/bin', '/sbin', '/usr/bin', '/usr/sbin'. you need to have the file versions of 'test', '[' and 'echo', plus file versions of what is nowadays usually internal to full bash (gnu version of echo). I used CygWin technique in 'mint.cnf' soft linking (sln) '/usr/bin => /bin' '/usr/sbin => /sbin' and on "AFROS-update developers edition" (gone to the wind, sorry) '/sbin => /bin'. This makes '/bin' messy, but you can still use full package build and install without changes, and without full SpareMiNT, EasyMiNT, GentooMiNT. You need extras like sed, cut, tr, ls, cat, xargs, basically anything you can find in `configure` and `Makefile` files.

There is a tiny version of both 'sh' and 'bash' out there, but you can also link/copy (tiny) '/bin/bash => /bin/sh'. if desktop is setup properly to use tiny shells, it will reduce memory consumption alot. If the binaries are built for specifc CPU they will also be faster.

mint.cnf
you can use 'include=another.cnf', and flip between different configs manually or with automation (same goes for 'xaaes.cnf' and 'myaes.ini') For AranyM there is fast network setup on AFROS-LiveCD, and it boots faster with 'Bootstrap=path/to/mintara.prg' instead of using "C:\AUTO\MINT040.PRG", plus it can have arguments and C: does not have to be boot drive.

Code: Select all

;Bootstrap = mintara.prg
;BootstrapArgs = DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO
;BootDrive = C
.rpm & RPM
You have found Thotto RPM and later Python. The new version of RPM uses considerbly more memory and itself is much larger. In newer .rpm packages the scripts are not backwards compaible (one reason for his development). For modern packages I was going to just strip them back to be compatible with the older version of RPM (pre-Fedora). With AranyM either solution works, but I wanted a practical solution for real hardware where memory is scarce, to build for 4Mb ST/e as well, or 14Mb 68000 emu at full (host) speed.

There are still some old Sun RPM mirrors on the net (I lost all mine plus links, 250Gb), but the last one I found by accident with ftpsearch, while looking for a version of GiMP from 1993-1995, note that would include GTK2. Anything from this era will compile with minimal effort. If you can find a list of (path) differences between Redhat and Debian from that time (or the RPM converter script - `alien`), then cross-building from .DEB to .RPM is easily done too (even by hand). It is then possible to `backport` newer software to MiNT with older libraries. You can also (but not always) find repos that contain older branches that will compile with minimal effort. I started MiNTed Games (publisher) and Get MiNTed (magazine) for that reason (there are still 3 games on an old x86 PC I have but cant use atm).

IRC & Discord, etc
Use a bridge, should be able to borrow the SGI IRC to Discord bridge if someone asks nicely. Same, I dont like alot of the newer ways of doing things, but I also saw (over time) a lot of older AtariST users who were now coming back as developers, but had forgotten everything AtariST/TOS/MiNT, so I am happy to have modern solutions for them to get started quickly. That was half the point of starting the AFROS-update project and the AFROS Devel livecd version (had all modern developer tools, languages, IDE's, docs, emus, etc).

Build & Cross-builds
I currently have a Developers Edition of BeePi (that also includes an AranyM Safemode Boot option - I broke 'bash' via '/etc/profile'), that (will) include host side cross compilers (hope to get that installed this week). Eventually I hope to have 2 seperate ARM/RPi build farms that can also do m68k (besides i386, armv6, armv7, aarch64 and arm-eabi), one using distcc and one that uses a different method that is faster for smaller projects, but that is some time away (mostly bucks to get the hardware). As soon as I have cross-build installed and working on BeePi, I will then build Buster AranyM with NF-HOST and NF-GL (compiled in and enabled) and do some other useful things with Atari Desktop (like Chromium in Window and YouTube video player). I would also like to provide Desktop widgets (like probhouse does) that allow easy access to new downloads and developer news (FreeMiNT, EmuTOS, MyAES, AHCC, GCC, etc), and one with Atari related forum notification and integration, and another one that is searchable and can tell you the latest version of any program or archive (or a combination of those 3)

Future For Me
Eventually I hope to get some native build tools working on pTOS, which is currently lacking USB, FAT and Keyboard drivers. I believe I can do it already, but without keyboard they are not so useful. Also it is based on 192Kb EmuTOS ROM, and I would like to do a 512Kb ROM version (with languages). I also hope to build newlibc as a ROM extension, to get around shared libraries problem and help with pTOS MiNT build (also build native SLB & LDG), as well as trying to come up with usable solution to allow Fork() to another CPU core from Desktop. I finally have 4x HDMI KVM with RPi B, 2B+, 3B+, 4Gb RPi4B running, but BeePi only works on RPi2 atm (a Buster build will fix that). First up however is 10Tb or 12Tb SATA for Geekworm/Seeed 3.5" SATA RPi2 server (I have 3x RPi2B+). Then work towards 2x 16 RPi4 clusters each with some ClusterCTRL board (adds 3-6 RPi per unit, like ClusterHAT or A+6), but that is a bucks thing so it will take a while. The main fileserver and any clustsers will be publically available on wired connection at fixed location, however I develop all this hardware and software from small 12v mobile home (I post photos when I have RPi, FireBee and AtariST logo on it).

For everyone else, build automation into your AtariST/TOS/MiNT presence on the net. Next time you pay for a domain, buy 10 years (not 12 months). Make it easier for someone to come pick up the pieces and continue later on.

Cheers and thanks for the hard work and persiverance

Paul