From glen at delfi.ee Fri Sep 1 13:01:26 2017 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 1 Sep 2017 14:01:26 +0300 Subject: th-builders Message-ID: could please pld builders be fixed: [*th-x86_64:OK* *th-i686:?**th-x32:?*] pldth at ep09-pld SRPMS/.metadata$ pfa-signpkg test gitlab-ci-multi-runner-images-9.5.0-2.src.rpm.info gitlab-ci-multi-runner-9.5.0-2.src.rpm.info ERR: gitlab-ci-multi-runner-images-9.5.0-2 (buildid d6cc402e-a123-4ed3-8dc4-f210d69c3b00) building not finished ERR: gitlab-ci-multi-runner-9.5.0-2 (buildid b5206e61-770e-4ee7-892e-0174f491e673) building not finished Checking signatures of 5 files from 2 packages 5/0 /home/pld/admins/th/ftp/test/SRPMS/RPMS/gitlab-ci-multi-runner-9.5.0-2.src.rpm No files to sign can't even remove those (need only x86-64 build for these anyway): 13:51:44 [load: 0.30 5,00% nproc: 6] pldth at ep09-pld SRPMS/.metadata$ pfa-rmpkg test gitlab-ci-multi-runner-images-9.5.0-2.src.rpm.info gitlab-ci-multi-runner-9.5.0-2.src.rpm.info ERR: gitlab-ci-multi-runner-images-9.5.0-2 (buildid d6cc402e-a123-4ed3-8dc4-f210d69c3b00) building not finished ERR: gitlab-ci-multi-runner-9.5.0-2 (buildid b5206e61-770e-4ee7-892e-0174f491e673) building not finished 2 error(s) encountered... aborting 13:51:47 [load: 0.27 4,50% nproc: 6] pldth at ep09-pld SRPMS/.metadata$ From glen at pld-linux.org Tue Sep 5 05:37:20 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 5 Sep 2017 06:37:20 +0300 Subject: http://rcd.pld-linux.org/ Message-ID: <3e2d2055-543c-7257-d49b-76752186358f@pld-linux.org> seems whoever has forgotten rcd.pld-linux.org alias. serves some directory listing, but should redirect to project real address. http://rescuecd.pld-linux.org/ -- glen From arekm at maven.pl Wed Sep 6 09:14:00 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 6 Sep 2017 09:14:00 +0200 Subject: [packages/kernel] - disable struct randomization, it's pointless for a distro kernel In-Reply-To: References: <3c1bdaffd564d4758d6cc169866988b172b3700a_refs_heads_master@pld-linux.org> Message-ID: <201709060914.00963.arekm@maven.pl> On Tuesday 05 of September 2017, baggins wrote: > commit aa2cca690b9ce623e4dac08b9563584530a0a489 > Author: Jan R?korajski > Date: Tue Sep 5 23:52:49 2017 +0200 > > - disable struct randomization, it's pointless for a distro kernel Not pointless - exploit needs to match specific pld kernel directly and generic or other distro exploits won't work. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From baggins at pld-linux.org Wed Sep 6 09:23:14 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Wed, 6 Sep 2017 09:23:14 +0200 Subject: [packages/kernel] - disable struct randomization, it's pointless for a distro kernel In-Reply-To: <201709060914.00963.arekm@maven.pl> References: <3c1bdaffd564d4758d6cc169866988b172b3700a_refs_heads_master@pld-linux.org> <201709060914.00963.arekm@maven.pl> Message-ID: <20170906072314.GA32579@home> On Wed, 06 Sep 2017, Arkadiusz Mi?kiewicz wrote: > On Tuesday 05 of September 2017, baggins wrote: > > commit aa2cca690b9ce623e4dac08b9563584530a0a489 > > Author: Jan R?korajski > > Date: Tue Sep 5 23:52:49 2017 +0200 > > > > - disable struct randomization, it's pointless for a distro kernel > > Not pointless - exploit needs to match specific pld kernel directly and > generic or other distro exploits won't work. What is very easy to accomplish, because you have to expose random seed used during kernel build to be able to build external modules. I'm not strongly opposed to the idea, but you need to make sure external modules will build/work if you really want a slower and bigger kernel for slight increase in security. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From arekm at maven.pl Wed Sep 6 09:30:40 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 6 Sep 2017 09:30:40 +0200 Subject: [packages/kernel] - disable struct randomization, it's pointless for a distro kernel In-Reply-To: <20170906072314.GA32579@home> References: <3c1bdaffd564d4758d6cc169866988b172b3700a_refs_heads_master@pld-linux.org> <201709060914.00963.arekm@maven.pl> <20170906072314.GA32579@home> Message-ID: <201709060930.40495.arekm@maven.pl> On Wednesday 06 of September 2017, Jan R?korajski wrote: > On Wed, 06 Sep 2017, Arkadiusz Mi?kiewicz wrote: > > On Tuesday 05 of September 2017, baggins wrote: > > > commit aa2cca690b9ce623e4dac08b9563584530a0a489 > > > Author: Jan R?korajski > > > Date: Tue Sep 5 23:52:49 2017 +0200 > > > > > > - disable struct randomization, it's pointless for a distro kernel > > > > Not pointless - exploit needs to match specific pld kernel directly and > > generic or other distro exploits won't work. > > What is very easy to accomplish, because you have to expose random seed > used during kernel build to be able to build external modules. Not for typical "attacker" or automated attacks. > I'm not strongly opposed to the idea, but you need to make sure external > modules will build/work Where there any problems already? > if you really want a slower and bigger kernel > for slight increase in security. How bigger and slower? It only changes order of struct members AFAIK. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From baggins at pld-linux.org Wed Sep 6 09:36:57 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Wed, 6 Sep 2017 09:36:57 +0200 Subject: [packages/kernel] - disable struct randomization, it's pointless for a distro kernel In-Reply-To: <201709060930.40495.arekm@maven.pl> References: <3c1bdaffd564d4758d6cc169866988b172b3700a_refs_heads_master@pld-linux.org> <201709060914.00963.arekm@maven.pl> <20170906072314.GA32579@home> <201709060930.40495.arekm@maven.pl> Message-ID: <20170906073657.GB32579@home> On Wed, 06 Sep 2017, Arkadiusz Mi?kiewicz wrote: > On Wednesday 06 of September 2017, Jan R?korajski wrote: > > On Wed, 06 Sep 2017, Arkadiusz Mi?kiewicz wrote: > > > On Tuesday 05 of September 2017, baggins wrote: > > > > commit aa2cca690b9ce623e4dac08b9563584530a0a489 > > > > Author: Jan R?korajski > > > > Date: Tue Sep 5 23:52:49 2017 +0200 > > > > > > > > - disable struct randomization, it's pointless for a distro kernel > > > > > > Not pointless - exploit needs to match specific pld kernel directly and > > > generic or other distro exploits won't work. > > > > What is very easy to accomplish, because you have to expose random seed > > used during kernel build to be able to build external modules. > > Not for typical "attacker" or automated attacks. > > > I'm not strongly opposed to the idea, but you need to make sure external > > modules will build/work > > Where there any problems already? Right now I'm fighting with systemd failing to setup encrypted rootfs in initramfs/boot process (something broke between 232 and 234). So can't test yet. > > if you really want a slower and bigger kernel > > for slight increase in security. > > How bigger and slower? It only changes order of struct members AFAIK. Enabling this feature will introduce some performance impact, slightly increase memory usage, and prevent the use of forensic tools like Volatility against the system (unless the kernel source tree isn't cleaned after kernel installation). -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Sat Sep 9 02:40:45 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 9 Sep 2017 03:40:45 +0300 Subject: [packages/firefox] - move lang to main package In-Reply-To: References:

Message-ID: <1240984c-ee74-b17c-9f4f-713ea51c0195@pld-linux.org> On 02.09.2017 18:01, baggins wrote: > - move lang to main package why do you still create commits not explain intentions? so question: "why?" -- glen From glen at pld-linux.org Sat Sep 9 02:44:30 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 9 Sep 2017 03:44:30 +0300 Subject: [packages/microcode-data-intel] - rel 2; produce single file that can be used by grub In-Reply-To: References: <06763ab409f8f875846f56204b5ac93149c78900_refs_heads_master@pld-linux.org> Message-ID: <03aada35-df3b-8ad8-7859-af8e00d30dd1@pld-linux.org> On 04.09.2017 10:14, arekm wrote: > +cp -p intel-microcode2ucode-single $RPM_BUILD_ROOT%{_sbindir} what is the point of packaging the binaries that are used just to build this package? not packaging those can make whole package noarch... -- glen From arekm at maven.pl Sat Sep 9 09:40:48 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sat, 9 Sep 2017 09:40:48 +0200 Subject: [packages/microcode-data-intel] - rel 2; produce single file that can be used by grub In-Reply-To: <03aada35-df3b-8ad8-7859-af8e00d30dd1@pld-linux.org> References: <06763ab409f8f875846f56204b5ac93149c78900_refs_heads_master@pld-linux.org> <03aada35-df3b-8ad8-7859-af8e00d30dd1@pld-linux.org> Message-ID: <201709090940.48489.arekm@maven.pl> On Saturday 09 of September 2017, Elan Ruusam?e wrote: > On 04.09.2017 10:14, arekm wrote: > > +cp -p intel-microcode2ucode-single $RPM_BUILD_ROOT%{_sbindir} > > what is the point of packaging the binaries that are used just to build > this package? > > not packaging those can make whole package noarch... There is a TODO in the spec just no one did it. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From baggins at pld-linux.org Sat Sep 9 09:45:08 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sat, 9 Sep 2017 09:45:08 +0200 Subject: [packages/firefox] - move lang to main package In-Reply-To: <1240984c-ee74-b17c-9f4f-713ea51c0195@pld-linux.org> References:

<1240984c-ee74-b17c-9f4f-713ea51c0195@pld-linux.org> Message-ID: <20170909074508.GC32579@home> On Sat, 09 Sep 2017, Elan Ruusam?e wrote: > On 02.09.2017 18:01, baggins wrote: > > - move lang to main package > > why do you still create commits not explain intentions? > > > so question: "why?" Isn't it obvious? a) the split itself was artificial, due to rpm deficiencies at that time. b) it was a PITA to maintain (desynchs) -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Sat Sep 9 17:55:07 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 9 Sep 2017 18:55:07 +0300 Subject: [packages/microcode-data-intel] - rel 2; produce single file that can be used by grub In-Reply-To: <201709090940.48489.arekm@maven.pl> References: <06763ab409f8f875846f56204b5ac93149c78900_refs_heads_master@pld-linux.org> <03aada35-df3b-8ad8-7859-af8e00d30dd1@pld-linux.org> <201709090940.48489.arekm@maven.pl> Message-ID: <61646983-cddb-eed1-2169-6c28449cd226@pld-linux.org> On 09.09.2017 10:40, Arkadiusz Mi?kiewicz wrote: > On Saturday 09 of September 2017, Elan Ruusam?e wrote: >> On 04.09.2017 10:14, arekm wrote: >>> +cp -p intel-microcode2ucode-single $RPM_BUILD_ROOT%{_sbindir} >> what is the point of packaging the binaries that are used just to build >> this package? >> >> not packaging those can make whole package noarch... > There is a TODO in the spec just no one did it. todo is there because nobody knows purpose of previous binaries, and therefore afraid to make changes risking getting beaten up in lists later. you just added new executable, so you must have purpose/reasoning. -- glen From arekm at maven.pl Sat Sep 9 20:20:17 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sat, 9 Sep 2017 20:20:17 +0200 Subject: [packages/microcode-data-intel] - rel 2; produce single file that can be used by grub In-Reply-To: <61646983-cddb-eed1-2169-6c28449cd226@pld-linux.org> References: <06763ab409f8f875846f56204b5ac93149c78900_refs_heads_master@pld-linux.org> <201709090940.48489.arekm@maven.pl> <61646983-cddb-eed1-2169-6c28449cd226@pld-linux.org> Message-ID: <201709092020.17610.arekm@maven.pl> On Saturday 09 of September 2017, Elan Ruusam?e wrote: > On 09.09.2017 10:40, Arkadiusz Mi?kiewicz wrote: > > On Saturday 09 of September 2017, Elan Ruusam?e wrote: > >> On 04.09.2017 10:14, arekm wrote: > >>> +cp -p intel-microcode2ucode-single $RPM_BUILD_ROOT%{_sbindir} > >> > >> what is the point of packaging the binaries that are used just to build > >> this package? > >> > >> not packaging those can make whole package noarch... > > > > There is a TODO in the spec just no one did it. > > todo is there because nobody knows purpose of previous binaries, and > therefore afraid to make changes risking getting beaten up in lists later. > > you just added new executable, so you must have purpose/reasoning. Added to match what's already in spec. The only reason I could imagine is to manually generate microcode files from manually download tarball from intel.com. Likely no one does that. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From gotar at polanet.pl Sun Sep 10 05:17:51 2017 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 10 Sep 2017 05:17:51 +0200 Subject: [packages/microcode-data-intel] - rel 2; produce single file that can be used by grub In-Reply-To: <201709092020.17610.arekm@maven.pl> References: <06763ab409f8f875846f56204b5ac93149c78900_refs_heads_master@pld-linux.org> <201709090940.48489.arekm@maven.pl> <61646983-cddb-eed1-2169-6c28449cd226@pld-linux.org> <201709092020.17610.arekm@maven.pl> Message-ID: <20170910031751.GA9009@polanet.pl> On Sat, Sep 09, 2017 at 20:20:17 +0200, Arkadiusz Mi?kiewicz wrote: > The only reason I could imagine is to manually generate microcode files from > manually download tarball from intel.com. There's no reason to do that ...provided we ship updates ASAP. But since we might be late, someone might make use of this binary in a future. We never know if some critical (like security-related) patch won't happen. See Skylake/Kaby Lake HT issue recently. So: 1. if kernel module requires per-CPU files, we should provide the binary to split upstream file, 2. if grub requires single file, but in different than upstream format, we should provide the binary merging files into it. This becames obvious if you only consider these as a compilers. We do provide gcc despite having binary ready-to-use packages. > Likely no one does that. Likely no non-developer uses PLD anymore... As it it mostly unusable without r/w git access and STBR permissions. Consider a r/o user in a need to update microcode we do not yet have - he _must_ go gcc-way (find the code & compile the binary, either with or without updating microcode-data-intel.spec itself), unless we do ship these binariers, ready to use on downloaded microcode. What I miss in the commit log is the source of these files. And/or iucode_tool. -- Tomasz Pala From mateusz-lists at ant.gliwice.pl Mon Sep 11 11:20:36 2017 From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak) Date: Mon, 11 Sep 2017 11:20:36 +0200 Subject: Lag in http://git.pld-linux.org/ ? Message-ID: <2885874.59V76lGDnc@matkor-lenovo> On http://git.pld-linux.org/ I can not see package: electrum which I added few days ago. Any other way to search package names in PLD? -- Mateusz Korniak "(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?, kr?tko m?wi?c - podpora spo?ecze?stwa." Nikos Kazantzakis - "Grek Zorba" From arekm at maven.pl Tue Sep 19 09:28:03 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Tue, 19 Sep 2017 09:28:03 +0200 Subject: file /usr/bin/encguess from install of perl-tools-5.26.0-4.x86_64 conflicts with file from package perl-Encode-2.91-1.x86_64 Message-ID: <201709190928.03267.arekm@maven.pl> What's the solution for this? file /usr/bin/encguess from install of perl-tools-5.26.0-4.x86_64 conflicts with file from package perl-Encode-2.91-1.x86_64 rm from Encode I would guess. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From baggins at pld-linux.org Tue Sep 19 20:02:11 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 19 Sep 2017 20:02:11 +0200 Subject: Mesa 17.2 from th-test is broken Message-ID: <20170919180211.GA4733@home> Xserver crashes for me after installing Mesa 17.2 from th-test Updating ati driver does not help. $ rpm -q xorg-driver-video-ati xorg-driver-video-ati-7.10.0-1.x86_64 [ 282.612] (II) Loading sub module "dri2" [ 282.612] (II) LoadModule: "dri2" [ 282.612] (II) Module "dri2" already built-in [ 282.612] (II) Loading sub module "glamoregl" [ 282.613] (II) LoadModule: "glamoregl" [ 282.613] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 282.615] (II) Module glamoregl: vendor="X.Org Foundation" [ 282.615] compiled for 1.19.3, module version = 1.0.0 [ 282.615] ABI class: X.Org ANSI C Emulation, version 0.4 [ 282.615] (II) glamor: OpenGL accelerated X.org driver based. [ 282.645] (EE) [ 282.645] (EE) Backtrace: [ 282.645] (EE) 0: /usr/lib64/xorg/Xorg (OsLookupColor+0x139) [0x473a19] [ 282.646] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7f72d68a01cf] [ 282.646] (EE) 2: /lib64/libc.so.6 (strlen+0x26) [0x7f72d614af76] [ 282.646] (EE) 3: /usr/lib64/xorg/modules/dri/r600_dri.so (nouveau_drm_screen_create+0x2c9959) [0x7f72cea6e1a9] [ 282.646] (EE) 4: /usr/lib64/xorg/modules/dri/r600_dri.so (nouveau_drm_screen_create+0x2c9d5b) [0x7f72cea6e95b] [ 282.646] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 282.646] (EE) 5: /usr/lib64/xorg/modules/dri/r600_dri.so (?+0x2c9d5b) [0x7f72ce32d15b] [ 282.647] (EE) 6: /lib64/ld-linux-x86-64.so.2 (call_init.part.0+0x9a) [0x7f72d6d0d64a] [ 282.647] (EE) 7: /lib64/ld-linux-x86-64.so.2 (_dl_init+0x8b) [0x7f72d6d0d75b] [ 282.647] (EE) 8: /lib64/ld-linux-x86-64.so.2 (dl_open_worker+0x3f8) [0x7f72d6d11c08] [ 282.648] (EE) 9: /lib64/libc.so.6 (_dl_catch_error+0x8c) [0x7f72d61f12dc] [ 282.648] (EE) 10: /lib64/ld-linux-x86-64.so.2 (_dl_open+0xc9) [0x7f72d6d11399] [ 282.648] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 282.648] (EE) 11: /lib64/libdl.so.2 (?+0xc9) [0x7f72d668b039] [ 282.649] (EE) 12: /lib64/libc.so.6 (_dl_catch_error+0x8c) [0x7f72d61f12dc] [ 282.649] (EE) 13: /lib64/libdl.so.2 (dlerror+0x2d9) [0x7f72d668b909] [ 282.649] (EE) 14: /lib64/libdl.so.2 (dlopen+0x42) [0x7f72d668b062] [ 282.649] (EE) 15: /usr/lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x17c4) [0x7f72cf7cffc4] [ 282.649] (EE) 16: /usr/lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x18ec) [0x7f72cf7d039c] [ 282.649] (EE) 17: /usr/lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x1d68) [0x7f72cf7d0b58] [ 282.650] (EE) 18: /usr/lib64/libgbm.so.1 (gbm_create_device+0x57) [0x7f72cf7cce07] [ 282.650] (EE) 19: /usr/lib64/xorg/modules/libglamoregl.so (glamor_egl_init+0x83) [0x7f72cf9dffb3] [ 282.650] (EE) 20: /usr/lib64/xorg/modules/drivers/radeon_drv.so (_init+0x4b937) [0x7f72d04f6f07] [ 282.650] (EE) 21: /usr/lib64/xorg/modules/drivers/radeon_drv.so (_init+0x3df99) [0x7f72d04daea9] [ 282.650] (EE) 22: /usr/lib64/xorg/Xorg (InitOutput+0xa3f) [0x490f4f] [ 282.650] (EE) 23: /usr/lib64/xorg/Xorg (InitFonts+0x216) [0x43a606] [ 282.650] (EE) 24: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7f72d60e75a1] [ 282.651] (EE) 25: /usr/lib64/xorg/Xorg (_start+0x2a) [0x4243ca] [ 282.651] (EE) 26: ? (?+0x2a) [0x2a] [ 282.651] (EE) [ 282.651] (EE) Segmentation fault at address 0x0 [ 282.651] (EE) Fatal server error: [ 282.651] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 282.651] (EE) [ 282.651] (EE) -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From ed at yen.ipipan.waw.pl Tue Sep 19 20:53:58 2017 From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=) Date: Tue, 19 Sep 2017 20:53:58 +0200 Subject: Mesa 17.2 from th-test is broken In-Reply-To: <20170919180211.GA4733@home> References: <20170919180211.GA4733@home> Message-ID: <18839839.RGfv92cUZ8@laptok> Dnia wtorek, 19 wrze?nia 2017 20:02:11 Jan R?korajski pisze: > Xserver crashes for me after installing Mesa 17.2 from th-test [...] Just to report: 12.7.1.x86_64 + Intel works for me. -- ?ukasz Ma?ko _o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana" From jajcus at jajcus.net Tue Sep 19 20:56:16 2017 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 19 Sep 2017 20:56:16 +0200 Subject: Mesa 17.2 from th-test is broken In-Reply-To: <18839839.RGfv92cUZ8@laptok> References: <20170919180211.GA4733@home> <18839839.RGfv92cUZ8@laptok> Message-ID: On 2017-09-19 20:53, ?ukasz Ma?ko wrote: > Dnia wtorek, 19 wrze?nia 2017 20:02:11 Jan R?korajski pisze: >> Xserver crashes for me after installing Mesa 17.2 from th-test > [...] > > Just to report: 12.7.1.x86_64 + Intel works for me. I just wanted to write the same ? no problem in Intel. Is there any llvm or libstdc++ version conflict possible? Gallium driver are quite sensitive to those. Jacek From atler at pld-linux.org Tue Sep 19 21:12:49 2017 From: atler at pld-linux.org (Jan Palus) Date: Tue, 19 Sep 2017 21:12:49 +0200 Subject: Mesa 17.2 from th-test is broken In-Reply-To: <20170919180211.GA4733@home> References: <20170919180211.GA4733@home> Message-ID: <20170919191249.d7hidmmj6ifrbff4@kalarepa> On 19.09.2017 18:02, Jan R?korajski wrote: >Xserver crashes for me after installing Mesa 17.2 from th-test >Updating ati driver does not help. Arch has similar report: https://bugs.archlinux.org/task/55551 https://bugs.freedesktop.org/show_bug.cgi?id=101832 initially fixed by disabling swr but now I think this patch is supposed to fix it https://bugs.freedesktop.org/attachment.cgi?id=133894 From baggins at pld-linux.org Wed Sep 20 08:53:07 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Wed, 20 Sep 2017 08:53:07 +0200 Subject: Mesa 17.2 from th-test is broken In-Reply-To: <20170919191249.d7hidmmj6ifrbff4@kalarepa> References: <20170919180211.GA4733@home> <20170919191249.d7hidmmj6ifrbff4@kalarepa> Message-ID: <20170920065307.GA8334@home> On Tue, 19 Sep 2017, Jan Palus wrote: > On 19.09.2017 18:02, Jan R?korajski wrote: > >Xserver crashes for me after installing Mesa 17.2 from th-test > >Updating ati driver does not help. > > Arch has similar report: > > https://bugs.archlinux.org/task/55551 > > https://bugs.freedesktop.org/show_bug.cgi?id=101832 > > initially fixed by disabling swr but now I think this patch is supposed to fix > it > > https://bugs.freedesktop.org/attachment.cgi?id=133894 Thank you, this patch fixed the crash. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/