I don't like to ask for help. I'm lazy and stubborn... or worse: harleytherapy.co.uk/counsellin…

1) I have the jobbot chroot set up. Outside the chroot is a mix of joborun and artix which I'm really embarrassed about. Nextcloud seems to need ipv6. Is there a good solution to this?

2) I don't need to more than update-jobo-repos, right? I don't need to replace the chroot with the new jobbot image? BTW, Any post to reddit should be mirrored here. I gave up on reddit when we moved here. The new images post really needs to be here.

3) eudev didn't build at first. Then I saw the error: missing dependency: linux6.6-headers

4) bash didn't build for me. No target specified error or something like that. Tried mkpkg and makepkg

5) Tried to build gcc. After 26 hours I aborted it as it was getting a lot of error messages. Over 4000

Joborun should be submitted to distrowatch. If you guys won't do it, can I?

Never Ask for Help? 9 Real Reasons You Always Go It Alone - Harley Therapy

Never ask for help but slog it out alone? You might tell yourself it's noble, but there is a cost. What psychological reasons drive your over independence?

^{Andrea M. Darcy (Harley Therapy - Psychotherapy & Counselling)}

1 It doesn't matter whether the chroot is in RHEL it will build the same
Artix Arch Manjaro ... no difference, just pid1 is different, all else is the same. Whether openrc syvinit dinit runit s6 manages services doesn't affect anything, the services are the same. What changes is that when logind is called elogind responds through dbus, instead of consolekit2 in obarun. In this respect spark linux with sinit/ssm is more honest, 99% arch just switching init and services through ssm. Artix wants to pretend it is a distro by rebuilding 100% arch pkgs.
At least obarun has a design of difference, no systemd boot, no systemd udev, no systemd logind, and packages built specifically without systemd.

