- Arch-general - lists.archlinux.org

[arch-general] gpg - actions on keyserver fail
by Friedrich Strohmaier 02 Mar '19

02 Mar '19

Hi all, I've setup a new arch install on a VM where almost everything runs as expected. Only gpg talking to key servers fails. Trying a key search results in: ~]$ gpg --keyserver hkp://pool.sks-keyservers.net --search-keys Alltag gpg: error searching keyserver: Server indicated a failure gpg: keyserver search failed: Server indicated a failure pacman-key --refresh-keys shows similar error. ~]$ gpg --version gpg (GnuPG) 2.2.13 libgcrypt 1.8.4 .. I made sure - pool.sks-keyservers.net is resolved - pool.sks-keyservers.net answers at port 11371 and 80 - gpg succeds key server interaction (--search-keys) from a neighbour VM (centOS gpg (GnuPG) 2.0.22, libgcrypt 1.5.3) - gpg succeds key server interaction (--search-keys) from the host (debian, gpg (GnuPG) 1.4.18) - gpg succeds key server interaction (--search-keys) from my home box,(archlinux gpg (GnuPG) 2.2.13, libgcrypt 1.8.4) any further ideas how to nail down this? -- Friedrich

1 0

Re: [arch-general] pacman.log has no timezone information in timestamp
by Juha Kankare 02 Mar '19

02 Mar '19

On 02/03/2019 02:23, ProgAndy wrote: > Am 02.03.19 um 01:12 schrieb mpan: >>> I just used the /var/log/pacman.log for the first time to give me the >>> last date-time I did a system upgrade ('starting full system upgrade' in >>> the log). There is no time-zone info in the time-stamp. It's also not >>> UTC. Does anyone know if this is by design or a bug? >> `pacman` uses local time of your system. Indeed it seems like an >> ommision. >> >> You may consider opening a feature request, so pacman.conf would allow >> either an option to include TZ in the logs (good idea) or setting custom >> time format (worse idea, as this would bind `pacman` codebase to the >> specific time formatting function). >> > > Meanwhile you can explicitly set the timezone to UTC when calling > pacman, that way the log will be consistent: > > $ TZ=UTC sudo pacman ... > > -- > ProgAndy For some reason, ' $ TZ=UTC sudo pacman' and '$ sudo TZ=UTC pacman' both work, but '$ alias pacman="TZ=UTC pacman"' and then '$ sudo pacman' doesn't, even though (from what I know) it should be practically equal to '$ sudo TZ=UTC pacman'. Not sure why, but it was worth a shot. Any other way to automate this TZ=UTC for pacman so you don't have to type it every time. Maybe a wrapper script aliased to "upacman" or something? -- Regards, Juha Kankare

3 2

[arch-general] HTTP spam from China
by Juha Kankare 28 Feb '19

28 Feb '19

I'm getting a lot of connections from China it seems. Whenever I check my journalctl, it's an andless wall of nginx complaints about a single ip spamming requests fro different php files. This happens with hundreds of ip's, and tens of times daily. Has anyone else been hit by this. I already made a shellscript to block all connections from China, but I'm curious as to why this happens, and if anyone else has had the same problem.

13 25

[arch-general] /var/run vs /run in systemd unit files
by Genes Lists 28 Feb '19

28 Feb '19

I've noticed warnings from systemd about changing systemd files to reference /run instead of /var/run. I'm not sure if this is upstream or arch or both? I see it for things like: rpc-statd (from nfs-utils) dovecot saslauthd chronyd There may well be more. gene

2 2

[arch-general] HDMI audio input - HDMI microphone
by Neven Sajko 27 Feb '19

27 Feb '19

Hi, I am designing a digital microphone that should send PCM (LPCM) data to a PC, and I am new to electronics. My first thought for the connection type to interface with the PC was of course USB, but then I figured that HDMI is an alternative more suited to digital audio data, and maybe simpler to work with. But how to get at audio data through HDMI on a Linux system, if it is even possible? I do not mind writing a kernel module if it would not be too complicated. My CPU is i5-8300H with Intel® UHD Graphics 630. Regards, Nsajko

3 10

[arch-general] Crashes in FF 65.0.1
by Peter Nabbefeld 27 Feb '19

27 Feb '19

