ScPup & ScPup64 - Slackware Current based Woof-CE pups

[6502coder]

I tested Oscar's gpicview-0.2.5-i686-scpup-gif-fix.pet in a second LiveCD test of the 32-bit "+6". I just unpacked the PET and grabbed the executable, then tried it on the same suite of pix I used on my previous LiveCD test. Looks OK to me. I tried all the buttons: rotating images, different zooms, save as, etc. No problems to report.

[peebee]

This is a long standing bug from 2016 that hasn't been fixed:
https://sourceforge.net/p/lxde/bugs/814/

@Radky in a pm says:

Early in the development of Dpup Stretch, to support viewing of animated GIFs, I compiled gpicview from source using the following patch:

https://bbs.archlinux.org/viewtopic.php ... 3#p1520553

and has sent a pet but it does indeed need libjpeg.so.8 ....

[peebee]

I compiled Viewnior 1.6 in ScPup32

Viewnior 1.7 is available and works from ArchLinux and ArchLinux32:

https://mirror.archlinux32.org/i686/com ... pkg.tar.xz

The gif I'm using to test:

[OscarTalks]

Yes, Viewnior 1.7 is better than 1.6 but you can't build it with autotools.

Building requires the meson build system:-
Install python 3 (3.5 or later, I used 3.7.3)
Install ninja
Install meson
Compile Viewnior 1.7

I have done this in ScPup32 and it works. Those build dependencies are not required to run it once built.

[Wiz57]

OscarTalks--I grabbed the 32 bit gpicview pet you uploaded, will test later tonight. Also may grab peebee's updated palemoon sfs, just to have on hand. Been busy this week manufacturing parts for oilfield, and some little tiny sleeves for an audio company. I'm running a couple of Brown and Sharpe screw machines at a local machine shop, been cutting steel quite a bit of late, both 303 stainless and "tool steel". That's been keeping me a tad busy, which is good! I kind of like paychecks!

ps...bandied about with OscarTalks gpicview 32bit, no issues, and animations working as expected on the few ani-GIFs I have. Looks good to go!


pps...peebee, I tried to download the updated palemoon sfs, and wget quit with error the checksums did not match! This was using the "Internet/Get web browser" button in the menu!

Wiz

[peebee]

19.04 versions of ScPup and ScPup64 are available - see post #1 & #2

Kernels remain the same.

32-bit 19.04+0 with md5 3a5da8e81f24a8f51ae06b0769db8626
and
64-bit 19.04+0 with md5 dc7575e9512bd79576932aa60e0e392d
become the new bases for delta updates.

Deltas from 19.01+0 to 19.04+0:
https://sourceforge.net/projects/spup/f ... a/download
to create
3a5da8e81f24a8f51ae06b0769db8626 ScPup-19.04+0-uefi-T.iso

https://sourceforge.net/projects/spup/f ... a/download
to create
dc7575e9512bd79576932aa60e0e392d ScPup64-19.04+0-uefi-T.iso

[Terry H]

Upgraded scpup64 19.01+0 iso to 19.04+0 using delta file. I then manually replaced the 19.01 +6 installation on Data Traveller USB 3 Flash drive, and chose to upgrade the existing Save Folder (which I have backed up).

All good. Thanks peebee

Code: Select all

# inxi -Fxz
System:    Host: puppypc1956 Kernel: 4.19.13-lxpup64 x86_64 (64 bit gcc: 8.2.0)
           Desktop: JWM 2.3.6 Distro: ScPup64 19.04
Machine:   Device: laptop System: Dell product: Latitude 3350
           Mobo: Dell model: 0TMD22 v: X02
           UEFI [Legacy]: Dell v: A09 date: 11/24/2016
Battery    BAT0: charge: 45.3 Wh 100.0% condition: 45.3/59.0 Wh (77%)
           model: Samsung SDI DELL 6C0FN58 status: Full
CPU:       Dual core Intel Core i5-5200U (-HT-MCP-) cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 8783
           clock speeds: max: 2700 MHz 1: 1786 MHz 2: 1764 MHz 3: 1227 MHz
           4: 1924 MHz
Graphics:  Card: Intel HD Graphics 5500 bus-ID: 00:02.0
           Display Server: X.org 1.20.4 drivers: intel (unloaded: modesetting,vesa) FAILED: fbdev
           tty size: 80x24 Advanced Data: N/A for root
