Re: [gentoo-user] how to support a package going out of tree

[Raffaele Belardi]

Walter Dnes wrote:
> On Fri, Jan 26, 2018 at 12:13:32PM +0100, Raffaele Belardi wrote
>> One of my son's favourite games (hedgewars) is going out of tree
>> due to dependency on deprecated QT4.
>>
>> I already have a local overlay with a modified hedgewars ebuild
>> which adds support for a non-standard USE flag but I suppose this
>> will not be sufficient to continue using/building the game. Once the
>> dependencies will go out of tree also there will be little chance
>> to rebuild the game if necessary, right?.
> 
>   If you're looking at long-term, I would suggest installing a separate
> machine or chroot or VM, which will not be updated.  If you keep it long
> enough, the main system is going to get to the point where either
> hedgewars doesn't work or your regular apps don't work.
> 

This could be an easier route than trying to maintain the ebuild locally, as 
Rich noted.

Thanks, I'll investigate on both routes.

raffaele

[gentoo-user] gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Adam Carter]

Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2

With gcc 7.2 + kernel 4.14.15;
Intel system shows; Vulnerable: Minimal generic ASM retpoline
AMD system shows: Vulnerable: Minimal AMD ASM retpoline

With gcc 7.3 + kernel 4.15.0;
Intel system shows; Mitigation: Full generic retpoline
AMD system shows' Mitigation: Full AMD retpoline

[gentoo-user] PSA: GCC 7.3 allows to build kernel with full Spectre v2 mitigation

[Nikos Chantziaras]

On 18/01/18 20:31, Nikos Chantziaras wrote:

On 18/01/18 10:28, Adam Carter wrote:

Nice;

$ ls /sys/devices/system/cpu/vulnerabilities/
meltdown  spectre_v1  spectre_v2
$ cat /sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: PTI
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Vulnerable
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Vulnerable: Minimal generic ASM retpoline


Good to know! Thanks.

For Spectre, GCC 7.3 is needed, which isn't released yet, but AFAIK is 
being fast-tracked for release by upstream. There's plans to backport to 
GCC 6 as well.


GCC 7.3.0 is now in the tree (~arch). If you want full mitigation 
against Spectre v2, you need to build the kernel with that version.


For this to work, you need to enable CONFIG_RETPOLINE in the kernel:

  Processor type and features
[*] Avoid speculative indirect branches in kernel

Rebuild kernel and modules and you should see something like this:

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline

Re: [gentoo-user] PSA: GCC 7.3 allows to build kernel with full Spectre v2 mitigation

[Rich Freeman]

On Mon, Jan 29, 2018 at 4:19 AM, Nikos Chantziaras  wrote:
> For this to work, you need to enable CONFIG_RETPOLINE in the kernel:
>
>   Processor type and features
> [*] Avoid speculative indirect branches in kernel
>

Note that in general upstream recommends enabling these protections
even if your CPU isn't vulnerable.  In general the kernel detects at
boot what is needed and they've done some work to try to use the least
invasive solution needed for your particular CPU.  Then, if you later
re-use that config on a vulnerable CPU without thinking about it
(perhaps years from now) you won't be left unprotected.

The only really expensive mitigation is for Meltdown (PTI) and it is
disabled automatically on AMD CPUs.  The Retpolines are also adjusted
by CPU type.

