Fatdog64-700 beta2 [Closed]

[L18L]

desktop icon with title "First-time localisation setup" or something like that?

English-only is English-only is E.......
__________________________________________________
Internationalization of Fatdog64-700b2

[L18L]

... Certain locale e.g. en_DK actually needs da_DK also).

Does that mean glibc is ....glibberish
Sorry for derailing a bit...
Once I have been trying to create de_DK and da_DE
because borders are fuzzy in real life.
I would also like ar_DE and tr_DE and de_IT and ... if that would be possible....

[gcmartin]

I think this was suggested some time in the past, but, would @Shinobar & BarryK's FirstRUN "Personalize Settings" either in Menu or Control Panel or at system start help, not just for Language, but for other things as well?

Hope this helps

[Wognath]

- bcrypt_gui - will update, thanks [EDIT] - ends up with a total re-write.

@jamesbond: while you're at it you might consider requiring password once to decrypt, twice to encrypt.

[jamesbond]

desktop icon with title "First-time localisation setup" or something like that?

English-only is English-only is E.......

Well we can put the icon title as "Welcome/Willkommen/Bienvenue/etc" ... will have to standardise on a few languages unfortunately.

- bcrypt_gui - will update, thanks [EDIT] - ends up with a total re-write.

@jamesbond: while you're at it you might consider requiring password once to decrypt, twice to encrypt.

yes, I already did.

Does that mean glibc is ....glibberish

No it's just making the split between providing "en_*" only locale and the rest a bit more convoluted

I think this was suggested some time in the past, but, would @Shinobar & BarryK's FirstRUN "Personalize Settings" either in Menu or Control Panel or at system start help, not just for Language, but for other things as well?

See above on the "welcome" icon. It won't be "auto-launched". But if anyone offers me a readable "first-run" script, I promise I'll consider to include it into the base. Taking Barry's or Shinobar's scripts won't do; many setups are done differently on Fatdog as compared to Puppy.

@technosaurus: I also didn't see a way to install FD64 to disk after booting from a unetbootin installed FD64 usb drive ... at least not in the control panel or start menu. - OK I read on how unetbootin does it stuff. Basically it isn't too difficult - I just need to offer a way to locate vmlinuz and initrd manually (and these get copied as part of installation). An easier way, perhaps, is just to copy the entire fatdog.iso file to the unetbootin-ed USB and tell the installer to locate that ISO file.

[gcmartin]

An easier way, perhaps, is just to copy the entire fatdog.iso file to the unetbootin-ed USB and tell the installer to locate that ISO file.

I did test this specific in the past. It worked.

I found @Scooby's approach easiest as it allowed different ISO flavors of a distro's family to exist on media. And, could easily be used in a KVM guest for booting ISOs and testing.

I know KVM and SAMBA are OOTB in FATDOG. So using @MikeB's QEMU Launcher, FATDOG is an excelllent facility in testing in FATDOG. BTW, I have shared that FATDOG RUNS FASTER IN A KVM guest than it runs normally, Noticeably so. Any guesses why? (No answer is required or needed, per sec.Just curious)

Hoping that as FATDOG moves to GA, it has latest

• SAMBA V4+
• DNSMASQ
• QEMU V2+

Hope this helps

[boblark]

I am new to FD64, but so far the experience has been great. Thanks for all the effort to make this happen.

I am installing octave and have gone to Gslapt, and done a "successful " install on gnu-octave. When I type "octave" into a terminal, I receive:

Code: Select all

/usr/bin/octave-cli-3.8.2: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory

I don't find this dependency in Gslapt. What is the proper way to deal with this? Also are others using octave without problems?

[SFR]

Code: Select all

/usr/bin/octave-cli-3.8.2: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory

This lib is in devx.sfs. D/L and load it:
http://distro.ibiblio.org/fatdog/sfs/70 ... _700b2.sfs
___________

- I mentioned earlier my issues with my intel sound card (where device 1 is the actual device) and posted an alsa conf entry to fix it... something like that could probably be added to a sound wizard. --> sound wizard only works with ALSA devices (so far). And there is no relationship between ALSA devices and OSS (/dev/dsp*) devices. For example, in my laptop, I have two ALSA devices (hw:0 for analog output and hw:1 for HDMI output) but there is only one /dev/dsp. Please print the content of your /proc/asound/oss/devices and /proc/asound/oss/sndstat for comparison?

