Re: [gentoo-user] NeoMutt and GnuPG

[Roger J. H. Welsh]

On  Wed, Jan 31, 2018 at 05:17:45AM +0100 , Floyd Anderson wrote:
> I would not do that. The topic itself is complex enough and sourcing of 14 !
> long and cryptic command lines doesn’t make it better. Also note that gpg.rc
> defines the deprecated ‘pgp_clearsign_command’ variable.
Right.

> BTW. as we‘re talking about NeoMutt here, I use:
> ${XDG_CONFIG_HOME:-${HOME}/.}${XDG_CONFIG_HOME:+/}neomutt/neomuttrc
> so I can run a parallel Mutt installation when things get broken.
That is a very good point.

> Instead I suggest to set ‘gpgme’ USE-flag and *only that* – no ‘crypt’,
> ‘gpg’, ‘pgp_classic’, ‘smime’, ‘smime_classic’. Look at the ebuild and
> especially the comments. This way I only need to set one ! variable to get
> the stuff working:
>
> set crypt_use_gpgme = yes
>
>
> To be sure you may also set:
> # ensure deprecated options are disabled or disarmed
> set pgp_autoinline  = no
> set pgp_clearsign_command   = ''
> set pgp_mime_auto   = ask-yes
> set pgp_replyinline = no
>
> And if one like:
> # semi-automated encrypted reply to encrypted messages
> # Notes:
> #- this can always be disabled by PGP-menu ('p')
> #- crypt_autoencrypt or crypt_replyencrypt (if set) disables 
> crypt_opportunistic_encrypt
> set crypt_opportunistic_encrypt = yes
> set crypt_autoencrypt   = no
> set crypt_replyencrypt  = no
>
> # whether or not display unusable (revoked, expired, disabled) keys
> set pgp_show_unusable   = yes
> set crypt_timestamp = no
>
>
> With more than one mail address I suggest:
> send2-hook  . 'set pgp_sign_as = ""'
> send2-hook  '~f "1st@example\.net$"'  'set pgp_sign_as = 
> "0x0123456789ABCDEF0123456789ABCDEF01234567"'
> send2-hook  '~f "2nd@example\.net$"'  'set pgp_sign_as = 
> "0xABCDEF0123456789ABCDEF0123456789ABCDEF01"'
Thanks for the above, I will certainly revisit this email when I update
my config in the next month or so. :)

>
> > On my neomutt, when I press "v" to view attachments, all I can
> > see is text/plain. I think my neomutt does something automatic to
> > decrypt the messages.
> >
>
> Indeed, viewing attachments encrypted would break many functions otherwise,
> e.g. piping, printing, saving.
So Lucas's original problem sounds like an issue with this, I can only
imagine it is some sort of lack of pgp support.

> > My source docs I used when setting my gpg up with mutt were:
> > https://gitlab.com/muttmua/mutt/wikis/MuttGuide/UseGPG
> > http://codesorcery.net/old/mutt/mutt-gnupg-howto
> >
>
> In the meantime NeoMutt != Mutt, so not to forget to mention
> . ;-)
Lol. Of course. I read that for my current setup. Though I never really
got to grips with what gpgme was, as I was more concerned with
bootstrapping a working (neo)mutt configuration, which is why I source
my : "14 ! long and cryptic command lines".

Thanks for the critique Floyd.

--

Roger Welsh
fpr: 2FCB 9E31 EA77 CDEC A3AE  5DD7 D54C C777 553A 180D


signature.asc
Description: PGP signature

Re: [gentoo-user] NeoMutt and GnuPG

[Floyd Anderson]

On Tue, 30 Jan 2018 20:48:02 -0800
Ian Zimmerman  wrote:

On 2018-01-31 05:17, Floyd Anderson wrote:


Instead I suggest to set ‘gpgme’ USE-flag and *only that* – no
‘crypt’, ‘gpg’, ‘pgp_classic’, ‘smime’, ‘smime_classic’. Look at the
ebuild and especially the comments. This way I only need to set one !
variable to get the stuff working:

set crypt_use_gpgme = yes


I second that.  This has been my setup for about a year and it just works.



Yes, and when not (and you are interested in) you may investigate what’s 
going on by invoking:


   `GPGME_DEBUG="9:/tmp/gpgme.log" neomutt`


--
Regards,
floyd

[gentoo-user] Re: NeoMutt and GnuPG

[Ian Zimmerman]

On 2018-01-31 05:17, Floyd Anderson wrote:

