Mikeserv Support Forum

Posted: **Fri Jun 21, 2024 2:26 am**

Look at what this new systemd bollocks does now:

[grogan@nicetry shit]$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4      196G   21G  166G  12% /
devtmpfs       devtmpfs   32G     0   32G   0% /dev
tmpfs          tmpfs      32G  253M   32G   1% /dev/shm
tmpfs          tmpfs      13G  1.4M   13G   1% /run
efivarfs       efivarfs  256K  124K  128K  50% /sys/firmware/efi/efivars
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-udev-load-credentials.service
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev-early.service
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-sysctl.service
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-sysusers.service
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev.service
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-vconsole-setup.service
tmpfs          tmpfs      32G  956K   32G   1% /tmp
/dev/nvme1n1p1 vfat     1022M   20M 1003M   2% /boot
/dev/nvme0n1p1 ext4      1.8T  1.7T  147G  92% /storage3
/dev/nvme1n1p6 ext4      1.3T  378G  794G  33% /storage2
/dev/nvme1n1p5 ext4      295G   84G  197G  30% /storage
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup.service
tmpfs          tmpfs     1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
tmpfs          tmpfs     6.3G   40K  6.3G   1% /run/user/1000

All those tmpfs mounts. How silly.

The second update recently was because it apparently has some tmp file cleaning service, where if the user invoked it without context it would delete their entire home directory (that's fixed now though)

Time to figure out exactly what's enabled in systemd and what's not. This is my system, not some VM lol.

Systemd has grown quite obnoxious and Arch doesn't hold these upgrades back.

Posted: **Mon Jul 22, 2024 5:45 pm**

Linux 6.10 headers and Glibc 2.40 today, in Arch (well, last night for my biology, but it's a job for today). That also means rebuilt gnu toolchain packages. New commits of gcc and binutils. I don't actually think they are in my package mirrors yet (just the linux headers... which is theoretically wrong to do before the rest but likely OK in this case), but the latest PKGBUILDs are updated.

For me that's a big deal, because I compile all of that (and a bit differently than they do). I've been dreading, but waiting for this. I jumped the gun last time and upgraded to gcc 14.1.0 (and bootstrapped all the above) and then the next day Arch did it, but used current commits instead of release tags. They were very current releases and there was no need for me to rebuild all that again just because of what they did, but it's still at least theoretically wrong to not be in sync. (however, it's theoretically wrong from a distro perspective to do what I do anyway... but I mostly know what I'm doing and I know what I don't like)

Posted: **Tue Jul 23, 2024 1:55 am**

LOL... I noticed something offensive in the glibc PKGBUILD (that I immediately commented out). What? They are forcing frame pointers in 32 bit glibc because of Nvidia? The compilers have been omitting them (-fomit-frame-pointer with at least -O1) where unnecessary for a long time, for performance optimization. This isn't a good thing for debugging and profiling etc. but for production code, performance is what should matter. It's the reason I compile my own shit, performance optimization for one thing.

Code: Select all

# remove frame pointer flags due to crashes of nvidia driver on steam starts
    # See https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/issues/10
    CFLAGS=${CFLAGS/-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer/}

Then I got looking at that... wait a minute, with that variable setting syntax it's removing -fno-omit-frame-pointer etc. from the CFLAGS variable. Where the Hell is that coming from in the first place that it needs to be removed? Nowhere for me, how utterly useless, I thought. No wonder I didn't understand (thought the rationale was mixed up) that issue justification in the URL.

Then it occurred to me... Arch made a change, they now force framepointers. I never bothered to look at /etc/makepkg.conf.pacnew because I know how I want my variables and stuff. I wonder how many times that's been overwritten lol

Code: Select all

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection \
        -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"

RUSTFLAGS="-Cforce-frame-pointers=yes"

LLlllLllloook at what they are doing. (... as I make another backup of my makepkg.conf lol)

That's just the relevant parts with respect to the frame pointers but that's a bucket of chum that they optimize packages for security and debugging/profiling. Not on my system they aren't. I was enjoying leaving more packages to the distro, but this has given me incentive to take over even more than before. (it actually takes longer to set up builds than to build most of them now anyway)

Posted: **Tue Jul 23, 2024 4:41 pm**

I thought I'd take a picture of this... it's probably the first time ever that there have been no version discrepancies in any of my packages or any other complaints. Arch has finally caught up to me

Code: Select all

[nicetry ~]# pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
:: Starting full system upgrade...
 there is nothing to do

That probably won't last the day.

Posted: **Mon Jul 29, 2024 9:12 pm**

Fucking Arch... you can't even install (or build, without altering) a package without it wanting a million unnecessary dependencies. First PKGBUILD for xfce, libxfce4util, wants Vala (an intermediate language needed for Gnome integration). I also need intltool (an actual build dep for this) so I install Vala too. Doesn't it pull in a whole bunch of stupid shit like graphvis, netpbm, a bunch of doc building utilities, xml parsers etc. So I just undid everything that was installed

Code: Select all

pacman -R docbook-xml docbook-xsl ghostscript glib2-docs graphviz gtk-doc gts ijs jbig2dec libidn netpbm perl-xml-parser intltool vala

And took Vala out of the build deps so it will build without it. Intltool's only dep is perl-xml-parser (which is something I should have anyway, I'm a bit surprised I haven't run into it yet)

I'm going to end up with a better build of XFCE out of the deal, with fewer dependencies and less fat.

Posted: **Mon Jul 29, 2024 10:47 pm**

So yep, I removed (and uninstalled from the system) unnecessary dependencies from the build, and only did the parts of XFCE that I need. No gnome garbage now. I removed all my xfce packages and built everything in order. I hate Thunar too, so why must I have it? Only because there's a dependency on it in xfdesktop if compiled against Thunar's extension library. My XFCE is now Thunar free, and none of that volume mounting/notifying crap either now. Of course, the packages are compiled my way too, like anything, without Arch's miserable build flags.

exo-4.18.0-2-x86_64.pkg.tar.zst
garcon-4.18.2-1-x86_64.pkg.tar.zst
libxfce4ui-4.18.6-1-x86_64.pkg.tar.zst
libxfce4util-4.18.2-1-x86_64.pkg.tar.zst
xfce4-panel-4.18.6-1-x86_64.pkg.tar.zst
xfce4-pulseaudio-plugin-0.4.8-1-x86_64.pkg.tar.zst
xfce4-session-4.18.4-1-x86_64.pkg.tar.zst
xfce4-settings-4.18.6-1-x86_64.pkg.tar.zst
xfce4-terminal-1.1.3-1-x86_64.pkg.tar.zst
xfconf-4.18.3-1-x86_64.pkg.tar.zst
xfdesktop-4.18.1-2-x86_64.pkg.tar.zst
xfwm4-4.18.0-2-x86_64.pkg.tar.zst
xfwm4-themes-4.10.0-6-any.pkg.tar.zst

I should have done this a long time ago.

Posted: **Tue Jul 30, 2024 8:26 pm**

So here's a funny little mystery that I think I understand now. I'd noticed sometimes that I'd come back to my system after a build finishes, to find the monitor turned on, with XFCE's Display configuration dialog sitting there, reverted to defaults (60 Hz... it mode switches back when changed back to 180 so I know it did revert). This would only happen if gone long enough for display power management, and if compiling.

At first I thought maybe something fucking up because of heat, but no. Hmm... it only seems to happen during my proton-tkg builds when I walk away and come back. Too often the same thing, to be a coincidence.

This stopped happening (XFCE losing its display settings while compiling this, with DPMS coming on), maybe the recompile of XFCE (Arch hasn't recompiled that in some time) with or without something, I don't know, but I was more observant of this today. I found this on my root console (I typed it so I omitted numbers etc.)

Code: Select all

xfwm4-critical: clientMoveToMonitorByDirectionTarget: assertion candidate_monitors !=NULL failed

That's it there, probably what was causing the loss of display settings. (I don't have multiple monitors)

OK, that build is invoking some system Wine components for the build, so there's probably some capabilities tests or something going on as they start up and something gets probed

Posted: **Sun Aug 04, 2024 7:59 pm**

Something interesting on Arch... I was reading their GTK wiki in hopes of finding some clues about my (subtle) font rendering differences in Arch and found that there's a semi-official "gtk3-classic" build maintained in the AUR, that has Client Side Decorations and some gnome hooks patched out. (moreover, you can't use this gtk3 for Gnome). While it didn't change anything to do with my font rendering in GTK environments (I didn't really expect it to) I like that, so I switched to it. I don't have any applications that don't respect my styling (e.g. I avoid anything GTK+4 though I'm stuck with having that because some other dependencies I need switched to it... like zenity used for some progress dialogs in Steam and Lutris) but now if anything tries to override my window decorations and titlebars and controls, it can't.

Posted: **Sun Aug 04, 2024 8:46 pm**

I was wrong, I do actually have one application that uses client side decorations, Meld. However, it uses it nicely, respecting my styling, only integrating the controls, such that I didn't really notice, however I do notice this now! Now it can't do that

(but this application doesn't deserve it)

: meld-nocsd.png (1.37 MiB) Viewed 76815 times

I just dragged the window small so it would be a huge file, but that's an uncompressed PNG (and with all image profile data preserved) which should look exactly like an application on my screen. I'm hoping that the bad subpixel hinting in GTK (seemingly caused by XFCE's font configuration on this system) and stuff might show up.

Does that show up? I can see it. Is a bit of red/brownish colour bleeding visible? Look at the i's in Maintainer and toolchain in the comments near the top. (That might not look like that on every display)

Posted: **Mon Aug 05, 2024 3:06 am**

I can see it, it's very subtle, maybe because of my eyes blending the adjacent colors and fading it out, but after pasting it into Gimp and taking it to 200% it was easy to see.

Posted: **Mon Aug 05, 2024 5:13 am**

It's a small thing, but now that I know about it, it's bugging me. While still not quite as crisp as in Gentoo (I don't think), the fonts are better outside of XFCE on my Arch. It's the same version as on Gentoo, but something is interacting differently somehow.

This wasn't anything new, it's always been like this on the new rig. Pretty much similar if not the same on my LFS setup too when I had it. That's why I was so surprised when I just changed a few fontconfig symlinks in Gentoo, and presto...

Posted: **Mon Aug 05, 2024 6:54 am**

I installed Meld in Gentoo now, and opened the same files so it would be the same text. This is a good GTK program to demonstrate it.

: meld-gentoo.png (1.37 MiB) Viewed 76691 times

Same, uncompressed PNG. Look how much nicer the fonts are in shape, hinting and sharpness. That's the same dejavu font (sans mono I think) at the same size.

Posted: **Mon Aug 05, 2024 8:56 am**

It does look much better.

Posted: **Wed Aug 07, 2024 1:15 am**

Arch's days are numbered... even for gaming for me. Another rebuild of the whole GNU toolchain, with new commits (not even the same code I'm building... I have to go look at it again to see WTF) 2 days later. Probably because now they have decided they want binutils-2.43 after all. This comes late in the day, after I did all my Arch system work today, all set for game time. I just bootstrapped all that Sunday night, too.

For me this means merging changes into PKGBUILDs then running them and cloning gigabytes of shit, compiling and then recompiling these packages (I do keep the raw git trees for the rebuilds though). That's probably a good part of my night ruined... just on time to fuck around with whatever they do again tomorrow. I have to, or I get behind. I've actually been keeping right up. (probably play some games first and at least TEST the things I built today before changing out the very guts of the system again... jeeze)

Arch is not a source based distro, and it's been a lot of work to try and treat it like one, even partially. It's a good distro, in the way of providing things though.

I'm wondering, with the automated build systems, if I could actually bring up a full multilib gaming system with Gentoo. I wouldn't be able to do things exactly the way I want them, but maybe I don't need to. I'm still getting the best compiled results (with my make.conf flags), even if it has more dependencies than I'd like because the USE flags aren't fine grained enough. Maintenance of it will be easier, especially if I don't fuck around too much.

I may actually blow my current Gentoo away again, and start working on that. Start with the multi-arch stage3 and work up to running Steam. Then work up to custom wine and proton builds etc. It would take some fiddling for me to get there the way I'd want to (no binary packages I mean) but I would still have this setup until such a day that it's superseded. Maybe I'm going about this all wrong, wanting Gentoo only for my minimal system.

Posted: **Mon Aug 12, 2024 5:59 pm**

Oh! Silly Arch bites me again. I don't use distro packages for build tools like this (simple utility I build with cargo and manually drop in /usr/local/bin), but I was curious to see what version of cbindgen Arch was using and how they were building it. Ahh, an upgrade to 0.27.0, good to know (I've been having to check out 0.26.0 instead of master). I thought surely they tested a Firefox build with it, but alas... no.

Code: Select all

 0:10.82 thread 'main' panicked at src/bindgen/config.rs:1125:34:
 0:10.83 called `Result::unwrap()` on an `Err` value: "Couldn't parse config file: TOML parse error at line 363, column 1\n    |\n363 | \"Keyframe\" = \"Keyframe\"\n    | ^\nduplicate key `Keyframe` in table `export.rename`\n."

Jeeze, I guess I better stop thinking "surely..." anything with Arch.

(They also build it with LTO... lol! This build utility is used for a few seconds at a time in a few builds. Moreover, some builds just build it as a library crate like they do with rust bindgen rather than expecting the binaries to be present. It's not practical, or necessary to build everything with LTO and it's not worth the risk if there is not significant benefit)

Good distro for my gaming uses though. Every time I get pissed off and think I'm going to move away from it, I realize just how flexible it is. I don't like the way they play the piano, so I can play my own music. Unlike Gentoo that makes me play Beethoven with bloody knuckles.

(I worded it like that because I actually had an old piano teacher that used to give me a stinging little whack on the back of the hands with her pointer until the day I stopped tolerating it... grade 6, age 11 or so, which was also around the same time I stopped tolerating religion

)

Posted: **Sat Sep 07, 2024 6:30 pm**

I just had a big update set with dozens of lib32 packages, a pkgrel bump without their 64 bit packages being updated. I wondered what was up there, so I went and looked.

They have rebuilt and pushed all those packages just for missing .SRCINFO file. This does not affect the binary package at all, and could have waited until next package upgrade. They have been like that for a long time, it's not urgent. This is the shit that pisses me off the most in Arch, they like to spin their wheels... and consequently mine. I let it install the distro packages, but I don't need to rebuild mine because of that, but now the pkgrel's aren't going to match and I'll get pacman warnings about the ignored packages.

Posted: **Wed Sep 11, 2024 7:03 pm**

I'm not sure how this happened, but their packages have a c in the git version string. (gab884fffe3f-1 vs. gab884fffe3fc-1

Code: Select all

[nicetry ~]# pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
:: Starting full system upgrade...
warning: gcc: ignoring package upgrade (14.2.1+r134+gab884fffe3f-1 => 14.2.1+r134+gab884fffe3fc-1)
warning: gcc-libs: ignoring package upgrade (14.2.1+r134+gab884fffe3f-1 => 14.2.1+r134+gab884fffe3fc-1)
warning: gcc-rust: ignoring package upgrade (14.2.1+r134+gab884fffe3f-1 => 14.2.1+r134+gab884fffe3fc-1)
warning: lib32-gcc-libs: ignoring package upgrade (14.2.1+r134+gab884fffe3f-1 => 14.2.1+r134+gab884fffe3fc-1)
warning: libgccjit: ignoring package upgrade (14.2.1+r134+gab884fffe3f-1 => 14.2.1+r134+gab884fffe3fc-1)
warning: lto-dump: ignoring package upgrade (14.2.1+r134+gab884fffe3f-1 => 14.2.1+r134+gab884fffe3fc-1)
 there is nothing to do

I just built and upgraded my gcc packages. Obviously it's the same version string, but theirs has an extra character. First time I've ever seen this. Harmless, but untidy... I've been trying to keep those version warnings to a minimum (it's irritating to have a long list... that's not all of it, I snipped some just to show the gcc packages)

It could be a case of packagers not eating their own dogfood... I used the latest PKGBUILD and my edits don't touch that in any way. It's obtained like this:

Code: Select all

pkgver() {
  cd gcc
  echo "$(cat gcc/BASE-VER)+$(git describe --tags | sed 's/[^-]*-[^-]*-//;s/[^-]*-/r&/;s/-/+/g;s/_/./')"
}

So... the packager likely has something different in that sed command.

Posted: **Sat Sep 14, 2024 4:54 pm**

So now it's not just /etc/makepkg.conf, they have added a makepkg.conf.d directory and they are now dropping files in it. They are bound and determined to push those bullshit compiler settings on me. For example, just in case you've commented them out in makepkg.conf, they've dropped in a rust.conf forcing frame pointers and debug info. I caught the play and nuked them.

When they start optimizing software for developers, for profiling and bug reporting, in addition to all those asshole hardening flags, they no longer serve their users.

Posted: **Sun Sep 15, 2024 9:06 am**

Arch news:

: ArchNews091524.jpg (86.29 KiB) Viewed 70098 times

Posted: **Sun Sep 15, 2024 4:58 pm**

That's stupid... it still needs root to install them. If I want to "download" packages as an unprivileged user I could use fucking wget. Arch spinning their wheels...

I don't have any local repos, so that doesn't affect me, but it irritates me that shit would be owned by another user. That's not even the problem, reading between the lines there, it also means they are setting restrictive permissions.

Posted: **Sun Sep 15, 2024 5:53 pm**

I haven't merged pacman.conf (I never use .pacnew files, only if there's something essential that I want/need to merge) so I don't have anything owned by alpm on my system, my repos and package cache etc. are all still owned by root:root with normal permissions. Moreover, I just did a "find / -user alpm" and not one file on this system is owned by that user. They did append the user into my /etc/passwd file though. This was added last (recent pacman upgrade), as the previous line was appended for the cosmic-greeter user.

alpm:x:958:958:Arch Linux Package Management:/:/usr/bin/nologin

In /etc /pacman.conf.pacnew

# Misc options
#UseSyslog
#Color
#NoProgressBar
CheckSpace
#VerbosePkgLists
#ParallelDownloads = 5
DownloadUser = alpm
#DisableSandbox

So as long as I don't merge that setting, I don't have to deal with that. I don't actually just "download" packages with pacman, if I want to download a package I'll use the browser or wget then explode it and look at the contents etc.

Posted: **Sun Sep 15, 2024 6:16 pm**

Yeah I thought that was a strange and pointless change. I won't be merging it either.

Posted: **Sun Nov 03, 2024 6:19 pm**

I'm kind of pissed off here (again). Look at this mess... Arch silliness:

Code: Select all

[nicetry ~]# pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra
 multilib is up to date
:: Starting full system upgrade...
warning: exo: ignoring package upgrade (4.18.0-3 => 4.18.0-4)
warning: garcon: ignoring package upgrade (4.18.2-2 => 4.18.2-3)
warning: gst-libav: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gst-plugin-gtk: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gst-plugins-bad: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gst-plugins-bad-libs: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gst-plugins-base: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gst-plugins-base-libs: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gst-plugins-good: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gst-plugins-ugly: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: gstreamer: local (1.24.9-2) is newer than extra (1.24.9-1)
warning: libxfce4ui: ignoring package upgrade (4.18.6-2 => 4.18.6-3)
warning: libxfce4util: ignoring package upgrade (4.18.2-2 => 4.18.2-3)
warning: linux-api-headers: local (6.11-1) is newer than core (6.10-1)
warning: xfce4-dev-tools: ignoring package upgrade (4.18.1-2 => 4.18.1-3)
warning: xfce4-panel: ignoring package upgrade (4.18.6-2 => 4.18.6-3)
warning: xfce4-pulseaudio-plugin: ignoring package upgrade (0.4.8-2 => 0.4.8-3)
warning: xfce4-session: ignoring package upgrade (4.18.4-2 => 4.18.4-3)
warning: xfce4-settings: ignoring package upgrade (4.18.6-3 => 4.18.6-4)
warning: xfce4-terminal: ignoring package upgrade (1.1.3-2 => 1.1.3-3)
warning: xfconf: ignoring package upgrade (4.18.3-2 => 4.18.3-3)
warning: xfdesktop: ignoring package upgrade (4.18.1-3 => 4.18.1-4)
warning: xfwm4: ignoring package upgrade (4.18.0-3 => 4.18.0-4)
 there is nothing to do

Gstreamer... there was an update to 1.24.9-1 a few days ago, but when I pulled the PKGBUILDs it had changed to a 1.24.9-2 pkgrel, a rebuild for x265, only they didn't push out the new packages. That's something I build and customize (fewer dependencies, less stuff enabled) to keep it from breaking my proton-media-converter and wine-gstreamer. I do wine-tkg and native proton-tkg builds and they aren't linked against Valve's gstreamer.

XFCE on the other hand, they simply changed the order of how they run configure... instead of doing it with autogen.sh they run autogen.sh with NOCONFIGURE and then run configure afterwards with --enable-maintainer-mode to spin their wheels (you don't need that, moreover it can cause failures). They insist on using git for everything even just to check out stable tags. It changes nothing about the software, it's just semantics. Yet they push out all those packages.

That's a lot of work for me, editing all those PKGBUILDs, I like XFCE built a bit differently and with fewer dependencies. My XFCE builds will literally run for a decade without a recompile, there's just no need for that shit. (and being my most important UI, I don't like updates to it. Hell, it took me 9 years to get off XFCE 4.12.0 and that's only because it won't run with Arch/systemd/dbus)

So OK, I'll take responsibility for that. I want to divorce that from Arch packaging, but it won't run from /opt on Arch because the systemd and dbus-broker shit won't run the xfconfd daemon. It has to go to --prefix=/usr. It still works on Gentoo like that (just need ldconfig entry, PKG_CONFIG_PATH, PATH and XDG_DATA_DIRS variables and built with --sysconfdir=/etc) but it fails to start an xfce4-session on Arch because of xfconfd. So I removed/undid everything and blasted back my XFCE packages. I wasted most of the afternoon yesterday troubleshooting this.

I can ignore the pacman warnings, but it makes it harder to spot real updates in the Ignorepkg list that I need to deal with. The only "legitimate" warning in there is because I built my glibc and friends against newer kernel headers. The gstreamer versioning will work itself out, but the XFCE won't. I think I'll just use sed to bump the pkgrel on my existing PKGBUILDs

P.S. I couldn't use sed, as the pkgrels weren't all the same, and it would have taken me longer to figure a way to script something that would increment them all by 1 and do it recursively than to just quickly edit the files and change one number, so that's what I did to clean up the ignore list warnings.

Posted: **Sun Nov 03, 2024 7:33 pm**

XFCE 4.20 is expected to release mid December

Posted: **Sun Nov 03, 2024 7:46 pm**

I probably won't upgrade it (I'll figure a more permanent solution for keeping this version by then). I don't want new dependencies, and deprecated APIs (e.g. XfcePanelImage) to break my styling etc.

There is no reason for me to want to use XFCE with Wayland at this time and consequently, no reason to upgrade at this time. If I was going to use a wayland session, I'd be using one of those DE/Compositors like Cosmic.

Posted: **Wed Nov 20, 2024 8:56 am**

Just licensing this time.

: ArchNews111924.jpg (90.02 KiB) Viewed 67483 times

Note: Despite its name, Zero-Clause BSD is an alteration of the ISC license, and is not textually derived from licenses in the BSD family. Zero-Clause BSD was originally approved under the name “Free Public License 1.0.0”.

Zero-Clause BSD
=============

Permission to use, copy, modify, and/or distribute this software for
any purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR DISCLAIMS ALL
WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE
FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

From opensource.org

Posted: **Wed Nov 20, 2024 10:20 am**

It's just build scripts... not even, it's a set of directives for makepkg/pacman. You can use them to build Arch packages, that's it. That's a free for all license anyway. They sure do like to spin their wheels.

Posted: **Mon Feb 17, 2025 9:13 am**

Arch news:

: ArchNews021725.jpg (75.71 KiB) Viewed 45493 times

I had no community repository entry on my main machine but I did on my game machine.

Posted: **Mon Feb 17, 2025 10:36 am**

I was just checking mine and I couldn't find /etc/pacman.conf. That's because I forgot I'm in Gentoo

I mounted and checked it and mine is modern enough that I don't have those old repos. That would have been last March when I built this system. I really should check for changes to merge, but I don't like the things they do and end up commenting out their shit anyway.

Posted: **Tue Feb 18, 2025 8:08 am**

That's something I've done before with multiple distros installed lol!

Yeah I installed Arch on my game machine before that change so that would be why it still had that repo. I still have to check the one downstairs, I forget when I installed it there.

Mikeserv Support Forum

Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024

Re: Arch Linux 2024