how to duplicate problem I wrote about, check email, and surf this forum, without rebooting for little over a day and a half, downloaded a file from this forum, and reply to a few posts.
The 'event' happen on this thread, during typing in a textbox..

Ted Dog, which browser (FF/SM)? Are you using Adblock? If not, please use it and see if it makes any difference?

Quote:

Opps that post was deleted (not by me) it was very wonky (typos galore) since the textbox was being blotted with white bars, and text chunks shifting in/out of view, the very bad time, posted the one above after that one did not have as many corruptions. Got a screen shot, but based on your reply it was not going to be anything you have not described. The white out block JUST occurred AS I was spell checking the word described, in the last sentance, Happened again when I misspelled sentence. Cool it is looking like an issue with spell checker..
If you are a good speeller if my never happen, I guess

I've got this time to time but usually not that bad. I think it is graphics driver related.

L18L wrote:

Yes the culprit is definitely the gma500_gfx module only.
in the running system makes it all black...
Anyway.. resolution is 1600x1200px (should be 1920x1080)
So I am hoping another kernel will help.

Since you are using UEFI, I would presume that you card is relatively new and therefore not supported properly by the kernel, thus the problems. GMA500 and GMA600 are not Intel designs despite the name, they are closer to Imagination POWERSGX (which is as closed as a GPU you can get), even those in the ARM world are complaining.

Quote:

I suggest that with pfix=nox and/or nomodeset xorgwizard (and modprobe <video>) should not start. At the moment it looks like just xwin is not started.

"pfix=nox" stops xwin from being run; "nomodeset" stops the KMS drivers from being activated; they are meant for different things. If your card isn't supported by the kernel and you've got lockups like Gobbi, then "pfix=nox" will not help, "nomodeset" may still help. Even with "nomodeset" you may still get a desktop successfully (using "vesa" driver for BIOS systems and "fbdev" driver for UEFI), if it doesn't happen automatically, you can use xorgwizard to tell Xorg to use the correct driver.

Quote:

I have copied some locales from
/usr/share/locales/i18n/locales

Or you can use the glibc_locales from the package repo.

Localisation is a big thing for Fatdog64, *nothing* is localised yet. Localisation of Fatdog64 scripts consist of two parts:
a) localisation of the GTK gui (this requires addition of 6 lines of gtk-server commands).
b) localisation of the scripts itself (this is similar to Puppy)

Gobbi wrote:

I did two things:
1 . Booted with pfix=nox loglevel=7 then modprobe radeon then xwin . This gave a lot of vertical narrow black and white stripes on my screen and the system frozen .
2 . As you suggested I removed the radeon-dmf.conf file before starting X adding loglevel=7 . Did modeprobe radeon and the last lines on the black screen were :

I assume you mean that when you remove radeon-dpm.conf, it works. So your card isn't compatible with DPM. Well DPM support is new, so yes we expect problems, and hopefully it will get better with time.

Quote:

I tested the glib-2.36-630.pet and it solved that glitch , but if it can make more damage on other occasions I can live with the old one since I only make those settings in the beginning and restarting X put back the normal screen.

Not saying that it will cause problems, I'm just saying that glib is used by so many other apps, it may have unexpected kinks unless it gets tested for all of those apps - and we haven't done so. If it works with you, you can keep it installed and use it to see if any other apps suddenly becomes broken. You can always uninstall it. If it works well we may move it to the main repo.

Quote:

BTW on that broken folder in ibiblio I saw Seamonkey 2.20 witch I use it with no problem on fatdog 620 .Did it also give problems ? I'd like to know more...

Why use SM 2.20 when SM 2.21 is available on the official repo (And yes, this SM 2.21 should work on earlier Fatdogs too).

Quote:

Installed the pet which contains the transset-df command line tool , did a visit to the owner's site and saw how to use it but , it seems fatdog's WM openbox has no such thing as transparency , or it needs other themes , I don't know .

You need to start "xcompmgr" first before you can use transset-df. Here: https://wiki.archlinux.org/index.php/xcompmgr

Atle wrote:

But if you look in the right lower corner, you see that there is 1,4 gb free savefile space. To me this looks more like permissions, but i am open for having made a mistake.

yes, this could be permission problem. Open /root/spot/Downloads - do you see the partial file that you've been trying to download? How do you install it - to flash drive? When you create the savefile, did you move agree to "move the Downloads folder" out of the savefile? What's the filesystem where the Downloads folder is located? Do this (in terminal):

Code:

su spot
cd /root/spot/Downloads

Do you get an error message? If you do then yes it is a permission problem.

LateAdopter wrote:

ran xorgwizard and the dialog box opened with the highlight on ATI so I clicked on Radeon and then clicked OK. This is what I got in the terminal.

Thanks for replying to my bug feedback.
I will always run stock when testing code, no need to add problems, Also am not running flash heavy sites, these bugs (bug) has occurred when the sole activity from boot was THIS forum. So unless that goofy red R1Soft Admin tool ad to the right of the word Forum is causing the issue.

It only seems to occur within typing in text-box, and have lots of typos, to correct. When my fingers and brain are sub-par it can be a bunch of corrections. But hopefully never enough to crash spellchecker.

I do boot in base2ram=expand mode, forgot once and it turned the laptop into molasses.

I am having problems compiling glibc-2.18 in Fatdog64-630. It does compile correctly in Fatdog64-520, so I'm not really sure what the problem is in the 600 series of FatDog64 (I had also tried fatdog64-620 but it failed in the same place as fatdog-64-630).

I'm pretty sure I have loaded the correct SFS packages (fd64-devx_630.sfs & kernel-source-3.11.4.sfs) and I used "configure --prefix=/usr".

When running "make", it runs for a few minutes and then bombs out with this error:

Localisation is a big thing for Fatdog64, *nothing* is localised yet. Localisation of Fatdog64 scripts consist of two parts:
a) localisation of the GTK gui (this requires addition of 6 lines of gtk-server commands).
b) localisation of the scripts itself (this is similar to Puppy)

Is a virtually will be a long ago "Booting the kernel" on Virtualbox
Is a ~3-5 minutes will be doesn't respond... on Latest Fatdog 6.30rc1

Odd, it boots here on VB 4.2.18 and 4.3 in less than 30 seconds, straight to desktop, both BIOS and UEFI emulation. With UEFI emulation xwin will fail to start, just run xorgwizard and choose "fbdev" and xwin will start next time.

Ted Dog wrote:

Thanks for replying to my bug feedback.
I will always run stock when testing code, no need to add problems, Also am not running flash heavy sites, these bugs (bug) has occurred when the sole activity from boot was THIS forum. So unless that goofy red R1Soft Admin tool ad to the right of the word Forum is causing the issue. Wink

It only seems to occur within typing in text-box, and have lots of typos, to correct. When my fingers and brain are sub-par it can be a bunch of corrections. But hopefully never enough to crash spellchecker.

Thanks for reporting the bug. I think it could be SM bug. I'll give it a try but I can't leave my machine running days without powering off (laptops will die very quickly if you do that). Do you mind using the latest FF pet and see if it happens too?

Interesting! Do yo use use $(gettext)? If yes, you have already set TEXTDOMAINDIR and TEXTDOMAIN, no? My suggestion is to use ${0##*/} as the TEXTDOMAIN (that is, the script name --- people usually use $(basename $0) for the same purpose).

For the control panel, since it doesn't use any GtkBuilder files, that's all you need to do, actually (no a) step is necessary at all).
For others, that do use GtkBuilder files, the file is the script name + xml (e.g. fatdog-event-manager.sh.xml is for fatdog-event-manager.sh).
For scripts like this, you need to insert these just before the 'gtk_init' line:

I believe once you have the .pot file, you know where to go from there ... you will need to combine the .pot file from the GtkBuilder above with the one you generated for the shell script, though.

The biggest is issue is this: some scripts have calculation inside, and the calculation implicitly uses "dot" as decimal separator. On some locales, "dot" is a thousand-separator and not decimal separator ... need to figure out which scripts have this problem. This isn't new anyway, I'm sure you've encountered this a thousand times during mainline Puppy's localisation effort _________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread

I am used to work with MoManager that can handle translation of Name;
I will have to add handling of Comment in MoManager.

jamesbond wrote:

Do yo use use $(gettext)? If yes, you have already set TEXTDOMAINDIR and TEXTDOMAIN, no? My suggestion is to use ${0##*/} as the TEXTDOMAIN (that is, the script name --- people usually use $(basename $0) for the same purpose).

Yes, I have used one TEXTDOMAIN=fatdog64 for all for now.

jamesbond wrote:

For others, that do use GtkBuilder files, the file is the script name + xml (e.g. fatdog-event-manager.sh.xml is for fatdog-event-manager.sh).
For scripts like this, you need to insert these just before the 'gtk_init' line:

Thank you, this gtk server stuff is really new for me (and that is why it should be fun).
I have been trying to apply your advice.
I have added just 2 msgid msgstr pairs to my fatdog64.po and used msgfmt.
But no translation was displayed.

I think I can make MoManager use these xml files too.
But one step after the other.
If you could build a working example of internationalzed fatdog-event-managersh that would be nice.
(just 2 phrases, you can use en_AU and en_US or msgstr="XXXmsgidXXX")

Known bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12366, you need to build a newer binutils first.

Thanks ... that worked for me. I had to configure binutils with:
"configure --prefix=/usr --build=x86_64-t2-linux-gnu"
so it would put things in the right place .... I was then able to compile glibc-2.18 in Fatdog64-630 without any problems.

Any chance they will put a newer version of glibc in final release of Fatdog64-630? The Folding@Home core17 used for GPU Folding (natively in linux ... without wine) requires at least glibc-2.15 to run properly.

Ok this may be a little too late but for whatever it is worth.
It contains the "localised" version of the gtk-server GUI, for "en_US" locale.

Look into fatdog-event-manager.sh script, search for "localisation" and you will see the changes I put there.

Run the run-me.sh script, it will start the "localised" GUI with "en_US" appened to certain labels (and window title).

I'm using LC_MESSAGES instead of LANG to make the changes minimal. I'd like to keep LANG=C by default to speed up the script, but I guess we need to see if there is any problem with this approach.

Use the generate-pot.sh to generate the .pot file. I don't recommend changing the GtkBuilder XML file by hand; as these files are auto-genereated by glade3 (you can actually load them into Glade3 and see how the GUI looks like --- that's how I built them, I don't do it by hand); and I'm not sure whether the comment you have put in will stay if I edit the file with glade3. Either way, I prefer not to mark an XML file as executable

I don't follow the discussion on how l18n is done on Puppy, is it done as one large .mo file that covers *all* puppy applications, or is every separate application has its own .mo file? For me, I'd prefer a separate .mo file for every application because it makes them more maintainable.

Sunny,
Glad that you make it to work

As for glibc update: we don't change critical libraries during a series. In my response to Gobbi, I hesitate to update glib (not glibc), which is used by GTK and many other GUI programs. glibc is even more critical than glib so it will stay during the entire 600 series.

If you need updated glibc, then you will either have to roll-out your own, and/or wait for the next series (Fatdog64 700).

I'm using LC_MESSAGES instead of LANG to make the changes minimal. I'd like to keep LANG=C by default to speed up the script, but I guess we need to see if there is any problem with this approach.

Just LC_MESSAGES sounds good! When and where is it set?

jamesbond wrote:

I don't follow the discussion on how l18n is done on Puppy, is it done as one large .mo file that covers *all* puppy applications, or is every separate application has its own .mo file? For me, I'd prefer a separate .mo file for every application because it makes them more maintainable.

On Puppy everything is possible. In the beginning it was one TEXTDOMAIN for each script. But it has been extended by Barry to have one TEXTDOMAIN for as many scripts as you like.
"One for all" and "each its own" are the extremes. Something in the mid should be best.
Greatest advantage of momanager is easiest maintenance!
"One for all" has no doubles (restart now? reboot now, press enter to continue etc. )
If anything in one of the script has been changed then
the translation file is marked "check needed" and
the msgstr is empty or marked "fuzzy"
Another argument for "one for all":
I have loaded puppy's languagepack_de and most is OK.
Keeping just one additional file for fatdog is not bad.

Glad you like it.
Going to look into your sample now...
(the first downloader was not me )

Curious_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

No, it doesn't apply, as Fatdog uses a wholly different program to remaster. In Fatdog, a remaster is a copy of the live running copy.

L18L wrote:

Just LC_MESSAGES sounds good! When and where is it set?

The same place where LANG is set. Where is it set in Puppy? It can't be in all scripts. I'd suggest to put it in $HOME/.profile so it is automatically inherited by all apps (and since it is in $HOME, different user can use different language settings).

Quote:

"One for all" and "each its own" are the extremes. Something in the mid should be best.

In general I agree, but somehow we need to decide sooner or later because it has practical consideration:
- if we use one-mo-file per app, then every app must set its own TEXTDOMAIN
- if we use one-mo-for-all, the app don't need to set that, just use TEXTDOMAIN that it inherits from $HOME/.profile (and if it's blank, there will be no translation).
We can't have half of the apps use the first method and the other halfs use the second one. Of course the third alternative is that all apps set their own TEXTDOMAIN but they use the same value (fatdog64) ...

I'd be curious how it is currently done on Puppy (good for lesson learnt and whether we can do it better in Fatdog).

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