January 2020 - Arch-general - lists.archlinux.org

[arch-general] pacman error when installing
by Maykel Franco 22 Jan '20

22 Jan '20

Before, with -f options or --force, it resolved it. And now, invalid option. error: failed to commit transaction (conflicting files) libmad: /usr/include/mad.h exists in filesystem libmad: /usr/lib/libmad.so exists in filesystem libmad: /usr/lib/libmad.so.0 exists in filesystem libmad: /usr/lib/libmad.so.0.2.1 exists in filesystem libmad: /usr/lib/pkgconfig/mad.pc exists in filesystem gperftools: /usr/bin/pprof exists in filesystem gperftools: /usr/include/google/heap-checker.h exists in filesystem gperftools: /usr/include/google/heap-profiler.h exists in filesystem gperftools: /usr/include/google/malloc_extension.h exists in filesystem gperftools: /usr/include/google/malloc_extension_c.h exists in filesystem gperftools: /usr/include/google/malloc_hook.h exists in filesystem gperftools: /usr/include/google/malloc_hook_c.h exists in filesystem gperftools: /usr/include/google/profiler.h exists in filesystem gperftools: /usr/include/google/stacktrace.h exists in filesystem gperftools: /usr/include/google/tcmalloc.h exists in filesystem gperftools: /usr/include/gperftools/heap-checker.h exists in filesystem gperftools: /usr/include/gperftools/heap-profiler.h exists in filesystem gperftools: /usr/include/gperftools/malloc_extension.h exists in filesystem gperftools: /usr/include/gperftools/malloc_extension_c.h exists in filesystem gperftools: /usr/include/gperftools/malloc_hook.h exists in filesystem gperftools: /usr/include/gperftools/malloc_hook_c.h exists in filesystem gperftools: /usr/include/gperftools/nallocx.h exists in filesystem gperftools: /usr/include/gperftools/profiler.h exists in filesystem gperftools: /usr/include/gperftools/stacktrace.h exists in filesystem gperftools: /usr/include/gperftools/tcmalloc.h exists in filesystem gperftools: /usr/lib/libprofiler.so exists in filesystem gperftools: /usr/lib/libprofiler.so.0 exists in filesystem gperftools: /usr/lib/libprofiler.so.0.4.18 exists in filesystem gperftools: /usr/lib/libtcmalloc.so exists in filesystem gperftools: /usr/lib/libtcmalloc.so.4 exists in filesystem gperftools: /usr/lib/libtcmalloc.so.4.5.3 exists in filesystem gperftools: /usr/lib/libtcmalloc_and_profiler.so exists in filesystem gperftools: /usr/lib/libtcmalloc_and_profiler.so.4 exists in filesystem gperftools: /usr/lib/libtcmalloc_and_profiler.so.4.5.3 exists in filesystem gperftools: /usr/lib/libtcmalloc_debug.so exists in filesystem gperftools: /usr/lib/libtcmalloc_debug.so.4 exists in filesystem gperftools: /usr/lib/libtcmalloc_debug.so.4.5.3 exists in filesystem gperftools: /usr/lib/libtcmalloc_minimal.so exists in filesystem gperftools: /usr/lib/libtcmalloc_minimal.so.4 exists in filesystem gperftools: /usr/lib/libtcmalloc_minimal.so.4.5.3 exists in filesystem gperftools: /usr/lib/libtcmalloc_minimal_debug.so exists in filesystem gperftools: /usr/lib/libtcmalloc_minimal_debug.so.4 exists in filesystem gperftools: /usr/lib/libtcmalloc_minimal_debug.so.4.5.3 exists in filesystem gperftools: /usr/lib/pkgconfig/libprofiler.pc exists in filesystem gperftools: /usr/lib/pkgconfig/libtcmalloc.pc exists in filesystem gperftools: /usr/lib/pkgconfig/libtcmalloc_debug.pc exists in filesystem gperftools: /usr/lib/pkgconfig/libtcmalloc_minimal.pc exists in filesystem gperftools: /usr/lib/pkgconfig/libtcmalloc_minimal_debug.pc exists in filesystem gperftools: /usr/share/doc/gperftools/AUTHORS exists in filesystem gperftools: /usr/share/doc/gperftools/COPYING exists in filesystem gperftools: /usr/share/doc/gperftools/ChangeLog exists in filesystem gperftools: /usr/share/doc/gperftools/ChangeLog.old exists in filesystem gperftools: /usr/share/doc/gperftools/INSTALL exists in filesystem gperftools: /usr/share/doc/gperftools/NEWS exists in filesystem gperftools: /usr/share/doc/gperftools/README exists in filesystem gperftools: /usr/share/doc/gperftools/README_windows.txt exists in filesystem gperftools: /usr/share/doc/gperftools/TODO exists in filesystem gperftools: /usr/share/doc/gperftools/cpuprofile-fileformat.html exists in filesystem gperftools: /usr/share/doc/gperftools/cpuprofile.html exists in filesystem gperftools: /usr/share/doc/gperftools/designstyle.css exists in filesystem gperftools: /usr/share/doc/gperftools/heap-example1.png exists in filesystem gperftools: /usr/share/doc/gperftools/heap_checker.html exists in filesystem gperftools: /usr/share/doc/gperftools/heapprofile.html exists in filesystem gperftools: /usr/share/doc/gperftools/index.html exists in filesystem gperftools: /usr/share/doc/gperftools/overview.dot exists in filesystem gperftools: /usr/share/doc/gperftools/overview.gif exists in filesystem gperftools: /usr/share/doc/gperftools/pageheap.dot exists in filesystem gperftools: /usr/share/doc/gperftools/pageheap.gif exists in filesystem gperftools: /usr/share/doc/gperftools/pprof-test-big.gif exists in filesystem gperftools: /usr/share/doc/gperftools/pprof-test.gif exists in filesystem gperftools: /usr/share/doc/gperftools/pprof-vsnprintf-big.gif exists in filesystem gperftools: /usr/share/doc/gperftools/pprof-vsnprintf.gif exists in filesystem gperftools: /usr/share/doc/gperftools/pprof_remote_servers.html exists in filesystem gperftools: /usr/share/doc/gperftools/spanmap.dot exists in filesystem gperftools: /usr/share/doc/gperftools/spanmap.gif exists in filesystem gperftools: /usr/share/doc/gperftools/t-test1.times.txt exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.1024.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.128.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.131072.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.16384.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.2048.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.256.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.32768.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.4096.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.512.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.64.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.65536.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspercpusec.vs.threads.8192.bytes.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.1.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.12.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.16.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.2.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.20.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.3.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.4.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.5.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc-opspersec.vs.size.8.threads.png exists in filesystem gperftools: /usr/share/doc/gperftools/tcmalloc.html exists in filesystem gperftools: /usr/share/doc/gperftools/threadheap.dot exists in filesystem gperftools: /usr/share/doc/gperftools/threadheap.gif exists in filesystem gperftools: /usr/share/licenses/gperftools/COPYING exists in filesystem gperftools: /usr/share/man/man1/pprof.1.gz exists in filesystem qtkeychain: /usr/include/qt5keychain/keychain.h exists in filesystem qtkeychain: /usr/include/qt5keychain/qkeychain_export.h exists in filesystem qtkeychain: /usr/lib/cmake/Qt5Keychain/Qt5KeychainConfig.cmake exists in filesystem qtkeychain: /usr/lib/cmake/Qt5Keychain/Qt5KeychainConfigVersion.cmake exists in filesystem qtkeychain: /usr/lib/cmake/Qt5Keychain/Qt5KeychainLibraryDepends-noconfig.cmake exists in filesystem qtkeychain: /usr/lib/cmake/Qt5Keychain/Qt5KeychainLibraryDepends.cmake exists in filesystem qtkeychain: /usr/lib/libqt5keychain.so exists in filesystem qtkeychain: /usr/lib/libqt5keychain.so.1 exists in filesystem qtkeychain: /usr/lib/qt/mkspecs/modules/qt_Qt5Keychain.pri exists in filesystem qtkeychain: /usr/share/licenses/qtkeychain/LICENSE exists in filesystem qtkeychain: /usr/share/qt/translations/qtkeychain_de.qm exists in filesystem qtkeychain: /usr/share/qt/translations/qtkeychain_ro.qm exists in filesystem Errors occurred, no packages were upgraded If delete these files, works well but... is not productive Any ideas?

