Kaisen-skeleton error?

@MidGe, @rkyrk and @catinabox can you retry (sorry for that…) again to launch an update of Kaisen Linux?
I just testing an update from a XFCE VM , and I not any problem with the update of the kaisen-skeleton package.

1 Like

Hi Kevin,

Yes, that seems to have fixed the problem. I am running the KDE edition by the way.

❯ sudo kaisen-update
[sudo] password for michel:
Hit:1 https://brave-browser-apt-release.s3.brave.com stable InRelease
Ign:2 Index of /stable/deb/ stable InRelease
Hit:3 Index of /stable/deb/ stable Release
Get:5 https://deb.kaisenlinux.org kaisen-rolling InRelease [19.7 kB]
Get:6 https://deb.kaisenlinux.org kaisen-rolling/main Sources [14.8 MB]
Get:7 https://deb.kaisenlinux.org kaisen-rolling/main amd64 Packages [18.4 MB]
Get:8 https://deb.kaisenlinux.org kaisen-rolling/main i386 Packages [18.2 MB]
Fetched 51.4 MB in 11s (4,607 kB/s)
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
1 package can be upgraded. Run ‘apt list --upgradable’ to see it.
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
The following packages will be upgraded:
kaisen-skeleton
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 5,900 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 https://deb.kaisenlinux.org kaisen-rolling/main amd64 kaisen-skeleton all 2.1+kaisen4 [5,900 kB]
Fetched 5,900 kB in 3s (1,853 kB/s)
Supported
Create a snapshot of ‘/tmp/apt-btrfs-snapshot-mp-kpf_l4jq/@’ in ‘/tmp/apt-btrfs-snapshot-mp-kpf_l4jq/@apt-snapshot-2022-08-09_07:15:33’
(Reading database … 605666 files and directories currently installed.)
Preparing to unpack …/kaisen-skeleton_2.1+kaisen4_all.deb …
Unpacking kaisen-skeleton (2.1+kaisen4) over (2.1+kaisen3) …
Setting up kaisen-skeleton (2.1+kaisen4) …
Processing triggers for kaisen-menu (2.1+kaisen6) …
Scanning processes…
Scanning processor microcode…
Scanning linux images…

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Thanks for that! :slight_smile:

Michel

Yes!

Thank you for your feedback! Glad your return was able to fix this bug! I’ll do the Codium updates soon :wink:

I’m waiting the return of @rkyrk and @catinabox to close this ticket :wink:

No worries.

I downloaded the latest vscodium and installed it with no issues. So, I don’t need an urgent fix for that.

Thanks anyway,

Michel

PS. What was the issue with the skeleton?

Thank you Kevin. Just did an update and all went smoothly with no issues. Fixed for me.

I currently doing a complete redesign of the kaisen-skeleton package. Actually, the kaisen-skeleton package install the default profiles for all interfaces for news users from the /etc/skel folder. This system makes the maintenance hard. In addition to this, errors may occur, as for MATE for example (the database dconf file was copied from /etc/skel for users).
So, I remake all default profile and they will be installed in /etc/xdg directory with few conffiles instead of database files or files in the /etc/skel directory. This commit as example : Add MATE default profile with conffiles. Remove the MATE defualt profile installed in the skel. (ec44c436) · Commits · Kaisen Linux / Packages / kaisen-skeleton · GitLab
But I not understand the bug with the git clone of oh-my-zsh, because this element or its installation wasn’t modified.
The bug with dconf was here because I forgot to declare an if statement in the maintainers scripts to exec the dconf command only when it’s installed.
In addition to this, the XDG standard will be more respected with this new installation of profiles method.

Thank you for your feedback @rkyrk!
I’m glad for that!

Thanks for the info, Kevin.

Re: oh-my-zsh - could it be because zsh can auto-update itself, perhaps, outside of apt?

No,
It’s not that.
When the kaisen-skeleton package is installed, all files are copied in the /usr/share/kaisen-skeleton/ and then will be installed in the /etc/skel folder by the postinst script (this script is run after the decompression of the package and allows to run actions after the installation of files for example). The oh-my-zsh repo is cloned and installed in the /etc/skel folder by the postinst script (for always keep it up-to-date for NETINST users or with updates of packages).
When an update of this package is running, the postrm script is called to run actions. In this script, the deletion of all files in the /etc/skel directory are made, including oh-my-zsh.

Think of it like this (very briefly):
=> First installation of the package:

  • Running of the preinst script if exist
  • Installation of files
  • Running of the postinst script if exist (oh-my-zsh will be installed in the /etc/skel at this moment)

Installation ok if no error encountered.

=> Update of the package (very briefly again):

  • Running of the prerm script if exist
  • Running the postrm script if exist (when an update is running, all files installed by the package are delete to be replaced by new versions and the postrm script will be run after that)
  • Execution of the preinst script if exist
  • Installation of files in the package
  • Execution of the postinst script if exist (oh-my-zsh previously uninstalled by the postrm script will be downloaded with the postinst script)

Update ok if no error encountered.

For that, I don’t understand why the oh-my-zsh cannot be cloned in indicating that the folder isn’t empty because the postrm script must delete oh-my-zsh before the execution of the postinst script when the new version of package is installed by APT or DPKG.

I fixed that in simply adding a boolean condition :slight_smile:

The postinst script of the kaisen-skeleton package : debian/postinst · master · Kaisen Linux / Packages / kaisen-skeleton · GitLab

The postrm script of the kaisen-skeleton package : debian/postrm · master · Kaisen Linux / Packages / kaisen-skeleton · GitLab

1 Like

I see now that is a two step process.

But still, I know that zsh/oh-my-zsh update automatically sometimes and that is without apt or dpkg intervention, simply scripts change I guess. Could that not create the problem? The postrm script would not be invoked then.

Anyway, your solution fixes the issue. I am simply interested in understanding the cause of the problem> :slight_smile:

Thanks again for your time and for your great distro, even if I have not a sysadmin bend. :slight_smile: It really saved me a lot of time when rebuilding my workstation which I do every 6 to 9 months usually. That usually takes more than a day. It took only 2-3 hours with your distro and will be faster next time.

Yes, he is automatically updated when users using it from their personnal home directory, but omz isn’t automatically updated in the skel.

I’m glad that Kaisen suits you :wink: