(old)Puppy Linux Discussion Forum

Packit and Uextract pinstall.sh scripts were woof incompliant. I removed them. And also Packit has this line in DOTdesktop file:
Exec=/usr/local/apps/PackIt/AppRun %F

Yeah. This was clever. Pet installer knows that % 'something' should be removed.

#120901 get rid of param on end of Exec, ex: Exec=gimp-2.8 %U
#sed -i -e 's/\(^Exec=[^%]*\).*/\1/' -e 's/ *$//' $ONEDOT #'s/\(^Exec=[^ ]*\).*/\1/'
#121015 01micko: alternative that may work better...
for PARMATER in u U f F #refer: http://standards.freedesktop.org/deskto ... 01s06.html
do
sed -i "s/ %${PARMATER}//" $ONEDOT
done

Maybe Woof-CE 3builddistro should have this checking mechanism also.

The solution. Remove that offending %F > save > fixmenus > restart jwm.

Possible issue with JWM: Adding Tray Buttons

Menu > Utility > PuppyControl Panel > Desktop > Windows Manager Settings > Tray Buttons > ADD

Unable to ADD 'Tray Button'
the SELECT ICON not working, and manually populating the field does not save.

Schpankme.
Jup. PupControl launches /usr/local/jwmconfig2/panel-buttons and that script tries to launch /usr/local/jwmconfig2/file-selector when you click the icon selection button.
And fails. If you do that straight from that file panel-buttons or using Jwm Configurator application....it works. So....it is PupControl quirk.

There is progress with Woof-CE problems I have had. UExtract and Packit woof compliant pinstall.sh scripts are almost there.

PupClockset pinstall.sh script for some reason blanks .jwmrc-tray.
I contact the developer...or he might even read this thread.

I have uploaded my used pets to ibiblio and I have created Woof-CE build from online stuff, not using anything I had in hdd. Next thing is to check what happens, when I launch this online stuff Woof-CE created version.

Hiihaa. Posting this from Woof-CE created Dpup Wheezy without using any hdd existing pets. or other stuff.
I downloaded master branch Woof-CE, okay, swapped the latest configuration files, started woofing, downloaded online pets and debs, processed them, started final building, okay....swapped that blanked .jwmrc-tray file....and created the .iso

Posting from it. Seems fully functional. No strange bug messages in xerrors.log or other log files.
Good to go.

Woof-CE master branch does not create atm firmwares correctly. I have understood it is work under progress. Just reminder, that all-firmware is about empty if you test woof-ce-ing. And my latest config files are not yet in Woof-CE. They need to be sent to official registration. Something like pull request. Or whatever.

pemasu wrote: .... PupControl launches /usr/local/jwmconfig2/panel-buttons and that script tries to launch /usr/local/jwmconfig2/file-selector when you click the icon selection button. And fails.

... use JWM Configurator

Works as intended, Thank you.

pemasu wrote: Woof-CE master branch does not create atm firmwares correctly. I have understood it is work under progress. Just reminder, that all-firmware is about empty if you test woof-ce-ing. And my latest config files are not yet in Woof-CE. They need to be sent to official registration. Something like pull request. Or whatever.

The firmware thing should be better now in master. Pls check.
BTW shouldn't you start "whatever'ing" yourself some time soon? Git is not that much harder than fossil or woof.

Mavrothal. Nope. Making Dpup Wheezy Woof-CE compatible and trashing bugs in using it takes my time. Starting tomorrow I dont have leisure time. No chance I start play with Github without guidance. Sorry.
I know what it took from me to learn woof. It takes time. I dont have spare hours for it. Sorry again.

Master - branch - testing - forking - pull - push - request - checkout - clone - initial setup - net tool possibility ( Zigbert) - whatever. They all have meaning what kind snapshots they are creating - updating - downloading. Without knowing - I mean Really knowing - what they do - I cant use it.

pemasu wrote: Master - branch - testing - forking - pull - push - request - checkout - clone - inital setup - net tool possibility ( Zigbert) - whatever. They all have meaning what kind snapshots they are creating - updating - downloading. Without knowing - I mean Really knowing - what they do - I cant use it.

OK
What about this then. You download the woof-CE, modify it as you need to, then re-extract the original zip file in another place/name, do a "diff -u -r original/ modified/ > woof.diff" and send/post the diff file.
Is this within your time constrains?

Diff or just packaging my changed files is ok. I do change only config files to create Dpup Wheezy. So...there is about 4 text files I do operate with. The rest is keeping ibiblio pet_packages-wheezy and database file for it in sync. And...maybe... updating woof compliant pets to noarch repo.

My main motivation is still woofing the Puppy distro. And I think Woof-CE masters need some one to really test the Woof-CE...how it creates Puppy. 01micko certainly do that....and with better knowledge and skill....but he has now hard multi-drive going on...it wont hurt if someone shares the building and testing part. Like all the users who give valuable feedback.

Ugh. I have spoken. Back to business.

Hi pemasu & all,

Looks nice. I can't get very far.
Processor: 4x AMD Phenom(tm) II X4 945 Processor
ATI Radeon 3100 Graphics supporting 1600x900 pixels
RaLink RT2561/RT61 802.11g PCI