Since it appears that Techno's and mine sound chips have similar "layout", perhaps this will help (Acer AO 722):

Code: Select all

  0: [0- 0]: mixer
 16: [1- 0]: mixer
 19: [1- 0]: digital audio
 20: [1- 0]: digital audio

Code: Select all

Sound Driver:3.8.1a-980706 (ALSA emulation code)
Kernel: Linux fatdog64-1eb 3.17.1 #1 SMP Sun Oct 19 15:10:08 EDT 2014 x86_64
Config options: 0

Installed drivers: 
Type 10: ALSA emulation

Card config: 
HD-Audio Generic at 0x90444000 irq 25
HDA ATI SB at 0x90440000 irq 16

Audio devices:
1: CX20588 Analog (DUPLEX)

Synth devices: NOT ENABLED IN CONFIG

Midi devices: NOT ENABLED IN CONFIG

Timers:
31: system timer

Mixers:
0: ATI R6xx HDMI
1: Conexant CX20588

Btw, any idea why beep doesn't make a sound on any of my two laptops?
I had this problem with Lupu-528, then no probs at all with Slackos (5.3.3 - 5.7) and now it has returned in FD...

Greetings!

[boblark]

SFR wrote:

This lib is in devx.sfs. D/L and load it:
http://distro.ibiblio.org/fatdog/sfs/70 ... _700b2.sfs

SOLVED
Octave is running terminal and GUI. I'll just leave that SFS loaded. Thanks, Bob

[technosaurus]

Re: beep
Iirc "beep" uses the pc speaker, many distros don't load it's driver or one that emulates it via the sound card because frankly most things that use it are just plain annoying. If you're not annoyed like the majority, you'll have to enable it by mod probing (possibly compiling) the appropriate drivers.

[SFR]

Re: beep
Iirc "beep" uses the pc speaker, many distros don't load it's driver or one that emulates it via the sound card because frankly most things that use it are just plain annoying. If you're not annoyed like the majority, you'll have to enable it by mod probing (possibly compiling) the appropriate drivers.

Actually, I don't mind it's disabled by default (AO722's beep it extremely loud and always scares the hell out of me), just would like to have a way to enable it on demand.
I already tried CONFIG_SND_HDA_INPUT_BEEP=y, but no difference; dunno what else could I try...

Greetings!

[technosaurus]

A lot of computers these days don't have a PC speaker installed. I once used an old set of headphones with the stripped wires attached to the pins with a clothes-pin to hear the POST beeps for trouble-shooting, but I don't know what the beeps mean anymore. Also many laptops may not even support a "PC speaker".

Maybe this will help though:
http://www.gentoo-wiki.info/HOWTO_Virtual_PC_Speaker

[Sage]

"Beep codes" remain an immutable constituent of x86 code according to my spies. An on-off/vol switch has always been part of the k/b-only controlled retrovol, but not all Puppies use it, the PCspeaker control doesn't always work, sound chip/card selection can be absent or confusing and the routing of sound-out/PCspeaker has varied across the spectrum of mboards this last millennium often conflicting with the said device. Cheapskates like Dell were prime perpetrators at one time. Notwithstanding, on some HW I used to use the PC speaker as o.p. on testing systems with interesting effects when the latter was just a tiny onboard sounder. At most, only a couple of wires required soldered across the board, but usually possible by other various low cunning other than SW.

[jamesbond]

The driver needed for "beep" is "pcspkr" driver. Normally it is already loaded (if not, you can force it to load at boot time by adding it to /etc/modules).

"beep" doesn't work in urxvt because it is disabled. See /etc/X11/app-defaults/URxvt (visualBell: true). Remove that line (or change to "false"). Alternatively, you may want to create $HOME/.Xdefaults and add visualBell there (/etc/X11/app-defaults is system-wide, while $HOME/.Xdefaults is per-user).

If you *really* want to have fun, then "rmmod pcspkr" and "modprobe snd-pcsp". Check your /proc/asound/cards, you'll have a new "soundcard" that is your PC speaker. Then try it "speaker-test -t wav -c 2 -Dplughw:2" (replace 2 with the number you've got from /proc/asound/cards). I can't have this fun, my laptop does not have the beeper in it. No matter what I do, I can't make it beep. After you get bored enough and want to have your beep back, "rmmod snd-pcsp" and "modprobe pcspkr" back.

