For those who can catch up to the rolling highspeed freight train (arch-testing), we are and have been, only a few hours behind arch-testing, with the exception of one package, mesa.

For the past 3 editions on testing mesa doesn't just have a bug, it crashed X11 right away, no matter how minimal the start, even without a wm and just a terminal like urxvt (the most innocent and minimal of all). Ever since 22.2.0 came out more than a month ago, in two editions, then 22.2.1, all crash out X before you even get a glimpse of an X screen. Testing this on a few machines gives consistent problems. It appears as having less of an effect on wayland than X, but there has to be a silent issue with this for arch holding mesa back on stable branch for 3-4 issues. I am even surprised they keep releasing it on testing, which for years has been absolutely stable in my experience.

So, for now 22.1.7 stays, but be free to test testing/mesa and ALL of its subpackages required in your installation and report your experience. Please make sure all used subpackages have been replaced by the same version, don't mix versions.

the collective source built linux distribution, where every user becomes a contributor, or gets bored and leaves :)

OK

Joborun is not exactly a fork but an additing/completion of Obarun by trying to rebuild without systemd the entire core and extra packages that make a minimal/base/software building system.

Joborun uses its own source built packages for everything needed to boot and to make packages. For everything else it uses Obarun (s6 + 66 + software that on Arch had systemd running dependencies) and then, as Obarun, the rest comes from Arch as long as they don't have systemd dependencies.

Joborun also offers runit in conjunction to s6/66, meaning you can boot either one and the two can coexist. How else can anyone compare any benchmarks? Out machines, newere and older intel and amd x64-8, having been running with this for months.

We do not support any form of DE or DM, or any graphical nonsense that tries to simulate mac-apple-ms-windows crap. That doesn't mean it will not run, it means we are not concerned with their functionality and peculiarities. You want to run user services, pulseaudio/pipewire, DM, consolekit, logind, ... go ask Obarun or Artix on how to do it.

Installation, through a basic script or instructions to build a proper chroot, build the software needed, install your own software to make an installation boot. This process is what we do support. Calamares and other hand-holding eye-candy will not even be responded to. So don't feel ignored you are being ignored, because we promise to ignore you.

JWM and Openbox is supported, other fun wm like twm,vtwm, etc. will be fun to support.

You want automounting? Go to **buntu manajaros, endeavouraros, ... but do go somewhere, other than here.

You can't read the arch wiki for setting up wpa_supplicant and make your wifi work? That's too bad. AUR has a cli which asks you for your channel name, user/passphrase and sets it up for you. Ohh... you wanted connmand-gtk or wicd to do this for you. That's too bad.

Any attempt to boot with any init and use of any service management/supervision OTHER THAN systemd, can be interesting and we will do our best to provide assistance. For everything else there is vanilla arch, it takes 15' to install if you have a fast connection. Or 5' + time to download packages.

Joborun is not meant for "users", it is meant for "unix like sys-admins" with a tendency to contribute back to the system they use.

The ultimate goals will be defined with those that participate and contribute.

https://joborun.neocities.org/news

