- Arch-general - lists.archlinux.org

[arch-general] OVMF fails to build
by mytbk920423＠gmail.com 26 Sep '15

26 Sep '15

Hi, I've just tried to build OVMF but failed to build with the ABS PKGBUILD. ----------------- Ran 259 tests in 1.271s OK make[1]: Leaving directory '/tmp/makepkg/ovmf/src/edk2/BaseTools/Tests' make: Leaving directory '/tmp/makepkg/ovmf/src/edk2/BaseTools' WORKSPACE: /home/irudog/SourceCode/edk2 EDK_TOOLS_PATH: /tmp/makepkg/ovmf/src/edk2/BaseTools sed: can't read Conf/target.txt: No such file or directory ==> ERROR: A failure occurred in build(). Aborting... ----------------- Iru

1 0

[arch-general] build package from source and shared libraries issue
by arnaud gaboury 25 Sep '15

25 Sep '15

I am scratching my head since a week now and can't figure out how to solve my issue. Here is the situation: 1- I have installed parallel_studio_xe from Intel with the AUR package[0] 2- /etc/ld.sconf.so has all the needed .conf file to feed correctly my ld.so.cache 2- I build R package[1] from source with the following script. The goal is to build R with intel MKL shared libraries and gcc compiler. ----------------------- source /opt/intel/mkl/bin/mklvars.sh intel64 _icclibpath=/opt/intel/composerexe/compiler/lib/intel64/ _mkllibpath=$MKLROOT/lib/intel64/ _omp_lib=/opt/intel/lib/intel64 MKL=" -L${MKLROOT}/lib/intel64 \ -Wl,--start-group \ -lmkl_gfl_ilp64 \ -lmkl_core \ lkml_intel_thread \ -Wl,--end-group \ -liomp5 -ldl -lpthread -lm" export LDFLAGS="${LDFLAGS} -L${_icclibpath}" export CFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include" export CXXFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include" export FFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include" export FCFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include" ./configure --prefix=/usr \ --libdir=/usr/lib \ --sysconfdir=/etc/R \ --datarootdir=/usr/share \ rsharedir=/usr/share/R/ \ rincludedir=/usr/include/R/ \ rdocdir=/usr/share/doc/R/ \ --with-x \ --enable-R-shlib \ --with-blas="$MKL" \ --with-lapack \ F77=${_F77} \ FC=${_FC} \ LIBnn=lib make -j4 ------------------------------------------------------------- from build package: $ ldd bin/exec/R linux-vdso.so.1 (0x00007ffd707b4000) libR.so => /usr/lib/R/lib/libR.so (0x00007f909d4e2000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f909d2c5000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f909cf21000) libmkl_gf_lp64.so => /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so (0x00007f909c84d000) libmkl_core.so => /opt/intel/mkl/lib/intel64/libmkl_core.so (0x00007f909ace0000) libmkl_gnu_thread.so => /opt/intel/mkl/lib/intel64/libmkl_gnu_thread.so (0x00007f9099f89000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f9099d85000) libimf.so => /opt/intel/lib/libimf.so (0x00007f90998ca000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f90995cc000) ............................ libintlc.so.5 => /opt/intel/lib/libintlc.so.5 (0x00007f90976df000) libgcc_s.so.1 => /usr/lib/../lib/libgcc_s.so.1 (0x00007f90974c9000) libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f909725c000) libicudata.so.55 => /usr/lib/libicudata.so.55 (0x00007f90957a6000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f9095424000) ----------------------------------- Fine, I can see some shared intel libraries. 3- Now I build same package on my systemd nspawn container, Fedora 22. I use same script, same ld.so conf files, intel parallel studio on same path (/opt/intel). 4- from build folder: linux-vdso.so.1 (0x00007ffe3d9de000) libR.so => /usr/lib64/R/lib/libR.so (0x00007f1061d6c000) libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f1061b3b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f106191f000) libc.so.6 => /lib64/libc.so.6 (0x00007f106155e000) libblas.so.3 => /lib64/libblas.so.3 (0x00007f1061305000) libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007f1060fda000) libm.so.6 => /lib64/libm.so.6 (0x00007f1060cd1000) libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007f1060a92000) libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f1060848000) libtre.so.5 => /lib64/libtre.so.5 (0x00007f1060637000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f10603c7000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f10601a1000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f105ff90000) libz.so.1 => /lib64/libz.so.1 (0x00007f105fd7a000) librt.so.1 => /lib64/librt.so.1 (0x00007f105fb72000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f105f96d000) libicuuc.so.54 => /lib64/libicuuc.so.54 (0x00007f105f5dc000) libicui18n.so.54 => /lib64/libicui18n.so.54 (0x00007f105f185000) /lib64/ld-linux-x86-64.so.2 (0x00005610cd111000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f105ef6d000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f105ed43000) libicudata.so.54 => /lib64/libicudata.so.54 (0x00007f105d317000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f105cf95000) ---------------------------------------------------- As you can see, no links at all to any Intel shared libraries. I am looking for advices/hints why I don't have the same linking libraries on both systems. I have tried to look everywhere I could, changed many and many settings/variables, I still can't get same result about shared libraries. I must forget or do something wrong, but no idea what. My building environment shall differ at some point. The config.log are nearly the same on the two distro, except for this: On Fedora: ------------------------------------------------- Configured with: ../configure --enable-bootstrap --enable-languages=c,c+$....... --------------------------------------------------------- On Arch: ------------------------------------ Configured with: /build/gcc-multilib/src/gcc-5.2.0/configure ...... Thank you for any hints and where to look to compare build environment diff. [0]https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-parallel-stu… [1]https://www.archlinux.org/packages/extra/i686/r/ --