> Instead I suggest to set ‘gpgme’ USE-flag and *only that* – no
> ‘crypt’, ‘gpg’, ‘pgp_classic’, ‘smime’, ‘smime_classic’. Look at the
> ebuild and especially the comments. This way I only need to set one !
> variable to get the stuff working:
> 
> set crypt_use_gpgme = yes

I second that.  This has been my setup for about a year and it just works.

-- 
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] NeoMutt and GnuPG

[Floyd Anderson]

Hi Roger,

On Wed, 31 Jan 2018 15:01:39 +1300
"Roger J. H. Welsh"  wrote:

Hi Lucas,


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

It looks like you are using gpgme, I personally have not set this up for
my neomutt, instead I use a gpg.rc file from the samples provided.

For example;
bzcat /usr/share/doc/neomutt-*/samples/gpg.rc.bz2 > ~/.mutt/gpg.rc
echo "source ~/.mutt/gpg.rc" >> ~/.mutt/muttrc


I would not do that. The topic itself is complex enough and sourcing of 
14 ! long and cryptic command lines doesn’t make it better. Also note 
that gpg.rc defines the deprecated ‘pgp_clearsign_command’ variable.


BTW. as we‘re talking about NeoMutt here, I use:

${XDG_CONFIG_HOME:-${HOME}/.}${XDG_CONFIG_HOME:+/}neomutt/neomuttrc

so I can run a parallel Mutt installation when things get broken.

Instead I suggest to set ‘gpgme’ USE-flag and *only that* – no ‘crypt’, 
‘gpg’, ‘pgp_classic’, ‘smime’, ‘smime_classic’. Look at the ebuild and 
especially the comments. This way I only need to set one ! variable to 
get the stuff working:


set crypt_use_gpgme = yes


To be sure you may also set:

# ensure deprecated options are disabled or disarmed
set pgp_autoinline  = no
set pgp_clearsign_command   = ''
set pgp_mime_auto   = ask-yes
set pgp_replyinline = no


And if one like:

# semi-automated encrypted reply to encrypted messages
# Notes:
#- this can always be disabled by PGP-menu ('p')
#- crypt_autoencrypt or crypt_replyencrypt (if set) disables 
crypt_opportunistic_encrypt
set crypt_opportunistic_encrypt = yes
set crypt_autoencrypt   = no
set crypt_replyencrypt  = no

# whether or not display unusable (revoked, expired, disabled) keys
set pgp_show_unusable   = yes
set crypt_timestamp = no


With more than one mail address I suggest:
send2-hook  . 'set pgp_sign_as = ""'
send2-hook  '~f "1st@example\.net$"'  'set pgp_sign_as = 
"0x0123456789ABCDEF0123456789ABCDEF01234567"'
send2-hook  '~f "2nd@example\.net$"'  'set pgp_sign_as = 
"0xABCDEF0123456789ABCDEF0123456789ABCDEF01"'



On my neomutt, when I press "v" to view attachments, all I can
see is text/plain. I think my neomutt does something automatic to
decrypt the messages.



Indeed, viewing attachments encrypted would break many functions 
otherwise, e.g. piping, printing, saving.



My source docs I used when setting my gpg up with mutt were:
https://gitlab.com/muttmua/mutt/wikis/MuttGuide/UseGPG
http://codesorcery.net/old/mutt/mutt-gnupg-howto



In the meantime NeoMutt != Mutt, so not to forget to mention
. ;-)


--
Regards,
floyd

Re: [gentoo-user] prototype testing: request for test cases

[Michael Lienhardt]

Dear everyone,

up until now, I received 8 systems to test with our prototype, many thanks to 
all participants :).
I hope others will join!

I did 3 tests on these test cases and posted a short report on the forum: 
https://forums.gentoo.org/viewtopic-p-8177602.html#8177602

The short conclusion is that the prototype seems very promising (it found a 
solution for all adequate test cases, while emerge had various inconclusive 
suggestions for all of them), but many details must be improved.
Also some of the solutions found by our tool were not validated by emerge, and 
I need to check why.
It is probably due to the strange semantics of the compact form + default USE 
dependencies: emerge says that "sys-fs/eudev-3.1.5" cannot satisfy the 
following dependency
 
