- Arch-general - lists.archlinux.org

Re: [arch-general] Acceso remoto consola (simil Teamviewer)
by Maykel Franco 07 Aug '19

07 Aug '19

El mié., 7 ago. 2019 21:47, Paynalton <cxescalona(a)gmail.com> escribió: > > Si un ave no rompe su huevo morirá antes de nacer. > Nosotros somos el ave y el mundo es nuestro huevo. > POR LA REVOLUCIÓN DEL MUNDO!!!! > > Ciudad de México > > > El mié., 7 ago. 2019 a las 14:40, Guido Ignacio (<guidoignacio(a)gmail.com>) > escribió: > >> A ver si entendí, te refieres a usar un tunel ssh, pero debo tener >> activo ese tunel desde mi servidor por lo cual voy a necesitar un >> servidor del otro lado que me sirva para hacer el tunel.... >> >> A eso vas? >> >> > No, un tunel VPN, y ya si quieres puedes usar ssh dentro del túnel vpn. > > Este manual explica como implementarlo en debian: > > https://wiki.debian.org/OpenVPN > > Para que funcione usas un servidor VPN que puedes contratar o poner como > servicio expuesto en cualquier lado. Los equipos cliente se conectan a este > y crean interfaces virtuales que funcionan como si físicamente se > encontraran dentro de la misma red, actuando el servidor como un router. > > Adicionalmente, puedes usar los equipos cliente como gateway para conectar > otras máquinas a la red VPN. > > El mié., 7 ago. 2019 a las 16:29, Paynalton (<cxescalona(a)gmail.com>) >> escribió: >> > >> > mmm, usar una vpn para poder acceder a través de un túnel a los equipos. >> > >> > >> > Si un ave no rompe su huevo morirá antes de nacer. >> > Nosotros somos el ave y el mundo es nuestro huevo. >> > POR LA REVOLUCIÓN DEL MUNDO!!!! >> > >> > Ciudad de México >> > >> > >> > El mié., 7 ago. 2019 a las 13:52, Guido Ignacio (< >> guidoignacio(a)gmail.com>) escribió: >> >> >> >> Estimados buenas tardes >> >> >> >> Les hago una consulta, tengo un servidor casero que por temas de >> >> restricción del ISP no tiene direccionamiento público por lo cual no >> >> tengo llegada desde la wan a mi lan (aun routeando y poniendo la DMZ >> >> en el router. >> >> >> >> La unica solución es usar algo similar a Teamviewer, pero necesito >> >> algo que no use las X, dado que solo tengo modo consola. >> >> >> >> Que alternativas tengo para llegar a la consola de mi servidor? >> >> >> >> GRacias! >> >> >> > Si sólo es para conectar por SSH, y no quieres abrir puertos, puedes usar ngrok. Te hace un túnel inverso muy fácil con un comando Wala.... > >>

2 1

Re: [arch-general] fenrir
by matthew dyer 05 Aug '19

05 Aug '19

Hi, Yes it should work. Jenux which is an arch system uses it by default. Matthew > On Aug 5, 2019, at 12:10 PM, adérito <aderito.carvalho(a)sapo.pt> wrote: > > Hello, does fenrir screen reader work on arch linux? > > Enviado do Correio para Windows 10 >

1 0

[arch-general] fenrir
by adérito 05 Aug '19

05 Aug '19

Hello, does fenrir screen reader work on arch linux? Enviado do Correio para Windows 10

1 0

[arch-general] Does Evolution or Claws work for other Arch Linux users?
by Ralf Mardorf 05 Aug '19

05 Aug '19

