Quirky Pyro64 version 0.6 (alpha) -- and Pyro32 0.5

[don570]

Here is quick solution to the cluttered open file window....

I commented out all the lines in fstab file and the puppy still booted fine

Code: Select all

#none          /proc        proc     defaults               0 0
#none          /sys         sysfs    defaults               0 0
#none          /dev/pts     devpts   gid=2,mode=620         0 0
#/dev/fd0      /mnt/floppy  auto     noauto,rw              0 0

This cleaned up my file open window.

However there was a complaint while booting that 'pts' wasn't defined.
____________________________________________________

[don570]

Blender 2.7.8 worked.
That means that there is no problem with openGL 2.1

https://builder.blender.org/download/
_______________________________________________

[don570]

gimp app can use gmic plug-in v1.7.9
-includes fftw3

Available:
4mb
https://drive.google.com/open?id=1-TGcu ... bk6h_A6rgp
_____________________________________

[don570]

A new version is available at git
mtpaint version 3.49.13

@wjaguar wjaguar Version 3.49.13

Updated & fixed packaging for Windows
Fixed compilation for GTK+1
Added workaround for KDE's "dialogparent" effect
Other assorted fixes

______________________________

[davids45]

G'day,

Here is quick solution to the cluttered open file window....

I commented out all the lines in fstab file and the puppy still booted fine

Code:
#none /proc proc defaults 0 0
#none /sys sysfs defaults 0 0
#none /dev/pts devpts gid=2,mode=620 0 0
#/dev/fd0 /mnt/floppy auto noauto,rw 0 0

In my Frugal Pup of Pyro32, I can confirm that by clearing the contents of the fstab file in /etc, I have a cleaner 'Places' panel when wanting to 'Open file' in, say, gimp.

This default listing of unwanted 'Places' (to look for files to open as a user) seems to be a problem (well, a minor iritation) only in recent StretchPups as well as Pyro, but not Ubuntu-Pups such as Xenial and Artful, nor in Slacko.

Re Pyro32-0.5:
I could not get a Pyro32 Full install to boot and run (blinking cursor on black screen) after installing from this Frugal or a Live-DVD (both of which do run). With just under 2GB RAM, maybe that's not enough for a Full? I tried an 8GB ext4 partition which ended up with well under 2GB of installed files for the Full (last screenshot).
As the Frugal Pyro32 seems not to utilise sfs as in normal Pups, the Frugal Pyro is at a big disadvantage when all my packages/applications are in sfs formats.

Waiting with interest to try Pyro32-0.6.

David S.

[BarryK]

Re Pyro32-0.5:
I could not get a Pyro32 Full install to boot and run (blinking cursor on black screen) after installing from this Frugal or a Live-DVD (both of which do run). With just under 2GB RAM, maybe that's not enough for a Full? I tried an 8GB ext4 partition which ended up with well under 2GB of installed files for the Full (last screenshot).
As the Frugal Pyro32 seems not to utilise sfs as in normal Pups, the Frugal Pyro is at a big disadvantage when all my packages/applications are in sfs formats.

Waiting with interest to try Pyro32-0.6.

David S.

Pyro32 0.6.1 will be uploaded soon.

For SFSs, Easy OS is the way to go. I will do a new build of Easy soon.

Yeah, that blinking cursor on blank screen is odd, I have sometimes got that too.
JWM must be running. I have asked Joe, the author of jwm, for any thoughts on that.

I am using jwm 2.3.7, which has at least two bugs, that I have informed Joe about.

I wonder if get that blank screen if I roll jwm back to rev 976 (the version I used for years, until this year).

[technosaurus]

Yeah, that blinking cursor on blank screen is odd, I have sometimes got that too.
JWM must be running. I have asked Joe, the author of jwm, for any thoughts on that.

I am using jwm 2.3.7, which has at least two bugs, that I have informed Joe about.

I wonder if get that blank screen if I roll jwm back to rev 976 (the version I used for years, until this year).

