Tiny Core Linux
Tiny Core Extensions => TCE Corepure64 => Topic started by: nick65go on May 12, 2019, 07:07:45 AM
-
tc@box:~$ XDG_SESSION_TYPE=x11 adriconf
adriconf running on X11
terminate called after throwing an instance of 'boost::locale::conv::invalid_charset_error'
what(): Invalid or unsupported charset:ANSI_X3.4-1968
Aborted
or without XDG variable:
tc@btc@box:~$ adriconf
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Abortedwhat shoud I do/load? I did not use a desktop manager, just flwm (window manager), and run the from aterm.
but the message is about some charset...
-
Google says your locale could be broken. Is it possible you generated mylocale.tcz on a previous TC version? It might need to be re-generated.
-
Hi curaga, no locale was generated. I use default lang=C etc. the only 'customisation' is keyboard=gb (in X config) and 'uk' in kmaps. I do not mess with any language (English is enough for me). Not use TZ (for time etc). Just simple interface TC (flwm + wbar, aterm etc).
from aterm, the default variable (using set): 'G_FILENAME_ENCODING='iso8859-1'
other users are welcome to test my finding with bootcode= base, norestore etc...
EDIT: same bad results even after I manualy delete the folders /home/tc/.cache and /var/cache, to avoid possibile fonts cached inside them.
Edit2: the strings about 'conv' and 'ANSI_X' are as originaly:
tc@box:/usr/lib/gconv$ ls -al
drwxr-xr-x 2 root root 160 Jan 20 15:23 ./
drwxr-xr-x 4 root root 660 May 12 16:32 ../
-rwxr-xr-x 1 root root 26616 Jan 20 15:23 ANSI_X3.110.so
-rwxr-xr-x 1 root root 14328 Jan 20 15:23 ISO8859-1.so
-rwxr-xr-x 1 root root 14328 Jan 20 15:23 ISO8859-15.so
-rwxr-xr-x 1 root root 14328 Jan 20 15:23 ISO8859-2.so
-rwxr-xr-x 1 root root 14344 Jan 20 15:23 UNICODE.so
-rw-r--r-- 1 root root 56352 Jan 20 15:23 gconv-modules
-
Things work here with flwm and without the locale set:
$ locale
LANG=C
...
$ XDG_SESSION_TYPE=x11 adriconf
adriconf running on X11
Current language code is c
Exception caught: Could not create parser context [but adriconf works]
Were you using Xorg-7.7-3d? What graphics hardware do you have?
-
I used the latest Xorg with 3D acceleration as radeon, not amdgpu. I have a GCN 2.x card (mullins) because AMD A-6000 APU (cpu+gpu) has integrated R4 graphics.
-
fyi: updates in git on 28/04/2019
https://github.com/jlHertel/adriconf/commit/0b3c97b271594802bfc15f7d4fc62439e83ced8e
index of /10.x/x86_64/tcz/src/adriconf/
adriconf-1.4.tar.gz 15-Apr-2019 09:16 2608826
compile_adriconf 15-Apr-2019 09:20 811
-
Maybe you could compile from the latest git locally and, if it fixes your problem, I'll update it in the repo?
-
Hi nick65go
I think curaga has it right. I think the program wants plain 7 bit ASCII (US-ASCII) and is not finding it. Try launching it like this:
LANG= XDG_SESSION_TYPE=x11 adriconfThere is a space between LANG= and XDG_SESSION_TYPE. The idea came from:
https://stackoverflow.com/questions/48743106/whats-ansi-x3-4-1968-encoding
If you look at the table here ANSI_X3.4-1968 is the first entry.
https://www.iana.org/assignments/character-sets/character-sets.xhtml
A couple of other interesting answers:
https://unix.stackexchange.com/questions/67680/what-would-break-if-the-c-locale-was-utf-8-instead-of-ascii
-
Finaly, I solved it!
The solution was that I MUST load getlocale.tcz, then is OK, with/without setting the variable LANG=, will not matter:
tc@box:~$ adriconf
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Aborted
tc@box:~$ XDG_SESSION_TYPE=x11 adriconf
adriconf running on X11
Current language code is c
Exception caught: Could not create parser context
(adriconf:16234): Gtk-WARNING **: 21:09:25.255: Could not find the icon 'list-remove-symbolic-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from: http://icon-theme.freedesktop.org/releases
c@box:~$ LANG=dummy XDG_SESSION_TYPE=x11 adriconf
(process:16246): Gtk-WARNING **: 21:09:37.652: Locale not supported by C library.
Using the fallback 'C' locale.
adriconf running on X11
Current language code is dummy
Exception caught: Could not create parser context
Fontconfig warning: ignoring dummy: not a valid language tag
(adriconf:16246): Gtk-WARNING **: 21:09:38.489: Could not find the icon 'list-remove-symbolic-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
no pain, no gain ;) So, should be getlocale.tcz a dependency of adriconf.tcz?
EDIT: And we need a wraper/script (in tce.installed) because the icon from wbar is not working, we need to start it with XDG_SESSION_TYPE=x11 @, as I did in aterm.
-
Finaly, I solved it!
The solution was that I MUST load getlocale.tcz, then is OK, with/without setting the variable LANG=, will not matter:
well spotted - I see that if mylocale is loaded onboot without LANG being set and /usr/lib/locale/locale-archive is deleted, adriconf still works :o
EDIT: And we need a wrapper/script (in tce.installed) because the icon from wbar is not working, we need to start it with XDG_SESSION_TYPE=x11 @, as I did in aterm.
It's a little more complicated than that - the script would need to detect if x11 or wayland is being used and set XDG_SESSION_TYPE accordingly
-
Probably a dependency of getlocale, unless you ran the getlocale script.
-
IMHO, I prefer just a small start-up script in adriconf.tcz, to test for necesary variables and initializes them, then start whatever demon if necesary; without loading bloat of locales. Thanks.
-
Probably a dependency of getlocale..
'not enough coffee this morning - yes, glibc_gconv is what's missing
-
IMHO, I prefer just a small start-up script in adriconf.tcz, to test for necesary variables and initializes them, then start whatever demon if necesary; without loading bloat of locales.
proposals for startup script to recognise x11 and wayland gratefully received :)
No daemon neccessary and no locales needed.
As a temporary fix, I tried changing the desktop file to read: Exec=env XDG_SESSION_TYPE=x11 adriconf..but although I can then start adriconf like this: $ gtk-launch adriconf
adriconf running on X11
Current language code is c..it will not start from the icon :(
-
Hi Juanito, may I propose a solution?
the default variable PATH is (i saw it by using 'set'`)
PATH='/home/tc/.local/bin:/usr/local/sbin:/usr/local/bin:/apps/bin:/usr/sbin:/us
so the folder tce.install (from adriconf.tcz) will write the script in ~/.local/bin/adriconf
XDG_SESSION_TYPE=x11 /usr/local/bin/adriconf
which will be executed both from menu and wbar, because
in autogenerated ~/.wmx/Applications/adriconf we have
#!/bin/sh
exec adriconf
in autogenerated ~/.wbar we have
i: /usr/local/share/pixmaps/br.com.jeanhertel.adriconf.png
t: adriconf
c: exec adriconf
-
What would be helpful (since adriconf apparently will not work with wayland at present) would be to check the following:
As far as I can tell, this is OK as per the freedesktop standard: $ grep Exec /usr/local/share/applications/adriconf.desktop
Exec=env XDG_SESSION_TYPE=x11 adriconf..and "gtk-launch adriconf" works.
..but: $ cat /home/tc/.wmx/Applications/adriconf
#!/bin/sh
exec env XDG_SESSION_TYPE
$ cat /home/tc/.wbar
...
i: /usr/local/share/pixmaps/br.com.jeanhertel.adriconf.png
t: adriconf
c: exec env XDG_SESSION_TYPE..so adriconf will not run from the wbar icon nor menu item.
Could somebody better than me at awk take a look at wbar_update.sh and figure out how to correct things so it parses the desktop Exec line as expected?
-
hi juanito, may I ask: what is wrong with my patch? it works for me, from default flwm:
so the folder tce.install (which is autorun when tce-load -i adriconf.tcz first time) will write/copy this script in ~/.local/bin/adriconf
XDG_SESSION_TYPE=x11 /usr/local/bin/adriconfwhich will be executed both from FLWM menu and wbar. (of course, it should be chmod-ed 775 to be executable)
-
There's nothing wrong with your solution, but there does seem to be a problem with wbar, which would affect other desktop files too.
-
Hi Juanito
I spent some time researching awk and I have some answers for you. The scripts set FS (field separator) to the equal sign.
When you do this:
Exec=env XDG_SESSION_TYPE=x11 adriconfawk sees 3 fields due to the extra = sign and only grabs field #2. I formatted the flwm_topside_menu_common script
so I could follow what was going on and to add some comments:
#!/bin/sh
# (c) Robert Shingledecker 2010
# Called from tc-config to setup initial flwm system menu & tce menu
writeFLWMitem()
{
busybox awk -v output="$TARGET" ' # $TARGET is set by calling program.
BEGIN # This block of code gets executed once before any input is read.
{
FS = "=" # Sets the field separator.
name = ""
exec = ""
}
{ # This block of code gets executed on each line read from the file.
# In this context, $1 and $2 are the fields of the line being read.
if ( $1 == "Name" && name == "") # Match on the Name= line.
{
name = $2
gsub(/ /, "", name) # Removes all space characters (not tabs) from name.
}
else if ( $1 == "Exec" && exec == "") # Match on the Exec= line.
{
#exec = $2
exec = substr($0, index($0, $2)) # index returns character # $2 starts on. substr copies from that
# character # to end of $0 into exec.
test = match(exec,"%") # Return the position of the first % character found.
if ( test )
exec = substr(exec,0,test-1) # Remove all text from the % character to the end of string.
}
else if ( $1 == "Terminal" ) # Match on the Terminal= line.
{
terminal = $2 # Flag used by the END block.
}
}
END # This block of code gets executed once after all input is read.
{ # In awk, the first print "blah blah" > filename creates the file.
# Further print "blah blah" > filename commands append to the file.
print "#!/bin/sh" > output"/"name
if ( terminal == "true" )
{
print "exec aterm +tr +sb -T \""name"\" -e " exec > output"/"name
}
else
{
print "exec " exec > output"/"name
}
system("chmod +x "output"/"name)
} ' "$1" # $1 is the file name to be parsed.
}
I did the same for the wbar_update.sh script:
#!/bin/sh
# (c) Robert Shingledecker 2010
# Called from desktop.sh to update wbar icons.
writeWBARitem()
{
busybox awk -v output="$TMP" -v target="$TARGET" -v wbaricons="$TCEWBAR" '
BEGIN # This block of code gets executed once before any input is read.
{
FS = "=" # Sets the field separator.
name = ""
exec = ""
}
function rtrim(s) { sub(/[ \t]+$/, "", s); return s } # Removes all space characters and tabs from end of string.
{ # This block of code gets executed on each line read from the file.
# In this context, $1 and $2 are the fields of the line being read.
if ( $1 == "Name" && name == "") # Match on the Name= line.
{
name = rtrim($2)
gsub(/ /, "", name) # Removes all space characters (not tabs) from name.
}
else if ( $1 == "Exec" && exec == "") # Match on the Exec= line.
{
#exec = $2
exec = substr($0, index($0, $2)) # index returns character # $2 starts on. substr copies from that
# character # to end of $0 into exec.
test = match(exec,"%") # Return the position of the first % character found.
if ( test )
exec = substr(exec,0,test-1) # Remove all text from the % character to the end of string.
}
else if ( $1 == "X-FullPathIcon" ) # Match on the X-FullPathIcon= line.
{
icon = $2
}
else if ( $1 == "Terminal" ) # Match on the Terminal= line.
{
terminal = $2 # Flag used by the END block.
}
}
END # This block of code gets executed once after all input is read.
{
found = 0
while (( getline item < wbaricons ) > 0 ) # Reading /usr/local/tce.icons.
{
if ( index(item, target) > 0 ) # Check for "$APPNAME".img (why???).
{
found = 1
print "i: " icon >> output # Save to /tmp/wbar.$$.
print "t: " name > output
if ( terminal == "true" )
{
print "c: exec aterm +tr +sb -T \""name"\" -e " exec > output
}
else
{
print "c: exec " exec > output
}
getline item < wbaricons # Purge the next 2 lines.
getline item < wbaricons
}
else
{
print item > output # Save to /tmp/wbar.$$.
}
}
if ( found == 0 ) # found == 0 means this is a new wbar entry.
{
print "i: " icon >> output
print "t: " name > output
if ( terminal == "true" )
{
print "c: exec aterm +tr +sb -T \""name"\" -e " exec > output
}
else
{
print "c: exec " exec > output
}
}
close(wbaricons)
} ' "$1"
sudo mv "$TMP" "$TCEWBAR" # Replace the old /usr/local/tce.icons file with the newly created one.
sudo chmod g+w "$TCEWBAR"
}
# Script starts here.
TCEWBAR="/usr/local/tce.icons"
TCEDIR=/etc/sysconfig/tcedir
APPNAME="$1"
#OnDemand xwbar check
if grep -qw "^t: *${APPNAME}$" "${TCEDIR}"/xwbar.lst 2>/dev/null; then exit 0; fi
TMP=/tmp/wbar.$$
#
FREEDESK=/usr/local/share/applications/"$APPNAME".desktop
if [ -e "$FREEDESK" ]; then
ICONCHECK="$(awk 'BEGIN{FS = "="}$1=="X-FullPathIcon"{print $2}' "$FREEDESK")"
NAMECHECK="$(awk 'BEGIN{FS = "="}$1=="Name"{print $2; exit 0}' "$FREEDESK")"
if grep -qw "^t: *${NAMECHECK// /}$" "${TCEDIR}"/xwbar.lst 2>/dev/null; then exit 0; fi
TARGET="$APPNAME".img
[ -f "$ICONCHECK" ] && writeWBARitem "$FREEDESK" && [ -G /tmp/.X11-unix/X0 ] && wbar.sh
fi
The fix for both files is here:
#exec = $2
exec = substr($0, index($0, $2)) # index returns character # $2 starts on. substr copies from that
# character # to end of $0 into exec.The exec = line needs to be changed so it copies from the start of field #2 to the end of $0 (the entire line).
-
I'd almost forgotten about that - thanks :)
Of course an even better fix would be for adriconf to realise for itself whether it was launched from a wayland or x11 session...
-
Hi Juanito
I'd almost forgotten about that - thanks :)
I rediscovered this thread about 6 weeks ago and left an open tab to it in my browser. That solved the forgetting part, but
not the procrastination because I found it difficult to follow and understand the code. You can't fix what you don't understand. ::)
Had I reformatted and commented the code from the get go, I would have been done a lot sooner. :-[
The fix was tested against your example to make sure it was parsed correctly.
I'm guessing all of the following will be affected:
fluxbox.tcz /usr/local/bin/fluxbox_menu_common
flwm.tcz /usr/local/bin/flwm_menu_common
flwm_topside.tcz /usr/local/bin/flwm_topside_menu_common
hackedbox.tcz /usr/local/bin/hackedbox_menu_common
icewm.tcz /usr/local/bin/icewm_menu_common
jwm.tcz /usr/local/bin/jwm_menu_common
openbox.tcz /usr/local/bin/openbox_menu_common
-
@Rich, I did look to see you have posted in the TC64 forum. Maybe TC32 has this file but not TC64
/usr/local/bin/icewm_menu_common
replaced on TC64 with icewm-menu-fdo - This generates IceWM program menus from FreeDesktop .desktop files.
ref https://ice-wm.org/manual/
so hopefully my precious wm won't be affected.
-
Hi aus9
You are correct. I created that list from the 32 bit repository. I figured the same scripts were in the 64 bit versions
since they are Tinycore specific.
So in the 64 bit repository, these window managers do contain the Tinycore menu scripts:
fluxbox.tcz /usr/local/bin/fluxbox_menu_common
flwm.tcz /usr/local/bin/flwm_menu_common
flwm_topside.tcz /usr/local/bin/flwm_topside_menu_common
hackedbox.tcz /usr/local/bin/hackedbox_menu_common
jwm.tcz /usr/local/bin/jwm_menu_common
These do not contain the Tinycore menu scripts:
icewm.tcz
openbox.tcz
-
Hi aus9
... These do not contain the Tinycore menu scripts:
icewm.tcz
openbox.tcz
Correction. In the 64 bit repository, openbox has the scripts in:
openbox-config.tcz
-
Hi aus9
I updated all of the window managers in the TC11 x86, x86_64, and ARM repositories except for yours. I don't know
how your extension handles desktop icons and menus and didn't want to risk breaking something.
-
Hi Rich
Very considerate of you. If you don't mind, as I am not sure if it affects me or not, can you send me a download link to the "changed" files. I can then try them please.
1) menu handled by new executable as already mentioned, but it knows nothing about "ondemand"
2) desktop icons handled by pcmanfm, if the member elects to download and run it
I have read a number of your posts regarding ondemand, so was not too fussed that users of my TCE will lack that feature. But I can be flexible. 8)
cheers
-
Hi aus9
The 2 files modified are posted in the first 2 code boxes of reply #18. The first file is flwm_topside_menu_common.
All of the window managers have this file, except the flwm_ part has the window managers name. For example, icewm
would have icewm_topside_menu_common. The only thing that changed was this 1 line:
From:
exec = $2To:
exec = substr($0, index($0, $2))There are actually 6 scripts added to the window manager packages. I think your best bet is to grab these:
/usr/local/bin/icewm_initmenu
/usr/local/bin/icewm_makemenu
/usr/local/bin/icewm_menu_common
/usr/local/bin/icewm_ondemand
/usr/local/bin/icewm_restart
/usr/local/bin/icewm_rmitemfrom the 32 bit icewm.tcz package:
http://tinycorelinux.net/11.x/x86/tcz/icewm.tcz.info
The second file I modified is part of the wbar.tcz extension. I fixed all of those so you don't need to worry about it.
-
HI Rich,
@Paul_123 (if he reads this arch forum)
First TC64 icewm
unpacked and moved files with root powers into /usr/local/bin and saved all files backup
full reboot no good. I lose menus.
I manually then loaded a ondemand by
$ tce-load -wo ace-of-penguins
That made no difference to the menu. At this stage, as Juanito says few people use TC64 and my menu works without so far any complaints, lets leave it.
a screenshot of before and after for anyone interested, wallpaper removed to avoid copyright issues.
https://imgur.com/1KQZ5NT
2) ARM jwm for 12x (alpha)
I wanted to test ondemand menu and that works great. As its still alpha, maybe let me submit to Paul_123. I am not sure if he reads TC64 forums either. I won't submit anything for 12x for a number of days for time reasons.
-
..as Juanito says few people use TC64...
Did I say that?
-
I presume the same problem exists in the x86 repo, but as hardly anybody uses Core64, the issue hasn't arisen
http://forum.tinycorelinux.net/index.php/topic,24246.msg153375.html#msg153375
I have taken the liberty of assuming Core64 is roughly the same as CorePure64, which I abbreviate to TC64
-
By Core64, I mean the 64-bit kernel with 32-bit apps - rootfs.gz + modules64.gz + vmlinuz64
Edit: In fact the majority of tc extension submissions are for CorePure64.
-
Hi aus9
... I have taken the liberty of assuming Core64 is roughly the same as CorePure64, which I abbreviate to TC64
If you are running Core (32 bit kernel, 32 bit apps), you can only run 32 bit programs.
If you are running Core64 (64 bit kernel, 32 bit apps), you can only run 32 bit programs.
If you are running Corepure64 (64 bit kernel, 64 bit apps), you can only run 64 bit programs.
Core64 is not in the release section of the repo. You need to make it yourself:
cat rootfs.gz modules64.gz > core64.gz
Core64 lets you use more then 4 GB of RAM. While each application is still limited to 4 GB, the kernel can allocate all of
the systems memory as required.
With Core, all applications share from a pool of up to 4 GB.
With Core64, all applications share from a pool of up to the maximum amount of RAM your system can take, and each
application can have up to a maximum of 4 GB of RAM to use.
-
@Rich
Finally getting around to jwm and one issue remains that you might not spot unless you try a jwm theme.
If you get a chance, load jwm and use a web browser to click on
/home/tc/.jwmrc-theme or /usr/local/share/jwm/tce/.jwmrc-theme
What I expect to happen is you might see a xml parsing error Line Number 40, Column 13:
The missing bit is one line above and the alleged fix is "add >"
# jwm is unsquashed and renamed from squashfs-root
THEME=jwm/usr/local/share/jwm/tce/.jwmrc-theme
sed 's|<Background>#2e3a67</Background|<Background>#2e3a67</Background>|' -i $THEME
-
not sure how I got "tce" in that pathway but I make mistakes
-
Hi aus9
not sure how I got "tce" in that pathway but I make mistakes
If it's a mistake, it's been there since TC4:
http://tinycorelinux.net/4.x/x86/tcz/jwm.tcz.list
... The missing bit is one line above and the alleged fix is "add >" ...
I'll fix that in TC12 since I'm going in there anyway.
-
I may have fixed that glitch as per
http://www.tinycorelinux.net/12.x/aarch64/tcz/src/jwm/build-jwm.sh
but not the tce dir issue. Thanks heaps Rich
-
Hi aus9
The TC12 jwm extensions were not missing a > in .jwmrc-theme.