- Arch-general - lists.archlinux.org

[arch-general] arch-dev-public Re: Bug tracker migration
by David C. Rankin 30 Aug '20

30 Aug '20

On 8/29/20 6:02 PM, Frederik Schwan via arch-dev-public wrote: <snip> > Please make sure you all have a working account at our Gitlab instance. > If this change is 2-weeks away, shouldn't there be a note at least at the following existing sites informing folks that a new gitlab account will be needed? Site where notice of the change would make sense: bugs.archlinux.org or https://wiki.archlinux.org/index.php/Getting_involved#Fix_and_report_bugs -- David C. Rankin, J.D.,P.E.

2 1

[arch-general] drop dependencies on legacy inetutils for `hostname`
by Geert Hendrickx 27 Aug '20

27 Aug '20

Hi A number of packages depend on inetutils merely for the `hostname` command. Common packages include xorg-xinit and mariadb, which makes that inetutils is still installed on a large number of Arch systems, although its other components like rcp, rsh, talk, telnet ... and their server counterparts, are really old, deprecated, and totally insecure. Plus the implementation seems to be largely abandoned by upstream (see FS#61041). Needless to say, I don't want any of these installed on my systems. Since `hostname` is still somewhat common though, there are probably more implicit dependencies on it, for example FS#66603. So I would like to eliminate dependencies on inetutils just for hostname, in one of the following ways: 1/ Split the inetutils package and provide hostname as a sub-package (but then still need to maintain inetutils) 2/ Package the Debian implementation, also used by Fedora and others (but this includes other legacy shit like `nisdomainname` and `ypdomainname`) See https://packages.qa.debian.org/h/hostname.html 3/ Use the implementation provided by gettext (/usr/lib/gettext/hostname), which is already part of base, and thus eliminates the need for explicit dependencies. Although this implementation can only *get* the hostname, not *set* it, that's all the dependent packages need, and setting the hostname is nowadays handled by systemd's `hostnamectl` anyway. My preference would be 3/, for simplicity. I already run my systems with /usr/bin/hostname symlinked to /usr/lib/gettext/hostname (after forcibly removing inetutils), and noticed no issues. This can be done in two steps: i. make the gettext package install (or symlink) /usr/bin/hostname, drop it from inetutils, and introduce mutual conflicts on older versions of each. ii. drop the dependency on inetutils from other packages (or replace it with a dependency on hostname if options 1/ or 2/ are preferred). Fans of `telnet` can continue to install inetutils manually, of course. ;-) WDYT ? Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

2 6

[arch-general] Xorg Segfault on Console Switch
by Yaro Kasear 27 Aug '20

27 Aug '20

I seem to be having an odd issue with Xorg since updating to 1.20.9. I tend to be logged onto Xorg across more than one user based on what kind of task I need, and switch between them via CTRL+ALT+F1/F2/F3. Since the update this morning it seems to have started causing segfaults on Xorg the longer I'm switched away from the console containing the Xorg instance that crashes. I am not even sure how to begin troubleshooting this problem. I can usually figure this out on my own. Process 8780 (Xorg) of user 1003 dumped core. Stack trace of thread 8780: #0 0x00007ff15b192615 raise (libc.so.6 + 0x3d615) #1 0x00007ff15b17b862 abort (libc.so.6 + 0x26862) #2 0x00005617387ee35a OsAbort (Xorg + 0x14a35a) #3 0x00005617387efe21 FatalError (Xorg + 0x14be21) #4 0x00005617387f5a79 n/a (Xorg + 0x151a79) #5 0x00007ff15b1926a0 __restore_rt (libc.so.6 + 0x3d6a0) #6 0x0000561738722f03 n/a (Xorg + 0x7ef03) #7 0x00005617387a8ed5 n/a (Xorg + 0x104ed5) #8 0x00005617387d67fc n/a (Xorg + 0x1327fc) #9 0x00005617386edbb3 mieqProcessDeviceEvent (Xorg + 0x49bb3) #10 0x00005617386edcfc mieqProcessInputEvents (Xorg + 0x49cfc) #11 0x00005617388045b9 ProcessInputEvents (Xorg + 0x1605b9) #12 0x00005617386dd8c8 n/a (Xorg + 0x398c8) #13 0x00007ff15b17d152 __libc_start_main (libc.so.6 + 0x28152) #14 0x00005617386de5ae _start (Xorg + 0x3a5ae) Yaro

2 1

[arch-general] Fwd: cscope fixup for emacs 27.1
by Yi Zheng 25 Aug '20

25 Aug '20

Hi, cscope released with contrib emacs plugin xcscope.el It uses emacs-lisp function process-kill-without-query, which is removed in emacs-27.1 I cloned the git repo of cscope(git://git.code.sf.net/p/cscope/cscope), and add an fixup. but it seems that the upstream is long not been updated. do u think we should add that patch into our archlinux pkg ? I do have tested that fixup, and it works(as in the old times) the patch is attached.

1 0

[arch-general] Telinit?
by David Rosenstrauch 23 Aug '20

23 Aug '20

Anyone know what happened to the "telinit" shortcut? It used to be included in systemd-sysvcompat (https://wiki.archlinux.org/index.php/Systemd#systemd-sysvcompat) but seems like it recently got removed. Was it removed upstream? (And if so, anyone know why?) Thanks, DR

10 20

[arch-general] pacman -Syu -- Applying kernel sysctl settings... Not setting ... Worry?
by David C. Rankin 22 Aug '20

22 Aug '20

Arch devs, For the past several updates, I have noticed the kernel sysctl settings messages saying: ( 5/17) Applying kernel sysctl settings... Not setting net/ipv4/conf/all/rp_filter (explicit setting exists). Not setting net/ipv4/conf/default/rp_filter (explicit setting exists). Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists). Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists). Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists). Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists). After the recent netctl message issue, I want to nail down what set these in /proc and whether it is something I need to do something about. I didn't set any of these specifically, so I presume they are either explicit settings made during the kernel build or they were set somewhere long ago by some previous Arch default. In either case, if there were no issues, I wouldn't expect pacman to go out of its way to tell me about them if nothing needs to be done. Though I can also see the messages just being some default behavior of whatever the kernel sysctl hook is warning about choices that are explicitly set. Do I need to do anything about these? -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] No login after update
by Manuel Reimer 21 Aug '20

