PorteuX 0.9 user problem

[Ed_P]

@Ed_P, that's because libtiff has been updated. There's a workaround: go to /usr/lib64 and as root make a copy of libtiff.so.6 to libtiff.so.5 (same path).

That works. Thank you.

Added in 10 hours 19 minutes 8 seconds:
So, in 0.8 this:

Code: Select all

dir2xzm /tmp/mod -o=/tmp/mycinnamon.xzm   &&   rm -rf /tmp/mod

produced this:

Code: Select all

guest@porteus:/mnt/nvme0n1p7/porteux/Modules$ ls -hon *08.xzm
-rwxrwxrwx 1 1000 33M Nov 11 16:25 mycinnamon08.xzm*

but in 0.9 I got this:

Code: Select all

guest@porteus:/mnt/nvme0n1p7/porteux/Modules$ ls -hon *09.xzm
-rwxrwxrwx 1 1000 576K Dec 17 18:42 mycinnamon09.xzm*

dir2xzm changed?

[Rava]

So, in 0.8 this:

Code: Select all

dir2xzm /tmp/mod -o=/tmp/mycinnamon.xzm   &&   rm -rf /tmp/mod

produced this:

Code: Select all

guest@porteus:/mnt/nvme0n1p7/porteux/Modules$ ls -hon *08.xzm
-rwxrwxrwx 1 1000 33M Nov 11 16:25 mycinnamon08.xzm*

but in 0.9 I got this:

Code: Select all

guest@porteus:/mnt/nvme0n1p7/porteux/Modules$ ls -hon *09.xzm
-rwxrwxrwx 1 1000 576K Dec 17 18:42 mycinnamon09.xzm*

dir2xzm changed?

Is your mycinnamon09.xzm meant as a replacement for the 003-DE module?
or is it meant as your "settings module" ?
But since there seems to be no ISO named porteux-v0.9-cinnamon*-x86_64.iso (be the * either "current" or "stable") I presume your mycinnamon09.xzm is meant as your DE module?
Or do you use mycinnamon08.xzm (mycinnamon09.xzm) together with an official 003-DE module to turn that GUI settings into the cinnamon flavour? (no pun on cinnamon and flavour intended.)

What does a

Code: Select all

du -sch foldername/

give you for the folder you used as dir2xzm base for the mycinnamon08.xzm and for the mycinnamon09.xzm module?

[Ed_P]

Is your mycinnamon09.xzm meant as a replacement for the 003-DE module?
or is it meant as your "settings module" ?

Both. It's the 003-cinnamon-5.8.0-current-20230630.xzm module plus some minor tweaks. I move the taskbar to the bottom of screen then tweak the Date & Time, time zone settings. I normally keep my changes separate from ISO modules but these were so minor and porteux so new, etc, etc and rather than have two modules I made one.

How I got the small changes module I have no idea. When I reran the script later in terminal mode to document the problem better it ran fine but the size was small again:

Code: Select all

total 576
srwxrwxrwx 1 1000      0 Dec 18 02:08 dbus-ikIgGIFdC9
-rw-r--r-- 1    0 589824 Dec 18 02:11 mycinnamon.xzm
drwx------ 2 1000     40 Dec 18 02:08 xdg-runtime-guest
drwx------ 2    0     40 Dec 18 02:08 xdg-runtime-root
guest@porteux:/mnt/nvme0n1p7/porteux$ 

And with it, booting doesn't start the GUI.
I wanted to post this last night but couldn't signon to report it till now.

Or do you use mycinnamon08.xzm (mycinnamon09.xzm) together with an official 003-DE module to turn that GUI settings into the cinnamon flavour? (no pun on cinnamon and flavour intended.)