">=sys-fs/eudev-1.5.3-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,gudev(-),introspection(-)?,static-libs?]"
Does anyone know why? (I didn't check yet).

I'll continue working on the prototype and test it with the test case you give 
me.
Thank you!
Michael Lienhardt

Il 13/01/2018 19:50, Michael Lienhardt ha scritto:

Dear Everyone,

With some friends and colleagues, I implemented an alternative dependency 
solver for portage (as discussed here: 
https://forums.gentoo.org/viewtopic-t-1074202.html and 
https://forums.gentoo.org/viewtopic-t-1075286.html ).
We need your help to test it and possibly improve in the long run the already 
great portage toolset.

You can help us in two ways:
  - you can send us the zip generated by this bash script: 
https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh
    This bash script extracts your world file, the USE flags and keywords 
configuration of your system and the list of installed packages you have (it 
should not take more than few seconds).
    With this, we will see if our solver is able to recreate your system and 
how much time it takes.

  - you can propose installation challenges, i.e., sets of packages to install.
    With this, we will compare the answer and the response time between emerge 
and our solver.

You can send everything to my professional email: mlien...@di.unito.it

Thank you!
Michael Lienhardt

Re: [gentoo-user] NeoMutt and GnuPG

[Roger J. H. Welsh]

Hi Lucas,

> Here is my muttrc on github:
> https://github.com/lramage94/dotfiles/blob/master/.mutt/muttrc
It looks like you are using gpgme, I personally have not set this up for
my neomutt, instead I use a gpg.rc file from the samples provided.

For example;
bzcat /usr/share/doc/neomutt-*/samples/gpg.rc.bz2 > ~/.mutt/gpg.rc
echo "source ~/.mutt/gpg.rc" >> ~/.mutt/muttrc

There are a few other samples in
ls /usr/share/doc/neomutt-*/samples

Maybe there is something there that will fix your issue.

> When I send an encrypted message I see two files:
>
> - noname (1kb)
> - msg.asc (10kb) # <-- this one changes size depending on my message.
Whenever I see an encrypted message on my gmail account, which was
encrypted on my PC, I see the exact same thing. These are the raw
PGP/MIME type files for PGP, as opposed to inline PGP which is embedded
in the plain text.

https://security.stackexchange.com/questions/128368/is-using-pgp-mime-or-pgp-inline-more-secure

On my neomutt, when I press "v" to view attachments, all I can
see is text/plain. I think my neomutt does something automatic to
decrypt the messages.

My source docs I used when setting my gpg up with mutt were:
https://gitlab.com/muttmua/mutt/wikis/MuttGuide/UseGPG
http://codesorcery.net/old/mutt/mutt-gnupg-howto

I remember in particular reading the codesorcery one pretty closely.
Hope this helps.

--

Roger Welsh
fpr: 2FCB 9E31 EA77 CDEC A3AE  5DD7 D54C C777 553A 180D


signature.asc
Description: PGP signature

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

[Rich Freeman]

On Mon, Jan 29, 2018 at 11:35 PM, Nikos Chantziaras  wrote:
> 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 ?
>
> These flags are for *affected* applications only. That means application
> that: a) run third-party code, and b) do so in a sandbox.

While I agree that it doesn't make sense to go rebuilding everything
right now, I did want to caution that Spectre is probably a bit
wider-reaching than you're suggesting.

The sandboxed code issue is actually more of a problem with meltdown
as it doesn't require vulnerable interfaces to work - but meltdown has
nothing to do with gcc 7.3.  Meltdown does not require any process
vulnerability to work - it just requires a vulnerable CPU and data
mapped into virtual address space that shouldn't be accessible.

Spectre is more about having vulnerable functions in your code being
executable by untrusted code, acting on untrusted data.  Now, a lot of
sandboxes do have APIs in them that would be vulnerable, but the
problem goes beyond this.  Any kind of API/IPC mechanism, including
sockets, could potentially be exploitable, as long as it is
interacting with some kind of local process (perhaps indirectly).
Spectre is about using data to trick a process to leak state via the
side channel of the cache, and then using local code to probe the
cache.

If you had some program that listened on a socket and accepted a
length and a string and then did a bounds check using the length, it
might be exploitable if a local process could feed it data.  Even if
the process only listened for outside connections it might be
vulnerable if a local process colluded with a remote host to make that
connection.

Now, the more directly coupled the untrusted process is to the
vulnerable one the easier this would probably be to pull off. This is
why the kernel system call interface is so attractive.  That, and also
the fact that kernel memory is of course a high-value target.

How exploitable any particular process is depends a lot on the actual
code/etc.  Spectre should be seen as a class of vulnerabilities just
like buffer overflows.  Not every call to strcpy is vulnerable to a
buffer overflow, but it is certainly an opportunity for one.  Well, in
the same way things like bounds checks or indirect calls that are
associated with untrusted input are also opportunities.  I imagine
that other classes of Spectre will emerge over the coming years as
well.  To some degree compilers might be able to become smart enough
on their own to detect vulnerable code and add protections.  The
question is whether that can be done with little overhead, vs having
developers identify these points and mark them for the compiler (which
I think is the current approach).

