Re: VI problem with latest update
On Jun 8 14:48, Karl M wrote: > Hi All... > With the latest update to VI (and the latest Cygwin (1.7.20), I get the > following error starting VI. http://cygwin.com/ml/cygwin-announce/2013-05/msg7.html Note especially: * The new vim-minimal package provides /usr/bin/ex and /usr/bin/vi, is compiled with the "small" feature set, and DOES NOT DEPEND ON vim-common. So vi complains about extended vim features in ~/.vimrc. The workaround is to have a shell alias vi->vim or a matching symlink in a bin directory preceeding /usr/bin in $PATH. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: VI problem with latest update
2013/6/9 Corinna Vinschen: > So vi complains about extended vim features in ~/.vimrc. The workaround > is to have a shell alias vi->vim or a matching symlink in a bin directory > preceeding /usr/bin in $PATH. I suggested a proper solution, but there was no response yet: http://cygwin.com/ml/cygwin-apps/2013-05/msg00068.html Regards, Frank -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.19
Greetings, Corinna Vinschen! >> I do not think I explained myself properly, sorry: Cygwin would >> previously read the >> obcaseinsensitve value under Windows 2000 to emulate the case >> insensitive behaviour of Windows XP and newer where obcaseinsensitive >> was present in the registry. >> >> The registry key does not represent the active state of case >> sensitivity, so it is surely the wrong thing to query and show in >> cygcheck as it only shows what the state is pending a reboot. Surely >> it would be better now to query how the case sensitivity actually is >> here and show that, and get rid of all references to >> obcaseinsensitive, which is a configuration parameter and private >> implementation detail of kernel? > Not from my POV, no. The registry key is what the user has to change to > get case sensitive behaviour. But that setting only permit case-sensitive behavior, but not actually implement (enable) it. Actual behavior of case-sensitivity relies on actual support from filesystem, in case of disk IO operations. If I read it right, of course. > We want to know if the user actually changed it in the first place, > otherwise we can point to that info in case of a case-sensitivity related > problem. The active state may be interesting as well, but additionally to > the registry key info and, as far as I'm concerned, it's a minor problem. > But, anyway, http://cygwin.com/acronyms/#PTC -- WBR, Andrey Repin (anrdae...@freemail.ru) 09.06.2013, <15:41> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
GetSystemTimePreciseAsFileTime (was Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.19)
On Jun 5 18:28, Corinna Vinschen wrote:
> On Jun 6 01:02, Shaddy Baddah wrote:
> > On 2013-06-05 19:39+1000, Corinna Vinschen wrote:
> > >- Drop support for Windows 2000 and Windows XP pre-SP3.
> >
> > I find this change interesting. In no way am I complaining about this,
> > releases matching the above are well past end-of-life anyway.
> >
> > But I am curious about the technical reason (and perhaps discussion)
> > that ruled Win 2K out.
> > [...]
> [...]
> There's also stuff we still not use a lot, foremost the Win32 API call
> CancelSynchronousIo which, if it had been introduced in NT4 already,
> would be probably heavily used by Cygwin (think signal handling).
> The next big thing developement-wise is not Windows 7, but Windows 8 (of
> all things!), because of the new GetSystemTimePreciseAsFileTime call,
> which I'm going to introduce into Cygwin pretty soon.
Or not. I just tested the GetSystemTimePreciseAsFileTime call and it's
a wonderful performance killer.
Below I pasted my simple testcase. It computes the average number of
CPU cycles per call to compare GetSystemTimeAsFileTime and
GetSystemTimePreciseAsFileTime with each other.
I tested the call on two 64 bit Windows 8 systems, one real machine,
one QEMU/KVM based virtual machine. On real hardware I get:
On the virtual machine, the results are:
Best case:
8 cycles for GetSystemTimeAsFileTime
15557 cycles for GetSystemTimePreciseAsFileTime
Worst case under load:
20 cycles for GetSystemTimeAsFileTime
17443 cycles for GetSystemTimePreciseAsFileTime
On real hardware, the results are much better, but the difference between
GetSystemTimeAsFileTime and GetSystemTimePreciseAsFileTime are still
terrible:
Best case:
9 cycles for GetSystemTimeAsFileTime
2761 cycles for GetSystemTimePreciseAsFileTime
Worst case under load:
18 cycles for GetSystemTimeAsFileTime
5874 cycles for GetSystemTimePreciseAsFileTime
Corinna
#include
#include
#include
void (WINAPI *pGetSystemTimeAsFileTime) (LPFILETIME);
void (WINAPI *pGetSystemTimePreciseAsFileTime) (LPFILETIME);
static inline uint64_t
rdtsc(void)
{
uint32_t low, high;
__asm __volatile("rdtsc" : "=a" (low), "=d" (high));
return (low | ((uint64_t)high << 32));
}
static void
cycle (void (WINAPI *f) (LPFILETIME), const char *name)
{
const int iter = 100;
int i;
uint64_t v;
FILETIME l;
v = rdtsc ();
for (i = 0; i < iter; i++)
f (&l);
v = rdtsc () - v;
v /= iter;
printf ("%6lld cycles for %s\n", v, name);
}
int main ()
{
HMODULE h = GetModuleHandle ("kernel32.dll");
pGetSystemTimeAsFileTime = (void (WINAPI *)(LPFILETIME))
GetProcAddress (h, "GetSystemTimeAsFileTime");
pGetSystemTimePreciseAsFileTime = (void (WINAPI *)(LPFILETIME))
GetProcAddress (h, "GetSystemTimePreciseAsFileTime");
if (!pGetSystemTimePreciseAsFileTime)
{
fputs ("GetSystemTimePreciseAsFileTime unsupported\n", stderr);
return 1;
}
cycle (pGetSystemTimeAsFileTime, "GetSystemTimeAsFileTime");
cycle (pGetSystemTimePreciseAsFileTime, "GetSystemTimePreciseAsFileTime");
return 0;
}
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.19
On Jun 9 15:43, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> I do not think I explained myself properly, sorry: Cygwin would > >> previously read the > >> obcaseinsensitve value under Windows 2000 to emulate the case > >> insensitive behaviour of Windows XP and newer where obcaseinsensitive > >> was present in the registry. > >> > >> The registry key does not represent the active state of case > >> sensitivity, so it is surely the wrong thing to query and show in > >> cygcheck as it only shows what the state is pending a reboot. Surely > >> it would be better now to query how the case sensitivity actually is > >> here and show that, and get rid of all references to > >> obcaseinsensitive, which is a configuration parameter and private > >> implementation detail of kernel? > > > Not from my POV, no. The registry key is what the user has to change to > > get case sensitive behaviour. > > But that setting only permit case-sensitive behavior, but not actually > implement (enable) it. > Actual behavior of case-sensitivity relies on actual support from filesystem, > in case of disk IO operations. > If I read it right, of course. Yes. We're talking about cygcheck, not the way the Cygwin DLL handles case sensitivity. We want to know the kernel setting in cygcheck output. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ctrl-c to windows program causes mintty to hang [1.7.20 / win7]
Greetings, Jeremy Hetzler!
> All,
> Steps:
> - Open mintty
> - Run a Windows program like c:\windows\system32\ping.exe
> - While the Windows program is running, press ctrl-c
> Result:
> - Windows program exits (disappears from task manager)
Check it with ping -t
It doesn't exit.
> - mintty hangs
> mintty's state in ps then appears as O ("waiting to output to a TTY").
> It does not respond to keyboard, mouse, or kill -9. It can be closed
> via task manager.
> Sending ctrl-c to Cygwin programs does not exhibit this problem. This
> behavior is new for me under 1.7.20. I have rebooted since updating
> Cygwin to no effect. Cygcheck output attached.
> Any ideas?
It's more interesting, than that.
The events are as follows:
1. Start mintty.
It starts bash and present you with a command prompt.
[]$ ps
PIDPPIDPGID WINPID TTY UIDSTIME COMMAND
4212 14212 4212 cons0 1004 16:58:35 /usr/bin/ps
16116 1 16116 16116 ? 1004 16:58:28 /usr/bin/mintty
I8708 161168708 6208 pty01004 16:58:28 /usr/bin/bash
2. Execute "/c/WINDOWS/system32/ping.exe -t localhost"
It starts YET ANOTHER bash, not visible to ps, even in -W mode, but clearly
spotted in task manager.
Module:bash.exe
Full path: C:\Programs\CygWin\bin\bash.exe
PID: 15688
Parent PID:6208 (bash.exe)
Priority: 8
Threads: 2
3. Now, if you Ctrl+C, the console hangs.
If you let it sit down and think a bit, the iterrupt will be delivered to ping
and it get out of the lockup.
Going to grab a snapshot and see if it affect anything.
P.S.
Standard console doesn't exhibit the lockup.
--
WBR,
Andrey Repin (anrdae...@freemail.ru) 09.06.2013, <16:56>
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problems with latest version of the ocaml package
Hi, The latest version of the ocaml (4.00.1) package seems broken. It is the linking phase using the native code compiler that do not work. Example output: ocamlopt -o mlok2hll-1 str.cmxa util.cmx error.cmx id.cmx mlok.cmx parse.cmx lex.cmx hll.cmx compile.cmx main.cmx ** Cannot resolve symbols for /usr/lib/ocaml/libasmrun.a(freelist.o): ___chkstk_ms ** Cannot resolve symbols for /usr/lib/ocaml/libasmrun.a(md5.o): ___chkstk_ms ** Cannot resolve symbols for /usr/lib/ocaml/libasmrun.a(sys.o): ___chkstk_ms File "caml_startup", line 1: Error: Error during linking There is nothing special with the inputs above, I get the same error on all of my ocaml projects. Per -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Python core dump depending on module import order with latest upgrade
Since the latest upgrade the following python program causes an "Aborted (core dumped)" error: #!/usr/bin/python import ctypes import zlib a = 1 If the order of imports is reversed (zlib then ctypes) no core dump error occurs. python2.7.exe.stackdump contains nothing of use: Stack trace: Frame Function Args Versions are: uname -srm CYGWIN_NT-6.2 1.7.20(0.266/5/3) i686 python Python 2.7.3 (default, Dec 18 2012, 13:50:09) [GCC 4.5.3] on cygwin ctypes __version__ = '1.1.0' zlib __version__ = '1.0' ZLIB_VERSION = '1.2.7' The dates on the latest cygwin dll files (cygwin1.dll) etc. in /usr/bin are Jun 7 10:11 O/S is Windows v8.0 Setup.exe version is 2.774 Neither ctypes nor zlib is in the site-packages directory so I don't see any user module recompilation being available. I do have sip installed in site-packages but this is not used by the failing program. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
incident during setup on newly built system
[[file fragment: /var/log/setup.log.full]] Found ini file - E:\mlo/setup.ini INVALID PACKAGE: file://E:\mlo/release/inetutils/inetutils-1.7-2.tar.bz2 - Size mismatch: Ini-file: 385658 != On-disk: 385652 INVALID PACKAGE: file://E:\mlo/release/inetutils/inetutils-1.7-2-src.tar.bz2 - Size mismatch: Ini-file: 2221406 != On-disk: 2221312 [[file fragment: /xpe/mlo/setup.ini]] @ inetutils sdesc: "Common networking clients and servers" ldesc: "inetutils provides common networking clients and servers, including the inetd super-server, telnetd and telnet, ftpd and ftp, talkd and talk, uucpd (but no uucp client), and syslogd." category: Net requires: crypt libgcc1 libncursesw10 libreadline7 libwrap0 csih terminfo _update-info-dir version: 1.7-2 install: release/inetutils/inetutils-1.7-2.tar.bz2 385658 7ef375a677c8c4683ffa0e212fb58984 source: release/inetutils/inetutils-1.7-2-src.tar.bz2 2221406 41a7ba247c92705b1fb2dea66bfb9050 [[bash: /xpe/mlo/]] lom@gorin /xpe/mlo $ ll total 3130 -rw-r--r--+ 1 lom None 72 2013.06.08 10:00 setup.bz2.sig -rw-r--r--+ 1 lom None 72 2013.06.08 10:00 setup.ini.sig -rw-r--r--+ 1 lom None 390546 2013.06.08 02:00 setup.bz2 -rw-r--r--+ 1 lom None 2092204 2013.06.08 02:00 setup.ini drwxr-xr-x+ 1 lom None 0 2013.06.07 01:54 release -rwxr-xr-x+ 1 lom None 705053 2013.04.07 18:05 setup.exe [[bash: /xpe/mlo/release/inetutils]] lom@gorin /xpe/mlo/release/inetutils $ ll total 5126 -rw-r--r--+ 1 lom None 645 2010.10.12 18:34 md5.sum -rw-r--r--+ 1 lom None 351 2010.10.12 18:33 setup.hint -rw-r--r--+ 1 lom None 385652 2010.10.11 06:27 inetutils-1.7-2.tar.bz2 -rw-r--r--+ 1 lom None 2221312 2010.10.11 06:27 inetutils-1.7-2-src.tar.bz2 -rw-r--r--+ 1 lom None 408484 2010.03.29 01:06 inetutils-1.7-1.tar.bz2 -rw-r--r--+ 1 lom None 264 2010.03.29 01:06 inetutils-1.7-1-src.tar.bz2 lom@gorin /xpe/mlo/release/inetutils $ md5sum inetutils-1.7-2.tar.bz2 21fe74de7a4ff673530da4670b134491 *inetutils-1.7-2.tar.bz2 lom@gorin /xpe/mlo/release/inetutils $ md5sum inetutils-1.7-2-src.tar.bz2 c37b77ec80404ef0417d5115346e00bd *inetutils-1.7-2-src.tar.bz2 lom@gorin /xpe/mlo/release/inetutils $ cat md5.sum d0029be8c1c71191d66b7b7e620a6a0a inetutils-1.5-3-src.tar.bz2 8030f856bd2ee75ab49e98527008a804 inetutils-1.5-3.tar.bz2 178f589077430a90c068040284b181ca inetutils-1.5-4-src.tar.bz2 e7888eecf5e8781619d85a2e6bc42bfd inetutils-1.5-4.tar.bz2 227f17fdc6e12ddb0f542e515fbdf58f inetutils-1.5-6-src.tar.bz2 c4d89805a602f11c130ed5d6064aa4ac inetutils-1.5-6.tar.bz2 63109de1d6d42bc4ea121369633eea11 inetutils-1.7-1-src.tar.bz2 9f25bb234afcde0ee293c3e3c7bac1c2 inetutils-1.7-1.tar.bz2 c37b77ec80404ef0417d5115346e00bd inetutils-1.7-2-src.tar.bz2 21fe74de7a4ff673530da4670b134491 inetutils-1.7-2.tar.bz2 a769d1008f75a8d9d90bf7a131c37f2c setup.hint -- http://www.fastmail.fm - A no graphics, no pop-ups email service -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Regression with 1.7.20-1
Since upgrading to the package "cygwin 1.7.20-1" a command such as this no longer works ffmpeg -codecs | grep mov http://ffmpeg.zeranoe.com/builds Two workarounds I have found 1. run command like this timeout 1 ffmpeg -codecs | grep mov 2. Downgrade to package "cygwin 1.7.18-1" -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Do the runtime support the large file 2GB with fstati64 (error: undefined reference to __fstati64 )?
Folks,
I did some research at mailing list, faq and I didn't seek any
information about this error . I am trying to build an installer of
some great tools of linux to windows, but I wanna use and Cygwin
runtime and Mingw(please don't redirect to another list). I am going
to explain what I did:
$ grep fstati64 /c/bin/*.dll
Binary file /c/bin/hdf5dll.dll matches
Binary file /c/bin/libcurl.dll matches
Binary file /c/bin/msvcr71.dll matches
Binary file /c/bin/msvcrt.dll matches
I can see an importation in mingw :
$ nm -g /usr/lib/gcc/i686-pc-mingw32/3.4.4/debug/libstdc++.a |grep fstati64
U __fstati64
or
$ find /usr/lib -name "*.a" -exec grep fstati64 {} \;
Binary file /usr/lib/gcc/i686-pc-mingw32/3.4.4/debug/libstdc++.a matches
Binary file /usr/lib/gcc/i686-pc-mingw32/3.4.4/libstdc++.a matches
In particular, I would have expected it to be exported by one or more
of the /usr/lib/w32api/libmsvc*.a files. In this directory are:
$ nm -o /usr/lib/w32api/libmsvcrt.a | grep fstati*
/usr/lib/w32api/libmsvcrt.a:daqgds00255.o: T __fstat64
/usr/lib/w32api/libmsvcrt.a:daqgds00255.o: I __imp___fstat64
/usr/lib/w32api/libmsvcrt.a:daqgds00254.o: T __fstat
/usr/lib/w32api/libmsvcrt.a:daqgds00254.o: I __imp___fstat
I have seen fstat64 which does something similar but is not linkage
(and possibly not functionality) compatible. I decided to download a
mingw in my laptop and I found:
grep -rl fstati64 /usr/i586-mingw32msvc/lib/libmsvc*
/usr/i586-mingw32msvc/lib/libmsvcr70.a
/usr/i586-mingw32msvc/lib/libmsvcr70d.a
/usr/i586-mingw32msvc/lib/libmsvcr71.a
/usr/i586-mingw32msvc/lib/libmsvcr71d.a
/usr/i586-mingw32msvc/lib/libmsvcr80.a
/usr/i586-mingw32msvc/lib/libmsvcr80d.a
/usr/i586-mingw32msvc/lib/libmsvcrt.a
/usr/i586-mingw32msvc/lib/libmsvcrtd.a
I am not suere bu I think there are some coincidences of fstati64 with
the current version of mingw.
My Makefile is at http://pastebin.com/EQGuXsEx and the output of make
is too long sorry for this:
$ make
make all-recursive
make[1]: Entering directory `/cygdrive/c/build/setup'
Making all in libgetopt++
make[2]: Entering directory `/cygdrive/c/build/setup/libgetopt++'
make[2]: Leaving directory `/cygdrive/c/build/setup/libgetopt++'
Making all in tests
make[2]: Entering directory `/cygdrive/c/build/setup/tests'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/cygdrive/c/build/setup/tests'
make[2]: Entering directory `/cygdrive/c/build/setup'
/bin/sh ./libtool --tag=CXX--mode=link g++ -mno-cygwin -Werror
-Wall -Wno-uninitialized -Wpointer-arith -Wcomments -Wcast-align
-Wwrite-strings -g -O2 -mwindows -L/usr/lib/w32api -o setup.exe
AntiVirus.o archive.o archive_tar.o archive_tar_file.o autoload.o
choose.o compress.o compress_bz.o compress_gz.o ConnectionSetting.o
ControlAdjuster.o cygpackage.o desktop.o express_package.o dialog.o
diskfull.o download.o Exception.o find.o FindVisitor.o filemanip.o
fromcwd.o geturl.o ini.o IniDBBuilderPackage.o iniparse.o
IniParseFeedback.o IniParseFindVisitor.o install.o io_stream.o
io_stream_cygfile.o io_stream_file.o io_stream_memory.o localdir.o
LogFile.o LogSingleton.o main.o mkdir.o mklink2.o mount.o msg.o
net.o netio.o nio-ie5.o nio-file.o nio-ftp.o nio-http.o package_db.o
package_meta.o package_source.o package_version.o
PackageSpecification.o PickCategoryLine.o PickPackageLine.o
PickView.o postinstall.o prereq.o proppage.o propsheet.o res.o
root.o ScanFindVisitor.o script.o setup_version.o simpsock.o site.o
source.o SourceSetting.o splash.o state.o String++.o threebar.o
UserSetting.o UserSettings.o win32.o window.o csu_util/MD5Sum.o
csu_util/rfc1738.o csu_util/version_compare.o libmd5-rfc/md5.o
libinilex.a libgetopt++/libgetopt++.la res.o -lbz2 -lz -lcomctl32
-lole32 -lwsock32 -lnetapi32 -luuid -lws2_32 -lstdc++ -lmingw32
-lws2_32
libtool: link: g++ -mno-cygwin -Werror -Wall -Wno-uninitialized
-Wpointer-arith -Wcomments -Wcast-align -Wwrite-strings -g -O2
-mwindows -o setup.exe AntiVirus.o archive.o archive_tar.o
archive_tar_file.o autoload.o choose.o compress.o compress_bz.o
compress_gz.o ConnectionSetting.o ControlAdjuster.o cygpackage.o
desktop.o express_package.o dialog.o diskfull.o download.o Exception.o
find.o FindVisitor.o filemanip.o fromcwd.o geturl.o ini.o
IniDBBuilderPackage.o iniparse.o IniParseFeedback.o
IniParseFindVisitor.o install.o io_stream.o io_stream_cygfile.o
io_stream_file.o io_stream_memory.o localdir.o LogFile.o
LogSingleton.o main.o mkdir.o mklink2.o mount.o msg.o net.o netio.o
nio-ie5.o nio-file.o nio-ftp.o nio-http.o package_db.o package_meta.o
package_source.o package_version.o PackageSpecification.o
PickCategoryLine.o PickPackageLine.o PickView.o postinstall.o prereq.o
proppage.o propsheet.o res.o root.o ScanFindVisitor.o script.o
setup_version.o simpsock.o site.o source.o SourceSetting.o splash.o
state.o String++.o threebar.o UserSetting.o UserSettings.o win32.o
window.o csu_util/MD5Sum.o csu_util/rfc1738.o
csu_util/vers
SQLite temporary path creation broken in latest stable release
The mandatory locking work (which I haven't been able to test) aside, temporary table creation is broken with SQLite 3.7.16.2-1. 'CREATE TEMP TABLE foo (bar INT)' fails. cygwinGetTempname, called from getTempname, returns the correct temporary directory --- "/var/tmp/etilqs_z28HceqmzVr3ZO1" in my case -- but getTempname then appends another random string to this name, yielding "/var/tmp/etilqs_z28HceqmzVr3ZO1\\etilqs_rnPCuceSOgjfeTd". We then give this string directly to CreateFileW, which understandably fails to create the indicated file. signature.asc Description: OpenPGP digital signature
