[gentoo-user] .tmp-unverified-download-quarantine

[gentoo-user] .tmp-unverified-download-quarantine

[n952162]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

While installing gentoo from scratch, after doing a "emerge --sync", the
command:

eselect profile list

fails because it can't get any profiles, and I see that the 17.1 profile
is in a .tmp-unverified-download-quarantine.

 1. what do I have to do to get this going again?
 2. how did I end up in this situation?  Is this a known bug.  I simply
    followed the handbook.


[-- Attachment #2: Type: text/html, Size: 618 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[james]

On 1/12/20 3:51 PM, n952162 wrote:
> While installing gentoo from scratch, after doing a "emerge --sync", the 
> command:
> 
> eselect profile list
> 
> fails because it can't get any profiles, and I see that the 17.1 profile 
> is in a .tmp-unverified-download-quarantine.
> 
>  1. what do I have to do to get this going again?
>  2. how did I end up in this situation?� Is this a known bug.� I simply
>     followed the handbook.
> 


Some folks on this list will not like the advise I give; caveat emptor 
my friend.

So, I install and give away many old system so folks can first learn 
about gentoo, with a working baseline.  my latest one, is for a savant 
EE, that just hates W. I have not seen him for a very long time. He 
asked for one, and I could not say no.  Gentoo is all I recommend
as I've pretty much tried many other linux distros; most give me 
heartburn for a myriad of reasons.

I also install and re-install, as many of the gentoo systems get 
"attacked" before I can  complete a secure install, or the hackers just 
read much more than I do.
I guess I'm still popular, in very negative way.

SO, I'm always looking for a quick and easy gentoo install 
method/medium. CloverOS  (cloveros.ga) use to work well. Then quite a 
few releases (through the decemeber 2019) failed in one way or another. 
I have not tried the latest release, so I'm about to give it a spin, 
just for fun. I offer this, hoping that all have gone through a few 
installs, via the handbook, but putting together your own streamlined 
install system,
is a pita to figure-out and get reasonable stable.


I've been using gentoo since 2003. A quick, supported install is a 
pet-peeve for me; to each his own. I've burned up some HD and cpus, and 
ram trying to bring old gentoo installs up to date; although most made 
it fine, despite tons of hours.

I hope this helps you. Installing gentoo is a religious  experience, 
once you diverge from the handbook; ymmv.

Perhaps one day, I'll be able to afford a 7nm and tons of ram system, so 
the heavy compiling can be complete therein and moved to a target, just 
like most embedded systems installs are these days.

hth,
James

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-12 16:48, james wrote:
> I also install and re-install, as many of the gentoo systems get
> "attacked" before I can  complete a secure install, or the hackers
> just read much more than I do.
> I guess I'm still popular, in very negative way.


Hmmm.  Is that "attacked" to be interpreted in some sort of metaphorical
way or do you mean really hacked over the internet? May I ask how, and
how do you know?  What's involved in a secure install?

Re: [gentoo-user] .tmp-unverified-download-quarantine

[james]

On 1/13/20 3:24 AM, n952162 wrote:
> On 2020-01-12 16:48, james wrote:
>> I also install and re-install, as many of the gentoo systems get
>> "attacked" before I can� complete a secure install, or the hackers
>> just read much more than I do.
>> I guess I'm still popular, in very negative way.
> 
> 
> Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical
> way or do you mean really hacked over the internet? May I ask how, and
> how do you know?� What's involved in a secure install?


Monitor your connection, with a system setup that the ethernet does not 
responds to any sort of request. The system just collects and log. NO, 
I'm not documenting how to do this, but various ways exist, documented 
on the internet to make *most* ethernet interface to where they are 
*one-direction* only. HOW you achieve this? There are a myriad of ways.

Good Hunting and *never* tell anyone how *you* do this....


caveat emptor

James

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Wols Lists]

On 16/01/20 21:01, james wrote:
> On 1/13/20 3:24 AM, n952162 wrote:
>> On 2020-01-12 16:48, james wrote:
>>> I also install and re-install, as many of the gentoo systems get
>>> "attacked" before I can� complete a secure install, or the hackers
>>> just read much more than I do.
>>> I guess I'm still popular, in very negative way.
>>
>>
>> Hmmm.� Is that "attacked" to be interpreted in some sort of
>> metaphorical
>> way or do you mean really hacked over the internet? May I ask how, and
>> how do you know?� What's involved in a secure install?
> 
> 
> Monitor your connection, with a system setup that the ethernet does not
> responds to any sort of request. The system just collects and log. NO,
> I'm not documenting how to do this, but various ways exist, documented
> on the internet to make *most* ethernet interface to where they are
> *one-direction* only. HOW you achieve this? There are a myriad of ways.
> 
> Good Hunting and *never* tell anyone how *you* do this....
> 
If you're handy with an ethernet crimping tool, just cut the TX wires
and put the interface into promiscuous mode ...

Just be aware that - routers especially - can swap TX and RX so they
could possibly get round that.

Cheers,
Wol

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

What protocol doesn't use acknowledgements?


On 2020-01-18 14:50, Wols Lists wrote:
> On 16/01/20 21:01, james wrote:
>> On 1/13/20 3:24 AM, n952162 wrote:
>>> On 2020-01-12 16:48, james wrote:
>>>> I also install and re-install, as many of the gentoo systems get
>>>> "attacked" before I can� complete a secure install, or the hackers
>>>> just read much more than I do.
>>>> I guess I'm still popular, in very negative way.
>>>
>>> Hmmm.� Is that "attacked" to be interpreted in some sort of
>>> metaphorical
>>> way or do you mean really hacked over the internet? May I ask how, and
>>> how do you know?� What's involved in a secure install?
>>
>> Monitor your connection, with a system setup that the ethernet does not
>> responds to any sort of request. The system just collects and log. NO,
>> I'm not documenting how to do this, but various ways exist, documented
>> on the internet to make *most* ethernet interface to where they are
>> *one-direction* only. HOW you achieve this? There are a myriad of ways.
>>
>> Good Hunting and *never* tell anyone how *you* do this....
>>
> If you're handy with an ethernet crimping tool, just cut the TX wires
> and put the interface into promiscuous mode ...
>
> Just be aware that - routers especially - can swap TX and RX so they
> could possibly get round that.
>
> Cheers,
> Wol
>
>

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Wols Lists]

On 18/01/20 17:45, n952162 wrote:
> What protocol doesn't use acknowledgements?
> 
Why would an eavesdropper want to acknowledge ANYTHING? Isn't that the
whole point?

Cheers,
Wol
> 
> On 2020-01-18 14:50, Wols Lists wrote:
>> On 16/01/20 21:01, james wrote:
>>> On 1/13/20 3:24 AM, n952162 wrote:
>>>> On 2020-01-12 16:48, james wrote:
>>>>> I also install and re-install, as many of the gentoo systems get
>>>>> "attacked" before I can� complete a secure install, or the hackers
>>>>> just read much more than I do.
>>>>> I guess I'm still popular, in very negative way.
>>>>
>>>> Hmmm.� Is that "attacked" to be interpreted in some sort of
>>>> metaphorical
>>>> way or do you mean really hacked over the internet? May I ask how, and
>>>> how do you know?� What's involved in a secure install?
>>>
>>> Monitor your connection, with a system setup that the ethernet does not
>>> responds to any sort of request. The system just collects and log. NO,
>>> I'm not documenting how to do this, but various ways exist, documented
>>> on the internet to make *most* ethernet interface to where they are
>>> *one-direction* only. HOW you achieve this? There are a myriad of ways.
>>>
>>> Good Hunting and *never* tell anyone how *you* do this....
>>>
>> If you're handy with an ethernet crimping tool, just cut the TX wires
>> and put the interface into promiscuous mode ...
>>
>> Just be aware that - routers especially - can swap TX and RX so they
>> could possibly get round that.
>>
>> Cheers,
>> Wol
>>
>>
> 
> 

Re: [gentoo-user] .tmp-unverified-download-quarantine

[james]

On 1/13/20 3:24 AM, n952162 wrote:
> On 2020-01-12 16:48, james wrote:
>> I also install and re-install, as many of the gentoo systems get
>> "attacked" before I can� complete a secure install, or the hackers
>> just read much more than I do.
>> I guess I'm still popular, in very negative way.
> 
> 
> Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical
> way or do you mean really hacked over the internet? May I ask how, and
> how do you know?� What's involved in a secure install?
> 
> 


Here is a good place *to start* self-education::


https://en.wikipedia.org/wiki/Unidirectional_network

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Sun, 12 Jan 2020 21:51:28 +0100, n952162 wrote:

> While installing gentoo from scratch, after doing a "emerge --sync", the
> command:
> 
> eselect profile list
> 
> fails because it can't get any profiles, and I see that the 17.1 profile
> is in a .tmp-unverified-download-quarantine.
> 
>  1. what do I have to do to get this going again?
>  2. how did I end up in this situation?  Is this a known bug.  I simply
>     followed the handbook.

I had a similar issue with the .tmp-unverified-download-quarantine
continually appearing, deleting it made no difference. In the end I
deleted the whole portage tree and resynced, then the problem
disappeared. This may or may not have a bearing on your profile issue,
but it's worth fixing first.


-- 
Neil Bothwick

