- Arch-general - lists.archlinux.org

[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

[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