Fatdog64-710 Alpha/2 [29 April 2016] [CLOSED]

[Belham]

WillM,

Sorry to get back to this so late. Yup, that did the trick. Mucho gracias. This whole time, when I type "Seamonkey 64-bit" into our Controlling Almighty (otherwise known as Google), it would bring up a link that took me straight to the page of Seamonkey downloads. Like an idiot, I'm thinking those are 64-bit builds when, as you pointed out, they are not. So, saw the unofficial 64-bit build down the middle of the page, and voila, everything works doing the dragging of the unarchived 2.40 folder in usr/lib64. Seamonkey is at 2..4.0 in my Fatdogs Thanks again.


Rodney,

Thanks for the tip. I too had figured that out (setting 'app.update.enabled' to true) a short while after I made the post asking about it here. Darn infuriating it was at first

[step]

@jamesbond, would you consider adding yad to the iso? More and more scripts in this forum take advantage of yad, which is also more flexible than xdialog in many ways.

[jamesbond]

@step: RE: yad - In the past yad was under heavy development and the interface (the command line options etc) changes very often; I didn't include it because it will be obsoleted very quickly. If the command line options have stabilised, and assuming the binary isn't too big (linking it to webkitgtk is out of question), I'm happy to include it in the base iso for the convenience of those who use it.
EDIT: It's 143K compressed, so it will go to the base. I've also uploaded yad-0.36.3 to the repo. Thanks to you and smokey01 who have been hosting yad for all these years.

@SFR: Thank you for all your reports and patches. They have all been actioned.

@spandey: "In Fatdog does the savefile/Diectory loaded to Ram during Boot?"
No. But this is a feature request that I'm considering to implement. Fatdog has "extrasfs" option to load additional SFS specified at boot time. I may add an option to copy to SFS into RAM first, before loading it.
EDIT: "extrasfs" parameter can now take optional ":ram" parameter and load it to RAM. Will be there in the next release.

@step: "So long as textmaker is running the panel doesn't come back in spite of the daemon restarting it. dmesg log ad libitum:" ... wow, I wonder that textmaker is doing. I'll send you email about it.

@TGS: 710a updates Xorg server release and its drivers. Perhaps there is something in Xorg 1.18.0 that VMware doesn't like ... I'll check if this is really the case (and/or if there is a newer vmware xorg driver that may help).
EDIT: I have uploaded a newer vmware driver, version 2016.05. Check it out.

NOTE for all: Flash player updater stops working. Adobe changed the website layout, so I can no longer detect the most recent version. I need to rework it.

[don570]

I finally know the reason why Barry K is distributing an old version of yaf-splash in WOOF
I tried this in werewolf 64 bit

Code: Select all

# yaf-splash --help

gtkdialog-splash
 
 an easy replacement for yaf-splash in Puppy (NOT Puppy <=4.x)
 mave 30.05.2010
 no warranty
 Thanks for Puppy!

In Barry's recent distros he uses gtkdialog-splash instead

A link is used...

ln -sf /usr/bin/gtkdialog-splash /usr/bin/yaf-splash

Barry is keeping compatible to a script line like this....

Code: Select all

root:~# yaf-splash -timeout 0 -margin 20 -outline 0 -bw 5 -placement top -bg orange -fg black -text "$(gettext 'Please wait for completion...')"  & PID=$!

[step]

@jamesbond, is there a specific reason you build cp without extended attribute support? Fatdog64 supports extended attributes, so could you enable cp too?

We users briefly touched on this subject before here, but in the context of ROX-Filer emblems. I'm now playing with a jun7's modded ROX-Filer source, and see that it would be trivial to patch ROX-Filer to enable copying extended attributes - but it needs cp support in the first place.

[laurentius77]

Hello,

I tried FatDog 710a2 with latest 4.4.3 kernel on my Surface Pro 4 and for now that is what I have functional:

- booted FatDog64 by using GPT FAT 32 partition
- wireless and bluetooth devices are functional
- glxinfo direct rendering=YES

Problems
- the Microsoft touch cover with keyboard is not working. It is detected and this can be seen in logs (I attached messages and xorg.0.log files).
- screen resolution is stuck at 2736x1824 which is default on Windows 10 but is very high for FatDog64 fonts, windows and icons. There is no option to change this resolution, it is the only one in the list.
Other things looks good.

Any advises or ideas in solving these two problems (a working cover touch-keyboard will be great in the beginning, I can manage with resolution by increasing font size...) would be greatly appreciated.

Anyway I didn't expected to have FatDog64 working so good on Surface Pro 4 which is a pretty new device.

Thanks!

[jamesbond]

