- Arch-general - lists.archlinux.org

[arch-general] Xterm and .Xresources
by Storm Dragon 11 Aug '19

11 Aug '19

Howdy, I am trying to get Xterm to work in practically the same way as the console, just with a bit better font support. I have searched the net and created an extensive .Xresources file, which is attached to this message. It is supposed to fix all the function keys, the six pack, and even the numpad keys. the problem is, the keyboard fix part, doesn't work. I found that if I export TERM=vt220 that most keys do work, but home and end in applications like nano and ne do not work still and cause weird behavior. I was wondering if exporting TERM should even be necessary, because in the console, I never have to do that, and it shows as "linux". Can someone please take a look and help fix up this .Xresources, and also, do I really need to export TERM, or can I ditch that setting? Thanks for the help, Storm --

2 3

[arch-general] samba domain member - check for unix auth first
by Łukasz Michalski 10 Aug '19

10 Aug '19

Hi, I am running samba AD DC as virtual machine from host, which is a samba domain member. I enabled PAM auth using wiki article[1]. My problem is that when host is starting I am unable to login (even as root) to it until DC vm starts and winbindd reestablishes connection to DC. I want to change auth priority: check for unix user first, and if not found check in AD. I tried to change /etc/pam.d/system-auth this way: [DO NOT use - it does not work] auth [default=ignore] pam_localuser.so auth [success=1 default=die] pam_unix.so nullok auth [default=die] pam_winbind.so auth requisite pam_deny.so auth optional pam_permit.so auth required pam_env.so account required pam_unix.so account [success=1 default=ignore] pam_localuser.so account required pam_winbind.so account optional pam_permit.so account required pam_time.so password [default=ignore] pam_localuser.so password [success=1 default=die] pam_unix.so sha512 shadow password [default=die] pam_winbind.so password requisite pam_deny.so password optional pam_permit.so session required pam_limits.so session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 session optional pam_permit.so but it does not work. Anyone has a working example? Thanks, Łukasz

1 0

[arch-general] Fractional HiDPI
by Yurii Kolesnykov 08 Aug '19

08 Aug '19

Hello archers, I’m looking to buy "24 4K monitor, the resolution is seems to be as twice as FullHD, but I don’t wan’t to use it as 2x, since I have bad eyes and do scaling of fonts across all desktops on my current "24 FullHD monitor anyway. But I didn’t tried a factorial DPI yet on the old one, since it definitely will look blurry. So I want to get some suggestions from community. Does Factorial screen DPI works good now across KDE and GNOME? On Arch Wiki I found only information on factorial DPI in GNOME. I know that macOS supports it well since last fall. Had anyone tried a factorial whole screen DPI? Or it will be better to stay as I’m now, just set 2x DPI for whole screen, and manually adjust font in every desktop/app/os?

3 2

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