Fatdog64-511

Message

Billtoo · #136 Post by **Billtoo** » Mon 07 Mar 2011, 13:22

xfe-1.32.2-x86_64.pet (X File Explorer) is similar to midnight
commander, it needs fox-1.6.43-x86_64.pet installed as well or it
won't run.

jamesbond · #137 Post by **jamesbond** » Tue 08 Mar 2011, 01:13

No worries Roy.
I wish I can make skype works on your machine

I've mirrored all the files in this thread (including the latest xfe pets from Billtoo) in mydrive.ch (details on page 7) as a staging area before moving it to official pet repository at ibiblio.

cheers!

Billtoo · #138 Post by **Billtoo** » Tue 08 Mar 2011, 15:54

lpairs-1.0.4-x86_64.pet is a memory game.

rcrsn51 · #139 Post by **rcrsn51** » Tue 08 Mar 2011, 17:39

The printer driver package foo2xxx relies on udev to download firmware to the printer. While attempting to get this working, I discovered that udev was ignoring any rules I added. I also noticed that 55-cups.rules, which is supposed to be necessary for CUPS, is also not working. Somehow, FD64 is printing in spite of this.

Has anyone tried using hardware like modems in FD64 that relies on udev rules? Did you get it to work?

[Edit] I suspect the problem is that the module usblp is not available.

kirk · #140 Post by **kirk** » Wed 09 Mar 2011, 02:30

[Edit] I suspect the problem is that the module usblp is not available.

CUPS 1.4.x has a new USB backed that requires usblp not to be loaded.

jamesbond · #141 Post by **jamesbond** » Wed 09 Mar 2011, 02:34

rcrsn51 wrote:Has anyone tried using hardware like modems in FD64 that relies on udev rules? Did you get it to work?

I used udev rules to configure wacom inputs for my tablet (ie, to create symlinks from actual device nodes). It works.

rcrsn51 · #142 Post by **rcrsn51** » Wed 09 Mar 2011, 02:38

Both Lupu and FD have CUPS 1.4. But Lupu creates device nodes like /dev/usb/lp0 correctly while FD does not. In Lupu, usblp is loaded when you plug in a USB printer.

IIRC, when you compile CUPS 1.4, you declare that it will not use usblp.

[Edit] I have a CUPS 1.4.4 PET compiled with "--disable-libusb" that I dropped into Quirky. The device nodes are created correctly and CUPS works.

kirk · #143 Post by **kirk** » Wed 09 Mar 2011, 19:47

I don't know if it will help, but I've attached the usblp module. This will normally break usb printing for Fatdog, but maybe it can work with rcrsn51 packages. I haven't tested this module, just loaded and unloaded it.

kirk · #144 Post by **kirk** » Wed 09 Mar 2011, 20:03

Debian has a patch for CUPS 1.4.x to allow usblp to coexist, so maybe a new version of CUPS for the next Fatdog64.

rcrsn51 · #145 Post by **rcrsn51** » Wed 09 Mar 2011, 22:02

I couldn't resolve this. I got different USB behaviours depending if I compiled CUPS 1.4 in Quirky or FD64. So I gave up.

[Edit] However CUPS 1.3.11 compiles and works fine in FD.

gcmartin · #146 Post by **gcmartin** » Wed 09 Mar 2011, 23:24

Running LiveCD FATDOG, I am experiencing a problem with the PPM's SeaMonkey V2.0.11.

I reported it here, indicating that I was using FATDOG, but have gotten no replies because, I believe, that it only relates to FATDOG's 64bit version.

I have tested various WARY implementations and other LIveCD PUPs without issues. So, it seems that maybe this is only related to 64bit at the moment.

Has anyone else seen this problem? Any advice.
P.S.

This is NOT a high priority as I have a circumvention, currently. But, it would be nice to check this for upcoming FATDOGs
This is NOT occurring in FATDOG's Namoroka. I can jump back and forth in a video.
SeaMonkey also indicates that "There are No new updates available..."

rcrsn51 · #147 Post by **rcrsn51** » Thu 10 Mar 2011, 01:30

rcrsn51 wrote:I couldn't resolve this. I got different USB behaviours depending if I compiled CUPS 1.4 in Quirky or FD64.

My mistake - I was using depmod wrong. If you install usblp and compile CUPS 1.4 with --disable-libusb, it works correctly.

gcmartin · #148 Post by **gcmartin** » Sat 12 Mar 2011, 17:18

@Kirk

I wanted to understand how to operate within the guidelines of the system's design for adding functionality that have been created for FATDOG in my running LiveDVDs. I have NOT experience any problems in using PPM for adding what it offers. The additions to the running system are saved via save-to-CD at reboot/shutdown. It has been very good since I discovered FATDOG last year.

BUT SFSs needs clarification in their use in FATDOG (at least for me).
2 Questions:

For LiveDVD, is there an "Official" approach to adding an SFS ("DEVX" for example) to the running system such that on LiveDVD reboot, it is present (I think it should be obvious that a user is saving the running system at shutdown)?

And
The PPM seems good for showing its installed extensions. What is the proper tool(s) which will show SFSs that are also added to the system?