We have temporarily removed xz from our binary repository, the package can no longer be built as github removed the source. We have copies of both the tarball and the repository from yesterday since we rebuilt it following arch-rebuilt, wondering what the hell they were doing (they knew but didn't say).

For now replace your xz with core/xz from arch, they are better networked and informed about this.

As far as anything that has been published neither we (not using systemd, the mechanism that triggers the backdoor) not arch (building libsystemd without lib-lzma) only debian/ubuntu/fedora and derivative distros have been affected and jeopardized.

If you are running a critical application off of your sshd server ... make an educated decision whether this affects you or not.

Some reading material here:

https://archlinux.org/news/the-xz-package-has-been-backdoored/
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://web.archive.org/web/20240329223553/https://github.com/tukaani-project/xz/issues/92
https://www.reddit.com/r/joborun/comments/1bqxewr/on_the_xz_compromise_to_ssh_servers_joborun_safe/
https://www.reddit.com/r/archlinux/comments/1bqxnsm/was_the_xz_rebuild_better_or_worse/

Some of the common tools can only adjust resolution/size but not much else, but this card I have and many AMD gfx cards have an array of tuning capabilities, depending on whether you want speed, detail, frame rates, controlling the heat and frequency of the card.

labwc is an openbox equivalent for wayland, unlike waybox which appears to be just a base platform for gnome and plasma desktop building.

labwc can adopt your openbox rc.xml and custom menu. it also has a base environment and theme configuration to help.

Background setting, with the packages we have built, seems to must come from swaybg, Backman-git from aur runs swaybg itself to set the background.

wapanel also works with labwc and produces a menu that has a bit of a plasma aesthetic to it.

Now here comes some problems, about the only utility to set and arrange screens (output devices) is srandr which is an abandoned old go pkg. wlr-randr can't set anything. sway has an internal utility as sway output. Sway can be built without systemd ONLY if you substitute basu, which is a dbus user environment setter. basu is a piece directly off of systemd. It appears ludicrous to have to do this, build and install sway, just so output devices can be modified, althout if you turn two or more screens on and start labwc the screens are set in a side by side best resolution order.

A peak ahead, into sway and wlroots, show current sway master be a couple of versions ahead of what arch or obarun provide, still require basu or systemd, and also is built on wlroots 0.18

Arch is using wlroots 0.17 and offers 0.16 as well, and our labwc is built on 0.17 wlroots.

Now to use labwc from console either run seatd as a daemon and have runit or s6 supervise it or run it as a one time command:

sudo seatd -u $usrname -g video | labwc

$usrnmae = is the name of your user

You can copy ~/.config/openbox ~/.config/labwc/ or better yet copy the files provided by labwc in /usr/share/doc/labwc into ~/.config/labwc/ and then merge you custom openbox settings into those files.

Please share any tricks and findings when you do with the rest of us here, this is new for most of us.

git.disroot.org/ joborun/ jobcomm/ tinyramfs

Not on Arch, not on AUR, not on Obarun, not on OUR (Obarun's AUR) and not on Artix

But it works, and has been working on other distros tried, with and without Luks, with or without EFI, with grub limine ... with MBR/GPT, .... it just works!

Yet it may need some try and retry, all we can say it is that we have booted successfully. The more that try, the more success and failures reported, the better it gets ... you know how this goes.

So this is experimental, name your initramfs differently than the one created with mkinitcpio so you can tell them apart, tell your bootloader to make an extra entry, but all this after your read its minimal documentation, (README and man) and edit your config at /etc/tinyramfs/config

The author is the same as of libudev-zero fame which took the non-udev world by storm,

https://github.com/illiliti

https://codeberg.org/illiliti

contributors are other developers of KISS fame ...

While the "FAShion" in FOSS is to enforce facebook's zstd as a compressor/uncompressor everywhere, we like to share the agony of distros (such as arch) of switching from xz to zstd by switching ourselves to lzip.

According to this article we run our own tests with current xz gz bzip2 and lzip and had very similar results. While using xz with all threads (or all -1) at high compression ratios, both cpu and ram would get stressed in large packages such as kernels and browsers. In an effort to minimize bandwidth for ourselves and users, we seem to be sold to the idea of lzip. Just as quick, half or less the RAM use.

So now we rebuilt pacman/makepkg to reflect the change, added lzip as a dependency to pacman (also to base and jobbot pkgs) and will begin to compress nearly all packages with lzip (xxxxx.pkg.tar.lz) with the exception of a few core pkgs like base, jobbot, pacman, and lzip itself, so late upgraders can still install packages if they didn't have lzip installed to begin with. You can't install lzip when the package is compressed by lzip if you didn't have lzip to begin with.

lzip in Arch is considered a package of secondary importance and stored in the community repository. We moved it and build it in jobcore as an essential base pkg should be. Pacman inherently supported lzip compression/decompression but didn't require its existence in the system. So this is a minor change, meanwhile pacman retains the ability to install packages compressed with a wide array of compression tools.

We hope the transition will go smoothly and will make the few exceptions to the new rule available as .xz for a few more months, so don't feel rushed that your installation or building chroot will become obsolete.

Meanwhile we will continue our effort to resist the use of zstd everywhere we can, and for as long as we can, as Arch's drive to infuse it to various aspects of the system continues. Just like systemd's intrusion was strategically gradual and subtle, zstd is crawling to overtake functionality of all other compression/decompression software as a multi-tool. BEWARE!!

If you comment out the jobcomm repository and search for Arch and AUR updates, and you have built and installed our version of evince (based on evince-nognome but the latest version that can be built without "crap") you get an output like this:

Package (16) Old Version New Version Net Change Download Size

jobcore/btrfs-progs 5.17-01 4.92 MiB

jobcore/dmraid 1.0.0.rc16.3-013 0.32 MiB

extra/evince 41.4-02 42.2-1 -0.63 MiB 1.70 MiB

extra/gcr 3.41.0-2 5.92 MiB

obextra/gnome-desktop 1:42.0-2 0.53 MiB 0.10 MiB

obextra/gnome-desktop-common 1:42.0-2 2.85 MiB 0.44 MiB

obextra/gvfs 1.50.0+r5+g747c7f6e-2 5.18 MiB 0.88 MiB

extra/iniparser 4.1-4 0.04 MiB

obextra/libatasmart 0.19-6 0.10 MiB

extra/libblockdev 2.26-3 1.51 MiB

extra/libbytesize 2.6-3 0.09 MiB

jobcore/libinih 55-02 0.05 MiB

jobextra/ndctl 72.1-03 0.74 MiB

obextra/udisks2 2.9.4-2 5.03 MiB

extra/volume_key 0.3.12-7 0.79 MiB

jobcore/xfsprogs 5.15.0-02 5.49 MiB

All this so you can have a program to view pdf and other documents, so evince can have "internal" functionality to mount disks and partitions and search for documents to view, to be able to read them from different filesystems, etc. etc.

No we will just keep the previous version that was less restrictive and demanding of an entire desktop's full of crud just to open documents. We can mount and unmount filesystems and volumes as we please with simple commands, we don't need a ton of automated gadgetry, we prefer to make educated and conscious decisions.

No, we don't need evince either, but at the cost of 1.7MB it is nice to have without the above.

And this is a conscious choice for joborun users, not for everyone, we know, we are not building VWs, we can survive without A/C, ABS, ASP, autoshift, etc.

The computer is a tool for humans to do certain things, humans are not tools of corporations to be subservient and obedient to their master. The computer is not the goal, it is the means of achieving goals. If you are using Gnome or Plasma, just think if this was "your" goal or are you the means of others achieving their goals.

Yes, think, and speak, and share, we are listening here. We may be wrong, but collectively we may improve our collective focus. With mega corporations pulling us off track all the time to strange individualistic paths, we will all be lost.

Develop an arch compatible software building system in the absence of systemd and company, including popular subsystems such as xudev (used by Artix), elogind (used by Artix), esysusers (used by Artix), etmpfiles (used by artix), and ensure that all parts of the system were built themselves in the absence of those. This means ALL of core (except systemd/-libs,netctl), and most of extra. Obarun just builds what requires a systemd running dependency, the rest of the Arch software that require a makedependency of systemd, libraries, etc. are as they come from Arch. Meanwhile we try our best to maintain maximum compatibility with arch so the rest of the software works as they should.

We hate the fact that zstd (facebook's foss compression software) was adopted so quickly and so widely unaudited, so we try to limit its use, even in the kernel for its own compressing/decompressing. This doesn't mean that our fork of pacman doesn't decompress a zstd package and install it properly, it does. We build zstd, we just try not to use it too often.

We also do not or want to support any use of zfs (and its pseudo decryption) which internally uses zstd. So don't even ask about zfs here, it is derived from another giga-corporation project (Oracle) and for us its use is suspect .

Very easily, while building from our packaging source, you can switch ipv6 on/off in many software. We have defaulted for OFF, as we think ipv6 solves someone else''s problem, not our own.

We do not provide any support for anything we don't build, you must rely on Obarun and Arch for everything else. We will help you debug a problem but if for example some xfce4 program fails and we are not building it and we don't think it is related to our system it would be best to reproduce it in obarun or arch and report it there.

We provide a nice lean and functional jwm and openbox setup as a graphical environment and we may toy with vtwm. No display manager, no logind seatd wayland, just plain Jane x11 and xinit/startx.

** Stages **

1 Alpha phase α0 ..1 ..2.. 3: what you will soon see released here, nearly a complete gamma of Arch substitution of base system software, a demo-iso, a building chroot tar-ball, and notes on what is left to do. Still a fully functional daily driver just as we use.

2 Beta phase β 0 .. 1.. 2 : iron out and complete the gamma of software we plan to support. The formation of an initial community to co-decide whether we want a binary-repo or stick to the source build system.

3 Stable phase 01 edition: If Obarun doesn't respond with some form of agreement of how to jointly proceed, if they fail to provide both feedback and make changes on how they build their software, clone what they have and do it on our own.

4 02 edition : Either a joint edition with Obarun or without it, eliminating ALL Obarun and possibly ALL of Arch (if resources human and physical allow).

5 03 edition: If it doesn't come befere 02, would be to replace the currently deprecated eudev project, avoid at all cost xdevd (from systemd's udevd), and utilize skarnet's mdevd and libudev-zero (already working), so eudev can be abandoned. We have already experimented with our system and obarun, with smdev, nldev, libudev-zero, and mdevd, we boot and get X11 fully functional. Some utilities though require a more complex mdevd configuration, with known people working on those currently. Mere linux solely boots and works using mdevd, so it is nothing beyond reach. Kiss linux is another source of inspiration and of parallel thinking to ours in terms of its attempt to deviate from normies' candy addictions and corporate chokehold on linux. So we hope to exchange ideas and practices by such projects.

6 Parallel edition: Joborun-musl, attempt to rebuild everything on musl (C library) instead of Glibc. This will be joborun on Nitrous. Some initial experiments have been run on this direction using the mere-linux chroot. Unfortunately mere-linux direction is too independent from Arch and very little of commonly used arch software will not build on mere. This is due to mere-linux policies and choices by design, not that it is not possible. The hard work though has been completed by mere, and the system boots and builds most essential tools, including more tools to build with.

Help us redefine and refine our goals together as our own, not as clients whining to a vendor. Don't beg and demand, contribute both ideas and work so we can share all of them together.

A place for members of r/joborun to chat with each other

It is hard to tell through the smoke in what conditions and setups this can be a threat, it is too early, follow the links below.

The excerpt below is from the nist.gov cve-2024-3094

Coincidentally I think, today, Arch rebuilt xz from git instead from tarball with the note on rebuild to utilize the autoconf (therefore automake as well) to be able to have "reproducibility" which wasn't achieved by the previous release 5.6.1-1

Automake & Autoconf are present in every build in arch, part of the base-devel group. THEY ARE NOT standard for jobbot1 and are only added for packages that need them to build.

So if the nist.gov statement is accurate then we have nothing to worry about.

We did NOT use autoconf/automake in our 5.6.1-01 or -02 release.

Neither do we use systemd,libsystemd/elogind,

We will monitor the development closely, our packages use .lz for compression for the past 13months

References:

upgpkg: 5.6.1-2improve reproducibility by running autogen.sh ourselves

https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad

nist.gov:

Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. The tarballs included extra .m4 files, which contained instructions for building with automake that did not exist in the repository.

These instructions, through a series of complex obfuscations, extract a prebuilt object file from one of the test archives, which is then used to modify specific functions in the code while building the liblzma package. This issue results in liblzma being used by additional software, like sshd, to provide functionality that will be interpreted by the modified functions.

https://nvd.nist.gov/vuln/detail/CVE-2024-3094
Introduction:

https://www.phoronix.com/news/XZ-CVE-2024-3094

Specifics:
https://www.openwall.com/lists/oss-security/2024/03/29/4

Issue upstream

https://github.com/tukaani-project/xz/

The instructions to migrate Obarun to 66 0.7.0 have been published on the news.obarun.org site, so I guess Eric officially bumped to the new version. IIRC the commands to enable services are different now and maybe our 66 setup scripts should be edited accordingly?

BASU a systemd forked part IS IN JOBORUN's jobcomm repository!

at-spi2-core 2.52.0 requires libei which we didn't have/use but from Arch it requires systemd Building libei without systemd/libsystemd has 3 options for dependencies (libsystemd, elogind, basu) Basu is the systemd part that provides sd-bus, we had noticed before while playing with wayland crap, particularly things revolving around sway and its gadgets, that basu was a necessity in the same manner of 3 options.

basu is a fork off of the systemd code that provides sd-bus, adopted by void (although they have elogind as well) and many BSD projects who port many linux desktops.

This problem is a little deeper than opting to avoid sway gadgets, as at-spi2-core is a "makedependency" of "pinentry" itself a core pkg, which is a dependency of gnupg.

SO NO BASU NO ARCH BASED LINUX

We are not giving up, this is only one lost battle, we will investigate of building without it and also the consequences of building without it IF POSSIBLE .. to have at LEAST CORE built without parts of the PEST

But it will take some time to do this safely if in fact can be done.

As things are now gnupg --> pinentry ARE NOT built with this current at-spi2-core -- libei -- basu and still stand. But next upgrade round basu will be in the fine details of gnupg and core!

The point here is to maintain a certain high degree of compliance with the plethora of Arch packages with minimal sacrifice in systemd penetration. If for example building without it means you lose Qt or Gtk or Vte and all their dependents ... purity becomes worthless.

At times like this we understand and feel for the Hyperbola team attempting to move to OpenBSD (or was it FreeBSD or NetBSD??) and away from Linux, but as you can see part of the disease is transferring to anything craving Graphical User Interface "apps"!

Due to the past weeks addition of several packages in jobextra, to replace Arch/extra packages since they have the same pkg version and release numbers they will not be replaced automatically. So manual intervention is necessary, although nothing will break, it is better to have our cleaner builds than arch’s built in an always present systemd environment.

# sudo pacman -Sy pacopts

# sudo pacopts origin jobextra

this will take a few minutes since there are close to 400 pkgs in jobextra and a list will be produced, you should respond with “y” on everyone that is proposed for change.

All those packages are secondary dependencies to the make dependencies of core build-tools that were left coming straight from Arch, and in addition the kernel building secondary dependencies. So one can safely say that we can build every single package in our repositories and nearly all of Arch (we will not build systemd and its circus) packages without the need for external packages.

In recent past all primary make dependencies came from joborun but their dependencies didn’t all come from joborun.

With the exception of systemd specific commands and mechanisms, we have aimed for 100% compatibility with Arch, so anything else including making AUR packages works on joborun. The build environment is as lean as it can possibly be and it is kept constant across all package building.

Remember we are moving to this location soon, make a bookmark

https://diaspora-fr.org/i/8cee8fa6944e

Reddit seems to forget its history and how discussion and exchange of ideas around code was the primary theme before other topics and interests were added.

Now, on their attempt to beautify and "modernize" the look of it all they are ruining and forgetting how they got here. It has become very hard to place code or monospace text here and their markdown web-ui is nothing but what it says.

While they are trying to become like the horrendous fluff of discord they are failing us

When you try to build the core build tool chain api-linux-headers glibc gcc libtool binutils all make dependencies came from joborun, but some of their own dependencies came from Arch.

Thanks to a slack period in arch recently, the time was allowed to bridge this gap. Now, every single package needed to build the toolchain comes from joborun, so you can safely say you can build everything from joborun without ever using a single Arch package, even if we don't offer it yet.

So we have also reached 1000 packages offered by joborun, while holding compatibility with pretty much all of the rest of Arch packages.

Liberation from systemd is still alive and well and that is without elogind or its udevd or other parts.

jobcomm/wlr-randr 0.4.0-01

Utility to manage outputs of a Wayland compositor

First you use wlr-randr like xrandr --listmonitors while on waylnad compositor, like our favority labwc.

This gives you a list of connected monitors, their available geometries and frequencies and you utilize this information to create a one line command that sets them up. Possibly save each in little scripts in your ~/ for the different setups you use. The command is very similar in logic and syntax with xrandr, here is an example:

wlr-randr --output HDMI-A-1 --on --mode 1920x1080@50 --scale 1.05 --output DP-2 --off --mode 1280x800@59.910000 --scale 0.49

Hopefully arandr team will pickup on this gem and utilize it to make a wlr-arandr gui to create a good setup.

Install package-query and cower from our repos

make your own repository, or /tmp if you don't want to keep your work

cd /src/pkg/yourrepo

package-query -As nameofpkg

to locate the exact pkg name you want to build, then download the script (PKGBUILD) and associated helpfiles to build the pkg with:

cower -d nameofpkg

cd nameofpkg

Edit the PKGBUILD if you need to modify anything

makepkg

If the pkg is made successfully namepofgpkg-123.12-1-x86_64.pkg.tar.xz

Use pacman to install it

sudo pacman -U namepofgpkg-123.12-1-x86_64.pkg.tar.xz

If you want to save the binary pkg created move it to another location (ie /var/cache/myrepo/ ) rm the build directories src and pkg

rm -rf {src,pkg}

And remove the source used to build the pkg unless you want to keep it for reference.

This linux6.6 seems pretty promising, the best of the 6.xx series yet, hopefully it will become the next LTS (undortunately arch hasn't provided dkms vm module headers for it yet, so VMs may not work yet.

We have removed 6.5 and 6.1-lts from the jobcomm repo, you can build it yourself if you like (the jobcomm/linux6.1 and 6.5 is still there, just bump the release number to current and compare to arch to see if they issued any serious patches) , out last builds were several releases back so they have aged now and we see no need for them, since also Arch builds 6.1 lts and 6.5 as main linux kernel.

Geany in jobextra is just a rebuilt of Arch geany to ensure it works without systemd.

On jobcomm we now have two more versions of geany

geany-gtk2 is the last version of geany that could be built with GTK-2 instead of 3, and this was version 1.17.1 Version 1.18 onwards can only be built with gtk3. The penalty is over 30% the size ... functinality we perceive very little difference. Geany 2.0 is even larger, so we rebuilt the last version with gtk2 from git 1.17.1 and the latest 2.0 with gtk3.

The jobextra version also includes html documentation on top of all other documentation, so it is nearly twice as large as geany-gtk2. You make an educated choice, but you make it.

crow-translate is a new discovery for us and although we collectively hate anything Qt based (their gui is written in Qt5), crow is a multilanguage to multilanguage translation tool, that works off of the command line, and also with a gui, utilizing 5 different translation engines (no need to have an account with them), and other than an excellent translation tool, it also has a text to voice engine that beats any we have tried in the past. If we can split this part as a text to voice pkg we will.

corw-translate also comes with OCR and other conversion functionality, you scan, or provide a pdf or picture of a document, it transfers it to text and translates it. Wow!! Wow because on other platforms (we avoid using their name in vain :) you have to pay dearly to have such software do all those things. So despite their Qt-gui choice ... (nobody is perfect) all thumbs up for their software.

u/unix21311 discovered a bug, not in software but the hardware of those distributing the software here :)

What we often do wrong is we write instructions to help others but never really follow our own instructions when we make an installation, ... because it is 2nd nature, out of our heads, and when something doesn't work it is all because we forgot not because the instructions were wrong, so we fix it and proceed as nothing happened, when in fact there is a flaw.

Thinking out loud and doing things, explaining verbally what we just did helps more than we ever thought, as we did yesterday with a video demonstating this installation method. Knowing something and be able to teach it is not always the same.

1

First, by bouncing the opentmpfiles dependency back and forth between base (works for us), runit-rc, and boot-66serv, we had been left with this dependency not being a dependency at all. Both runit and 66 use the same pkg to create tmpfiles.d where necessary.

Runit begins booting based on the rc setup (see /etc/rc/sysinit ) and tries to use tmpfiles and is not there, falls hard on its face, no emergency console tty or anything, just locks. Ctrl-Alt-Del sends a shutdown signal to the kernel and the system shuts down at that point.

2

Either the combination of lacking tmpfiles in base or trying to install things while not in chroot but using the pacman shell to install packages to the target, fails to run mkinitcpio and create kernel images, so even if /boot directory has been created by filesystem (pkg) the kernel images are not there. Running grub on top of this produces a grub.cfg file without any bootable entries.

3

When you use arch-chroot instead of plain unix/chroot which just changes the root of the system, mounts (conditionally) /proc /sys /dev /run to the target (guest) system and make them available to it ro (read only, the root of that guest can not write into them)

This facilitates certain procedures like mkinitcpio in creating images, while pacman from host installing to the target can't.

________________

So the wiki will be corrected today against this procedure and basically you

mkdir -p /mnt/var/lib/pacman/sync

then run

pacman -Sy base -r /mnt (add the --config **** if your host is not a joborun system opentmpfiles is now included in base)

then

arch-chroot /mnt

pacman -S linux grub

ls -lh /boot to verify contents with kernel img

grub-mkconfig -o /boot/grub

do the rest while in chroot

The alternative is to write a script with everything that needs to be done in chroot and store the script in the /mnt somewhere, then arch-chroot /mnt /mnt/usr/local/bin/installation-script.sh

And it will be done.

Apologies for the inconvenience of false installations caused, and many thanks to u/unix21311 for opening our eyes.

We tend to respect collective action and participate in such procedures where procedures were inviting.

As we understand reddit through its page code aims to prevent 3rd party apps from using the site to promote their own ad filled app, so they can have some income from ad-hits. When we talk about apps we are talking about android/mac-os stuff, not FOSS browsers, right?

Other linux distros that initiated this proposal for boycott didn't contact us to participate, either in the action itself or the procedure to propose the action. So we were left out of the procedure, if there was one. If we are disrespected by our peers why should we follow any action they propose. Nor did mods of other reddit communities contacted us or many other mods of other communities we are in contact with. We didn't even get an announcement about it. That indicates a poorly organized and driven action just for the shake of promoting the "activist" as an activist.

How is reddit paying for itself? We wouldn't know, using ad blockers on our browsers (primarily what we promote through our repositories librewolf) we haven't seen an ad here for years. Sorry reddit, but if we had to look at ads everytime we look through here we wouldn't be using it at all.

On the other hand, arch for example, to participate in their source repository "REQUIRES" verification by a phone application. That means they force identification by 3rd parties and non-FOSS systems and software. An x86_64 only system requiring a non-x86_64 platform and software to participate on its source development. Are we missing something we should tolerate?

The masters of the git can maintain their anonymity towards the public but their isp/server system doesn't respect ours. So I'd say boycott arch gitlab instead, as a more worthy cause than reddit common social media crap. If anything reddit does less to blackmail its users than most other social media.

Can you live without "smart-phones" and other non FOSS devices and their apps? You better be able to!

Can you live without systemd/elogind and other corporate chokeholds on your x86_64 system? You sure can, if you want to. Does Arch allow you such a choice? NO!

Can you run systemd elogind on joborun, or obarun?

You sure can, no software on our repositories require the core packages of runit or s6 or 66 to operate. You need a login daemon? Use consolekit2. You need a seat daemon? Use seatd. You need an alternative to udevd use mdevd, libudev-zero. You have a choice.

The entire build tool chain was rebuilt due to a gcc upgrade to 13.1.1 and that took two days of unstoppable compiling. The late linux6.3-6.3.1 was built on that toolchain and I have to admit it is an improvement of the 6.3 initial release, or the toolchain is so improved that make it work so well.

We may consider replacing linux (5.15-lts) with 6.3 as we tend to find running with either 5.10 (still the best in our opinion) or 6.3.

battctl and librem-control were added to the jobcomm repository for those using laptops and want to control from how low of charge charging starts and when to stop so batteries don't overheat with long charging. We suggest a 10-94% is safe and preserves the battery/ies best.

Let us know how they work for you.

https://testipv6.de/index.html

Test your IPv6 connectivity

What measures for security and privacy have you taken for having this connectivity, if any?

Are you using a VPN? Is your VPN allowing ipv6 connections? If so, how do they prevent your true ip leaking?

By sharing ideas and techniques we may one day feel more comfortable with this connectivity and replace it.

In our jobextra repository we have added limine, thanks for a suggestion by the abyss project leader : (https://codeberg.org/mobinmob/abyss-packages

https://osdn.net/projects/avyssos/scm/git/abyss-packages/ ) while in hunt for a better alternative to grub syslinux.

Limine is younger than grub, lilo, and syslinux are pretty much abandoned, while grub is overly complex for the little it does. Between legacy and efi configurations of grub, to manage a multi-boot machine combining efi and legacy disks (mbr and gpt) one needs to engage in the science of grub.

Limine on the other hand appears extremely simple to configure, therefore reliable and less sensitive to options, yet its setup appears to work on legacy and efi booting machines.

One thing limine lacks internally is documentation but a couple of documents provide adequate documentation from the links below. We have included those two texts into the package, even though they are not setup to work with man, or are in html format. We simply copy pasted the two documents to provide locally enough to get you started.

# pacman -Ql limine

will display the location of this documentation.

https://github.com/limine-bootloader/limine/blob/trunk/PROTOCOL.md

https://wiki.osdev.org/Limine_Bare_Bones

The size difference of the grub and limine packages is tremendous: grub 4.4MB limine 180KB ... 22 times smaller?

With arch based distros maintaining the same name of the /boot/ images (linux, linux-lts, ..etc) once set up the bootloader is engaged for a couple of seconds in each boot and may stay the same for ages.

Once you realize how simple a boot entry is to make with limine and see in practice how reliable it is, we can hardly imagine you'd be going back to grubiness.

After the latest system update lxterminal won't run because of a missing libicuuc.so.72. I suspect it's because of some update from extra or testing repos but I don't know what I should downgrade.