(old)Puppy Linux Discussion Forum

Just pokin' my nose in the door to say - way to go, guys! I think Stretch/Debian is the best possible choice in regards to Puppy's future, and am eagerly awaiting the cumulation of all of your wonderful efforts resulting in a genuine, 'official' Stretch release. (Also, admittedly, in hopes of the final product attracting the magnificent talents of peebee, rg66 and Geoffrey into building LXDE and XFCE versions... my favorites)

Wish I was in a position to at least help contribute with any meager talents I may possess... but, alas, too much other "life" stuff going on, ATM.

But, you guys GO!!! Lookin' great. Bless ya' all!

Bob

Moat wrote:Just pokin' my nose in the door to say - way to go, guys! I think Stretch/Debian is the best possible choice in regards to Puppy's future, and am eagerly awaiting the cumulation of all of your wonderful efforts resulting in a genuine, 'official' Stretch release. (Also, admittedly, in hopes of the final product attracting the magnificent talents of peebee, rg66 and Geoffrey into building LXDE and XFCE versions... my favorites)

Wish I was in a position to at least help contribute with any meager talents I may possess... but, alas, too much other "life" stuff going on, ATM.

But, you guys GO!!! Lookin' great. Bless ya' all!

Bob

2.14X I used XFCE panel etc and liked it a lot, It only took a min more resources than JWM. But since then JWM has acquired a lot of deps and now they might actually be identical in resources.
ttuuxxx

musher0 wrote:Re-run the build-distro script and waste another hour?

What happened to the change-kernel script? What does that do?

On the other hand, just replacing the files doesn't sound so bad.

BFN.

All you would have to do is run woof_gui and select the last tab "Build distro" Takes about 20 mins, Longer if you wait for the devx, I usually just move the devx for safe keeping, but this time it should be built for compiling.
ttuuxxx

How do you find that build number again? Is it Billtoo or belham2 who
mentioned it?

I'm asking because I re-built a new DPupStretch-7. It took me about an
hour. It's working fine. Writing from it now. It picked up my former
pupsave and ydrv, so I have nothing to re-install or re-configure.

Congrats to the Superior Powers at woof-CE for a speedy, efficient and well
done job reacting to the testing in this thread.

Back to being a grouch. (2nd Friday of the month is "Grouch Day", AYMK.)

TWYL (maybe).

ttuuxxx wrote:

musher0 wrote:Re-run the build-distro script and waste another hour?

What happened to the change-kernel script? What does that do?

On the other hand, just replacing the files doesn't sound so bad.

BFN.

All you would have to do is run woof_gui and select the last tab "Build distro" Takes about 20 mins, Longer if you wait for the devx, I usually just move the devx for safe keeping, but this time it should be built for compiling.
ttuuxxx

Thanks for the useful tip. I already have created the devx, so I move it
somewhere else so it won't get zapped. Got it.

ttuuxxx wrote: 2.14X I used XFCE panel etc and liked it a lot, It only took a min more resources than JWM.

The "clinchers" for me with XFCE are - Whisker menu (with integrated search, recently used programs and favorites), great selection of easily-applied, useful panel applets, and XFCE's native compositing (I like a bit of drop shadow on my windows).

10-12 yrs. ago, JWM's minimalism made sense. That level of minimalism is largely irrelevant today, IMO. XFCE runs perfectly fine and snappy on what currently constitutes "low-spec" hardware, and brings a lot more to the feature/functionality/usability table, compared to JWM.

I do know XFCE makes Musher0 a bit nauseous, though...

Bob

About panels:

bmpanel2 is a little-known but quite nice alternative. It has no applets,
but it has great themes (some transparent), and its configuration is very
versatile: you can move the parts of the config around if you wish.

I probably tried all known panels before deciding on bmpanel2. I use it
with pekwm and wmx. It's the panel at the bottom of my scrots above.
I've got a pet handy if you like. (In its own forum thread, actually.)