I'm not a complete idiot - several parts are missing.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-12 23:07, Neil Bothwick wrote:
> On Sun, 12 Jan 2020 21:51:28 +0100, n952162 wrote:
>
>> While installing gentoo from scratch, after doing a "emerge --sync", the
>> command:
>>
>> eselect profile list
>>
>> fails because it can't get any profiles, and I see that the 17.1 profile
>> is in a .tmp-unverified-download-quarantine.
>>
>>   1. what do I have to do to get this going again?
>>   2. how did I end up in this situation?  Is this a known bug.  I simply
>>      followed the handbook.
> I had a similar issue with the .tmp-unverified-download-quarantine
> continually appearing, deleting it made no difference. In the end I
> deleted the whole portage tree and resynced, then the problem
> disappeared. This may or may not have a bearing on your profile issue,
> but it's worth fixing first.
>
>

I just finished running "emerge --sync" again, based on something I saw
on the internet - it did the whole thing again, takes about 2 hours. 
Same result.  But I didn't delete "the whole portage tree".  What does
that mean?

rm -rf /var/db/repos?

or:

rm -rf /var/db/pkg?

And why should it work?  Is it not rather something broken in the
upstream repository?  Or the 20200108 minimum cd image I'm using? It's
otherwise a naked machine.

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

On Sun, 12 Jan 2020 23:41:43 +0100, n952162 wrote:

> > I had a similar issue with the .tmp-unverified-download-quarantine
> > continually appearing, deleting it made no difference. In the end I
> > deleted the whole portage tree and resynced, then the problem
> > disappeared. This may or may not have a bearing on your profile issue,
> > but it's worth fixing first.

> I just finished running "emerge --sync" again, based on something I saw
> on the internet - it did the whole thing again, takes about 2 hours. 

Two hours? How slow is your connection?

> Same result.  But I didn't delete "the whole portage tree".  What does
> that mean?
> 
> rm -rf /var/db/repos?

If you're using the new default location, I think it is
/var/db/repos/gentoo, but someone should confirm that.

> or:
> 
> rm -rf /var/db/pkg?

No, that's the database of installed packages, don't mess with it.

> And why should it work?  Is it not rather something broken in the
> upstream repository?  Or the 20200108 minimum cd image I'm using? It's
> otherwise a naked machine.

No idea, but something went wrong on one sync and I was stuck with this
directory. Deleting it was no help, but deleting the whole tree fixed it.
It did slow down sync times, but not the the extent you have.


-- 
Neil Bothwick

WinErr 00B: Inadequate disk space - Free at least 50MB

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Mick]