2 2

[arch-general] Getting 404 errors while trying to install arch on a fresh system. Any rreason why?
by ilovecountrymusic483＠gmail.com 21 Jan '20

21 Jan '20

Hi all, Using the tarch iso from www.tarch.info <http://www.tarch.info> , I am unable to install to a fresh system. During the download of packages, I get unable to retreave packages the requested URL returned error code 404. I eventually I am given the message "Envalide or corrupted package." Any ideas on why this is happens? I tried the latest tarch image from October, but the image gives me no internet connection. My internection is fine. I have updated the gpg keys, but the same thing hppens. I am guessing that I am getting partial downloads of some packages. Any one seeing this with the standered arch iso? I am a blind user of linux so can not use the standard iso to test. If anyone has any ideas it would be greatly appreaseated. I did some searching but came up empty. Thanks. Matthew

5 7

[arch-general] [mkinitpcio] running as non-root creates non-root files in the cpio
by Damjan Georgievski 20 Jan '20

20 Jan '20

I've already opened a bug issue, and supplied a patch at https://bugs.archlinux.org/task/65006 but except from the first comment by dreisner, there's not much activity. Is it ok if I escalate here? :) Alternatively, is there a better place for reporting mkinitpcio issues, and sending patches? -- damjan

2 2

Re: [arch-general] do i need to configure mkinitcpio.conf for my md array ?
by Shadrock Uhuru 20 Jan '20