Bmpanel2 will even work with jwm if you empty .jwmrc-tray completely.
(Make a real back-up of that file beforehand of course, naming it .jwmrc-
tray.me or something like that; jwm already uses the .bak extension, so if
you use the .bak extension for your back-up, jwm will zap it.)

Because jwm's panel will steal priority if it exists and prevent other panels
from loading at the same place as itself.

Just a thought.

I did a new build which uses the kernel that ttuuxxx posted:

System: Host: puppypc27223 Kernel: 4.1.38 i686 (32 bit) Desktop: JWM 2.3.6 Distro: Dpup Stretch 7.0.0a1
Machine: Device: desktop System: Compaq-Presario product: AU194AA-A2L CQ5123F serial: MXX9300M0F
Mobo: MSI model: Boston v: 1.0 BIOS: Phoenix v: 5.24 date: 06/19/2009
CPU: Dual core Pentium E5200 (-MCP-) speed/max: 1200/2500 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.19.1 drivers: nouveau (unloaded: modesetting,fbdev,vesa)
tty size: 122x39 Advanced Data: N/A for root
Network: Card-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169
Card-2: D-Link System AirPlus G DWL-G122 Wireless Adapter(rev.C1) [Ralink RT2571W] driver: rt73usb
Drives: HDD Total Size: 500.1GB (7.9% used)
Weather: Conditions: 9 F (-13 C) - Clear Time: March 10, 11:08 PM EST
Info: Processes: 105 Uptime: 1:50 Memory: 196.7/3153.5MB Client: Shell (bash) inxi: 2.3.5

I installed all the usual stuff with PPM and have @radky's pets installed too.
I got a warning that the devx should be loaded when installing pets so I did that.
When it was building the iso I saw a message that it wasn't a syslinux hybred iso (something like that) that
I haven't seen before.
I installed the XFE and Fox Toolkit pets from my last 4.9.13 build and XFE installed as an executable.
The only other problem so far is that VLC segfaults.

Hello all.

I thought this Stretch needed a couple of media playing utilities in CLI.

So here are:
~~~~~~~~~
Sound_eXchange-14.2.1 (aka soX) built on and for DpupStretch7. It's a
dynamic build, meaning: with only shared libs, hence rather small-sized,
considering what it is.

Ref.: http://sox.sourceforge.net

SoX can play almost any music file.
Usage for playing is : < play MusicFile.Ext >
For info on the file, you would type: < soxi MusicFile.ext >

To reassemble the attached parts of the pet, please open a terminal in
your download dir. and type:And then you can install the pet normally. You
may wish to remove the xa* files once the install is successful.

Those who like more bass may wish to alter play's bass number setting,
like so: < play MusicFile.Ext bass +2 >.

~~~~~~~~~~
Also, please find attached qiv, or Quick Image Viewer, v. 2.3.1, the latest
as of this writing. Again compiled on DpupStretch7.

Ref.: https://spiegl.de/qiv

I'm offering a few qiv scripts that turn qiv into a slide show player, if you
wish to try them or play with them.

Of note, qiv has its own qiv-command script executable in /usr/bin which
contains a set of additional commands you can call by typing 0 or 1, etc.,
up to 9. For ex., I've edited mine so when I type 0 on the picture
displayed by qiv, it opens in mtpaint. This extends qiv's usefulness.

Another feature of qiv is that it can set the general system background,
the one underneath the ROX-Filer background, if you call it from .xinitrc.
This is one way to achieve transparency for conky, for ex.

Finally, IMO, to say that qiv is a only a CLI utility is unfair: it has its own
desktop file.

~~~~~~~~~~~
Enjoy!

BFN.

ttuuxxx wrote:
I haven't tried that yet, I'm compiling live and have build environment set right, lol I don't want to reset yet until I get a few more things compiled, I would think you would just drop the kernel into woof-out_x86_x86_debian_stretch/huge_kernel/ directory and run the build distro.
This was the output when compiling the kernel was finished.
Output files:
- dist/packages/huge-4.1.38-stretch.tar.bz2
(kernel tarball: vmlinuz, modules.sfs - used in the woof process)
you can use this to replace vmlinuz and zdrv.sfs from the current wce puppy install..