[-- Attachment #1: Type: text/plain, Size: 12042 bytes --]

On Sunday, 12 January 2020 23:32:16 GMT Neil Bothwick wrote:
> On Sun, 12 Jan 2020 23:41:43 +0100, n952162 wrote:
> > > I had a similar issue with the .tmp-unverified-download-quarantine
> > > continually appearing, deleting it made no difference. In the end I
> > > deleted the whole portage tree and resynced, then the problem
> > > disappeared. This may or may not have a bearing on your profile issue,
> > > but it's worth fixing first.
> > 
> > I just finished running "emerge --sync" again, based on something I saw
> > on the internet - it did the whole thing again, takes about 2 hours. 
> 
> Two hours? How slow is your connection?

Assuming this is not the time it takes to run rsync (even on a dial-up 
analogue modem connection?) I would guess the delay is caused by the post-sync 
tree verification.  The .tmp-unverified-download-quarantine file is where the 
sync is stored until the signature verification is performed.  Even on a 
really old dual-core laptop with low RAM the sync and verification only takes 
around 20 minutes.


> > Same result.  But I didn't delete "the whole portage tree".  What does
> > that mean?
> > 
> > rm -rf /var/db/repos?
> 
> If you're using the new default location, I think it is
> /var/db/repos/gentoo, but someone should confirm that.

Yes, the new location for the portage ebuilds is:

$ ls -la /var/db/repos/gentoo/.*
/var/db/repos/gentoo/.:
total 1132
drwxr-xr-x  175 root root  4096 Jan 11 10:14 .
drwxr-xr-x    4 root root  4096 Jan  2 14:22 ..
-rw-r--r--    1 root root  1349 Jan 11 08:39 Manifest
-rw-r--r--    1 root root 29427 Jan 11 08:39 Manifest.files.gz
drwxr-xr-x  124 root root  4096 Jan 11 10:07 acct-group
drwxr-xr-x  109 root root  4096 Jan 11 10:07 acct-user
drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-accessibility
drwxr-xr-x  206 root root  4096 Jan 11 10:07 app-admin
drwxr-xr-x    6 root root  4096 Jan  2 12:06 app-antivirus
drwxr-xr-x  100 root root  4096 Jan 11 10:07 app-arch
drwxr-xr-x   63 root root  4096 Jan 11 10:07 app-backup
drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-benchmarks
drwxr-xr-x   52 root root  4096 Jan 11 10:07 app-cdr
drwxr-xr-x  152 root root  4096 Jan 11 10:07 app-crypt
drwxr-xr-x  313 root root 12288 Jan 11 10:07 app-dicts
drwxr-xr-x   45 root root  4096 Jan 11 10:07 app-doc
drwxr-xr-x   86 root root  4096 Jan 11 10:07 app-editors
drwxr-xr-x  206 root root  4096 Jan 11 10:07 app-emacs
drwxr-xr-x  126 root root  4096 Jan 11 10:07 app-emulation
drwxr-xr-x   50 root root  4096 Jan 11 10:07 app-eselect
drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-forensics
drwxr-xr-x  125 root root  4096 Jan 11 10:07 app-i18n
drwxr-xr-x   20 root root  4096 Jan  2 12:06 app-laptop
drwxr-xr-x   73 root root  4096 Jan  2 12:06 app-leechcraft
drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-metrics
drwxr-xr-x  307 root root 12288 Jan 11 10:07 app-misc
drwxr-xr-x   22 root root  4096 Jan 11 10:07 app-mobilephone
drwxr-xr-x   55 root root  4096 Jan 11 10:07 app-office
drwxr-xr-x   10 root root  4096 Jan  2 12:06 app-officeext
drwxr-xr-x   15 root root  4096 Jan 11 10:07 app-pda
drwxr-xr-x   62 root root  4096 Jan 11 10:07 app-portage
drwxr-xr-x   50 root root  4096 Jan 11 10:07 app-shells
drwxr-xr-x  313 root root 12288 Jan 11 10:07 app-text
drwxr-xr-x  198 root root  4096 Jan 11 10:07 app-vim
drwxr-xr-x  133 root root  4096 Dec 22 09:59 app-xemacs
drwxr-xr-x   20 root root  4096 Dec 18 07:47 dev-ada
drwxr-xr-x   55 root root  4096 Jan 11 10:07 dev-cpp
drwxr-xr-x  108 root root  4096 Jan 11 10:07 dev-db
drwxr-xr-x   17 root root  4096 Dec 27 13:24 dev-dotnet
drwxr-xr-x   56 root root  4096 Jan 11 10:07 dev-embedded
drwxr-xr-x   37 root root  4096 Dec 28 09:42 dev-erlang
drwxr-xr-x   35 root root  4096 Jan 11 10:07 dev-games
drwxr-xr-x   37 root root  4096 Jan  4 11:40 dev-go
drwxr-xr-x  684 root root 20480 Jan  2 12:06 dev-haskell
drwxr-xr-x  530 root root 20480 Jan 11 10:07 dev-java
drwxr-xr-x  107 root root  4096 Jan 11 10:07 dev-lang
drwxr-xr-x  500 root root 20480 Jan 11 10:07 dev-libs
drwxr-xr-x   21 root root  4096 Jan 11 10:07 dev-lisp
drwxr-xr-x   39 root root  4096 Jan 11 10:07 dev-lua
drwxr-xr-x  253 root root 12288 Jan 11 10:07 dev-ml
drwxr-xr-x 1604 root root 69632 Jan 11 10:07 dev-perl
drwxr-xr-x  230 root root 12288 Jan 11 10:07 dev-php
drwxr-xr-x 1791 root root 69632 Jan 11 10:07 dev-python
drwxr-xr-x   61 root root  4096 Jan 11 10:07 dev-qt
drwxr-xr-x  346 root root 16384 Jan 11 10:07 dev-ros
drwxr-xr-x  686 root root 20480 Jan 11 10:07 dev-ruby
drwxr-xr-x   34 root root  4096 Jan 11 10:07 dev-scheme
drwxr-xr-x   40 root root  4096 Jan 11 10:07 dev-tcltk
drwxr-xr-x   76 root root  4096 Jan 11 10:07 dev-tex
drwxr-xr-x   40 root root  4096 Dec  4 08:34 dev-texlive
drwxr-xr-x  403 root root 12288 Jan 11 10:07 dev-util
drwxr-xr-x   80 root root  4096 Jan 11 10:07 dev-vcs
drwxr-xr-x    3 root root 12288 Jan 11 10:07 eclass
drwxr-xr-x   83 root root  4096 Jan  5 11:08 games-action
drwxr-xr-x  129 root root  4096 Jan 11 10:07 games-arcade
drwxr-xr-x   72 root root  4096 Jan 11 10:07 games-board
drwxr-xr-x   60 root root  4096 Jan 11 10:07 games-emulation
drwxr-xr-x   24 root root  4096 Jan  5 11:08 games-engines
drwxr-xr-x   66 root root  4096 Jan 11 10:07 games-fps
drwxr-xr-x   10 root root  4096 Jan 11 10:07 games-kids
drwxr-xr-x   73 root root  4096 Jan 11 10:07 games-misc
drwxr-xr-x   14 root root  4096 Oct 11 20:04 games-mud
drwxr-xr-x  105 root root  4096 Jan  5 11:08 games-puzzle
drwxr-xr-x   20 root root  4096 Jan  5 11:08 games-roguelike
drwxr-xr-x   50 root root  4096 Jan 11 10:07 games-rpg
drwxr-xr-x   12 root root  4096 Dec 27 13:24 games-server
drwxr-xr-x   21 root root  4096 Dec 28 09:42 games-simulation
drwxr-xr-x   16 root root  4096 Dec 29 13:40 games-sports
drwxr-xr-x   54 root root  4096 Jan 11 10:07 games-strategy
drwxr-xr-x   44 root root  4096 Jan 11 10:07 games-util
drwxr-xr-x   38 root root  4096 Jan 11 10:07 gnome-base
drwxr-xr-x   66 root root  4096 Jan 11 10:07 gnome-extra
drwxr-xr-x   34 root root  4096 Dec 27 13:24 gnustep-apps
drwxr-xr-x   11 root root  4096 Dec 27 13:24 gnustep-base
drwxr-xr-x   12 root root  4096 Dec 27 13:24 gnustep-libs
drwxr-xr-x   10 root root  4096 Nov  4 08:27 gui-apps
drwxr-xr-x    8 root root  4096 Jan 11 10:07 gui-libs
drwxr-xr-x    3 root root  4096 Oct 11 20:04 gui-wm
-rw-r--r--    1 root root   105 Jan  1 11:09 header.txt
drwxr-xr-x   12 root root  4096 Oct 19 08:37 java-virtuals
drwxr-xr-x  237 root root 12288 Jan 11 10:07 kde-apps
drwxr-xr-x   86 root root  4096 Jan 11 10:07 kde-frameworks
drwxr-xr-x   33 root root  4096 Jan 11 10:07 kde-misc
drwxr-xr-x   50 root root  4096 Jan 11 10:07 kde-plasma
drwxr-xr-x    2 root root 20480 Jan 11 10:07 licenses
drwxr-xr-x   17 root root  4096 Nov 18 08:59 lxde-base
drwxr-xr-x   18 root root  4096 Jan  2 12:06 lxqt-base
drwxr-xr-x   27 root root  4096 Jan 11 10:07 mail-client
drwxr-xr-x   56 root root  4096 Jan 11 10:07 mail-filter
drwxr-xr-x   14 root root  4096 Jan 11 10:07 mail-mta
drwxr-xr-x   14 root root  4096 Dec 14 09:08 mate-base
drwxr-xr-x   16 root root  4096 Jan 11 10:07 mate-extra
drwxr-xr-x  219 root root 12288 Jan 11 10:07 media-fonts
drwxr-xr-x  244 root root 12288 Jan 11 10:07 media-gfx
drwxr-xr-x  397 root root 12288 Jan 11 10:07 media-libs
drwxr-xr-x  293 root root 12288 Jan 11 10:07 media-plugins
drwxr-xr-x   31 root root  4096 Jan  2 12:06 media-radio
drwxr-xr-x  378 root root 12288 Jan 11 10:07 media-sound
drwxr-xr-x   24 root root  4096 Jan 11 10:07 media-tv
drwxr-xr-x  164 root root  4096 Jan 11 10:07 media-video
drwxr-xr-x    9 root root  4096 Jan 11 10:07 metadata
drwxr-xr-x  286 root root 12288 Jan 11 10:08 net-analyzer
drwxr-xr-x   37 root root  4096 Jan 11 10:08 net-dialup
drwxr-xr-x   54 root root  4096 Jan 11 10:08 net-dns
drwxr-xr-x   29 root root  4096 Jan 11 10:08 net-firewall
drwxr-xr-x   28 root root  4096 Jan 11 10:08 net-fs
drwxr-xr-x   25 root root  4096 Jan 11 10:08 net-ftp
drwxr-xr-x   58 root root  4096 Jan 11 10:08 net-im
drwxr-xr-x   48 root root  4096 Jan 11 10:08 net-irc
drwxr-xr-x  199 root root  4096 Jan 11 10:08 net-libs
drwxr-xr-x   92 root root  4096 Jan 11 10:08 net-mail
drwxr-xr-x  339 root root 12288 Jan 11 10:08 net-misc
drwxr-xr-x   16 root root  4096 Dec 18 07:47 net-nds
drwxr-xr-x   14 root root  4096 Jan 11 10:08 net-news
drwxr-xr-x   13 root root  4096 Dec 27 13:24 net-nntp
drwxr-xr-x   48 root root  4096 Jan 11 10:08 net-p2p
drwxr-xr-x   39 root root  4096 Jan 11 10:08 net-print
drwxr-xr-x   32 root root  4096 Jan 11 10:08 net-proxy
drwxr-xr-x    7 root root  4096 Dec 14 09:08 net-voip
drwxr-xr-x   38 root root  4096 Jan 11 10:08 net-vpn
drwxr-xr-x  111 root root  4096 Jan 11 10:08 net-wireless
drwxr-xr-x   49 root root  4096 Dec 14 09:08 perl-core
drwxr-xr-x   13 root root  4096 Jan 11 10:08 profiles
drwxr-xr-x   54 root root  4096 Dec 18 07:47 ros-meta
drwxr-xr-x   40 root root  4096 Jan 11 10:08 sci-astronomy
drwxr-xr-x  144 root root  4096 Jan 11 10:08 sci-biology
drwxr-xr-x   21 root root  4096 Jan 11 10:08 sci-calculators
drwxr-xr-x   93 root root  4096 Jan 11 10:08 sci-chemistry
drwxr-xr-x   59 root root  4096 Jan 11 10:08 sci-electronics
drwxr-xr-x   67 root root  4096 Jan 11 10:08 sci-geosciences
drwxr-xr-x  254 root root 12288 Jan 11 10:08 sci-libs
drwxr-xr-x   88 root root  4096 Jan 11 10:08 sci-mathematics
drwxr-xr-x   22 root root  4096 Jan 11 10:08 sci-misc
drwxr-xr-x   35 root root  4096 Jan 11 10:08 sci-physics
drwxr-xr-x   33 root root  4096 Jan 11 10:08 sci-visualization
drwxr-xr-x    2 root root  4096 Jun 10  2019 scripts
drwxr-xr-x  260 root root 12288 Dec 22 09:59 sec-policy
-rw-r--r--    1 root root  7491 Jan  3 19:39 skel.ebuild
-rw-r--r--    1 root root  1173 Feb 28  2017 skel.metadata.xml
drwxr-xr-x  301 root root 12288 Jan 11 10:08 sys-apps
drwxr-xr-x   63 root root  4096 Jan 11 10:08 sys-auth
drwxr-xr-x   65 root root  4096 Jan 11 10:08 sys-block
drwxr-xr-x   41 root root  4096 Jan 11 10:08 sys-boot
drwxr-xr-x   79 root root  4096 Jan 11 10:08 sys-cluster
drwxr-xr-x   57 root root  4096 Jan 11 10:08 sys-devel
drwxr-xr-x   27 root root  4096 Jan  5 11:08 sys-fabric
drwxr-xr-x   31 root root  4096 Jan 11 10:08 sys-firmware
drwxr-xr-x  132 root root  4096 Jan 11 10:08 sys-fs
drwxr-xr-x   32 root root  4096 Jan 11 10:08 sys-kernel
drwxr-xr-x   88 root root  4096 Jan 11 10:08 sys-libs
drwxr-xr-x   31 root root  4096 Jan 11 10:08 sys-power
drwxr-xr-x   54 root root  4096 Jan 11 10:08 sys-process
drwxr-xr-x  201 root root 12288 Jan 11 10:08 virtual
drwxr-xr-x   43 root root  4096 Jan 11 10:08 www-apache
drwxr-xr-x   80 root root  4096 Jan 11 10:08 www-apps
drwxr-xr-x   38 root root  4096 Jan 11 10:08 www-client
drwxr-xr-x   22 root root  4096 Jan 11 10:08 www-misc
drwxr-xr-x   11 root root  4096 Jan 11 10:08 www-plugins
drwxr-xr-x   33 root root  4096 Jan 11 10:08 www-servers
drwxr-xr-x   91 root root  4096 Jan 11 10:08 x11-apps
drwxr-xr-x    7 root root  4096 Jan 11 10:08 x11-base
drwxr-xr-x   33 root root  4096 Jan  4 11:40 x11-drivers
drwxr-xr-x  126 root root  4096 Jan 11 10:08 x11-libs
drwxr-xr-x  299 root root 12288 Jan 11 10:08 x11-misc
drwxr-xr-x  172 root root  4096 Dec 27 13:24 x11-plugins
drwxr-xr-x   29 root root  4096 Jan 11 10:08 x11-terms
drwxr-xr-x  137 root root  4096 Jan 11 10:08 x11-themes
drwxr-xr-x   59 root root  4096 Jan 11 10:08 x11-wm
drwxr-xr-x   15 root root  4096 Jan 11 10:08 xfce-base
drwxr-xr-x   55 root root  4096 Jan 11 10:08 xfce-extra


You may need to remove the whole tree as Neil did, if the verification fails 
because of the portage tree contents.  Theoretically a re-sync ought to fix 
this, because the .tmp-unverified-download-quarantine file would/should be 
initially overwritten and eventually deleted once the verification is 
complete, but as you reported it didn't do so.  :-/

This bug points to the tree owned by root:root instead of portage:portage, 
interestingly in my most recent installation the tree is owned by root as you 
can see above and I'm not getting this problem.

https://bugs.gentoo.org/661834

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-13 09:22, Mick wrote:
>
>>> Same result.  But I didn't delete "the whole portage tree".  What does
>>> that mean?
>>>
>>> rm -rf /var/db/repos?
>> If you're using the new default location, I think it is
>> /var/db/repos/gentoo, but someone should confirm that.
> Yes, the new location for the portage ebuilds is:
>
> $ ls -la /var/db/repos/gentoo/.*
> /var/db/repos/gentoo/.:



I just noticed that there's a new stag3, from 2020/01/12 instead of
2020/01/08 so - since this is a fresh install - I'm just going to start
from there.


> total 1132
> drwxr-xr-x  175 root root  4096 Jan 11 10:14 .
> drwxr-xr-x    4 root root  4096 Jan  2 14:22 ..
> -rw-r--r--    1 root root  1349 Jan 11 08:39 Manifest
> -rw-r--r--    1 root root 29427 Jan 11 08:39 Manifest.files.gz
> drwxr-xr-x  124 root root  4096 Jan 11 10:07 acct-group
> drwxr-xr-x  109 root root  4096 Jan 11 10:07 acct-user
> drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-accessibility
> drwxr-xr-x  206 root root  4096 Jan 11 10:07 app-admin
> drwxr-xr-x    6 root root  4096 Jan  2 12:06 app-antivirus
> drwxr-xr-x  100 root root  4096 Jan 11 10:07 app-arch
> drwxr-xr-x   63 root root  4096 Jan 11 10:07 app-backup
> drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-benchmarks
> drwxr-xr-x   52 root root  4096 Jan 11 10:07 app-cdr
> drwxr-xr-x  152 root root  4096 Jan 11 10:07 app-crypt
> drwxr-xr-x  313 root root 12288 Jan 11 10:07 app-dicts
> drwxr-xr-x   45 root root  4096 Jan 11 10:07 app-doc
> drwxr-xr-x   86 root root  4096 Jan 11 10:07 app-editors
> drwxr-xr-x  206 root root  4096 Jan 11 10:07 app-emacs
> drwxr-xr-x  126 root root  4096 Jan 11 10:07 app-emulation
> drwxr-xr-x   50 root root  4096 Jan 11 10:07 app-eselect
> drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-forensics
> drwxr-xr-x  125 root root  4096 Jan 11 10:07 app-i18n
> drwxr-xr-x   20 root root  4096 Jan  2 12:06 app-laptop
> drwxr-xr-x   73 root root  4096 Jan  2 12:06 app-leechcraft
> drwxr-xr-x   31 root root  4096 Jan 11 10:07 app-metrics
> drwxr-xr-x  307 root root 12288 Jan 11 10:07 app-misc
> drwxr-xr-x   22 root root  4096 Jan 11 10:07 app-mobilephone
> drwxr-xr-x   55 root root  4096 Jan 11 10:07 app-office
> drwxr-xr-x   10 root root  4096 Jan  2 12:06 app-officeext
> drwxr-xr-x   15 root root  4096 Jan 11 10:07 app-pda
> drwxr-xr-x   62 root root  4096 Jan 11 10:07 app-portage
> drwxr-xr-x   50 root root  4096 Jan 11 10:07 app-shells
> drwxr-xr-x  313 root root 12288 Jan 11 10:07 app-text
> drwxr-xr-x  198 root root  4096 Jan 11 10:07 app-vim
> drwxr-xr-x  133 root root  4096 Dec 22 09:59 app-xemacs
> drwxr-xr-x   20 root root  4096 Dec 18 07:47 dev-ada
> drwxr-xr-x   55 root root  4096 Jan 11 10:07 dev-cpp
> drwxr-xr-x  108 root root  4096 Jan 11 10:07 dev-db
> drwxr-xr-x   17 root root  4096 Dec 27 13:24 dev-dotnet
> drwxr-xr-x   56 root root  4096 Jan 11 10:07 dev-embedded
> drwxr-xr-x   37 root root  4096 Dec 28 09:42 dev-erlang
> drwxr-xr-x   35 root root  4096 Jan 11 10:07 dev-games
> drwxr-xr-x   37 root root  4096 Jan  4 11:40 dev-go
> drwxr-xr-x  684 root root 20480 Jan  2 12:06 dev-haskell
> drwxr-xr-x  530 root root 20480 Jan 11 10:07 dev-java
> drwxr-xr-x  107 root root  4096 Jan 11 10:07 dev-lang
> drwxr-xr-x  500 root root 20480 Jan 11 10:07 dev-libs
> drwxr-xr-x   21 root root  4096 Jan 11 10:07 dev-lisp
> drwxr-xr-x   39 root root  4096 Jan 11 10:07 dev-lua
> drwxr-xr-x  253 root root 12288 Jan 11 10:07 dev-ml
> drwxr-xr-x 1604 root root 69632 Jan 11 10:07 dev-perl
> drwxr-xr-x  230 root root 12288 Jan 11 10:07 dev-php
> drwxr-xr-x 1791 root root 69632 Jan 11 10:07 dev-python
> drwxr-xr-x   61 root root  4096 Jan 11 10:07 dev-qt
> drwxr-xr-x  346 root root 16384 Jan 11 10:07 dev-ros
> drwxr-xr-x  686 root root 20480 Jan 11 10:07 dev-ruby
> drwxr-xr-x   34 root root  4096 Jan 11 10:07 dev-scheme
> drwxr-xr-x   40 root root  4096 Jan 11 10:07 dev-tcltk
> drwxr-xr-x   76 root root  4096 Jan 11 10:07 dev-tex
> drwxr-xr-x   40 root root  4096 Dec  4 08:34 dev-texlive
> drwxr-xr-x  403 root root 12288 Jan 11 10:07 dev-util
> drwxr-xr-x   80 root root  4096 Jan 11 10:07 dev-vcs
> drwxr-xr-x    3 root root 12288 Jan 11 10:07 eclass
> drwxr-xr-x   83 root root  4096 Jan  5 11:08 games-action
> drwxr-xr-x  129 root root  4096 Jan 11 10:07 games-arcade
> drwxr-xr-x   72 root root  4096 Jan 11 10:07 games-board
> drwxr-xr-x   60 root root  4096 Jan 11 10:07 games-emulation
> drwxr-xr-x   24 root root  4096 Jan  5 11:08 games-engines
> drwxr-xr-x   66 root root  4096 Jan 11 10:07 games-fps
> drwxr-xr-x   10 root root  4096 Jan 11 10:07 games-kids
> drwxr-xr-x   73 root root  4096 Jan 11 10:07 games-misc
> drwxr-xr-x   14 root root  4096 Oct 11 20:04 games-mud
> drwxr-xr-x  105 root root  4096 Jan  5 11:08 games-puzzle
> drwxr-xr-x   20 root root  4096 Jan  5 11:08 games-roguelike
> drwxr-xr-x   50 root root  4096 Jan 11 10:07 games-rpg
> drwxr-xr-x   12 root root  4096 Dec 27 13:24 games-server
> drwxr-xr-x   21 root root  4096 Dec 28 09:42 games-simulation
> drwxr-xr-x   16 root root  4096 Dec 29 13:40 games-sports
> drwxr-xr-x   54 root root  4096 Jan 11 10:07 games-strategy
> drwxr-xr-x   44 root root  4096 Jan 11 10:07 games-util
> drwxr-xr-x   38 root root  4096 Jan 11 10:07 gnome-base
> drwxr-xr-x   66 root root  4096 Jan 11 10:07 gnome-extra
> drwxr-xr-x   34 root root  4096 Dec 27 13:24 gnustep-apps
> drwxr-xr-x   11 root root  4096 Dec 27 13:24 gnustep-base
> drwxr-xr-x   12 root root  4096 Dec 27 13:24 gnustep-libs
> drwxr-xr-x   10 root root  4096 Nov  4 08:27 gui-apps
> drwxr-xr-x    8 root root  4096 Jan 11 10:07 gui-libs
> drwxr-xr-x    3 root root  4096 Oct 11 20:04 gui-wm
> -rw-r--r--    1 root root   105 Jan  1 11:09 header.txt
> drwxr-xr-x   12 root root  4096 Oct 19 08:37 java-virtuals
> drwxr-xr-x  237 root root 12288 Jan 11 10:07 kde-apps
> drwxr-xr-x   86 root root  4096 Jan 11 10:07 kde-frameworks
> drwxr-xr-x   33 root root  4096 Jan 11 10:07 kde-misc
> drwxr-xr-x   50 root root  4096 Jan 11 10:07 kde-plasma
> drwxr-xr-x    2 root root 20480 Jan 11 10:07 licenses
> drwxr-xr-x   17 root root  4096 Nov 18 08:59 lxde-base
> drwxr-xr-x   18 root root  4096 Jan  2 12:06 lxqt-base
> drwxr-xr-x   27 root root  4096 Jan 11 10:07 mail-client
> drwxr-xr-x   56 root root  4096 Jan 11 10:07 mail-filter
> drwxr-xr-x   14 root root  4096 Jan 11 10:07 mail-mta
> drwxr-xr-x   14 root root  4096 Dec 14 09:08 mate-base
> drwxr-xr-x   16 root root  4096 Jan 11 10:07 mate-extra
> drwxr-xr-x  219 root root 12288 Jan 11 10:07 media-fonts
> drwxr-xr-x  244 root root 12288 Jan 11 10:07 media-gfx
> drwxr-xr-x  397 root root 12288 Jan 11 10:07 media-libs
> drwxr-xr-x  293 root root 12288 Jan 11 10:07 media-plugins
> drwxr-xr-x   31 root root  4096 Jan  2 12:06 media-radio
> drwxr-xr-x  378 root root 12288 Jan 11 10:07 media-sound
> drwxr-xr-x   24 root root  4096 Jan 11 10:07 media-tv
> drwxr-xr-x  164 root root  4096 Jan 11 10:07 media-video
> drwxr-xr-x    9 root root  4096 Jan 11 10:07 metadata
> drwxr-xr-x  286 root root 12288 Jan 11 10:08 net-analyzer
> drwxr-xr-x   37 root root  4096 Jan 11 10:08 net-dialup
> drwxr-xr-x   54 root root  4096 Jan 11 10:08 net-dns
> drwxr-xr-x   29 root root  4096 Jan 11 10:08 net-firewall
> drwxr-xr-x   28 root root  4096 Jan 11 10:08 net-fs
> drwxr-xr-x   25 root root  4096 Jan 11 10:08 net-ftp
> drwxr-xr-x   58 root root  4096 Jan 11 10:08 net-im
> drwxr-xr-x   48 root root  4096 Jan 11 10:08 net-irc
> drwxr-xr-x  199 root root  4096 Jan 11 10:08 net-libs
> drwxr-xr-x   92 root root  4096 Jan 11 10:08 net-mail
> drwxr-xr-x  339 root root 12288 Jan 11 10:08 net-misc
> drwxr-xr-x   16 root root  4096 Dec 18 07:47 net-nds
> drwxr-xr-x   14 root root  4096 Jan 11 10:08 net-news
> drwxr-xr-x   13 root root  4096 Dec 27 13:24 net-nntp
> drwxr-xr-x   48 root root  4096 Jan 11 10:08 net-p2p
> drwxr-xr-x   39 root root  4096 Jan 11 10:08 net-print
> drwxr-xr-x   32 root root  4096 Jan 11 10:08 net-proxy
> drwxr-xr-x    7 root root  4096 Dec 14 09:08 net-voip
> drwxr-xr-x   38 root root  4096 Jan 11 10:08 net-vpn
> drwxr-xr-x  111 root root  4096 Jan 11 10:08 net-wireless
> drwxr-xr-x   49 root root  4096 Dec 14 09:08 perl-core
> drwxr-xr-x   13 root root  4096 Jan 11 10:08 profiles
> drwxr-xr-x   54 root root  4096 Dec 18 07:47 ros-meta
> drwxr-xr-x   40 root root  4096 Jan 11 10:08 sci-astronomy
> drwxr-xr-x  144 root root  4096 Jan 11 10:08 sci-biology
> drwxr-xr-x   21 root root  4096 Jan 11 10:08 sci-calculators
> drwxr-xr-x   93 root root  4096 Jan 11 10:08 sci-chemistry
> drwxr-xr-x   59 root root  4096 Jan 11 10:08 sci-electronics
> drwxr-xr-x   67 root root  4096 Jan 11 10:08 sci-geosciences
> drwxr-xr-x  254 root root 12288 Jan 11 10:08 sci-libs
> drwxr-xr-x   88 root root  4096 Jan 11 10:08 sci-mathematics
> drwxr-xr-x   22 root root  4096 Jan 11 10:08 sci-misc
> drwxr-xr-x   35 root root  4096 Jan 11 10:08 sci-physics
> drwxr-xr-x   33 root root  4096 Jan 11 10:08 sci-visualization
> drwxr-xr-x    2 root root  4096 Jun 10  2019 scripts
> drwxr-xr-x  260 root root 12288 Dec 22 09:59 sec-policy
> -rw-r--r--    1 root root  7491 Jan  3 19:39 skel.ebuild
> -rw-r--r--    1 root root  1173 Feb 28  2017 skel.metadata.xml
> drwxr-xr-x  301 root root 12288 Jan 11 10:08 sys-apps
> drwxr-xr-x   63 root root  4096 Jan 11 10:08 sys-auth
> drwxr-xr-x   65 root root  4096 Jan 11 10:08 sys-block
> drwxr-xr-x   41 root root  4096 Jan 11 10:08 sys-boot
> drwxr-xr-x   79 root root  4096 Jan 11 10:08 sys-cluster
> drwxr-xr-x   57 root root  4096 Jan 11 10:08 sys-devel
> drwxr-xr-x   27 root root  4096 Jan  5 11:08 sys-fabric
> drwxr-xr-x   31 root root  4096 Jan 11 10:08 sys-firmware
> drwxr-xr-x  132 root root  4096 Jan 11 10:08 sys-fs
> drwxr-xr-x   32 root root  4096 Jan 11 10:08 sys-kernel
> drwxr-xr-x   88 root root  4096 Jan 11 10:08 sys-libs
> drwxr-xr-x   31 root root  4096 Jan 11 10:08 sys-power
> drwxr-xr-x   54 root root  4096 Jan 11 10:08 sys-process
> drwxr-xr-x  201 root root 12288 Jan 11 10:08 virtual
> drwxr-xr-x   43 root root  4096 Jan 11 10:08 www-apache
> drwxr-xr-x   80 root root  4096 Jan 11 10:08 www-apps
> drwxr-xr-x   38 root root  4096 Jan 11 10:08 www-client
> drwxr-xr-x   22 root root  4096 Jan 11 10:08 www-misc
> drwxr-xr-x   11 root root  4096 Jan 11 10:08 www-plugins
> drwxr-xr-x   33 root root  4096 Jan 11 10:08 www-servers
> drwxr-xr-x   91 root root  4096 Jan 11 10:08 x11-apps
> drwxr-xr-x    7 root root  4096 Jan 11 10:08 x11-base
> drwxr-xr-x   33 root root  4096 Jan  4 11:40 x11-drivers
> drwxr-xr-x  126 root root  4096 Jan 11 10:08 x11-libs
> drwxr-xr-x  299 root root 12288 Jan 11 10:08 x11-misc
> drwxr-xr-x  172 root root  4096 Dec 27 13:24 x11-plugins
> drwxr-xr-x   29 root root  4096 Jan 11 10:08 x11-terms
> drwxr-xr-x  137 root root  4096 Jan 11 10:08 x11-themes
> drwxr-xr-x   59 root root  4096 Jan 11 10:08 x11-wm
> drwxr-xr-x   15 root root  4096 Jan 11 10:08 xfce-base
> drwxr-xr-x   55 root root  4096 Jan 11 10:08 xfce-extra
>
>
> You may need to remove the whole tree as Neil did, if the verification fails
> because of the portage tree contents.  Theoretically a re-sync ought to fix
> this, because the .tmp-unverified-download-quarantine file would/should be
> initially overwritten and eventually deleted once the verification is
> complete, but as you reported it didn't do so.  :-/
>
> This bug points to the tree owned by root:root instead of portage:portage,
> interestingly in my most recent installation the tree is owned by root as you
> can see above and I'm not getting this problem.
>
> https://bugs.gentoo.org/661834
>

I'm not exactly sure what you mean here ... did you do a chown -R or
will the ownership be different when my new stage3 is finally downloaded?

I'm not keen on overriding the default configuration in a global way 
like changing the ownwhip of all files.

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Mon, 13 Jan 2020 09:34:01 +0100, n952162 wrote:

> >> If you're using the new default location, I think it is
> >> /var/db/repos/gentoo, but someone should confirm that.  
> > Yes, the new location for the portage ebuilds is:
> >
> > $ ls -la /var/db/repos/gentoo/.*
> > /var/db/repos/gentoo/.:  
> 
> 
> 
> I just noticed that there's a new stag3, from 2020/01/12 instead of
> 2020/01/08 so - since this is a fresh install - I'm just going to start
> from there.

The stage3 doesn't include the portage tree, so that is unlikely to make
a difference. Remove the portage tree and either download a snapshot or
resync it.


-- 
Neil Bothwick

Top Oxymorons Number 43: Genuine imitation

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Monday, 13 January 2020 08:34:01 GMT n952162 wrote:
> On 2020-01-13 09:22, Mick wrote:
> >>> Same result.  But I didn't delete "the whole portage tree".  What does
> >>> that mean?
> >>> 
> >>> rm -rf /var/db/repos?
> >> 
> >> If you're using the new default location, I think it is
> >> /var/db/repos/gentoo, but someone should confirm that.
> > 
> > Yes, the new location for the portage ebuilds is:
> > 
> > $ ls -la /var/db/repos/gentoo/.*
> 
> > /var/db/repos/gentoo/.:
> I just noticed that there's a new stag3, from 2020/01/12 instead of
> 2020/01/08 so - since this is a fresh install - I'm just going to start
> from there.

The portage tree is sync'ed to the portage tree mirrors.  A newer fs snapshot 
won't include the tree itself, but it will include the new default fs 
locations for the portage directory.


> > This bug points to the tree owned by root:root instead of portage:portage,
> > interestingly in my most recent installation the tree is owned by root as
> > you can see above and I'm not getting this problem.
> > 
> > https://bugs.gentoo.org/661834
> 
> I'm not exactly sure what you mean here ... did you do a chown -R or
> will the ownership be different when my new stage3 is finally downloaded?

I do not recall running a chown on this installation.  Had I done this, in all 
likelihood I would have chown'ed it to portage:portage, as older installations 
of mine are set to.


> I'm not keen on overriding the default configuration in a global way 
> like changing the ownwhip of all files.

Right, I haven't changed them on this installation either and emerge FEATURES 
include

'... userfetch userpriv usersandbox usersync'.

With 'userpriv' portage is meant to drop privileges to the owner of the gentoo 
repo directory, but if the directory is owned by root to start with I am not 
clear how userpriv is meant to work.  I take it your gentoo portage tree is 
also owned by root:root in its default installation state?

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-13 11:17, Mick wrote:

>> I just noticed that there's a new stag3, from 2020/01/12 instead of
>> 2020/01/08 so - since this is a fresh install - I'm just going to start
>> from there.
> The portage tree is sync'ed to the portage tree mirrors.  A newer fs snapshot
> won't include the tree itself, but it will include the new default fs
> locations for the portage directory.


Not sure what you mean ... you mean that the portage tree only comes in
with the emerge --sync?

A preliminary copy isn't in the stage3 tarball?


> I take it your gentoo portage tree is
> also owned by root:root in its default installation state?
>
Oh, I see you're right - I unpacked it though by cut&paste of the
command in the handbook (with -p, I'm sure).

Anyway, I  used a different sync and timed it more carefully: 1 1/4
hours for the --sync.  Completely from scatch.  Completely - only
lost+found and the tarball in the partition.  Using the stage3 that's 4
days newer.  I get the same result.

The minimal CD hasn't changed since the 8th.  Presumably lots of people
have used it since then ...

New hardware: AMD Ryzen 3 3200g, Asrock b450m mainboard.

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On Mon, 13 Jan 2020 11:42:23 +0100, n952162 wrote:

> > The portage tree is sync'ed to the portage tree mirrors.  A newer fs
> > snapshot won't include the tree itself, but it will include the new
> > default fs locations for the portage directory.  
> 
> 
> Not sure what you mean ... you mean that the portage tree only comes in
> with the emerge --sync?
> 
> A preliminary copy isn't in the stage3 tarball?

That's correct.


-- 
Neil Bothwick

After all is said and done let there not be more said than done.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-13 11:48, Neil Bothwick wrote:
> On Mon, 13 Jan 2020 11:42:23 +0100, n952162 wrote:
>
>>> The portage tree is sync'ed to the portage tree mirrors.  A newer fs
>>> snapshot won't include the tree itself, but it will include the new
>>> default fs locations for the portage directory.
>>
>> Not sure what you mean ... you mean that the portage tree only comes in
>> with the emerge --sync?
>>
>> A preliminary copy isn't in the stage3 tarball?
> That's correct.
>
>
is this happening because I'm not using (the "optional") webrsync?

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Mon, 13 Jan 2020 12:37:11 +0100, n952162 wrote:

> >>> The portage tree is sync'ed to the portage tree mirrors.  A newer fs
> >>> snapshot won't include the tree itself, but it will include the new
> >>> default fs locations for the portage directory.  
> >>
> >> Not sure what you mean ... you mean that the portage tree only comes
> >> in with the emerge --sync?
> >>
> >> A preliminary copy isn't in the stage3 tarball?  
> > That's correct.
> >
> >  
> is this happening because I'm not using (the "optional") webrsync?

It happens because the stage 3 doesn't contain a tree. The handbook tells
you to run a sync after unpacking the stage 3 for that reason. webrsync
is just another way of syncing, one that is more efficient than rsync
when starting with an empty tree.


-- 
Neil Bothwick

An expert is nothing more than an ordinary person away from home.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-13 23:42, Neil Bothwick wrote:
> On Mon, 13 Jan 2020 12:37:11 +0100, n952162 wrote:
>
>>>>> The portage tree is sync'ed to the portage tree mirrors.  A newer fs
>>>>> snapshot won't include the tree itself, but it will include the new
>>>>> default fs locations for the portage directory.
>>>> Not sure what you mean ... you mean that the portage tree only comes
>>>> in with the emerge --sync?
>>>>
>>>> A preliminary copy isn't in the stage3 tarball?
>>> That's correct.
>>>
>>>
>> is this happening because I'm not using (the "optional") webrsync?
> It happens because the stage 3 doesn't contain a tree. The handbook tells
> you to run a sync after unpacking the stage 3 for that reason. webrsync
> is just another way of syncing, one that is more efficient than rsync
> when starting with an empty tree.
>
>
I mean, am I getting these manifest/verification errors because I
haven't used webrsync (apparently not).

Which leaves me in a deadlocked situation.  A fresh install, according
to the instructions, on new hardware, fails.  What should I do?  Does
anyone else have this problem?

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On Mon, 13 Jan 2020 10:17:06 +0000, Mick wrote:

> Right, I haven't changed them on this installation either and emerge
> FEATURES include
> 
> '... userfetch userpriv usersandbox usersync'.
> 
> With 'userpriv' portage is meant to drop privileges to the owner of the
> gentoo repo directory, but if the directory is owned by root to start
> with I am not clear how userpriv is meant to work.

According to the make.conf man page, userpriv will

"Allow portage to drop root privileges and compile packages as
portage:portage without a sandbox"


-- 
Neil Bothwick

Everything should be made as simple as possible, but no simpler.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

On Monday, 13 January 2020 10:42:57 GMT Neil Bothwick wrote:
> On Mon, 13 Jan 2020 10:17:06 +0000, Mick wrote:
> > Right, I haven't changed them on this installation either and emerge
> > FEATURES include
> > 
> > '... userfetch userpriv usersandbox usersync'.
> > 
> > With 'userpriv' portage is meant to drop privileges to the owner of the
> > gentoo repo directory, but if the directory is owned by root to start
> > with I am not clear how userpriv is meant to work.
> 
> According to the make.conf man page, userpriv will
> 
> "Allow portage to drop root privileges and compile packages as
> portage:portage without a sandbox"

According to my emerge --info output I have sandbox, usersandbox and userpriv, 
all set.  The owner of my portage directory and all files therein is 
root:root.  Should the ownership be portage:portage?  What is the default?

I haven't performed a full portage sync for a while now to confirm how long it 
takes here, but a re-sync over a slow ADSL takes ~20 minutes on a dual core 
ancient Intel, much less on my more modern PCs.  More than 80% of this time is 
spent on verifying the signatures of the downloaded tmp sync file.  I would 
think on a modern AMD Ryzen PC like the OP's it should take a fraction of the 
time.
-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Mon, 13 Jan 2020 11:15:31 +0000, Mick wrote:

> According to my emerge --info output I have sandbox, usersandbox and
> userpriv, all set.  The owner of my portage directory and all files
> therein is root:root.  Should the ownership be portage:portage?  What
> is the default?

As it happens, I switched a machine from rsync to git syncing last night,
so started with a new tree. Everything is root:root. That implies that
portage does not drop permissions for the sync, otherwise it wouldn't be
able to write to the tree. And ps confirms that with an rsync sync, rsync
is running as root.


-- 
Neil Bothwick

Cross a tagline and a tribble? You get a full HD...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Mick]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Monday, 13 January 2020 22:40:14 GMT Neil Bothwick wrote:
> On Mon, 13 Jan 2020 11:15:31 +0000, Mick wrote:
> > According to my emerge --info output I have sandbox, usersandbox and
> > userpriv, all set.  The owner of my portage directory and all files
> > therein is root:root.  Should the ownership be portage:portage?  What
> > is the default?
> 
> As it happens, I switched a machine from rsync to git syncing last night,
> so started with a new tree. Everything is root:root. That implies that
> portage does not drop permissions for the sync, otherwise it wouldn't be
> able to write to the tree. And ps confirms that with an rsync sync, rsync
> is running as root.

Thanks Neil, this this leaves me mildly confused as to what the gentoo-default 
ownership of portage tree is/should be.  Until I hear differently I'll leave 
my old installations as portage:portage and the latest as root:root.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-14 00:16, Mick wrote:
> On Monday, 13 January 2020 22:40:14 GMT Neil Bothwick wrote:
>> On Mon, 13 Jan 2020 11:15:31 +0000, Mick wrote:
>>> According to my emerge --info output I have sandbox, usersandbox and
>>> userpriv, all set.  The owner of my portage directory and all files
>>> therein is root:root.  Should the ownership be portage:portage?  What
>>> is the default?
>> As it happens, I switched a machine from rsync to git syncing last night,
>> so started with a new tree. Everything is root:root. That implies that
>> portage does not drop permissions for the sync, otherwise it wouldn't be
>> able to write to the tree. And ps confirms that with an rsync sync, rsync
>> is running as root.
> Thanks Neil, this this leaves me mildly confused as to what the gentoo-default
> ownership of portage tree is/should be.  Until I hear differently I'll leave
> my old installations as portage:portage and the latest as root:root.
>
It sounds to me like the repository is broken - having ownership as root
seems to be slightly more entropy than portage and could have happened
as a unintended consequence of some uncarefully completed operation.

Is this the proper list to be on?

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:

> It sounds to me like the repository is broken - having ownership as root
> seems to be slightly more entropy than portage and could have happened
> as a unintended consequence of some uncarefully completed operation.

If the repository was broken, it would be affecting a lot more people
than just you.

Have you tried completely removing your portage tree and reinstating it
with webrsync?
 
> Is this the proper list to be on?

It's the Gentoo User list, which seems to fit.


-- 
Neil Bothwick

If ignorance is bliss, why aren't more people happy?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-14 09:44, Neil Bothwick wrote:
> On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
>
>> It sounds to me like the repository is broken - having ownership as root
>> seems to be slightly more entropy than portage and could have happened
>> as a unintended consequence of some uncarefully completed operation.
> If the repository was broken, it would be affecting a lot more people
> than just you.
>
> Have you tried completely removing your portage tree and reinstating it
> with webrsync?


This is a fresh install from a minimal cd image.  I'm starting out with
mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
and once using a stage 3 from 2020/01/12.

Thus, in answer to your question, yes, I've always removed the portage
tree (and everything else).

I've always used emerge --sync rather than webrsync because I always
like to use the smallest hammer possible.  But if you say I should use
webrsync rather than emerge --sync, I have no other hint.



>
>> Is this the proper list to be on?
> It's the Gentoo User list, which seems to fit.
>
>

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Tue, 14 Jan 2020 10:37:24 +0100, n952162 wrote:

> > Have you tried completely removing your portage tree and reinstating
> > it with webrsync?  

> I've always used emerge --sync rather than webrsync because I always
> like to use the smallest hammer possible.  But if you say I should use
> webrsync rather than emerge --sync, I have no other hint.

It's certainly worth trying webrsync, if anything else, it's faster for a
full tree.

I prefer to use the largest hammer and let the tool do the work for me ;-)


