Quirky 1.4 bug reports and feedback
New to Quirky / Puppy / Woof. Decided to check this out after reading the release announcement on DistroWatch. Love it so far!
Detected all hardware on first boot. Wasn't hard at all to figure out how to get nvidia working.
Audio works, video works, pretty much everything works. (The KDE Trinity .sfs does not, though.)
Successfully loaded Skype during first session by downloading from Skype's site, using tar and install. I was able to connect using text, but audio wasn't working (didn't try video). Rebooted, Skype wouldn't load. Found the Skype .sfs on the forums, deleted the old Skype files, downloaded .sfs, put it into the Boot Manager, rebooted. Now I see it in the menu bar, but it won't load at all. Will work on it some more tomorrow.
Quirky is exactly what I need, if I can get Skype to work so I can talk to my family while I fool with a fresh Gentoo or LSF install on my hard drives. If I mess up the install (again), I figure I'll still be able to pop the disk in and talk to them when they want without having to install Mint to the hard drive just to use Skype.
But the more I read about Puppy and Woof, I may abandon the plan to build from source using Gentoo and instead try it using Woof.
Thanks for a great project!
Detected all hardware on first boot. Wasn't hard at all to figure out how to get nvidia working.
Audio works, video works, pretty much everything works. (The KDE Trinity .sfs does not, though.)
Successfully loaded Skype during first session by downloading from Skype's site, using tar and install. I was able to connect using text, but audio wasn't working (didn't try video). Rebooted, Skype wouldn't load. Found the Skype .sfs on the forums, deleted the old Skype files, downloaded .sfs, put it into the Boot Manager, rebooted. Now I see it in the menu bar, but it won't load at all. Will work on it some more tomorrow.
Quirky is exactly what I need, if I can get Skype to work so I can talk to my family while I fool with a fresh Gentoo or LSF install on my hard drives. If I mess up the install (again), I figure I'll still be able to pop the disk in and talk to them when they want without having to install Mint to the hard drive just to use Skype.
But the more I read about Puppy and Woof, I may abandon the plan to build from source using Gentoo and instead try it using Woof.
Thanks for a great project!
Sound
This version of Quirky dutifiy reports that it can't see my onboard sound card(chip).
What files should I copy from Quiry 1,2, which does detect the chip to be able to use Quirky 1,4?
Thanks
Thom
What files should I copy from Quiry 1,2, which does detect the chip to be able to use Quirky 1,4?
Thanks
Thom
I don't know what happened because it has worked in my last two tests, but during the first test fontmap wasn't empty (I just checked). I didn't explicitly boot with pfix=ram but used this entry in GRUB2:BarryK wrote:I am running Quirky 1.4 right now. I just checked /etc/fontmap, it is empty, as it should be.pakt wrote:Barry, the ‘FONTMAP’ problem in rc.country remains in quirky-140.
Code: Select all
menuentry "quirky-1.4 26nov10 (on /dev/sda8)" {
insmod ext2
set root='(hd0,8)'
search --no-floppy --fs-uuid --set dc252aad-49ae-46c3-93cf-762d911a231b
echo 'Loading quirky 1.4 ...'
linux /quirky140/vmlinuz pmedia=atahd pdev1=sda8 psubdir=quirky140
echo 'Loading initial ramdisk ...'
initrd /quirky140/initrd.gz
}
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
The wizard does suggest installing 'the DRI (mesa)' package first (but un-clear as to what package is referred to and no clear instruction on how to obtain or install it).BarryK wrote:Hmmm, perhaps this needs to be clarified in the Video Upgrade Wizard. If you upgrade the Intel video driver, you do NOT use mesa 6.5.2.
I did look at the two buttons at bottom of window but the first was concerned with compiling (no mention of 'DRI'). And the second button mentioned 'DRI' in connection with 'non-Intel' hardware only.BarryK wrote: If you do need the rest of the mesa package, the Wizard explains to install 'xorg_upgrade_dri_extra-7.8.2' -- see the two buttons at bottom of window.
Here's the wizard menu for my Intel chip:
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
Right click on one of the icons (back forwar button etc) and from the pop-up select 'customise'nubc wrote:Seamonkey's Navigation Toolbar is has unusual and unnecessary height. Maybe an eighth inch excess on a 17-inch screen. Can't think of a reason this extra height would be beneficial.
In the pop-up panel, select 'use small icons', located bottom/centre on panel.
Spup Frugal HD and USB
Root forever!
Root forever!
Also install and use Compact Menu 2 https://github.com/Milly/compact_menu_2nubc wrote:Seamonkey's Navigation Toolbar is has unusual and unnecessary height. Maybe an eighth inch excess on a 17-inch screen. Can't think of a reason this extra height would be beneficial.
and add this code to /root/.mozilla/seamonkey/blahblahdefault/chrome/userchrome.css
Code: Select all
.tabbrowser-strip {
padding-bottom: 0px !important;
padding-top: 0px !important;
border-bottom: 0px !important;
}
tab {
padding: 0px 3px !important;
}
.tabbrowser-tabs {
padding-top: 0px !important;
}
Spup Frugal HD and USB
Root forever!
Root forever!
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I have fixed the Wizard, announced on my blog, so it should be ok for the next Wary.pakt wrote:The wizard does suggest installing 'the DRI (mesa)' package first (but un-clear as to what package is referred to and no clear instruction on how to obtain or install it).BarryK wrote:Hmmm, perhaps this needs to be clarified in the Video Upgrade Wizard. If you upgrade the Intel video driver, you do NOT use mesa 6.5.2.I did look at the two buttons at bottom of window but the first was concerned with compiling (no mention of 'DRI'). And the second button mentioned 'DRI' in connection with 'non-Intel' hardware only.BarryK wrote: If you do need the rest of the mesa package, the Wizard explains to install 'xorg_upgrade_dri_extra-7.8.2' -- see the two buttons at bottom of window.
Here's the wizard menu for my Intel chip:
[url]https://bkhome.org/news/[/url]
Concerns about light-weight module loading
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.Richard
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.
Code: Select all
alias usb:v12D1p140Cd*dc*dsc*dp*icFFiscFFipFF* option
alias usb:v12D1p140Cd0000dc*dsc*dp*ic*isc*ip* usb-storage
BarryK wrote:Ha ha, yeah that is great! Good if we could get rid of the signature on it -- with due respect to any copyright requirement.bigpup wrote:Found a wallpaper for Quirky.
- Attachments
-
- ws_sweeeet_chiwawa_1280x1024.jpg
- (158.71 KiB) Downloaded 587 times
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)
change line 28 from
to
aragon
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)
Code: Select all
/usr/local/apps/Xlock/AppRun
Code: Select all
. $APPDIR/locale/${LANGUAGE}.po 2> /dev/null
Code: Select all
if [ -e $APPDIR/locale/${LANGUAGE}.po ];then
. $APPDIR/locale/${LANGUAGE}.po 2> /dev/null
fi
PUPPY SEARCH: http://wellminded.com/puppy/pupsearch.html
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.
http://bkhome.org/blog/?viewDetailed=02008
Files attached. These need to be gunzipped and placed in /usr/local/petget.
- Attachments
-
- pkg_chooser.sh.gz
- (4.16 KiB) Downloaded 516 times
-
- help.htm.gz
- (2.24 KiB) Downloaded 496 times
-
- findnames.sh.gz
- (1.05 KiB) Downloaded 528 times
-
- filterpkgs.sh.gz
- (2.42 KiB) Downloaded 500 times
[url]https://bkhome.org/news/[/url]
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
Now PPM doesn't open any longer.
Just reporting. It's probably a logical conflict between Quirky 1.4 and Inpu.
Bert
[url=http://pupsearch.weebly.com/][img]http://pupsearch.weebly.com/uploads/7/4/6/4/7464374/125791.gif[/img][/url]
[url=https://startpage.com/do/search?q=host%3Awww.murga-linux.com%2F][img]http://i.imgur.com/XJ9Tqc7.png[/img][/url]
[url=https://startpage.com/do/search?q=host%3Awww.murga-linux.com%2F][img]http://i.imgur.com/XJ9Tqc7.png[/img][/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Try running this in a terminal window:Bert wrote: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
# /usr/local/petget/pkg_chooser.sh
...see if any error msgs.
[url]https://bkhome.org/news/[/url]
I did the same as BertBarryK wrote:Try running this in a terminal window:Bert wrote: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
# /usr/local/petget/pkg_chooser.sh
...see if any error msgs.
# /usr/local/petget/pkg_chooser.sh
bash: /usr/local/petget/pkg_chooser.sh: Permission denied
#
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!
BTW that help file has this:
It didn't look like you changed anything else. For example I was thinking the main package list might be stretchable like the installed packages list, but it's not. I also don't see the "ALL" category like you showed on your blog. Perhaps it is underneath the "Show" checkboxes? I made the assumption it would work in Lupu 511, hope that's right. I think I got the files over properly; at least the loaded size is a bit larger than the originals.
Also just noticed that I have double entries in my installed package list (in this case for Seamonkey and openvpn_2.1.0); not sure how they got there but maybe this calls for a check before another entry is added to the list:
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!
BTW that help file has this:
Perhaps you mean, bottom-right...When a package is installed, it appears in the window bottom-left.
It didn't look like you changed anything else. For example I was thinking the main package list might be stretchable like the installed packages list, but it's not. I also don't see the "ALL" category like you showed on your blog. Perhaps it is underneath the "Show" checkboxes? I made the assumption it would work in Lupu 511, hope that's right. I think I got the files over properly; at least the loaded size is a bit larger than the originals.
Also just noticed that I have double entries in my installed package list (in this case for Seamonkey and openvpn_2.1.0); not sure how they got there but maybe this calls for a check before another entry is added to the list:
Code: Select all
# cat user-installed-packages
Seamonkey-2.0.9-Lucid|Seamonkey|2.0.9-Lucid||Document|44104K|pet-packages-lucid|Seamonkey-2.0.9-Lucid.pet||SeaMonkey Composer html editor|ubuntu|lucid||
Seamonkey-2.0.9-Lucid|Seamonkey|2.0.9-Lucid||Document|44104K|pet-packages-lucid|Seamonkey-2.0.9-Lucid.pet||SeaMonkey Composer html editor|ubuntu|lucid||
liblocale-gettext-perl_1.05-6|liblocale-gettext-perl|1.05-6||BuildingBlock|108K|pool/main/libl/liblocale-gettext-perl|liblocale-gettext-perl_1.05-6_i386.deb|+libc6|Using libc functions for internationalization in Perl|
libpkcs11-helper1_1.07-1build1|libpkcs11-helper1|1.07-1build1||BuildingBlock|176K|pool/main/p/pkcs11-helper|libpkcs11-helper1_1.07-1build1_i386.deb|+libc6,+libssl0.9.8|library that simplifies the interaction with PKCS#11|
libtext-charwidth-perl_0.04-6|libtext-charwidth-perl|0.04-6||BuildingBlock|92K|pool/main/libt/libtext-charwidth-perl|libtext-charwidth-perl_0.04-6_i386.deb|+libc6,+perl-base,+perlapi-5.10.0|get display widths of characters on the terminal|
libtext-iconv-perl_1.7-2|libtext-iconv-perl|1.7-2||BuildingBlock|108K|pool/main/libt/libtext-iconv-perl|libtext-iconv-perl_1.7-2_i386.deb|+libc6,+perl-base,+perlapi-5.10.0|converts between character sets in Perl|
libtext-wrapi18n-perl_0.06-7|libtext-wrapi18n-perl|0.06-7||BuildingBlock|68K|pool/main/libt/libtext-wrapi18n-perl|libtext-wrapi18n-perl_0.06-7_all.deb|+libtext-charwidth-perl|internationalized substitute of Text::Wrap|
openssl-blacklist_0.5-2|openssl-blacklist|0.5-2||BuildingBlock|12240K|pool/main/o/openssl-blacklist|openssl-blacklist_0.5-2_all.deb|+python,+openssl|list of blacklisted OpenSSL RSA keys|
openvpn-blacklist_0.4|openvpn-blacklist|0.4||BuildingBlock|2100K|pool/main/o/openvpn-blacklist|openvpn-blacklist_0.4_all.deb|+python|list of blacklisted OpenVPN RSA shared keys|
openvpn_2.1.0|openvpn|2.1.0|1ubuntu1|Network|1196K|pool/main/o/openvpn|openvpn_2.1.0-1ubuntu1_i386.deb|+debconf,+libc6,+liblzo2-2,+libpam0g,+libpkcs11-helper1,+libssl0.9.8,+openssl-blacklist,+openvpn-blacklist,+net-tools,+lsb-base|virtual private network daemon|
debconf_1.5.28ubuntu4|debconf|1.5.28ubuntu4||System|924K|pool/main/d/debconf|debconf_1.5.28ubuntu4_all.deb|+debconf-i18n|Debian configuration management system|
openvpn_2.1.0|openvpn|2.1.0|1ubuntu1|Network|1196K|pool/main/o/openvpn|openvpn_2.1.0-1ubuntu1_i386.deb|+debconf,+libc6,+liblzo2-2,+libpam0g,+libpkcs11-helper1,+libssl0.9.8,+openssl-blacklist,+openvpn-blacklist,+net-tools,+lsb-base|virtual private network daemon|
#
chmod FILEbash: /usr/local/petget/pkg_chooser.sh: Permission denied
1 executeable
2 write
4 read
...........user | group | other/world
chmod 777 : rwxrwxrwx
chmod 6 ......... 6 .............. 6 : rw-rw-rw-
chmod 555 : r-xr-xr-x
chmod 444 : r--r--r--
chmod 333 : -wx-wx-wx
chmod 222 : -w--w--w-
chmod 111 : --x--x--x
very common is chmod 755 /FILE
there is also a fourth parameter :
1 Sticky ( kind of a hardlink, stays on the place of the disk, deleting a copy of it would also delete the file itself )
2 SGID SET GROUP ID
4 SUID SET USER ID ( share the file to sudoers ( run as root ) ) http://www.codecoffee.com/tipsforlinux/ ... s/028.html
so chmod 1764 would make the file sticky and `ls -l` would show rwxrw-r--
if the fourth (or better first) value is not set, then it is treated as '0'
It would be chmod 0755 /usr/local/petget/FILE in the terminal
HTH