https://lxqt-project.org

r53199 already: disable qt5 qtwebengine by default
IMHO we should package all qt variant as individual submodules to improve dependencies, build time:
qtxmlpatterns, qtx11extras, qtwinextras, qtwebview, qtwebsockets, qtwebglplugin, qtwebengine, qtwebchannel, qtwayland, qtvirtualkeyboard, qttranslations, qttools, qtsvg, qtspeech, qtserialport, qtserialbus, qtsensors, qtscxml, qtscript, qtremoteobjects, qtquicktimeline, qtquickcontrols2, qtquickcontrols, qtquick3d, qtpurchasing, qtnetworkauth, qtmultimedia, qtmacextras, qtlottie, qtlocation, qtimageformats, qtgraphicaleffects, qtgamepad, qtdoc, qtdeclarative, qtdatavis3d, qtconnectivity, qtcharts, qtbase, qtandroidextras, qtactiveqt, qt3d

https://download.qt.io/official_releases/qt/5.15/5.15.2/submodules/

When cross-compiling Perl (tested on x86_64 -> hppa, might happen on other archs), the resulting package is much smaller than when native compiling:

bash-5.1# wc -l /var/adm/flists/perl
5684 /var/adm/flists/perl
bash-5.1# wc -l build/hypatia-21-svn-generic-hppa-cross-linux/var/adm/flists/perl 
1703 build/hypatia-21-svn-generic-hppa-cross-linux/var/adm/flists/perl

After examining the flists it's apparent that many modules are missing from the cross-compiled package (maybe a gcc cross compiling problem?), for example Scalar/Util.pm.

The full flists are attached to the issue, along with the cross compilation build log.

cross.flist.log
cross.log.gz
native.flist.log

As there are quite some Emacs fans, it would be cool if we could cross compile it, too. IIRC they usually use their bootstrap Lisp compiler to pre-compile byte code, which would need some cross compile handling.

mine, the T2 package manager, bundles several libraries dating back to the early 2000s (e.g. libtar 1.2.11 or bzip2 1.0.2), many of which have been updated since and might have security vulnerabilities.

I think these should be updated or possibly even removed from the tarball and linked dynamically.

make cross compiled python fully functional, e.g. all modules and building other Python based packages.

E.g. updates, dead Urls, ... https://repology.org/repository/t2/problems

As cmake takes rather long to compile, it would be nice to be able to cross compile it to have it at hand for slower, vintage or retro system to compile smaller packages requiring make.

E.g. via Repology: https://repology.org/projects/?inrepo=t2&vulnerable=1

While booting T2 on Itanium, udevd prints out a warning like this for different modules (the first one is for the SCSI module, but it also happens for Ethernet (e1000) and USB (stack shortened):

T2 SDE early useudevd[45]: starting version 182
rspace (c)2005-2021 Rene Rebe, ExactCODE GmbH; Germany.
Mounting /dev, /proc and /sys
Linux 5.14.6-t2, populating u/dev
------------[ cut here ]------------
WARNING: CPU: 0 PID: 54 at fs/proc/generic.c:406 __proc_create+0x5a0/0x600
name len 0
Modules linked in: scsi_mod(+) usb_common
CPU: 0 PID: 54 Comm: udevd Not tainted 5.14.6-t2 #1
Hardware name: hp server rx2620                   , BIOS 03.17                  
                                          03/31/2005                            

Call Trace:
 [<a000000100015070>] show_stack+0x90/0xc0
                                sp=e000000100bbfab0 bsp=e000000100bb9638
...
 [<a0000002001f8400>] scsi_init_procfs+0x80/0x480 [scsi_mod]
                                sp=e000000100bbfce0 bsp=e000000100bb93e0
 [<a0000002001f8020>] init_scsi+0x20/0x1a0 [scsi_mod]
                                sp=e000000100bbfce0 bsp=e000000100bb93c0
...
 [<a00000010000c860>] ia64_ret_from_syscall+0x0/0x20
                                sp=e000000100bbfe30 bsp=e000000100bb9100
 [<a000000000040720>] ia64_ivt+0xffffffff00040720/0x400
                                sp=e000000100bc0000 bsp=e000000100bb9100
---[ end trace 0a4e30188a2ec52a ]---
------------[ cut here ]------------

There are also some NaT consumption warnings mixed in there:

udevd[48]: NaT consumption 17179869216 [2]

Along with worker terminated messages:

udevd[45]: seq 954 '/devices/pci0000:00/0000:00:01.0' killed
udevd[45]: worker [50] timeout, kill it
udevd[45]: seq 955 '/devices/pci0000:00/0000:00:01.1' killed
udevd[45]: worker [67] timeout, kill it
udevd[45]: seq 961 '/devices/pci0000:20/0000:20:02.0' killed
udevd[45]: worker [49] terminated by signal 9 (Killed)
udevd[45]: worker [50] terminated by signal 9 (Killed)
udevd[45]: worker [67] terminated by signal 9 (Killed)

It's not easy to exactly determine how are those related, since they are printed over each other, but they are clearly regressions of udev, the Linux kernel or both.

Following powerpc et al. sparc* should also default to create bootable ISOs w/ grub2.

Someone (sigh) should package Google's Chrome / Chromium sources. Proof of concept test built a while ago live on YT ;-)

Since a long, long time (15+ years) overwriting the build system hooks for flexible target customization with custmain= is deprecated. Convert the remaining packages to use hooks instead:

grep custmain= package///*.conf

Usually easily like:
makeopt=
makeinstopt=
hook_add inmake 5 "the custmain code"

Like e.g. Committed revision 53416. for rox-filer

https://github.com/ptitSeb/box86

https://github.com/linuxmint/Cinnamon

Package more optional GNOME dependencies.

Thread.3 is used by both perl and tcl:

Found shared files with other packages:
usr/share/man/man3/Thread.3: perl tcl

As the good old cracklib suport was phased out in pam, we should package and update to the new passwdqc and pwquality projects.

using their kernel, drivers and user-land.

Since upstream assimilated udev into systemd (sigh) we should probably peel that outa there and update our standalone udev package somehow :-/

other 32-bit x86 variants work though. IIRC this looks like an inf. loop in libatomic?

Currently we can bootstrap rust, but not yet cross compile rustc itself to a target native rust within the cross stage.

https://ghidra-sre.org/

unfortunately needs Java which we historically often neglected, so this comes together with updating our Java stuff, potentially deleting bitrotting decade old stuff ,-)

