Page 1 of 1
SpaceFM
Posted: 13 Aug 2023, 10:03
by rych
I think I'd like the latest spacefm module to use on LXDE (in PorteuX actually) alongside its native PCManFM (which doesn't have folder sizes column -- and I need it; what other light/fast FM has folder sizes column?).
I have a spacefm-1.0.6-x86_64-1salix15.0.xzm built by getmod. Is it the version used in OpenBox Porteus 5.0? Then it might do I suppose, even though its very old and doesn't have an 'alpha' in its name.
There is a more recent fork of it here:
https://github.com/thermitegod/spacefm Could someone build it please for Porteus?
UPDATE. No, the spacefm-1.0.6-x86_64-1salix15.0.xzm didn't work on PorteuX:
Code: Select all
root@porteux:~# spacefm
spacefm: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
SpaceFM
Posted: 13 Aug 2023, 13:57
by Majestic
rych wrote: ↑13 Aug 2023, 10:03
I think I'd like the latest spacefm module to use on LXDE (in PorteuX actually) alongside its native PCManFM (which doesn't have folder sizes column -- and I need it; what other light/fast FM has folder sizes column?).
I have a spacefm-1.0.6-x86_64-1salix15.0.xzm built by getmod. Is it the version used in OpenBox Porteus 5.0? Then it might do I suppose, even though its very old and doesn't have an 'alpha' in its name.
There is a more recent fork of it here:
https://github.com/thermitegod/spacefm Could someone build it please for Porteus?
This version is very unstable and many unnecessary dependencies.
SpaceFM
Posted: 13 Aug 2023, 17:28
by beny
hi Majestic have you build it,if yes how have you solved the zmq.hpp and the other one zmq_addon.hpp header not found...but are installed, and the glibmm version that is needed do not match slackware current version.
SpaceFM
Posted: 14 Aug 2023, 11:14
by Majestic
beny wrote: ↑13 Aug 2023, 17:28
hi Majestic have you build it,if yes how have you solved the zmq.hpp and the other one zmq_addon.hpp header not found...but are installed, and the glibmm version that is needed do not match slackware current version.
I built it without errors in the Arch, in it he works very unstable.
SpaceFM
Posted: 14 Aug 2023, 12:17
by ncmprhnsbl
rych wrote: ↑13 Aug 2023, 10:03
I think I'd like the latest spacefm module to use on LXDE (in PorteuX actually) alongside its native PCManFM (which doesn't have folder sizes column -- and I need it; what other light/fast FM has folder sizes column?).
best you build it yourself for your target system.
here's a
SlackBuild 
for it.
just untar it (& edit the options and tag if you want) and run the SlackBuild, it will download the source and build it for you.
EDIT: activate (the appropriate) 05-devel.xzm first. and you'll also need ffmpegthumbnailer(getpkg) for it's headers/pkgconfig
.
as Majestic says.
it seems to be thermitegod's personal project(there's no issue/bug reporting enabled) under heavy development aimed squarely at a Gentoo environment.
in any case it doesn't have the folder sizes feature you want that's in alpha.
SpaceFM
Posted: 15 Aug 2023, 10:29
by rych
ncmprhnsbl wrote: ↑14 Aug 2023, 12:17
run the SlackBuild, it will download the source and build it for you.
Thanks, but it's not that easy:
Code: Select all
root@porteus:/tmp/spacefm-alpha# ./spacefm-alpha.SlackBuild
...
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/tmp/SBo/spacefm-alpha':
configure: error: C compiler cannot create executables
See `config.log' for more details
I had to activate 05-devel.xzm to make it this far (06-crippled_sources-6.1.1-64bit.xzm also but this doesn't make any difference)
Looks like it can't find a certain "libbfd-2.36.1-slack15.so":
Code: Select all
root@porteus:/tmp/spacefm-alpha# cat /tmp/SBo/spacefm-alpha/config.log
...
gcc version 11.2.0 (GCC)
configure:3893: $? = 0
configure:3882: gcc -V >&5
gcc: error: unrecognized command-line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3893: $? = 1
configure:3882: gcc -qversion >&5
gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:3893: $? = 1
configure:3882: gcc -version >&5
gcc: error: unrecognized command-line option '-version'
gcc: fatal error: no input files
compilation terminated.
configure:3893: $? = 1
configure:3913: checking whether the C compiler works
configure:3935: gcc -O2 -fPIC conftest.c >&5
as: error while loading shared libraries: libbfd-2.36.1-slack15.so: cannot open shared object file: No such file or directory
configure:3939: $? = 1
configure:3979: result: no
...
I have a slightly different /usr/lib64/libbfd-2.37-slack15.so on my system.
Anyway, thanks for trying to teach me to use SlackBuild, but it looks like an additional pain.
Perhaps, it's a chance to fix something I didn't know was wrong on my system, as my gcc indeed can't compile anything with this BFD. I make a main.c and try to compile it as in
https://en.wikipedia.org/wiki/Binary_Fi ... or_library with the same error:
Code: Select all
root@porteus:/tmp# gcc main.c -lbfd -o output
as: error while loading shared libraries: libbfd-2.36.1-slack15.so: cannot open shared object file: No such file or directory
root@porteus:/tmp# cat main.c
#include "bfd.h"
#include <stdio.h>
int main()
{
bfd* abfd = bfd_openr("a.o",NULL);
printf("%llu\n", bfd_get_size(abfd));
return 0;
}
SpaceFM
Posted: 16 Aug 2023, 00:26
by ncmprhnsbl
rych wrote: ↑15 Aug 2023, 10:29
I had to activate 05-devel.xzm
sorry, i made the assumption you would know this

looks like you've activated the wrong 05-devel.xzm, be sure that it matches whatever your base is.
hint: libbfd is part of binutils, which in porteus is split between 001-core and 05-devel. the correct version for slack15 is 2.37
EDIT: and you'll also need ffmpegthumbnailer(getpkg) for it's headers/pkgconfig
SpaceFM
Posted: 16 Aug 2023, 03:23
by Ed_P
ncmprhnsbl wrote: ↑16 Aug 2023, 00:26
05-devel.xzm, be sure that it matches whatever your base is.
How does one know what version their 05-devel.xzm is?
Added in 1 minute 47 seconds:
Code: Select all
~# ls -l /mnt/live/memory/images
000-kernel-6.3.13.xzm : Aug 4 13:54
001-core.xzm : Jun 14 00:42
002-xorg.xzm : Jun 17 01:18
002-xtra.xzm : Dec 11 2022
003-cinnamon.xzm : Sep 25 2022
011-slapt-get-0.11.6-x86_64-2gv.xzm : Oct 29 2022
05-devel.xzm : Feb 8 2022
07-printing-x86_64-2023-02-04.xzm : Feb 4 2023
SpaceFM
Posted: 16 Aug 2023, 05:06
by ncmprhnsbl
rych wrote: ↑13 Aug 2023, 10:03
UPDATE. No, the spacefm-1.0.6-x86_64-1salix15.0.xzm didn't work on PorteuX:
that's because it's built for gtk2. add that and it might work.
try this premade one:
spacefm-alpha-1.06+alpha-x86_64-4_ncm.xzm
it's the build used in porteus-5.0 openbox, should work in porteux-stable , no guarantees.
Ed_P wrote: ↑16 Aug 2023, 03:24
How does one know what version their 05-devel.xzm is?
i would have said: cat /etc/porteus/*
but because of an oversight (now corrected, thanks) in the build script 05-devel missed out on that feature..
for now, a mismatch of versions between binutils-min and binutils-maj is a major red flag (version 2.36 suggests 5.0rc3)
otherwise, if in doubt get the one from the server (if using porteus-v5.0) or the one for whatever from wherever.
SpaceFM
Posted: 16 Aug 2023, 10:12
by rych
ncmprhnsbl wrote: ↑16 Aug 2023, 00:26
looks like you've activated the wrong 05-devel.xzm
Yes, I suspected that. I decided to update my modules and to get the proper, official and up-to-date ones from the server. Including the kernel. Not that it's dictated by 05-devel, but I've had other reasons to fall back to the stock Porteus 5.0 kernel anyway.
SpaceFM
Posted: 20 Aug 2023, 10:40
by rych
ncmprhnsbl wrote: ↑16 Aug 2023, 05:06
try this premade one: spacefm-alpha-1.06+alpha-x86_64-4_ncm.xzm
Yes, that works fine in PorteuX LXDE. Thanks
SpaceFM
Posted: 26 Aug 2023, 23:06
by gomway
SpaceFM
Posted: 31 Aug 2023, 22:58
by Rava
Is this md5sum correct?
Code: Select all
root@porteus:/tmp# md5sum spacefm-alpha-1.06+alpha-x86_64-4_ncm.xzm
1494ea07893a0bd6e15bedffd4d06be1 spacefm-alpha-1.06+alpha-x86_64-4_ncm.xzm
Added in 4 minutes 20 seconds:
I am a bit confused by the version naming of that project.
I have an older download of it (or maybe I created it myself, file date is from 2019, so I don't recall):
spacefm-1.0.6-x86_64-1_slonly.xzm
Is 1.0.6 the same as 1.06 when it comes to spacefm versions?
SpaceFM
Posted: 01 Sep 2023, 04:12
by ncmprhnsbl
Rava wrote: ↑31 Aug 2023, 23:03
Is this md5sum correct?
yep
Rava wrote: ↑31 Aug 2023, 23:03
Is 1.0.6 the same as 1.06 when it comes to spacefm versions?
just a typo from me.. even so the version would be 1.0.6+alpha which means it was built from an unreleased git branch("alpha") that features the 'folder sizes column' , so not the same.
..a note about that feature: nice and handy as it is, it can be resource intensive, with extra disk reading and not entirely accurate eg. a folder with symlinks in it may seem bigger than it actually is.
on the plus side it's easy to enable/disable. (rclickmenu>view>style>folder sizes)
SpaceFM
Posted: 01 Sep 2023, 17:07
by Rava
ncmprhnsbl wrote: ↑01 Sep 2023, 04:12
it can be resource intensive
If that's so, then I think I pass.
When searching for where the most data is stored on a certain drive I prefer Baobab-DiskUsage - is is extremely small as a module, and it is resource-easy.
Of course it still needs to read the whole of the certain drive, but how else could any program display its folders and sub-folders used-sizes?