live, I just installed Python 2.6 and Openshot 1.3.1 from the Puppy Package Manger and it seemed to work. It started and loaded and played an mp4 video anyway. (I am using the pre-266 luci though.)

You must install python first, and you must ignore the errors. I am irritated with PPM because those are not real errors--the libraries are just not where PPM expects them to be. Sometimes I can do some slight of hand to conceal the "errors" but not in the case of Openshot. I have requested the ability to turn the error checking off because all of the packages in the puppy-lucid repo are checked already, but that hasn't happened. Any hackers???

I did the same procedure as for Pup525 and of course Python was first installed.

Quote:

The errors you show are missing Qt files--perhaps you had a different Openshot?

At the top of the current first post of this thread it mentions right-click. I had assumed that this meant that right-click was installed out-of-the 265-box. I was also under the impression that right-click was a development of Rox-right-clicks, originated by HairyWill. However, I must be wrong, because Rox-right-clicks created a separate, customised Open-with right-click option for each mime-type. By contrast, the open-with sub-menu of the Rox right click menu is always the same. Does this menu seem sensible for a directory to anyone?

A properly customised open-with menu would IMHO be a major usability enhancement to Puppy. It is a bit hard to see why this was not made standard some time ago. Alternatively, in 432 Official, ttuuxxx used the customisable area at the top of the right click menu to provide much the same enhancement.

The customisable area is user-modifiable but is a PITA to use, because, contrary to what is said in the Rox manual, you have to make a wrapper script to open the clicked file or directory.

playdayz and rerwin,
Regarding extra drivers, I seem to recall that you have already included a few of my fixed/upgraded drivers?
From the "Extras for Puppy 5.1" thread, I consider the important updates to be:

Most of the other drivers in that thread are for very recent hardware, and the value of adding them seems to be offset by the fact that new hardware and drivers are appearing all the time. If you added my Realtek wifi drivers, for example, there's a fair chance that several new Realtek devices would appears shortly afterwards, and the Realtek drivers require immediate updating to support them.

So the only additional driver I consider worthy of adding would be "acx-old-k2.6.33.2.pet". This supports a range of wifi devices which are quite common, and these devices are otherwise unsupported in Lucid 5.x.

But hold the presses!
There's an important wifi firmware update necessary for certain (old) orinoco-based wifi devices.
I now attach the orinoco firmware package, which should be located in /lib/modules/all-firmware
Then a corresponding new line needs to be added to /etc/modules/firmware.dep.2.6.33.2

Code:

orinoco_firmware:orinoco.ko

And while on the subject of "firmware.dep.2.6.33.2" I'm hoping you have already changed it as per my suggestion several months ago, from

Just to be clear; "N300" describes a wifi mode, not a model number.
Any Belkin device with "N300" in its description will still have a separate model number. To be able to help you with a suitable driver, I need to know the model number ... better still, give me the USB device ID.

rerwin wrote:

Although rt3572sta supports several Belkin (050d) devices, the N300 (945a) is not among them.

Again, let's be clear about various devices in question; USB device ID 050d:945a is the Belkin F7D1101 v1000.
This particular device is supported by the Realtek (not Ralink) 8712u driver, available here -
http://www.murga-linux.com/puppy/viewtopic.php?p=462469#462469
... but are we sure that's the device that Jim1911 has?

In order to make a simple mouse cursor switch, clicking on pcur tells you to first go to the PPM and download some cursor themes. In 265, as in all other Puppies I have tried, this means downloading nearly 41MB of crud! This is nearly 1/3 the size of the entire Lupu ISO to change a 330 byte file! A 125,000-fold overkill.

It is faster and takes less keystrokes to copy a cursor from the Help file of the PupSnap screen capture utility

I liked mikeB's comment on this; "It's supposed to be Puppy, not Great Dane Linux"

Just to be clear; "N300" describes a wifi mode, not a model number.
Any Belkin device with "N300" in its description will still have a separate model number. To be able to help you with a suitable driver, I need to know the model number ... better still, give me the USB device ID.

rerwin wrote:

Although rt3572sta supports several Belkin (050d) devices, the N300 (945a) is not among them.

Again, let's be clear about various devices in question; USB device ID 050d:945a is the Belkin F7D1101 v1000.
This particular device is supported by the Realtek (not Ralink) 8712u driver, available here -
http://www.murga-linux.com/puppy/viewtopic.php?p=462469#462469
... but are we sure that's the device that Jim1911 has?