I didn't see an issue on GitHub. Joe has been really good about handling issues posted there. His source code is relatively easy to follow and since it is all in git, its easy to bisectinate to the last known working version to see what code may be causing the issue. BTW there are some differences in XML in recent versions​ that can be fixed by applying the xslt included in the source. I log on to GitHub daily and jwm is on my notifications, so if you post the issue there, I will have a look.

[BarryK]

Yeah, that blinking cursor on blank screen is odd, I have sometimes got that too.
JWM must be running. I have asked Joe, the author of jwm, for any thoughts on that.

I am using jwm 2.3.7, which has at least two bugs, that I have informed Joe about.

I wonder if get that blank screen if I roll jwm back to rev 976 (the version I used for years, until this year).

I didn't see an issue on GitHub. Joe has been really good about handling issues posted there. His source code is relatively easy to follow and since it is all in git, its easy to bisectinate to the last known working version to see what code may be causing the issue. BTW there are some differences in XML in recent versions​ that can be fixed by applying the xslt included in the source. I log on to GitHub daily and jwm is on my notifications, so if you post the issue there, I will have a look.

I contacted him by email. Yeah, I should have raised them as issues on github.

[BarryK]

Pyro32 0.6.1 is out:

http://bkhome.org/news/201712/quirky-py ... eased.html

Printing and PPLOG should now be working.

[foxpup]

The wifi persistence problem is still there in pyro-0.6, for me. Am I the only one?
Could the output in console, running rc.network, be of any help to solve it? There is an error "ifconfig: SIOCSIFFLAGS: Unknown error 132" which looks like a clue. When I google this error the solution is often something with rfkill.

The problem in pyro seems worse then in xenial or slacko: clicking the saved wlan0 in SNS does work in the latter, but not in pyro. Same for running rc.connect. It seems worse, but maybe it isn't. charlie6 reports for xenial7.5 32bit that his wlan0 keeps blocked.

Frisbee also does not work for me in pyro, it doesn't even connect at all. Frisbee does work in xenial7.5, and persists over reboots.

[BarryK]

Yeah, that blinking cursor on blank screen is odd, I have sometimes got that too.
JWM must be running. I have asked Joe, the author of jwm, for any thoughts on that.

I am using jwm 2.3.7, which has at least two bugs, that I have informed Joe about.

I wonder if get that blank screen if I roll jwm back to rev 976 (the version I used for years, until this year).

I didn't see an issue on GitHub. Joe has been really good about handling issues posted there. His source code is relatively easy to follow and since it is all in git, its easy to bisectinate to the last known working version to see what code may be causing the issue. BTW there are some differences in XML in recent versions​ that can be fixed by applying the xslt included in the source. I log on to GitHub daily and jwm is on my notifications, so if you post the issue there, I will have a look.

I contacted him by email. Yeah, I should have raised them as issues on github.

This is the email that I sent to Joe:

Joe,
I used jwm 976 for ages, then this year upgraded to v2.3.7.

Have found at least two bugs.

1.
jwm crashes when starting 'xcalc'. This is due to missing
/usr/include/X11/bitmaps/calculator

This is also discussed on the puppy forum:

http://murga-linux.com/puppy/viewtopic. ... 9b1#906675

rev 976 does not crash when that file is missing, and xcalc works.

I couldn't see anything in the jwm changelog since 2.3.7 that fixes this.

2.
This is an odd one. In Quirky 0.5/06, using jwm 2.3.7, one of the
icons does not display in the menu.

Everything is setup correctly. the pavrecord.desktop file has
"Icon=mini-record.xpm" and the .jwmrc has the path to the icon, but it
does not display. (see Multimedia menu in Quirky).

Other icons in that same location do display.

There is nothing wrong with mini-record.xpm, it does display as the
icon for 'pavrecord.desktop' in the rox-filer window. It also
displayed in jwm 976.

If you want to see this in action, Quirky Pyr64 0.6 has it:

http://bkhome.org/news/201711/quirky-py ... eased.html

3.
Even odder. Sometimes, at startup just get a blank screen with mouse
pointer. jwm must be running, as if not, X will terminate.

