Porteus Nemesis v3.5 BUG REPORTS

[donald]

Thanks francois
Quoting brokenman: "I also prefer xfce4 so will put something together"
so I will wait until it's ready...I'm lazy ATM...winter depression.

[francois]

Just get on phototherapy for SADS, three days of a 10000 lumens white spectrum, 30 minutes a day, or better blue lite 465 nm at 100% for 15 mins a day should do it. 8)

ATM. What is it?

But your are right xfce4 should be the next. I will be very easy to set up.

@ brokenman: can we get a complete desktop with packages like what we have on porteus 3.1 xfce4: gparted, browser, accessories including leafpad (instead of mousepad). The full set to name it.

[Philip]

32-bit nemesis 3.5 LXDE

In Porteus 3.1, we have /lib/libncurses.so.5 as a symbolic link to /lib/libncurses.so.5.9 and all is well.

But in nemesis 3.5, there is a file /lib/libncurses.so but it's not a symbolic link to anything (appears to be just a text file).
There is no /lib/libncurses.so.5 sym link and libncurses.so.5.9 is missing.

There are other libncurses libraries present, libncursesw for example, and others ending in ++ as there are in Slackware Porteus.

[brokenman]

Thanks Philip.

[istinnjazz]

I had tested some parts of this very useful distro for the first time.
I am using x64 LXDE
I have managed successfully to compile a custom kernel 4.5.4 with ck patches and I have installed nvidia drivers 340.96 version.
I have also created java 8 xzm with "java builder".

First of all I had some problems using wifi, firmware missing, kernel could not find it. I had to download linux-firmware package with pman somehow.
I found network manager confusing.
Bug: Panel button in task bar shows always "enable networking/wifi/notifications" and it will not change to "disable" even if it appears to function. As I have a notebook with a touch button I have to use rfkill command to enable disable it in terminal.

Kernel compile asked for a missing package: bc
installed as xzm

Other than this it seems pretty stable. As I go further I will use aur, for now I get:

Code: Select all

guest ~ $ pacaur -Syy
:: /tmp/pacaurtmp-guest does not have write permission.

Code: Select all

root /home/guest # pacaur -Syy
:: you cannot perform this operation as root

[istinnjazz]

There is also an other odd issue:
There is no savefile manager (at leas in task-bar menu), so I have created a new image file with dd and mkfs.ext4 command, it works and saves ok.
But after loading, there are some missing icons and corresponding commands in pcmanfm (root and guest), e.g. *.xzm or *.sh files do not have an icon, somehow pcmanfm looses some of its original preferences considering icon and "menu" commands.

[Evan]

<removed>

[istinnjazz]

Ok evan, thanks for the info
I hope there will be space for an arch or manjaro version
It seems coplicated to maintain a special rolling release for this type of distribution, but it seems very usefull in practice.
I had also have seen an other project called aporteus here, but not sure what the differences are. Manjaro/arch? Systemd/openrc?

I will use this for a while as i can do almost all i want for now, i hope a version will survive with minimum updates once in a while.

[jamie81]

Ok evan, thanks for the info
I hope there will be space for an arch or manjaro version
It seems coplicated to maintain a special rolling release for this type of distribution, but it seems very usefull in practice.
I had also have seen an other project called aporteus here, but not sure what the differences are. Manjaro/arch? Systemd/openrc?

I will use this for a while as i can do almost all i want for now, i hope a version will survive with minimum updates once in a while.

I agree. I've been following this and have always been a fan of arch. The aur is just amazing and you can get anything you want rather simply most of the time. I really hope this Nemesis continues as it is an amazing idea and would be great to see it fully realized.

[istinnjazz]

Report for the 1st system update:
Note: Always backup your savefile before any update. I had serious problems in manjaro with updates that had destroyed the system (black screens etc.) and it seems there is not a straight recovery operation as far as I know. This is a known often phenomenon of rolling releases, you have to backup. There is always a risk.

1. There has been some pacman related messages according some "duplicated database entries". There has been some "pman" xmz installations from repository before the update, there had to be deleted to proceed to the update (apparently it concerned those packages also). There was no message in the GUI, just in the embedded console and of course it was a known message in pacman to me (I have seen it in other arch also). you have to delete xzm modules if there are still active and reboot.

proposal: You could think of taking care of the "duplicated database entries", "pacman -Suu" could not resolve this. You could temporarily deactivate them and move them in an other folder.


2. There was a strange message about a dublicated file: "libdcadec.so.0" in libs directory. This was a symbolic link. I had to delete for the update to proceed. I do not have a clue why, but update manager checks and verifications reported it.