Hello, my Firefox windows randomly crash - is it because of Xorg, Xfce or Firefox? Does somebody else have noticed this behaviour? When I don't do anything at my laptop (and it seems to happen only if I don't do anything at it), after a while when I want to do sth. in the browser again, it doesn't work properly any more. It seems, as if the JavaScript engine would have crashed for the tab or window: As soon as I enter sth., the GUI is corrupted, i.e. layers are shown at the wrong place in an order I cannot do any editing any more etc. If I try to close the tab, the GUI stays unchanged or just the layers of the closed tab are somehow changed, but it seems as if the tab were still active. Re-opening the tab from history results in a blank window (though the correct is shown in the address bar). As I said, it seems to be because of the JavaScript engine, but I'm not sure, yet. Another issue I have is about atlassian: When I open a link, usually a login page is shown. Instead, FF crashes completely. Any idea? Kind regards Peter

4 5

[arch-general] What update left mandb scrambled?
by David C. Rankin 26 Feb '19

26 Feb '19

This was odd, $ apropos memcmp memcmp: nothing appropriate. In fact, no man pages were available (checked 2 arch installs). I ended up having to rebuild the database with 'mandb' and now all is well. My question is -- what did this? It must have occurred in the last couple of days. -- David C. Rankin, J.D.,P.E.

5 7

[arch-general] Libreoffice fresh not starting
by Friedrich Strohmaier 24 Feb '19

24 Feb '19

Hi community, Since Libreoffice 6.2.0 libreoffice-fresh refuses to start. No Problems with libreoffice-still. As I could not find other reports I assume this beeing a local problem. Message: Fatal exception: Signal 11 Stack: /usr/lib/libreoffice/program/libuno_sal.so.3(+0x3b804)[0x7f4125a5b804] /usr/lib/libreoffice/program/libuno_sal.so.3(+0x3ba25)[0x7f4125a5ba25] /usr/lib/libc.so.6(+0x37e00)[0x7f412578ae00] /usr/lib/libreoffice/program/libuno_cppu.so.3(+0x141e6)[0x7f4124ec41e6] /usr/lib/libreoffice/program/libuno_cppu.so.3(uno_type_any_assign+0x98)[0x7f4124ec3838] /usr/lib/libreoffice/program/libutllo.so(+0x6a9c1)[0x7f41228049c1] /usr/lib/libreoffice/program/libutllo.so(+0x6b735)[0x7f4122805735] /usr/lib/libreoffice/program/libutllo.so(_ZN3utl10ConfigItemC2ERKN3rtl8OUStringE14ConfigItemMode+0x7e)[0x7f41227f5c6e] /usr/lib/libreoffice/program/libutllo.so(+0xc640a)[0x7f412286040a] /usr/lib/libreoffice/program/libutllo.so(_ZN19SvtSysLocaleOptionsC1Ev+0x128)[0x7f41228619f8] /usr/lib/libreoffice/program/libvcllo.so(_Z7InitVCLv+0x1a8)[0x7f4122483b68] /usr/lib/libreoffice/program/libvcllo.so(_Z10ImplSVMainv+0x126)[0x7f4122485266] /usr/lib/libreoffice/program/libsofficeapp.so(soffice_main+0x99)[0x7f41259b63a9] /usr/lib/libreoffice/program/soffice.bin(+0x102d)[0x55fd4308a02d] /usr/lib/libc.so.6(__libc_start_main+0xf3)[0x7f4125777223] /usr/lib/libreoffice/program/soffice.bin(+0x106e)[0x55fd4308a06e] Bugreport: https://bugs.archlinux.org/task/61701?project=1&string=libreoffice-fresh Any ideas on this? -- Friedrich

5 7

[arch-general] pambase update now requires explicit service files in /etc/pam.d/ - dovecot affected
by David C. Rankin 24 Feb '19

24 Feb '19

All, With the latest change to pambase, e.g. https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pam… if you have services that rely on pam authentication, such as dovecot, etc.., you will find that your applications an no longer authenticate using pam until you install a specific pam service in /etc/pam.d for that application, e.g. https://wiki.archlinux.org/index.php/Dovecot#PAM_Authentication I recall seeing something about this change coming earlier, but this was the first update where something stopped working as a result. So add whatever additional files you require to /etc/pam.d/ Thankfully the journal messages are good in pointing out the problem. -- David C. Rankin, J.D.,P.E.

10 11

[arch-general] pambase in testing breaks email
by Genes Lists 24 Feb '19

24 Feb '19

pambase 20190105.1-1 caused bad failure for email. The error I saw immediately was from postfix failing to authenticate users via saslauthd which in turn blames pam. Downgrading back to 20171006-1 restores email funtioning ok. Logs say: saslauthd[22214]: pam_warn(smtp:auth): function=[pam_sm_authenticate] flags=0x8000 service=[smtp] terminal=[<unknown>] user=[lists] ruser=[<unknown>] rhost=[<unknown>] saslauthd[22214]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure saslauthd[22214]: do_auth : auth failure: [user=lists] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

2 4