Page 1 of 2

Nemesis update- v25.04 (2025-04-01)

Posted: 03 Apr 2025, 03:49
by ncmprhnsbl
Second release for 2025

ISOs available here: ISO Downloads :dl-green:
Modules here: Module Downloads :dl-green:
05-devel here: 05-devel Download :dl-green:
Kernel and crippled sources: Kernel Downloads :dl-green:

Changelog:
  • Packages updated to 2025-04-01 (and mirrorlists set to corresponding package archive by default).
  • Kernel updated to 6.14 (thanks Blaze)
  • dbus, pipewire etc are now handled by openrc user service supervision (see ~./.config/rc ) removed pipewire startup script/.desktop
  • Adjusted .bash_profile to account for startup changes due to openrc user service processes ie. changed test and removed dbus-launch-session
  • Xfce4: added xfce4-screensaver and xfce4-pulseaudio-plugin , removed volumeicon
  • 001-core: removed syslog-ng and replaced it with metalog (thanks dreadbird)
  • removed linux-headers from 05-devel ...just getting too large and aren't needed for most things and easy enough to get if you do need them
ToDo
:) maybe read the last ToDo and do that...
probably an issue: mostly likely pipewire won't be working for root graphical sessions now.
Known Issues

Nemesis update- v25.04 (2025-04-01)

Posted: 03 Apr 2025, 08:00
by M. Eerie
First to download. I claim my badge as president of the fan club.
:cheerleader:

EDIT: Can post the sha256sums?

Nemesis update- v25.04 (2025-04-01)

Posted: 03 Apr 2025, 13:38
by ncmprhnsbl
M. Eerie wrote:
03 Apr 2025, 08:00
Can post the sha256sums?
sha256sums are on the download pages if you click on the "i" button ..
but perhaps i should put them in a .txt file that could be used by a network install type script or an updater script at some point..

Nemesis update- v25.04 (2025-04-01)

Posted: 03 Apr 2025, 14:05
by M. Eerie
ncmprhnsbl wrote:
03 Apr 2025, 13:38
sha256sums are on the download pages if you click on the "i" button ..
Would be much appreciated. For example, when I click on the 'i' of 05-devel it shows sha1sum and md5sum (this one checks ok, tho), but not sha256. SHA-1 is known for its speed, but not so much for its safety.

Thanks.

How do you get to control the sound now? --> (EDIT:) YOU ADD THE PULSEAUDIO PLUGIN TO THE PANEL.

NOTE:
When setup-pman finishes its execution, a module called pacman-settings.xzm is saved on demand in the $PORTDIR/modules/ folder.
However, I have found that the module doesn't get into UnionFS unless you prepend its name with a number following the mods style. That is, by adding a ###- prefix, like in: 099-pacman-settings.xzm

Nemesis update- v25.04 (2025-04-01)

Posted: 03 Apr 2025, 18:16
by M. Eerie
I can't find a way to automatically start the GUI. So far, I have to boot into text mode and then run startx. Otherwise, it seems that the X-server enters a loop.

Speaking of which..., would it be possible to include a login manager now?

I almost forgot. At the beginning, an error message related to .bash-profile is shown. Should be corrected (maybe in the sourced script).

This is its content:

Code: Select all

# Start x on login
if [[ -z $DISPLAY && ! -e /tmp/.X11-unix/X0 ]]; then
   #exec startx 
fi

# Use settings from ~/.bashrc

Proposed change:

Code: Select all

/.bash_profile 

# Start x on login
if [[ -z $DISPLAY && ! -e /tmp/.X11-unix/X0 ]]; then
   #exec startx 
   return
fi

# Use settings from ~/.bashrc
On the other side, we finally have a clean start (almost). :good:

Nemesis update- v25.04 (2025-04-01)

Posted: 04 Apr 2025, 00:43
by ncmprhnsbl
M. Eerie wrote:
03 Apr 2025, 14:05
but not sha256.
hah, i didn't notice that :) read "sha" a stopped there :teehee:
i'll generate and upload a shasums.txt (256)
M. Eerie wrote:
03 Apr 2025, 14:05
How do you get to control the sound now? --> (EDIT:) YOU ADD THE PULSEAUDIO PLUGIN TO THE PANEL.
M. Eerie wrote:
03 Apr 2025, 18:16
I can't find a way to automatically start the GUI.
M. Eerie wrote:
03 Apr 2025, 18:16
Proposed change:
99% sure you're getting these because of some loaded changes from previous ..
take a look at /mnt/live/memory/modules/003-xfce4*/home/guest/.bash_profile
it now looks like this:

