- Arch-general - lists.archlinux.org

[arch-general] calibre is now available in python3
by Eli Schwartz 25 Nov '19

25 Nov '19

After about 15 months of gradual work by me and a few other people, https://calibre-ebook.com/ is running pretty stably on python3, so I've uploaded a split package to [community]: calibre (the default python2 build), calibre-python3 (a python3 build, naturally), and calibre-common with some common files. Hopefully this will get rid of one of our major python2 consumers soon. Upstream doesn't officially support this yet, so treat it like the pre-beta it is. You'll also be unable to use thirdparty plugins, since none of those are ported yet, so you may want to have both 'calibre-python3' and 'calibre' installed -- since pacman still doesn't have support for an "alternatives" feature, I've written a dumb shell script to do the work of switching between the two, see `calibre-alternatives help` for details (it is in the calibre-common package). General information about the port and its status can be found here: https://github.com/kovidgoyal/calibre/pull/870 At some point soon upstream will finish making cross-platform betas and plugins will start to be ported by their developers, so watch this space (and the mobileread.com forums) for more info... Bug reports for python3 regressions will be greatly appreciated, as there are probably a lot of fun edge cases and I'd like to see this finished sooner rather than later. ;) -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-general] Many timers now running at boot. How to make them run later?
by David C. Rankin 23 Nov '19

23 Nov '19

After not booting an Arch box for several days, the first few minutes seem quite MS like lately with a flurry of processes running to the point after I enter my username at the console, it may be 10-20 sec before the password prompt is displayed. Since it's all timers now and not cron running things quietly at 4:00 am, this loads sever processes right at boot that cause the problem. For example, boot just now was crawling and checking systemctl timers shows: (leading columns snipped) LAST PASSED UNIT ACTIVATES n/a n/a systemd-tmpfiles-clean.timer systemd-t> Thu 2019-11-21 03:33:43 CST 11min ago logrotate.timer logrotate> Thu 2019-11-21 03:33:43 CST 11min ago man-db.timer man-db.se> Thu 2019-11-21 03:33:43 CST 11min ago shadow.timer shadow.se> 4 timers listed. Pass --all to see loaded but inactive timers, too. This impacts being able to get thins from a computer in a hurry and reminds me of the unpleasant waits waiting for windows to run all of its on-boot checks. What is the best way to modify this scheme to prevent, e.g. logrotate.time, man-db.timer and shadow.timer all trying to run on boot? I'd rather set them up to run a 5:00 localtime as I would with cronnie. But I do want to use the systemd timer, so what is the best way to configure the systemd timer to schedule these things to run at a convenient time instead of all firing on boot? -- David C. Rankin, J.D.,P.E.

6 9

[arch-general] Disable pam_securetty.so
by Daan De Meyer 21 Nov '19

21 Nov '19

Hi, I don't want to come across as impatient but I was wondering how I can accelerate handling of this particular issue: https://bugs.archlinux.org/task/45903?project=1&string=pam I've listed examples in the issue that pam_securetty has been disabled on other major distros. The main issue is that it prevents root login on systemd-nspawn containers. It should be easy to remove and there's a precedence in other distros. Any tips on how to proceed to get this fixed? Regards, Daan

2 1

[arch-general] issue with i915
by Enrique Pérez Arnaud 20 Nov '19

20 Nov '19

Hi, I am experiencing some issue with the i915 driver. The symptom is hangups of the graphic environment every few minutes, lasting for a couple of seconds. When they happen, journalctl shows a log entry like: Nov 14 12:39:46 eperez-ws kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0 This seems to be reported [1] but I don't see any solution there. Does anyone know of some solution for this? Thanks in advance, and have a nice day :) 1.- https://gitlab.freedesktop.org/mesa/mesa/issues/1837 -- Enrique Pérez Arnaud enriquepablo(a)gmail.com

2 2

[arch-general] The differences among bootx64.efi, loader.efi and grubx64.efi.
by Hongyi Zhao 20 Nov '19

20 Nov '19

I noticed that for many distro's install iso, there are some efi files in the EFI/efi folder as follows: bootx64.efi, loader.efi and grubx64.efi Say, for arch: bootx64.efi, loader.efi for debian: bootx64.efi grubx64.efi I just cannot figure out the differences among them. Could you please give me some hints on this? Thanks in advance. -- Hongsheng Zhao <hongyi.zhao(a)gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493

3 7

[arch-general] Extreme Minimalist Challenge
by Lonnie Cumberland 18 Nov '19

18 Nov '19