There is talk of allowing KPTI to be disabled per-process in the
future, which would be the best of both worlds.  If you had a database
server you could disable KPTI on the database server process itself
(which does effectively give it root access, though only if exploited
- it isn't going to accidentally mess things up), but still leave the
overall system protected against random processes escalating privs.
If you have a dedicated database server then probably the only process
you truly worry about is the database server itself, so if something
is running malicious code on this process you've already lost whether
it has root access or not.  Though, I would probably also point out
that I would use care applying this to containers and not just to VMs,
because the vulnerability would let you cross container boundaries,
but not VMs (assuming you haven't enabled similar exceptions to PTI in
the hypervisor).


-- 
Rich

[gentoo-user] emerge -quad --newuse @world

[gg]

Hallo ,

please help me. I try to install a new  Gentoo with no-multilib  (AMD64)  ,

but compiling sandbox fails :


ebuild   R   ] sys-apps/sandbox-2.12

Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-apps/sandbox-2.12::gentoo
>>> Failed to emerge sys-apps/sandbox-2.12, Log file:
>>>  '/var/tmp/portage/sys-apps/sandbox-2.12/temp/build.log'
 * Package:sys-apps/sandbox-2.12
 * Repository: gentoo
 * Maintainer: sand...@gentoo.org
 * USE:abi_x86_32 abi_x86_64 amd64 elibc_glibc kernel_linux
userland_GNU
 * FEATURES:   preserve-libs sandbox userpriv usersandbox
 * abi_x86_32.x86: running multilib-minimal_abi_src_configure
checking for a BSD-compatible install...
/usr/lib/portage/python3.5/ebuild-helpers/xattr/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking environment state... ok
checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
checking whether the C compiler works... no
configure: error: in
`/var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12-abi_x86_32.x86':
configure: error: C compiler cannot create executables
See `config.log' for more details

!!! Please attach the following file when seeking support:
!!!
/var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12-abi_x86_32.x86/config.log
 * ERROR: sys-apps/sandbox-2.12::gentoo failed (configure phase):
 *   econf failed
 *
 * Call stack:
 *   ebuild.sh, line  124:  Called src_configure
 * environment, line 2921:  Called
multilib-minimal_src_configure
 * environment, line 2039:  Called multilib_foreach_abi
'multilib-minimal_abi_src_configure'
 * environment, line 2253:  Called
multibuild_foreach_variant '_multilib_multibuild_wrapper'
'multilib-minimal_abi_src_configure'
 * environment, line 1969:  Called _multibuild_run
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 * environment, line 1967:  Called
_multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
 * environment, line  362:  Called
multilib-minimal_abi_src_configure
 * environment, line 2033:  Called multilib_src_configure
 * environment, line 2468:  Called econf
 *phase-helpers.sh, line  665:  Called __helpers_die 'econf failed'
 *   isolated-functions.sh, line  117:  Called die
 * The specific snippet of code:
 *  die "$@"
 *
 * If you need support, post the output of `emerge --info
'=sys-apps/sandbox-2.12::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=sys-apps/sandbox-2.12::gentoo'`.
 * If configure failed with a 'cannot run C compiled programs' error,
try this:
 * FEATURES='-sandbox -usersandbox' emerge sandbox
 * The complete build log is located at
'/var/tmp/portage/sys-apps/sandbox-2.12/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-apps/sandbox-2.12/temp/environment'.
 * Working directory:
'/var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12'

 * Messages for package sys-apps/sandbox-2.12:

 * ERROR: sys-apps/sandbox-2.12::gentoo failed (configure phase):
 *   econf failed
 *
 * Call stack:
 *   ebuild.sh, line  124:  Called src_configure
 * environment, line 2921:  Called
multilib-minimal_src_configure
 * environment, line 2039:  Called multilib_foreach_abi
'multilib-minimal_abi_src_configure'
 * environment, line 2253:  Called
multibuild_foreach_variant '_multilib_multibuild_wrapper'
'multilib-minimal_abi_src_configure'
 * environment, line 1969:  Called _multibuild_run
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 * environment, line 1967:  Called
_multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
 * environment, line  362:  Called
multilib-minimal_abi_src_configure
 * environment, line 2033:  Called multilib_src_configure
 * environment, line 2468:  Called econf
 *phase-helpers.sh, line  665:  Called __helpers_die 'econf failed'
 *   isolated-functions.sh, line  117:  Called die
 * The specific snippet of code:
 *  die "$@"

Portage 2.3.13 (python 3.5.4-final-0, default/linux/amd64/17.0/desktop, 
gcc-6.4.0, glibc-2.25-r9, 4.5.2-aufs-r1 x86_64)
=
 System Settings
