[gentoo-user] Re: AMD Tonga + kernel 4.19 broken

2018-11-14 Thread Adam Carter 
On Thu, Nov 1, 2018 at 12:57 PM Adam Carter  wrote:

> For me;
>
> Oct 25 15:34:51 phat kernel: fbcon: amdgpudrmfb (fb0) is primary device
> Oct 25 15:34:51 phat kernel: amdgpu: [powerplay]
>   failed to send message 148 ret is 0
> Oct 25 15:34:51 phat kernel: amdgpu: [powerplay]
>   last message was failed ret is 0
>

For the record, the patch mentioned in the bug below fixed the issue
https://bugs.freedesktop.org/show_bug.cgi?id=108704

Re: [gentoo-user] Weird compilation error (nasm)

2018-11-14 Thread Adam Carter 
On Thu, Nov 15, 2018 at 6:20 AM  wrote:

> Hi,
>
> its gone this evening while updateing...


Yeah the nasm update was backed out

Fri May 11 15:25:38 2018 >>> dev-lang/nasm-2.13.03-r1
Mon Nov 12 12:27:25 2018 >>> dev-lang/nasm-2.14
Wed Nov 14 16:31:50 2018 >>> dev-lang/nasm-2.13.03-r1

Re: [gentoo-user] Weird compilation error (nasm)

2018-11-14 Thread Sergei Trofimovich 
On Tue, 13 Nov 2018 18:11:38 +0100
tu...@posteo.de wrote:

> Hi,
> 
> I got a weird looking error while upgrading/recompiling nasm:
...
> F: fopen_wr
> S: deny
> P: /?
> A: /?
> R: /?
> C: /usr/bin/nasm /? 

This is likely a nasm bug:
https://bugs.gentoo.org/670944
https://bugzilla.nasm.us/show_bug.cgi?id=3392529

nasm-2.14 was masked to prevent further failures:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d09ad3d85d31fb36deec08d16e1e1424a75f0a52

-- 

  Sergei

Re: [gentoo-user] Shorewall config problem

2018-11-14 Thread Adam Carter 
>
> That is odd. I tried inserting the IPV[4,6] .config entries by hand, but
> oldconfig removed them again.
>

I'd say those entries are deprecated and that shorewall will just need an
update to make it compatible with 4.19.

Re: [gentoo-user] Shorewall config problem

2018-11-14 Thread Peter Humphrey 
On Tuesday, 13 November 2018 08:06:03 GMT Adam Carter wrote:

> My .config hasnt changed, other than from setting the new options via make
> oldconfig;
> 
> /usr/src/configs # grep CONFIG_NF_CONNTRACK_IP config-2018-10-29
> config-2018-11-13
> config-2018-10-29:CONFIG_NF_CONNTRACK_IPV4=y
> config-2018-10-29:CONFIG_NF_CONNTRACK_IPV6=y
> 
> /usr/src/configs # head -n3 config-2018-10-29 config-2018-11-13
> ==> config-2018-10-29 <==
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86 4.18.16-gentoo Kernel Configuration
> 
> ==> config-2018-11-13 <==
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86 4.19.0-gentoo Kernel Configuration
> /usr/src/configs #

That is odd. I tried inserting the IPV[4,6] .config entries by hand, but 
oldconfig removed them again.

The help text in kernel 4.14.78 says:

   Defined at net/ipv4/netfilter/Kconfig:12 
   
   Depends on: NET [=y] && INET [=y] && NETFILTER [=y] && NF_CONNTRACK [=y]
   Selects: NF_DEFRAG_IPV4 [=y]

None of those dependencies look likely to hide the IPV[4,6] options.

I also tried copying in the old config file from 4.14.78 and running it 
through oldconfig again, this time including all the new netfilter options. 
Again there was no sign of the IPV[4,6] options.

-- 
Regards,
Peter.

Re: [gentoo-user] Weird compilation error (nasm)

2018-11-14 Thread tuxic 
Hi,

its gone this evening while updateing...

Thanks a lot to all for the help!

Cheers
Meino




