RPMint Distribution

[mikro]

I'm pretty sure I'm going to come out of this like a jerk but guys, what about instead of competing in graphomania and discussing completely useless things like build farms on underpowered CPUs and discussion forums who will nobody ever visit (it reminds me of another person I personally know, he always starts his projects with creating a forum; it is usually the first and the last step taken in that project) you just basically, you know, do the work and when it is finished then just, you know, announce it.

I for one had a similar idea presented here (auto builds, public repository etc), it took me one week to setup on github&travis&bintray. That means from step zero "automatically create an aranym image with bash and ssh from scratch" to step X "I'm able to build a source package to which I had prepared a minimalistic recipe". Everything works on one press of button, in about 30 KB of scripts and configuration files. No rocket science, simple stuff but yet 100% native compilation, even for FireBee.

I'm not writing this to brag (I still haven't finished the project that's why I haven't announce it anywhere -- got distracted and haven't come back yet) just to remind you that you are wasting your precious time and energy on things which aren't essential to the project (which is itself a nice idea of course).

[Eero Tamminen]

While blue-skying package builds...

I'm wondering whether the use of Debian package format would be more lightweight than RPM. At least that was my impression when Nokia's ARM-based Maemo/MeeGo OS started transitioning from DEBs to RPMs, disk usage went up, and package installation didn't get any faster.

While there's no maintained m68k RPM based distro, m68k Debian is still chugging along fine, and fixing bugs with m68k in large number of packages. Just for this reason, if one is starting from scratch, MiNT distro might be better based on Debian (or on something using Debian as upstream, but converting packages to simpler opkg ones).

Btw. Because of how a lot of the open source is built (Autotools etc), cross-building doesn't really work for amount of SW in Debian (except for the actual compilation step, using distcc). For a long time Debian m68k port used Aranym for building the SW natively under emulation, but the m68k port build machines have apparently moved now to (faster) m68k-qemu to avoid package builds falling too much behind. Unfortunately user-space qemu is an option only for Linux. :-/

[ragnar76]