21 Aug '20

Hello, I know that Arch is not for the "average user" and some background knowledge is expected, but this was the first time I needed a boot stick since I think at least one year. Some minutes ago I did a regular system update and after that decided to reboot. After reboot I was unable to log into my system. After fiddling a bit I rebooted to an Arch boot stick to find the following message in pacman.log: [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login installed as /etc/pam.d/system-login.pacnew As this seemed to be a candidate that may cause login problems, I deleted "system-login" and moved the ".pacnew" into place. After reboot I'm now able to log in again... IMHO something like this should not happen... Maybe it's worth a note on the Arch homepage that it is important to move this pacnew into place before reboot? Manuel

11 24

Re: [arch-general] HP Laserjet plus 1020 Problem
by das 21 Aug '20

21 Aug '20

On Wed, Aug 19, 2020 at 7:04 PM Rafael Fontenelle <rafaelff(a)gnome.org> wrote: > Have you tried installing the "hplip" package, which provides PPD for > your printer? > > Installing removing reinstalling hplip -- nothing worked. Ok, as you suggest I will now explore the ArchWiki links you have provided. -- দাস das http://ddts.randomink.org/ -- দাশ das http://ddts.randomink.org/

7 18

[arch-general] netcl leaves network down until reenable performed - do we need note?
by David C. Rankin 21 Aug '20

21 Aug '20

Archdevs, I have two computers using netctl, one for a static and one for a dhcp address. After the last update on May, 3, netctl (1.22-1 -> 1.23-1) all remained fine and old profiles generated as subservices in /etc/systemd/system, such as: netctl\@rlf_network\\x2dstatic.service continued to bring the network up. However within the past week there was a change, likely to systemd 246, that no longer respects the subservices originally created by netctl. Now attempting at reboot causes the network to fail completely. Not good for remotely adminned boxes. What is required is a "reenable" of the netctl profile. Doing so will remove the old subservice and symlinks and replace then with a directory in /etc/systemd/system of same name as the old subservice, but with a ".d" appended that now contains a "profile.conf", e.g. netctl@rlf_network\x2dstatic.service.d/ └── profile.conf However, there is no note or warning during update that any manual intervention will be needed. That will leave anyone adminning a remote arch install with netctl with a box that is unreachable and has no network. Shouldn't there be a warning about this change generated on update? Arch is always pretty good about warning when manual interaction is required -- and this is a biggie. Couldn't there also be a post install that does a reenable for each netctl profile found in /etc/systemd/system as another option to avoid this SNAFU? -- David C. Rankin, J.D.,P.E.

4 5

[arch-general] Gaetan Bisson Resignation
by Amin Vakil 20 Aug '20

20 Aug '20

Hello, I'm not an Arch Linux Developer myself, so I'm not allowed to reply to this email on arch-dev-public. But just out of curiosity and to learn something, would you care to share with us what majority's views is in conflict with your views? Best Regards, Amin Vakil On 8/20/20 3:13 AM, Gaetan Bisson via arch-dev-public wrote: > Dear all, > > I've joined the Arch team in 2010 and spent a decade as a developer; > it's been a great privilege to be a part of such an awesome community > and also a lot of fun. However I felt the ten-year mark was a good > opportunity for me to move on since I recognize the majority's views on > the future of the distro have of late steadily been diverging from mine. > > And thus I hereby resign my position of Arch Linux Developer. > > All the best in your future endeavors! >

2 1