Fatdog64-710 beta [28 August 2016] [CLOSED]

[Gobbi]

Hi, step !
Running seamonkey-spot in a terninal gives only :
[calBackendLoader] Using libical backend at /usr/lib64/seamonkey-2.40/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
which , I think , is related to Lightning only . Nothing more .
Testing a bit more , I've noticed Seamonkey and Firefox start also normally , that is fast , before I connect to Internet . Only after , they slow down and rox too ...Installing the last rox from the repo fixes rox but those two browsers are still slow to open . Google Chrome , Transmission and Pidgin are OK .In all previous versions of Fatdog ( up to FD710-alpha3 - that is with older rox ) this never happend .
In FD710 beta - trying to open one of these browsers , the CPU monitor shows activity as if trying to execute , only after long pause , a second CPU monitor activity is seen and the browser opens . It behaves the same if I open it as spot or as root . Also , it doesn't matter if I'm connected wireless or wired ., or if eztables is on or off .
I'm curious if it happens only to me ...

[prehistoric]

@ SFR and prehistoric

I deleted my save file in order to start from scratch. I loaded the
32-bit-fd64_710.sfs and did a ldconfig. Rebooted. No joy and still
no clues as to what the problem might be.

Unfortunately, Fatdog is very different internally from most Pupplets. It is built via the Linux From Scratch recipes.

To find out what is going on you will need to run those commands that are giving trouble from a console window so you can see the error messages.

[SFR]

Okay, thanks. Unless it would be of genuine benefit to you or the other developers - I would prefer to live with things as they are for now. I have no other problems.

Nah, if it doesn't bother you that much, it's ok.
___________

I deleted my save file in order to start from scratch. I loaded the
32-bit-fd64_710.sfs and did a ldconfig. Rebooted. No joy and still
no clues as to what the problem might be.

I built ink + its deps (libinklevel & libieee1284).
I don't have a printer, so can't check if it really works.
Just unpack the attached ZIP, install all 3 pkgs and let me know if it works, so I'll upload it to contrib repo.

Btw, I didn't bother with packaging InkGUI (it also uses gxmessage, unavailable in FD), so try it from CLI, e.g.:

Code: Select all

ink -p usb

Oh, and do not install InkGUI after installing the above pkgs, because it would overwrite 'ink' binary with its own, 32bit version that doesn't work in FD.

Greetings!

[step]

Gobbi,

I really doubt rox has anything to do with slow seamonkey. The new rox you downloaded is faster because it doesn't query DNS unnecessarily. If you have slow DNS servers they will slow down all programs that make DNS queries, browsers included. I don't know if this could be your problem. The description you gave makes me think that a problem in the network environment, such as slow servers, is more likely to be the cause, but I can't be sure.

I have problems with Seamonkey but of a very different nature. When I start it from the console I see lots of errors that slow it down to a crawl, "failed to connect to the D-BUS daemon". It's something in my save folder, because if I boot the fatdog.iso without a savefile it doesn't happen.

If you boot fatdog.iso without a savefile is seamonkey slow to start?

Hi, step !
Running seamonkey-spot in a terninal gives only :
[calBackendLoader] Using libical backend at /usr/lib64/seamonkey-2.40/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
which , I think , is related to Lightning only . Nothing more .
Testing a bit more , I've noticed Seamonkey and Firefox start also normally , that is fast , before I connect to Internet . Only after , they slow down and rox too ...Installing the last rox from the repo fixes rox but those two browsers are still slow to open . Google Chrome , Transmission and Pidgin are OK .In all previous versions of Fatdog ( up to FD710-alpha3 - that is with older rox ) this never happend .
In FD710 beta - trying to open one of these browsers , the CPU monitor shows activity as if trying to execute , only after long pause , a second CPU monitor activity is seen and the browser opens . It behaves the same if I open it as spot or as root . Also , it doesn't matter if I'm connected wireless or wired ., or if eztables is on or off .
I'm curious if it happens only to me ...

[Gobbi]

If you boot fatdog.iso without a savefile is seamonkey slow to start?

Yes, step . I always use fatdog without savefile .
About your guess that it might be because of local slow servers , I think it makes sense ... Once the browser opens ( with a 10 seconds delay ) , it is as fast at it should be . And if , during the time it's open , I open another instance ( or even several ) from the terminal the browser opens in less than a second , just like Google Chrome or other programs that use internet .
I wonder what has changed with the network approach in FD710b with respect to FD710 alpha ... And what can I do about it ...
Another odd thing is that the same Seamonkey 2.40 works normally in previous Fatdogs... And an older Seamonkey presents the same issue in FD710b . And my local network and my servers are the same , obviously .
I don't think is related , but I've noticed there is no message bus service and now there is mdns service in /etc/init.d/ folder . Things evolve and in my case I found this glitch with my favourite browser .

[artsown]

@ sfr

Your ink package worked ok. Ink levels are reported. Just to verify that
32 bit libs aren't required, I started from scratch again. It's really
great to not have to mess with 32 bit libs! Thanks much for your
efforts.

BTW, in my prior investigations on inkgui I discovered that part of
the problem was the lack of gxmessage in FD (as you mentioned).
However, FD has xmessage, and when I changed the script to use
that instead I started seeing gui messages. But that was just part of
the problem. The ink file was not being recognized. The terminal
error report was "no such file or dir". This was with 32 bit libs
installed.

If you recall, I initially was also interested in getting rcsrn51's candi
working so as to have the Canon scanner app available. Maybe if
I point him to this thread he will take an interest and come up with
solutions not requiring 32 bit libs

Let me know if you want any more testing of your ink package.

Art

[jake29]

jake: You completely misunderstand.
Money is NOT necessarily needed!
You could start by indicating in which country you reside. If it is anywhere near me I will GIVE you a spare system, including caddies. But you can obtain what you need by keeping your eyes and ears open, making good friends and politely asking for cast-offs. Many folks are only too glad to off-load their surplus stuff rather than sending to landfill. And, please don't complain about me before you check out my record.

Apologies Sage. Definitely no disrespect intended on my part. I was just a bit too enthusiastic to make a point. It's obvious you only have the best of intentions. Thanks for the generous offer. Maybe we can continue this via PM.

[SFR]

Your ink package worked ok. Ink levels are reported.

Ok, thanks for confirmation. Packages uploaded to contrib repo.

If you recall, I initially was also interested in getting rcsrn51's candi
working so as to have the Canon scanner app available. Maybe if
I point him to this thread he will take an interest and come up with
solutions not requiring 32 bit libs

Yeah, that would be best if Rcrsn51 could look into it personally.
From what I saw in candi.pet, there's a lot of stuff that probably wouldn't work in FD, unless re-written specifically for it.

Greetings!

[step]

@Gobbi, we'll need to wait for jamesbond to tell us what's changed in the network between alpha and beta. I think he's travelling these days, but eventually he'll be back and review this thread.

[jake29]

I just set up my Epson PX700W printer. It's networked - connected directly to router. In the Fatdog64-710 Alpha, I'm fairly sure CUPS > Admin > Find new printers - was able to detect the PX700W. This does not happen in the Beta.

I had to manually configured CUPS to use socket://hostname:9100. I do have a different router for initial setup in CUPS this time; that could well be the cause.

[artsown]

@ SFR

I noticed candi is in the repo. It works fine in FD64.

FD64 is shaping up for me as a "workhorse" distro. It "feels" solid
and "mature", at least for my wants and needs. Can't help feeling
thankful to the devs and expert contributors.

Art

[artsown]

I couldn't find a time sync app in FD or in the repos. I found Psync-2.7-64.pet
by tasmod which is said to work on FD. I installed it and it does appear to
work in 710b.

Seems to me FD should include this or some other app that adjusts
system time to accurate sources from remote servers. At least it should be
included in optional package repo. Of course, I may be missing some
app that does this which I don't recognise by its name.

Art

[SFR]

I couldn't find a time sync app in FD or in the repos. I found Psync-2.7-64.pet
by tasmod which is said to work on FD. I installed it and it does appear to
work in 710b.

Seems to me FD should include this or some other app that adjusts
system time to accurate sources from remote servers. At least it should be
included in optional package repo. Of course, I may be missing some
app that does this which I don't recognise by its name.

Art

Yes, it's already there, see Control Panel -> System -> Manage Servers and Services -> ntpd-boot/ntpd-client.

Greetings!

[prehistoric]