=
System uname: 
Linux-4.5.2-aufs-r1-x86_64-Intel-R-_Celeron-R-_D_CPU_3.46GHz-with-gentoo-2.4.1
KiB Mem: 3328484 total,188564 free
KiB Swap: 524284 total, 

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Ian Zimmerman]

On 2018-01-29 20:11, Adam Carter wrote:

> Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2
> 
> With gcc 7.2 + kernel 4.14.15;
> Intel system shows; Vulnerable: Minimal generic ASM retpoline
> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
> 
> With gcc 7.3 + kernel 4.15.0;
> Intel system shows; Mitigation: Full generic retpoline
> AMD system shows' Mitigation: Full AMD retpoline

Is there a simple way, with the upstream (kernel.org) sources, to force
a compiler different from the system default?  If there is, it's not in the
README, and a simple grep over the Makefiles also doesn't enlighten.

I am not ready to activate a keyworded gcc for general use.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Alexander Kapshuk]

On Mon, Jan 29, 2018 at 7:50 PM, Ian Zimmerman  wrote:
> On 2018-01-29 20:11, Adam Carter wrote:
>
>> Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2
>>
>> With gcc 7.2 + kernel 4.14.15;
>> Intel system shows; Vulnerable: Minimal generic ASM retpoline
>> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
>>
>> With gcc 7.3 + kernel 4.15.0;
>> Intel system shows; Mitigation: Full generic retpoline
>> AMD system shows' Mitigation: Full AMD retpoline
>
> Is there a simple way, with the upstream (kernel.org) sources, to force
> a compiler different from the system default?  If there is, it's not in the
> README, and a simple grep over the Makefiles also doesn't enlighten.
>
> I am not ready to activate a keyworded gcc for general use.
>
> --
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet, fetch the TXT record for the domain.
>

To compile the kernel with a different compiler, the method shown
below may be used, e.g.:
make CC=clang

See [1], for details:
Building the kernel with Clang:
[1] https://lwn.net/Articles/734071/

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Mike Gilbert]

On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman  wrote:
> On 2018-01-29 20:11, Adam Carter wrote:
>
>> Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2
>>
>> With gcc 7.2 + kernel 4.14.15;
>> Intel system shows; Vulnerable: Minimal generic ASM retpoline
>> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
>>
>> With gcc 7.3 + kernel 4.15.0;
>> Intel system shows; Mitigation: Full generic retpoline
>> AMD system shows' Mitigation: Full AMD retpoline
>
> Is there a simple way, with the upstream (kernel.org) sources, to force
> a compiler different from the system default?  If there is, it's not in the
> README, and a simple grep over the Makefiles also doesn't enlighten.
>
> I am not ready to activate a keyworded gcc for general use.

You could pass CC=gcc-7.3.0 to the make command, like so:

make -j6 CC=gcc-7.3.0

Re: [gentoo-user] emerge -quad --newuse @world

[Dale]

gg wrote:
> Hallo ,
>
> please help me. I try to install a new  Gentoo with no-multilib  (AMD64)  ,
>
> but compiling sandbox fails :
>
>
> ebuild   R   ] sys-apps/sandbox-2.12
>
> Would you like to merge these packages? [Yes/No] y
 Verifying ebuild manifests
 Emerging (1 of 1) sys-apps/sandbox-2.12::gentoo
 Failed to emerge sys-apps/sandbox-2.12, Log file:
  '/var/tmp/portage/sys-apps/sandbox-2.12/temp/build.log'
