SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
While trying to build packages in a chroot (both 64-current with multilib and a pure 32-current), make-4.1 segfaults. I've bind-mounted dev, proc and sys, and the chroots worked before upgrading them to their respective -current states. Even without an actual makefile to handle, make does segfault. Stracing it reveals that it tries to stat just about every node in /dev which neither the old make from 14.1 does inside the chroots, nor make-4.1 does outside chroot.
Recompiling make without stripping it gives the following backtrace:
Code:
#0 0x00007fb92905cff6 in strlen () from /lib64/libc.so.6
#1 0x00007fb92905cd0e in strdup () from /lib64/libc.so.6
#2 0x00000000004185b9 in xstrdup (ptr=ptr@entry=0x0) at misc.c:259
#3 0x000000000042356c in define_variable_in_set (name=name@entry=0x428e23 "MAKE_TERMOUT",
length=length@entry=12, value=0x0, origin=origin@entry=o_default, recursive=recursive@entry=0,
set=set@entry=0x635fc0 <global_variable_set>, flocp=0x0) at variable.c:243
#4 0x0000000000406f29 in main (argc=<optimized out>, argv=<optimized out>, envp=0x7ffeaacd8da8)
at main.c:1404
Looking at the code around main.c:1404 indicates that it tries to figure out if stdout and stderr is a tty, and exporting MAKE_TERMOUT and MAKE_TERMERR as empty strings makes make not segfault.
I'll report back and file a bug report with make after digging a litte more in the source, trying to figure out a proper patch.
UPDATE
The bug turns out to already have been reported twice, and was fixed in make-git292da6f6867b75a5af7ddbb639a1feae022f438f. Recompiling make-4.1 with the associated diff fixes the segfault.
Just thought I've give the heads up that support for the Sony DualShock 4 controllers is broken in the 4.4 (and probably several earlier) kernels, and is reported to have been fixed in 4.5.
newt has been updated to 0.52.19, thanks: that brings the support of --notags in whiptail's checklist and radiolist that was missing since a long time.
But still whiptail lacks the bidi patch that was removed in 0.52.1 for a reason specific to Fedora.
Still this patch IMHO brings the only feature of whiptail that lacks in dialog: ability to properly display messages in bidi languages like Arabic, Persian or Hebrew.
(This is almost entirely a bug fix release with important fixes to GATT, HoG, AVRCP & A2DP. It is recommended to upgrade if you were previously using 5.38)
In xf86-video-amdgpu-1.0.1 there's /usr/share/X11/xorg.conf.d/10-amdgpu.conf that uses Section "OutputClass" but according to "man amdgpu"it should use Section "Device".
Is there a reason for this?
I don't have the hardware so i can't test it myself.
There's also an new xf86-video-amdgpu-1.1 release. https://lists.x.org/archives/xorg-an...il/002686.html
Last edited by Nille_kungen; 04-07-2016 at 10:39 AM.
The new xf86-video-intel driver seems to cause some graphical glitches that weren't there before upgrading. Can anyone confirm this?
I'm using an i7-6700 with the HD 530 iGPU. I haven't overclocked my PC or anything.
I've tested the latest 4.4.6 Kernel and the 4.5.0 kernel from testing. Switching between those two kernels didn't change anything.
Attached below is a picture of the corruption.
Might it be related to glamor? I seen rendering errors like that with glamor on non intel hardware.
After checking the link provided by ppencho it seems that it's not related to glamor.
Last edited by Nille_kungen; 04-07-2016 at 10:45 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.