Not sure that jwm is to blame for that one, will need to try and
isolate the cause.

It might help if I attach that icon.

Regards,
Barry

[technosaurus]

2.
This is an odd one. In Quirky 0.5/06, using jwm 2.3.7, one of the
icons does not display in the menu.

Everything is setup correctly. the pavrecord.desktop file has
"Icon=mini-record.xpm" and the .jwmrc has the path to the icon, but it
does not display. (see Multimedia menu in Quirky).

Other icons in that same location do display.

There is nothing wrong with mini-record.xpm, it does display as the
icon for 'pavrecord.desktop' in the rox-filer window. It also
displayed in jwm 976.

If you want to see this in action, Quirky Pyr64 0.6 has it:

http://bkhome.org/news/201711/quirky-py ... eased.html

Its not an xpm. Its a png. Jwm added some optimizations to use the appropriate library based on file extensions if it has one. I could probably patch it to detect magic@offset instead, but in the mean time, just rename it to mini-record.png or convert it to an actual xpm. FWIW, when I converted all of the png images to xpm and used squash with xz compression (another pupngo experiment), the resulting sfs was actually smaller.

3.
Even odder. Sometimes, at startup just get a blank screen with mouse
pointer. jwm must be running, as if not, X will terminate.

Not sure that jwm is to blame for that one, will need to try and
isolate the cause.

Sounds like X is not fully started when jwm starts. There are a few possible solutions.
1 Add -display :0 to the wm command line.
2 Use a little tiny-core-linux program called waitforX (which continually tries XopenDisplay()).
3 Add a while loop in the xinitrc to wait for /tmp/.X11-unix/X0 (when the unix socket is in place XopenDisplay() should work)

Code: Select all

while ([ ! -S /tmp/.X11-unix/X0 ]) do sleep .1;done 
jwm -display :0

I'd have to look at #1, but in the mean time I could just patch xcalc to use the bitmap as builtin data rather than needing an external file ... or put the data in a sane place like /usr/share/xcalc/calculator so it doesn't get DEVX'ed

Edit Xcalc uses libXaw which seems to be causing the problem:
https://cgit.freedesktop.org/xorg/lib/l ... c/Pixmap.c so this may be related to jwm's title bar icon changes from a while ago.
Edit2: Debian uses /usr/share/x11/bitmaps/

[rockedge]

strange you mention the blank screen with blinking cursor....I am experiencing this with new builds of Xenialpup 32 bit built with woof-CE testing recently. nothing is responsive but when power button is pressed the test sound is played (similar to woof-woof)

no noticeable errors and does it also when the computer is idle, suddenly black screen blinking cursor and hard power off is the only fix.

[technosaurus]

strange you mention the blank screen with blinking cursor....I am experiencing this with new builds of Xenialpup 32 bit built with woof-CE testing recently. nothing is responsive but when power button is pressed the test sound is played (similar to woof-woof)

no noticeable errors and does it also when the computer is idle, suddenly black screen blinking cursor and hard power off is the only fix.

That sounds like the screensaver kicking in and then not recovering properly. What Xorg video driver is getting autodetected? Or are you using Xvesa/xfbdev?

[BarryK]

2.
This is an odd one. In Quirky 0.5/06, using jwm 2.3.7, one of the
icons does not display in the menu.

Everything is setup correctly. the pavrecord.desktop file has
"Icon=mini-record.xpm" and the .jwmrc has the path to the icon, but it
does not display. (see Multimedia menu in Quirky).

Other icons in that same location do display.

There is nothing wrong with mini-record.xpm, it does display as the
icon for 'pavrecord.desktop' in the rox-filer window. It also
displayed in jwm 976.

If you want to see this in action, Quirky Pyr64 0.6 has it:

http://bkhome.org/news/201711/quirky-py ... eased.html

