Re: [arch-general] Issue linking 32-bit GAS assembly
On Wed, Oct 17, 2018 at 08:14:48PM -0700, Anatol Pomozov via arch-general wrote: > Hello > On Wed, Oct 17, 2018 at 12:37 PM Dutch Ingraham wrote: > > > > Hi all: > > > > I'm having a problem linking 32-bit GAS assembly code that references > > external > > C libraries on an up-to-date 64-bit Arch installation. > > > > I have enabled the 32-bit repositories and installed the multilib-devel > > group > > and lib32-glibc. I have updated the library cache with ldconfig and > > rebooted. > > > > The command to assemble is: . Assembly > > succeeds. > > > > However, when linking using the command > > > filename.o> > > > > the command fails with: > > ld: skipping incompatible /usr/lib/libc.so when searching for -lc > > ld: skipping incompatible /usr/lib/libc.a when searching for -lc > > ld: cannot find -lc > > > > Note this linker command (or a hierarchy-appropriate one) seems standard, > > and > > succeeds on a 64-bit Debian OS. > > > > There is a fairly recent Forum question (but pre-dating the discontinuance > > of > > i686 support) regarding the same issue at > > https://bbs.archlinux.org/viewtopic.php?id=229235 which indicates the > > command > > should be: > > > > > filename filename.o -lc> > > > > This command succeeds, insofar as the linker returns an exit code of 0. > > However, > > running the program (and all other similar programs) fails with "Illegal > > instruction (core dumped)." Assembling with debugging symbols and running a > > backtrace didn't enlighten me. > > > > Note that changing /lib/ld-linux to /usr/lib32/ld-linux in the command > > immediately > > above produces the same result, as confirmed by the output of > > > > Anyone see something I've missed of have any suggestions? Thanks. > > > > > > --- > > > > Here is some simple code to test with: > > > > > > # paramtest2.s - Listing system environment variables > > .section .data > > output: > >.asciz "%s\n" > > .section .text > > .globl _start > > _start: > >movl %esp, %ebp > >addl $12, %ebp > > loop1: > >cmpl $0, (%ebp) > >je endit > >pushl (%ebp) > >pushl $output > >call printf > >addl $12, %esp > >addl $4, %ebp > >loop loop1 > > endit: > >pushl $0 > >call exit > > > Here is what I ran to make your example working on my Arch Linux machine > > > sudo pacman -S lib32-glibc > as --32 -o asm.o asm.s > ld -melf_i386 --dynamic-linker /lib/ld-linux.so.2 -L/usr/lib32 -lc -o asm > asm.o > ./asm > > > The only difference that I specified -L (library search path) to make > sure the linked can find 32-bit version of libc. Hi Anatol: I was able assemble and link with gcc, then look at the library paths used with ldd. Actually, your command is the same as the command above, minus the 'shared' option, from the Forum post. That command was core dumping for me; not sure how it was working for them. Thanks for your help; your command works fine.
Re: [arch-general] Issue linking 32-bit GAS assembly
On Wed, Oct 17, 2018 at 11:07:02PM +0200, Maarten de Vries via arch-general wrote: > Why not let gcc take care of what compiler/assembler and linker to invoke > with which precise flags: > > $ gcc -m32 -o foo filename.s > $ ./foo # great success! > > It will probably link to libc without you even asking for it. And if that > works and you really want to know what linker flags you need, you can add -v > to make gcc spam you about it. > GCC will handle some files, but not others. In this case, I get garbage output then a segfault/core dump. Using -nostdlib and -static also fail to build, but I have had success with just using I would, however, like to know how to use as/ld on Arch, as it is my main OS. > > -- Maarten > > (Sent off-list by accident before, sending to the list now.) > > > On 10/17/18 9:36 PM, Dutch Ingraham wrote: > > Hi all: > > > > I'm having a problem linking 32-bit GAS assembly code that references > > external > > C libraries on an up-to-date 64-bit Arch installation. > > > > I have enabled the 32-bit repositories and installed the multilib-devel > > group > > and lib32-glibc. I have updated the library cache with ldconfig and > > rebooted. > > > > The command to assemble is: . Assembly > > succeeds. > > > > However, when linking using the command > > > filename.o> > > > > the command fails with: > > ld: skipping incompatible /usr/lib/libc.so when searching for -lc > > ld: skipping incompatible /usr/lib/libc.a when searching for -lc > > ld: cannot find -lc > > > > Note this linker command (or a hierarchy-appropriate one) seems standard, > > and > > succeeds on a 64-bit Debian OS. > > > > There is a fairly recent Forum question (but pre-dating the discontinuance > > of > > i686 support) regarding the same issue at > > https://bbs.archlinux.org/viewtopic.php?id=229235 which indicates the > > command > > should be: > > > > > filename filename.o -lc> > > > > This command succeeds, insofar as the linker returns an exit code of 0. > > However, > > running the program (and all other similar programs) fails with "Illegal > > instruction (core dumped)." Assembling with debugging symbols and running a > > backtrace didn't enlighten me. > > > > Note that changing /lib/ld-linux to /usr/lib32/ld-linux in the command > > immediately > > above produces the same result, as confirmed by the output of > > > > Anyone see something I've missed of have any suggestions? Thanks. > > > > > > --- > > > > Here is some simple code to test with: > > > > > > # paramtest2.s - Listing system environment variables > > .section .data > > output: > > .asciz "%s\n" > > .section .text > > .globl _start > > _start: > > movl %esp, %ebp > > addl $12, %ebp > > loop1: > > cmpl $0, (%ebp) > > je endit > > pushl (%ebp) > > pushl $output > > call printf > > addl $12, %esp > > addl $4, %ebp > > loop loop1 > > endit: > > pushl $0 > > call exit
Re: [arch-general] Issue linking 32-bit GAS assembly
On Wed, Oct 17, 2018 at 10:59:07PM +0200, Andy Pieters wrote: > On Wed, Oct 17, 2018 at 9:37 PM Dutch Ingraham wrote: > > > > Hi all: > > > > I'm having a problem linking 32-bit GAS assembly code that references > > external > > C libraries on an up-to-date 64-bit Arch installation. > > > > I have enabled the 32-bit repositories and installed the multilib-devel > > group > > and lib32-glibc. I have updated the library cache with ldconfig and > > rebooted. > > > > The command to assemble is: . Assembly > > succeeds. > > > > However, when linking using the command > > > filename.o> > > > > the command fails with: > > ld: skipping incompatible /usr/lib/libc.so when searching for -lc > > ld: skipping incompatible /usr/lib/libc.a when searching for -lc > > ld: cannot find -lc > > > > Note this linker command (or a hierarchy-appropriate one) seems standard, > > and > > succeeds on a 64-bit Debian OS. > > > > There is a fairly recent Forum question (but pre-dating the discontinuance > > of > > i686 support) regarding the same issue at > > https://bbs.archlinux.org/viewtopic.php?id=229235 which indicates the > > command > > should be: > > > > > filename filename.o -lc> > > > > This command succeeds, insofar as the linker returns an exit code of 0. > > However, > > running the program (and all other similar programs) fails with "Illegal > > instruction (core dumped)." Assembling with debugging symbols and running a > > backtrace didn't enlighten me. > > > > Note that changing /lib/ld-linux to /usr/lib32/ld-linux in the command > > immediately > > above produces the same result, as confirmed by the output of > > > > Anyone see something I've missed of have any suggestions? Thanks. > > > > > > --- > > > > Here is some simple code to test with: > > > > > > # paramtest2.s - Listing system environment variables > > .section .data > > output: > >.asciz "%s\n" > > .section .text > > .globl _start > > _start: > >movl %esp, %ebp > >addl $12, %ebp > > loop1: > >cmpl $0, (%ebp) > >je endit > >pushl (%ebp) > >pushl $output > >call printf > >addl $12, %esp > >addl $4, %ebp > >loop loop1 > > endit: > >pushl $0 > >call exit > > Silly question perhaps but does that file actually exist, > /lib32/ld-linux.so.2? > > I haven't set up 32 bit etc and that file doesn't exist on my machine, > and I get the exact same errors as you. No, but /usr/lib32/ld-linux.so.2 does, as a symlink to ld-2.28.so. As noted, I've tried that as well, with the same results.
[arch-general] Issue linking 32-bit GAS assembly
Hi all: I'm having a problem linking 32-bit GAS assembly code that references external C libraries on an up-to-date 64-bit Arch installation. I have enabled the 32-bit repositories and installed the multilib-devel group and lib32-glibc. I have updated the library cache with ldconfig and rebooted. The command to assemble is: . Assembly succeeds. However, when linking using the command the command fails with: ld: skipping incompatible /usr/lib/libc.so when searching for -lc ld: skipping incompatible /usr/lib/libc.a when searching for -lc ld: cannot find -lc Note this linker command (or a hierarchy-appropriate one) seems standard, and succeeds on a 64-bit Debian OS. There is a fairly recent Forum question (but pre-dating the discontinuance of i686 support) regarding the same issue at https://bbs.archlinux.org/viewtopic.php?id=229235 which indicates the command should be: This command succeeds, insofar as the linker returns an exit code of 0. However, running the program (and all other similar programs) fails with "Illegal instruction (core dumped)." Assembling with debugging symbols and running a backtrace didn't enlighten me. Note that changing /lib/ld-linux to /usr/lib32/ld-linux in the command immediately above produces the same result, as confirmed by the output of Anyone see something I've missed of have any suggestions? Thanks. --- Here is some simple code to test with: # paramtest2.s - Listing system environment variables .section .data output: .asciz "%s\n" .section .text .globl _start _start: movl %esp, %ebp addl $12, %ebp loop1: cmpl $0, (%ebp) je endit pushl (%ebp) pushl $output call printf addl $12, %esp addl $4, %ebp loop loop1 endit: pushl $0 call exit
Re: [arch-general] Intel microcode - latest version not loading
On Fri, Mar 02, 2018 at 08:10:45PM +, Mike Cloaked via arch-general wrote: > There is a newer version of that file dated February 26th but I can't > remember where I downloaded it from. > > I've put it at > https://filebin.net/q3s5in117kp7mkut/microcode-update-guidance.pdf if you > want to see it. Thanks - I'll take a look.
Re: [arch-general] Intel microcode - latest version not loading
On Thu, Mar 01, 2018 at 08:13:08PM +0100, ProgAndy wrote: > Am 01.03.2018 um 00:41 schrieb Dutch Ingraham: > > On Wed, Feb 28, 2018 at 04:54:03PM -0600, Doug Newgard via arch-general > > wrote: > > > On Wed, 28 Feb 2018 12:43:26 -0600 > > > Dutch Ingraham wrote: > > > > > > > On Wed, Feb 28, 2018 at 11:50:09AM -0600, Doug Newgard via arch-general > > > > wrote: > > > > > You're looking at the dates that the last *bundle* was released. That > > > > > says > > > > > nothing about what firmware is available for your processor. Your > > > > > microcode was > > > > > "updated early", so it is being loaded just fine. > > > > > > > > > > Scimmia > > > > Thanks, Scimmia. I had considered that, but thought that would have > > > > been spelled-out somewhere on Intel's site and didn't want to just > > > > assume. So, how does one determine what files are on the .img? > > > The img file can be extracted with bsdtar. iucode_tool in the AUR used for > > > working with the intel bin file inside of that .img file. It can list, > > > extract, > > > search, and more. There's even an example on the Microcode wiki page. > > > > Did you just add that wiki page information?? (I'm just kidding, of > > course.) Totally missed it - thanks for the info! > > In February Intel also released a PDF with available and planned microcode > updates. The original now asks for a login, but this is a mirror: > > http://www-pc.uni-regensburg.de/systemsw/security/microcode-update-guidance_02122018.pdf > > > Original location: > https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf That's excellent information. Apparently, my 8 year old Core2 may soon be getting its first MCU!
Re: [arch-general] Intel microcode - latest version not loading
On Wed, Feb 28, 2018 at 04:54:03PM -0600, Doug Newgard via arch-general wrote: > On Wed, 28 Feb 2018 12:43:26 -0600 > Dutch Ingraham wrote: > > > On Wed, Feb 28, 2018 at 11:50:09AM -0600, Doug Newgard via arch-general > > wrote: > > > You're looking at the dates that the last *bundle* was released. That says > > > nothing about what firmware is available for your processor. Your > > > microcode was > > > "updated early", so it is being loaded just fine. > > > > > > Scimmia > > > > Thanks, Scimmia. I had considered that, but thought that would have > > been spelled-out somewhere on Intel's site and didn't want to just > > assume. So, how does one determine what files are on the .img? > > The img file can be extracted with bsdtar. iucode_tool in the AUR used for > working with the intel bin file inside of that .img file. It can list, > extract, > search, and more. There's even an example on the Microcode wiki page. Did you just add that wiki page information?? (I'm just kidding, of course.) Totally missed it - thanks for the info!
Re: [arch-general] Intel microcode - latest version not loading
On Wed, Feb 28, 2018 at 11:50:09AM -0600, Doug Newgard via arch-general wrote: > On Wed, 28 Feb 2018 11:46:23 -0600 > Dutch Ingraham wrote: > > > Hi all: > > > > I'm having an issue with Intel microcode loading. Specifically, the > > microcode > > does not appear to be loading the latest version: > > > > ~ $ dmesg | grep microcode > > [0.00] microcode: microcode updated early to revision 0x19, date = > > 2013-06-21 > > [0.931272] microcode: sig=0x106a5, pf=0x2, revision=0x19 > > [0.931319] microcode: Microcode Update Driver: v2.2. > > > > > > My processor is: > > > > ~ $ grep -E 'family|model|stepping' -m 4 /proc/cpuinfo > > cpu family : 6 > > model : 26 > > model name : Intel(R) Xeon(R) CPU W3503 @ 2.40GHz > > stepping: 5 > > > > The Intel website indicates the latest version of microcode for this > > processor > > is version 20171117 [1]. However, as indicated above, the version loaded at > > boot is dated 2013-06-21. > > > > I have the latest stable version of intel-ucode installed: > > > > ~ $ pacman -Q intel-ucode > > intel-ucode 20180108-1 > > > > I have updated GRUB with , and > > rebooted. > > The grub.cfg file shows, as the last line in the menuentry: > > 'initrd /boot/intel-ucode.img /boot/initramfs-linux.img' > > > > I am using a stock kernel: > > > > ~ $ uname -a > > Linux arch2 4.15.5-1-ARCH #1 SMP PREEMPT Thu Feb 22 22:15:20 UTC 2018 > > x86_64 GNU/Linux > > > > > > Can someone help me determine what is going on here? > > > > > > [1] > > https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?product=40799 > > You're looking at the dates that the last *bundle* was released. That says > nothing about what firmware is available for your processor. Your microcode > was > "updated early", so it is being loaded just fine. > > Scimmia Thanks, Scimmia. I had considered that, but thought that would have been spelled-out somewhere on Intel's site and didn't want to just assume. So, how does one determine what files are on the .img?
[arch-general] Intel microcode - latest version not loading
Hi all: I'm having an issue with Intel microcode loading. Specifically, the microcode does not appear to be loading the latest version: ~ $ dmesg | grep microcode [0.00] microcode: microcode updated early to revision 0x19, date = 2013-06-21 [0.931272] microcode: sig=0x106a5, pf=0x2, revision=0x19 [0.931319] microcode: Microcode Update Driver: v2.2. My processor is: ~ $ grep -E 'family|model|stepping' -m 4 /proc/cpuinfo cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU W3503 @ 2.40GHz stepping: 5 The Intel website indicates the latest version of microcode for this processor is version 20171117 [1]. However, as indicated above, the version loaded at boot is dated 2013-06-21. I have the latest stable version of intel-ucode installed: ~ $ pacman -Q intel-ucode intel-ucode 20180108-1 I have updated GRUB with , and rebooted. The grub.cfg file shows, as the last line in the menuentry: 'initrd /boot/intel-ucode.img /boot/initramfs-linux.img' I am using a stock kernel: ~ $ uname -a Linux arch2 4.15.5-1-ARCH #1 SMP PREEMPT Thu Feb 22 22:15:20 UTC 2018 x86_64 GNU/Linux Can someone help me determine what is going on here? [1] https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?product=40799
Re: [arch-general] Thank you for keeping 32 bit alive
On Thu, Oct 12, 2017 at 04:09:06PM -0400, theodore.preunin...@lycos.com wrote: > The current issue of Distro Watch Weekly has some topics including if 32-bit > prematurely obsoleted or not. > > http://distrowatch.com/weekly.php?issue=20171009 > > Since I can not offer any money or time to assist you at this time, thank > you for keeping 32 bit alive. The news item dated Jan. 25, 2017 may be of interest to you.
Re: [arch-general] system crashes when starting network connection
On Tue, Oct 18, 2016 at 10:16:26PM +0200, sivmu wrote: > After upgrading the kernel to 4.7.8 today the issue did not occur again. What repo did you find that kernel in?
Re: [arch-general] .xsession-errors - can't startx with that file
On Sun, Sep 18, 2016 at 10:14:35AM -0500, Doug Newgard wrote: > On Sun, 18 Sep 2016 09:47:57 -0500 > Dutch Ingraham wrote: > > > On Sun, Sep 18, 2016 at 09:23:01AM -0500, Doug Newgard wrote: > > > On Sun, 18 Sep 2016 09:11:45 -0500 > > > Dutch Ingraham wrote: > > > > > > > Hello all: > > > > > > > > TL;DR: One Arch installation will allow redirecting startx's stderr to > > > > a file, one won't. What is the difference between systems? > > > > > > > > > > Is X running as root or as the user (rootless)? This can change based on > > > configuration and on drivers used. > > > > Excellent question - how is this conclusively determined? Note I have > > taken no > > explicit action either way, i.e., to enable rootlessness or not. > > > > Looking at the xorg wiki, it appears as though 3 conditions are necessary > > for > > running "rootless": > > > > 1. systemd >= 216; OK, I'm at 231 on both machines; > > 2. start X via xinit; OK, I'm using xinit through startx, not a display > > manager; > > 3. if I can summarize, if using a proprietary display driver, such as > > Catalyst > > or Nvidia, need to take an extra step to run rootless; *this may be the > > issue.* > > > > On the machine where redirection works, I am using the nvidia proprietary > > driver; on the machine where the error occurs, I am using the xf-video-ati > > driver. > > > > So, unless I have step 3 above backwards (which is entirely possible), the > > question is how to redirect stderr when running rootless? (If I am in fact > > misunderstanding, please explain so a moron like me can understand!) > > > > Thanks for your help. > > rooted vs rootless does look like one difference between the systems. Next, I > would enable rooted X on the problem machine and see if it works. If it does, > we know we've narrowed down the issue. Bingo. Created the Xwrapper.config file with the line "needs_root_rights = yes" and I can now startx and redirect stderr. To get back the rootless operation, I then backed that file out and appended, to ~/.xserverrc, "vt$XDG_VTNR -keeptty." This seems to be working at this point. (Note I had, some days ago, appended the "vt$XDG_VTNR" to the .xserverrc, but that alone doesn't work. Need the -keeptty.) Thanks for your help.
Re: [arch-general] .xsession-errors - can't startx with that file
On Sun, Sep 18, 2016 at 04:29:47PM +0200, Ralf Mardorf wrote: > On Sun, 18 Sep 2016 16:24:12 +0200, Ralf Mardorf wrote: > >On Sun, 18 Sep 2016 09:11:45 -0500, Dutch Ingraham wrote: > >>TL;DR: One Arch installation will allow redirecting startx's stderr to > >>a file, one won't. What is the difference between systems? > > > >Hi, > > > >what actually was too long to read? > > > >Did you for testing purpose install a display manger, e.g. lightdm? > >Does lightdm or any other DM also not provide the wanted output? If so, > >what does the display manager's log file in /var provide? > > Pardon, your mal was TL;DR, my bad, ok, .xsession-errors is used, here > is output, however, what is mentioned by "Please also check the log file > at "/home/dutch/.local/share/xorg/Xorg.0.log" for additional > information"? Sorry, I should have included information on that; there are no errors at all noted in the xorg.log.
Re: [arch-general] .xsession-errors - can't startx with that file
On Sun, Sep 18, 2016 at 04:24:12PM +0200, Ralf Mardorf wrote: > On Sun, 18 Sep 2016 09:11:45 -0500, Dutch Ingraham wrote: > >TL;DR: One Arch installation will allow redirecting startx's stderr to > >a file, one won't. What is the difference between systems? > > Hi, > > what actually was too long to read? > > Did you for testing purpose install a display manger, e.g. lightdm? > Does lightdm or any other DM also not provide the wanted output? If so, > what does the display manager's log file in /var provide? > > Regards, > Ralf Thanks for your response. I do have sddm installed, as it came along with the Plasma goo, but it is disabled as I never use a display manager. I could enable it for testing purposes, though, if other testing does not pan out (see other responses in this thread.) Thanks again.
Re: [arch-general] .xsession-errors - can't startx with that file
On Sun, Sep 18, 2016 at 09:23:01AM -0500, Doug Newgard wrote: > On Sun, 18 Sep 2016 09:11:45 -0500 > Dutch Ingraham wrote: > > > Hello all: > > > > TL;DR: One Arch installation will allow redirecting startx's stderr to > > a file, one won't. What is the difference between systems? > > > > Is X running as root or as the user (rootless)? This can change based on > configuration and on drivers used. Excellent question - how is this conclusively determined? Note I have taken no explicit action either way, i.e., to enable rootlessness or not. Looking at the xorg wiki, it appears as though 3 conditions are necessary for running "rootless": 1. systemd >= 216; OK, I'm at 231 on both machines; 2. start X via xinit; OK, I'm using xinit through startx, not a display manager; 3. if I can summarize, if using a proprietary display driver, such as Catalyst or Nvidia, need to take an extra step to run rootless; *this may be the issue.* On the machine where redirection works, I am using the nvidia proprietary driver; on the machine where the error occurs, I am using the xf-video-ati driver. So, unless I have step 3 above backwards (which is entirely possible), the question is how to redirect stderr when running rootless? (If I am in fact misunderstanding, please explain so a moron like me can understand!) Thanks for your help.
[arch-general] .xsession-errors - can't startx with that file
Hello all: TL;DR: One Arch installation will allow redirecting startx's stderr to a file, one won't. What is the difference between systems? I am having an issue with logging xsession errors. Specifically, if I create an .xsession-errors file in /home/user, then startx with < /home/user/.xsession-errors>>, startx will write to the file, but otherwise error-out and not actually start X. The error, in its entirety, is: "X.Org X Server 1.18.4 Release Date: 2016-07-19 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.5.4-1-ARCH x86_64 Current Operating System: Linux archlinux 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=763598c6-08b4-44d9-9b21-d4dbd558b107 rw Build Date: 19 July 2016 05:54:24PM Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/dutch/.local/share/xorg/Xorg.0.log", Time: Sat Sep 17 20:01:10 2016 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) xf86OpenConsole: Cannot open virtual console 1 (Permission denied) (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/dutch/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error" For the correctness of the specific incantation < /home/user/.xsession-errors>>, see these [1][2] threads. In addition, that command works on any number of other distros (Fedora, Gentoo, etc., and even OpenBSD). But here is the real kicker - I have another computer with a very similar Arch installation, i.e., x86_64, fully up-to-date, "full" KDE and other window managers installed, using identical (actually copied from machine-to-machine) .xinitrc files. The above error only happens on one machine, and happens regardless of whether I am trying to start Plasma or just DWM, Awesome, i3, or whatever. Searching for that specific error does return a few hits [3][4], but none of those issues/remedies are similar to mine. Any ideas on how I can determine the differences between the two Arch installations that are causing only one to error-out when redirecting stderr to a file? [1] https://bbs.archlinux.org/viewtopic.php?id=143068 [2] https://www.linuxquestions.org/questions/slackware-14/where-is-~- xsession-errors-log-867498/ [3] https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1562219 [4] https://bbs.archlinux.org/viewtopic.php?id=192329
Re: [arch-general] Mutt Compile-time Configuration
On Sat, Aug 20, 2016 at 02:09:47AM +0200, Thibaut Marty wrote: > On Sat, Aug 20, 2016 at 01:39:28AM +0200, Bruno Pagani wrote: > > I think that the packager just didn’t see this addition and only bounced > > the pkgver. There is an open ticket about this: > > https://bugs.archlinux.org/task/50445. > Thanks, Bruno - you're probably right. > This would be surprising, as the new compile-time option was explicitly > given in the release announce mail. Does that mean the packager did not > subscribe to the very low-traffic mutt announce list or did not read it > before updating the package? > However, the UPDATING file does not mention the new option. Well, the maintainer just enabled it in an updated package, so all's moot at this point. In fact, I was in the middle of adding a comment to the feature request regarding updating the wiki when the ticket was closed and blew away my comment. Hopefully someone will get to it. Thanks both for your replies!
[arch-general] Mutt Compile-time Configuration
Hello all: Mutt 1.7.0 was just released.[1] One new feature is the sidebar, which up to now required a patched version of mutt from the AUR. However, it is a compile-time option and it appears as though the Arch packager has decided to not enable it (my muttrc will throw an error if I try and configure the sidebar.) Can someone more familiar than myself explain why a packager would decide to do this? In other words, what are the general considerations for including certain options at compile-time? (In this particular case, the sidebar would not be turned on until configured in the muttrc, so compiling the option into the package would not affect those who do not want it.) Thanks for your replies. [1]https://marc.info/?l=mutt-users&m=147154326009383
Re: [arch-general] very out of date packages
On Sun, Aug 14, 2016 at 03:19:29PM -0400, Ido Rosen wrote: > On Sun, Aug 14, 2016 at 3:14 PM, Ido Rosen wrote: > > Although, it's worth noting, 220/14800 (<2%) of out of date packages at any > given time (and <0.2% badly out of date) isn't that bad... I would argue it is not the raw number or percentage of packages that are out of date, but *which* packages are out of date. For example, I wouldn't place equal weight on pychess as I would glibc.
Re: [arch-general] Chromium Favorites Bar Partially Inoperative
On Mon, Feb 01, 2016 at 11:34:37AM +0100, Martin S. Weber wrote: > On 2016-01-31 18:11:24, Dutch Ingraham wrote: > > (...) > > confirm chrome on awesome "right" (or 2ndary) monitor problems: This is > an awesome + multi-monitor + chromium problem, not your graphics driver. > > folders in the bookmark bar do not track "pressed" status or track the > mouse at all. > > I believe it's more of awesome + some dirty stuff chromium does that it > gets away in most other window managers because those aren't as awesome > as awesome is awesome. > Thanks, Martin, for the confirmation. I now also now agree that the source of the problem is likely not the driver but "an awesome + multi-monitor + chromium problem." I've had the chance to set up a similar situation on a different computer running OpenBSD, which uses a different driver and the problem exists there as well.
Re: [arch-general] Chromium Favorites Bar Partially Inoperative
On Sun, Jan 31, 2016 at 11:08:16PM +0100, Damjan Georgievski wrote: > > I just installed Chromium, v. 48.0.2564.97, two days ago. I imported > > my bookmarks from Firefox and enabled the bookmarks bar. I added a few > > new bookmarks to the bar, but not in my existing folders. > > > > Today, I tried to drag-and-drop the bookmarks into the folders on my > > bookmarks bar, but nothing happened - the bookmarks just remained on > > the bar. In addition, it seems impossible to move anything on the bar, > > i.e., adjusting the order of folders or bookmarks. Everything just stays > > where it was originally placed. > > > > For those who don't use Chromium, this is not normal behavior - one should > > be able to drag-and-drop into folders, subfolders, and slide things > > around at will. > > > > In fact, even in the bookmark manager it is not possible to drag-and-drop; > > the only way I've found to move a bookmark into a folder is to copy and > > paste it there, then delete the original. > > > > I've tried disabling my two extensions without luck, and I see no > > recent activity on the boards or on Chromium's bug tracker. > > > > Anyone else seeing this? Any suggestions? > > huh. > possibly unreleated but I just experienced that drag&drop from dolphin > to a html5 drop-zone doesn't work either. > it even doesn't work from a directory view in chromium itself to a > html5 page in chromium. Thanks Damjan, but unfortunately I don't think it is related. Actually, this is getting interesting. First, this is related to Chromium, as Firefox does not exhibit this behavior. Second, I decided to test the issue with KDE, DWM, and Awesome (Awesome is what I was using when I first noticed the issue.) The problem does not exist with KDE or DWM - only Awesome. Third, and this is the really interesting part, the problem only exists on my right monitor; if I open Chromium on my left monitor, the bookmarks work as expected. In fact, I can even drag a running instance of Chromium from the right monitor, where the bookmarks are not working properly, to the left monitor and they begin working! I'm using the [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] card and the xf86-video-ati driver. I've tried starting X with and without an xrandr script, but it makes no difference. I've also looked at the Arch ATI wiki and tried some tweaks to my 20-radeon.conf, without success. I think this is most likely a driver issue than an Awesome/Chromium issue; they are likely just exposing some underlying driver quirk. Does anyone have any diagnostic/other hints?
[arch-general] Chromium Favorites Bar Partially Inoperative
Hello all: I just installed Chromium, v. 48.0.2564.97, two days ago. I imported my bookmarks from Firefox and enabled the bookmarks bar. I added a few new bookmarks to the bar, but not in my existing folders. Today, I tried to drag-and-drop the bookmarks into the folders on my bookmarks bar, but nothing happened - the bookmarks just remained on the bar. In addition, it seems impossible to move anything on the bar, i.e., adjusting the order of folders or bookmarks. Everything just stays where it was originally placed. For those who don't use Chromium, this is not normal behavior - one should be able to drag-and-drop into folders, subfolders, and slide things around at will. In fact, even in the bookmark manager it is not possible to drag-and-drop; the only way I've found to move a bookmark into a folder is to copy and paste it there, then delete the original. I've tried disabling my two extensions without luck, and I see no recent activity on the boards or on Chromium's bug tracker. Anyone else seeing this? Any suggestions?
Re: [arch-general] Firefox without signature checking
On Sat, Jan 02, 2016 at 09:01:10PM +, Emil Lundberg wrote: > > If that is Mozilla's plan, I will most definitely use or make an > alternative package. I use Pentadactyl, which is currently unsigned, and I > will not switch away from it anytime soon. I agree that an alternative > package would probably belong in the AUR, at least for starters. > > > As to the future of Pentadactyl: https://github.com/5digits/dactyl/issues/99
Re: [arch-general] Blue/Black Screen of Death with Plasma5
On Mon, Oct 19, 2015 at 09:25:45AM +0530, Bhushan Shah wrote: > Hi, > > On Mon, Oct 19, 2015 at 4:45 AM, Dutch Ingraham wrote: > > The backstory: I bought a new el-cheapo multi-function printer-scanner > > today and as a consequence installed sane, xsane, and > > kdegraphics-ksaneplugin. I did all that while logged into my usual > > window manager, dwm. All was fine. > > > > Then I wanted to try the kde plugin, so logged into kde desktop and was > > presented with what appeared to be the blue screen of death (sometimes > > black). Plasma seems to start fine, i.e., splash screen goes through > > its usual motions, then the blue/black screen appears when the desktop > > usually does. > > Can you kill plasmashell and start it again from the terminal, and > provide output? > > i.e from krunner (alt+f2) open konsole, killall plasmashell && plasmashell > > -- > Bhushan Shah > > http://bhush9.github.io > IRC Nick : bshah on Freenode Thanks, everybody. Since everyone's questions, and the answers, all are related, I'll respond to Marshall, Bhushan, and Ralf all in this response: I've killed and restarted plasmashell and here is the output: ~ $ killall plasmashell && plasmashell kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR" kscreen: Primary output changed from KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) to KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability last screen is < 0 so putting containment on screen 0 kscreen: Launcher finished with exit code 1 , status 0 kscreen: Service for requested backend already running Plasma Shell startup completed kscreen: Primary output changed from KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) to KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) I don't normally have an .xsession-errors file, but I created one and here is the output from starting a session: X.Org X Server 1.17.2 Release Date: 2015-06-16 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.0.4-2-ARCH x86_64 Current Operating System: Linux arch 4.2.3-1-ARCH #1 SMP PREEMPT Sat Oct 3 18:52:50 CEST 2015 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=f72c94ff-cf1f-42dd-9d10-ab716a64b067 rw Build Date: 17 July 2015 05:38:19PM Current version of pixman: 0.32.8 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 19 08:37:59 2015 (==) Using system config directory "/usr/share/X11/xorg.conf.d" Loading stage "initial" 1187 startkde: Starting up... Service started, version: 6.2.0 kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR" Service started, version: 6.2.0 kscreen: Launcher finished with exit code 1 , status 0 kscreen: Service for requested backend already running kscreen: Primary output changed from KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) to KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability unversioned plugin detected, may result in instability last screen is < 0 so putting containment on screen 0 Plasma Shell startup completed kscreen: Primary output changed from KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) to KScreen::Output(Id: 587 , Name: "DVI-I-2" ) ( "DVI-I-2" ) I/O warning : failed to load external entity "/home/dutch/.qalculate/eurofxref-daily.xml" I/O warning : failed to load external entity "/home/dutch/.qalculate/eurofxref-daily.xml" The only recent plugin installed was the aforementioned kdegraphics-ksaneplugin; after removing that plugin, the output to .xsession-errors is the same. Any thoughts?
[arch-general] Blue/Black Screen of Death with Plasma5
Hi folks- The backstory: I bought a new el-cheapo multi-function printer-scanner today and as a consequence installed sane, xsane, and kdegraphics-ksaneplugin. I did all that while logged into my usual window manager, dwm. All was fine. Then I wanted to try the kde plugin, so logged into kde desktop and was presented with what appeared to be the blue screen of death (sometimes black). Plasma seems to start fine, i.e., splash screen goes through its usual motions, then the blue/black screen appears when the desktop usually does. However, not was all as it seemed. The entire kde suite works, i.e., mouse and keyboard, and most, but not all, applications (although to access them I need to alt-F2 and run them manually.) The only thing that does not seem to work is the desktop itself. I cannot say the packages I installed today are the cause - it could be any update within the last two weeks; as noted, I rarely log into the kde desktop. My uname -a is: Linux arch 4.2.3-1-ARCH #1 SMP PREEMPT Sat Oct 3 18:52:50 CEST 2015 x86_64 GNU/Linux My desktop is: plasma-desktop-5.4.2-1 As you can imagine, there are no shortage of google results regarding the blue/black screen. However, there was nothing current enough or otherwise useful. [1][2][3] Here's what I've tried so far, in no particular order: 1. removed kdegraphics-ksaneplugin; 2. re-installed plasma-desktop; 3. downgraded kactivities-frameworks; 4. removed ~/.kde and /tmp/kde-dutch. Logs don't show anything of importance (as I would expect, as Xorg starts and runs properly.) Top shows kwrapper5, dbus, polkit, kdeinit5, klauncher, kded5, kactivitymanager, etc., all running. Any suggestions are greatly appreciated; If further information is needed, please let me know. [1] https://bbs.archlinux.org/viewtopic.php?id=143124 [2] https://forum.kde.org/viewtopic.php?f=67&t=118151 [3] https://bbs.archlinux.org/viewtopic.php?id=193286