Would you share how you feel these should be handled please. (These may have been answered somewhere else for FATDOG, but I can't find it.)

Thanks in advance.

kirk · #149 Post by **kirk** » Sun 13 Mar 2011, 17:46

I've only ran a multisession cd/dvd setup a couple times, and then just to test that it worked. I think that the only reason to run a multisession CD would be that you don't want to write to your hard drive. In that case I think you would have to remake the main sfs file with whatever other sfs files included. Again, I really haven't given it much thought or had any experience to speak of, maybe others have ideas.

gcmartin · #150 Post by **gcmartin** » Tue 15 Mar 2011, 19:04

kirk wrote:I've only ran a multisession cd/dvd setup a couple times, and then just to test that it worked. I think that the only reason to run a multisession CD would be that you don't want to write to your hard drive. I ... Again, I really haven't given it much thought or had any experience to speak of, maybe others have ideas.

Thanks for your help.

Based upon this, I would assume that FATDOG's current implementation (at least for LiveDVD) is one of a system that extends the base system with PETs that is provided for it. Thus, there is no OFFICIAL support for SFSs in LiveDVD operations in FATDOG.

Anyone else have ideas/contributions on this for LiveDVD use.

Thanks in advance for any help.

jamesbond · #151 Post by **jamesbond** » Sun 20 Mar 2011, 11:49

rcrsn51 wrote:
rcrsn51 wrote:I couldn't resolve this. I got different USB behaviours depending if I compiled CUPS 1.4 in Quirky or FD64.
My mistake - I was using depmod wrong. If you install usblp and compile CUPS 1.4 with --disable-libusb, it works correctly.

Interesting. Epson tools from cups doesn't work without usblp - and yet the same cups won't work with usblp (I'm talking about default cups in FD64). So if we can still disable libusb, that sounds like the best of both worlds - unless there is some unforeseen consequences ....

Anyway, does it mean that your previous pets in this thread won't work? Haven't got any comments and not having the printers themselves, I can't test ...

Billtoo · #152 Post by **Billtoo** » Sun 20 Mar 2011, 12:02

Here's the newest Ltris game.
The following is from the change log:

1.0.16:
- improved random number generator (2011/03/02 MS)
- generate pieces according to official Tetris guidelines (2011/03/02 Andrey
Maykov)
- always deal same sequence of pieces to all players (2011/03/02 MS)
- in expert mode deal most unsuitable piece out of current bag instead
of random piece (2011/03/02 MS)

rcrsn51 · #153 Post by **rcrsn51** » Sun 20 Mar 2011, 12:33

All the PETs I have posted above work in the current CUPS. They do not need usblp support. However, there are two udev rules files where this is an issue.

1. 55-cups. The purpose of this rule is to give all printer device nodes 666 permissions so the unprivileged CUPS user can access them. Supposedly, without that rule in play, you couldn't print at all. However, the purpose of the usblp module is to manage those device nodes and FD64 doesn't have it. So I was surprised that any printer would work.

I suspect that printing works anyway because of the rule in 50-udev-puppy-basic that assigns ownership of all USB devices to the unprivileged user spot. That's an odd hack. Or maybe if you print via libusb, you aren't constrained by ownership/permission issues.

2. 11-hplj10xx. This is the rule used by some older non-standard HP models that downloads firmware from the host computer to the printer. It is part of the foo2xxx driver package. It requires a device node like /dev/usb/lp0, so it definitely needs usblp. But there are only nine models affected by this issue.

Like I said above, Lupu has CUPS 1.4 AND usblp. Since it is built from Ubuntu packages, I'm assuming that the big-boy distros are still compiling CUPS with libusb disabled.

Billtoo · #154 Post by **Billtoo** » Sun 20 Mar 2011, 14:18

I don't see this in the fatdog repo:

jamesbond · #155 Post by **jamesbond** » Mon 21 Mar 2011, 13:15

rcrsn51 wrote:All the PETs I have posted above work in the current CUPS. They do not need usblp support.

Ah, good to hear that.

However, there are two udev rules files where this is an issue.

1. 55-cups. The purpose of this rule is to give all printer device nodes 666 permissions so the unprivileged CUPS user can access them. Supposedly, without that rule in play, you couldn't print at all. However, the purpose of the usblp module is to manage those device nodes and FD64 doesn't have it. So I was surprised that any printer would work.

I suspect that printing works anyway because of the rule in 50-udev-puppy-basic that assigns ownership of all USB devices to the unprivileged user spot. That's an odd hack. Or maybe if you print via libusb, you aren't constrained by ownership/permission issues.

I remembered troubleshooting usb printing problem back in FD64 500 beta days. It was CUPS 1.4 I think - and at that time, I can assure you, permission did have effect. Apparently CUPS of that day accessed usb printers through the usbfs (/proc/usb) and there was no way I can control the access (other than doing chmod 0666 manually). The problem at that time was, the usb backend, for some reason the usb backend was run as nobody instead of root - so definitely no usb printing before I did the manual chmod. Luckily we found the issue and managed to convince CUPS to run it as root. My understanding is that usbfs is deprecated, so newer libusb should not depend on it anymore, and should depend on /dev/usb which *is* managed by udev as you said above - but I have yet to confirm this.

2. 11-hplj10xx. This is the rule used by some older non-standard HP models that downloads firmware from the host computer to the printer. It is part of the foo2xxx driver package. It requires a device node like /dev/usb/lp0, so it definitely needs usblp. But there are only nine models affected by this issue.

As far as I know, /dev/usb/lp is managed by udev. Usblp will create /dev/usblp0 nodes. But I agree, anything that require raw access to the printers (e.g. checking ink status on Epson) seems to require usblp.

Like I said above, Lupu has CUPS 1.4 AND usblp. Since it is built from Ubuntu packages, I'm assuming that the big-boy distros are still compiling CUPS with libusb disabled.

Sounds good - I'm sure kirk will take note of this, if he decides to upgrade CUPS on next release of Fatdog.

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Fatdog64-511

Fatdog64-511

Fatdog64-511

SeaMonkey problem unique to FATDOG64

Using LiveDVD

Fatdog64-511

Fatdog64-511