.tmp-unverified-download-quarantine

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

.tmp-unverified-download-quarantine

n952162

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.
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

james-3
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

Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
In reply to this post by n952162
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.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
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

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Mick-10
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
In reply to this post by james-3
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?


Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
In reply to this post by Mick-10
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.



Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
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

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Dale-46
In reply to this post by Mick-10
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

:-)  :-) 

Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Mick-10
In reply to this post by n952162
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
In reply to this post by Mick-10
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.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
In reply to this post by n952162
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.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Mick-10
In reply to this post by Neil Bothwick
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
In reply to this post by Neil Bothwick
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?



Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
In reply to this post by Mick-10
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...

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
In reply to this post by n952162
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.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Mick-10
In reply to this post by Neil Bothwick
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
In reply to this post by Neil Bothwick
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?


12