Audio:     Card-1 Intel Wildcat Point-LP High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Card-2 Intel Broadwell-U Audio Controller
           driver: snd_hda_intel bus-ID: 00:03.0
           Sound: Advanced Linux Sound Architecture v: k4.19.13-lxpup64
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169 port: e000 bus-ID: 03:00.0
           IF: eth0 state: down mac: <filter>
           Card-2: Intel Wireless 7265 driver: iwlwifi bus-ID: 04:00.0
           IF: wlan0 state: up mac: <filter>
Drives:    HDD Total Size: 264.1GB (6.1% used)
           ID-1: /dev/sda model: Crucial_CT256MX1 size: 256.1GB
           ID-2: /dev/sdb model: DataTraveler_3.0 size: 8.0GB
           ID-1: swap-1 size: 10.49GB used: 0.00GB (0%) fs: swap dev: /dev/sda4
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 135 Uptime: 46 min Memory: 484.2/7609.2MB
           Init: SysVinit runlevel: 5 Gcc sys: N/A
           Client: Shell (bash 5.0.31) inxi: 2.3.8 
# 

[Wiz57]

Downloaded, extracted the new ScPup 19.04+0 32 bit ISO, upgraded the save file upon bootup, and here I am. No problems noted as of yet, noticed the new desktop icon for mounted drives...nice touch, much easier to distinguish between mounted and unmounted drives now!
Thank you peebee!

[OscarTalks]

Now testing both 32bit and 64bit ScPup 19.04+0
Here is the 64bit version of Viewnior 1.7
Compiled using python 3.7.3 with meson and ninja

[ozsouth]

Loving my new 19.01+5 remaster.
.

[OscarTalks]

One observation, I don't have a solution to offer as yet.
When compiling in ScPup32 19.04+0
Running new2dir make install
The shared library symlinks are installed in system as normal, BUT
These symlinks are NOT written into the new directory (which would normally be used to create a .pet or .sfs package).

So for example, libwhatever.so.1.2.3 is in the new directory, but the usual symlinks libwhatever.so.1 (run-time) and libwhatever.so (development) are not present in the new directory. I have to create them manually before creating a .pet package otherwise the .pet is (obviously) no good.

[ozsouth]

Further to long (30 sec) pause in bootup (at ... optical input message) - culprit is /etc/profile LANG setting, when using AU instead of US. Get normal speed if .UTF-8 omitted, but that causes other problems. No issue in Slacko64 or Bionic64, & is fine on subsequent boot after savefolder made.

[peebee]

32-bit
9985f8a5c3fbb6cdffac9147afbb804f ScPup-19.04+2-uefi-T.iso

{delta update} - must be applied to the base 3a5da8e81f24a8f51ae06b0769db8626 ScPup-19.04+0-uefi-T.iso

Updates are cumulative - only the most recent needs to be applied.

======================
64 bit
b7b1f81079000d5fcca558326b74c236 ScPup64-19.04+2-uefi-T.iso

{delta update} - must be applied to the base dc7575e9512bd79576932aa60e0e392d ScPup64-19.04+0-uefi-T.iso

Updates are cumulative - only the most recent needs to be applied.

[watchdog]

Mplayer was not working for me as for disco dingo, neither pavrecord video preview. I have compiled MPlayer 1.4 for my architecture (kernel headers were needed) and now both are working. Why has one to compile mplayer for different cpu architectures? In the readme file of source mplayer I read:

MPlayer has builtin support for the most common audio and video formats. For a
few formats no native decoder exists and external binary codecs are required
to handle them. Examples are newer RealVideo variants and a variety of rare
formats. However, binary codecs are NOT required in this day and age, they are
strictly optional.

Please note that binary codecs only work on the processor architecture they
were compiled for. Choose the correct package for your processor. No other
package is necessary.

Are the codecs compiled with mplayer?

[OscarTalks]

Confirmed in ScPup32 19.04+2

Code: Select all

# mplayer /mnt/sda2/Part-1.mp4
MPlayer 1.4-8.3.0 (C) 2000-2019 MPlayer Team

Playing /mnt/sda2/Part-1.mp4.


MPlayer interrupted by signal 4 in module: demux_open
- MPlayer crashed by an 'Illegal Instruction'.
  It usually happens when you run it on a CPU different than the one it was
  compiled/optimized for.
  Verify this!