@boblark: The library for R from the package is from aaa-gcclibs-full. Taking it from devx works too. Of you may want to use step's R sfs package (this one is more tested and proven to work, the repo's one is not...): http://murga-linux.com/puppy/viewtopic. ... 845#801845.

@SFR/@technosaurus: Ok, I know what you mean now. Basically HDMI output is /dev/dsp0 (and /dev/dsp), and normal soundcard becomes /dev/dsp1. I have similar problem, I solved it in a different way - I tell modprobe to load my "normal" soundcard first, (so that it gets the first index - /dev/dsp) and the HDMI one later. Here is my /proc/asound/cards:

Code: Select all

 0 [Generic_1      ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfeb40000 irq 16
 1 [Generic        ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfeb44000 irq 28 

And here is my /etc/modprobe.d/alsa-fix.conf:

Code: Select all

options snd-hda-intel id=Generic_1 index=0
options snd-hda-intel id=Generic index=1

I think you could do similarly.

As for fixing playing with switching symlinks for /dev/dsp ... that may not always work. In my case (with the above setup) I have /dev/dsp but not /dev/dsp0 nor /dev/dsp1. So there is nothing to switch. Interestingly, I *do* have /dev/mixer and /dev/mixer1 (but no /dev/mixer0).

[Ted Dog]

back in the day company removed sound card or did not buy one. We used the motherboard micobuzzer ( speaker ) and ran the talk program in dos-shell to 'add ghost voices' to coworkers machines. sounds other worldly.

[Sage]

Nice to have the full SP, thanks, jb. Just need you to to call round about this HDMI sound issue...

[SFR]

Re: BEEP

Finally nailed it!

Once again, I have enabled these (like it is in Slacko):
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1
CONFIG_SND_HDA_INPUT_JACK=y
(1st & 4th probably not needed, but just in case...)

And this time I recompiled not only bzImage, but also all modules in sound/pci/hda/*.
Then after depmod and reboot the 'Beep' control showed up in Alsamixer/Retrovol at last (see scrsht) and it's working.

Code: Select all

options snd-hda-intel id=Generic_1 index=0 
options snd-hda-intel id=Generic index=1

Yep, it re-ordered the soundcards properly, thanks!
What's interesting, it also made the 'beep' command working (on Acer AO722; my main box, on which I was struggling with beep, is Toshiba), without the need of the above recompiling, but also without the 'Beep' control in Alsamixer.

In my case (with the above setup) I have /dev/dsp but not /dev/dsp0 nor /dev/dsp1

Yeah, same here. And without the above setup I had only /dev/dsp1 (no dsp/dsp0).

Greetings!

[olinm]

remote-code exec flaw in GNU C Library TERRIFIES Linux

http://www.theregister.co.uk/2015/01/27 ... erability/

Security researchers have uncovered a critical bug in the GNU C Library (glibc), a key component of Linux and some other operating systems, which could render countless machines vulnerable to remote code execution attacks.

The flaw, which was discovered by Qualys and assigned CVE-2015-0235, is known as the GHOST vulnerability because it can be triggered by the library's gethostbyname family of functions.

An attacker who successfully exploits the flaw can potentially gain complete control over an affected machine without any prior knowledge of system logins or passwords.

[jamesbond]

remote-code exec flaw in GNU C Library TERRIFIES Linux

http://www.theregister.co.uk/2015/01/27 ... erability/

Security researchers have uncovered a critical bug in the GNU C Library (glibc), a key component of Linux and some other operating systems, which could render countless machines vulnerable to remote code execution attacks.

The flaw, which was discovered by Qualys and assigned CVE-2015-0235, is known as the GHOST vulnerability because it can be triggered by the library's gethostbyname family of functions.

An attacker who successfully exploits the flaw can potentially gain complete control over an affected machine without any prior knowledge of system logins or passwords.

Thanks. The 700 series are not affected, the bug is for glibc between 2.2 and 2.17. Fatdog 700 uses glibc 2.19.

[olinm]

Thanks James for confirming.