20 Jan '20

thanks for the clarification. shadrock

1 0

[arch-general] Mouse freezes
by siefke_listen＠web.de 20 Jan '20

20 Jan '20

Hello, since yesterday I become mouse freezes for short moments, I must often klick or move then it work. Everytime is so, it looks at the mouse slept when not need. Is there something in update since yesterday what make this trouble? [2020-01-18T07:53:39+0100] [PACMAN] starting full system upgrade [2020-01-18T07:53:55+0100] [ALPM] upgraded linux (5.4.11.arch1-1 -> 5.4.12.arch1-1) [2020-01-18T07:53:55+0100] [ALPM] upgraded acpi_call (1.1.0-275 -> 1.1.0-276) [2020-01-18T07:53:55+0100] [ALPM] upgraded snappy (1.1.7-1 -> 1.1.8-1) [2020-01-18T07:53:56+0100] [ALPM] upgraded chromium (79.0.3945.117-1 -> 79.0.3945.130-2) [2020-01-18T07:53:56+0100] [ALPM] upgraded imagescan (3.61.0-2 -> 3.62.0-1) [2020-01-18T07:53:56+0100] [ALPM] upgraded inkscape (0.92.4-10 -> 0.92.4-11) [2020-01-18T07:53:56+0100] [ALPM] upgraded libde265 (1.0.4-1 -> 1.0.5-1) [2020-01-18T07:53:57+0100] [ALPM] upgraded qt5-base (5.14.0-1 -> 5.14.0-2) [2020-01-18T07:53:57+0100] [ALPM] upgraded tracker (2.3.0-2 -> 2.3.1+6+g4d3073954-1) [2020-01-18T07:53:57+0100] [ALPM] upgraded tracker-miners (2.3.0-2 -> 2.3.1+23+g139553959-1) [2020-01-18T07:53:57+0100] [ALPM] upgraded wireguard-arch (0.0.20200105-3 -> 0.0.20200105-4) [2020-01-18T07:53:57+0100] [ALPM] upgraded wireguard-tools (1.0.20200102-1 -> 1.0.20200102-2) [2020-01-18T07:53:58+0100] [ALPM] upgraded wireshark-cli (3.2.0-1 -> 3.2.1-1) [2020-01-18T07:53:58+0100] [ALPM] upgraded wireshark-qt (3.2.0-1 -> 3.2.1-1) [2020-01-18T07:53:58+0100] [ALPM] upgraded xapps (1.6.8-1 -> 1.6.10-1) [2020-01-18T07:53:58+0100] [ALPM] upgraded xorg-server-common (1.20.6-3 -> 1.20.7-1) [2020-01-18T07:53:58+0100] [ALPM] upgraded xorg-server (1.20.6-3 -> 1.20.7-1) [2020-01-18T07:53:58+0100] [ALPM] upgraded xorg-server-xephyr (1.20.6-3 -> 1.20.7-1) [2020-01-18T08:24:46+0100] [ALPM] upgraded yay-bin (9.4.3-1 -> 9.4.4-1) Maybe someone have same problem and found the solution. The battery I have changes 3 times and nothing change. Thank you Silvio

