slacko-700 rc3

[radky]

Re: testing slacko-6.9.9.9-k3.16-4G-FF-ABI

The following scenario is reproducible:

1 - With ROX-Filer, click-mount any sfs and choose 'view contents'
2 - Go to Nathan's wallpaper setter to change background
3 - At this point, Rox creates a second pinboard (/root/.config/rox.sourceforge.net/ROX-Filer/pb_Default) and clicking the desktop will alternate between the original pinboard and this new pb_Default pinboard.
4 - Restarting X is required to reclaim the normal pinboard
5 - No problem with the ROX pinboard in current iterations of tahrpup or tahrpup64

[bigpup]

Wifi issue.

Something to think about while I continue to try ideas.

For now I am only testing 32bit version of Slacko.

I am still testing ideas and trying different things.

Note:
This seems to be common to every version of Slacko 6.9.9.9 32bit.
I wonder if this has something to do with loading all the sfs layers when it boots.
Maybe timing issue.
Something that is in one sfs, needing something that is in another sfs, and whatever not getting loaded at the time it needs to.

This is what I see:

ininitial boot of a frugal install of Slacko 6.9.9.9 32bit.
Setup wifi network connection.
Seems to work OK.
No problems.

Make a save.

Reboot using the save and Wifi starts having problems.
Slow and cuts off and on.

Using the save is just one more layer added to the layered filesystem.
This seems to cause the wifi problem to start happening.

Any ideas

Example:
I am posting this from an initial boot of Slacko 6.9.9.9 32bit K4.4.70
Have not made a save.
Wifi is working OK, no problems.

[prehistoric]

Re: testing slacko-6.9.9.9-k3.16-4G-FF-ABI

The following scenario is reproducible:

1 - With ROX-Filer, click-mount any sfs and choose 'view contents'
2 - Go to Nathan's wallpaper setter to change background
3 - At this point, Rox creates a second pinboard (/root/.config/rox.sourceforge.net/ROX-Filer/pb_Default) and clicking the desktop will alternate between the original pinboard and this new pb_Default pinboard.
4 - Restarting X is required to reclaim the normal pinboard
5 - No problem with the ROX pinboard in current iterations of tahrpup or tahrpup64

This is exactly what happened in an earlier test of mine. I stopped chasing that bug because the Wifi bug was crippling operation.

I've long wanted to rewrite the Nathan wallpaper setter for a different reason, but now see that I am never going to regain the ability to deal with convoluted code.

The problem which originally bothered me was the discovery that Nathan made a copy of the background file which was renamed "original", and then modified the true original to fit the screen. This raised a red flag because many people will use the tool to add photos from a flash drive rather than copy them to /usr/share/backgrounds. You don't want to deal with a photographer who has just had a large and irreplaceable photo resized to 1024x768. The wallpaper setter should only modify pictures in a private directory where people are unlikely to place images they want to keep.

Aside: my problem with browsers above was less about lightweight browsers like dillo than about indicators of activity while waiting for big programs to start on slow machines. I couldn't tell whether or not I had actually launched a browser, and more than once launched a second instance. Another solution would be to quickly launch a placeholder that would be on the screen until the real program came up and replaced it.

The way the Internet is changing, I doubt that any lightweight browser will function properly on a large percentage of popular sites. With current phone and tablet designs all past the limitation to 1 GB of RAM I doubt there is any way back. This is ominous for other reasons. I doubt that any program as large as 1 MB has ever been completely debugged. Programs using 1 GB are at least 1,000 times less likely to be debugged, and this is without mention of malicious use of those programs.

Here's an example of just how ridiculous a Turing-complete language can be, and it doesn't even include Word or Excel macros. Customization features probably make many large programs Turing-complete, which means they could do anything. Consider this when you think about which code you can trust.

[Sailor Enceladus]

@bigpup: I might have missed this, but does Slacko 6.9.9.8 or 6.9.9.6 work normally, or 6.9.6.7?

The problem which originally bothered me was the discovery that Nathan made a copy of the background file which was renamed "original", and then modified the true original to fit the screen. This raised a red flag because many people will use the tool to add photos from a flash drive rather than copy them to /usr/share/backgrounds. You don't want to deal with a photographer who has just had a large and irreplaceable photo resized to 1024x768. The wallpaper setter should only modify pictures in a private directory where people are unlikely to place images they want to keep.

I agree. A better solution might be to rename the stretched/scaled/altered image to something new, like default.[extension].

Aside: my problem with browsers above was less about lightweight browsers like dillo than about indicators of activity while waiting for big programs to start on slow machines. I couldn't tell whether or not I had actually launched a browser, and more than once launched a second instance. Another solution would be to quickly launch a placeholder that would be on the screen until the real program came up and replaced it.