-- 
Neil Bothwick

SCSI: System Can't See It

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Peter Humphrey]

On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote:
> On 2020-01-14 09:44, Neil Bothwick wrote:
> > On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
> >> It sounds to me like the repository is broken - having ownership as root
> >> seems to be slightly more entropy than portage and could have happened
> >> as a unintended consequence of some uncarefully completed operation.
> > 
> > If the repository was broken, it would be affecting a lot more people
> > than just you.
> > 
> > Have you tried completely removing your portage tree and reinstating it
> > with webrsync?
> 
> This is a fresh install from a minimal cd image.  I'm starting out with
> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
> and once using a stage 3 from 2020/01/12.

Er...you aren't running out of disk space, are you (either physical space or 
inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge --sync' 
return? Specifically, did you see a 'Sync completed' message? Have you watched 
/usr/bin/top status lines while syncing?

And have you actually tried emerge-webrsync?

-- 
Regards,
Peter.

Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

On 2020-01-14 11:10, Peter Humphrey wrote:
> On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote:
>> On 2020-01-14 09:44, Neil Bothwick wrote:
>>> On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
>>>> It sounds to me like the repository is broken - having ownership as root
>>>> seems to be slightly more entropy than portage and could have happened
>>>> as a unintended consequence of some uncarefully completed operation.
>>> If the repository was broken, it would be affecting a lot more people
>>> than just you.
>>>
>>> Have you tried completely removing your portage tree and reinstating it
>>> with webrsync?
>> This is a fresh install from a minimal cd image.  I'm starting out with
>> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
>> and once using a stage 3 from 2020/01/12.
> Er...you aren't running out of disk space, are you (either physical space or
> inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge --sync'
> return? Specifically, did you see a 'Sync completed' message? Have you watched
> /usr/bin/top status lines while syncing?
>
> And have you actually tried emerge-webrsync?
>