1 0

[arch-general] Arch Forum problem
by Travis 24 Sep '15

24 Sep '15

if you try to register https://bbs.archlinux.org/register.php it has a anti-spam question. that fails on both cent and arch cent: [x@x /]$ date -u +%V$(uname)|sha256sum|sed 's/\W//g > ^C [x@x /]$ arch: [root@alarmpi ~]# echo date -u +%V$(uname)|sha256sum|sed 's/\W//g > [root@alarmpi ~]# date -u +%V$(uname)|sha256sum|sed 's/\W//g > [root@alarmpi ~]# ... also the post i'm asking about (and was willing to register to the arch forum) https://bbs.archlinux.org/viewtopic.php?id=183086 someone did a RTFM response and the wiki/manual page person reference doesn't have a straight answer and please don't complain about it being an old post, i'm trying to help you guys, as that post comes up in google first page and with fairly board google searches. so a proper answer would help other potential Arch users.

5 5

[arch-general] Glade package outdated
by Lukas K. 24 Sep '15

24 Sep '15

Hi there, the glade package is outdated for quite some time now. Glade 3.19 has been released June this year and still isn't included in the Archlinux repos. I flagged the package out of date several times, but the flag got reset without the package being updated. Are there any roadblocks in updating the package to 3.19? I'm running Glade 3.19 for some time without any issues. Lukas

2 1

[arch-general] man page selection helper for arch
by David C. Rankin 24 Sep '15

24 Sep '15

All, For what it is worth, I like to have an automatic list of manual pages presented when there is more than one matching page available (similar to whatis) I also like to be able to select which page to display from the that list, without having to type 'man pg name' again. This has always been a feature on some oh the other distros. I couldn't find anything that would do that on Arch, so I wrote a small function that can be aliased to provide the functionality. If you're interested, it is: ## function to alias as man on arch to provide # user selection of available man pages manselect() { [ -z "$1" ] && return 1 if [ -z "$2" ]; then local timeout=5 local pgs=( $(whatis "$1" | sed -e 's/^.*[(]//' -e 's/[)].*$//') ) local npgs=${#pgs[@]} [ $npgs -eq 0 ] && return 1 local pg=${pgs[0]} if [ $npgs -eq 1 ]; then /usr/bin/man $pg "$1" else local line while read -r line; do printf " %s\n" "${line%)*})" done < <(whatis "$1") printf "Select a man page (%s): " "$pg" read -t $timeout ans && pg=$ans || echo "" /usr/bin/man $pg "$1" fi else if [ ${1:0:1} -eq ${1:0:1} ] >/dev/null 2>&1 ; then /usr/bin/man $1 "$2" else printf "error: invalid man page specification: '%s'\n" "man $1 $2" fi fi } I just include it as a function in .bashrc and then provide an alias: alias man='manselect' You can adjust the order the man pages are presented in by adjusting the SECTION order in /etc/man_db.conf. This can tailor the order of which page is shown by default if no selection is made. Thought I would pass it along... -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] systemd-logind: failed to get session
by Ralf Mardorf 23 Sep '15

23 Sep '15

Hi, Arch runs without any issues, so I randomly discovered this: [rocketmouse@archlinux ~]$ grep EE /var/log/Xorg.0.log [ 26.702] Current Operating System: Linux archlinux 3.10.61-rt65-1-rt-lts x86_64 [ 27.745] (EE) systemd-logind: failed to get session: PID 437 does not belong to any known session [rocketmouse@archlinux ~]$ ps aux | grep 437 root 437 2.1 2.2 297136 84320 tty7 Ssl+ Sep22 32:09 /usr/lib/xorg-server/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch Web research regarding "does not belong to any known session" without experiencing issues leads nowhere. What could be the reason? Regards, Ralf