4 3

Re: [arch-general] do i need to configure mkinitcpio.conf for my md array ?
by Shadrock Uhuru 19 Jan '20

19 Jan '20

On 16.01.2020 15:36, Josef Miegl wrote: >On January 16, 2020 2:44:44 PM GMT+01:00, Shadrock Uhuru via arch-general <arch-general(a)archlinux.org> wrote: >>do i need to reconfigure mkinitcpio.conf for my md array >>so that the array is assembled and started at boot > >Depends on when you want to assemble your array. If you want/need the array to be assembled in early user space, then use the mdadm_udev hook as described in https://wiki.archlinux.org/index.php/Mkinitcpio#Using_RAID. This is typically needed when booting a system on software RAID. However, if you don't need the array assembled in early user space, just use mdadm later on in the boot process. > >Josef Miegl hi i've rebooted the server and the raid is automatically assembled and mount without any issues or input on my part, i have not altered mkinitcpio.conf or regenerated mkinitcpio, I'm assuming that mdadm.conf is being read on startup or should i still go through the editing of mkinitcpio.conf and regeneration to make sure mdadm.conf is being read at boot, bearing in mind i will not be booting arch of the raid. shadrock

2 1

Re: [arch-general] do i need to configure mkinitcpio.conf for my md array ?
by Shadrock Uhuru 18 Jan '20

18 Jan '20

1 0

[arch-general] systemd-zram generator
by Chris Murphy 17 Jan '20

17 Jan '20

Hi, swap-create@.service generator for zram devices https://github.com/systemd/zram-generator zram: Compressed RAM based block devices https://www.kernel.org/doc/Documentation/blockdev/zram.txt The gist is, if a configuration file exists, a /dev/zram0 device is created during early boot and marks it for use by swap.target; so all the existing systemd stuff to mkswap and swapon gets used. The nice thing is, very low overhead. RAM is not reserved for the device, it's only consumed as needed. The generator could be installed by default, but without a configuration file. In that case, it doesn't create a swap on zram device, unless the user creates a configuration file. And at some point, the distribution can decide to include a configuration file by default. I'm thinking a useful yet conservative default would be to create a device up to 1:1 with RAM, capping out around 2G-4G. That way small RAM devices, like Pi's, get a pretty big zram device. And large RAM devices just have a smallish swap for incidental usage. One issue (reported upstream in github) is getting priority supported. I don't know whether it needs to be configurable, from the config file. But it seems sane to have the generator set a high priority, so that the zram device is used first, spilling over to a conventional swap if the user creates ones. This is a project in rust. And I think once some of the issues get worked out, it would be great if distributions can converge on this implementation. Thanks, -- Chris Murphy