>  * Package:sys-apps/sandbox-2.12
>  * Repository: gentoo
>  * Maintainer: sand...@gentoo.org
>  * USE:abi_x86_32 abi_x86_64 amd64 elibc_glibc kernel_linux
> userland_GNU
>  * FEATURES:   preserve-libs sandbox userpriv usersandbox
>  * abi_x86_32.x86: running multilib-minimal_abi_src_configure
> checking for a BSD-compatible install...
> /usr/lib/portage/python3.5/ebuild-helpers/xattr/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether make supports nested variables... (cached) yes
> checking environment state... ok
> checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
> checking whether the C compiler works... no
> configure: error: in
> `/var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12-abi_x86_32.x86':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
>
> !!! Please attach the following file when seeking support:
> !!!
>


I thought this looked familiar.  I did a google search and found a old
thread of mine.  I did a emerge -e @world to fix it.  You may can do a
emerge -e @system and it fix it, since it should fix gcc and everything
it depends on. 

Before doing that tho, I would check gcc-config -l and see if it is
set.  It should have a "*" beside one version in the list.  I seem to
recall once ages ago setting it, even tho it shows it is set, again and
it helping.  Should look something like this:

root@fireball / # gcc-config -l
 [1] x86_64-pc-linux-gnu-6.4.0 *
root@fireball / # gcc-config 1
 * Switching native-compiler to x86_64-pc-linux-gnu-6.4.0
... 

[ ok ]
root@fireball / # gcc-config -l
 [1] x86_64-pc-linux-gnu-6.4.0 *
root@fireball / #

That is grasping at straws but if it works, it would save a lot of
compile time.  It's faster too.

Hope that helps and if not, maybe someone else has a good idea. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Mick]

On Monday, 29 January 2018 18:35:58 GMT Mike Gilbert wrote:
> On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman  
wrote:
> > On 2018-01-29 20:11, Adam Carter wrote:
> >> Comparing the contents of
> >> /sys/devices/system/cpu/vulnerabilities/spectre_v2
> >> 
> >> With gcc 7.2 + kernel 4.14.15;
> >> Intel system shows; Vulnerable: Minimal generic ASM retpoline
> >> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
> >> 
> >> With gcc 7.3 + kernel 4.15.0;
> >> Intel system shows; Mitigation: Full generic retpoline
> >> AMD system shows' Mitigation: Full AMD retpoline
> > 
> > Is there a simple way, with the upstream (kernel.org) sources, to force
> > a compiler different from the system default?  If there is, it's not in
> > the
> > README, and a simple grep over the Makefiles also doesn't enlighten.
> > 
> > I am not ready to activate a keyworded gcc for general use.
> 
> You could pass CC=gcc-7.3.0 to the make command, like so:
> 
> make -j6 CC=gcc-7.3.0

Shouldn't you have at least compiled your whole toolchain with gcc-7.3.0 
first?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Mike Gilbert]

On Mon, Jan 29, 2018 at 1:56 PM, Mick  wrote:
> On Monday, 29 January 2018 18:35:58 GMT Mike Gilbert wrote:
>> On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman 
> wrote:
>> > On 2018-01-29 20:11, Adam Carter wrote:
>> >> Comparing the contents of
>> >> /sys/devices/system/cpu/vulnerabilities/spectre_v2
>> >>
>> >> With gcc 7.2 + kernel 4.14.15;
>> >> Intel system shows; Vulnerable: Minimal generic ASM retpoline
>> >> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
>> >>
>> >> With gcc 7.3 + kernel 4.15.0;
>> >> Intel system shows; Mitigation: Full generic retpoline
>> >> AMD system shows' Mitigation: Full AMD retpoline
>> >
>> > Is there a simple way, with the upstream (kernel.org) sources, to force
>> > a compiler different from the system default?  If there is, it's not in
>> > the
>> > README, and a simple grep over the Makefiles also doesn't enlighten.
>> >
>> > I am not ready to activate a keyworded gcc for general use.
>>
>> You could pass CC=gcc-7.3.0 to the make command, like so:
>>
>> make -j6 CC=gcc-7.3.0
>
> Shouldn't you have at least compiled your whole toolchain with gcc-7.3.0
> first?

I don't see any reason that would be necessary.

[gentoo-user] NeoMutt and GnuPG

[Lucas Ramage]

Hello,

I know I have posted about this once before, but basically, even though I
can receive and decrypt messages in neomutt, I am not able to send
encrypted emails.

Here is my muttrc on github:
https://github.com/lramage94/dotfiles/blob/master/.mutt/muttrc

When I receive an encrypted message, it is all inline:

-BEGIN PGP MESSAGE-

ASDKNALSKFASF!#@$!@ # <-- All that good encrypted stuff.

-END PGP MESSAGE-

When I send an encrypted message I see two files:

- noname (1kb)
- msg.asc (10kb) # <-- this one changes size depending on my message.

Thanks,

-- 

[image: Visit online journal] 

*Lucas Ramage* / Software Engineer
ramage.lu...@openmailbox.org / (941) 404-6794

*PGP Fingerprint* / Learn More 
EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7


*Visit online journal*
http://lramage94.github.io 

[image: Github]  [image: Linkedin]

[gentoo-user] rust 1.23.0 fails to install

[John Covici]

Hi.  In my world update Rust 1.23.0 failed to install with the
following error:
install: installing component 'rustc'

Rust is ready to roll.

< Rustc { stage: 2, target: "x86_64-unknown-linux-gnu", host:
"x86_64-unknown-linux-gnu" }
Build completed successfully in 0:21:12
mv: cannot stat
'/var/tmp/portage/dev-lang/rust-1.23.0/image//usr/share/doc/rust/*':
No such file or directory

I did not see a bug on bgo -- anyone knows how to fix?

Thanks in advance for any suggestions.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: [gentoo-user] gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Henry Kohli]

Would it be usefull to do a emerge -e @world with the new GCC 7.3 ?

If yes, should we add /-mindirect-branch/, /-mindirect-branch-loop/,
/-mfunction-return/ and /-mindirect-branch-register to the CFLAGS ?/


On 29/01/18 10:11, Adam Carter wrote:
> Comparing the contents of
> /sys/devices/system/cpu/vulnerabilities/spectre_v2
>
> With gcc 7.2 + kernel 4.14.15;
> Intel system shows; Vulnerable: Minimal generic ASM retpoline
> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
>
> With gcc 7.3 + kernel 4.15.0;
> Intel system shows; Mitigation: Full generic retpoline
> AMD system shows' Mitigation: Full AMD retpoline

Re: [gentoo-user] UEFI-fails to boot

[Corbin Bird]

On 01/28/2018 04:35 AM, Dan Johansson wrote:
>>>   ASPEED's AST2500 Display To Be Supported By Linux 4.11's DRM
>>>
>>> https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/x-org-drm/935002-aspeed-s-ast2500-display-to-be-supported-by-linux-4-11-s-drm
> Thanks for that link, I will have to look into that.
> Although I will not be using X on this box, as it is a server, it looks
> like I need to configure DRM.
>
> KR
>
.
This will give you some idea of what version of kernel to aim for :
> index : ~airlied/linux
> https://cgit.freedesktop.org/~airlied/linux/log/?qt=grep&q=AST2400&showmsg=1
.
This link forced VESA / frame buffer without 'drm'.
> Xorg support for Aspeed AST2400 VGA controller [solved]
> http://forums.system-rescue-cd.org/viewtopic.php?t=5351
.
Corbin

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Nikos Chantziaras]

On 30/01/18 00:36, Henry Kohli wrote:

Would it be usefull to do a emerge -e @world with the new GCC 7.3 ?


No. Unless there's a bug involved that would require a rebuild. There 
doesn't seem to be such bug.




If yes, should we add /-mindirect-branch/, /-mindirect-branch-loop/,
/-mfunction-return/ and /-mindirect-branch-register to the CFLAGS ?/


No!

These flags are for *affected* applications only. That means application 
that: a) run third-party code, and b) do so in a sandbox.


The vast majority of software doesn't do that. Examples that do are web 
browsers (they run JIT compiled javascript), and the kernel.


Packages that benefit from these new flags will be updated and they will 
use those flags on their own, as needed.