Code: Select all

# Start x on login
#if [[ -z $DISPLAY && ! -e /tmp/.X11-unix/X0 ]]; then
#if pstree -s $$ | grep -q 'login'; then
if [[ $(tty) = "/dev/tty1" && ! -e /tmp/.X11-unix/X0 ]]; then
   exec startx 
fi
# Use settings from ~/.bashrc
if [ -f ~/.bashrc ]; then
    source ~/.bashrc
fi
as per
ncmprhnsbl wrote:
03 Apr 2025, 03:49
Adjusted .bash_profile to account for startup changes due to openrc user service processes ie. changed test
login/display manager: one that doesn't suck would be nice :)

Nemesis update- v25.04 (2025-04-01)

Posted: 04 Apr 2025, 03:28
by ncmprhnsbl
ncmprhnsbl wrote:
03 Apr 2025, 03:49
Don't use pman -Ss to search for packages (it will spawn unnecessary processes) use pacman -Ss , then use pmod with the correct package name
repeating this here:
ok, have uploaded a quick fix for this:
:dl-green: pman-fix.xzm
this should:
  • allow searching(-Ss)(and probably other non package fetching operations) without triggering an attempt to build a module from nothing
  • allow for wrong package name input without triggering an attempt to build a module from nothing (will output: error: target not found)
still needs some redesigning for saner operation, but should work for now

Nemesis update- v25.04 (2025-04-01)

Posted: 04 Apr 2025, 04:03
by ncmprhnsbl
M. Eerie wrote:
03 Apr 2025, 08:00
Can post the sha256sums?
done, doesn't quite cover every file, but all the newer.. https://sourceforge.net/projects/nemesi ... t/download

Nemesis update- v25.04 (2025-04-01)

Posted: 04 Apr 2025, 09:28
by M. Eerie
ncmprhnsbl wrote:
04 Apr 2025, 00:43
99% sure you're getting these because of some loaded changes from previous ..
Make it 100%. There have been many significant changes this time and I missed a few.
ncmprhnsbl wrote:
04 Apr 2025, 00:43
login/display manager: one that doesn't suck would be nice
My vote goes to LXDM. However there are many to choose from

Nemesis update- v25.04 (2025-04-01)

Posted: 04 Apr 2025, 09:55
by M. Eerie
May I suggest to use pacmandb-normalize at build time or as part of setup-pman?. Should not harm and provides for a cleaner setup

Nemesis update- v25.04 (2025-04-01)

Posted: 05 Apr 2025, 22:53
by M. Eerie
Once I deleted my ~/.[email protected], everything was in place and working seamlessly.

After working with it for a couple of days, I must say this is a great version.

Congrats!

(Bluetooth untested yet)

Nemesis update- v25.04 (2025-04-01)

Posted: 16 Apr 2025, 16:37
by isr
ncmprhnsbl wrote:
03 Apr 2025, 13:38
M. Eerie wrote:
03 Apr 2025, 08:00
Can post the sha256sums?
sha256sums are on the download pages if you click on the "i" button ..
but perhaps i should put them in a .txt file that could be used by a network install type script or an updater script at some point..
Can I suggest that you DON'T put the checksums on the same webserver as the iso's. After all, if someone can get access to the iso's & modify them, they can also update the checksums to match.

My suggestion: just put up a simple github (or chisel, for fossil) repo, whose sole purpose is to keep checksum files for each iso release. Then link to the raw version of the relevant file from each download page.

Nemesis update- v25.04 (2025-04-01)