Hi, both MUAs Evolution and Claws are broken on my machine. I tried to at least work around the Evolution issue, but this was a naive miscalculation. I ensured that icu 64 is available for other apps and that ico 63 is available to build and run evolution and that the sonames are linked against icu 63 [1]. I check that icu 63 from an old package isn't broken [2]. After checking out Evolution 3.32.4 and increasing the pkgrel to 1.1 [3], I tried building evolution-data-server and got [rocketmouse@archlinux extra-x86_64]$ makepkg -s ==> Making package: evolution-data-server 3.32.4-1.1 (Fri 02 Aug 2019 04:41:43 PM CEST) [snip] [ 25%] Linking C shared library libcamel-1.2.so /usr/bin/ld: CMakeFiles/camel.dir/camel-net-utils.c.o: in function `camel_host_idna_to_ascii': camel-net-utils.c:(.text+0x15b): undefined reference to `u_strFromUTF8_64' /usr/bin/ld: camel-net-utils.c:(.text+0x1a2): undefined reference to `u_strFromUTF8_64' /usr/bin/ld: camel-net-utils.c:(.text+0x1ec): undefined reference to `uidna_IDNToASCII_64' /usr/bin/ld: camel-net-utils.c:(.text+0x289): undefined reference to `u_strToUTF8_64' /usr/bin/ld: camel-net-utils.c:(.text+0x2ca): undefined reference to `u_strToUTF8_64' collect2: error: ld returned 1 exit status make[2]: *** [src/camel/CMakeFiles/camel.dir/build.make:1941: src/camel/libcamel-1.2.so.62.0.0] Error 1 make[1]: *** [CMakeFiles/Makefile2:2958: src/camel/CMakeFiles/camel.dir/all] Error 2 make: *** [Makefile:141: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Obviously it's not that simple, as just providing 2 versions of icu ;). The reasons that I try to build Evolution 3.32.4 against icu 63 are 1. a bug that prevents to access the contacts, see https://bugs.archlinux.org/task/62317 . 2. I'm using the downgraded packages of version 3.32.0-1 against the provided icu 63 libs. This works without issues, if I write emails in (broken) English. Unfortunately sent emails containing umlauts and/or the "Eszett" show "??", instead of umlauts and/or the "Eszett", while editing the message with those "special character" works. Btw. the stored emails still contain the umlauts, just received mails are missing them. 3. Claws on Arch Linux is one of those apps that suffers from the well known "!xcb_xlib_threads_sequence_lost" issue, IOW my alternative MUA claws is completely broken, since it crashes all the times. The same version(s) build against dependencies of a very old Ubuntu 16.04 LTS release is (were) stable, using identical build options. Claws upstream know about it, see "Walter Lapchynski 2019-05-05 07:06:45 CEST I just wanted to add a note that there's a similar bug in Ubuntu that is affecting PCManFM. It seems there are several other bugs against other packages that all feature the same behavior: crashing with the "Assertion `!xcb_xlib_threads_sequence_lost' failed" error. The other thing they have in common, like Claws: GTK2. There were applications (e.g SpaceFM, LibreOffice) that also had GTK3 support and when compiled with it, worked without problem. https://bugs.launchpad.net/ubuntu/+source/pcmanfm/+bug/1782984 That said, I'm pretty sure GTK2 is to blame, but not sure how to actually solve it or where exactly to look to find the answers." - https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4203#c10 https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1808710 FWIW Evolution upstream also knows about the Evolution icu issue, see https://mail.gnome.org/archives/evolution-list/2019-August/msg00032.html . Regards, Ralf [1] [root@archlinux lib]# ls -go libicu*so lrwxrwxrwx 1 18 Aug 2 16:06 libicudata.so -> libicudata.so.63.1 lrwxrwxrwx 1 18 Aug 2 16:06 libicui18n.so -> libicui18n.so.63.1 lrwxrwxrwx 1 16 Aug 2 16:06 libicuio.so -> libicuio.so.63.1 lrwxrwxrwx 1 18 Aug 2 16:06 libicutest.so -> libicutest.so.63.1 lrwxrwxrwx 1 16 Aug 2 16:06 libicutu.so -> libicutu.so.63.1 lrwxrwxrwx 1 16 Aug 2 16:06 libicuuc.so -> libicuuc.so.63.1 [root@archlinux lib]# ls -go libicu*so*63* lrwxrwxrwx 1 18 Oct 24 2018 libicudata.so.63 -> libicudata.so.63.1 -rwxr-xr-x 1 27185816 Oct 24 2018 libicudata.so.63.1 lrwxrwxrwx 1 18 Oct 24 2018 libicui18n.so.63 -> libicui18n.so.63.1 -rwxr-xr-x 1 2996296 Oct 24 2018 libicui18n.so.63.1 lrwxrwxrwx 1 16 Oct 24 2018 libicuio.so.63 -> libicuio.so.63.1 -rwxr-xr-x 1 55064 Oct 24 2018 libicuio.so.63.1 lrwxrwxrwx 1 18 Oct 24 2018 libicutest.so.63 -> libicutest.so.63.1 -rwxr-xr-x 1 76912 Oct 24 2018 libicutest.so.63.1 lrwxrwxrwx 1 16 Oct 24 2018 libicutu.so.63 -> libicutu.so.63.1 -rwxr-xr-x 1 211488 Oct 24 2018 libicutu.so.63.1 lrwxrwxrwx 1 16 Oct 24 2018 libicuuc.so.63 -> libicuuc.so.63.1 -rwxr-xr-x 1 1890072 Oct 24 2018 libicuuc.so.63.1 [root@archlinux lib]# ls -go libicu*so*64* lrwxrwxrwx 1 18 Apr 23 18:25 libicudata.so.64 -> libicudata.so.64.2 -rwxr-xr-x 1 27538072 Apr 23 18:25 libicudata.so.64.2 lrwxrwxrwx 1 18 Apr 23 18:25 libicui18n.so.64 -> libicui18n.so.64.2 -rwxr-xr-x 1 3090496 Apr 23 18:25 libicui18n.so.64.2 lrwxrwxrwx 1 16 Apr 23 18:25 libicuio.so.64 -> libicuio.so.64.2 -rwxr-xr-x 1 55056 Apr 23 18:25 libicuio.so.64.2 lrwxrwxrwx 1 18 Apr 23 18:25 libicutest.so.64 -> libicutest.so.64.2 -rwxr-xr-x 1 76904 Apr 23 18:25 libicutest.so.64.2 lrwxrwxrwx 1 16 Apr 23 18:25 libicutu.so.64 -> libicutu.so.64.2 -rwxr-xr-x 1 211480 Apr 23 18:25 libicutu.so.64.2 lrwxrwxrwx 1 16 Apr 23 18:25 libicuuc.so.64 -> libicuuc.so.64.2 -rwxr-xr-x 1 1918752 Apr 23 18:25 libicuuc.so.64.2 [2] [root@archlinux lib]# ldd libicudata.so.63.1 statically linked [root@archlinux lib]# ldd libicui18n.so.63.1 linux-vdso.so.1 (0x00007ffd1af8e000) /usr/lib/libgtk3-nocsd.so.0 (0x00007f9950dc1000) libicuuc.so.63 => /usr/lib/libicuuc.so.63 (0x00007f9950b8e000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f99509a6000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f9950860000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f9950846000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f9950683000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f995067c000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f995065b000) libicudata.so.63 => /usr/lib/libicudata.so.63 (0x00007f994ec6d000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f99510aa000) [root@archlinux lib]# ldd libicuio.so.63.1 linux-vdso.so.1 (0x00007fffb05ff000) /usr/lib/libgtk3-nocsd.so.0 (0x00007f14dff81000) libicuuc.so.63 => /usr/lib/libicuuc.so.63 (0x00007f14dfd4e000) libicui18n.so.63 => /usr/lib/libicui18n.so.63 (0x00007f14dfa70000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f14df888000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f14df86e000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f14df6ab000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f14df6a4000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f14df683000) libicudata.so.63 => /usr/lib/libicudata.so.63 (0x00007f14ddc95000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f14ddb4f000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f14dff9b000) [root@archlinux lib]# ldd libicutest.so.63.1 linux-vdso.so.1 (0x00007ffeab79c000) /usr/lib/libgtk3-nocsd.so.0 (0x00007f307affd000) libicutu.so.63 => /usr/lib/libicutu.so.63 (0x00007f307af33000) libicuuc.so.63 => /usr/lib/libicuuc.so.63 (0x00007f307ad63000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f307ab7b000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f307ab61000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f307a99e000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f307a997000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f307a976000) libicui18n.so.63 => /usr/lib/libicui18n.so.63 (0x00007f307a698000) libicudata.so.63 => /usr/lib/libicudata.so.63 (0x00007f3078caa000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f3078b64000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f307b09c000) [root@archlinux lib]# ldd libicutu.so.63.1 linux-vdso.so.1 (0x00007ffe68ec9000) /usr/lib/libgtk3-nocsd.so.0 (0x00007f26064c0000) libicui18n.so.63 => /usr/lib/libicui18n.so.63 (0x00007f260617f000) libicuuc.so.63 => /usr/lib/libicuuc.so.63 (0x00007f2605faf000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f2605f8e000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f2605da6000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f2605d8c000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f2605bc7000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f2605bc2000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f2605a7c000) libicudata.so.63 => /usr/lib/libicudata.so.63 (0x00007f260408e000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f2606532000) [root@archlinux lib]# ldd libicuuc.so.63.1 linux-vdso.so.1 (0x00007ffe1387b000) /usr/lib/libgtk3-nocsd.so.0 (0x00007f2e8924a000) libicudata.so.63 => /usr/lib/libicudata.so.63 (0x00007f2e877f9000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f2e877d8000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f2e877d3000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f2e875eb000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f2e874a5000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f2e87489000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f2e872c6000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f2e89425000) [3] [rocketmouse@archlinux tmp]$ svn checkout --depth=empty svn://svn.archlinux.org/packages && cd packages Checked out revision 358889. [rocketmouse@archlinux packages]$ svn update evolution [snip] Updated to revision 358889. [rocketmouse@archlinux packages]$ cd evolution/repos/extra-x86_64/ [rocketmouse@archlinux extra-x86_64]$ grep -epkgver= -epkgrel= PKGBUILD pkgver=3.32.4 pkgrel=1.1 [rocketmouse@archlinux extra-x86_64]$ cd ../../.. [rocketmouse@archlinux packages]$ svn update evolution-data-server [snip] Updated to revision 358889. [rocketmouse@archlinux packages]$ cd evolution-data-server/repos/extra-x86_64/ [rocketmouse@archlinux extra-x86_64]$ grep -epkgver= -epkgrel= PKGBUILD pkgver=3.32.4 pkgrel=1.1