I use this 003 module PorteuX 0.5 has been released (Post by porteux #94812) with this ISO: porteux-v0.9-mate-1.27.3-current-x86_64.iso.

Added in 2 hours 51 minutes 35 seconds:
Finally able to signon again.

I found the problem and coded the fix for it.

Code: Select all

guest@porteux:/mnt/nvme0n1p7/porteux$ ls -hon Modules/
total 135M
-rwxrwxrwx 1 1000  33M Nov  5 04:31 003-cinnamon-5.8.0-current-20230630.xyzm*
-rwxrwxrwx 1 1000  70M Oct 31 20:05 firefox-119.0-x86_64-en-US.xzm*
-rwxrwxrwx 1 1000  33M Nov 11 21:25 MyCinnamon.xzm*
-rwxrwxrwx 1 1000 4.0K Nov 21 23:58 mynemochanges.xzm*
guest@porteux:/mnt/nvme0n1p7/porteux$ 

My simple script reads the 003- file, runs the xzm2dir command on it to copy all the files & folders to the new module folder. Once my Cinnamon tweak is done and the module created the new module is added to the Modules folder and I rename the 003- module so it doesn't load rather than removing the file. This works fine but fails when the 003- has been renamed as .xyzm. xzm2dir doesn't like .xyzm files. I have modified the script to test for the absence of the 003-*.xzm file and abort if not found.

Added in 4 minutes 43 seconds:

What does a

Code: Select all

du -sch foldername/

give you for the folder you used as dir2xzm base for the mycinnamon08.xzm and for the mycinnamon09.xzm module?

Code: Select all

guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ du -sch 003-*
33M	003-cinnamon-5.8.0-current-20230630.xyzm
33M	total
guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ 

[Rava]

^
I meant using

Code: Select all

du -sch foldername/

when "foldername/" is the folder you use as source for the dir2xzm… (hence I wrote "foldername/" (even with an ending "/" that cannot be part of a filename) and not "filename") but it seems the issue solved itself (because it seems the issue was that the porteux dir2xzm script dares to check if the given output module name ends in ".xzm")

[Ed_P]

I meant using

Code: Select all

du -sch foldername/

when "foldername/" is the folder you use as source for the dir2xzm…

Hard to do.

Code: Select all

xzm2dir /mnt/nvme0n1p7/porteux/Modules/003-*       -o=/tmp/mod

Code: Select all

guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ du -sch 
168M	.
168M	total
guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ du -sch 003-*/
du: cannot access '003-*/': No such file or directory
0	total
guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ ls -hon
total 135M
-rwxrwxrwx 1 1000  33M Nov  5 04:31 003-cinnamon-5.8.0-current-20230630.xyzm*
-rwxrwxrwx 1 1000  70M Oct 31 20:05 firefox-119.0-x86_64-en-US.xzm*
-rwxrwxrwx 1 1000  33M Dec 18 14:14 MyCinnamon.xzm*
-rwxrwxrwx 1 1000 4.0K Nov 21 23:58 mynemochanges.xzm*
guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ du -sch 003-cinnamon-5.8.0-current-20230630.xyzm/
du: cannot access '003-cinnamon-5.8.0-current-20230630.xyzm/': Not a directory
0	total
guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ du -sch 003-cinnamon-5.8.0-current-20230630.xzm/
du: cannot access '003-cinnamon-5.8.0-current-20230630.xzm/': Not a directory
0	total
guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ 

You mean the other command.

Code: Select all

 dir2xzm /tmp/mod -o=/tmp/MyCinnamon.xzm   &&   rm -rf /tmp/mod

Code: Select all

guest@porteux:/mnt/nvme0n1p7/porteux/Modules$ su
Password: 
root@porteux:/mnt/nvme0n1p7/porteux/Modules# du -sch /tmp/mod/
125M	/tmp/mod/
125M	total
root@porteux:/mnt/nvme0n1p7/porteux/Modules#

[Ed_P]

So, how does one make a module of a link? As in a file whose Properties have: "Type Link to share library (application/x-sharedlib)"? I know how to do the file the link points to but links are smaller. Does "cp -a --parents /etc/lib64/libtiff.so.5 /tmp/mod/" copy the link or the libtiff.so.6 file?

[Rava]

Why don't you use

Code: Select all

ln -s source-file target-filename

to create a link?
It doesn't matter when the link in the folder you create the module from seems broken - e.g. because it wants to link to a file in the same path as itself, but that doesn't exist in the module creation folder. But as long as that file exists in the live system, the link will be an active and valid one.

Example: The module I create for Pale Moon has this symlink in it:

Code: Select all

usr/bin/palemoon -> /opt/palemoon/palemoon

This link is only valid when the Pale Moon module is itself activated, because without it there is no folder /opt/palemoon/ and without that folder there is no binary /opt/palemoon/palemoon

[Ed_P]

Why don't you use

Code: Select all

ln -s source-file target-filename

to create a link?

So I should create a desktop file with the "ln -s /etc/lib64/libtiff.so.5 /etc/lib64/libtiff.so.6" command in it, put it in /.config/autostart (or /etc/xdg/autostart) and put that in my module?

The module I create for Pale Moon has this symlink in it:

Code: Select all

usr/bin/palemoon -> /opt/palemoon/palemoon

So the "cp -a --parents /etc/lib64/libtiff.so.5 /tmp/mod/" code I posted above will copy the symlink and not the linked file. Perfect. Thank you.



Added in 6 hours 14 minutes 24 seconds:
This worked. Creates a tiny 4K module.

Code: Select all

cd /usr/lib64
ln -s libtiff.so.6 libtiff.so.5  # ln -s source target
cp -a -p --parents /usr/lib64/libtiff.so.5            /tmp/mod 

Thank you Rava/LinkMstr

[Rava]

Code: Select all

cd /usr/lib64
ln -s libtiff.so.6 libtiff.so.5  # ln -s source target
cp -a -p --parents /usr/lib64/libtiff.so.5            /tmp/mod

If that works for you, okay.
I would do it like so:

Code: Select all

# as user root
mkdir -p /tmp/mod/usr/lib64/
cd /tmp/mod/usr/lib64/
ln -s libtiff.so.6 libtiff.so.5

But I guess either way you get a mere (broken) symlink in /tmp/mod/usr/lib64/ named libtiff.so.5 - and when that settings module gets activated, the broken symlink becomes a valid one because then its target "libtiff.so.6" in the same folder as itself ( /usr/lib64/ ) is now valid.
Why do I choose to do it that way? Maybe because it is the same way the Slackware setup scripts in /var/lib/pkgtools/scripts/ do it.
Maybe take a look into some of these, I find them rather simple yet charming the way they are coded.

[Ed_P]

If that works for you, okay.
I would do it like so:

I did it as you recommended here:

You don't need to make a copy, a symlink also works.
as root :

Code: Select all

cd /usr/lib64
ln -s libtiff.so.6 libtiff.so.5  # ln -s source target

While I see how your new suggestion would also work it doesn't fit my standard module script format.

[Otto]

porteux-v0.9-xfce-4.18-current-x86_64
The welcome screen of vivaldi browser will show up after 20 seconds or more.
Opera has almost the same delay also.

No problem with porteux-v0.8.

[porteux]

porteux-v0.9-xfce-4.18-current-x86_64
The welcome screen of vivaldi browser will show up after 20 seconds or more.
Opera has almost the same delay also.

I failed to replicate this issue.

Have you tried in Always Fresh?

[Otto]

The browsers have the same problem with v0.9 fresh install or after updated from v0.8 to v0.9

[Otto]

The browsers problem solved using porteux-v1.0-xfce-4.18-current-x86_64