I compiled Mutt from the source. When I connect to my IMAP mailbox, some mails (but not all) have incorrect titles:
21 F 10/19 To Someone (0.4K) M-b~T~LM-b~T~#>
22 r + 10/19 Someone (1.0K) M-b~T~LM-b~T~#>
23 F 10/19 To Someone (0.2K) M-b~T~LM-b~T~#>
The mutt version and compilation options:
Mutt 1.5.21 (2010-09-15)
System: Linux 3.2.0-30-generic-pae (i686)
ncurses: ncurses 5.9.20110404 (compiled with 5.9)
hcache backend: Berkeley DB 4.8.30: (April 9, 2010)
Compile options:
-DOMAIN
-DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK
-USE_POP +USE_IMAP -USE_SMTP
+USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSS +HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/local/share/mutt"
SYSCONFDIR="/usr/local/etc"
EXECSHELL="/bin/sh"
-MIXMASTER
I found the answer here: http://dev.mutt.org/trac/wiki/MuttFaq/Charset
Basically what went wrong was linking against the wrong ncurses library. What you want is linking against libncursesw:
$ ldd `which mutt` | grep curses
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb7752000)
not just libncurses. Checking at my configure script, the output was similar to this:
checking for ncurses/ncurses.h... no
checking for waddnwstr in -lncursesw... no
After installing libncursesw5-dev (Ubuntu/Debian), the correct libraries were found, linked against and the headers look fine.
I faced a similar problem with Putty when trying to use mutt through SSH. The solution is to change the charset used.
Putty->Settings->Window->Translation
Changed charset form ISO-8859-1 (Latin-1) to UTF-8.
Incidentally, the same page also has settings for how Putty handles line-drawing characters, but this didn't do anything for me.
Related
I have an OCaml program that worked fine on Ubuntu 16 but when recompiled and run on Ubuntu 20 I get the following error:-
$ ocamldebug ./linearizer
OCaml Debugger version 4.08.1
(ocd) r
Loading program... done.
Time: 89534
Program end.
Uncaught exception: Sys_error "Illegal seek"
(ocd) b
Time: 89533 - pc: 624888 - module Netaccel_link
No source file for Netaccel_link.
I thought this was due to missing dev libraries but:-
$ sudo apt install libocamlnet-ocaml-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libocamlnet-ocaml-dev is already the newest version (4.1.6-1build6).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
What setup step am I missing on Ubuntu 20?
This looks like a regression bug in libocamlnet and you should report an issue there or, I am a bit pessimistic that you will get any response, you can try to debug the issue yourself.
The problem that you are facing has nothing to do with missing libraries (they will be reported during installation or, if the package is broken, end up in linker errors). It may result, however, from some misconfiguration of the system. If that is true, then you're lucky as you can fix it yourself.
I will give you some advice that might help you in debugging this issue. For more, please try using discuss.ocaml.org as a more suitable media (SO doesn't favor this kind of a discussion and we might get deleted by admins).
The illegal seek exception is thrown when the seek operation is applied on a non-regular file, aka ESPIPE Unix error. So check your inputs. It could be that what was previously regarded as a file in Ubuntu is now a pipe or a socket.
Try to use ltrace or strace to pinpoint the culprit e.g.,
ltrace ./linearizer
or, if it overwhelms you, try strace
strace ./linearizer
Instead of using ocamldebug you can use plain gdb. You can use gdb's interfaces to provide the path to the source code (though most likely it won't work since ocamlnet is not compiled with debug information). I believe that it will give you a more meaningful backtrace.
Instead of using the system installation try using opam. Install your dependencies with opam and try older versions as well as newer versions of the OCaml compiler. Also, try different versions of ocamlnet. Ideally, try to reproduce the environment that used to work for you.
When nothing else works, you can use objdump -d and look at the disassembly of your binary. OCaml is using a pretty readable and intuitive name mangling scheme (<module_name>__<function_name>_<uid>), so you can easily find the source code (search for <module_name>.ml file and look for the <function_name> there)
Finally, just use docker or any other container to run your application. Consider switching from ocamlnet to something more modern and supported.
I'm using a Blue Pill board (STM32F103CB with 128kB of flash according to st-info --probe) via a clone ST-Link/V2 like this one. I've also tested using a genuine ST-Link/V2 like this one. I get the same result, described below, with both programmers.
My system is Linux (Debian LXDE) and I've installed OpenOCD from Liviu Ionescu's releases here.
My OpenOCD installation is working. As well as the Blue Pill I have a ST-Nucleo-F103RB board, and I can connect to it using OpenOCD. The command
openocd -f board/st_nucleo_f103rb.cfg
using the standard .cfg file that ships with OpenOCD gives
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.271135
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
But I still haven't managed to connect to my Blue Pill using the ST-Link/V2 programmers. I've read everything I can find, including relevant sections of https://elinux.org/Category:OpenOCD and as much as I can personally digest of http://openocd.org/doc/. The following is where I've got to.
The .cfg file stm32f103c8_blue_pill.cfg doesn't work for me. It produces the output described below.
Based on what I've read I've prepared my own .cfg file at ../board/stm32f103.cfg. It says:
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32f1x.cfg]
#source [find board/stm32f103c8_blue_pill.cfg]
#reset_config srst_only
#reset_config none separate
Sources I've read suggest this should work, but it doesn't. Using my .cfg described above, it I can use either target/stm32f1x.cfg or board/stm32f103c7_blue_pill.cfg, and I still get the same output as described below. (In the case of both of those .cfg files I'm using the standard files, as shipped with OpenOCD.) I've tested with both of the reset_config variants shown above, and with neither. None of the combinations works.
The file interface/stlink.cfg that I'm using is modified. I've changed it to state the correct device_desc "ST-LINK/V2" and the correct vid_pid 0x0483 0x3748. (Both confirmed using lsusb.) So, ignoring commented lines, stlink.cfg reads
interface hla
hla_layout stlink
hla_device_desc "ST-LINK/V2"
hla_vid_pid 0x0483 0x3748
I've experimented with including the hla_serial of the programmer. Interestingly, lsusb can't find the full serial number. st-info --probe finds the serial number, but gives a slightly different number from the STLinkUpgrade firmware application. I've tried using both serial numbers. No difference.
Here's the command I give to OpenOCD:
openocd -s ~/stm32/openocd/scripts -f board/stm32f103.cfg
Notice that I have to set the path using -s for this command. With the ST-Nucleo-F103RB board, I don't have to do this. With the stm32f103.cfg file, however, if I don't set the path I get:
Error: Can't find board/stm32f103.cfg
in procedure 'script'
If I use the full command shown above, with -s to set the path, I get:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
/[..]stm32/openocd/scripts/target/stm32f1x.cfg:47: Error: invalid command name "dap"
in procedure 'script'
at file "embedded:startup.tcl", line 60
at file "/[..]stm32/openocd/scripts/board/stm32f103.cfg", line 18
at file "/[..]stm32/openocd/scripts/target/stm32f1x.cfg", line 47
Here's the offending line 47 of stm32f1x.cfg:
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
I've searched for items on Stackoverflow/ similar about Error: invalid command name "dap". Using the OpenOCD documentation I understand that the dap create command exists, and roughly what it does. The most similar reported error I've found documented is at https://elinux.org/OpenOCD_Troubleshooting:_Invalid_Command_Name_JTAG, and the solution suggested there doesn't seem to be applicable because I'm not invoking interface/stlink.cfg from the command line.
I can't see what I'm doing wrong, and I'm now completely stuck. If someone can give me a steer I'd be really grateful. Sorry it's such a long post.
I just encountered this problem too. Officially there are no binaries provided, only source code. But there are two sites which release binaries was recommended by OpenOCD official:
1. Maintained by Freddie Chopin.
2. Maintained by Liviu Ionescu in Github.
I tried the latest version(OpenOCD 0.10.0 commit date: 2017-01-22 20:31:28 build date: 2017-01-23) released from Freddie Chopin's site, and I encountered this Error: invalid command name "dap" problem. But all *.cfg files I referenced had ran normally in my another computer with another OpenOCD binary(although I forgot where did I download that binary).
Not sure what went wrong, so I turned to the latest version(gnu-mcu-eclipse-openocd-0.10.0-11-20190118-1134-win64.zip) released by GNU MCU Eclipse(maintained by Liviu Ionescu), the error was gone, problem solved.
PS: I'm not saying there is a bug in Freddie Chopin's build, but if someone encountered this problem, maybe you can solve it by trying the version which is currently under actively maintained.
Agree with Wulfric, using standard install for OpenOCD
sudo apt install openocd
gave the "dap" error.
However the github version openocd-xpack worked correctly.
Using:
Linux clamps 4.15.0-66-generic #75-Ubuntu SMP ... as remote, Windows 8/10 as client target MIMXRT1010-EVK
I am trying to run a secure HTTP connection from a Verifone C680 POS terminal. Libcurl was added in Verix EOSSDK version 2.12.2.0 and i am using this resource from Verix SDK.
All code i write was compiled and linked fine. But, when i run the app in the terminal it was logged (log debug) that "libcurl.l" (without "ib" in file name extension) wasn´t in the terminal.
A little part of the log:
19 17:28:40.150 sgpi(N:/SSL2.LIB,2,1) -1:abs=0 -1:rel=0
19 17:28:40.150 sgpi(N:/LIBCURL.L.LIB,2,1) -1:abs=0 -1:rel=0
19 17:28:40.150 -- Lib N:/LIBCURL.L absent
The file libcurl.lib are loaded in terminal group 15.
That seems the command
$(VRXSDK)\bin\vrxhdr -s 256000 -h 256000
-lvoyns.lib=/voyns.lib -lGCFG.lib=/GCFG.lib -lCSUM.lib=/CSUM.lib
-lVCS.lib=/VCS.lib -lEMV.lib=/EMV.lib -lEMOD.lib=/EMOD.lib -lESCR.lib=?/ESCR.lib -lnet.lib=N:/net.lib -lelog.lib=N:/elog.lib -lceif.lib=N:/ceif.lib
-llibcurl.lib=N:/libcurl.lib -lssl2.lib=N:/ssl2.lib
-lctls.lib=N:/ctls.lib $(OutDir)\MyApp.out
was truncating the libcurl file name. Why? And how to solve this?
I recently saw this error on programs which used to work fine. I think that the error started appearing after I did a sudo apt-get upgrade, which might have upgraded the Qt libraries on my machine.
I've reproduced this error for newly created project containing this code:
QDesktopServices::openUrl(QUrl("/home/sashoalm/Has Spaces.txt"));
QDesktopServices::openUrl(QUrl::fromLocalFile("/home/sashoalm/Has Spaces.txt"));
This produces 2 message boxes saying the same - /home/sashoalm/Has%20Spaces.txt: No such file or directory. But the file exists - I've verified that, xdg-open "/home/sashoalm/Has Spaces.txt" works fine, for example.
Any workarounds? When did this bug happen? My OS is Debian Wheezy.
Edit: I checked Qt4's source code, and the relevant code is this (from qdesktopservices_x11.cpp):
return (QProcess::startDetached(client + QLatin1Char(' ') + QString::fromLatin1(url.toEncoded().constData())));
QUrl::toEncoded() returns the percent-encoded path as file:///home/sashoalm/Has%20Spaces.txt. What is strange is that there were no changes in that file save updating the copyright notices since at before 2011. So it can't be a change in Qt. But the command issued by QDesktopServices::openUrl() is xdg-open file:///home/sashoalm/Has%20Spaces.txt, and that doesn't work on my computer. Perhaps it used to work before, and an update to xdg-open itself broke it? Does anyone know if xdg-open should handle file:/// with percent encoding?
on Qt5
QDesktopServices::openUrl(QUrl::fromLocalFile("/home/sashoalm/Has Spaces.txt"));
worked just fine. I was having the same problem when loading the file purely from a QUrl like the first line
QDesktopServices::openUrl(QUrl("/home/sashoalm/Has Spaces.txt"));
but when used the QUrl::fromLocalFile it just did the thing
Either escape the space with \
QUrl("/home/sashoalm/Has\ Spaces.txt")
or add quotes to the path: -
QUrl("\"/home/sashoalm/Has Spaces\"")
I'd like to know in the code (.c file) how I can find the linux distribution name version (like ubuntu 10.0.4, or centOS 5.5...)?
The c function that I'm looking for should be like the uname() system call used in (.c files) to get kernel version.
it will be appreciated that the function is working for all linux distribution (standard)
I 'm not looking to get distribution name and version by the use of command line linux from code (.c file) (like the use of system("cat /etc/release");).
Any suggestion will be appreciated!
Regards
There is no standard for this yet. You can query following files or check for existence:
/etc/lsb-release
/etc/issue
/etc/*release
/etc/*version
Well, you can (and should) use fopen and fgets instead of system("cat"), for reading /etc/release.
There's no universal method though, I can even build a linux image which has no filesystem at all (except initramfs) and definitely no distribution name.
AFAIK there isn't a standard system call to get this if uname(2) doesn't give you enough info.
Safest approach is probably to check for "/proc/version" and read that
You could fopen("/etc/lsb-release") and parse its contents. It looks like this:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.3 LTS"
This method is not universal. You'll need to make sure that it works on all distros that you care about (if it doesn't, I suggest you go with #ott--'s answer).
Is it acceptable to run some shell commands?
$ /usr/bin/lsb_release -r
Release: 11.04
$ /usr/bin/lsb_release -d
Description: Ubuntu 11.04
$ /usr/bin/lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04
There is no portable way to do that, you'll have to use some OS detection tool/library.
Fortunately, there are a few out there. I know those 2 :
Facter, a professional (yet free/open) information gathering program in ruby : http://puppetlabs.com/puppet/related-projects/facter/
a shell script : http://www.novell.com/coolsolutions/feature/11251.html
(I used facter via puppet and it is very good.)
With a little additional scripting, you can use one of those program's output to generate a .h that you can then use in your code.
You can even integrate this generation as a step in your makefile.
I usually inspect /etc/issue; while (as others pointed out) it is not guaranteed, I've fount in the field that's quite reliable.
As far as I've experienced, it works on ubuntu, debian, redhat, centos, slackware and archlinux.