(old)Puppy Linux Discussion Forum

I don't tell xorg what resolution to pick. Automatic desktop means it's luck of the draw.

Thanks for putting that straight. Curious that it's not a problem with others? Any chance of a cheat code workaround? Or is there an HW fix? Newish (ie newer than Cirrus Logic!) nV cards would seem to be an issue? Think I've read similar problems previously that were eventually circumvented?
[Wales 24 Italy 3]
[Ireland 32 Scotland 14]

Hi jemimah & all:

Jemimah Quote:
I'm not sure where you got your gnome-mplayer. The one in the repo lists these dependencies: +gtk+,+dbus,+dbus-glib,+mplayer which all should be fine.

I've been exploring builder since version 1, at which time I created a folder for pets I wanted to include in adrive. I guess at that time, not finding gnome-mplayer in Saluki's repo, I placed a gnome-mplayer pet from wary/racy/quirky? into that folder. I hadn't realized it was still being used until you asked: since replaced.
Thanks for the new wine 1.4 pet. If anyone doesn't already know, Wine.org uses an odd-even numbering system to distinguish their apps. Those with even numbers following the "." are considered stable after long testing and debugging of their test versions which are given odd numbers after the ".". 1.4 is the result of about 2 years of testing. I recommend anyone still using 1.3 to upgrade.

mikesLr

jemimah wrote:

mavrothal wrote:Thunar defaults to SFS_load for SFSs instead of the "traditional" filemnt.
However, if you accept the default and mount another puppy sfs your system is wasted till you fix /etc/rc.d/BOOTCONFIG.
I was wondering if filemnt is a better default or if SFS_load should refuse to load another puppy main sfs.

I'm not sure how I would tell which sfses should not be union mounted.

I would think /sbin/init is pretty universal in main sfses. Though just changing thunar's defaults may be easier

If I had known you were going to compile scribus, I wouldn't have done it yesterday. Doh!

Where did 1.4.1 come from? The latest on the scibus sourceforge site is 1.4.0.

I have tried to sort out the Python_DEV pet. I have reuploaded Python and Python_DEV. See if you can make scribus see this version.

I'm not sure if ghostscript should be listed as a dependency since it's installed with the printer-scanner sfs. Maybe a message about it in the pinstall script would be best.

I missed podofo in my build. I think we do certainly want it.

Let me know if you get the python problem sorted and I'll upload your scribus to the repo.

pemasu wrote:It is time to start publishing international Saluki News daily newspaper and to creat Saluki business Cards. Lobster has promised to be the chief editor and Sage has promised to be critic reviewer....joke...

I have compiled the Scribus-1.4.1 and podofo for pdf support in it. It needs scribus-1.4.1. pet + qt-4.8.0 + podofo + ghostscript + python_DEV + aspell.
Python came from devx.sfs and it was the 2.6.4 version from wary5 repo. Sorry, not the jemimah's newer 2.7.2. I dont have knowledge to overwrite devx.sfs version.
Pet.specs file dependencies finds all the other but I couldnt get python_DEV-2.6.4 from wary repo to be seen as dependency, not sure why.
If podofo-0.9.1 will be copied along scribus-1.4.1 pet to the saluki repo, all other dependencies will be downloaded when you accept the chase for them.

Download link:http://smokey01.com/pemasu/Saluki/Saluki-pets/scribus/

Scribus is an Open Source program that brings professional page layout to Linux desktops with a combination of press-ready output and new approaches to page design.
Underneath a modern and user-friendly interface, Scribus supports professional publishing features, such as color separations, CMYK and Spot Color support, ICC color management, and versatile PDF creation

http://wiki.scribus.net/canvas/Help:TOC

http://www.google.com/search?q=youtube% ... %20scribus

Sage wrote:

I don't tell xorg what resolution to pick. Automatic desktop means it's luck of the draw.

Thanks for putting that straight. Curious that it's not a problem with others? Any chance of a cheat code workaround? Or is there an HW fix? Newish (ie newer than Cirrus Logic!) nV cards would seem to be an issue? Think I've read similar problems previously that were eventually circumvented?
[Wales 24 Italy 3]

The cheat code is pfix=nox then run xorgwizard from the prompt.

mavrothal wrote:

jemimah wrote:

mavrothal wrote:Thunar defaults to SFS_load for SFSs instead of the "traditional" filemnt.
However, if you accept the default and mount another puppy sfs your system is wasted till you fix /etc/rc.d/BOOTCONFIG.
I was wondering if filemnt is a better default or if SFS_load should refuse to load another puppy main sfs.

I'm not sure how I would tell which sfses should not be union mounted.

I would think /sbin/init is pretty universal in main sfses. Though just changing thunar's defaults may be easier

Definitely easier - but this way I get no posts from newbies who can't figure out how to load sfs file. I'm not sure which is worse.

Perhaps I'll add a dialog asking which action you want.

Source code for compilation
See Official:Compile_with_CMake for building instructions.
Stable branch:
Download and compile the 1.4.x sources if you know that it contains a patch for a bug you're facing in Scribus 1.4

svn://scribus.net/branches/Version14x/Scribus - Scribus 1.4.1svn (developmental).
svn checkout svn://scribus.net/branches/Version14x/Scribus your14ScribusDirectory