Its not an xpm. Its a png. Jwm added some optimizations to use the appropriate library based on file extensions if it has one. I could probably patch it to detect magic@offset instead, but in the mean time, just rename it to mini-record.png or convert it to an actual xpm. FWIW, when I converted all of the png images to xpm and used squash with xz compression (another pupngo experiment), the resulting sfs was actually smaller.

Ha ha, I didn't even check! Just assumed, as it had .xpm extension, that is what it is.

Now, how did that come about I wonder? And my memory, though vague at times, is that the icon did used to display sometime ago.

Thanks for that, will fix, and will let Joe know.

[BarryK]

strange you mention the blank screen with blinking cursor....I am experiencing this with new builds of Xenialpup 32 bit built with woof-CE testing recently. nothing is responsive but when power button is pressed the test sound is played (similar to woof-woof)

no noticeable errors and does it also when the computer is idle, suddenly black screen blinking cursor and hard power off is the only fix.

In my case, I got a blank screen with mouse cursor, that was moveable.

But yeah, have had that situation in the past also, the blinking cursor.

[BarryK]

3.
Even odder. Sometimes, at startup just get a blank screen with mouse
pointer. jwm must be running, as if not, X will terminate.

Sounds like X is not fully started when jwm starts. There are a few possible solutions.
1 Add -display :0 to the wm command line.
2 Use a little tiny-core-linux program called waitforX (which continually tries XopenDisplay()).
3 Add a while loop in the xinitrc to wait for /tmp/.X11-unix/X0 (when the unix socket is in place XopenDisplay() should work)

Code: Select all

while ([ ! -S /tmp/.X11-unix/X0 ]) do sleep .1;done 
jwm -display :0

Yes, I found that source yesterday, waitforX.c:

https://sourceforge.net/projects/tinyco ... lease/src/

Then I discovered that goingnuts was looking for that source sometime ago:

http://www.murga-linux.com/puppy/viewto ... 269#549269

...I sent him a pm.

jwm is called from ~/.xinitrc, and X is supposed to be running by then. I wonder though, if sometimes it is not quite ready. In which case, that waitforx would be good to put into .xinitrc.

[davids45]

G'day,

Made a live-CD of Pyro32-0.6 which was good, then installed to 8GB partition (where I had had no luck with version 0.5).

Pyro32 booted up and runs very well, with some extra pets added and some other packages running as sym-links from my mounted sda5 data partition (screenshot).

CUPS has a problem with PDF printer 'backend' (screenshot) and my networked Epson XP200 printer wouldn't print even after trying rcrsn51's usual fixes that have usually worked (screenshot).

The inkgui program only works if I connect via usb; networking the printer and 'No printer found'

Scanning seems to have a problem as well with the XP-200, iscan and peasyscan taking a very long time to respond (about half a minute) if at all. Initially, I had to add some library files (from my ad-hoc archive) to get iscan to start so maybe these library files were not fully compatable

The 'Open file' 'Places' panel has some unwanted (by me) places, an issue with StretchPups but not Xenials and Slackos.

All in all, as just a 'user', pretty good for a 0.6 version Full Pup.

David S.

[technosaurus]

Yes, I found that source yesterday, waitforX.c:

https://sourceforge.net/projects/tinyco ... lease/src/

Here is a shell function to replace waitforX

Code: Select all

waitforX(){
  while ([ ! -S /tmp/.X11-unix/X0 ]) do sleep .1;done 
}

On second though, if you run multiple Xservers this may work better

Code: Select all

waitforX(){
  #usage: waitforX [display number]
  while ([ ! -S /tmp/.X11-unix/X${1:-0} ]) do sleep .1;done 
}

[BarryK]

CUPS has a problem with PDF printer 'backend' (screenshot) and my networked Epson XP200 printer wouldn't print even after trying rcrsn51's usual fixes that have usually worked (screenshot).

Oh curses, just when I was congratulating myself on having fixed printing!

But then, I fixed it in Pyro64, didn't test Pyro32 build.

Also, my printer is local, and uses foomatic, not gutenprint.

Can you test with a local printer?

Note, I don't think that missing "pdf-writer" matters. The print-to-file should still work.