Hi All, I am new to Arch Linux and am hoping that this might be the direction that I need to look for a demo project that I am eagerly seeking to build and I really hope that someone can help me towards the right direction. The project is basically to have the absolutely smallest possible Linux distro (x86_64 based) that would be a type of LiveCD RAM-Based bootable system that has an Xserver and VirtualBox 6.0 but no real desktop running. I want it to boot directly into the VirtualBox 6.0 GUI. The other catch is that I need a system that has an extremely small footprint image and am hoping that the ISO could be between 150 MB - 200 MB in size, but of course even smaller is better. Its an ambitious project and I am seeking help on if Arch Linux may be a good starting point for the basic OS and Xorg server as well as any suggestions or advice that the mailing list might like to provide. Any suggestions or recommendations would be greatly appreciated. Best Regards, Lonnie

4 4

[arch-general] What happened to Arch Wiki recent changes news feed?
by Štěpán Němec 15 Nov '19

15 Nov '19

Hello, I noticed some time ago the feed stopped working. I used to follow it using the gwene.org gateway, but even following the link from https://www.archlinux.org/feeds/ to https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=rss sends me to a "Login Required" page. So apparently either the feed is gone for good intentionally (I hope not) and shouldn't be listed, or is broken and should be fixed? -- Štěpán

4 6

Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks
by Amish 14 Nov '19

14 Nov '19

On 11/11/19 3:11 am, Arch Linux: Recent news updates: Giancarlo Razzolini wrote: > All our official kernels: linux, linux-lts, linux-zen and linux-hardened, do not install the actual kernel to /boot anymore. I would like to report an issue I faced due to this. Not an issue for everyone but can be an issue in a certain special cases. I have a custom package (in my custom repo) which modifies grub UI / menus (cosmetic change only) by putting some files in /etc/grub.d/ and regenerates /boot/grub/grub.cfg (by calling grub-mkconfig in package's post install script). This has been working fine from 2 years or so. Recently I released an update to that custom package but at the same time, upgrades to linux as well as linux-lts packages were also available in arch repository. And after upgrade, grub.cfg lost linux and linux-lts menu entries completely. What happened is: 1. mkinitcpio hook first removed vmlinuz-linux, vmlinuz-linux-lts and initrd files from /boot 2. My package got updated along with new versions of linux and linux-lts 3. My package's post install script ran grub-mkconfig but new vmlinuz files did not exist yet in /boot. So grub entries were not created for them. 4. mkinitcpio-install post transaction hook runs and copies kernel to /boot (but its too late for my post install scripts) So effectively this created an un-bootable system requiring manual booting. This is going to happen every time my package plus linux / linux-lts package get upgraded in the same pacman run. (i.e. this will not happen always but only in certain conditions) I know my issue is not common and I will also change my script to post transaction hook. But this is to warn anyone who has a custom package with post install script which looks for / expects kernel files in /boot. (like grub-mkconfig). Those scripts are going to break with the recent changes to kernel package and it would be advisable to put them in post transaction hook and that too after mkinitcpio-install scripts run. Regards, Amish

3 4

[arch-general] electron upgrade (7.1.1-1 -> 7.1.1-2) sort of broke functionality on several electron apps
by Javier 11 Nov '19

11 Nov '19

The 1st thing I noticed was that after the upgrade, the lectron apps no longer show up under the legacy tray, but instead on the more modern notification area (under LXQT). The 2nd thing, was the tray icons not doing any action. The 3rd thing, was that in order to use the electron apps, I had to call them with starting on tray, since the tray icons don't respond. And finally I can't try to iconify on tray, given the tray icons don't respond... Any one else experiencing the same? Other than just reverting to the prior electron, is there known workarounds for these issues? Has anyone faced them already, and dealt with them? Just in case a few electron apps experiencing the same: signal-desktop-bin whatsapp-nativefier slack-desktop Thanks ! -- Javier

1 1

Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks
by Damjan Georgievski 11 Nov '19

11 Nov '19

> This has been discussed a bit on the dracut thread, as well on some other threads over time. > I *personally* don't like the complexity of kernel-install that much. I've now read this twice on Arch mail lists, so I have to ask, without any presumptions on my side, what are the arguments against kernel-install? I must say, I don't see much complexity in it. It's only a 184 line bash script[1]. And as added feature, it decouples the kernel install from the kernel package install (and pacman), also defines couple of easy-to-use config locations like /etc/kernel/cmdline But I guess I might be missing something. [1] especially compared to dracut (not that they do the same thing), which seems much more complex, and that complexity did introduce bugs - for which I've sent a PR -- damjan

3 2