- Arch-general - lists.archlinux.org

[arch-general] Out-of-date package "code"
by Jens Hausdorf 31 Oct '18

31 Oct '18

Hey folks, as this is my first post on any of the Arch Linux mailing lists, please correct me if I'm putting this on the wrong list. The code package in the community repository[1] is flagged out-of-date since 2018-10-08 and after contacting the Maintainer personally via e-mail on 2018-10-21, I didn't get any response until now(10 days later). I wonder whether Filipe is alright or maybe on vacation? Regards, Jens 1 - https://www.archlinux.org/packages/community/x86_64/code/

1 0

[arch-general] atlas-lapack-base vs openblas issue requires manual intervention to allow an update
by Ralf Mardorf 30 Oct '18

30 Oct '18

Hi, depending on what we have installed, there's the need to replace 'atlas-lapack-base' by 'cblas', 'lapack' and 'openblas'. My install's dependency chain needs it for packages such as 'blender' and 'gimp' (all from official repositories), resp. without having 'sagemath' installed 'openblas' seemingly could be replaced by 'blas' [1], too. However, there's seemingly the need to install 'cblas', 'lapack' and 'openblas' or 'blas' first. Perhaps this should be mentioned by the news at https://www.archlinux.org/ and by https://lists.archlinux.org/listinfo/arch-announce. Regards, Ralf [1] $ sudo pacman -Syu [snip] looking for conflicting packages... :: openblas and atlas-lapack-base are in conflict (blas). Remove atlas-lapack-base? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: unable to satisfy dependency 'lapack' required by r [snip] $ sudo pacman -S openblas cblas lapack [snip] Packages (4) atlas-lapack-base-3.10.3-1 [removal] cblas-3.8.0-2 lapack-3.8.0-2 openblas-0.3.3-1 [snip] :: Proceed with installation? [Y/n] n $ sudo pacman -S blas cblas lapack [snip] Packages (4) atlas-lapack-base-3.10.3-1 [removal] blas-3.8.0-2 cblas-3.8.0-2 lapack-3.8.0-2 [snip] :: Proceed with installation? [Y/n] Y $ sudo pacman -Syu [snip] :: openblas and blas are in conflict. Remove blas? [y/N] y Packages (149) [snip] :: Proceed with installation? [Y/n] Y $ pactree -r openblas openblas ├─cblas │ [snip] ├─lapack │ [snip] ├─r └─sagemath $ sudo pacman -S blas [snip] :: blas and openblas are in conflict. Remove openblas? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: removing openblas breaks dependency 'openblas' required by sagemath [snip]

1 0

[arch-general] Reboot-less Computers
by Jayesh Badwaik 28 Oct '18

28 Oct '18

Hi, I am looking at possibilities to have a setup which does not need to be restarted at all and can be live patched. I have seen this old post: http://allanmcrae.com/2015/03/updating-arch-kernel-on-digital-ocean/ And I am reading information about kpatch. But there does not need to be much information. Is there a reliable way to do this currently? If yes, I would like to know some information about it. Ideally, a tried and tested set of steps will be welcome. But things are never so easy I guess. -- Cheers Jayesh Badwaik https://jayeshbadwaik.github.io

4 4

[arch-general] Issue linking 32-bit GAS assembly
by Dutch Ingraham 18 Oct '18

18 Oct '18