'emerge --sync' gave me status 1 and before that, the error about the
manifest:


Number of files: 158,236 (reg: 131,524, dir: 26,712)
Number of created files: 158,235 (reg: 131,524, dir: 26,711)
Number of deleted files: 0
Number of regular files transferred: 131,524
Total file size: 208.96M bytes
Total transferred file size: 208.96M bytes
Literal data: 208.96M bytes
Matched data: 0 bytes
File list size: 3.90M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2.71M
Total bytes received: 218.79M

sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec
total size is 208.96M  speedup is 0.94
  * Manifest timestamp: 2020-01-12 18:38:55 UTC
  * Valid OpenPGP signature found:
  * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
  * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
  * - timestamp: 2020-01-12 18:38:55 UTC
  * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
...!!! Manifest v>
Manifest mismatch for media-plugins/Manifest.gz
   __size__: expected: 48363, have: 48349


Inodes?  That's an interesting thought.  Not sure how I'd check that ...
I'll redirect the output into a file next time.

What would I look for in the top(1) status lines (the lines at the top
before the process table?)?

With emerge-webrsync do you mean webrsync or is there some additional
facility?

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Dale]

n952162 wrote:
> On 2020-01-14 11:10, Peter Humphrey wrote:
>> On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote:
>>> On 2020-01-14 09:44, Neil Bothwick wrote:
>>>> On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
>>>>> It sounds to me like the repository is broken - having ownership
>>>>> as root
>>>>> seems to be slightly more entropy than portage and could have
>>>>> happened
>>>>> as a unintended consequence of some uncarefully completed operation.
>>>> If the repository was broken, it would be affecting a lot more people
>>>> than just you.
>>>>
>>>> Have you tried completely removing your portage tree and
>>>> reinstating it
>>>> with webrsync?
>>> This is a fresh install from a minimal cd image.  I'm starting out with
>>> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
>>> and once using a stage 3 from 2020/01/12.
>> Er...you aren't running out of disk space, are you (either physical
>> space or
>> inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge
>> --sync'
>> return? Specifically, did you see a 'Sync completed' message? Have
>> you watched
>> /usr/bin/top status lines while syncing?
>>
>> And have you actually tried emerge-webrsync?
>>
>
> 'emerge --sync' gave me status 1 and before that, the error about the
> manifest:
>
>
> Number of files: 158,236 (reg: 131,524, dir: 26,712)
> Number of created files: 158,235 (reg: 131,524, dir: 26,711)
> Number of deleted files: 0
> Number of regular files transferred: 131,524
> Total file size: 208.96M bytes
> Total transferred file size: 208.96M bytes
> Literal data: 208.96M bytes
> Matched data: 0 bytes
> File list size: 3.90M
> File list generation time: 0.001 seconds
> File list transfer time: 0.000 seconds
> Total bytes sent: 2.71M
> Total bytes received: 218.79M
>
> sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec
> total size is 208.96M  speedup is 0.94
>  * Manifest timestamp: 2020-01-12 18:38:55 UTC
>  * Valid OpenPGP signature found:
>  * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
>  * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
>  * - timestamp: 2020-01-12 18:38:55 UTC
>  * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> ...!!! Manifest v>
> Manifest mismatch for media-plugins/Manifest.gz
>   __size__: expected: 48363, have: 48349
>
>
> Inodes?  That's an interesting thought.  Not sure how I'd check that ...
> I'll redirect the output into a file next time.
>
> What would I look for in the top(1) status lines (the lines at the top
> before the process table?)?
>
> With emerge-webrsync do you mean webrsync or is there some additional
> facility