1 1

Re: [arch-general] talkingarch
by David Runge 05 Aug '19

05 Aug '19

On 2019-08-04 20:46:35 (+0100), adérito wrote: > I did not have jenux because I can not change the language to > Portuguese jenux. because I can't get into settings. Please stop spamming the mailing lists with these one line requests, or you will be put on moderation. You're opening a new mail thread every time ([1][2][3][4]) without any gain for anyone (including yourself). If you would like to discuss a topic, please answer to your own mail thread and the replies you got there (e.g. [2]). Also, please read the mailing lists guideline [5] (again), for best practices on mailing lists. Best, David [1] https://lists.archlinux.org/pipermail/arch-general/2019-August/046692.html [2] https://lists.archlinux.org/pipermail/arch-general/2019-August/046693.html [3] https://lists.archlinux.org/pipermail/arch-general/2019-August/046713.html [4] https://lists.archlinux.org/pipermail/arch-general/2019-August/046717.html [5] https://wiki.archlinux.org/index.php/Code_of_conduct#Mailing_lists -- https://sleepmap.de

1 0

[arch-general] talkingarch
by adérito 04 Aug '19

04 Aug '19

I did not have jenux because I can not change the language to Portuguese jenux. because I can't get into settings. Enviado do Correio para Windows 10