@step - no special reason. cp is part of "coreutils" and was built very early in the build process, I suppose the extended-attribute library wasn't built yet at that time.

@laurentius77 - For the xorg resolution, try opening a terminal and then type "xrandr". What do you see? If you see other resolutions, they can be set using "xrandr -s 1920x1080" for example. If you don't see any other resolution, well then ... you can't change the resolution.

For the cover pad - well, I have no idea what it is. Is it a touchpad? is it a keyboard? which one works? which one doesn't? Anyway, again, open a terminal, then launch "xev". Move your cursor over xev, then use the touchpad/keyboard (touch it, move it, press the keys etc) and see if anything at all registers in the original terminal window where you launch it.

[laurentius77]

- 2736x1824 is the only resolution available with xrandr command
- Surface 4 cover is both a keyboard, multitouch touchpad and screen cover, connected to tablet using 6 metallic mag dots. The tablet runs Windows 10 desktop OS and has a touchscreen. It is a great piece of hardware and running FatDog64 on it would be wonderful. It is recognized as Microsoft HID by the Linux kernel (as you can see in logs). I searched internet for having this cover recognized by Linux and I found https://launchpad.net/~tigerite/+archive/ubuntu/kernel
Do you thing that is possible to try compiling a kernel for FD64 which can recognize the cover?
Using the tablet with external keyboard and mouse is possible but the tablet has just one USB port and an USB hub is needed, which has great impact in portability.
Thanks!

[laurentius77]

@step - no special reason. cp is part of "coreutils" and was built very early in the build process, I suppose the extended-attribute library wasn't built yet at that time.

@laurentius77 - For the xorg resolution, try opening a terminal and then type "xrandr". What do you see? If you see other resolutions, they can be set using "xrandr -s 1920x1080" for example. If you don't see any other resolution, well then ... you can't change the resolution.

For the cover pad - well, I have no idea what it is. Is it a touchpad? is it a keyboard? which one works? which one doesn't? Anyway, again, open a terminal, then launch "xev". Move your cursor over xev, then use the touchpad/keyboard (touch it, move it, press the keys etc) and see if anything at all registers in the original terminal window where you launch it.

[laurentius77]

@step - no special reason. cp is part of "coreutils" and was built very early in the build process, I suppose the extended-attribute library wasn't built yet at that time.

@laurentius77 - For the xorg resolution, try opening a terminal and then type "xrandr". What do you see? If you see other resolutions, they can be set using "xrandr -s 1920x1080" for example. If you don't see any other resolution, well then ... you can't change the resolution.

For the cover pad - well, I have no idea what it is. Is it a touchpad? is it a keyboard? which one works? which one doesn't? Anyway, again, open a terminal, then launch "xev". Move your cursor over xev, then use the touchpad/keyboard (touch it, move it, press the keys etc) and see if anything at all registers in the original terminal window where you launch it.

1) 2736x1824 is the only resolution available with xrandr command
2) Surface 4 cover is both a keyboard, multitouch touchpad and screen cover, connected to tablet using 6 metallic mag dots. The tablet runs Windows 10 desktop OS and has a touchscreen. It is a great piece of hardware and running FatDog64 on it would be wonderful. It is recognized as Microsoft HID by the Linux kernel (as you can see in logs). I searched internet for having this cover recognized by Linux and I found https://launchpad.net/~tigerite/+archive/ubuntu/kernel
Do you thing that is possible to try compiling a kernel for FD64 which can recognize the cover?
Using the tablet with external keyboard and mouse is possible but the tablet has just one USB port and an USB hub is needed, which has great impact in portability.
Thanks!

[laurentius77]

1) 2736x1824 is the only resolution available with xrandr command
2) Surface 4 cover is both a keyboard, multitouch touchpad and screen cover, connected to tablet using 6 metallic mag dots. The tablet runs Windows 10 desktop OS and has a touchscreen. It is a great piece of hardware and running FatDog64 on it would be wonderful. It is recognized as Microsoft HID by the Linux kernel (as you can see in logs). I searched internet for having this cover recognized by Linux and I found https://launchpad.net/~tigerite/+archive/ubuntu/kernel
Do you thing that is possible to try compiling a kernel for FD64 which can recognize the cover?
Using the tablet with external keyboard and mouse is possible but the tablet has just one USB port and an USB hub is needed, which has great impact in portability.
Thanks!
Sorry, I tried to quote jamesbond messages but it stays empty on the web, even if I can see it in my forum control panel.
Hope will work with New Reply

[James C]