Agree here too, big browsers should have a message ("Opening Firefox...") to let you know what's going on. I don't think I've used any computer where Firefox, IE, Chrome opened instantly the first time. I blame big browser devs for this oversight.

[rcrsn51]

@bigpup: Is your WiFi problem with the actual WiFi connection or with a browser running over WiFi?

Here is a quick WiFi speed test:

Code: Select all

ping -I wlan0 -c 20 192.168.2.1

Use the IP address of your router. Check the summary at the end.

If would be useful if you had a separate USB WiFi adapter that you could test for comparison purposes.

[Sailor Enceladus]

Tried another 14.2 woof-CE build (commit 5380). The Firefox-52.2.0 is actually 4.5MB smaller than Firefox-52.1.2
It looks like it's because the Slackware team used --enable-optimize=-O1 instead of --enable-optimize=-O2 this time.

norgo might be happy to see that the upper rim of the wallpaper is finally working now
http://www.murga-linux.com/puppy/viewto ... 167#943167

[Hesse James]

Hello
A short feedback of my experiences with 64 bit only:
Computer 1: Skylake processor, Z270 Chipset
Computer 2: Pentium E6300 processor, Nvidia Nforce 730i (9300 compatible)

Computer 1 boots to the desktop with full network support only with kernel 4.9. No network support with kernel 3.1 (as expected), blackscreen during kernel modules loading with kernel 4.4 (same as with all other RC's).

Computer 2 boots successfully all versions with network support. Nvidia 64 bit legacy driver installation possible.
http://www.mediafire.com/file/727aiq2ul ... acko64.sfs

I used woofy to search for missing libs in the ISO (K4.9):

• File /usr/bin/alsabat has these missing library files:
  libfftw3.so.3
  File /usr/bin/gsx has these missing library files:
  libgdk-3.so.0 libgtk-3.so.0
  File /usr/bin/poppler-glib-demo has these missing library files:
  libgdk-3.so.0 libgtk-3.so.0
  File /usr/bin/qv4l2 has these missing library files:
  libQtCore.so.4 libQtGui.so.4 libQtOpenGL.so.4
  File /usr/lib64/libpoppler-qt4.so.4.9.0 has these missing library files:
  libQtCore.so.4 libQtXml.so.4 libQtGui.so.4
  File /usr/lib64/xmms/Input/libxmms-flac.so has these missing library files:
  libxmms.so.1 libglib-1.2.so.0 libgmodule-1.2.so.0 libgdk-1.2.so.0 libgtk-1.2.so.0
  File /usr/lib64/ao/plugins-4/libpulse.so has these missing library files:
  libpulse.so.0 libpulse-simple.so.0
  File /usr/lib64/gimp/2.0/plug-ins/gutenprint has these missing library files:
  libgimpbase-2.0.so.0 libgimpcolor-2.0.so.0 libgimpmath-2.0.so.0 libgimpconfig-2.0.so.0 libgimp-2.0.so.0 libgimpmodule-2.0.so.0 libgimpwidgets-2.0.so.0 libgimpui-2.0.so.0
  File /usr/libexec/gcc/x86_64-slackware-linux/5.3.0/cc1 has these missing library files:
  libmpc.so.3
  File /usr/libexec/gcc/x86_64-slackware-linux/5.3.0/lto1 has these missing library files:
  libmpc.so.3
  File /usr/libexec/gcc/x86_64-slackware-linux/5.3.0/cc1plus has these missing library files:
  libmpc.so.3
  File /usr/lib/polkit-1/polkitd has these missing library files:
  libmozjs185.so.1.0
  Firefox misses also a couple of libs...

I verified this list with ldd.

Good luck with the release.

Christian

[prehistoric]

Just want to say that the fix for WiFi problems is still working on that battered D600 running the 32-bit version of Slacko 6.9.9.9. It even connects automatically when I boot, which hasn't always worked on other systems in the past. This one is good to go!

[radky]

Re: Additional testing of the Rox pinboard bug in recent Woof-CE Pups

1 - With ROX-Filer, click-mount any sfs and choose 'view contents'
2 - Go to Nathan's wallpaper setter to change background
3 - At this point, Rox creates a second pinboard (/root/.config/rox.sourceforge.net/ROX-Filer/pb_Default)
4 - Clicking the desktop will alternate between the original pinboard and this new pb_Default pinboard
5 - Restarting X is required to reclaim the normal pinboard

It seems the Rox pinboard bug was introduced in Woof-CE Pups in late 2016 or early 2017.

slacko-6.3.2 (released 21-Jun-2016): OK
slacko-6.9.6.4 (released 08-Oct-2016): OK
slacko-6.9.9.x (released May/June 2017): Pinboard bug

tahrpup-6.0.5 (released 20-Dec-2016): OK
tahrpup-6.0.6 (released 07-Feb-2017): Pinboard bug

[bigpup]

@bigpup: Is your WiFi problem with the actual WiFi connection or with a browser running over WiFi?

Not so sure. I am only testing by running a browser and trying to use it.

Here is a quick WiFi speed test:

Code: Select all

ping -I wlan0 -c 20 192.168.2.1

Use the IP address of your router. Check the summary at the end.

I am not totally sure what this should show me, but it seems to give good results.

If would be useful if you had a separate USB WiFi adapter that you could test for comparison purposes.

I have already tried that.
It seemed to have the same problems.

With my luck, the ISP I am using, could be cutting off and on, just when I am trying to troubleshoot this.
However, I think I ruled this out by going to booting computer (using different Puppy version) and it working no problems.

[rcrsn51]

Does the ping test give the same speed with/without a savefile?

[bigpup]

Wifi Issue.
Slacko 6.9.9.9 32bit K4.4.70

The save and using it seems to be at the base of this issue.

I notice when doing a boot up.
The info about loading the different SFS packages, main SFS, adrv, fdrv, zdrv, and the save.

Before the save is loaded a message comes up that it is loading kernel driver modules hid.

I think this is the one it is talking about:
lib/modules/4.4.70/kernel/drivers/hid/i2c-hid/i2c-hid.ko

Is this suppose to be happening and if so, is it the correct process just before the save loads?

[bigpup]

Does the ping test give the same speed with/without a savefile?

I will try it and see.

Update:
It is faster when not using a save.

When using a save.
One time the test stopped after 5 passes.
The next time it did all 20 and the results were not that bad, but still slower than when not using a save.

[bigpup]

Wifi issue.

I tried something that watchdog suggested in a PM.

I initially booted. Did wifi setup. shutdown making a save.

I used a different Puppy to access the save.
Removed all the wifi config info in the save.

Booted using this save.
Configured wifi setup.

For what ever reason this save is not that bad.
Wifi is working most of the time and only gets slower at times, but does not cut off.

Make any sense to anyone?


If I am the only one really seeing this wifi issue.
I can see it being my hardware and Slacko just do not like each other.

Are we having fun yet!!

[01micko]

bump!

@bigpup - you can actually try the 64 bit k4.9.30 in 32 bit on your box - if nothing else it will tell us it might work better - or not! If it does work then I can compile 4.9.3x for 32 bit and probably ditch the palemoon isos and use firefox. I doubt firmware will make a difference because the kernel-kit build script has an option to get latest firmware which I always use. Also, there probably exists a manufacturer driver on github - I have an rtl8192eu dongle that has no in kernel tree driver and I just built it for 64 bit, posting from it now.

Anyway .. I have built k4.9.33 for 32 bit.. not uploaded yet as I've had no time! I have also found a github repo by lwfinger (noted linux wireless dev) that replaces (almost) the whole rtl* driver stack! See https://github.com/lwfinger/rtlwifi_new

Anyone can build it themselves if they load devx and kernel_source from sfs-manager (in setup menu).

Code: Select all

git clone https://github.com/lwfinger/rtlwifi_new
cd rtlwifi_new
make
make install

Reboot and see what happens. I can't test as I haven't the compatible hardware.

------------------------------------

It seems the Rox pinboard bug was introduced in Woof-CE Pups in late 2016 or early 2017.

An even more amusing way to reproduce this is like so...

Code: Select all

# rox -p=
# rox -p=~/Choices/ROX-Filer/PuppyPin 
# rox -p ~/Choices/ROX-Filer/PuppyPin 
# rox -p=~/Choices/ROX-Filer/PuppyPin 
# rox -p ~/Choices/ROX-Filer/PuppyPin 

Last command restores the original...

So it seems the 'p=' syntax is a bug. I'll fix it in due course.

Thanks for making me think .

[Sailor Enceladus]

Thanks radky. Now I have a consistent way of triggering the bug.

An even more amusing way to reproduce this is like so...

Code: Select all

# rox -p=
# rox -p=~/Choices/ROX-Filer/PuppyPin 
# rox -p ~/Choices/ROX-Filer/PuppyPin 
# rox -p=~/Choices/ROX-Filer/PuppyPin 
# rox -p ~/Choices/ROX-Filer/PuppyPin 

Last command restores the original...

So it seems the 'p=' syntax is a bug. I'll fix it in due course.

Thanks for making me think .

Hmm... I don't think that reproduces the same thing exactly, but it's a start. Maybe rox -p= and rox -p are both broken

Going to try another build with an older 2016 woof-CE branch later (Slacko 6.9.6.4?) and see if that fixes it.

[bigpup]

Wifi Issue.
Slacko 6.9.9.9 32bit K4.4.70

The save and using it seems to be at the base of this issue.

I notice when doing a boot up.
The info about loading the different SFS packages, main SFS, adrv, fdrv, zdrv, and the save.

Before the save is loaded a message comes up that it is loading kernel driver modules hid.

I think this is the one it is talking about:
lib/modules/4.4.70/kernel/drivers/hid/i2c-hid/i2c-hid.ko

Is this suppose to be happening and if so, is it the correct process just before the save loads?

Wifi issue success, MAYBE, well so far.
Seems to be working better.

Slacko 6.9.9.9 64bit K4.9.30
Frugal using a save.

It boots and loads the save just after the last sfs package loads.
Nothing is loaded before, like it does in the 32 bit Slacko.

It loads main sfs, adrv, fdrv, zdrv, save.

I never see this:

Before the save is loaded a message comes up that it is loading kernel driver modules hid.

I think this is the one it is talking about:
lib/modules/4.4.70/kernel/drivers/hid/i2c-hid/i2c-hid.ko

Could this be causing the save wifi issue in Slacko 32bit???????



With this being a very new computer. I am sure the newer kernel is a help

[bigpup]

I have also found a github repo by lwfinger (noted linux wireless dev) that replaces (almost) the whole rtl* driver stack! See https://github.com/lwfinger/rtlwifi_new

Anyone can build it themselves if they load devx and kernel_source from sfs-manager (in setup menu).

Code: Select all

git clone https://github.com/lwfinger/rtlwifi_new
cd rtlwifi_new
make
make install

I will try this later today.
Got to go do stuff for now!!

[sheldonisaac]

Slacko 6.9.9.9 64bit K4.9.30 Frugal using a save.

It boots and loads the save just after the last sfs package loads.
Nothing is loaded before, like it does in the 32 bit Slacko.
It loads main sfs, adrv, fdrv, zdrv, save.

I never see this:

Before the save is loaded a message comes up that it is loading kernel driver modules hid.
Could this be causing the save wifi issue in Slacko 32bit???????

Folks, I think bigpup is not only VERY helpful in general, but he is doing a fine job of trying to solve this!

[Billtoo]

I installed a build of Slack 6.9.9.9 to the hard drive of my compaq
desktop:

# inxi -b
System: Host: puppypc24651 Kernel: 4.4.73-pae i686 (32 bit) Desktop: JWM 2.3.2 Distro: Slacko Puppy 6.9.9.9
Machine: Device: desktop System: Compaq Presario 061 product: DQ182A-ABA S6700NX NA410 v: 0nB1411RE101COBRA10 serial: MXM41001K5
Mobo: ASUSTeK model: Cobra v: 1.xx serial: X312345678
BIOS: American Megatrends v: 3.28 date: 08/27/2004
CPU: Single core Intel Pentium 4 (-HT-) speed: 2800 MHz (max)
Graphics: Card: Advanced Micro Devices [AMD/ATI] RV530 [Radeon X1600 PRO]
Display Server: X.org 1.18.3 driver: radeon tty size: 152x49 Advanced Data: N/A for root
Network: Card-1: Realtek RTL-8100/8101L/8139 PCI Fast Ethernet Adapter driver: 8139too
Card-2: D-Link System AirPlus G DWL-G122 Wireless Adapter(rev.C1) [Ralink RT2571W] driver: rt73usb
Drives: HDD Total Size: 320.1GB (3.0% used)
Info: Processes: 168 Uptime: 1:06 Memory: 175.6/1506.9MB Client: Shell (bash) inxi: 2.3.8
#
# report-video
VIDEO REPORT: Slacko Puppy, version 6.9.9.9

Chip description:
VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530 [Radeon X1600 PRO] Display controller:
Advanced Micro Devices, Inc. [AMD/ATI] RV530 [Radeon X1600] (Secondary)

Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 3840x1080
Depth (bits, or planes): 24
Modules requested to be loaded: dbe
Drivers requested to be loaded: radeon

Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): radeon
Loaded modules: dbe dri2 exa fb glx kbd mouse ramdac

Actual rendering on monitor:
Resolution: 3840x1080 pixels (1015x285 millimeters)
Depth: 24 planes

...the above also recorded in /tmp/report-video
#

No problems with the usb wireless adapter.