- Arch-general - lists.archlinux.org

[arch-general] FS#65265 - community/dolphin-emu 1:5.0.r11530.ea9b96370d-1 conflicts with discord-rpc-api (I don't agree with Scimmia decision)
by Krzysztof Krakowiak 29 Jan '20

29 Jan '20

Hi, I'm Krzysztof Krakowiak (pix3l in archlinux) and I'm new there https://bugs.archlinux.org/task/65265 I'm very dissapointed by Doug Newgard (Scimmia) bug resolution, who simply closed my bug report with excuse "AUR packages are not supported", but the problem is not in the package from 'aur', but from 'community': I've made request to re-open the the bug-report, by he simply ignored that request The problem lies in fact that dolphin-emu package contains files: discord-rpc-api: /usr/include/discord_register.h exists in filesystem (owned by dolphin-emu) discord-rpc-api: /usr/include/discord_rpc.h exists in filesystem (owned by dolphin-emu) They should belong to 'discord-rpc-api' (currently in aur), and there are many packages dependant on it. Even if 'dolphin-emu' maintainer decides that dolphin-emu wil be built using internal copy of 'discord-rpc-api', there's no reason to export/package those header files, because it's for internal use only(compilation time). I don't get reasoning that if something is fucked up in upstream, then it should be fucked up in distro package (because of upstream...) I was active PLD distro developer (evil_core) and we always had high standards and main excuse for pour existence was to fix upstream brakage/incompetence. best regards, Krzysztof Krakowiak (pix3l)

3 3

[arch-general] ssh askpass problem after todays updates to qt 5.14.1
by Genes Lists 27 Jan '20

27 Jan '20

After the recent updates to qt 5.14.1, both ksshaskpass as well as qt4-ssh-askpass (provided by openssh-askpass) programs dump core. Perhaps these need to be recompiled against the newer qt libraries? Wonder if the latter really is qt4 or just needs to be renamed. thanks. gene

2 4

[arch-general] Why "systemd --user" process hanging around after logout?
by David Rosenstrauch 25 Jan '20

25 Jan '20

I've noticed recently that even after I log out of my desktop env (XFCE) there is a process tree left hanging around running "systemd --user" under my user ID (with a bunch of gvfs child processes running under it). I wouldn't normally care about this, but if I then try to power down the machine, that running process seems to block syslog from successfully shutting down, and so the shutdown process waits for an extra minute and a half until it finally kills the process and powers off. If I manually kill the "systemd --user" process tree, I have no such issues and the machine can power down instantly. Anyone have an idea why this is happening / how to fix? Either by forcing "systemd --user" to terminate on logout, or by forcing syslog and/or the shutdown process to not be blocked by systemd? I did some digging on this, and saw some indication that setting "KillUserProcesses=yes" in /etc/systemd/logind.conf would force the systemd process to get shut down. But I tried changing that setting and it didn't make a difference. I also tried setting a script to run at logout in lightdm, but that didn't seem to work either: it did kill the original systemd process tree running gvfs, but then it looks like another one gets spun up to replace it, and I wind up with the same issue. Anyone have any suggestions how to work around this? Thanks, DR

3 3

[arch-general] Why are Archlinux packages stripped of (debugging) symbols?
by Neven Sajko 24 Jan '20

24 Jan '20

Hello, Why is it that makepkg strips symbols by default, and many packagers even make extra effort to get packages stripped; instead of building with "-g"? Even Go software, which by Go's design makes use of debugging symbols at run time had been stripped as far as I remember (although it seems that has changed, thankfully). It is quite nice to have debugging symbols in executables for learning and entertainment purposes (seriously, try Ghidra or radare2 once), and they are, of course, indispensable when bad luck strikes and one actually has to debug. And there do not seem to be any significant downsides to extra symbols, it just means more permanent storage and bandwidth used. Especially in view of Arch's existing packaging practice patterns, like no "-dev" or "-doc" split packages. I know some developers have some degree of desire for split packages with stripped symbols in separate files, but that would indeed be inconsistent with the lack of "-dev" or "-doc" packages. More importantly, splitting symbols from executable files is most of the time a harmful complication: it makes packaging more complicated, it makes using the separated symbols by humans more complicated, and it makes using the debugging symbols from the program they belong to harder (ref. Ian Lance Taylor's libbacktrace, which does not work with symbols in a separate file, very possibly for reasons fundamental to libbacktrace's purpose). To conclude: besides arguing for debugging symbols to be installed as part of executable files, I am honestly asking what are the reasons for the apparent aversion towards them in Arch's (and wider) culture (because I am curious about that). Regards, Neven Sajko

6 12

[arch-general] R: R: Eduroam madness with iwd
by Riccardo Paolo Bestetti 23 Jan '20

23 Jan '20

Christian, That was it! Thank you for your help. - Riccardo ________________________________ Da: Christian Hesse Inviato: Giovedì, 23 Gennaio, 2020 13:22 A: Riccardo Paolo Bestetti via arch-general Cc: Riccardo Paolo Bestetti Oggetto: Re: [arch-general] R: Eduroam madness with iwd Riccardo Paolo Bestetti via arch-general <arch-general(a)archlinux.org> on Thu, 2020/01/23 08:37: > I'm going to have another chance at testing this on Monday. What else could > I try? Possibly missing something like this? EAP-Identity=anonymous(a)unipmn.it -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

[arch-general] R: Eduroam madness with iwd
by Riccardo Paolo Bestetti 23 Jan '20

23 Jan '20

Hi Christian, Thank you for your response! That's probably it for the systemd error. However, The connection issue persists even when starting iwd manually, with the different error message. I'm going to have another chance at testing this on Monday. What else could I try? -Riccardo ________________________________ Da: Christian Hesse Inviato: Mercoledì, 22 Gennaio, 2020 13:12 A: Riccardo Paolo Bestetti via arch-general Cc: Riccardo Paolo Bestetti Oggetto: Re: [arch-general] Eduroam madness with iwd Riccardo Paolo Bestetti via arch-general <arch-general(a)archlinux.org> on Wed, 2020/01/22 11:45: > And the following error in the system journal: > failed to load /home/random/.cat_installer/ca.pem The certificate can not be loaded as iwd.service has ProtectHome=yes set. Move it to a location where iwd can read it. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

3 2

[arch-general] Eduroam madness with iwd
by Riccardo Paolo Bestetti 22 Jan '20

22 Jan '20

Hi! I'm trying to configure iwd to connect to Eduroam. My home istitution requires EAP-TTLS authentication with PAP Phase 2. I have the following configuration file: [Security] EAP-Method=TTLS EAP-TTLS-CACert=/home/random/.cat_installer/ca.pem EAP-TTLS-ServerDomainMask=*.unipmn.it EAP-TTLS-Phase2-Method=Tunneled-PAP EAP-TTLS-Phase2-Identity=theUser EAP-TTLS-Phase2-Password=thePassword [Settings] AutoConnect=true When I try to connect with iwd started as a systemd unit, I get the following error in iwctl: Not configured. And the following error in the system journal: failed to load /home/random/.cat_installer/ca.pem (the certificate is valid and is in the required PEM format - I checked it with the openssl command and it also works with different network daemons) When I try to connect with iwd started manually with /usr/lib/iwd/iwd -d, I get the following error instead: Operation failed. And idw outputs: 4-Way handshake failed for ifindex: 3, reason: 23. I ran out of debugging ideas! Can anyone help? - Riccardo

2 1

[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