1 0

Re: [arch-general] talkingarch
by NTS 04 Aug '19

04 Aug '19

Dear Adérito, Have you read our many e-mails and recommendations for you? Regards NTS On Sun, 4 Aug 2019 at 14:28, adérito <aderito.carvalho(a)sapo.pt> wrote: > > Hello you can help me to install talkingarch send me the commands to install talkingarch. > > Enviado do Correio para Windows 10 >

1 0

Re: [arch-general] talkingarch
by Jelle van der Waa 04 Aug '19

04 Aug '19

On 08/04/19 at 03:28pm, adérito wrote: > Hello you can help me to install talkingarch send me the commands to install talkingarch. This is the 4th time you emailed the same message, please refrain from bumping your topic every day. -- Jelle van der Waa

1 0

[arch-general] talkingarch
by adérito 04 Aug '19

04 Aug '19

Hello you can help me to install talkingarch send me the commands to install talkingarch. Enviado do Correio para Windows 10

1 0

[arch-general] Opening a document with unicode in path
by John Z. 04 Aug '19

04 Aug '19

Hi everyone, there's a document on Dropbox, that has unicode character in its path (french character). Trying to open this document with libre office (Plasma is running) fails with 'file not found', and the path shown with error clearly presents the path with that unicode character replaced by '??' What I tried: * copy the document in a path where there's no unicode - it opens * copy the document using shell - it works * copy the document using Dolphin (from Plasma) - it works * check $LANG - its set to `en_CA.UTF8` * search for 'libreoffice unicode path', 'archlinux unicode path' and plethora of similar search terms - not much came through This makes me think the issue is actually with LibreOffice, but the reason I ask here, and not in their forum, is that on another computer running Ubuntu - this works without fail, so I'm fairly certain the issue is in some local configuration. Could anyone shed some light on this, please, or at least point me in some direction where I could look? Cheers -- "That gum you like is going to come back in style."

8 18