Puppy Linux Discussion Forum

nubc · Joined: 23 Jan 2007 Posts: 739 Location: USA

Ya, that changes the Navigation Toolbar height. Can you tell me how to get rid of the Print icon on the Navigation Toolbar. I like an uncluttered toolbar on my browser.

DaveS · Joined: 09 Oct 2008 Posts: 3669 Location: UK

rerwin · Joined: 24 Aug 2005 Posts: 1316 Location: Maine, USA

I have verified that my intel536 and HSF modems work under Quirky 1.4, but see in the backend_modprobe (etc.) revision some areas of concern that compromise its effectiveness.

1. Rc.services: Although rc.services waits until the ALSA sound support is ready, it does not verify that firmware processing and usb_modeswitching are complete. That is easily remedied by adding a wait loop that tests for the absence of /pinstall.*.sh scripts (the firmware processing) and usb_modeswitch processes in operation. Assuming a loop counter is used, a message should be logged if the count is exhausted, indicating a potential bug somewhere.

2. Allusbserial/Cdcacm: Because the standard usb_modeswitch dispatch script uses modprobe directly to load modem drivers, bypassing the backend_modprobe processing of firmware tarballs, the related initialization script may not get placed into /etc/init.d for execution by rc.services to detect USB modems. I suggest making init scripts related to drivers that usb_modeswitch might load be removed from firmware tarballs and placed permanently in /etc/init.d. Currently, that would be Allusbserial and Cdcacm, which probably should be renamed to begin with a 2-digit number.

3. Backend_modprobe (1): The logic to ensure that a module is processed (re ALSA and firmware) only once is as flawed as it was before I provided the "protect" function. Although the data is stored differently -- in multiple files instead of a single list -- the vulnerability itself is not resolved. A test is made for the module having been processed already, then (if not) the processing is done, then the indication is made that the module is processed. But multiple processes/threads/cores/CPUs processing events for the same module could execute that logic simultaneously, with each thinking it is the first process for that module! Ideally, the "processed" indication and the test for a previous such indicator should be done in the same command, possibly sed or awk (and in-place). If not possible, at least the setting of the indicator should be done before the test for previous indicators, with a way to determine which process's indicator was first.

4. Backend_modprobe (2): The firmware-loaded test uses the module name as the indication that its firmware is loaded, whereas previously the tarball name was used. Multiple modules can use the same tarball, so the tarball name is what would prevent duplicate processing. If module-duplication is corrected (#3 above) the module name would be seen only once by the firmware function, so its use is redundant. Even using the tarball name, the list maintenance needs treatment similar to that for modules -- update first or simultaneously, then test for being the first such entry.

5. Backend_modprobe (3): Required special treatment of some hybrid devices (cdrom-modem) is missing. (This could account for muggins' need to manually modprobe the option driver.) These devices have two modaliases, only one of which gets detected by backend_modprobe. Since the usb-storage modalias is near the end of the modules.alias file and does not filter by interface class, it is the one detected, so the modem driver gets missed altogether, unless usb_modeswitch loads it (which is not always the case, since usb-storage sometimes does the mode-switch). I suggest, following the initial modprobe of the modalias, to try temporarily blacklisting usb-storage and re-modprobing to find the alternative (e.g., modem) if there is one. This assumes usb-storage is always already loaded by rc.sysinit or earlier, so never needs further modprobing.

artifus · Joined: 06 Jul 2010 Posts: 318

aragon · Joined: 15 Oct 2007 Posts: 1690 Location: Germany

i've found that bug in insidous but i think it's woof-related so i'm posting it here:

xlock fails to run if $LANG is not en_US or fr_FR because the other language files are missing.

the fix is simple (i think)

BarryK · Posted: Tue 30 Nov 2010, 19:01 Post subject:

If anyone wants the upgraded PPM, as I announced on my blog:

http://bkhome.org/blog/?viewDetailed=02008

Files attached. These need to be gunzipped and placed in /usr/local/petget.

Bert · Joined: 30 Jun 2006 Posts: 693

Barry, I was feeling adventurous and placed the 4 files in Insidious Puppy's PPM.

Now PPM doesn't open any longer.
Just reporting. It's probably a logical conflict between Quirky 1.4 and Inpu.

Bert

BarryK · Posted: Tue 30 Nov 2010, 20:01 Post subject:

Billtoo · Joined: 07 Apr 2009 Posts: 1493 Location: Ontario Canada

PaulBx1 · Joined: 16 Jun 2006 Posts: 2308 Location: Wyoming, USA

I downloaded and extracted them, and changed permissions to the same as the original files had.

The help button certainly would have helped me earlier. Clears up some questions I had. I was able to find lots of packages having to do with vpn, now that I know how to use it! Embarassed

BTW that help file has this:

Karl Godt · Joined: 20 Jun 2010 Posts: 2671 Location: Kiel,Germany