Disclaimer: I'm definitely not a major authority in Spectre.  However,
the attack should not be considered limited to sandboxes and JIT and
such.

-- 
Rich

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

[Ian Zimmerman]

On 2018-01-29 20:35, Alexander Kapshuk wrote:

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

Unfortunately, this has the annoying side effect that kconfig forces a
full reconfiguration, asking every question.  Maybe there is a way
around that but looking at the complexity of the Makefile, I'm scared
to mess with it.

What I did in the end was to prepend the following to PATH:

/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0:

I use a pretty complex script for building kernels, so adding this to
the script was small potatoes.  And indeed, after a reboot I see I have
full mitigation against spectre_v2.  Now what about spectre_v1?

-- 
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] [off topic] Opteron CPU missing chips on the bottom

[R0b0t1]

On Tue, Jan 30, 2018 at 10:02 AM, taii...@gmx.com  wrote:
> On 01/30/2018 09:43 AM, Peter Humphrey wrote:
>
>> On Tuesday, 30 January 2018 13:51:31 GMT taii...@gmx.com wrote:
>>>
>>> I purchased a used g34 opteron off of fleabay (sold as working with no
>>> mention of this) and I noticed that it is missing some of the bits on
>>> the bottom
>>
>> Do you mean the pins that mate with the socket?
>>
>>> ... and that most of them are crooked,
>>
>> Send it back! Don't even touch it. Any attempt to straighten a pin will
>> snap
>> it off, as like as not.
>
> Not the pins (which on socket g34 are on the motherboard)
>
> It is the little IC components on the bottom of the CPU.
>

You should return it, most of those components are decoupling
capacitors. Quickly switching power produces high frequency noise that
can migrate to other parts of the circuit and cause spurious logic
errors.

It probably plugs in and turns on but I would not accept such a part.

Cheers,
 R0b0t1

Re: [gentoo-user] [off topic] Opteron CPU missing chips on the bottom

[Dale]

taii...@gmx.com wrote:
> On 01/30/2018 09:43 AM, Peter Humphrey wrote:
>
>> On Tuesday, 30 January 2018 13:51:31 GMT taii...@gmx.com wrote:
>>> I purchased a used g34 opteron off of fleabay (sold as working with no
>>> mention of this) and I noticed that it is missing some of the bits on
>>> the bottom
>> Do you mean the pins that mate with the socket?
>>
>>> ... and that most of them are crooked,
>> Send it back! Don't even touch it. Any attempt to straighten a pin
>> will snap
>> it off, as like as not.
> Not the pins (which on socket g34 are on the motherboard)
>
> It is the little IC components on the bottom of the CPU.
>
>


Could you attach a photo or a link to one?  Maybe seeing it wouold help.

Dale

:-)  :-) 

Re: [gentoo-user] [off topic] Opteron CPU missing chips on the bottom

[taii...@gmx.com]

On 01/30/2018 09:43 AM, Peter Humphrey wrote:


On Tuesday, 30 January 2018 13:51:31 GMT taii...@gmx.com wrote:

I purchased a used g34 opteron off of fleabay (sold as working with no
mention of this) and I noticed that it is missing some of the bits on
the bottom

Do you mean the pins that mate with the socket?


... and that most of them are crooked,

Send it back! Don't even touch it. Any attempt to straighten a pin will snap
it off, as like as not.

Not the pins (which on socket g34 are on the motherboard)

It is the little IC components on the bottom of the CPU.

Re: [gentoo-user] [off topic] Opteron CPU missing chips on the bottom

[Peter Humphrey]

On Tuesday, 30 January 2018 13:51:31 GMT taii...@gmx.com wrote:
> I purchased a used g34 opteron off of fleabay (sold as working with no
> mention of this) and I noticed that it is missing some of the bits on
> the bottom

Do you mean the pins that mate with the socket?

> ... and that most of them are crooked,

Send it back! Don't even touch it. Any attempt to straighten a pin will snap 
it off, as like as not.

--->8

> I noticed many CPU's sold on ebay have this issue (in those cases they
> mentioned it) but I can't understand how it happens, for instance I
> noticed a 6386 for sale where they mentioned that it was missing a few
> and because of that it doesn't work in a dual socket configuration.

Sometimes a CPU chip comes out faulty in the specific respect that it can't 
operate in SMP, so those pins are removed and the chip is sold as a 
monoprocessor.

-- 
Regards,
Peter.

[gentoo-user] [off topic] Opteron CPU missing chips on the bottom

[taii...@gmx.com]