1) 2736x1824 is the only resolution available with xrandr command
2) Surface 4 cover is both a keyboard, multitouch touchpad and screen cover, connected to tablet using 6 metallic mag dots. The tablet runs Windows 10 desktop OS and has a touchscreen. It is a great piece of hardware and running FatDog64 on it would be wonderful. It is recognized as Microsoft HID by the Linux kernel (as you can see in logs). I searched internet for having this cover recognized by Linux and I found https://launchpad.net/~tigerite/+archive/ubuntu/kernel
Do you thing that is possible to try compiling a kernel for FD64 which can recognize the cover?
Using the tablet with external keyboard and mouse is possible but the tablet has just one USB port and an USB hub is needed, which has great impact in portability.
Thanks!
Sorry, I tried to quote jamesbond messages but it stays empty on the web, even if I can see it in my forum control panel.
Hope will work with New Reply

The old url messing up the whole post problem......

[jamesbond]

@James C - thanks
@laurentius77 -
a) xrandr - that's too bad. Your only choice is playing with the DPI settings but frankly Fatdog64 is never designed to support high-DPI devices (high resolution is okay, but high-DPI is another matter ...), so you will have to do some tweaking there.
b) for the keyboard - I will take a look.

For others - to keep up with the Joneses (http://murga-linux.com/puppy/viewtopic. ... 097#905097), I have enhanced Fatdog's extrasfs parameter to be able to:
a) load additional SFS from un-mounted partition
b) load additional SFS to RAM
This will be coming out in beta.

[don570]

@ James

There are a group of USB wireless adaptors that require firmware to
be included

I reported this here

http://www.murga-linux.com/puppy/viewto ... 833#902833
_____________________________________________

[laurentius77]

@James C - thanks
@laurentius77 -
a) xrandr - that's too bad. Your only choice is playing with the DPI settings but frankly Fatdog64 is never designed to support high-DPI devices (high resolution is okay, but high-DPI is another matter ...), so you will have to do some tweaking there.
b) for the keyboard - I will take a look.

For others - to keep up with the Joneses (http://murga-linux.com/puppy/viewtopic. ... 097#905097), I have enhanced Fatdog's extrasfs parameter to be able to:
a) load additional SFS from un-mounted partition
b) load additional SFS to RAM
This will be coming out in beta.

Thanks jamesbond !
I tried do disable synaptics and use evdev with no success for the Surface Cover 4 in FD64.
Changing dpi to 144 seems to be usable so I can't complain about my huge resolution. Even in Windows 10 that is the only resolution available!
Your additional SFS to RAM will be a great thing ! And if I can solve the problem with my surface cover I would have everything I need from my lovely FD64.
Thank you for your great work!

[jake29]

I'm running Fatdog 710a2 with included 4.4.3 kernel.

kodi-14.1.sfs fails to start with error message:

/usr/lib/kodi/kodi.bin: error while loading shared libraries: libcap.so.2: wrong ELF class: ELFCLASS64

kodi-15.2-x86_64.sfs fails to start with error message:

/usr/lib/kodi/kodi.bin: error while loading shared libraries: libavahi-client.so.3: cannot open shared object file: No such file or directory

I'm fairly sure I had Kodi 14.1 working with Fatdog64 701. Any suggestions appreciated.

[laurentius77]

I'm running Fatdog 710a2 with included 4.4.3 kernel.

kodi-14.1.sfs fails to start with error message:

/usr/lib/kodi/kodi.bin: error while loading shared libraries: libcap.so.2: wrong ELF class: ELFCLASS64

kodi-15.2-x86_64.sfs fails to start with error message:

/usr/lib/kodi/kodi.bin: error while loading shared libraries: libavahi-client.so.3: cannot open shared object file: No such file or directory

I'm fairly sure I had Kodi 14.1 working with Fatdog64 701. Any suggestions appreciated.

Maybe is not the proper answer but try to load 32bit-slacko6.sfs

[tonyfd710]

The issue for For Kodi 14.1 is that by default the path is searched for 64 bit libraries first. The library file in question has both 64 bit and 32 bit counterpart and is choosing the wrong one. One way to fix it is when running the Kodi binary set up the library path to point to the 32 bit libraries.
Kodi 15.1 is missing a bunch of libraries. I cannot see how that ever worked. Just compare the libraries in 14.1 to 15.2. You will see in 14.1 the Avahi client library is there but nowhere to be seen in 15.2.

[Doglover]

Beta Beta Beta

Please Please Please

Thank you in advance.

[mikeslr]

Hi tonyfd710 or anybody,

... One way to fix it is when running the Kodi binary set up the library path to point to the 32 bit libraries.
.

I hope I'm not diverting this thread for long. But the above advice shows up from time to time on 64-bit Puppy threads. And I would like to know exactly what has to be done to accomplish it.

Thanks in advance,

mikesLr