What about opkg (https://en.wikipedia.org/wiki/Opkg) It's more leightweight as debians dpkg

[mikro]

Yes, OPKG is what I have used. Bintray has direct support for it.

Eero, thanks for the tip, right now I have been using aranym-mmu for ./configure step but m68k-qemu sounds pretty intriguing, too!

[ThorstenOtto]

A bit off-topic, but just a note: the reason why qemu is faster is because it only emulates userland, and thus does have to care about catching bus-errors resulting from I/O memory accesses. As a result, its JIT code generator can be used, since it does not have to emulate an MMU. In Aranym, that is not possible, because linux is emulated in system mode, therefore the MMU emulation is needed, and that cannot be used together with JIT.

[paulwratt]

I am still surpirsed no one have come up with a command lne only build of ARAnyM yet, which by itself (without any gfx/snd/desktop/hw emu etc overhead) would speed up compilation. https://github.com/vivier/qemu-m68k would be ok, but no one (to my knowledge) has ever got EmuTOS or MiNT running on it, so that would have to be done first before it would be 100% usable as a FreeMiNT build option. It is also not upstreamed yet (even though it is around 3 years old now - but there is a build post here: https://wiki.debian.org/M68k/QemuSystemM68k)

Just a reminder that oTOSis related project creators we targeting a .deb based MiNT distro, so there may already be some working tools (if there is a copy of their old ftp server somewhere - mine is gone)

[wongck]

my 2 cents....
keep it as RPM
ppl used that and familiar with that on Mint. Easy to pick and mix what is wanted....
unless there is a big step forward - like a GUI that will auto install, auto update, brainless installations - don't change what has been done.

[stormy]

+++ in support of Wong sifu!

[wongck]

+++ in support of Wong sifu!

Thank you for your kind words.... but no.. no... i am no sifu, just a regular user.

[mikro]

I am still surpirsed no one have come up with a command lne only build of ARAnyM yet, which by itself (without any gfx/snd/desktop/hw emu etc overhead) would speed up compilation.

Because it is not worth the effort. As Aranym is SDL-based, it's totally OK to run it as headless SDL_VIDEODRIVER="dummy" SDL_AUDIODRIVER="dummy" ./aranym-jit booting into a ssh/telnet daemon and you get pretty much what are you asking for. One could perhaps gain a few % by removing Videl + VDI emulation (as now it prints into the 640x480@1bit console which is in turn just a screen which never gets shown) but not much.

[PeterS]

Let's not overlook Alan's gentoo work.

Having only tried to build a few apps and libraries I found the biggest difficulty was dependencies.

[mikro]

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.

Well, Jeff's gempy certainly didn't need more than this: https://github.com/ArmstrongJ/gempy/blo ... oad_mint.c so I have been wondering whether your solution is really that much worse?

[ThorstenOtto]

Thats only a py wrapper for gem functions. It does not call any functions from mintlib.

[paulwratt]

@WongCK: RPM is fine, but most packages require the new RPM version, and there was a problem getting it build on MiNT at sometime in the past, so that either needs to be fixed, and/or, new packages have to be "back ported" to the older RPM that works.

@ragnar76: I have a plan, that may or may not include 'opkg', we will see (thanks for the reminder)

[ragnar76]

@paulwratt please _but_ i've tried to build it using thotto's crosscompiler and i get a lot of errors:

Code: Select all

ragnar@testop:~/src/opkg$ make
make  all-recursive
make[1]: Verzeichnis „/home/ragnar/src/opkg“ wird betreten
Making all in libopkg
make[2]: Verzeichnis „/home/ragnar/src/opkg/libopkg“ wird betreten
  CC       opkg_cmd.lo
In file included from /usr/m68k-atari-mint/sys-root/usr/include/features.h:425,
                 from /usr/m68k-atari-mint/sys-root/usr/include/stdio.h:30,
                 from opkg_cmd.c:23:
/usr/include/x86_64-linux-gnu/sys/cdefs.h:467:49: error: missing binary operator before token "("
  467 | #if __GNUC_PREREQ (4,8) || __glibc_clang_prereq (3,5)
      |                                                 ^
In file included from /usr/m68k-atari-mint/sys-root/usr/include/sys/dirent.h:14,
                 from /usr/m68k-atari-mint/sys-root/usr/include/dirent.h:1,
                 from opkg_cmd.c:24:
/usr/include/x86_64-linux-gnu/bits/dirent.h:19:3: error: #error "Never use <bits/dirent.h> directly; include <dirent.h> instead."
   19 | # error "Never use <bits/dirent.h> directly; include <dirent.h> instead."
      |   ^~~~~
In file included from /usr/m68k-atari-mint/sys-root/usr/include/signal.h:18,
                 from opkg_cmd.c:27:
/usr/m68k-atari-mint/sys-root/usr/include/bits/sigset.h:32:27: error: conflicting types for '__sigset_t'
   32 | typedef unsigned long int __sigset_t;
      |                           ^~~~~~~~~~
In file included from /usr/include/x86_64-linux-gnu/bits/types/sigset_t.h:4,
                 from /usr/include/x86_64-linux-gnu/sys/select.h:33,
                 from /usr/include/x86_64-linux-gnu/sys/types.h:197,
                 from /usr/m68k-atari-mint/sys-root/usr/include/stdio.h:657,
                 from opkg_cmd.c:23:
/usr/include/x86_64-linux-gnu/bits/types/__sigset_t.h:8:3: note: previous declaration of '__sigset_t' was here
    8 | } __sigset_t;
      |   ^~~~~~~~~~
In file included from /usr/m68k-atari-mint/sys-root/usr/include/signal.h:191,
                 from opkg_cmd.c:27:
/usr/include/x86_64-linux-gnu/bits/sigaction.h:33:29: error: unknown type name 'siginfo_t'
   33 |  void (*sa_sigaction) (int, siginfo_t *, void *);
      |                             ^~~~~~~~~
In file included from opkg_cmd.c:27:
/usr/m68k-atari-mint/sys-root/usr/include/signal.h:231:39: error: '__NSIG' undeclared here (not in a function); did you mean 'NSIG'?
  231 | extern const char* const _sys_siglist[__NSIG];
      |                                       ^~~~~~
      |                                       NSIG
opkg_cmd.c: In function 'opkg_update_cmd':
opkg_cmd.c:111:13: warning: implicit declaration of function 'mkdtemp'; did you mean 'mkstemp'? [-Wimplicit-function-declaration]
  111 |     dtemp = mkdtemp(tmp);
      |             ^~~~~~~
      |             mkstemp
opkg_cmd.c:111:11: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  111 |     dtemp = mkdtemp(tmp);
      |           ^
opkg_cmd.c: In function 'opkg_prep_intercepts':
opkg_cmd.c:187:11: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  187 |     dtemp = mkdtemp(ctx->statedir);
      |           ^
Makefile:663: recipe for target 'opkg_cmd.lo' failed
make[2]: *** [opkg_cmd.lo] Error 1
make[2]: Verzeichnis „/home/ragnar/src/opkg/libopkg“ wird verlassen
Makefile:503: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Verzeichnis „/home/ragnar/src/opkg“ wird verlassen
Makefile:391: recipe for target 'all' failed
make: *** [all] Error 2

i'm not a coder but i dont think this will be an easy port

[mikro]

