August 2020 - Arch-general - lists.archlinux.org

[arch-general] Thunderbird 78
by Xorg 28 Nov '20

28 Nov '20

Hi, Thunderbird 78 is available since 1 month (https://www.thunderbird.net/en-US/thunderbird/78.0/releasenotes). Is there any reason the package is stuck to version 68? Can someone update this package? Thank in advance.

19 34

[arch-general] usbguard package neglected
by arch user 27 Oct '20

27 Oct '20

Hello, the package usbguard was flagged out of date in november. Three new versions came out since then. A package update or any info on this would be greatly appreciated. Kind regards

5 5

[arch-general] Packages "jami-gnome" and "libjamiclient" out of date
by Friedrich Strohmaier 24 Oct '20

24 Oct '20

Hi archers, Packages "jami-gnome" and "libjamiclient" are flagged out of date since 2019-11-16 / 2019-11-20. There are two new releases in place. I tried to contact the maintainer twice but nothing happened. I retrieved the maintainers (Bruno Pagani) mail adress from this mailinglist. I suspect the mails didn't ever get there. Any hints how to proceed? -- Friedrich

3 5

[arch-general] package pages link to github (which is partly broken)
by Marcus Hoffmann 19 Oct '20

19 Oct '20

Hi, I just noticed the package pages linking to github, instead of https://git.archlinux.org/. So far, trying to view the commit history for any community package just resulted in a page with the message: > Sorry, this commit history is taking too long to generate See, i.e. here: https://github.com/archlinux/svntogit-community/commits/master/element.io/t… I can find the package I'm interested in manually in https://git.archlinux.org/svntogit/community.git/ but is there a better solution for this planned somehow? Marcus

4 8

[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