All,
Upon k3b start, the only error received during startup check was:
<quote> System locale charset is ANSI_X3.4-1968 Your system's locale charset (i.e. the charset used to encode filenames) is set to ANSI_X3.4-1968. It is highly unlikely that this has been done intentionally. Most likely the locale is not set at all. An invalid setting will result in problems when creating data projects. Solution: To properly set the locale charset make sure the LC_* environment variables are set. Normally the distribution setup tools take care of this. </quote>
I know about a year ago, there was considerable discussion about where these variables should be set. Looking, it seems that some distros take care of this with XDG config which can be set separately between gnome XDG and kde XDG. Does TDE need to look at setting these? I don't know the answer. I do know SuSE sets them and Arch doesn't. So there is a variation between the way this is handled distro to distro. May not be a bad thing to do in the TDE config if these setting matter.
Upon k3b start, the only error received during startup check was:
<quote> System locale charset is ANSI_X3.4-1968 Your system's locale charset (i.e. the charset used to encode filenames) is set to ANSI_X3.4-1968. It is highly unlikely that this has been done intentionally. Most likely the locale is not set at all. An invalid setting will result in problems when creating data projects. Solution: To properly set the locale charset make sure the LC_* environment variables are set. Normally the distribution setup tools take care of this. </quote>
I know about a year ago, there was considerable discussion about where these variables should be set. Looking, it seems that some distros take care of this with XDG config which can be set separately between gnome XDG and kde XDG. Does TDE need to look at setting these? I don't know the answer. I do know SuSE sets them and Arch doesn't. So there is a variation between the way this is handled distro to distro. May not be a bad thing to do in the TDE config if these setting matter.
The starttde script makes a feeble effort to set the XDG_CONFIG_DIRS and XDG_DATA_DIRS variables.
Big picture, I am not in favor of tinkering further. This is mostly a distro issue, although I am curious how you resolve the k3b error on your system.
Does k3b still burn despite the previously reported hal configure warnings?
Darrell
On 03/27/2012 09:37 PM, Darrell Anderson wrote:
The starttde script makes a feeble effort to set the XDG_CONFIG_DIRS and XDG_DATA_DIRS variables.
Big picture, I am not in favor of tinkering further. This is mostly a distro issue, although I am curious how you resolve the k3b error on your system.
Does k3b still burn despite the previously reported hal configure warnings?
Darrell
Dunno,
Still running in VB - no burner :) I guess I could try configuring VB to recognize the host writer as a writer withing vbox, but any problems and I'm not sure we would have a valid test. Ever configure VB to write to a host burner? (I've never had the need until now :)
Still running in VB - no burner :) I guess I could try configuring VB to recognize the host writer as a writer withing vbox, but any problems and I'm not sure we would have a valid test. Ever configure VB to write to a host burner? (I've never had the need until now :)
* Close the VM and open the VirtualBox configurator.
* For the appropriate VM, select the Storage section.
* Select the CD/DVD controller.
* Change the option from Empty to Host Drive.
* Enable the Passthrough check box.
* Start the VM.
I am testing K3B in a VM right now as I write. Like yours, my k3b package built without HAL support. Yet the disk is burning without incident.
I haven't rebooted to test in a physical machine.
Darrell
-
Darrell Anderson -
David C. Rankin