[gentoo-user] Portage, git and shallow cloning

[Davyd McColl]

I'm not sure if there's a better place to put this, so please feel free to
tell me I should report it elsewhere (:

After the recent GitHub fun, I changed from using the GitHub git source to
git://anongit.gentoo.org/repo/sync/gentoo.git, as suggested by some on this
mailing list. I completely nuked /usr/portage/* and set off with an `emerge
--sync`, which looked like it was going to take ages and clone about a gig.
Reading https://wiki.gentoo.org/wiki/Project:Portage/Sync, I figured there
was nothing much I could do about it, since the page speaks of the
`sync-depth` config option and states that 1 is "shallow clone, only
current state (*default if option is absent*)" (emphasis mine).
After multiple failures to clone (other side hangs up after a few minutes
-- I only have a 4mbps line, maxing out at around 450Kb/s), I thought I'd
try explicitly setting `sync-depth` in my repo config and found:

1) `sync-depth` has been deprecated (should now use `clone-depth`)
2) with the option missing, portage was fetching the entire history --
after adding the option (and nuking /usr/portage/* again), a new clone
happened in short order, bringing down only around 65Mb (according to git)

So I'd like to ask how to assist in rectifying the above:
1) the docs need to be updated to refer to `clone-depth`
2) I believe that the original intent of defaulting to a shallow clone was
a good idea -- perhaps that can be investigated. If the intent has changed
for some reason, the docs should be updated to reflect the change.

Thanks
-d

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing

Which is stupid.

- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY

*Quidquid latine dictum sit, altum sonatur. *

Re: [gentoo-user] How to update public keys?

[Marc Joliet]

Am Donnerstag, 5. Juli 2018, 23:37:53 CEST schrieb Marc Joliet:
> Am Donnerstag, 5. Juli 2018, 21:22:15 CEST schrieb Grant Edwards:
> [SNIP]
> 
> For those still having this problem, see https://bugs.gentoo.org/659914#c9.
> 
> In my case I just ran my usual "emerge -uDUva @world", which updated to the
> new app-crypt/openpgp-keys-gentoo-release-20180703 despite the sync failure
> (a problem that Rich described several times over the last few days); after
> all, what's one more unverified sync after this long?  Afterwards I synced
> again to verify that the problem was actually gone.
> 
> HTH

(Shouldn't have snipped everything, dammit.)

To be specific, I meant this particular problem:

!!! Manifest verification failed:
OpenPGP verification failed:
gpg: Signature made Thu 05 Jul 2018 06:38:32 PM UTC
gpg:using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: Can't check signature: No public key

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


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

Re: [gentoo-user] Re: How to update public keys?

[Mick]

On Thursday, 5 July 2018 23:05:51 BST Grant Edwards wrote:
> On 2018-07-05, Grant Edwards  wrote:
> > On 2018-07-05, Grant Edwards  wrote:
> >> On 2018-07-05, Grant Edwards  wrote:
> >>> As of today, I seem to be unable to a an "emerge --sync".
> >> 
> >>> The process either hangs forever at the "Refreshing keys from keyserver 
step:
> >> [...]
> >> 
> >>> Or, it fails because there are no public key to verify a manfest:
> >> For now, I've had to set add "sync-rsync-verify-metamanifest = no" to
> >> my repo conf file so that I can actually do updates, but that seems
> >> like a dangerous work-around.
> > 
> > After turning off sync-rsync-verify-metamanifest and doing a sync and
> > update (which included app-crypt/openpgp-keys-gentoo-release-20180703),
> > 
> > I had hoped that I would be able to turn it back on, but now I get this:
> > # emerge --sync
> > 
> > >>> Syncing repository 'gentoo' into '/usr/portage'...
> >  
> >  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> > 
> >  * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
> > gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
> > gpg: keyserver refresh failed: General error
> > 
> > OpenPGP keyring refresh failed:
> > gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
> > gpg: keyserver refresh failed: General error
> > 
> > OpenPGP keyring refresh failed:
> > gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
> > gpg: keyserver refresh failed: General error
> > 
> > The last four lines repeat forever with an increasingly longer period.
> 
> I never did figure what was causing the "General error".  After about
> an hour of googling and reading descriptions of unrelated problems, it
> just started working with no changes to any configuration.  Apparently
> a server issue?

It could be a congestion issue.  I have noticed the same with different key 
servers at times.
-- 
Regards,
Mick

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

[gentoo-user] Re: How to update public keys?

[Grant Edwards]

On 2018-07-05, Grant Edwards  wrote:
> On 2018-07-05, Grant Edwards  wrote:
>> On 2018-07-05, Grant Edwards  wrote:
>>> As of today, I seem to be unable to a an "emerge --sync".
>>>
>>> The process either hangs forever at the "Refreshing keys from keyserver 
>>> step:
>>
>> [...]
>>
>>> Or, it fails because there are no public key to verify a manfest:
>>
>> For now, I've had to set add "sync-rsync-verify-metamanifest = no" to
>> my repo conf file so that I can actually do updates, but that seems
>> like a dangerous work-around.
>
> After turning off sync-rsync-verify-metamanifest and doing a sync and
> update (which included app-crypt/openpgp-keys-gentoo-release-20180703),
> I had hoped that I would be able to turn it back on, but now I get this:
>
> # emerge --sync
> >>> Syncing repository 'gentoo' into '/usr/portage'...
>  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
>  * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
> gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
> gpg: keyserver refresh failed: General error
> 
> OpenPGP keyring refresh failed:
> gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
> gpg: keyserver refresh failed: General error
> 
> OpenPGP keyring refresh failed:
> gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
> gpg: keyserver refresh failed: General error
> 
> The last four lines repeat forever with an increasingly longer period.

I never did figure what was causing the "General error".  After about
an hour of googling and reading descriptions of unrelated problems, it
just started working with no changes to any configuration.  Apparently
a server issue?

-- 
Grant Edwards   grant.b.edwardsYow! I didn't order any
  at   WOO-WOO ... Maybe a YUBBA
  gmail.com... But no WOO-WOO!

Re: [gentoo-user] How to update public keys?

[Marc Joliet]

Am Donnerstag, 5. Juli 2018, 21:22:15 CEST schrieb Grant Edwards:
[SNIP]

For those still having this problem, see https://bugs.gentoo.org/659914#c9.

In my case I just ran my usual "emerge -uDUva @world", which updated to the 
new app-crypt/openpgp-keys-gentoo-release-20180703 despite the sync failure (a 
problem that Rich described several times over the last few days); after all, 
what's one more unverified sync after this long?  Afterwards I synced again to 
verify that the problem was actually gone.

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


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

[gentoo-user] Re: How to update public keys?

[Grant Edwards]

On 2018-07-05, Grant Edwards  wrote:
> On 2018-07-05, Grant Edwards  wrote:
>> As of today, I seem to be unable to a an "emerge --sync".
>>
>> The process either hangs forever at the "Refreshing keys from keyserver step:
>
> [...]
>
>> Or, it fails because there are no public key to verify a manfest:
>
> For now, I've had to set add "sync-rsync-verify-metamanifest = no" to
> my repo conf file so that I can actually do updates, but that seems
> like a dangerous work-around.

After turning off sync-rsync-verify-metamanifest and doing a sync and
update (which included app-crypt/openpgp-keys-gentoo-release-20180703),
I had hoped that I would be able to turn it back on, but now I get this:

# emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

The last four lines repeat forever with an increasingly longer period.

Firing up wireshark shows that for each of those failures, there's a
TLS 1.2 connection to port 443 at hkps.pool.sks-keyservers.net which
gets set up, negotiated, and then closed.

-- 
Grant Edwards   grant.b.edwardsYow! Hello...  IRON
  at   CURTAIN?  Send over a
  gmail.comSAUSAGE PIZZA!  World War
   III?  No thanks!

Re: [gentoo-user] Re: How to update public keys?

[Dale]

Grant Edwards wrote:
> On 2018-07-05, Grant Edwards  wrote:
>> As of today, I seem to be unable to a an "emerge --sync".
>>
>> The process either hangs forever at the "Refreshing keys from keyserver step:
> [...]
>
>> Or, it fails because there are no public key to verify a manfest:
> For now, I've had to set add "sync-rsync-verify-metamanifest = no" to
> my repo conf file so that I can actually do updates, but that seems
> like a dangerous work-around.
>
> Is access to a keyserver via TCP port 11371 now a requirement for
> using portage?
>
> Is there any other way to get keys updated that only requires the
> normal https and rsync access?
>


For those having this problem, may I suggest this.  Look at the USE
flags here for portage.


[ebuild   R    ] sys-apps/portage-2.3.40-r1::gentoo  USE="(ipc)
native-extensions rsync-verify xattr -build -doc -epydoc -gentoo-dev
(-selinux)" PYTHON_TARGETS="python2_7 python3_5 (-pypy) -python3_4
-python3_6"


It seems to me that one could emerge portage with rsync-verify USE flag
disabled.  After that, do one update, hopefully that will update the
keys etc and then emerge portage again with the USE flag enabled. 
Hopefully after that one time workaround, the keys will be updated and
things will work like they should.

It seems to me that a perfect set of problems popped up at a rather bad
time.  It seems some keys expired AND the verify option which requires
those keys was enabled.  Now you have a catch 22 problem since you can't
get the new keys and verify at the same time due to the expired/bad
keys.  Add in the recent git issue and it has folks a little touchy
about working around this problem.   

I suspect one could use some variable on the command line or in
make.conf as a one time workaround as well. 

Would this work for everyone, rsync, websync and git or am I missing
something else?  Could this at least lead to a fix that everyone should
be able to use???

Dale

:-)  :-) 

[gentoo-user] Re: How to update public keys?

[Grant Edwards]

On 2018-07-05, Jalus Bilieyich  wrote:
> You just need to use Gentoo's built-in script from gentoolkit.
>
> Just run:
>
> # etc-update
>
> And overwrite the current config file you have (trust me, it's safe).

No help.  All that did was update the sshd config file by adding the following:

AcceptEnv COLORTERM

-- 
Grant Edwards   grant.b.edwardsYow! The Korean War must
  at   have been fun.
  gmail.com

[gentoo-user] Re: How to update public keys?

[Grant Edwards]

On 2018-07-05, Grant Edwards  wrote:
> As of today, I seem to be unable to a an "emerge --sync".
>
> The process either hangs forever at the "Refreshing keys from keyserver step:

[...]

> Or, it fails because there are no public key to verify a manfest:

For now, I've had to set add "sync-rsync-verify-metamanifest = no" to
my repo conf file so that I can actually do updates, but that seems
like a dangerous work-around.

Is access to a keyserver via TCP port 11371 now a requirement for
using portage?

Is there any other way to get keys updated that only requires the
normal https and rsync access?

-- 
Grant Edwards   grant.b.edwardsYow! If I had a Q-TIP, I
  at   could prevent th' collapse
  gmail.comof NEGOTIATIONS!!

Re: [gentoo-user] How to update public keys?

[Jalus Bilieyich]

You just need to use Gentoo's built-in script from gentoolkit.

Just run:

# etc-update

And overwrite the current config file you have (trust me, it's safe).

On 7/5/18, Grant Edwards  wrote:
> As of today, I seem to be unable to a an "emerge --sync".
>
> The process either hangs forever at the "Refreshing keys from keyserver
> step:
>
> # emerge --sync
> >>> Syncing repository 'gentoo' into '/usr/portage'...
>  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
>  * Refreshing keys from keyserver ...
>
> Or, it fails because there are no public key to verify a manfest:
>
> # emerge --sync
> >>> Syncing repository 'gentoo' into '/usr/portage'...
>  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
>  * Refreshing keys from keyserver ...
>  [ ok ]
> >>> Starting rsync with rsync://156.56.247.193/gentoo-portage...
> [...]
> receiving incremental file list
> timestamp.chk
>
> Number of files: 1 (reg: 1)
> [...]
> sent 109 bytes  received 1.15K bytes  838.00 bytes/sec
> total size is 32  speedup is 0.03
> -
> [...]
> receiving incremental file list
> metadata/timestamp.chk
>
> Number of files: 161,932 (reg: 134,486, dir: 27,446)
> [...]
> sent 27.56K bytes  received 4.04M bytes  626.31K bytes/sec
> total size is 218.65M  speedup is 53.71
> !!! Manifest verification failed:
> OpenPGP verification failed:
> gpg: Signature made Thu 05 Jul 2018 06:38:32 PM UTC
> gpg:using RSA key
> E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
> gpg: Can't check signature: No public key
>
> q: Updating ebuild cache in /usr/portage ...
> q: Finished 35635 entries in 0.141629 seconds
>
>  * IMPORTANT: config file '/etc/ssh/sshd_config' needs updating.
>  * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
>  * sections of the emerge man page to learn how to update config files.
>
> Action: sync for repo: gentoo, returned code = 1
>
> I've found all sorts of recipes to try to fix this for webrsync users
> but I use plain-old "emerge --sync".
>
> I also found a recipe that appears to recommend you completely wipe
> portage and reinstall it from scratch using a snapshot.Is that
> seriously what we're supposed to do?
>
> --
> Grant
>
>
>

[gentoo-user] How to update public keys?

[Grant Edwards]

As of today, I seem to be unable to a an "emerge --sync".

The process either hangs forever at the "Refreshing keys from keyserver step:

# emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ... 

Or, it fails because there are no public key to verify a manfest:

# emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ...   
  [ ok ]
>>> Starting rsync with rsync://156.56.247.193/gentoo-portage...
[...]
receiving incremental file list
timestamp.chk

Number of files: 1 (reg: 1)
[...]
sent 109 bytes  received 1.15K bytes  838.00 bytes/sec
total size is 32  speedup is 0.03
-
[...]
receiving incremental file list
metadata/timestamp.chk

Number of files: 161,932 (reg: 134,486, dir: 27,446)
[...]
sent 27.56K bytes  received 4.04M bytes  626.31K bytes/sec
total size is 218.65M  speedup is 53.71
!!! Manifest verification failed:
OpenPGP verification failed:
gpg: Signature made Thu 05 Jul 2018 06:38:32 PM UTC
gpg:using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: Can't check signature: No public key

q: Updating ebuild cache in /usr/portage ... 
q: Finished 35635 entries in 0.141629 seconds

 * IMPORTANT: config file '/etc/ssh/sshd_config' needs updating.
 * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
 * sections of the emerge man page to learn how to update config files.

Action: sync for repo: gentoo, returned code = 1

I've found all sorts of recipes to try to fix this for webrsync users
but I use plain-old "emerge --sync".

I also found a recipe that appears to recommend you completely wipe
portage and reinstall it from scratch using a snapshot.Is that
seriously what we're supposed to do?

-- 
Grant

Re: [gentoo-user] [Maybe OT]: Instability of system

[Alan Mackenzie]

On Sun, Jun 10, 2018 at 19:18:25 +, Alan Mackenzie wrote:
> Hello again, Dale.

> On Sun, Jun 10, 2018 at 11:23:14 -0500, Dale wrote:

> > To, OP.  I was hoping you found a solution.  Maybe you will at some
> > point,  You have certainly eliminated a lot of potential causes.  I
> > can't recall if you have or not, have you tried a different version of
> > the kernel?  In the past, I've upgraded to a new kernel and it be
> > buggy.  I go back to a older version until I see a new update then try
> > again.  Generally it works.  Don't know if it was a kernel bug or just
> > some stray code that something didn't like but . . .

> I've been running on my (no longer quite so) new box since about last
> August.  I don't recall crashes from that long ago, though that could be
> to do with my memory.

> I've just configured and build a 4.17.0 kernel (thanks for the
> suggestion!), having previously been running on 4.15.15 for quite some
> time.  Maybe this will help.  We'll see.

I was about to post saying my problem appeared solved.  But not ten
minutes ago, my system hung for the first time with it's 4.17.0 kernel.
:-(

It's annoying, and unsettling, but living with it might be the least
worst option.

> > Dale

> > :-)  :-) 

-- 
Alan Mackenzie (Nuremberg, Germany).

[gentoo-user] How to recover gentoo keys and verify portage following recent update debacle

[Mick]

My use case may be slightly different to others who use git or webrsync.  I've 
always used rsync to keep portage up to date.  Since the portage gentoo keys 
went out of sync a couple of days ago I ended up like other gentoo users with 
a 'chicken and egg' situation.  The rsync process would fail verification 
because the public key was not available without app-crypt/openpgp-keys-
gentoo-release first being updated to the latest 20180703 version.

A poster on another thread has provided advice on using gemato to verify the 
gentoo keys, but I don't know or understand the process gemato follows to just 
type incantations on a keyboard and hope for the best.

The process I ended up using involved:

- removing all stale portage files;
- refreshing the gentoo keys manually;
- downloading the latest portage snapshot md5sum and its gpg signature;
- verifying the snapshot with gpg and using it to install the latest app-
crypt/openpgp-keys-gentoo-release.

You may find all this too radical for your needs, but I post it here in case 
others benefit from it.


1. Fetch the gentoo keys on your user keyring:

>From Gentoo Release media signatures web page[1] I can see the fingerprint of 
the Gentoo Portage Snapshot Signing Key is 0xDB6B8C1F96D8BF6D.

I assumed here if this key had gone bad then Release Engineering would have 
replaced it by now.

$ gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0xDB6B8C1F96D8BF6D

This downloads all keys and signatures.

$ gpg --check-signatures 0xDB6B8C1F96D8BF6D

The output shows the signature on the keyserver is still valid and has not 
been revoked.


2. Remove stale portage and download the latest portage snapshot from your 
local mirror[2]:

# cd /usr
# rm -Rf portage/*
# wget /snapshots/portage-latest.tar.xz*


3. Verify the snapshot was signed by the gentoo keys:

$ cd /usr
$ gpg --verify portage-latest.tar.xz.gpgsig portage-latest.tar.xz
gpg: enabled debug flags: memstat
gpg: Signature made Thu Jul  5 01:51:21 2018 BST
gpg:using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: using subkey EC590EEAC9189250 instead of primary key DB6B8C1F96D8BF6D
gpg: using classic trust model
gpg: Good signature from "Gentoo ebuild repository signing key (Automated 
Signing Key) " [unknown]
gpg: aka "Gentoo Portage Snapshot Signing Key (Automated 
Signing Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: DCD0 5B71 EAB9 4199 527F  44AC DB6B 8C1F 96D8 BF6D
 Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F  DF1C EC59 0EEA C918 9250
gpg: binary signature, digest algorithm SHA512, key algorithm rsa4096
gpg: keydb: handles=2 locks=0 parse=0 get=3
gpg:build=0 update=0 insert=0 delete=0
gpg:reset=1 found=3 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=18 cached=18 good=18 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
  outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x calls=0 bytes=0
gpg: secmem usage: 0/65536 bytes in 0 blocks

OK, the "Good signature" message above and the correct fingerprint is an 
encouraging indication.  Had I selected to trust this key the signature would 
be shown as trusted.


4. Untar the snapshot into portage/

# tar -xvf portage-latest.tar.xz


5. Install the latest app-crypt/openpgp-keys-gentoo-release-20180703

# emerge -1aDv app-crypt/openpgp-keys-gentoo-release


6. Remove uneeded files:

# rm -Rf portage-latest.tar.xz*


7. Sync your portage as usual, in my case:

# eix-sync

This time the verification process completes without any complains about 
public keys missing:

..
Number of files: 161,932 (reg: 134,484, dir: 27,448)
Number of created files: 25 (reg: 24, dir: 1)
Number of deleted files: 13 (reg: 13)
Number of regular files transferred: 118
Total file size: 218.65M bytes
Total transferred file size: 2.67M bytes
Literal data: 2.67M bytes
Matched data: 0 bytes
File list size: 3.41M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 32.27K
Total bytes received: 5.88M

sent 32.27K bytes  received 5.88M bytes  358.23K bytes/sec
total size is 218.65M  speedup is 36.99
 * Manifest timestamp: 2018-07-05 15:38:30 UTC
 * Manifest timestamp: 2018-07-05 15:38:30 UTC
 * Valid OpenPGP signature found:
 * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
total size is 218.65M  speedup is 36.99
 * Manifest timestamp: 2018-07-05 15:38:30 UTC
 * Valid OpenPGP signature found:
 * Valid OpenPGP signature found:
 * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
 * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
 * - timestamp: 2018-07-05 15:38:30 UTC
 * - timestamp: 2018-07-05 15:38:30 UTC
 * Verifying /usr/portage ...[ ok ]
=== Sync completed for 

Re: [gentoo-user] syncing via via git and signature failure

[Floyd Anderson]

On Wed, 04 Jul 2018 22:57:05 -0400
John Covici  wrote:


I got the following when running your command:
gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/
INFO:root:Refreshing keys from keyserver...
INFO:root:Keys refreshed.


To be more specific, I wasn't interested in verifying the tree. My main 
goal was to get:


 INFO:root:Keys refreshed.

because my sync/update script hung at:

 INFO:root:Refreshing keys from keyserver...

all the time, caused by:

 gpg: Can't check signature: No public key

result, so I wasn't able to update.


ERROR:root:Top-level Manifest not found in /usr/portage/

How can I fix, or do I need to fix?


I've no idea why your portage tree doesn't have a top-level Manifest 
file (assuming "/usr/portage" is the location of your tree), but it 
should be created/updated on next syncing.



--
Regards,
floyd

[gentoo-user] Re: All Gentoo signing key expired and no way to fix it

[Grant Edwards]

On 2018-07-04, gevisz  wrote:
> 2018-07-04 21:00 GMT+03:00 Jack :
>> On 2018.07.04 13:38, gevisz wrote:

>>> I hate using sudo since I have been forced to use it in Ubuntu.
>>
>> I almost never used sudo when I used Ubuntu.  I used su or logged in as root
>> when necessary.
>
> It is quite strange because, when I used Ubuntu, it had no root account,
> and so, everybody was forced to use sudo to get root privileges.

Nonsense.

Ubuntu has always had a root account, and still does [see below].  By
default the installer doesn't set up a password for the root account,
but that's trivial to do after the install is finished.




$ cat /etc/os-release 

NAME="Ubuntu"
VERSION="18.04 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash

-- 
Grant Edwards   grant.b.edwardsYow! PARDON me, am I
  at   speaking ENGLISH?
  gmail.com

Re: [gentoo-user] All Gentoo signing key expired and no way to fix it

[Rich Freeman]

On Wed, Jul 4, 2018 at 1:34 PM Rich Freeman  wrote:
>
> I wonder if we can have portage instead do a fetch, then do the
> verification of HEAD, and then if it passes do a checkout.  That will
> still leave you with invalid data in the git history, but it won't
> actually be checked out, so at least emerge won't be seeing it.
>

Kudos to zmedico on the quick patch:
https://github.com/gentoo/portage/pull/332/commits/74c3b10dba60bcb096404c6aca148b9ae7a9a80b

I'm sure it will be a bit before it is released, but this should make
git syncs much more secure.

-- 
Rich

Re: [gentoo-user] Firefox & ALSA

[Andrew Lowe]

On 05/07/18 08:54, Adam Carter wrote:
>         Does anyone know of a reason why this would happen?
> 
> 
> Is firefox built with pulseaudio? If so, check the pavucontrol settings
> too (media-sound/pavucontrol)
> 
> Perhaps VLC is talking directly to ALSA, but firefox is talking to
> pulseaudio to get to ALSA, and there's an issue with pulse hence the
> discrepancy between VLC and firefox.

No PulseAudio on the machine, Lennart makes my skin crawl, and I think
you can infer from that that there has never been PulseAudio on the
machine. It basically boils down to:

Before holiday -> Firefox/Youtube makes noise.

Go away for a holiday

Come back from holiday

Turn on computer -> no boot, "dead in the water", "this is an ex-parrot".
...
...
...
etc

Whilst writing this I had a brain wave. Was Firefox
hardcoded/defaulting to "reading/writing/working" the first discovered
sound card? I subsequently removed the tricks that I had done to get VLC
working and rebooted. No sound as expected. "lspci -nn | grep -i audio"
and "aplayer -l" shows the nVidia chip to be first:

0a:00.1 Audio device [0403]: NVIDIA Corporation GP106 High Definition
Audio Controller [10de:10f1] (rev a1)
0c:00.3 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Device
[1022:1457]

so can I disable the HDMI sound chip with an ebuild option in the nvidia
ebuild - it appears not. Next can I reorder the discovery/assignment
process?

More googling found:

https://www.linuxquestions.org/questions/linux-hardware-18/wrong-sound-card-order-in-alsa-4175544059/

and

http://docs.slackware.com/howtos:hardware:audio_and_snd-hda-intel

which resulted in me having to rebuild my kernel as I usually have
everything linked in, no modules, and updating the

/etc/modprobe.d/alsa.conf

file. I added the lines below. Note that the vid & pid values for the
AMD are now assigned first.

alias snd-card-0 snd-hda-intel
alias snd-card-1 snd-hda-intel
options snd-hda-intel index=0 vid=1022 pid=1457
options snd-hda-intel index=1 vid=10de pid=10f1

A reboot and I now have sound everywhere - YEAH!!

There is every chance that someone way more versed in the innards of
the boot process may indicate holes in the above but hey, it works.

Andrew

Re: [gentoo-user] Multilib blues continues

[Zoltán Kócsi]

On Thu, 05 Jul 2018 12:06:53 +0200
Kai Peter  wrote:

> On 2018-07-05 09:09, Zoltán Kócsi wrote:
> [...]
> See bug 604802 (https://bugs.gentoo.org/604802).
> 
> Workaround: unmerge gperf, merge libpcap, afterwards merge gperf
> again.
> 
> For an 'emerge -e @world', temporarily downgrade to gperf-3.0.4
> before.

Thanks!

Zoltan

Re: [gentoo-user] Multilib blues continues

[Kai Peter]

On 2018-07-05 09:09, Zoltán Kócsi wrote:

The */* x86_ ... in the use file and asking emerge to re-build the
libraries is pretty cool for building both 64 and 32 bit libs.

But it has it's problems, it seems.
The library libcap fails to compile with some spectacular errors:

--
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -Wall -Wwrite-strings
-Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -Wall
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g  -fPIC
-I/var/tmp/portage/sys-libs/libcap-2.24-r2/work/libcap-2.24-abi_x86_32.x86/libcap/../libcap/include/uapi
-I/var/tmp/portage/sys-libs/libcap-2.24-r2/work/libcap-2.24-abi_x86_32.x86/libcap/../libcap/include
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -c cap_file.c -o
cap_file.o
In file included from :0:0:
./_caps_output.gperf:71:80: error: unknown type name 'size_t'
 gperf_case_strncmp (register const char *s1, register const char *s2,
register size_t n)

 ^~
./_caps_output.gperf:96:53: error: unknown type name 'size_t'
 __cap_hash_name (register const char *str, register size_t len)
 ^~
./_caps_output.gperf:197:55: error: unknown type name 'size_t'
 __cap_lookup_name (register const char *str, register size_t len)
   ^~
./_caps_output.gperf:197:1: error: conflicting types for 
'__cap_lookup_name'

 __cap_lookup_name (register const char *str, register size_t len)
 ^
./_caps_output.gperf:33:29: note: previous declaration of
'__cap_lookup_name' was here
 const struct __cap_token_s *__cap_lookup_name(const char *, unsigned 
int);

 ^
cap_text.c: In function 'cap_to_name':
cap_text.c:291:2: warning: ignoring return value of 'asprintf',
declared with attribute warn_unused_result [-Wunused-result]
  asprintf(, "%u", cap);
  ^
make[1]: *** [Makefile:84: cap_text.o] Error 1


If it can't find size_t then for some reason it fails to include
pretty much any standard header. Which is supported by the
"included from " pip from gcc. Obviously, whatever
generates the _caps_output.gperf file made a mistake, both not
including the standard headers and also with declaration of the
__cap_lookup_name() function.

Considering that libcap builds happily on a 64-bit system and I assume
would also build on 32-bit one, the problem must be with the magic
required to build a 32-bit version on a 64-bit machine.

Should it be considered a bug worthy of reporting?

Thanks,

Zoltan


See bug 604802 (https://bugs.gentoo.org/604802).

Workaround: unmerge gperf, merge libpcap, afterwards merge gperf again.

For an 'emerge -e @world', temporarily downgrade to gperf-3.0.4 before.

--
Sent with eQmail-1.11 beta

Re: [gentoo-user] syncing via via git and signature failure

[gevisz]

2018-07-05 1:25 GMT+03:00 Mick :
> On Wednesday, 4 July 2018 19:32:33 BST gevisz wrote:
>> 2018-07-04 21:01 GMT+03:00 Mick :
>> > On Wednesday, 4 July 2018 18:57:56 BST gevisz wrote:
>> >> 2018-07-04 11:55 GMT+03:00 Alex Thorne :
>> >> >> I use rsync and get the following for more than a day now;
>> >> >>
>> >> >> !!! Manifest verification failed:
>> >> >> OpenPGP verification failed:
>> >> >> gpg: Signature made Wed 04 Jul 2018 04:08:28 AM UTC
>> >> >> gpg:using RSA key
>> >> >> E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
>> >> >> gpg: Can't check signature: No public key
>> >> >
>> >> > I'm seeing this too. For me `app-crypt/gentoo-keys` is somehow no
>> >> > longer installed and `/var/lib/gentoo/gkeys` is missing. I have no idea
>> >> > how this happened. Perhaps it somehow got into `emerge --depclean`
>> >> > and I didn't catch it.
>> >>
>> >> No. Gentoo maintainers just overlooked that all Gentoo signing keys
>> >> expired on July 1, and added new openpgp-keys-gentoo into portage
>> >> tree only on July 2.
>> >>
>> >> So, since July 1, rsync cannot verify any new portage tree and cannot
>> >> download app-crypt/openpgp-keys-gentoo-release-20180702
>> >>
>> >> It was discovered in the thread
>> >> "All Gentoo signing key expired and no way to fix it"
>> >
>> > Is there a documented manual workaround we could follow at present,
>> > irrespective of our sync'ing mechanism of choice?

It seems that everything is explained in
https://wiki.gentoo.org/wiki/Portage_Security
(This link was first provided in this thread by methylherd.)

>> For me, it somehow worked by manually refreshing the Gentoo signing keys by
>> executing the following two commands:
>> # gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --refresh-keys
>> # gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys
>> 0xDB6B8C1F96D8BF6D in different order and sourcing /etc/profile
>>
>> But, please, note that I use emerge-webrsync to update the portage tree.
>
> Thanks gevisz, the first line to refresh keys fails, because in /var/lib/
> gentoo/ I only have a news/ subdirectory.

Interestingly, it was the second line that seemed to fail in my case.
(I was in a hurry and executed it so many times, so that I cannot
 say if for sure.)

But, as it has already been pointed out by Bill Kenworthy and
explained in https://wiki.gentoo.org/wiki/Portage_Security ,
the internal mechanisms for checking Gentoo signatures
are different between git, rsync and webrsync.

[gentoo-user] Multilib blues continues

[Zoltán Kócsi]

The */* x86_ ... in the use file and asking emerge to re-build the
libraries is pretty cool for building both 64 and 32 bit libs.

But it has it's problems, it seems.
The library libcap fails to compile with some spectacular errors:

--
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -Wall -Wwrite-strings -Wpointer-arith 
-Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes 
-Wnested-externs -Winline -Wshadow -g  -Wall -Wwrite-strings -Wpointer-arith 
-Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes 
-Wnested-externs -Winline -Wshadow -g  -fPIC 
-I/var/tmp/portage/sys-libs/libcap-2.24-r2/work/libcap-2.24-abi_x86_32.x86/libcap/../libcap/include/uapi
 
-I/var/tmp/portage/sys-libs/libcap-2.24-r2/work/libcap-2.24-abi_x86_32.x86/libcap/../libcap/include
 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -c cap_file.c -o 
cap_file.o
In file included from :0:0:
./_caps_output.gperf:71:80: error: unknown type name 'size_t'
 gperf_case_strncmp (register const char *s1, register const char *s2, register 
size_t n)

^~
./_caps_output.gperf:96:53: error: unknown type name 'size_t'
 __cap_hash_name (register const char *str, register size_t len)
 ^~
./_caps_output.gperf:197:55: error: unknown type name 'size_t'
 __cap_lookup_name (register const char *str, register size_t len)
   ^~
./_caps_output.gperf:197:1: error: conflicting types for '__cap_lookup_name'
 __cap_lookup_name (register const char *str, register size_t len)
 ^
./_caps_output.gperf:33:29: note: previous declaration of '__cap_lookup_name' 
was here
 const struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);
 ^
cap_text.c: In function 'cap_to_name':
cap_text.c:291:2: warning: ignoring return value of 'asprintf', declared with 
attribute warn_unused_result [-Wunused-result]
  asprintf(, "%u", cap);
  ^
make[1]: *** [Makefile:84: cap_text.o] Error 1


If it can't find size_t then for some reason it fails to include
pretty much any standard header. Which is supported by the 
"included from " pip from gcc. Obviously, whatever
generates the _caps_output.gperf file made a mistake, both not
including the standard headers and also with declaration of the
__cap_lookup_name() function.

Considering that libcap builds happily on a 64-bit system and I assume
would also build on 32-bit one, the problem must be with the magic
required to build a 32-bit version on a 64-bit machine. 

Should it be considered a bug worthy of reporting?

Thanks,

Zoltan