Hi all: I'm having a problem linking 32-bit GAS assembly code that references external C libraries on an up-to-date 64-bit Arch installation. I have enabled the 32-bit repositories and installed the multilib-devel group and lib32-glibc. I have updated the library cache with ldconfig and rebooted. The command to assemble is: <as --32 -o filename.o filename.s>. Assembly succeeds. However, when linking using the command <ld -melf_i386 --dynamic-linker /lib32/ld-linux.so.2 -lc -o filename filename.o> the command fails with: ld: skipping incompatible /usr/lib/libc.so when searching for -lc ld: skipping incompatible /usr/lib/libc.a when searching for -lc ld: cannot find -lc Note this linker command (or a hierarchy-appropriate one) seems standard, and succeeds on a 64-bit Debian OS. There is a fairly recent Forum question (but pre-dating the discontinuance of i686 support) regarding the same issue at https://bbs.archlinux.org/viewtopic.php?id=229235 which indicates the command should be: <ld -melf_i386 -shared -L /usr/lib32 -dynamic-linker /lib/ld-linux.so.2 -o \ filename filename.o -lc> This command succeeds, insofar as the linker returns an exit code of 0. However, running the program (and all other similar programs) fails with "Illegal instruction (core dumped)." Assembling with debugging symbols and running a backtrace didn't enlighten me. Note that changing /lib/ld-linux to /usr/lib32/ld-linux in the command immediately above produces the same result, as confirmed by the output of <ldconfig -p> Anyone see something I've missed of have any suggestions? Thanks. ----------- Here is some simple code to test with: # paramtest2.s - Listing system environment variables .section .data output: .asciz "%s\n" .section .text .globl _start _start: movl %esp, %ebp addl $12, %ebp loop1: cmpl $0, (%ebp) je endit pushl (%ebp) pushl $output call printf addl $12, %esp addl $4, %ebp loop loop1 endit: pushl $0 call exit

5 7

[arch-general] How to delete user from bugs.archlinux.org
by scootergrisen 15 Oct '18

15 Oct '18

How do i delete my user/account from https://bugs.archlinux.org/ ?

2 1

[arch-general] Can I prevent Pacman from running hooks?
by Tobias Hunger 14 Oct '18

14 Oct '18

Hi Arch Community, I have scripts that will install a set of arch linux machines for me with all the tweaks I want. These scripts run pacman a lot to install bits and pieces. Usually the script will running pacman to install one package and then configure that package and then proceed to install the next (set of) packages. This works great, but a noticeable part of the run time is spent on running pacman hooks (e.g. to update the man-db and similar things). So I am wondering: Is it possible to stop pacman from running hooks during package installation? I do know when it is "safe" to not run hooks (when the system is not complete yet) and when I need to run all of them (right after the system has all packages installed that it will have). So far I run pacman with a --hookdir that contains symlinks to /dev/null named like some of the more expensive hooks that tend to take long to complete. But a --no-hooks option to pacman would be great for my use case. Is it possible to run pacman without it triggering hooks? Best Regards, Tobias

5 12

[arch-general] If you have a SuperMicro board....
by David C. Rankin 06 Oct '18

06 Oct '18

Worth passing along: We can now add motherboard stealth chips to the list of security concerns https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-u… The upside is the article reads better than any modern day spy novel. -- David C. Rankin, J.D.,P.E.

3 3

[arch-general] Gnome 3.30 - Suspend acts as suspend-then-hibernate
by Reto Haeberli 01 Oct '18

01 Oct '18

Hello arch-general, I don’t know where to address this properly, so I try here: Obviously the behaviour for suspend has been changed in gnome 3.30 from suspend to "suspend then hibernate". Personally I have only discovered this after a while - suddenly experiencing random crashes after entering suspend mode. The whole implementation does not check reliably if hibernate is fully established (this was not the case on my pc cause I don’t need it) and then causes crashes that could potentially result in a data loss when trying to hibernate from suspend state. There is also a discussion in the forum: https://bbs.archlinux.org/viewtopic.php?pid=1810621#p1810621 I’m new to arch but I’d assume it would be beneficial to issue a warning to users or change the default behaviour back to the old one where suspend is “suspend" and not "suspend then hibernate"? Thoughts? Best regards

1 0

[arch-general] MariaDB package version
by Kevin Dodd 30 Sep '18

30 Sep '18

I recently noticed Arch Linux's mariadb package is still on the 10.1 release series, even though upstream has considered the 10.2 and 10.3 release series to be "stable" for at least 4 months. Arch is usually so good about keeping everything up-to-date, so I am curious what the reason for this is. Something to do with compatibility? Thanks, ~ Kevin Dodd

8 9

[arch-general] AppArmor support
by Gus 28 Sep '18

28 Sep '18

I know such request was rejected here https://bugs.archlinux.org/task/59733 recently, but still AppArmor doesn't need linking with libraries and doesn't require as much userland support as SELinux, so it will not hurt to have one option enabled in kernel, right?

12 48