I purchased a used g34 opteron off of fleabay (sold as working with no 
mention of this) and I noticed that it is missing some of the bits on 
the bottom and that most of them are crooked, I haven't tried it in my 
system yet and I am wondering should return it? or if there isn't any 
much risk of it damaging my (expensive kgpe-d16) motherboard and I 
should see if it works?


Igot it for half the usual priceguess I should have asked for photos.

I noticed many CPU's sold on ebay have this issue (in those cases they 
mentioned it) but I can't understand how it happens, for instance I 
noticed a 6386 for sale where they mentioned that it was missing a few 
and because of that it doesn't work in a dual socket configuration.

Re: [gentoo-user] rust 1.23.0 fails to install

[John Covici]

On Tue, 30 Jan 2018 04:27:18 -0500,
Floyd Anderson wrote:
> 
> Hi John,
> 
> On Mon, 29 Jan 2018 16:58:56 -0500
> John Covici  wrote:
> > 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.
> > 
> 
> Maybe a resync for dev-lang/rust-1.23.0-r1::gentoo helps. But
> before you emerge, be aware of bug #646092 [1] (where I also ran
> into). For me [2] solves the described issue.
> 
> 
> References:
>  - [1] 
>  - [2] 
> 
> 
> -- 
> Regards,
> floyd
> 
> 

OK, I will check that out -- thanks.

-- 
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] rust 1.23.0 fails to install

[John Covici]

On Tue, 30 Jan 2018 03:29:55 -0500,
Mick wrote:
> 
> [1  ]
> On Monday, 29 January 2018 21:58:56 GMT John Covici wrote:
> > 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" }
>   ^^^
> Is your /usr/src/linux symlink pointing to a valid kernel tree?
Absolutely.  I am using an unstable system.
> 
> 
> > 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.
> 
> 
> PS.  Here on stable systems portage decided to uninstall all rust packages it 
> had installed recently as firefox dependencies and then downgraded firefox to 
> 52.6.0.
>

-- 
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] Removal of media-plugins/npapi-vlc

[Thomas Schmitz]

Hi Petric,

as far as I know the VLC browser plugin allows you to play back media using
VLC. However in my opinion you don't need that. Firefox has its own
playback backend and hence it can play back media without the VLC plugin.

So I think you shouldn't run into any issues if you don't use npapi-vlc. To
my understanding Firefox bundles its own codecs unless specified otherwise
through USE flags.


Regards

Thomas Schmitz

On 30 January 2018 at 11:50, Petric Frank  wrote:

> Hello,
>
> during an upgrade i got a message that media-plugins/npapi-vlc have been
> masked and being removed from portage.
>
> The reasoning is understandable (Firefox removes NPAPI interface). But
> what to
> use instead ?
>
> kind regards
>   Petric
>
>
>

[gentoo-user] Removal of media-plugins/npapi-vlc

[Petric Frank]

Hello,

during an upgrade i got a message that media-plugins/npapi-vlc have been 
masked and being removed from portage.

The reasoning is understandable (Firefox removes NPAPI interface). But what to 
use instead ?

kind regards
  Petric

Re: [gentoo-user] NeoMutt and GnuPG

[Floyd Anderson]

Hi Lucas,

On Mon, 29 Jan 2018 15:20:23 -0500
Lucas Ramage  wrote:


When I send an encrypted message I see two files:

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



please be more specific, i.e. where did you see those two lines of 
files? In the attachment menu (after sending the mail) or compose menu 
(before you send the mail)? Can you see anchor pairs:


   -BEGIN PGP MESSAGE-
   -END PGP MESSAGE-

with your mail selected and after invoking :exec view-raw-message from 
NeoMutt’s command prompt?


Also, what is the version of your NeoMutt and the USE-flags.

--
Regards,
floyd

Re: [gentoo-user] rust 1.23.0 fails to install

[Floyd Anderson]

Hi John,

On Mon, 29 Jan 2018 16:58:56 -0500
John Covici  wrote:

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.



Maybe a resync for dev-lang/rust-1.23.0-r1::gentoo helps. But before you 
emerge, be aware of bug #646092 [1] (where I also ran into). For me [2] 
solves the described issue.



References:
 - [1] 
 - [2] 


--
Regards,
floyd

Re: [gentoo-user] rust 1.23.0 fails to install

[Mick]

On Monday, 29 January 2018 21:58:56 GMT John Covici wrote:
> 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" }
  ^^^
Is your /usr/src/linux symlink pointing to a valid kernel tree?


> 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.


PS.  Here on stable systems portage decided to uninstall all rust packages it 
had installed recently as firefox dependencies and then downgraded firefox to 
52.6.0.

-- 
Regards,
Mick

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