The df command will give you that info.  This is a example just replace
your device with the one I used.

df -i /dev/sdb1

Hope that helps.

Dale

:-)  :-) 

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Peter Humphrey]

On Tuesday, 14 January 2020 11:07:34 GMT n952162 wrote:
> On 2020-01-14 11:10, Peter Humphrey wrote:
--->8
> >> This is a fresh install from a minimal cd image.  I'm starting out with
> >> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
> >> and once using a stage 3 from 2020/01/12.
> > 
> > Er...you aren't running out of disk space, are you (either physical space
> > or inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge
> > --sync' return? Specifically, did you see a 'Sync completed' message?
> > Have you watched /usr/bin/top status lines while syncing?
> > 
> > And have you actually tried emerge-webrsync?
> 
> 'emerge --sync' gave me status 1 and before that, the error about the
> manifest:

I didn't see a manifest error before; perhaps I overlooked it.

> Number of files: 158,236 (reg: 131,524, dir: 26,712)
> Number of created files: 158,235 (reg: 131,524, dir: 26,711)
> Number of deleted files: 0
> Number of regular files transferred: 131,524
> Total file size: 208.96M bytes
> Total transferred file size: 208.96M bytes
> Literal data: 208.96M bytes
> Matched data: 0 bytes
> File list size: 3.90M
> File list generation time: 0.001 seconds
> File list transfer time: 0.000 seconds
> Total bytes sent: 2.71M
> Total bytes received: 218.79M
> 
> sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec

HOW long?! 56KB/s shows something going badly wrong.

> total size is 208.96M  speedup is 0.94

I've never seen a speedup less than 1 before.

>   * Manifest timestamp: 2020-01-12 18:38:55 UTC
>   * Valid OpenPGP signature found:
>   * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
>   * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
>   * - timestamp: 2020-01-12 18:38:55 UTC
>   * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> ...!!! Manifest v>
> Manifest mismatch for media-plugins/Manifest.gz
>    __size__: expected: 48363, have: 48349

That would indeed leave the tree safely in quarantine.

> Inodes?  That's an interesting thought.  Not sure how I'd check that ...
> I'll redirect the output into a file next time.
> 
> What would I look for in the top(1) status lines (the lines at the top
> before the process table?)?

I'd want to see how much memory and swap were consumed and available; the
processor load may offer you a clue too.
 
> With emerge-webrsync do you mean webrsync or is there some additional
> facility?

According to the Wiki* the first thing you do after chrooting into the new
system is to issue the command 'emerge-webrsync'. I suggest you try it.


*  https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Installing_an_ebuild_repository_snapshot_from_the_web

-- 
Regards,
Peter.

Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

I guess you're referring to this:

"The use of emerge-webrsync is recommended for those who are behind restrictive firewalls (because it uses HTTP/FTP protocols for downloading the snapshot) and saves network bandwidth. Readers who have no network or bandwidth restrictions can happily skip down to the next section."