- dist/sources/kernel_sources-4.1.38-stretch.sfs
(you can use this to compile new kernel modules - load or install first..)
------------------
Done!
ttuuxxx

Hi Ttuuxxx, Musher and all,

I thought what I have been doing is obvious? Musher, dropping in another kernel into the build script presents no problems for the script and result if you focus on running only step ./3builddistro-Z again (it vastly helps to do this all in its own separate, designated partition). I even drop new .deb packages into the correct build-pkg folder, modify the corresponding pkg-build list.......he!!, I even convert .pets to .debs, then drop them in, do the modifications to the pkg-build-list (and the ,/3builddistro-Z if necessary) and away you go. Stuff shows up in the new ISO build no problems I've encountered so far (except cherrytree not making it thru the build---only works if installed afterwards---must be python-related, and me not tracking every necessary dependency). So you not only get new kernels, but also new included programs. Lastly, you can change, in the build script, the lines that have the default packages to the ones you want, and the end result is a different ISO with the "default" packages you want, not build-script-Z mandated. Jilst did wonders in letting us play with this whole setup!!!

@ttuuxxx....thank you for another kernel....I just tried it, and I don't care that end of life is next year as Musher says (Musher, please!, how about not being so "negaitive", it gets hard when you become like that yelling at us all in your posts )...anyway, ttuuxxx your new kernel is great, stable and works with everything I've thrown at it. I am now thinking of flopping over to it as the "default" on my goosed-up build/ISO I had did (a few posts back), and will re-do over with your new kernel. Thanks again so much!!

@musher---thanks for the "qiv" script for creating a slideshow, going to try it, and if I like, going to include it too in the build. Geoffrey has some fantastic camera/graphics programs I am looking at (in the Carolina repos--evidenced in his x-tahr-2.0 with the super camera/graphics adrv he made). Not sure how they'll go though in re-compiling.


In case anyone is wondering, my inspiration for all this fooling with the 3rd step in the build process has been Billtoo!

MPlayer (with GUI) is not too difficult to compile and others may have uploaded packages, but my one compiled in Stretch is uploaded to http://smokey01.com/OscarTalks at least for now in case it is helpful to anyone. The binary has been left showing as a dynamic lib because MPlayer has been like this for a while even in earlier Puppies. It would probably be OK to change it but I have not experimented yet.

Version is svn checkout 37926 which is only a few days old. The MPlayer devs always recommend using checkouts. Latest release 1.3.0 is already over a year old.

@ttuuxxx - I thought it would be possible to link against system ffmpeg by using the configure options --disable-ffmpeg_a --enable-ffmpeg_so but I have never tested this. I always just allow static linking of the trunk ffmpeg since it will be the latest.

To anyone using my Wheezy VLC in Stretch, thinking about it, I would expect some of the codecs and other functions not to work because the libav libraries will be mismatched.

OscarTalks wrote:MPlayer (with GUI) is not too difficult to compile and others may have uploaded packages, but my one compiled in Stretch is uploaded to http://smokey01.com/OscarTalks at least for now in case it is helpful to anyone. The binary has been left showing as a dynamic lib because MPlayer has been like this for a while even in earlier Puppies. It would probably be OK to change it but I have not experimented yet.

Version is svn checkout 37926 which is only a few days old. The MPlayer devs always recommend using checkouts. Latest release 1.3.0 is already over a year old.

@ttuuxxx - I thought it would be possible to link against system ffmpeg by using the configure options --disable-ffmpeg_a --enable-ffmpeg_so but I have never tested this. I always just allow static linking of the trunk ffmpeg since it will be the latest.

To anyone using my Wheezy VLC in Stretch, thinking about it, I would expect some of the codecs and other functions not to work because the libav libraries will be mismatched.

Stretch is a new Linux distro so it has the latest ffmpeg, your doubling up that way. Or adding an extract 6M compressed. My last Mplayer was 1.8MB pet and Gnome-mplayer GUI 224kb pet
ttuuxxx

