SpaceFM

[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

[Majestic]

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.

[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.

[Majestic]

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.

[ncmprhnsbl]

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
.

There is a more recent fork of it here: https://github.com/thermitegod/spacefm Could someone build it please for Porteus?

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.

[rych]

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;
}

[ncmprhnsbl]

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

[Ed_P]

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

[ncmprhnsbl]

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.

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.

[rych]

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.

[rych]

try this premade one: spacefm-alpha-1.06+alpha-x86_64-4_ncm.xzm

Yes, that works fine in PorteuX LXDE. Thanks

[gomway]

spacefm_1.0.6-5_amd64(latest): https://www.mediafire.com/file/hrxt6mq ... 4.xzm/file

[Rava]

try this premade one: spacefm-alpha-1.06+alpha-x86_64-4_ncm.xzm

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?

[ncmprhnsbl]

Is this md5sum correct?

yep

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)

[Rava]

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?