On 11/13 09:35, David Haller wrote:
> Hello,
> 
> On Tue, 13 Nov 2018, tu...@posteo.de wrote:
> >I got a weird looking error while upgrading/recompiling nasm:
> >cmake -C 
> >/var/tmp/portage/media-libs/libjpeg-turbo-2.0.1/work/libjpeg-turbo-2.0.1-abi_x86_64.amd64/gentoo_common_config.cmake
> > -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr 
> >-DCMAKE_INSTALL_DEFAULT_DOCDIR=/usr/share/doc/libjpeg-turbo-2.0.1 
> >-DENABLE_STATIC=no -DWITH_JAVA=no -DWITH_MEM_SRCDST=ON 
> >-DCMAKE_BUILD_TYPE=Gentoo 
> >-DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/media-libs/libjpeg-turbo-2.0.1/work/libjpeg-turbo-2.0.1-abi_x86_64.amd64/gentoo_toolchain.cmake
> >  /var/tmp/portage/media-libs/libjpeg-turbo-2.0.1/work/libjpeg-turbo-2.0.1
> >loading initial cache file 
> >/var/tmp/portage/media-libs/libjpeg-turbo-2.0.1/work/libjpeg-turbo-2.0.1-abi_x86_64.amd64/gentoo_common_config.cmake
> > * ACCESS DENIED:  fopen_wr: /?
> >Build type  Gentoo
> >Install path/usr
> >Compiler flags:
> >C   -march=native -O -pipe
> >C++ 
> >Linker flags:
> >Executable  -Wl,-O1 -Wl,--as-needed
> >Module  -Wl,-O1 -Wl,--as-needed
> >Shared  -Wl,-O1 -Wl,--as-needed
> >
>  Source configured.
> > * --- ACCESS VIOLATION SUMMARY 
> > ---
> > * LOG FILE: "/var/log/sandbox/sandbox-16492.log"
> > * 
> >VERSION 1.0
> >FORMAT: F - Function called
> >FORMAT: S - Access Status
> >FORMAT: P - Path as passed to function
> >FORMAT: A - Absolute Path (not canonical)
> >FORMAT: R - Canonical Path
> >FORMAT: C - Command Line
> >
> >F: fopen_wr
> >S: deny
> >P: /?
> >A: /?
> >R: /?
> >C: /usr/bin/nasm /? 
> > * 
> > 
> 
> The problem is cmake's way to figure out what nasm it has got:
> 
>  /usr/share/cmake/Modules/CMakeDetermineASMCompiler.cmake:79 
>   list(APPEND CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDORS MSVC )
>   set(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_FLAGS_MSVC "/?")
>   set(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_MSVC "Microsoft
> 
> 
> Workaround1:
> 
> 
> --- libjpeg-turbo-2.0.1.ebuild~ 2018-11-13 20:45:58.0 +0100
> +++ libjpeg-turbo-2.0.1.ebuild  2018-11-13 20:44:02.0 +0100
> @@ -52,6 +52,7 @@
> -DENABLE_STATIC="$(usex static-libs)"
> -DWITH_JAVA="$(multilib_native_usex java)"
> -DWITH_MEM_SRCDST=ON
> +   -DCMAKE_ASM_NASM_COMPILER_ID=GNU
> )
> [[ ${ABI} == "x32" ]] && mycmakeargs+=( -DREQUIRE_SIMD=OFF ) #420239
> cmake-utils_src_configure
> 
> 
> Workaround2: if you have dev-lang/yasm installed, use:
> 
> ASM_NASM=/usr/bin/yasm [ebuild|emerge] ...
> 
> Workaround3: delete those MSVC lines from
> /usr/share/cmake/Modules/CMakeDetermineASMCompiler.cmake
> 
> Workaround4: patch cmake-utils.eclass to add 
> -DCMAKE_ASM_NASM_COMPILER_ID=GNU to cmakeargs in
> cmake-utils_src_configure.
> 
> HTH,
> -dnh, I'd prefer solution 3 ;)
> 
> -- 
> my other signature is more intellectual
>