I have built & tested opkg with some minor patches if you are interested.

[ThorstenOtto]

Code: Select all

In file included from /usr/m68k-atari-mint/sys-root/usr/include/features.h:425,
                 from /usr/m68k-atari-mint/sys-root/usr/include/stdio.h:30,
                 from opkg_cmd.c:23:
/usr/include/x86_64-linux-gnu/sys/cdefs.h:467:49: error: missing binary operator before token "("

Looks like your installation is broken: it is using the host systems <sys/cdefs.h> instead of that from mintlib. Did you accidently delete it?

[ragnar76]

@mikro not yet. thanks

@ThorstenOtto well, it works to build bash 5.0.0(1) and a few other tools. maybe i'm missing some includes, libs, ....

[ThorstenOtto]

<sys/cdefs.h> is from mintlib, you should not missing that if you installed it And it is included by <features.h>, which in turn is included by almost all system header files. Since mintlib originally was based on glibc, you may be lucky (or unlucky) that most software compiles even with the hosts version, because they are rather similar, but doing so will call for trouble, and introduce some hard-to-find inconsistencies. You should really fix that.

Edit: you can have a look at http://tho-otto.de/listtar.php?filename ... xz&local=1 for a list of files which are part of mintlib.

[ragnar76]

It's there, perhaps configure did not find it or whatever. maybe i have to add > -I /usr/m68k-atari-mint/sys-root/usr/include < somewhere (or export it somehow) but, as i said before, i'm just a happy - interested - user. i'm not able to do more than ./configure (--host=m68k-atari-mint) ; make ; make install (okay, a bit more i can write "hello world" in c without asking google but thats it )

[ThorstenOtto]

I would be surprised if configure excplictly checks for sys/cdefs.h. That is only an internal header file, common to most glibc based system.

What could be, that somehow an explicit -i/usr/include slipped in. Typically, this can come from different sources:
- from configure itself. Some brain-damaged configure scripts unconditionally add that directory to the list of include directories, even when cross-compiling, and even although that is totally useless since it is a default directory.
- same as above, but specified in some Makefile
- the configure script uses pkg-config to test for existence of packages. In that case, you should set the environment variables PKG_CONFIG_LIBDIR and PKG_CONFIG_PATH to point to /usr/m68k-atari-mint/lib/pkgconfig . This will instruct pkg-config to check those directories only, and thus only use the available mint packages, not the hosts ones.
- from some libtool archive (*.la) file. libtool has the annoying habit of writing absolute paths to its *.la files, and if you have such a file in your hosts default directories, and the corresponding archive for mint it missing, it could be that when checking for the library, those absolute directives are added to the compiler options.

Edit: i think the culprit in this case is the missing gpgme library. This is not yet available for mint.

Edit2: you can still try to build it using --disable-gpg

Edit3: that still gives compilation errors, because mintlib is lacking mkdtemp(). Luckily, that can easily be fixed. I've done that now, and results are available on http://tho-otto.de/crossmint.php (just compiled, i did not attempt to run any tests). Sources were taken from https://git.yoctoproject.org/cgit/cgit.cgi/opkg/; there seems to be at least another version used in https://openwrt.org/docs/guide-user/add ... tware/opkg and i have no idea how different they are.

[paulwratt]

for those who want to try cross compiling with Vincents 'cross-mint' but dont use Ubuntu (yet - like me), I have updated the scripts mentioned on the mint mailing-list:

NOTES:
They are designed for any Debian based distribution.
The will also work on Ubuntu, but this is not the the standard Ubuntu way to install and use PPA's.
Vincents 'cross-mint' Ubuntu PPA's support Focal, Eoan, Bionic, Xenial. Using Xenial on a Jessie (Trusty) installation may work (not tested yet).
The build script contains enough info to be able to build from source by hand for Fedora or Arch (or Void), if you dont already have 'cross-mint-essential' in your distro repo.

cross-mint-ppa-build.sh

Build from source using i386 or amd64 source packages, optionally install all libraries from PPA, as opposed to "build from source".
https://gist.github.com/paulwratt/b4019 ... a34d3d36f1

cross-mint-ppa-arm.sh

Install packages from ARM PPA (armhf=armv7 or arm64=aarch64) , optionally install all libraries from PPA, does not support "build from source" (but works for i386=x86 or amd64=x64 as well).
https://gist.github.com/paulwratt/98de1 ... 3bdb13af37

gist-file.sh

browse and get files by raw_url's from GitHub Gist users, which makes it easier to get or update the above files directly from the command line:

Code: Select all

./gist-file.sh palwratt cross-mint | xargs wget

https://gist.github.com/paulwratt/c8199 ... 77a67d6f13

Cheers

Paul