Page 15 of 17
Porteus-v4.0 bug reports
Posted: 10 Dec 2020, 03:00
by ncmprhnsbl
Rava wrote: ↑07 Dec 2020, 13:32
Could I try using the working 3.1 Kernel and its initrd to boot 4.0 i586?
there is no "its initrd" specific to a kernel... there's just vmlinuz(the kernel) and 000-kernel.xzm(it's modules)
mixing initrds from different porteus versions serves no purpose and is only likely to cause a problem..
Porteus-v4.0 bug reports
Posted: 10 Dec 2020, 03:25
by Rava
ncmprhnsbl wrote: ↑10 Dec 2020, 03:00
Rava wrote: ↑07 Dec 2020, 13:32
Could I try using the working 3.1 Kernel and its initrd to boot 4.0 i586?
there is no "its initrd" specific to a kernel... there's just vmlinuz(the kernel) and 001-kernel.xzm(it's modules)
mixing initrds from different porteus versions serves no purpose and is only likely to cause a problem..
okay then…
So the colourful crash
Rava wrote: ↑09 Dec 2020, 13:06
is only the kernel I presume?
Then I change my line or lines in the porteus.cfg to boot the 3.1 kernel and 3.1
000-kernel.xzm (the 00
1 file is the
001-core.xzm) and look if that alone is the solution to the errors.
Since I do need to start 3.1 anyway I can also copy /etc/bootcmd.cfg + /etc/profile.d/porteus.sh
Porteus-v4.0 bug reports
Posted: 12 Dec 2020, 20:30
by Rava
In the end it was simple:
use 4.0 initrd, boot 3.1 kernel, deactivate init 3 - text mode in 4.0 cfg file and 4.0 started. Yay.
But now… too tired to try getting florence to run... but tomorrow is also a day.
Porteus-v4.0 bug reports
Posted: 18 Jan 2021, 20:37
by Rava
Porteus-v4.0 i586 XFCE
Unfortunately, even when its mentioned in .bashrc
Code: Select all
# Fix bug in ncurses that affects xterm.
# From the slackware changelog
#l/ncurses-6.1_20180324-x86_64-4.txz: Rebuilt.
# Change the xterm entry in xterm.terminfo (way down at the bottom, where it
# says "customization begins here" and that we may need to change the xterm
# entry since it is used "for a variety of incompatible terminal emulations")
# to drop the use of use=rep+ansi. In addition to causing Konsole breakage, I
# have verification that rep= was causing problems with terminals connecting
# from OSX. Only the xterm entry has changed. Previously this was an alias for
# xterm-new, which has not been altered. Feel free to use xterm-new instead if
# it suits your needs better.
#
# This change broke mc arrow buttons.
alias mcedit='TERM=xterm-new mcedit'
the mc arrow buttons are all broken.
What please is the fix?
Porteus-v4.0 bug reports
Posted: 03 Feb 2021, 09:25
by Rava
Since redshift-1.11-i586-2_slonly.txz is the only and newest version of redshift USM would offer, I tried converting redshift-1.12-7.1.i586.rpm but it failed:
Code: Select all
root@porteus:/Porteus_modules/guest# rpm2xzm redshift-1.12-7.1.i586.rpm
ERROR: rpm2cpio failed. (maybe redshift-1.12-7.1.i586.rpm is not an RPM?)
Cannot install /tmp/rpm2xzm11222/redshift-1.12-7.1.i586.txz: file not found
error installing /tmp/rpm2xzm11222/redshift-1.12-7.1.i586.txz package
mv: cannot stat 'redshift-1.12-7.1.i586.xzm': No such file or directory
root@porteus:/Porteus_modules/guest# file redshift-1.12-7.1.i586.rpm
redshift-1.12-7.1.i586.rpm: RPM v3.0 bin i386/x86_64
mc can open the rpm but shows only files with zero length, and Engrampa cannot open it either and only shows this unspecific error:
Code: Select all
(engrampa:11624): Gtk-WARNING **: 10:21:07.997: Allocating size to GtkScrolledWindow 0x8efe640 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Could it be that V3 of an rpm is beyond what standard 4.0 i586 of Porteus can handle?
Any ideas what I could do? The Port 4,0 i586 machine is the only one I have access to right now.
Porteus-v4.0 bug reports
Posted: 03 Feb 2021, 21:36
by donald
@Rava
I've read they changed the compression format.
Unpacking the rpm [p7zip GUI] gives a redshift-1.12-7.1.i586.cpio.zstd file.
zstd was not on my system [3.2.2], but there is a zstd-1.3.0-i586-1_slonly.txz
Porteus-v4.0 bug reports
Posted: 03 Feb 2021, 22:03
by Rava
^
Thanks for the info.
I created a zstd-1.3.0-i586-1_slonly.xzm but even when activated I still get the same error:
Code: Select all
# rpm2xzm redshift-1.12-7.1.i586.rpm
ERROR: rpm2cpio failed. (maybe redshift-1.12-7.1.i586.rpm is not an RPM?)
Cannot install /tmp/rpm2xzm19387/redshift-1.12-7.1.i586.txz: file not found
error installing /tmp/rpm2xzm19387/redshift-1.12-7.1.i586.txz package
mv: cannot stat 'redshift-1.12-7.1.i586.xzm': No such file or directory
Seems, just adding zstd was not the solution.
Me thinks I will have to stick with redshift-1.11-i586-2_slonly.txz - and no GUI .
I installed the needed library:
Code: Select all
# deb2xzm redshift-gtk_1.12-4_all.deb
Checking required libraries ...
#############################
# Missing library #
#############################
You are missing libbfd. Please
activate 05_devel or run the
command: getpkg binutils
and installpkg the file.
I have the library installed:
Code: Select all
-rwxr-xr-x 1 root 1317260 2016-03-07 21:43 /usr/lib/libbfd-2.26.20160125.so
lrwxrwxrwx 1 root 23 2021-02-03 11:46 /usr/lib/libbfd-2.26.so -> libbfd-2.26.20160125.so
lrwxrwxrwx 1 root 23 2021-02-03 11:47 /usr/lib/libbfd-2.so -> libbfd-2.26.20160125.so
-rw-r--r-- 1 root 1389724 2016-03-07 21:43 /usr/lib/libbfd.a
-rwxr-xr-x 1 root 1041 2016-03-07 21:43 /usr/lib/libbfd.la
lrwxrwxrwx 1 root 23 2021-02-03 11:30 /usr/lib/libbfd.so -> libbfd-2.26.20160125.so
I manually added libbfd-2.26.so and libbfd-2.so symlinks in the hope that would solve the issue, but nope.
How come deb2xzm insists I need a lib when I already installed the lib?
Porteus-v4.0 bug reports
Posted: 03 Feb 2021, 22:41
by donald
Rava wrote: ↑03 Feb 2021, 22:03
^
Thanks for the info.
I created a zstd-1.3.0-i586-1_slonly.xzm but even when activated I still get the same error:
Yep, scripts [rpm2xzm] do not work. but you can try to build your module by hand.
if you have the redshift-1.12-7.1.i586.cpio.zstd file + zstd, uncompress it:
zstd -d <file> (you may have to shorten the suffix to zst)
now you have a *cpio file which can be extracted to get the content.
[even with engrampa]
You can go from there to build the module.
Porteus-v4.0 bug reports
Posted: 03 Feb 2021, 22:49
by beny
hi rava:
redshift (screen colour adjuster)
Redshift adjusts the colour temperature of your screen according to
your surroundings. This may help your eyes if you are working in front
of the screen at night.
This package has a dependency on geoclue2, however it will compile the
package without it if geoclue2 is not present.
This package will build against python3 for the gui if python3 is
available. If not, we use the fedora patch to build the gui with
python2. If you want to compile using python3 on 14.2, you will need
the pyxdg and pygobject3-python3 packages from SBo.
maybe help you this is the readme on slackbuild.
Porteus-v4.0 bug reports
Posted: 04 Feb 2021, 06:15
by Rava
Prior reading donalds post above I created the module using the redshift-1.8-i586-2_slonly.txz. It has no GUI, but it is nice and slim (92 kB as xzm), and works without any dependency issues out of the box. (running 4,0 i586 XFCE - other DEs could have some stuff missing)
Only issue: you would have to give it your longitude and latitude, but you can force a colour by using -O like so:
Code: Select all
redshift -O 4200K # good for beginning
redshift -O 3700K # more red, maybe too red for initial settings - redshift's night-time colour
Porteus-v4.0 bug reports
Posted: 06 Feb 2021, 14:30
by Rava
Back to redshift: putting the needed command e.g.
into /etc/rc.d/rc.local not works, since at the time of executing /etc/rc.d/rc.local XWindows is not yet started.
But for some weird reason putting
not works, either.
When executing the same command with 3700K as parameter the colour change shows that the guiexec from the kernel command was not performed.
Would it have to be e.g.
Code: Select all
guiexec=uxterm~-e~redshift~-O~3700K
instead?
Porteus-v4.0 bug reports
Posted: 06 Feb 2021, 15:35
by martomlub
I have openbox 4.0 and for some reason my spacefm desktop does not start.
It looks like this:
guest@porteus:~$ spacefm --desktop
special mount changed: gvfsd-fuse (0:23) on /tmp/xdg-runtime-guest/gvfs
Segmentation fault
guest@porteus:~$ killall spacefm
spacefm: no process found
guest@porteus:~$
Could someone please help me fix this?
I cannot paste quotes from the terminal, sory about this.
Porteus-v4.0 bug reports
Posted: 06 Feb 2021, 18:54
by Rava
martomlub wrote: ↑06 Feb 2021, 15:35
guest@porteus:~$ spacefm --desktop
special mount changed: gvfsd-fuse (0:23) on /tmp/xdg-runtime-guest/gvfs
Segmentation fault
A segmentation fault is a severe error. Did it work in the past?
When I get an segfault the only way to get a program to run is either reboot (when the program ran before) or one has to find a different version of the program.
Try updating spacefm to a newer or older version than the one you have installed.
The version should be reflected in the file name in var/log/packages
Example trying to get the version of mousepad when mousepad itself would give a segfault - running 4.0 XFCE:
Code: Select all
guest@porteus:~$ cd /mnt/live/memory/images
guest@porteus:/mnt/live/memory/images$ find . 2>/dev/null|grep var/log/packages/mousepad
./003-xfce.xzm/var/log/packages/mousepad-0.4.0-i586-1_slonly
You only need the 2>/dev/null when running it as guest, when you are root you not get any
Code: Select all
find: `./whatever.xzm/var/log/setup/tmp': Permission denied
errors.
Sorry I could not help you and further than that.
Porteus-v4.0 bug reports
Posted: 06 Feb 2021, 23:51
by ncmprhnsbl
martomlub wrote: ↑06 Feb 2021, 15:35
I have openbox 4.0 and for some reason my spacefm desktop does not start.
first thing is to try in "always fresh" (no changes, rootcopy, extra modules) to see if something added/changed is the problem..
Porteus-v4.0 bug reports
Posted: 07 Feb 2021, 10:21
by martomlub
After running in "alwais fresh" mode everything is OK, so I ran "changes" from a few days ago and it's OK.
From this I can see that it was my fault, I exaggerated with improvements.
Thank you for your help.