- Arch-general - lists.archlinux.org

[arch-general] conflict on /usr/bin generated by tigervnc?
by Javier 10 Sep '20

10 Sep '20

Hi ! On Today's upgrade: % pacman -Syu :: Synchronizing package databases... ... Packages (9) ... tigervnc-1.11.0-1 ... ... tigervnc-1.11.0-1-x86_64 131.3 MiB 3.51 MiB/s 00:37 [########################################################] 100% (9/9) checking keys in keyring [########################################################] 100% (9/9) checking package integrity [########################################################] 100% (9/9) loading package files [########################################################] 100% (9/9) checking for file conflicts [########################################################] 100% error: failed to commit transaction (conflicting files) tigervnc: /usr/sbin exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded. Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite? Thanks ! -- Javier

8 10

[arch-general] What companion SW to use with Trojitá to get integration and syncing of calendar (caldav) and contacts (carddav)
by Javier 08 Sep '20

08 Sep '20

I've been thinking on trying Trojitá as e-mail client, specially because it's GNUPG integration and support. However I understand it doesn't integrate neither synchronize with a calendar, neither it recognizes calendar invitations to integrate with a calendar, and I believe it doesn't support neither synchronize with remote contacts. I do depend on syncing with a remote caldav calendar, as well as with remote ics calendars for events like holidays, or astronomy calendars. And I also depend on syncing with a remote cardav contacts addressbook. I'm wondering if there is SW that can interact with Trojitá to get the needed functionality. Has anyone gotten such functionality using Trojitá? Which sw/applications? How? Thanks ! -- Javier

2 2

[arch-general] permission problems with brasero (cdrecord)
by Łukasz Michalski 07 Sep '20

07 Sep '20

Hi, Today I discovered that I cannot burn CD from iso image with brasero - it says I do not have requires permissions. My user is in "optical group". I finally resolved this problem by setting sticky bit on /bin/cdrecord and /bin/cdrdao. Is there a better solution? Here is interesting part of log from brasero run with --brasero-media-debug --brasero-burn-debug --brasero-utils-debug: BraseroBurn: (at burn-process.c:142) BraseroCDRecord got varg: BraseroBurn: (at burn-process.c:145) cdrecord BraseroBurn: (at burn-process.c:145) -v BraseroBurn: (at burn-process.c:145) dev=/dev/sr0 BraseroBurn: (at burn-process.c:145) gracetime=0 BraseroBurn: (at burn-process.c:145) speed=24 BraseroBurn: (at burn-process.c:145) driveropts=burnfree BraseroBurn: (at burn-process.c:145) fs=16m BraseroBurn: (at burn-process.c:145) -data BraseroBurn: (at burn-process.c:145) -nopad BraseroBurn: (at burn-process.c:145) /home/zork/Downloads/cd140201.iso BraseroBurn: (at burn-process.c:624) BraseroCDRecord Launching command BraseroBurn: (at burn-job.c:1309) BraseroCDRecord called brasero_job_get_fd_out BraseroBurn: (at burn-task.c:439) entering loop BraseroBurn: (at burn-process.c:415) BraseroCDRecord stdout: BraseroBurn: (at burn-job.c:1190) BraseroCDRecord called brasero_job_get_fd_in BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: No write mode specified. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stdout: BraseroBurn: (at burn-job.c:1309) BraseroCDRecord called brasero_job_get_fd_out BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Assuming -sao mode. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: If your drive does not accept -sao, try -tao. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Future versions of cdrecord may have different drive dependent defaults. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2). BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: WARNING: This causes a high risk for buffer underruns. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: WARNING: This causes a high risk for buffer underruns. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Insufficient 'file read' privileges. You will not be able to open all needed devices. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Insufficient 'file write' privileges. You will not be able to open all needed devices. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Insufficient 'device' privileges. You may not be able to send all needed SCSI commands, this my cause various unexplainable problems. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Insufficient 'memlock' privileges. You may get buffer underruns. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Insufficient 'priocntl' privileges. You may get buffer underruns. BraseroBurn: (at burn-job.c:1374) BraseroCDRecord called brasero_job_get_flags BraseroBurn: (at burn-process.c:415) BraseroCDRecord stderr: cdrecord: Insufficient 'network' privileges. You will not be able to do remote SCSI. Regards, Łukasz

2 1

[arch-general] brltty - Detected unsafe path transition /etc → /etc/brlapi.key Howto Fix?
by David C. Rankin 06 Sep '20

06 Sep '20

All, On system update, I get the following related to the brltty[1] package: (2/7) Creating temporary files... Detected unsafe path transition /etc → /etc/brlapi.key during canonicalization of /etc/brlapi.key. error: command failed to execute correctly Apparently this package was installed as a dependency of qemu. I generally do not want to ignore errors on update, so how do I fix this problem? The package was updated August 29, but the issue continues. Should I just delete the key and let qemu start over with a new one in a new location? Checked https://wiki.archlinux.org/index.php/QEMU, but nothing noted. [1] https://www.archlinux.org/packages/extra/x86_64/brltty/ -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] arch-general list down?
by David C. Rankin 06 Sep '20

06 Sep '20

All, I have no posts from arch-general since 8/30. I have tried to post related to a pacman update issue, but the posts are not getting though?? -- David C. Rankin, J.D.,P.E.

3 2

[arch-general] brltty - Detected unsafe path transition /etc → /etc/brlapi.key Howto Fix?
by David C. Rankin 03 Sep '20

03 Sep '20

All, On system update, I get the following related to the brltty[1] package: (2/7) Creating temporary files... Detected unsafe path transition /etc → /etc/brlapi.key during canonicalization of /etc/brlapi.key. error: command failed to execute correctly Apparently this package was installed as a dependency of qemu. I generally do not want to ignore errors on update, so how do I fix this problem? The package was updated August 29, but the issue continues. Should I just delete the key and let qemu start over with a new one in a new location? Checked https://wiki.archlinux.org/index.php/QEMU, but nothing noted. [1] https://www.archlinux.org/packages/extra/x86_64/brltty/ -- David C. Rankin, J.D.,P.E.

1 0

[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