3. There has been also some errors related to "arch" and "manjaro" certificates packages like "manjaro-keyring-20160514-1-any.pkg.xzm" that had been created in modules dir. Update manager created also one named with the prefix "arch". There was a conflict between them.

The manager, as a pacman wrapper has same minor bugs, e.g. sometimes it could not save preferences for selected packages not to be updated.
The related last window shows only a part of the packages to be updated, but the update is all there. It used cached downloads successfully after all failed attempts. The last stop messages where "unexpected error".
Finally as a feature: I would like to see a select all and multiple-selections with shift button.


Update was successful, updated files saved to savefile disk image.

Some missing icons had been corrected. It seems that there are bugs related to each software not the distro itself.
I choose not to update xorg and x86 packages just for precaution.

General notes:
OpenRC works great, faster than systemd here, clearer boot messages

I have a proposal, I do not know if it is applicable: After an update, any update, there could be a way to save a xzm "with only the updated files" this kind of xzm that have priority over the savefile if selected somehow in boot (as a recovery operation)

If it is successfull, there could be a user driven process to delete all old (dublicated) files and recreate xzm files, and free save-file. I do not know if this is good or not. After all if all updates take place in the savefile side there will be only one incremental file to care about.


WARNING!!

A serious bug:
for USB fat32 installation with a savefile.

I think it concerns all porteus versions, and it has to do with "trash" feature of pcmanfm. I had to disable it. Although it says that it will not use trash on removable media, actually it does. And the fat32 file system gets corrupted. If you delete a file, it seems deleted, but it is there physically and occupies space that it is not reported by the system.
Systems sees more free space that you actually have, check disk in win7 created recovered files for all the deleted files, and corrected the real free space!

There were system unrecoverable errors when tried to update without knowing the real free space of the media, the update stopped unexpectedly with "could not write" or "could not continue" or something, I do not really remember. The package that has been destroyed was gtk2, there was unexpected behavior after reboot. I had to recover save-file from backup.


Finlay, the system runs as smooth as before (about 285 updates). Impressed!
I do not have a clue what it will be the update model in the future, but somehow it seem to work. I hope you will keep the manjaro/openrc combination, it seems well supported in manjaro community.
For the update you will need at least 4GB card, savefile >2GB

[istinnjazz]

After the update there are some menu artifacts, missing real formatting (before there were missing icons on applets). Also all gtk3 apps like gnome player, paman updater etc, have serious formating problems.
You have to download some new gtk3 themes and icons from repository.
I choose to use those manjaro themes, they look good. Now there are some other, only minor formating problems.
Also solved the missing enable/disable icons on network manager menu

adwaita-maia-gtk3 (has some nice icons too)
vertex-maia-gtk3 (has a good looking dark alternative)

There were minor issues with the non-gtk3 LXDE packages.
LXDE GTK3 packages installed and solved (as far as I have tested) the graphics problems. There could be issues with other software.

OpenRC updated also

[istinnjazz]

An other problem, an independent bug in libc, when tiring to compile a kernel.

Code: Select all

make menuconfig
  HOSTCC  scripts/basic/fixdep
/usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib/crti.o: unrecognized relocation (0x2a) in section `.init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
scripts/Makefile.host:91: recipe for target 'scripts/basic/fixdep' failed
make[1]: *** [scripts/basic/fixdep] Error 1
Makefile:443: recipe for target 'scripts_basic' failed

partial explanation: https://bugs.debian.org/cgi-bin/bugrepo ... bug=808205

solution:

Code: Select all

root /mnt/sdb5/linux/linux-4.5 # pman -S binutils
resolving dependencies...
looking for conflicting packages...

Packages (1) binutils-2.26-4

Total Installed Size:  27.72 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                                                 [#############################################] 100%
(1/1) checking package integrity                                               [#############################################] 100%
(1/1) loading package files                                                    [#############################################] 100%
(1/1) checking for file conflicts                                              [#############################################] 100%
error: failed to commit transaction (conflicting files)
binutils: /usr/bin/addr2line exists in filesystem
binutils: /usr/bin/ar exists in filesystem
binutils: /usr/bin/as exists in filesystem
binutils: /usr/bin/c++filt exists in filesystem
binutils: /usr/bin/dwp exists in filesystem
binutils: /usr/bin/elfedit exists in filesystem
binutils: /usr/bin/gprof exists in filesystem
binutils: /usr/bin/ld exists in filesystem
binutils: /usr/bin/ld.bfd exists in filesystem
binutils: /usr/bin/ld.gold exists in filesystem
binutils: /usr/bin/nm exists in filesystem
binutils: /usr/bin/objcopy exists in filesystem
binutils: /usr/bin/objdump exists in filesystem
binutils: /usr/bin/ranlib exists in filesystem
binutils: /usr/bin/readelf exists in filesystem
binutils: /usr/bin/size exists in filesystem
binutils: /usr/bin/strings exists in filesystem
binutils: /usr/bin/strip exists in filesystem
binutils: /usr/include/ansidecl.h exists in filesystem
binutils: /usr/include/bfd.h exists in filesystem
binutils: /usr/include/bfdlink.h exists in filesystem
binutils: /usr/include/dis-asm.h exists in filesystem
binutils: /usr/include/plugin-api.h exists in filesystem
binutils: /usr/include/symcat.h exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.x exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xbn exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xc exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xd exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xdc exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xdw exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xn exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xr exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xs exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xsc exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xsw exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xu exists in filesystem
binutils: /usr/lib/ldscripts/elf32_x86_64.xw exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.x exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xbn exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xc exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xd exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xdc exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xdw exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xn exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xr exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xs exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xsc exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xsw exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xu exists in filesystem
binutils: /usr/lib/ldscripts/elf_i386.xw exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.x exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xbn exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xc exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xd exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xdc exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xdw exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xn exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xr exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xs exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xsc exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xsw exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xu exists in filesystem
binutils: /usr/lib/ldscripts/elf_k1om.xw exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.x exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xbn exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xc exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xd exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xdc exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xdw exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xn exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xr exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xs exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xsc exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xsw exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xu exists in filesystem
binutils: /usr/lib/ldscripts/elf_l1om.xw exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.x exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xbn exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xc exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xd exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xdc exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xdw exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xn exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xr exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xs exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xsc exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xsw exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xu exists in filesystem
binutils: /usr/lib/ldscripts/elf_x86_64.xw exists in filesystem
binutils: /usr/lib/ldscripts/i386linux.x exists in filesystem
binutils: /usr/lib/ldscripts/i386linux.xbn exists in filesystem
binutils: /usr/lib/ldscripts/i386linux.xn exists in filesystem
binutils: /usr/lib/ldscripts/i386linux.xr exists in filesystem
binutils: /usr/lib/ldscripts/i386linux.xu exists in filesystem
binutils: /usr/lib/libbfd.a exists in filesystem
binutils: /usr/lib/libopcodes.a exists in filesystem
Errors occurred, no packages were upgraded.

If you force installation:

Code: Select all

pman -S --force binutils

problem solved

I do not know if it has side effects. Pman with force parameter did not create xzm, it installed in main. (maybe a feature todo)

[francois]

Very good testing guys. Continue to keep it alive. Until it could be reanimated.

[istinnjazz]

Very good testing guys. Continue to keep it alive. Until it could be reanimated.

I am sure it will be. This is a very special porteus that has to survive. The manjaro/openRC combination is a very good case of the arch linux platform.

There is no need to keep frequent updates, this is a rolling release. And a rolling release has its drawbacks anyway. Everyone have to be careful because sometimes updates can blow things up. But now and then you have to see if the tools provided will live ok with the updated core parts of the mainline, e.g. pacman has been updated to version 5 recently.

This is why I propose a mechanism to separate all changes that came up with an update to be possibly reside as a xzm "update snapshot". Otherwise you have to always backup your save-file before any mass update, especially those that are more than 6 months old, and set priorities on them.

You have to be especially careful with xorg, glibc, and other core parts. In some cases is wise to disable those before the update or update them separately. If a software depends on new versions of core parts, you have to backup.

LXDE seems ok at the beginning but it looks it can get scrambled. Manjaro has the ability to use its LXDM "Login manager" to select what environment you like. Even a standalone openbox is possible with some RAM and resources gain, if you like. You could add more than one desktop environment there after installing it with the package manager, login manager has to be configured the manjaro way, and then if I remember correctly it will recognize all installed supported environments (xfce, kde etc) and offer them all at login/logout screen.
A standalone openbox with a taskbar only can be good light choice among the main one, as it is a core part of other more feature rich environments, I use it with manjaro openRC successfully and it consumes considerably less ram.

I do not know if this "aporteus" experiment can be used or combined here, without of course disabling the classic pacman which is the core of arch update system.

[istinnjazz]

To use AUR you have to update certificates:

Code: Select all

trust extract-compat

after updating to pacman 5, you can install yaourt or other helpers