AwesomeWM on Raspberry Pi "Error Nil at Screen Connect" - awesome-wm

I have Arch installed on my raspberry pi and am trying to use AwesomeWM. It works with the basic config, but when I try to use my modified version of copycats copland theme I get this error on the following line.
"Error Nil at Screen Connect"
-- Create a wibox for each screen and add it
awful.screen.connect_for_each_screen(function(s) beautiful.at_screen_connect(s) end)
-- }}}
I had a similar issue with i3 on it with raspbian and I think the issue is due to the pi not having a lvds display. Is there anyway to fix this issue on the pi? This config works just fine on my laptop.

I had the same issue last night. There's some issue with the lain, noted here that is resulting in every single awesome copycat theme save the last being broken. While there are solutions are that issue on updating the version of Glib, I found it much simpler to revert to an earlier checkout of lain.
To do this, cd into the lain folder. Then run
git checkout -b SAFE_COMMIT_HASH
I personally ran
git checkout -b 35856d49a249cdfff09439fde73351b12ed8576c
I chose a commit in January to be safe because it was late and I wanted to be done.
All I had to do after this was reboot my Awesome shell and everything went back to working order.

Related

Freebasic install for Raspberry Pi problem

I am looking to install Freebasic on a Raspberry Pi. I have already looked at the Freebasic forum - but it seems from a lot of posts that others have found that following the steps shown no longer end up working.
Other Pi forums have said that a working installation can be difficult to achieve.
I am trying to find a way to get the freebasic compiler running on an otherwise virgin installation, starting from Noobs.
At first I thought it was too difficult for me, but even some serious pi-enthusiasts who were going to help me have ended up stumped.
This link has a step by step that can be considered simple, as long as attention is paid to the directories and first step, installing some necessary packages.
I followed steps 1 through 5 and installed it on my Raspberry.
From what is reported there, "part of the problem is that FreeBASIC is written primarily in FreeBASIC, so you need a working compiler to initialize the latest version".
Therefore, you need to install an "old version" (step #2), clone the latest version and compile it with the old version (step #3). Uninstall old version (step #4) and install new version (step #5).
In step #3 I used the make -j4 command. I have a Raspberry Pi 3 model B.
In my case, I used fbc_linux_armv6_rpi_0365_2020-01-12.zip as "old version". I tested the installation by compiling and running a program and it was OK, working perfectly.

Fedora 30: GTK fails to load appmenu-gtk-module

I am learning to program in Python and Rust. On different versions of Ubuntu these programs compiled and ran perfectly. Now that I have a dedicated Fedora 30 KDE system, every time I try and build a program, I get a warning: Failed to load module "appmenu-gtk-module"
I have tried looking this up and have re/installed anything GTK on my system. The programs otherwise function well, but no menus are drawn. I was also trying things in GNOME and hit the same thing.
I am also using QT. Those programs also build and run fine, but again, no menu.
I'm going bonkers with this. Any help is appreciated.
The appmenu-gtk module is not packaged on Fedora. (GNOME doesn't support them anyway.)
The real questions are:
Why is it configured to load? Did you copy or share GTK config files from an Ubuntu system? You should remove this module from your settings.
Even with improper configs I don't believe this should result in menus not appearing. It should just fail to load and work as normal. How is your application using menus?
I finally got so fed up with getting this error that I went full nerd-diagnosis, and ran this command to find out which file contained the errant reference to the appmenu-gtk (the package that would provide this is not installable on my system either).
(Replace "dolphin" with the command that is giving you the error.)
strace -e openat,access dolphin 2>&1 |grep -v ENOENT |awk '/appmenu-gtk/ {exit} !/appmenu-gtk/ {print}'|cut -d '"' -f2 |sort|uniq|xargs grep appmenu-gtk 2>/dev/null
This will then give you a list of files which contain the line appmenu-gtk, and in my case it was ~/.config/gtk-3.0/settings.ini. From there I just commented it out, and that gets rid of the error message (not sure if this will fix your problem of not having any menus, but you might just be able to edit that line to fix it in another way if commenting it out doesn't work).

Viber program stopped working log file: start timer Timers can only be used with threads started with QThread 1

I was using VIBER application(cousin of SKYPE) when it stopped working.
I re-start my PC (it's installed only on my PC win7-kaspersky) but it doesn't work anymore.
The shortcut points to C:\Users\pardis\AppData\Local\Viber where i have:
launcher.db
Viber.exe
Viber.exe.log
ViberUpdater.log
ViberUpdater.cmd
a lot of Qt*.dll files
when i click on viber.exe nothing happens(the program doesn't open-nor it's process) but just Viber.exe.log is updated with this message:
1|<> :0 => QObject::startTimer: Timers can only be used with threads
started with QThread
Any idea what should i do to make it work again? thanks
Find Viber's installation folder (C:\Users\<username>\AppData\Local\Viber on Windows 8), navigate to the folder with the name of the latest downloaded version (5.1.1.15 in my case), and run ViberSetup.exe. This should update it to the latest version, keeping your data and resolving the issue.
Had the same problem, including the text from log file. I updated the program to the latest version and it started working again, it should work for you too.
Unfortunately the version that stopped working is the latest version. When I try to reinstall, it simply says: you already have Viber installed.
I guess the only answer is to completely uninstall Viber and then reinstall a fresh version. I found a site with all recent versions. So I could reinstall and update without losing any settings or syncs.

building brackets was "Done, without errors" in Debian Wheezy, but

i was trying to build "brackets sprint 40" from source code (by following #jasonsanjose instructions look #4816 and the official wiki's page here) in my 32bit Wheezy, Using CEF3 (Verion 3.1547.1406_linux32_release with glibc 2.13) and everything was OK .
when i ran grunt build and grunt installer the output was: Running "build" task
Running "build-linux" task
Done, without errors.
and when i installed .deb package and executed it in the terminal , this error has been thrown:brackets: libcef_dll/wrapper/libcef_dll_wrapper.cc:120: int CefExecuteProcess(const CefMainArgs&, CefRefPtr): Assertion `false' failed.
Aborted
I did rebuild it many times, but the problem persist.
And this is where i stopped, i don't know where the problem lies.
some help will be appreciated, thank you in advance.
There's a duplicate of this question with longer discussion posted here - https://github.com/adobe/brackets/issues/8170.
Note: This problem shouldn't affect a "vanilla" brackets-shell build on Linux -- it's specific to a hack some people have developed to support an older version of Debian than Brackets officially supports. This requires swapping in a newer version of the CEF library, which is not always easy to do since they are not usually backwards-compatible.

GVIM - Crash during startup

Recently I wanted to try the gvim7.2 for its wonderful support of CSCOPE and installed it from my company's installation directory. However, when I execute it - I get a segmentation fault and the message looks thus,
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault (core dumped)
When I was searching for this issue in the online forums, I found general complaints about the reproducibility of the issue. Any insights on this would be greatly appreciated.
I have had crashes with incompatible shared libraries for Python3 IIRC.
I never got ultisnips working on Ubuntu Natty 64 for that very reason.
Removing the plugin made vim start normally (probably by not loading the incompatible library in the first place).
You may disable your plugins and reenable them one by one to see whether Python is the culprit, or test directly:
gvim -u NONE +'python3 print "test"'
On my box:
Fatal Python error: take_gil: NULL tstate
Vim: Caught deadly signal ABRT
Vim: Finished.
Conversely,
gvim -u NONE +'python2 print "test"'
Works correctly
This surely took me a long time to debug, I indeed went through the painful process of manually disabling every plugin that I had installed and yet the same error kept popping up.
[Solution] : It turned out that the gvim is tightly bound to the graphics settings used. We use a citrix client to remote login into UNIX servers and develop from there. As per my colleague's suggestion - I changed the color settings to "True Color 24 bit" and voila!!, things worked perfectly.
One of the classic examples of the times when we get hit by totally unsuspecting source of bugs!
Anyways, thanks for all your suggestions - I learned a lot :).
Try verbose logging,
vim -V10/tmp/vim.log
You can also try running strace to see where it is bombing,
strace vim
It's possible that it's a permissions issue, but that's a guess.
try starting Vim like so:
$ vim -u NONE
which will disable all plugins to see if the problem still persists.
If it starts OK, move all the plugins from Vim's runtime directory (usually):
~/.vim/
on Linux & add them back one by one until the seg fault occurs.
Can be a tedious process especially as there may be a conflict between two or more plugins & in that case, it hard to ascertain when exactly they clash, but nine times out of ten, it usually gets you to the root of the problem.

Resources