Understood. If compiling a new MPlayer for an older Puppy it offers advantages to allow the better functions at the cost of a larger size, but here using system ffmpeg seems like a good idea. I was just curious as to what you did because I had thought that the configure options would do this but your earlier post gave me the impression that you had to look a little deeper and tweak something.

I have never really been a fan of gnome-mplayer but it is always worth including as it is small, plus of course you need it if you want to run the gecko-mediaplayer browser plugins.

OscarTalks wrote:Understood. If compiling a new MPlayer for an older Puppy it offers advantages to allow the better functions at the cost of a larger size, but here using system ffmpeg seems like a good idea. I was just curious as to what you did because I had thought that the configure options would do this but your earlier post gave me the impression that you had to look a little deeper and tweak something.

I have never really been a fan of gnome-mplayer but it is always worth including as it is small, plus of course you need it if you want to run the gecko-mediaplayer browser plugins.

In the configure script there is about 6-7 lines of code where it checks your system ffmpeg to see if compatible, I removed that and then it worked.
I uploaded the sources to
http://smokey01.com/ttuuxxx/WoofCe/mpla ... -09.tar.gz
ttuuxxx

OK, thanks for that, will take a look.

OscarTalks wrote:
To anyone using my Wheezy VLC in Stretch, thinking about it, I would expect some of the codecs and other functions not to work because the libav libraries will be mismatched.

Hi Oscar,

Do I have really to go to mplayer now, lol? I have gotten to like the vlc wheezy .pet of yours (ever since Musher mentioned it worked fine in these dpup-stretches builds), easily adding it via the .pet afterwards. For the few videos I've thrown at this VLC, they've played good, with sound. Haven't, though, thrown any of the .mkv and other assorted weird video formats I have on other drives.

Here's is the small Mplayer version that uses the systems ffmpeg 1.8Mb pet http://smokey01.com/ttuuxxx/WoofCe/mpla ... 9-i386.pet

and here is the latest Gnome Mplayer GUi for Mplayer http://smokey01.com/ttuuxxx/WoofCe/gnom ... b-i386.pet 223kb pet
ttuuxxx

BUILD_FROM_WOOF='testing;791a7b98;2017-03-11

# uname -a
Linux puppypc10766 4.9.13 #1 SMP PREEMPT Sat Mar 11 18:40:11 EET 2017 i686 GNU/Linux

I stole DOTconfig from xenialpup, thank you 666philb, heh.

Mavrothal`s magic bites. The binaries look like binaries now in Rox. Elfedit hack has worked.
There is now cc symlink in devx.sfs.

Kernel-kit with 4.9.13 DOTconfig compiled working kernel ( in use now when writing ) which installed succesfully to the build from inside the kernel-kit.

Woof-ce creates now working dpup stretch ready for installing additional stuff....

EDIT. I installed as test Firefox 52.0. Then I compiled apulse. In terminal: apulse firefox
but the youtube videos didnt even start to play after using apulse command. So it looks like Firefox 52.0 is mute now.

pemasu wrote:BUILD_FROM_WOOF='testing;791a7b98;2017-03-11

Any chance to put it up somewhere?

belham2 wrote:

OscarTalks wrote: To anyone using my Wheezy VLC in Stretch, thinking about it, I would expect some of the codecs and other functions not to work because the libav libraries will be mismatched.

Hi Oscar,

Do I have really to go to mplayer now, lol? I have gotten to like the vlc wheezy .pet of yours (ever since Musher mentioned it worked fine in these dpup-stretches builds), easily adding it via the .pet afterwards. For the few videos I've thrown at this VLC, they've played good, with sound. Haven't, though, thrown any of the .mkv and other assorted weird video formats I have on other drives.

Hi guys.

Just a word to mention that OscarTalks's sfs of vlc-wheezy also works
fine in this Stretch too.

I find that mplayer sometimes doesn't play all the "chapters" in a video,
and that's frustrating.

It never happens with vlc. (In my experience.)

BFN.