5 7

[arch-general] do i need to configure mkinitcpio.conf for my md array ?
by Shadrock Uhuru 16 Jan '20

16 Jan '20

Hi i have just configured my 4 disk raid 10 array with mdadm the filesystem is ext4 unencrypted and arch is installed on a separate disk do i need to reconfigure mkinitcpio.conf for my md array so that the array is assembled and started at boot, all the examples i've seen have arch installed on the raid array including the example in the wiki https://wiki.archlinux.org/index.php/RAID i have not reboot the new array yet so i would like to make sure everything necessary is configure before i do that. shadrock

4 3

[arch-general] Network UPS Tools (AUR) using usbhid
by David C. Rankin 13 Jan '20

13 Jan '20

Archdevs, Have there been any changes to startup that would impact the Network UPS Tools startup using the usbhid device? I ask because the nut-server.service that has worked for years, is now failing to come up in the normal boot process. $ upsc phoinix_ups Error: Driver not connected However restarting the service after the system is up and running everything works fine. So it's like there is a new depends for the usbhid driver startup that means it has to wait until something else is now started before it can initialize properly. Any idea what could be causing that or what nut-server.service needs to wait on before it tries to start? After kernel update, the failed log messages are: -- Reboot -- Jan 13 11:06:31 phoinix systemd[1]: Starting Network UPS Tools - power devices information server... Jan 13 11:06:32 phoinix upsd[541]: fopen /var/state/ups/upsd.pid: No such file or directory Jan 13 11:06:32 phoinix upsd[541]: /etc/ups/upsd.conf is world readable Jan 13 11:06:32 phoinix upsd[541]: /etc/ups/upsd.conf is world readable Jan 13 11:06:32 phoinix upsd[541]: listening on 127.0.0.1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: listening on ::1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: listening on 127.0.0.1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: listening on ::1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: Can't connect to UPS [phoinix_ups] (usbhid-ups-phoinix_ups): No such file or directory Jan 13 11:06:32 phoinix upsd[541]: Can't connect to UPS [phoinix_ups] (usbhid-ups-phoinix_ups): No such file or directory Jan 13 11:06:32 phoinix upsd[561]: Startup successful Jan 13 11:06:32 phoinix systemd[1]: Started Network UPS Tools - power devices information server. Jan 13 11:11:32 phoinix upsd[561]: Can't connect to UPS [phoinix_ups] (usbhid-ups-phoinix_ups): No such file or directory Then the restart works fine: Jan 13 11:19:20 phoinix systemd[1]: Stopped Network UPS Tools - power devices information server. Jan 13 11:19:20 phoinix systemd[1]: Starting Network UPS Tools - power devices information server... Jan 13 11:19:20 phoinix upsd[823]: fopen /var/state/ups/upsd.pid: No such file or directory Jan 13 11:19:20 phoinix upsd[823]: /etc/ups/upsd.conf is world readable Jan 13 11:19:20 phoinix upsd[823]: /etc/ups/upsd.conf is world readable Jan 13 11:19:20 phoinix upsd[823]: listening on 127.0.0.1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: listening on 127.0.0.1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: listening on ::1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: listening on ::1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: Connected to UPS [phoinix_ups]: usbhid-ups-phoinix_ups Jan 13 11:19:20 phoinix upsd[823]: Connected to UPS [phoinix_ups]: usbhid-ups-phoinix_ups Jan 13 11:19:20 phoinix upsd[824]: Startup successful Jan 13 11:19:20 phoinix systemd[1]: Started Network UPS Tools - power devices information server. Any ideas what to check? This just started within the last month or two. -- David C. Rankin, J.D.,P.E.

1 0