2 No the new image is just updated pkgs so you get the same as running pkg -Suy in chroot, Most of the essential scripts in chroot are included in the jobbot pkgs so if there would be a change you get that replaced as well. /usr/local/bin/**

3 Not that it would make any difference but yes deps was changed to linux-headers PK*D linux6.6-headers but since linux-api-headers is 5.15 eudev is best built with it as well. I passed the change and rebuild it

4 Bash took a long while in this last build and there has always been a test that fails so what to do is after it fails the test
makepkg -e --nocheck
which finishes up fast as it uses everything compiled already and skips the tests
The theory is that test data that succeeded are incorporated in the build while makepkg -f --nocheck will not run tests at all.
There are a few pkgs that work this way, many of them because they assume a dbus system is running and trying to use dbus to complete the test ... so Bleep-bloop ... some fail for more dangerous reasons, so let them fail.

5 grep -i ipv6 /src/pkg/job//PKGBUILD reveals ALL packages where ipv6 is disabled.
For kernel it is a bit more complicated as you have to edit config and switch all the =n into =y
Also in default boot grub.cfg remove the tag that says disable ipv6
Then you have ipv6
The interesting part is running a vm inside joborun of a system that utilizes ipv6 and it gets an ipv6 address, because of use of ipv6 tunnel over ipv4
And that is good enough reason to chop the head of the hydra even knowing that it can still prop up another.

6 I wish you had told me before you erase all the work of the 26hrs .. makepkg -e --nocheck
I don't know why you had tests fail though, did you build in the order of linux-api-headers --- glibc binutils ... gcc The last rebuild we did took nearly 40hrs but no tests failed.
Building without tests builds fine and in a few hours .. but yes, this is the pkg from hell but we can't live without it
Imagine that when it is upgraded to new version and glibc is nearly always upgraded at the same time that whole chain of build tools is built twice
On the last run we went wild, we rebuilt another sequence and most of the pkgs in chroot optimized for our build machine, we gave the pkgrel 001 instead of 01 to separate them. Not a spec of difference in speed that we could observe, little difference if any, so never again.

compile and learn instead of live ...

harleytherapy.co.uk/counsellin…

guilty guilty ... of same diagnosis
Getting lost on a trip and never asking for directions just rely on maps and signs 😀 Yes yes yes!

There is a sense of autonomy and DIY in some of us, we can't escape it, it is part of who we are. Not all characteristics of a personality need to change and receive therapy, shrinks can go ... .. ff... @@ ..

And fuck the easy way and the proven popular way ....
.... like Sid said, I did it MOY WAY!!! (sinatra sid vicious parody)

FUCK IBM .... I didn't say it all day and I was feeling nauseous

Never Ask for Help? 9 Real Reasons You Always Go It Alone - Harley Therapy

Never ask for help but slog it out alone? You might tell yourself it's noble, but there is a cost. What psychological reasons drive your over independence?

^{Andrea M. Darcy (Harley Therapy - Psychotherapy & Counselling)}

I have done it! All that's left of Artix is openrc while I take a break and figure out which init I should be using.

OS: joborun linux x86_64
Host: MS-7721 (6.0)
Kernel: Linux 5.15.184-01
Shell: zsh 5.9
CPU: AMD Athlon(tm) X4 860K Quad Core (4) @ 3.70 GHz
GPU: AMD Radeon HD 5000/6000/7350/8350 Series
Memory: 1.02 GiB / 31.31 GiB (3%)
Disk (/): 494.40 GiB / 928.51 GiB (53%) - btrfs

Some things that I've learned:

1) Some packages need/like to be installed together: pkg -S linux, mkinitcpio, eudev, libeudev, base, kmod or pkg -S cryptsetup gnupg gpgme libassuan libgcrypt libgpg-error pacman rpcbind.

2) ./pacman-static is very helpful. timeshift was essential. pacopts was the cleanup hitter! Of course, pkg -Q identifies joborun packages very easily with the 01, 02.03 extensions. Thank you for that!

3) Nextcloud works well on joborun! I had to disable ipv6 on one nextcloud config file. Dovecot and ningx both needed to have ipv6 disabled and so ipv6.disable=1 is in force. Not surprisingly, nextcloud is much zippier now than before.

4) I learned more about systemd than I ever wanted to. /usr/lib/sysusers.d was the bane of the conversion. Artix versions were esysusers and etmpfiles. systemd tentacles everywhere. Even so, we have deal with opensysusers, opentmpfiles, udev, libudev among other systemd parts. It's exhausting.

pacopts is a good tool when trying to clean up between repository sources, unfortunately it brings in a chain of obarun/skarnet pkgs but in total it is a small load.

pacopts origin jobextra

for example will go through the list of jobextr ( pacman -Sl jobextra) see whether any are installed and check if they are authentic against the jobextra.db or not and offer to replace them with the originals.
so if you have liburing-2.11-1 even though 2.11-01 will not replace it pacopts will pick-it up

also on cache .zst is arch or artix, .xz is obarun .lz is joborun (except for very few old pkgs still on .xz)

Another trick is to see what you have in
pacman -Qo /usr/lib/systemd/system/*

As far as I know none of our pkgs have anything there, so most likely what you find there is another source's pkg which has service files for systemd srored there.

DO ask when you get stuck on anything, discussion here encourages other people to attempt similar things, and that is good because we all learn tricks from one another. It is like libertarian school 😀

DO ask when you get stuck on anything, discussion here encourages other people to attempt similar things, and that is good because we all learn tricks from one another. It is like libertarian school 😀

Will do. Some packages built fine in the jobbot chroot. Some did not. Is there a generic troubleshooting guideline?

I've got the hang of it. Everything is building fine. It"s me, not you. ;)

Building the tool chain now. I should be installing what I build in the jobbot chroot, right?

We used to make notes of when some tests failed to run without tests/check but without feedback from users we stopped being consistent.
What is generic as procedure is:

makepkg
--> some tests fail
makepkg -e --nocheck

there have been instances where a valid gpg signature is not found in the default pacman server, either server is down or not up to date, in this case either search other servers or risk and run --skippgpcheck and especially when recently you have run other sw with the same key and it worked or rebuilt the same .. If it is gnu sw ... they are known to be a mess so don't worry about them .. unfortunately we are on gnu linux. If you are within US borders, maybe CDN as well, you may be oK but outside their turf things (networked gnu servers) tend to be neglected. Arch building servers are US based so whet they see is one thing, what the rest of the world sees is another, when it comes to gnu.
Worst of all is they don't give a shit .. because they are GNU

One problematic exception to building we are investigating is e2fsprogs and its fuse byproduct.
It compiles fine all the way and when it gets to the stage of building documentation it fails to find language modules of the documents it supposedly were built.
The problem was narrowed down to using gettext, and using arch gettext instead, produced those modules. The difference between our gettext and their gettext is using our own minimalist build of emacs (emacs-git) which is more recent than arch but is minalistic not full of plugins and guis, so better ;)
We tebuilt emacs-git in case there was a bug in previous session tested emacs to make sure it works well, then rebuilt gettext 2-3 times, same problem. So for now we let the e2fsprogs go by using arch/gettext and this is the 1st time we have done such a thing in 5 years. All the research we have done on this ends in dead ends and same problem. We can''t find specific documentation for those modules, and the error comes up for 4-5 languages, is it specific to them or the builder quits after the 5th error?

Did you notice the labwc 0.9.0 release?

Re: Did you notice the labwc 0.9.0 release?

I did. I built it and installed it. Anything new?

It is pretty much the same as the last rc
I haven't seen anything worth talking about.
As a major release it is build on wlroots19 and the most notable change was that split colors on title bar 😀

% more /usr/share/doc/labwc/NEWS.md

<br />- Add client `lab-sensible-terminal` and add a `Terminal` entry to the default
  root-menu @johanmalm [#2877]
- Enhance `-v|--version` option by adding feature flags like `+xwayland -rsvg`.
  @Consolatis [#2873]
- Send drm leases to XWayland clients. This requires XWayland >= 21.1.9.
  @Consolatis [#553] [#2873]
- Add `<windowRule iconPriority="client|server">`. @Consolatis @tokyo4j [#2839]
- Support theme colors defined by X11-color-names and '#rgb' syntax @jlindgren90
  [#2686]
- Support basic vertical titlebar gradients and the additional theme options
  listed below. @jlindgren90 [#2686]

Eureka!!

The problem with gettext encountered when building e2fs-progs first then icewm then today on mercurial. Because gettext needs dbus installed to build, and since dbus is always on Arch base not on out building base, and since we opted to build dbus recently with selinux enabled, libselinux must be present when using gettext to build. So we are adding it as a running dependency but make a note of it before -03 comes out if you are building something requiring gettext.

Why is dbus so necessary in building documents for software translated in languages or other texts internationalized ... your guess is as bad as mine ! Freaking snitch crawls everywhere

The cost of breaking things down to elements and not being as sloppy as Arch

Last night I got a -testing batch of upgrades to do but was too late to even start, so saved the list and started today. Before starting I run the script that picks up Arch upgrades again and compared to see what has come up more. Mercurial and curl.
Because everything else was on -testing and mercurial was stable I wondered whether they actually build on a stable environment or on -testing from last night? So yes, when building something that is to bypass testing and be placed straight to stable they build on a stable environment, even though a bunch (curl libxml2) were upgraded on testing.

They say you can't teach an old dog new tricks, this dog keeps learning and there is so much more and so little time left ...