For the convenience of the user, we probably should implement cross compiling w/ gobject-introspection and ship the .gir files by default, ...

Replacing the Linux kernel w/ some Net, Open or FreeBSD

Among the nearly 4k packages, we have quite some obscure, exotic, and certainly upstream moved packages. One janitor task would be to systematically go thru (all) of them (a-z?) and update Urls, Downloads, and update to the latest and greatest upstream versions ;-)

Package more optional KDE dependencies

https://nim-lang.org/

When building harfbuzz, gtkdoc-mkhtml tries to call xsltproc from the cross toolchain used to build the package:

ERROR: Error in gtkdoc helper script:
^9-harfbuzz
ERROR: ['/opt/gnome2/bin/gtkdoc-mkhtml', '--path=/home/tglozar/t2-trunk/src.harfbuzz.default.20210908.165904.22086.nietzsche-t2/harfbuzz-2.6.7/docs:/home/tglozar/t2-trunk/src.harfbuzz.default.20210908.165904.22086.nietzsche-t2/harfbuzz-2.6.7/objdir/docs', 'harfbuzz', '../harfbuzz-docs.xml'] failed with status 127
/opt/gnome2/bin/gtkdoc-mkhtml: 95: /srv/t2-trunk/build/x86-64-21.7-generic-x86-64-nocona-cross-linux/TOOLCHAIN/tools.cross/bin/xsltproc: not found

A workaround to this is recompiling the package.

When a package version is overridden by a architecture-specific or target-specific desc (e.g. GCC 7 is used for IA-64 instead of the global GCC 11), the correct version is built, but the binary package name and the mine metadata stays at the global version.

IMHO we should ship.a perf package, as found in the linux kernel sources (sigh) tools/perf. IMHO^2 this should already be a standalone package upstream proper, but it isn't. It might be a good idea to take a look what other gems are hiding in some linux kernel tools/ and other corners, ... ;-)

grub2 halts and catches fire early when run on real i486

Potentially use the vintage cluster, scripts/Create-PkgQueue code and unite it with Build-Target / Emerge to build multiple packages in parallel to speed builds up on modern hardware.

21.5 x86-64 boots install cd just fine but trying 21.7 something in the bootup script ejects the "cd" so you get ls stage2* not found umount /media not a mount point going to hyperv settings and mounting cd again allows the install to find it just fine.

Decades ago we adopted devfs and similar tech early, we probably still have some patches for that, hotplug w/o udev, and other such patches, config and code glue fragments, we probably want to look out for and eventually clean up.

The rather hacky and tricky memtest86+ code does not produce a working binary when build with a gcc / binutils of the last years.

It is widely known that the speculative execution and cache coherency of r10k based O2 cause Linux instability. However, historically archived web looked like it should boot. For a r12k O2 I could not yet get arcload (which surprisingly works ;-) to load and execute the Linux kernel.

http://www.total-knowledge.com/progs/mips/R10K-issue.shtml
https://bukosek.si/hardware/collection/sgi-o2.html (various internal Sgi specs)
http://www.pfrst.de/download.html
http://www.total-knowledge.com/progs/mips/vice/
https://www.linux-mips.org/~glaurung/

Currently a cross compiled glibc is missing all the pre-compiled locales. We should either hack those to generate somehow, or run the most important ones (en_US.UTF-8?) postinstall.d

This has been broken for some time, and it's needed for some math software (namely R and Octave).

as the popular libre / open office suite and also package most of its new internally downloaded dependencies, e.g. those commented in libreoffice.conf's confopt and downloaded in its .desc

as yet another embedde "coreutils", busybox alternative

https://github.com/amaranth-lang (previously https://github.com/nmigen nmigen)

https://github.com/ValveSoftware/Proton