Dpup Wheezy 3.5.2.9 drops to console during boot allowing me to successfully choose graphics which then boots to desktop at proper resolution.

Attempting to configure wireless end with information shown in attached jpg.
I think this is the same firmware or driver problem I've had with previous wheezys.

mikesLr

Hmm... does my build have pdiag.....
# pdiag
ls: cannot access /etc/frisbee/: No such file or directory
/usr/sbin/pdiag: line 110: 23766 Terminated gtkdialog-splash -placement center -bg orange -text "$MSG2"

# ls /root | grep pdiag*
pdiag-20131208.tar.gz

And posting that tar ball helps to diagnose the wireless problems.

Dpup Wheezy 3.5.2.10 is out !
It is my second Woof-CE build. This update consists of bug fixes found since first Woof-CE.
UExtract and PackIt are now woof compliant and so...the Rox Right Click file type couplings are working. They are great tools and I think they challenge Xarchive soon...no...they challenge it already !
Thank you SFR of your great work !
I didnt include them to the Pinboard because that is personal choice.

- Woof-CE related ( a couple ) bugs have been fixed.
- Multiple menu application locations fixed.
- PPM download choices reduced. Double download bug possibility still persists. It is PPM bug. While updating PPM, skip Packages-debian-wheezy_updates-multimedia. It causes update process to fail. Meaning that bug also persists.

Mostly this build is sanity check to create Woof-CE Dpup Wheezy.

As side effect...you can test - use - blame - give feedback of - it.

Cheers.

Download link: http://smokey01.com/pemasu/DpupWheezy/DpupWheezy35210/

Hi pemasu,

D/l'd, unpacked and booted into Dpup Wheezy 3.5.2.10. Same situation as I reported regarding 3.5.2.9. pdiag being present. I ran it and it generated the reports in the attached file.
FWIW, wifi functioned in all of your rarings, your upups, the latest slacko and those which preceeded it, and in all Exprimos. I've only had wifi problems with Archpup, AlphaOne, all Wheezys, and one slacko build by jejy69.

mikesLr

pemasu wrote:Dpup Wheezy 3.5.2.10 is out !

Frugal install on netbook Acer aspire one

First boot + settings: OK!
Add Greek keyboard: OK!
Connect through PGPRS: OK!
Update package manager*: OK!

*without the multimedia repository

But when i tried to create a save file, i got this:



I have Slacko 5.5 XL, Slacko 5.6.3 & your previous wheezy release installed in the same drive, this shouldn't happen!

Quick manual frugal install on the old Athlon XP box. Looks good.

Still need to use nouveau.noaccel=1 kernel parameter.

# report-video
VIDEO REPORT: Dpup Wheezy, version 3.5.2.10

Chip description:
VGA compatible controller: NVIDIA Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev c1)

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

Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): nouveau
Loaded modules: dbe dri dri2 exa extmod fb fbdevhw glx kbd mouse record shadowfb

Actual rendering on monitor:
Resolution: 1440x900 pixels (380x238 millimeters)
Depth: 24 planes

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

-Computer-
Processor : AMD Athlon(tm) XP 2400+
Memory : 1033MB (185MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Sun 08 Dec 2013 11:28:49 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Unknown
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : VIA8233 - VIA 8235

EDIT:
Almost forgot...... needed to use SNS to get on the internet and saving to an ext 3 partition. No NTFS or fat on this box.

Tried it on a VM, and looks good here.
No save issues on an ext2 partition that had other puppies.
Had to use xorgwizard to get the desired screen resolution I guess because it defaults to modsetting instead of vesa ? (Slacko 5.6.3 offered this option the quicksetup)
Also updated 3.5.2.9 to 3.5.2.10 in another (type of) VM with no issues.

Quickly booted 3.5.2.10 live pfix=ram on another old box and successfully saved to a Windows 7 NTFS partition.
Had to use SNS for internet connection again but was primarily testing saving on NTFS.

BootFlash Install Puppy To USB: sdc1

Dpup Wheezy, version 3.5.2.10

Created save file.

Working as intended.

Screenie.....

Installed 3.5.2.10 onto a fresh usb drive and created a new save file, found the the wireless
module 'iwl4965', which is my intel wifi card, was not found and was not on the list of
available modules that could be loaded for wifi connections. This module was automaticly
picked up and used on the 3.5.2.7 version.

Installed 3.5.2.10 onto an exisiting 3.5.2.8, that was previously updated from a 3.5.2.7...
found that Chrome no longer runs and fails with missing lib references (libnss3*.so and
other libs that Firefox uses in it's own directory),

Examining the differences between 3.5.2.10 and 3.5.2.8, I found that '.8' had symbolic links
for the libs in '/usr/lib' and in '/initrd/usr/lib'.

Found the 3.5.2.10 had the same links in '/initrd/usr/lib', but were missing in '/usr/lib', and
reinstalling Chrome made no differences. Hense the lib ref failures.

Doing a dependency check on the Chrome package showed missing library refs, all of
which are located in the Firefox directory. Creating symblic links of all libs in the Firefox
directory within the /usr/lib', solved Chrome's startup problem.