2 1

[arch-general] Kernel NULL pointer and crash - raid bug in 4.1.6 - and fix
by Genes Lists 21 Sep '15

21 Sep '15

I (and others) have enocuntered a pretty nasty raid bug that crashes the machine running current 4.1.x stable. It seems a commit is available but not yet in 4.1.6. (commit 49895bcc7e566ba455eb2996607d6fbd3447ce16) Seems like it is in 4.2 tho. Not sure it's worth patching 4.1.6 with this if 4.2 is imminent - but it may be - it kills the machine and has caused some file lossage. Bugzilla: Upstream: https://bugzilla.kernel.org/show_bug.cgi?id=103711 Arch : https://bugs.archlinux.org/task/46188 Tobias - what do you suggest best way to proceed - skip as 4.2 is out or patch 4.1.6? Thanks gene/

3 3

[arch-general] sddm crashing with plasma
by Genes Lists 21 Sep '15

21 Sep '15

Anyone else seeing this - started after systemd 226 update. It starts sometimes - most often crashes on warm reboot - cold reboot seems more likely to work. Feels like a threading bug (missing mutex somewhere, or a barrier or something). Symptom: Reboot - sddm won't start. Log: ddm-helper[4240]: segfault at 14 ip 000000000042965e sp 00007ffdec4eb3b0 error 4 in sddm-helper[400000+3a000] Rebooting cold - will usually get it running again with no errors.

2 1

[arch-general] pulseaudio 6.99 in [testing], daemon can't start, chokes on module-native-protocol-unix
by Oon-Ee Ng 21 Sep '15

21 Sep '15

Anyone else seeing this? My default.pa is stock (it wasn't before, but I reverted the minor changes and no change in behaviour), and the daemon just won't start. If I comment out module-native-protocol-unix it will, but of course it's not usable that way. Reported it as a bug on freedesktop[1], but I'd be surprised if its actually a bug given how I'd assume I'm not the only [testing] user using this... any ideas? [1] - https://bugs.freedesktop.org/show_bug.cgi?id=92061

1 0

[arch-general] Can we talk about the systemd mkinitcpio hook for a minute?
by Chris Bell 20 Sep '15

20 Sep '15

Hello all, First off, apologies if this has been/is being discussed elsewhere, but this has been on my mind for quite some time. The state of the systemd mkinitcpio hook has been bothering me recently. It seems that there is some confusion/ambiguity about what capabilities, precisely, said hook provides; particularly with regards to replacing the 'base' hook at some point. I think it's effectively ready now; I've been using the systemd hook without base and udev for some time now. The only sticking point seems to be with the rescue and emergency shells. Of the 19 open systemd bugs [0], four of them [1-4] deal with systemd not providing an emergency/rescue shell and/or busybox/maintenance tools to the initrd image. Based on my understanding of the status quo, the systemd init hook is intended to simplify and streamline the boot process and the initrd image for systemd-based systems. The hook currently does this. It does not provide any functional rescue capabilities (you can get to an emergency shell, but it doesn't work), and I don't think it should. The use case for initrd-based rescue shells is very small and specific; many of these use cases can make do with a live image or something similar. Basically, my view is this: the systemd hook should only provide boot functionality, and not contain rescue/emergency targets/shells by default. The problem with providing such functionality is that the dependencies and binary include requirements quickly spiral out of control when providing a full shell within the initrd (sulogin, busybox, any rescue tools, etc). Having so many dependencies goes against the simplicity that the systemd hook is trying to accomplish. If anything, I propose a new hook, sd-rescue, which provides rescue.{target,service}, emergency.{target,service}, busybox, and minimal binaries useful for rescuing a system. This can be used in situations where live-image booting is not an option, or where the sysadmin prefers the option of initrd emergency/rescue functions. Also, we should maybe stop including emergency.target with the systemd hook, since it doesn't seem to work in most cases. -- Chris [0] https://bugs.archlinux.org/?project=1&cat%5B%5D=31&string=systemd [1] https://bugs.archlinux.org/task/44493?project=1&cat%5B0%5D=31&string=systemd [2] https://bugs.archlinux.org/task/45480?project=1&cat%5B0%5D=31&string=systemd [3] https://bugs.archlinux.org/task/42399?project=1&cat%5B0%5D=31&string=systemd [4] https://bugs.archlinux.org/task/36265?project=1&cat%5B0%5D=31&string=systemd

3 2