Hi tempestuous,

Sorry, that I didn't provide the proper numbers, however, I don't know where to find them. 01micko's latest spup does work with my wireless adapter and it uses the 8712u driver. I'll give it a try with 265, however, it'll be a while before I can do it.

EDIT: The 8712u driver above works fine, posting this edit using the new wireless connection.

Thanks,
JimLast edited by Jim1911 on Thu 21 Jul 2011, 18:32; edited 2 times in total

Sorry, that I didn't provide the proper numbers, however, I don't know where to find them.

Pupscan should show it, in the USB listing when you click the USB-related button.

tempestuous wrote:

Again, let's be clear about various devices in question; USB device ID 050d:945a is the Belkin F7D1101 v1000.
This particular device is supported by the Realtek (not Ralink) 8712u driver, available here -
http://www.murga-linux.com/puppy/viewtopic.php?p=462469#462469
... but are we sure that's the device that Jim1911 has?

Thanks for clarifying that. I took the ID from a googled posting somewhere that seemed to address the issue. So it is not necessarily what Jim1911 has. Sorry for my misconception and misdirection.
Richard

These are added. The orinoco and iwlagan pets had the files in /lib/firmware, which is where I put them.

Quote:

So the only additional driver I consider worthy of adding would be "acx-old-k2.6.33.2.pet". This supports a range of wifi devices which are quite common, and these devices are otherwise unsupported in Lucid 5.x.

This is added.

Quote:

But hold the presses!
There's an important wifi firmware update necessary for certain (old) orinoco-based wifi devices.
I now attach the orinoco firmware package, which should be located in /lib/modules/all-firmware

As I said, this seemed to go into /lib/firmware instead of /lib/modules/all-firmware.

Quote:

Then a corresponding new line needs to be added to /etc/modules/firmware.dep.2.6.33.2

Code:

orinoco_firmware:orinoco.ko

Done.

Quote:

And while on the subject of "firmware.dep.2.6.33.2" I'm hoping you have already changed it as per my suggestion several months ago, from

Code:

rt2870sta-fw:rt2870sta.ko

to

Code:

rt2870sta-fw:rt2870sta.ko,rt2800usb.ko

Done.

I will double-check after building because Woof has a weird habit of replacing files in all-firmware.

And of course, I will rebuild if I am wrong about where the orinoco and iwlagn firmware goes.Last edited by playdayz on Thu 21 Jul 2011, 12:01; edited 1 time in total

As I said, this seemed to go into /lib/firmware instead of /lib/modules/all-firmware.

Let me explain the situation.

1. The firmware file that is to be loaded into the hardware has to exist in /lib/firmware -- when needed.

2. Most of such files are already there, permanently.

3. A few firmware files are placed into /lib/firmware by "firmware" tarballs maintained in /lib/modules/all-firmware. It seems unfortunate that Barry chose an alternate meaning to "firmware" for those tarballs, because it is misleading. The tarballs do whatever is necessary once a driver has been identified to be loaded. The "_firmware" tarballs contain the actual firmware files and cause them to be placed into /lib/firmware.

4. The /etc/modules/firmware.dep.* file needs to be updated only if a firmware-tarball is involved. Its entries make the connection between driver-modules and "all-firmware" tarballs. But installing actual firmware files permanently in /lib/firmware makes the tarball unnecessary. It would be necessary if some additional actions were required before the actual loading of the related driver module.

So, I conclude that no matter which technique is used, the firmware is compressed either in a tar.gz file or in the main/zdrv SFS file. I see the only advantage to using the intermediate tarball would be if a zdrv SFS file were used, because the firmware would not get loaded into RAM (in the main file) for everyone. Currently, the /lib/firmware directory is about a megabyte in size, uncompressed.
Richard

Will the 'final' have these umount enhancements (please) http://bkhome.org/blog/?viewDetailed=02360

+1

1+

That's easy for y'all to say. Any chance someone could make a pet?

Barry said something about changes in scripts, but didn't specify what changes.
But they are in woof and that woof will be uploaded soon. _________________Time savers:
Find packages in a snap and install using Puppy Package Manager (Menu).
Consult Wikka
Use peppyy's puppysearch

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum