Fatdog64-630rc1 (16 Oct 2013) [CLOSED]

[LateAdopter]

Hello jamesbond

but the recommended way of doing this is to run xorgwizard (you can run this from existing X session, no need to quit to terminal) and specify the radeon driver

Do you mind editing /usr/sbin/fatdog-xorgwizard.sh and add "-x" to the first line so it looks like "#!/bin/dash -x" and then run xorgwizard from terminal and copy/paste the output?

I 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.

Code: Select all

xorgwizard
+ APPTITLE=Xorgwizard
+ DRIVER_PATH=/usr/X11R7/lib64/xorg/modules/drivers
+ OUTPUT_FILE=/usr/share/X11/xorg.conf.d/20-gpudriver.conf
+ TMP_XINIT=/tmp/xinit_test
+ setup
+ DIALOG=dialog
+ [ :0 ]
+ DIALOG=Xdialog
+ which ddcprobe
+ DDCPROBE=/usr/X11R7/bin/ddcprobe
+ sleep 1
+ /usr/X11R7/bin/ddcprobe
+ pidof ddcprobe
+ + sed s_/usr/X11R7/lib64/xorg/modules/drivers/__; s/_drv\.so//
ls /usr/X11R7/lib64/xorg/modules/drivers/ati_drv.so /usr/X11R7/lib64/xorg/modules/drivers/fbdev_drv.so /usr/X11R7/lib64/xorg/modules/drivers/intel_drv.so /usr/X11R7/lib64/xorg/modules/drivers/modesetting_drv.so /usr/X11R7/lib64/xorg/modules/drivers/nouveau_drv.so /usr/X11R7/lib64/xorg/modules/drivers/nv_drv.so /usr/X11R7/lib64/xorg/modules/drivers/openchrome_drv.so /usr/X11R7/lib64/xorg/modules/drivers/radeon_drv.so /usr/X11R7/lib64/xorg/modules/drivers/sis_drv.so /usr/X11R7/lib64/xorg/modules/drivers/vesa_drv.so /usr/X11R7/lib64/xorg/modules/drivers/vmware_drv.so
+ DRIVERS=ati
fbdev
intel
modesetting
nouveau
nv
openchrome
radeon
sis
vesa
vmware
+ + sed -n /^mode:/ { s/.* //; p}
/usr/X11R7/bin/ddcprobe
+ AVAIL_RES_COLOR=640x400x256
640x480x256
800x600x256
1024x768x256
1280x1024x256
640x480x64k
800x600x64k
1024x768x64k
1280x1024x64k
320x200x64k
1600x1200x256
1600x1200x32k
1600x1200x64k
+ echo 640x480
+ echo 800x600
+ echo 1024x768
+ echo 1280x1024
+ /usr/X11R7/bin/ddcprobe
+ sed -n /^mode:/ { s/.* //; s/x/@/2; s/@.*//; p}
+ sort+  -h
uniq
+ + /usr/X11R7/bin/ddcprobe
sed -n /timing:/ {s/.* //; s/@.*//; p}
+ AVAIL_RES=auto 
		(8514A)
IBM)
(VESA)
(VGA)
320x200
640x400
640x480
800x600
1024x768
1152x864
1280x1024
1600x1200 
		custom
+ ls /dev/fb /dev/fb0
+ AVAIL_FB=/dev/fb
/dev/fb0
+ lspci
+ sed -n /VGA/ {s/ / "/;s/$/"/;p}
+ AVAIL_CARDS=01:05.0 "VGA compatible controller: ATI Technologies Inc Device 9710"
+ id -u
+ [ 0 -ne 0 ]
+ [ -e /usr/share/X11/xorg.conf.d/20-gpudriver.conf ]
+ true
+ choose_driver
+ drv=
+ desc=very old ATI cards
+ drv= ati "very old ATI cards"
+ desc=Generic framebuffer driver
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver"
+ desc=modern Intel cards (KMS)
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)"
+ desc=modesetting
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting"
+ desc=new Nvidia driver (KMS)
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)"
+ desc=old Nvidia driver
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)" nv "old Nvidia driver"
+ desc=openchrome
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)" nv "old Nvidia driver" openchrome "openchrome"
+ desc=ATI/AMD Radeon cards (KMS)
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)" nv "old Nvidia driver" openchrome "openchrome" radeon "ATI/AMD Radeon cards (KMS)"
+ desc=SIS cards
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)" nv "old Nvidia driver" openchrome "openchrome" radeon "ATI/AMD Radeon cards (KMS)" sis "SIS cards"
+ desc=Generic video driver
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)" nv "old Nvidia driver" openchrome "openchrome" radeon "ATI/AMD Radeon cards (KMS)" sis "SIS cards" vesa "Generic video driver"
+ desc=VMware driver
+ drv= ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)" nv "old Nvidia driver" openchrome "openchrome" radeon "ATI/AMD Radeon cards (KMS)" sis "SIS cards" vesa "Generic video driver" vmware "VMware driver"
+ eval dlg --menu "Choose Driver" 0 0 0 ati "very old ATI cards" fbdev "Generic framebuffer driver" intel "modern Intel cards (KMS)" modesetting "modesetting" nouveau "new Nvidia driver (KMS)" nv "old Nvidia driver" openchrome "openchrome" radeon "ATI/AMD Radeon cards (KMS)" sis "SIS cards" vesa "Generic video driver" vmware "VMware driver"
+ dlg --menu Choose Driver 0 0 0 ati very old ATI cards fbdev Generic framebuffer driver intel modern Intel cards (KMS) modesetting modesetting nouveau new Nvidia driver (KMS) nv old Nvidia driver openchrome openchrome radeon ATI/AMD Radeon cards (KMS) sis SIS cards vesa Generic video driver vmware VMware driver
+ Xdialog --stdout --title Xorgwizard --menu Choose Driver 0 0 0 ati very old ATI cards fbdev Generic framebuffer driver intel modern Intel cards (KMS) modesetting modesetting nouveau new Nvidia driver (KMS) nv old Nvidia driver openchrome openchrome radeon ATI/AMD Radeon cards (KMS) sis SIS cards vesa Generic video driver vmware VMware driver
+ drvchoice=radeon
+ choose_card
+ wc -l
+ echo 01:05.0 "VGA compatible controller: ATI Technologies Inc Device 9710"
+ [ 1 -lt 2 ]
+ busid=auto
+ return
+ choose_resolution
+ res=
+ res= auto "Let driver choose"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480" 800x600 "800 x 600"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480" 800x600 "800 x 600" 1024x768 "1024 x 768"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480" 800x600 "800 x 600" 1024x768 "1024 x 768" 1152x864 "1152 x 864"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480" 800x600 "800 x 600" 1024x768 "1024 x 768" 1152x864 "1152 x 864" 1280x1024 "1280 x 1024"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480" 800x600 "800 x 600" 1024x768 "1024 x 768" 1152x864 "1152 x 864" 1280x1024 "1280 x 1024" 1600x1200 "1600 x 1200"
+ res= auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480" 800x600 "800 x 600" 1024x768 "1024 x 768" 1152x864 "1152 x 864" 1280x1024 "1280 x 1024" 1600x1200 "1600 x 1200" custom "Type in your own resolution"
+ true
+ eval dlg --menu "Choose Resolution" 0 0 0 auto "Let driver choose" (8514A) "(8514A) x (8514A)" IBM) "IBM) x IBM)" (VESA) "(VESA) x (VESA)" (VGA) "(VGA) x (VGA)" 320x200 "320 x 200" 640x400 "640 x 400" 640x480 "640 x 480" 800x600 "800 x 600" 1024x768 "1024 x 768" 1152x864 "1152 x 864" 1280x1024 "1280 x 1024" 1600x1200 "1600 x 1200" custom "Type in your own resolution"
/usr/sbin/xorgwizard: 1: eval: Syntax error: "(" unexpected
+ reschoice=
+ return 1
+ rm /usr/share/X11/xorg.conf.d/20-gpudriver.conf
rm: cannot remove `/usr/share/X11/xorg.conf.d/20-gpudriver.conf': No such file or directory
+ [ -e /usr/share/X11/xorg.conf.d/20-gpudriver.conf.bak ]
+ dlg --msgbox Cancelled. Nothing changed. 5 40
+ Xdialog --stdout --title Xorgwizard --msgbox Cancelled. Nothing changed. 5 40
+ break
# 

[jamesbond]

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?

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.

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.

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.

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)

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.

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.

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).

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

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: Select all

su spot
cd /root/spot/Downloads

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

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, I've identified the culprit. Fix is on the way.

cheers!

[Scotchialoo]

I have a one problem and a one question.

Problem:

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

[Ted Dog]

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.

[Sunny]

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:

/usr/lib64/gcc/x86_64-t2-linux-gnu/4.6.2/../../../../x86_64-t2-linux-gnu/bin/ld: Please report this bug.

collect2: ld returned 1 exit status
make[1]: *** [/mnt/sda8/fatdog-630/glibc-2.18.0/linkobj/libc.so] Error 1

Any suggestions?

[L18L]

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)

a) for you
b) for me
OK?

[L18L]

first b) steps

edit
... and 2nd

translated comment of desktop file in use

[jamesbond]

I have a one problem and a one question.

Problem:

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.

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?

I am having problems compiling glibc-2.18 in Fatdog64-630.

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

first b) steps

edit
... and 2nd

translated comment of desktop file in use

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:

Code: Select all

gtk gtk_server_define setlocale NONE STRING 2 INT STRING
gtk gtk_server_define bindtextdomain NONE STRING 2 STRING STRING
gtk gtk_server_define textdomain NONE STRING 1 STRING
gtk setlocale 6 ""
gtk bindtextdomain $TEXTDOMAIN $TEXTDOMAINDIR  
gtk textdomain $TEXTDOMAIN
gtk gtk_init # and so on and so on ...

And then create the POT file (using the event-manager as an example):

xgettext --sort-output --keyword=translatable -o event-manager.pot -L glade /usr/sbin/fatdog-event-manager.sh.xml

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

[L18L]

first b) steps

edit
... and 2nd

translated comment of desktop file in use

Interesting!

For now this has not been used in puppy.
But it works now. My fatdog-event-manager.desktop containing comments for de_BE and de:

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Name[de]=Fatdog64 Ereignis-Manager
Name=Fatdog64 Event Manager
Icon=so.xpm
Comment[de_BE]=Einstellingen für das periodische Speichern und die Desktop-Laufwerks-Symbole
Comment[de]=Einstellungen für periodisches Speichern und Desktop-Laufwerks-Symbole
Comment=Configure periodic save settings and desktop drive icon preferences
Exec=fatdog-event-manager.sh
Terminal=false
Type=Application
Categories=X-Desktop
GenericName=eventmanager
NoDisplay=true

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

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.

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")

[Sunny]

jamesbond wrote:

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.

Thanks again for the help!

[L18L]

...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")

Not necessary!
I have made MoManager-20131029 (not yet published) handle these files too
More than 1 script and/or xml in one TEXTDOMAIN (fatdog64 for now) is possible!

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<interface>
  <requires lib="gtk+" version="2.18"/>
  <!-- #20131028 MoManager needs this file be executable and this:
export TEXTDOMAIN=fatdog64
  -->    
  <!-- interface-naming-policy project-wide -->
  <object class="GtkWindow" id="main_window">
    <property name="can_focus">False</property>
    <property name="title" translatable="yes">Fatdog64 Event Manager</property>

[jamesbond]

L18L,

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).

[L18L]

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?

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 )

[gcmartin]

Would the work on REMASTER2 apply to this distro, as well?
Or, has the consideration shown there already happening in FD630?

Curious

[jamesbond]

Would the work on REMASTER2 apply to this distro, as well?
Or, has the consideration shown there already happening in FD630?

Curious

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.

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).

"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).

cheers!

[L18L]

...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.

I've been using run-me.sh and could see fatdog-even-manager run in German. But I did work only if LC_MESSAGES=$LANG
LC_MESSAGES=de fell back to C because ....
LC_MESSAGES=de_DE fell back to C because ....
LC_MESSAGES=de_DE.UTF-8 works.
LC_MESSAGES must be a directory

Working with LANG means gettext will
find msgstr in TEXTDOMAINDIR/de_DE.UTF-8/LC_MESSAGES/TEXTDOMAIN.mo
if not found
find msgstr in TEXTDOMAINDIR/de_DE/LC_MESSAGES/TEXTDOMAIN.mo
if not found
find msgstr in TEXTDOMAINDIR/de/LC_MESSAGES/TEXTDOMAIN.mo
if not found use msgid

For German there is just directory de
But locales are for Austria Belgium Germany Lichtenstein Luxemburg and Switzerland
..and we would need symlinks from all these to de....horrible

UTF-8 must be default for all non-English locales

Speeding up in puppy is:
LANG_ORIG=$LANG
LANG=C
...
LANG=$LANG_ORIG

.... 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

Thanks for your PM containing your fix for momanager's find

find /bin /sbin /usr/bin /usr/sbin /usr/X11R7/bin /usr/local /etc/rc.d /root/my-applications/bin -maxdepth 4 -type f -executable -print0 | xargs -0 grep --files-with-matches '^export TEXTDOMAIN=' | while read -r p; do echo "$p"; [ -e "${p}.xml" ] && echo "${p}.xml"; done | sed -e 's% %SPACECHAR%g' > $CACHE/GETTEXTSCRIPTS

I have have run it without -executable successfully. It is fast!
...and the xml files are found without the commented export Text...
But
export TEXTDOMAIN=...
is needed
Maybe we (you ? ) can integrate it into that find code (and I will test) ?
Then MoManager can use the unchanged not executable *.xml files.

[Scotchialoo]

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:

/usr/lib64/gcc/x86_64-t2-linux-gnu/4.6.2/../../../../x86_64-t2-linux-gnu/bin/ld: Please report this bug.

collect2: ld returned 1 exit status
make[1]: *** [/mnt/sda8/fatdog-630/glibc-2.18.0/linkobj/libc.so] Error 1

Any suggestions?

Maybe you have even a Old GCC (4.6.2 instead 4.8.2)?
Even I tried it build too even in binutils (with configure --prefix=/usr --build=x86_64-t2-linux-gnu as a Your Post.) and That's same Problem...
from

cd glibc-build
glibc2.18/.configure --prefix=/usr --libdir=/usr/lib64
make

Maybe I will be wait to FatDog64-700 too... I want to fix any problems... (Maybe I am not creator a FatDog64 but I will be search problems.)
And I have a another problem with Wine64: I Compiled with --enable-win64 Command with fd64-devx_630.sfs [FatDog64 Developerment package]: Compile is works around (without --enable-win64: Depend to 32bit Development libraries),but Wine64 doesn't creates even with 32bit system. (Native Firefox from Nightly works around.) -> http://www.murga-linux.com/puppy/viewtopic.php?t=89950 [With Known problems]

[L18L]

Specify a dict server please.

Code: Select all

'dict.conf' doesn't specify any dict server

[L18L]

...The desktop drive icons should be placed some bits higher.... (see my screeny above)...

Forgive me my ignorance

I have found the Fatdog way to solve this problem (translating event manager ):

Control Panel > Fatdog Event Manager
Drive icon margins
Bottom

Changed from 55 to 85 solved my problem.

[L18L]

For German there is just directory de
But locales are for Austria Belgium Germany Lichtenstein Luxemburg and Switzerland
..and we would need symlinks from all these to de....horrible

Sorry, no it is NOT horrible!
A symlink from LANG to ${LANG:0:2} only is needed (that is just one!)

I am running fatdog now with LC_MESSAGES=$LANG and LANG=C