- MPlayer crashed by bad usage of CPU/FPU/RAM.
  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.
#

The binary codecs are not likely to be needed for anything most people would come across these days and leaving them out would certainly not cause MPlayer to fail to run.

At compile time you can define the path to them with --codecsdir=/usr/lib/codecs (which seems to be the location in earlier Puppies). Maybe --codecsdir=/usr/lib/mplayer/codecs would be better for clarity if you still want to include them.

There is also the configure option --enable-runtime-cpudetection which may be on by default but it is perhaps worth including just to be sure.

[watchdog]

I put in /etc/X11/xorg.conf.d the radky's 20-intel.conf forcing "uxa" accel method for palemoon to work. But I do not think this is the culprit after OscarTalks' previous post confirming the mplayer bug.

[peebee]

I used the petbuild:
https://github.com/puppylinux-woof-CE/p ... r.petbuild

Code: Select all

# MPlayer
# Builds from https://github.com/puppylinux-woof-CE/petbuilds

. ../func
. ../build.conf

URL=http://www.mplayerhq.hu/MPlayer/releases
PKG=MPlayer
VER=1.4
COMP=tar.xz
DESC="Media player for audio and video"
DEPS=+ffmpeg
CAT=Multimedia
DESKTOP=MPlayer.desktop
BUILD=
CWD=$(pwd)
[ -z "$MWD" ] && MWD=$(dirname $CWD)	
[ -z "$BUILD" ] && BUILD=$DEF_BUILD
[ -f "$DESKTOP" ] || DESKTOP=not
[ -z "$DEPS" ] && DEPS=not	

ARCH=$(uname -m)
case $ARCH in
 *64) 	LIBDIR=$LIBCONF64 ;;
 arm*)	LIBDIR=$LIBCONFarm;;
 *) 	LIBDIR=$LIBCONF32 ;;
esac

build() {
	cd ${PKG}-${VER}
	./configure --prefix=/usr \
		--disable-runtime-cpudetection \
		--confdir=/etc \
		--disable-smb \
		--disable-mencoder
	[ "$?" -eq 0 ] || exit
	
	make $MKFLG
	[ "$?" -eq 0 ] || exit
	make DESTDIR=$CWD/${PKG}-install install
	cd -
}
	
# main
retrieve ${PKG}-${VER}.${COMP}
extract ${PKG}-${VER}.${COMP}
build
package_std $PKG $VER $ARCH $DESKTOP "$DESC" $DEPS $CAT	

[OscarTalks]

I would suggest to try changing --disable-runtime-cpudetection to --enable-runtime-cpudetection

Seems that [disabled] is the default but I always build with this enabled.
This issue cropped up in a Slacko (5.x) a few years back and we decided that we should enable this feature. Not sure why the petbuild has it different.

[peebee]

We need to amend the petbuild if your suggestion helps...I'll build some new pets and upload them for testing as I'm not able to....

The MPlayer module in woof-ce resulting from the petbuild has no libs at all - so either the binary contains static libs or the ffmpeg libs are being used.

I can't get the problem on my desktop (Xeon) or my laptop (Celereon) where test mp4s play with no problem on both....as does pavrecord video preview....

What processors do you both have??

Do you get the problem on both ScPup32 and ScPup64??

[OscarTalks]

I haven't tested 64bit yet. EDIT - Have now - seems OK
That is on a different machine in another room.
CPU on this machine is Pentium Dual-Core.
I recall discussing this with 01micko and we found that --enable-runtime-cpudetection makes the executable much more portable.
I am no expert, but would suggest amending the petbuild.

Modern day MPlayer links statically against ffmpeg, allowing for builds to always contain latest trunk snapshot (that is the idea anyway). Snapshots of trunk of MPlayer will download and use a trunk snapshot of ffmpeg at build time and use that. The release tarball (eg 1.4) of MPlayer contains a snapshot of ffmpeg master from the time of release, which it is known to be compatible with. If you want MPlayer to use system ffmpeg you can (I believe) configure for that and produce a smaller executable which will of course dynamically link. This might make sense, since ffmpeg libs are very recent, but it is personal choice.

QUICK UPDATE:-
ScPup64 19.04+2
MPlayer seems OK on the 64bit version, different machine though.
CPU is Intel Core i5 - 2500 with 4 cores