Indeed that was a sub-theme of my question (although I oversaw that "emerge-" was indeed part of the command): could that have an impact on my problem?  I'm not behind a firewall and have no bandwidth restrictions (DSL).  It's a bad state when you start having to do things which are nominally not relevant, because you don't have anything else to lose (but time).  That's called "grasping at straws"


> Gesendet: Dienstag, 14. Januar 2020 um 16:47 Uhr
> Von: "Peter Humphrey" <peter@prh.myzen.co.uk>
> An: gentoo-user@lists.gentoo.org
> Betreff: Re: [gentoo-user] .tmp-unverified-download-quarantine
>
> On Tuesday, 14 January 2020 11:07:34 GMT n952162 wrote:
> > On 2020-01-14 11:10, Peter Humphrey wrote:
> --->8
> > >> This is a fresh install from a minimal cd image.  I'm starting out with
> > >> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
> > >> and once using a stage 3 from 2020/01/12.
> > >
> > > Er...you aren't running out of disk space, are you (either physical space
> > > or inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge
> > > --sync' return? Specifically, did you see a 'Sync completed' message?
> > > Have you watched /usr/bin/top status lines while syncing?
> > >
> > > And have you actually tried emerge-webrsync?
> >
> > 'emerge --sync' gave me status 1 and before that, the error about the
> > manifest:
>
> I didn't see a manifest error before; perhaps I overlooked it.
>
> > Number of files: 158,236 (reg: 131,524, dir: 26,712)
> > Number of created files: 158,235 (reg: 131,524, dir: 26,711)
> > Number of deleted files: 0
> > Number of regular files transferred: 131,524
> > Total file size: 208.96M bytes
> > Total transferred file size: 208.96M bytes
> > Literal data: 208.96M bytes
> > Matched data: 0 bytes
> > File list size: 3.90M
> > File list generation time: 0.001 seconds
> > File list transfer time: 0.000 seconds
> > Total bytes sent: 2.71M
> > Total bytes received: 218.79M
> >
> > sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec
>
> HOW long?! 56KB/s shows something going badly wrong.
>
> > total size is 208.96M  speedup is 0.94
>
> I've never seen a speedup less than 1 before.
>
> >   * Manifest timestamp: 2020-01-12 18:38:55 UTC
> >   * Valid OpenPGP signature found:
> >   * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
> >   * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
> >   * - timestamp: 2020-01-12 18:38:55 UTC
> >   * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> > ...!!! Manifest v>
> > Manifest mismatch for media-plugins/Manifest.gz
> >    __size__: expected: 48363, have: 48349
>
> That would indeed leave the tree safely in quarantine.
>
> > Inodes?  That's an interesting thought.  Not sure how I'd check that ...
> > I'll redirect the output into a file next time.
> >
> > What would I look for in the top(1) status lines (the lines at the top
> > before the process table?)?
>
> I'd want to see how much memory and swap were consumed and available; the
> processor load may offer you a clue too.
>
> > With emerge-webrsync do you mean webrsync or is there some additional
> > facility?
>
> According to the Wiki* the first thing you do after chrooting into the new
> system is to issue the command 'emerge-webrsync'. I suggest you try it.
>
>
> *  https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Installing_an_ebuild_repository_snapshot_from_the_web
>
> --
> Regards,
> Peter.
>
>
>
>
>

Re: Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine

[Peter Humphrey]

On Tuesday, 14 January 2020 18:36:23 GMT n952162@web.de wrote:
> I guess you're referring to this:
> 
> "The use of emerge-webrsync is recommended for those who are behind
> restrictive firewalls (because it uses HTTP/FTP protocols for downloading
> the snapshot) and saves network bandwidth. Readers who have no network or
> bandwidth restrictions can happily skip down to the next section."
> 
> Indeed that was a sub-theme of my question (although I oversaw that
> "emerge-" was indeed part of the command): could that have an impact on my
> problem?  I'm not behind a firewall and have no bandwidth restrictions
> (DSL).  It's a bad state when you start having to do things which are
> nominally not relevant, because you don't have anything else to lose (but
> time).  That's called "grasping at straws"

Why don't you just try it? What could you lose?

"When all else fails, read the instructions."

-- 
Regards,
Peter.

Fw: Re: Re: [gentoo-user] .tmp-unverified-download-quarantine

[n952162]

In what way is emerge sensitive to reduced bandwidth?

> Gesendet: Donnerstag, 16. Januar 2020 um 11:48 Uhr
> Von: "Peter Humphrey" <peter@prh.myzen.co.uk>
> An: n952162 <n952162@web.de>
> Betreff: Re: Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine
>
> On Thursday, 16 January 2020 07:28:19 GMT you wrote:
>
> > But it's not synced, and that's the point in the end.
>
> Well, it isn't far off. The tarball will have been made no earlier than the
> previous day.
>
> > Now I don't know, if I run emerge --sync, will it corrupt the system
> > I've just installed?
>
> I can't see how. The worst it can do is to repeat your original problem, and
> you'll be no worse off except for the disk space used. If the --sync fails on
> verification, the new portage tree will be left in quarantine; that's what the
> verification step is for.
>
> I've reinstalled systems here recently more often than I can count, and I've
> always gone on from emerge-webrsync without another --sync. When I have a
> bootable system I do boot it, then finish the system build natively, as it
> were.
>
> When all packages have been installed and configured, I do a --sync and an -e
> @world, just to make sure everything fits together properly*.
>
> You will need to do something about that DSL link though, if it's still as bad
> while running your new system.
>
> * Actually, I'm more paranoid than that: I do an emerge @system, then
> recompile and reboot the kernel, then an -e @world minus what was installed by
> @system. I've no doubt that all the experts would say it's pointless, but I
> learned caution when I was leading the team that maintained the 15-mainframe
> system at five control centres that runs the national grid in England and
> Wales. That was 25 years ago, but some habits stick - and CPU cycles are
> cheap.
>
> --
> Regards,
> Peter.
>
>
>
>

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

On Tue, 14 Jan 2020 15:47:51 +0000, Peter Humphrey wrote:

> > sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec  
> 
> HOW long?! 56KB/s shows something going badly wrong.

This sounds like it could be a network problem. Have you used
mirrorselect?
 
> > total size is 208.96M  speedup is 0.94  
> 
> I've never seen a speedup less than 1 before.
> 
> >   * Manifest timestamp: 2020-01-12 18:38:55 UTC
> >   * Valid OpenPGP signature found:
> >   * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
> >   * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
> >   * - timestamp: 2020-01-12 18:38:55 UTC
> >   * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> > ...!!! Manifest v>
> > Manifest mismatch for media-plugins/Manifest.gz
> >    __size__: expected: 48363, have: 48349  
> 
> That would indeed leave the tree safely in quarantine.

I wondered if the file was truncated from some sort of network problem,
until I checked my tree and saw that that file was 48349 bytes and
portage was really happy.
 
> > Inodes?  That's an interesting thought.  Not sure how I'd check that
> > ... I'll redirect the output into a file next time.
> > 
> > What would I look for in the top(1) status lines (the lines at the top
> > before the process table?)?  
> 
> I'd want to see how much memory and swap were consumed and available;
> the processor load may offer you a clue too.
>  
> > With emerge-webrsync do you mean webrsync or is there some additional
> > facility?  
> 
> According to the Wiki* the first thing you do after chrooting into the
> new system is to issue the command 'emerge-webrsync'. I suggest you try
> it.

I would definitely try emerge-webrsync as it downloads a consistent
snapshot of the system. You say you have no network or bandwidth
restrictions, but 56K/s says otherwise.


-- 
Neil Bothwick

... but you can't expect to wield supreme executive power just because
some watery tart threw a sword at you!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] .tmp-unverified-download-quarantine

[Dale]

Mick wrote:
> On Sunday, 12 January 2020 23:32:16 GMT Neil Bothwick wrote:
>> On Sun, 12 Jan 2020 23:41:43 +0100, n952162 wrote:
>>>> I had a similar issue with the .tmp-unverified-download-quarantine
>>>> continually appearing, deleting it made no difference. In the end I
>>>> deleted the whole portage tree and resynced, then the problem
>>>> disappeared. This may or may not have a bearing on your profile issue,
>>>> but it's worth fixing first.
>>> I just finished running "emerge --sync" again, based on something I saw
>>> on the internet - it did the whole thing again, takes about 2 hours. 
>> Two hours? How slow is your connection?
> Assuming this is not the time it takes to run rsync (even on a dial-up 
> analogue modem connection?) I would guess the delay is caused by the post-sync 
> tree verification.  The .tmp-unverified-download-quarantine file is where the 
> sync is stored until the signature verification is performed.  Even on a 
> really old dual-core laptop with low RAM the sync and verification only takes 
> around 20 minutes.
>
>

I'm on DSL, fairly slow DSL but DSL is what they call it, and had a long
re-sync time until a month or so ago.  It started around the time the
verification part started so I assumed it was that.  Then it kept
getting slower and slower.  After a while, I decided to try something
else.  I found a different server to sync too.  The first one was a
little better but still slow.  I tried another one and hit the jackpot. 
It was several times faster than the original one. 

This may not be your problem but it may be worth looking into.  You can
use mirrorselect to help you find a good server.  Try a few and see what
changes.  For me at least, it pretty much maxes out my DSL.  Obviously
there is some things that take a while that is done on my end but if the
download is slow due to a slow server, maybe you can find a faster one.

I might add, I've always tried to get servers that are physically close
by because they *should* be faster.  I've found that not to be true in
every case. 

As I said, this may not be your problem but it may be worth looking into
at least.  Just in case.

Dale

:-)  :-)