Posted: 18 Apr 2025, 03:36
by ncmprhnsbl
M. Eerie wrote:
04 Apr 2025, 09:55
May I suggest to use pacmandb-normalize at build time or as part of setup-pman?. Should not harm and provides for a cleaner setup
yep, shouldn't be too hard to implement, maybe something in pman too.. correct me if i'm wrong: this affects the line:(when querying the database) "Install Reason:" ,
which will be : "Explicitly Installed" for all packages because of using "pacman -Uddr" (dd = no dependency resolution) regardless of the "Required by:" line
isr wrote:
16 Apr 2025, 16:37
Can I suggest that you DON'T put the checksums on the same webserver as the iso's. After all, if someone can get access to the iso's & modify them, they can also update the checksums to match.
the checksums are more for just checking the download integrity, than for any security concerns, which if i was to be really serious about, i'd be looking at the gpg/pgp keys route..
but yeah it'd be easy enough to put them in separate place or simply posting them here would have similar effect.

Nemesis update- v25.04 (2025-04-01)

Posted: 18 Apr 2025, 09:32
by M. Eerie
ncmprhnsbl wrote:
18 Apr 2025, 03:36
this affects the line:
Exactly. In reality, the only modification that occurs happens in the file /var/lib/pacman/local/<package>/desc, right below the %REASON% line, where a 1 will appear if the package is a dependency or a 0 %REASON% line doesn't exists if the package is explicit. This could also be done using sed instead of pacman -D --as<deps/explicit>.

You can do a quick manual test by deleting the lines %REASON% and the one immediately following it, and then:

Code: Select all

pacman -Qqe | wc -l
or

Code: Select all

pacman -Qqd | wc -l

The method I use to determine this is the string found after "Depends on" in english. This one should match the line below the %DEPENDS% line in the "desc" package file located in /var/lib/pacman/local/<package>/desc. I don't know exactly how pacman interprets it as "None". Logic suggests that this would be true if the line were empty or contained the word "None," but in the tests I've conducted, that hasn't been the case, so I trust what `pacman` reports instead.


For example, in my Arch Linux, xfconf appears among the explicit packages when I run `pacman -Qqe`; however

Code: Select all

grep -A 1 "%DEPENDS%" /var/lib/pacman/local/xfconf-4.20.0-2/desc
returns:

Code: Select all

%DEPENDS%
libxfce4util

Nemesis update- v25.04 (2025-04-01)

Posted: 19 Apr 2025, 13:44
by M. Eerie
ncmprhnsbl wrote:
18 Apr 2025, 03:36
regardless of the "Required by:" line
I hadn’t noticed the "Required by:" line provided by pacman -Qi, and it turns out to be the most reliable method for determining whether a package is a strong candidate to be explicit or not. I’ll be updating the script shortly.
Thanks!

According to Copilot this is the explanation:

Is it worth doing a second pass with Depends On.*None?

In theory, it could complement the first check, but it doesn't necessarily guarantee that the package should be explicit. Here’s why:

Checking Required By: None is sufficient in most cases
If a package is not required by others (Required By: None), it is a strong candidate to be explicit.

* Whether it has dependencies (Depends On: X) is irrelevant because many explicit packages depend on others without affecting their classification.

* A package with Depends On: None doesn't guarantee it should be explicit

A package not having dependencies simply means it doesn’t require others to function, but it could still have been installed automatically as a dependency of another package.

Example: If pacman installed libpng automatically as part of a dependency and libpng doesn’t require other packages (Depends On: None), that doesn’t mean it was originally explicit.


When might a second pass be useful?

If you want to perform a broader verification and detect truly independent packages in the system, you could do something like this:

Code: Select all

LC_ALL=en pacman -Qq | while read -r package; do
    pacman -Qi "$package" | grep -q "Required By.*None" && echo "$package"
done | tee explicit_candidates.txt

LC_ALL=en pacman -Qq | while read -r package; do
    pacman -Qi "$package" | grep -q "Depends On.*None" && echo "$package"
done | tee independent_packages.txt
This would create two lists:

explicit_candidates.txt: Packages with no dependents.
independent_packages.txt: Packages with no dependencies.

Then, you could compare both lists and filter packages that appear in both with:

Code: Select all

comm -12 <(sort explicit_candidates.txt) <(sort independent_packages.txt)
Conclusion:

A second pass using "^Depends On.*None" is not strictly necessary for restoring explicit packages, but it could be useful if you want to analyze which packages are truly independent—meaning they don’t depend on anyone and no one depends on them. If your goal is to recover the correct classification, the "^Required By.*None" check remains the most reliable method.