...
Yes, it's already there, see Control Panel -> System -> Manage Servers and Services -> ntpd-boot/ntpd-client.

Greetings!

It took me a while to find this, so there should at least be some words about it in initial set up. Ideally, you would just have a checkbox for "Do you want to sync the system clock with a network time server at each start-up?"

Also, most users really won't understand the reason for the two different service options. Pick one that is very likely to work for most people, and leave the other to be found by those for whom the first option fails, when they ask for help.

[artsown]

prehistoric wrote:

It took me a while to find this, so there should at least be some words about it in initial set up. Ideally, you would just have a checkbox for "Do you want to sync the system clock with a network time server at each start-up?"

My suggestion is to sync also at 'Restart X' so the user has a "on-demand"
option as well. I dunno why the time sync function is disabled by default.
The fact that a time sync exists should be mentioned in the FAQ, IMO. The
FAQ could mention that Restart X also invokes time sync.

Be nice if a momentary pop up appeared announcing that time sync has
been successfully (or not) accomplished.

Art

[artsown]

pup-advert-blocker is a popular and effective script that (I think) would
be a good addition to FD64.

Art

[Sunny]

In Fatdog64-710b, the xine-lib package in the repository is not compatible with the version of libdvdcss that is installed.

To demonstrate the problem:
I booted with "savefile=none" kernel parameter and then used Gslapt to install xine-ui and xine-lib (version 1.2.6). Doesn't matter if you use xine-ui or gxine.

When starting xine, error messages pop up that indicate that libdvdread can not access the dvd properly. (Note that mplayer and VLC work just fine when playing this same dvd in this setup).

To resolve the problem, I used Gslapt to remove libdvdcss (version 1.4.0 x86_64). I then went into the Fatdog64 700 Repository (note this is the repository for the older fatdogs) and downloaded libdvdcss (version 1.3.0 x86_64). When I installed this older version of libdvdcss then xine worked properly. (Note that mplayer and VLC still work properly with this older version of libdvdcss installed)

[jamesbond]

Thanks, somebody else found the problem too (and with the fix).
https://mailman.videolan.org/pipermail/ ... 01641.html.
Will be fixed in next release.

[Pelo]

Fatdog64-710 beta. I will load it as soon as finale released . Yet tested in the past. Was diificult enough for a Puppy user. But so many people enjoy fatdog..

[Sunny]

The Nvidia 304 driver will not install on kernels newer than 4.3 and will indicate MTRR errors. To use this legacy driver on Fatdog64-710b, a patch needs to be installed on the Nvidia driver as discussed in this thread. To summarize, the following are the steps required to patch the Nvidia driver for Fatdog64-710:

1) From the Nvidia site, download the Linux x86_64 driver (NVIDIA-Linux-x86_64-304.131.run) and extract the contents to a local folder:

> sh ./NVIDIA-Linux-x86_64-304.131.run --extract-only

2) Download the MTRR-Patch. The patch (named nvidia_mtrr_k4_3.patch.gz) can be found (near the bottom of the page):
http://murga-linux.com/puppy/viewtopic. ... 5&start=75

Download the nvidia_mtrr_k4_3.patch.gz file, rename it to nvidia_mtrr_k4_3.patch and then move it to the NVIDIA-Linux-x86_64-304.131/kernel/ folder.

3) Go to the NVIDIA-Linux-x86_64-304.131/kernel/ folder and apply the patch:

> patch -p1 < nvidia_mtrr_k4_3.patch

4) Go back to the directory containing the NVIDIA-Linux-x86_64-304.131 folder and create a patched run file:

> sh ./NVIDIA-Linux-x86_64-304.131/makeself.sh --target-os Linux \
--target-arch x86_64 NVIDIA-Linux-x86_64-304.131 \
NVIDIA-Linux-x86_64-304.131-patched.run \
"NVIDIA driver 304.131 patched for k4.3+" ./nvidia-installer

5) This creates a new run file named NVIDIA-Linux-x86_64-304.131-patched.run that will install normally. (Boot fatdog64 with the "blacklist=nouveau" kernel parameter, then exit to terminal mode and execute the NVIDIA-Linux-x86_64-304.131-patched.run file) Remember that you will need to load the kernel source & devx .sfs packages before trying to install the Nvidia driver.