I didnt say I used latest stable. I compiled stable enough development version, not the 1.5 developmental version which would have been probably near suicide.

The problem. Saluki devx sfs has wary5 2.6.4 python...I am not sure what happens if I install those Python-2.7.2 pet and DEV pets. Would the scribus see the later ones or will it still be asking after the older version...I am not familiar with python and I absolutely dont want to be. Since scribus compiles without any python understanding...it didnt disturb me. I have to confess that normally nowadays I avoid python apps like plague. Compiling py-gtk was enough for me....well not compiling but to get python understand that I had compiled it that I wanted python to find it. Well...I remember one command for ever: update-python-modules....

Since I have all the needed stuff in place....I will test the newer python by installing those pets and lets see.
It might be good idea to update the python in devx sfs ?

pemasu wrote:Since I have all the needed stuff in place....I will test the newer python by installing those pets and lets see.
It might be good idea to update the python in devx sfs ?

I should do that. I'm just not sure if Barry does anything special for the devx version. I'll try it for the next release.

Installing the pets does make programs see the new version and not the devx version.

jemimah wrote:

DaveS wrote:Having a really strange time with 14. Wireless network has become a real toss of the coin. Sometimes it finds the network interface wlan0, sometimes not. A reboot is the only way I can make it connect. 13 did not behave this way. What changed?

I need more info. Can you run the wireless diagnostics program both when it's working and when it's not working and post the results?

If it's greyed out you can run the diagnositc program from the command line with

Code: Select all

/usr/local/Frisbee/pnetworkdiag

Jemimah, I vaguely remember this from a pup in the past. I think Frisbee looks for wlan before the pc has detected it. Answer was to put a sleep line in frisbee start up script. Will look into it.

DaveS wrote:

jemimah wrote:

DaveS wrote:Having a really strange time with 14. Wireless network has become a real toss of the coin. Sometimes it finds the network interface wlan0, sometimes not. A reboot is the only way I can make it connect. 13 did not behave this way. What changed?

I need more info. Can you run the wireless diagnostics program both when it's working and when it's not working and post the results?

If it's greyed out you can run the diagnositc program from the command line with

Code: Select all

/usr/local/Frisbee/pnetworkdiag

Jemimah, I vaguely remember this from a pup in the past. I think Frisbee looks for wlan before the pc has detected it. Answer was to put a sleep line in frisbee start up script. Will look into it.

I just find it odd that this would start happening right after a frisbee update.

Zigbert says that pfind is compatible with Saluki.

http://murga-linux.com/puppy/viewtopic. ... &start=405

_______________________________________

Pfind is included in the base system.

Sleep command did not help. Diagnostics herewith.

Pfind is included in the base system.

...but do all the features work?? Zigbert says yes.

_____________________________________

DaveS,

Here is the difference.

Working:
Not working:
I have no idea why it would sometimes find the firmware and sometimes not.

What are you doing to make it work vs not work?


EDIT: The one thing I did change that might have affected this is I installed Mavothal's fixed udev pet. I'll roll it back for the next release and see if your problem goes away.

don570 wrote:

Pfind is included in the base system.

...but do all the features work?? Zigbert says yes.

_____________________________________

It should be fine. The rox command opens thunar unless you install rox.

I tested scribus compile again. First I sfs_loaded devx sfs. Then your both Python-2.7.2 pets. Then all the rest pet packaged needed dependencies. I cooked scribus again and I made a pet of whole lot, not stripping and splitting. I made your Python as dependency to pet.specs...with the rest needed of course.
Reboot with fresh install. Podofo only installed first...it is not in saluki or wary5 repo. The I installed the scribus...it did find your Python-2.7.2 pet and installed it. In console scribus and.... They exist in devx sfs, I copied just them....
Oh well...it seems that the devx sfs python stuff interferes the compiling. Can I just delete those libpython2.6 lib and symlink...before I configure scribus for compiling...and would it help....your Python pets does not have similar libpython2.7 lib and symlink.

pemasu wrote:I tested scribus compile again. First I sfs_loaded devx sfs. Then your both Python-2.7.2 pets. Then all the rest pet packaged needed dependencies. I cooked scribus again and I made a pet of whole lot, not stripping and splitting. I made your Python as dependency to pet.specs...with the rest needed of course.
Reboot with fresh install. Podofo only installed first...it is not in saluki or wary5 repo. The I installed the scribus...it did find your Python-2.7.2 pet and installed it. In console scribus and....

Code: Select all

# scribus
scribus: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory

They exist in devx sfs, I copied just them....

Code: Select all

# scribus
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Failed to set default encoding to utf-8.

Failed to import warnings module. Something is probably broken with your Python.
Traceback (most recent call last):
  File "<string>", line 2, in <module>
ImportError: No module named warnings

Oh well...it seems that the devx sfs python stuff interferes...

It should be linking against libpython2.7.a. Try deleting libpython2.6.so*. Or I guess just wait until I post the updated devx for saluki-015.

I would like to wait your updated devx sfs and you would get good reason to update. I will compile scribus when the python has been unified. Win-win-situation.