[ME TOO] Re: [gentoo-user] --sync

[Dr Rainer Woitok]

Neil,

On Sunday, 2022-07-31 21:43:12 +0100, you wrote:

> ...
> I switched to using git for syncing, from github, and haven't looked
> back. It is *much* faster, several times faster syncing from github than
> using rsync to sync from a local mirror, and github is always there.

The replies from you and some other people suggesting the use of Git for
syncing and providing howtos  were the straw that broke the camel's back
and overcame my lazyness.   So I too switched to Git and now am as happy
as can be :-D

Many thanks for this tip :-)

Sincerely,
  Rainer

Re: [gentoo-user] --sync

[Michael]

On Monday, 1 August 2022 10:43:55 BST tastytea wrote:
> On 2022-08-01 07:58+0100 Michael  wrote:
> > […]
> > 
> > 2. These days rsync uses hashes and gpg to check the integrity of
> > portage and will flag up a warning in case of file tampering, or
> > corrupt data.  As far as I know such a solution doesn't exist with
> > git.
> 
> Verification can be turned on with
>   sync-git-verify-commit-signature = yes
> in repos.conf.[1] This does not seem to be enabled by default.[2]
> 
> [1]
> 
> [2] 

I see ... this is an improvement from what I recall it to be.  Thanks for 
pointing it out.  Perhaps I should start using git again.  :-)

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

Re: [gentoo-user] --sync

[tastytea]

On 2022-08-01 07:58+0100 Michael  wrote:

> […]
> 
> 2. These days rsync uses hashes and gpg to check the integrity of
> portage and will flag up a warning in case of file tampering, or
> corrupt data.  As far as I know such a solution doesn't exist with
> git.

Verification can be turned on with
  sync-git-verify-commit-signature = yes
in repos.conf.[1] This does not seem to be enabled by default.[2]

[1] 
[2] 

Re: [gentoo-user] --sync

[Neil Bothwick]

On Mon, 01 Aug 2022 07:58:05 +0100, Michael wrote:

> 1. It used to be the case the first time you run git it would try to
> download GB of commits history and take ages to do so on a slow
> connection.  The solution used to be to add "EGIT_CLONE_TYPE=shallow"
> in your make.conf, but I'm not sure if this is still needed (I don't
> use git).

It doesn't seem to be the case, running sync with an empty portage tree
gives

>>> Syncing repository 'gentoo' into '/var/portage'...
/usr/bin/git clone --depth 1 https://github.com/gentoo-mirror/gentoo .

% du /var/portage
608M/var/portage

It did take 32s, but most of that was the Performing Global Updates stage.


-- 
Neil Bothwick

"A hundred years of forgetting and it all comes rushing back..."


pgpwv3Vd16uAM.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --sync

[Michael]

On Monday, 1 August 2022 06:09:07 BST n952162 wrote:
> On 7/31/22 21:51, n952162 wrote:
> > I've been running gentoo for years now, and every time I go to --sync,
> > it's really a painful process.
> > 
> > The process can take *very* before you find out if it succeeded or not.
> > 
> > I try different repos.conf servers - one works for a while, then
> > doesn't, then later, the new one doesn't work anymore and the old one
> > works again.
> > 
> > I've asked here about it multiple times and get the answers
> > 
> > - "I don't have a problem"
> > 
> > - "just change the server"
> > 
> > - "keep trying"
> > 
> > It can take several hours before it finally works
> > 
> > It seems like a time-out problem.  Or maybe a memory problem ... In any
> > case, it doesn't seem like it ought to be difficult to at least know
> > what the problem is.
> > 
> > Or?
> 
> Thanks all, for the various suggestions, I'll try each.

Two points to consider when choosing git to sync your portage tree:

1. It used to be the case the first time you run git it would try to download 
GB of commits history and take ages to do so on a slow connection.  The 
solution used to be to add "EGIT_CLONE_TYPE=shallow" in your make.conf, but 
I'm not sure if this is still needed (I don't use git).

2. These days rsync uses hashes and gpg to check the integrity of portage and 
will flag up a warning in case of file tampering, or corrupt data.  As far as I 
know such a solution doesn't exist with git.

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

Re: [gentoo-user] --sync

[n952162]

On 7/31/22 21:51, n952162 wrote:

I've been running gentoo for years now, and every time I go to --sync,
it's really a painful process.

The process can take *very* before you find out if it succeeded or not.

I try different repos.conf servers - one works for a while, then
doesn't, then later, the new one doesn't work anymore and the old one
works again.

I've asked here about it multiple times and get the answers

- "I don't have a problem"

- "just change the server"

- "keep trying"

It can take several hours before it finally works

It seems like a time-out problem.  Or maybe a memory problem ... In any
case, it doesn't seem like it ought to be difficult to at least know
what the problem is.

Or?




Thanks all, for the various suggestions, I'll try each.

Re: [gentoo-user] --sync

[Lee]

Given the speed improvement in using git for --sync, I wonder why that
isn't the default in the portage section of the manual

On Sun, Jul 31, 2022 at 4:49 PM Peter Humphrey 
wrote:

> On Sunday, 31 July 2022 21:43:12 BST Neil Bothwick wrote:
>
> > I switched to using git for syncing, from github, and haven't looked
> > back. It is *much* faster, several times faster syncing from github than
> > using rsync to sync from a local mirror, and github is always there.
>
> One thing to note, if you do change to git syncing, is that you'll have to
> delete your entire portage tree: 'rm -r /var/db/repos/portage'. That may
> seem
> like a bad idea if you're having sync problems, but it isn't really. After
> that, the sync will take just seconds, as Neil said.
>
> You'll never look back.
>
> --
> Regards,
> Peter.
>
>
>
>
>

-- 
Lee 

Re: [gentoo-user] --sync

[Peter Humphrey]

On Sunday, 31 July 2022 21:43:12 BST Neil Bothwick wrote:

> I switched to using git for syncing, from github, and haven't looked
> back. It is *much* faster, several times faster syncing from github than
> using rsync to sync from a local mirror, and github is always there.

One thing to note, if you do change to git syncing, is that you'll have to 
delete your entire portage tree: 'rm -r /var/db/repos/portage'. That may seem 
like a bad idea if you're having sync problems, but it isn't really. After 
that, the sync will take just seconds, as Neil said.

You'll never look back.

-- 
Regards,
Peter.

Re: [gentoo-user] --sync

[Neil Bothwick]

On Sun, 31 Jul 2022 15:55:51 -0700, Lee wrote:

> Had a similar issue to the OP, and it turned out to be a flaky internet
> connection. I switched ISP's and, while sync's still take longer than
> I'd like, I don't have the failures, time outs I did before.

I have no complaints about the time taken to sync

% time emerge --sync
>>> Syncing repository 'gentoo' into '/var/portage'...
/var/portage
/usr/bin/git fetch origin
[snip]
=== Sync completed for gentoo

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


emerge --sync  1.58s user 0.51s system 75% cpu 2.750 total


-- 
Neil Bothwick

Do Roman paramedics refer to IV's as "4's"?


pgp4CnHLsboO5.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --sync

[Lee]

Had a similar issue to the OP, and it turned out to be a flaky internet
connection. I switched ISP's and, while sync's still take longer than I'd
like, I don't have the failures, time outs I did before.

On Sun, Jul 31, 2022 at 1:54 PM Stefan Schmiedl  wrote:

> Sonntag, 31. Juli 2022 21:51:
>
>
>
> I've been running gentoo for years now, and every time I go to --sync,
> it's really a painful process.
>
>
> The process can take *very* [long] before you find out if it succeeded or
> not.
>
> ...
>
>
> It can take several hours before it finally works
>
>
>
> Use a tool like atop to get some info about the throughput
>
> of your network connection. Something like "ss -ntp" might
>
> show interesting info about the state of the connection
>
> between your machine and the server, too.
>
>
>
> You might have problems with DNS name resolution or your
>
> box patiently trying to establish an IPv6 connection when
>
> your internet connection is IPv4 only.
>
>
>
> But switching to git, like Neil said, does make things faster.
>
>
>
> FWIW, my config file reads like this:
>
>
>
> # cat /etc/portage/repos.conf/gentoo.conf
>
> [DEFAULT]
>
> main-repo = gentoo
>
>
> [gentoo]
>
> location = /var/db/repos/gentoo
>
> sync-type = git
>
> sync-uri = https://github.com/gentoo-mirror/gentoo.git
>
> auto-sync = yes
>
> sync-git-verify-commit-signature = yes
>
> sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
>
>
>
> good luck,
>
> s.
>
>
> It seems like a time-out problem.  Or maybe a memory problem ... In any
> case, it doesn't seem like it ought to be difficult to at least know
> what the problem is.
>
>
> Or?
>
>
>
>
>
>

-- 
Lee 

Re: [gentoo-user] --sync

[Stefan Schmiedl]

Sonntag, 31. Juli 2022 21:51:
 
> I've been running gentoo for years now, and every time I go to --sync,
> it's really a painful process.

> The process can take *very* [long] before you find out if it succeeded or not.
...

> It can take several hours before it finally works
 
Use a tool like atop to get some info about the throughput
of your network connection. Something like "ss -ntp" might
show interesting info about the state of the connection 
between your machine and the server, too.
 
You might have problems with DNS name resolution or your
box patiently trying to establish an IPv6 connection when
your internet connection is IPv4 only.
 
But switching to git, like Neil said, does make things faster.
 
FWIW, my config file reads like this:
 
# cat /etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo

[gentoo]
location = /var/db/repos/gentoo
sync-type = git
sync-uri = https://github.com/gentoo-mirror/gentoo.git
auto-sync = yes
sync-git-verify-commit-signature = yes
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
 
good luck,
s.

> It seems like a time-out problem.  Or maybe a memory problem ... In any
> case, it doesn't seem like it ought to be difficult to at least know
> what the problem is.

> Or?

Re: [gentoo-user] --sync

[Neil Bothwick]

On Sun, 31 Jul 2022 21:51:05 +0200, n952162 wrote:

> I've been running gentoo for years now, and every time I go to --sync,
> it's really a painful process.
> 
> The process can take *very* before you find out if it succeeded or not.
> 
> I try different repos.conf servers - one works for a while, then
> doesn't, then later, the new one doesn't work anymore and the old one
> works again.

I switched to using git for syncing, from github, and haven't looked
back. It is *much* faster, several times faster syncing from github than
using rsync to sync from a local mirror, and github is always there.

% cat /etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo

[gentoo]
priority = 20
location = /var/portage
sync-type = git
sync-uri = https://github.com/gentoo-mirror/gentoo
auto-sync = yes


-- 
Neil Bothwick

Cereal Killer Strikes Again! Cap'n Crunch found dead...


pgpkry4rD9z7y.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] --sync

[Dale]

n952162 wrote:
> I've been running gentoo for years now, and every time I go to --sync,
> it's really a painful process.
>
> The process can take *very* before you find out if it succeeded or not.
>
> I try different repos.conf servers - one works for a while, then
> doesn't, then later, the new one doesn't work anymore and the old one
> works again.
>
> I've asked here about it multiple times and get the answers
>
> - "I don't have a problem"
>
> - "just change the server"
>
> - "keep trying"
>
> It can take several hours before it finally works
>
> It seems like a time-out problem.  Or maybe a memory problem ... In any
> case, it doesn't seem like it ought to be difficult to at least know
> what the problem is.
>
> Or?
>
>
>

This wiki page and mirrorselect may help.

https://wiki.gentoo.org/wiki/Mirrorselect

I think this is the command I use to get the best server to sync with. 
You may want to make a backup of make.conf first, just in case.

mirrorselect -D -s4

One of those should help some unless you have a internet connection
problem.  If you have problems with multiple servers, it could be a
connection problem and you may figure that out.  It tests by downloading
a file.  If it fails on most or all servers, connection problem.  If it
works on most, just a bad server(s) most likely. 

Hope that helps.

Dale

:-)  :-) 

Re: [gentoo-user] --sync

[Jack]

On 7/31/22 15:51, n952162 wrote:

I've been running gentoo for years now, and every time I go to --sync,
it's really a painful process.

The process can take *very* before you find out if it succeeded or not.

I try different repos.conf servers - one works for a while, then
doesn't, then later, the new one doesn't work anymore and the old one
works again.

I've asked here about it multiple times and get the answers

- "I don't have a problem"

- "just change the server"

- "keep trying"

It can take several hours before it finally works

It seems like a time-out problem.  Or maybe a memory problem ... In any
case, it doesn't seem like it ought to be difficult to at least know
what the problem is.

Or?


Well, since "it works for me" I can only suggest some things to think of 
and to try.  While a memory problem is possible, if it is timing out, 
I'd look at a possible network problem.


First, as you talk about repos.conf, is your issue with the main portage 
repo or some overlay?  Second, for the problem (or just pick one if it 
happens with several) server, can you ping that server without 
problems?  Third (maybe should have been first) what is your sync method 
and what is GENTOO_MIRRORS in your make.conf?  Related to that last one, 
have you run mirrorselect recently?


No solution, I know, but maybe something to trigger a useful thought.

[gentoo-user] --sync

[n952162]

I've been running gentoo for years now, and every time I go to --sync,
it's really a painful process.

The process can take *very* before you find out if it succeeded or not.

I try different repos.conf servers - one works for a while, then
doesn't, then later, the new one doesn't work anymore and the old one
works again.

I've asked here about it multiple times and get the answers

- "I don't have a problem"

- "just change the server"

- "keep trying"

It can take several hours before it finally works

It seems like a time-out problem.  Or maybe a memory problem ... In any
case, it doesn't seem like it ought to be difficult to at least know
what the problem is.

Or?

Re: [gentoo-user] sync-type: rsync vs git

[Wol]

On 27/04/2022 16:18, Rich Freeman wrote:

On Wed, Apr 27, 2022 at 10:22 AM Grant Edwards
  wrote:

Is there any advantage (either to me or the Gentoo community) to
continue to use rsync and the rsync pool instead of switching the
rest of my machines to git?

I've been very impressed with the reliability and speed of sync
operations using git they never take more than a few seconds.

With git you might need to occasionally wipe your repository to delete
history if you don't want it to accumulate (I don't think there is a
way to do that automatically but if you can tell git to drop history
let me know).


Look into "git pack". It won't get rid of old versions, but I think it 
compresses all the old stuff. But once the repository has been packed, I 
gather it's normal for the old packed stuff to take up less space than 
the current stuff.


Cheers,
Wol

Re: [gentoo-user] sync-type: rsync vs git

[Rich Freeman]

On Wed, Apr 27, 2022 at 10:22 AM Grant Edwards
 wrote:
>
> Is there any advantage (either to me or the Gentoo community) to
> continue to use rsync and the rsync pool instead of switching the
> rest of my machines to git?
>
> I've been very impressed with the reliability and speed of sync
> operations using git they never take more than a few seconds.

With git you might need to occasionally wipe your repository to delete
history if you don't want it to accumulate (I don't think there is a
way to do that automatically but if you can tell git to drop history
let me know).

Of course that history can come in handy if you need to revert something/etc.

If you sync infrequently - say once a month or less frequently, then
I'd expect rsync to be faster.  This is because git has to fetch every
single set of changes since the last sync, while rsync just compares
everything at a file level.  Over a long period of time that means
that if a package was revised 4 times and old versions were pruned 4
times, then you end up fetching and ignoring 2-3 versions of the
package that would just never be fetched at all with rsync.  That can
add up if it has been a long time.

On the other hand, if you sync frequently (especially daily or more
often), then git is FAR less expensive in both IO and CPU on both your
side and on the server side.  Your git client and the server just
communicate what revision they're at, the server can see all the
versions you're missing, and send the history in-between.  Then your
client can see what objects it is missing that it wants and fetch
them.  Since it is all de-duped by its design anything that hasn't
changed or which the repo has already seen will not need to be
transferred.  With rsync you need to scan the entire filesystem
metadata at least on both ends to figure out what has changed, and if
your metadata isn't trustworthy you need to hash all the file contents
(which isn't done by default).  Since git is content-hashed you
basically get more data integrity than the default level for rsync and
the only thing that needs to be read is the git metadata, which is
packed efficiently.

Bottom line is that I think git just makes more sense these days for
the typical gentoo user, who is far more likely to be interested in
things like changelogs and commit histories than users of other
distros.  I'm not saying it is always the best choice for everybody,
but you should consider it and improve your git-fu if you need to.
Oh, and if you want the equivalent of an old changelog, just go into a
directory and run "git whatchanged ."

-- 
Rich

[gentoo-user] sync-type: rsync vs git

[Grant Edwards]

A while back I switched one of my machines sync-type for the gentoo
repo from rsync to git using https://anongit.gentoo.org/git/repo/sync/gentoo.git
because that machine is behind a firewall that stopped allowing rsync
connections.

Is there any advantage (either to me or the Gentoo community) to
continue to use rsync and the rsync pool instead of switching the
rest of my machines to git?

I've been very impressed with the reliability and speed of sync
operations using git they never take more than a few seconds. When
using rsync, it seems like I regularly used to have to spend time
trying different mirrors and hard-wiring one in my config file because
the one I (or the pool) had chosen had fallen back to using a Bell-212
modem for its internet connection. Sync operations often used to take
many minutes and would sometimes just hang.

-- 
Grant

Re: [gentoo-user] sync fails : ERROR:root:OpenPGP verification failed

[Helmut Jarausch]

On 02/02/2018 11:38:54 AM, Floyd Anderson wrote:

On Fri, 02 Feb 2018 11:11:38 +0100
Helmut Jarausch  wrote:

Hi,

I cannot run emerge --sync
I always get


ERROR:root:OpenPGP verification failed:
gpg: Signature made Fri 02 Feb 2018 09:38:18 AM UTC
gpg:using RSA key
E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: Can't check signature: No public key


What might have been happened?



Have a look at: 




Many thanks Floyd!

I've reemerged portage- which fixed it.
Helmut

Re: [gentoo-user] sync fails : ERROR:root:OpenPGP verification failed

[Luigi Mantellini]

See https://bugs.gentoo.org/645194

should be solved by last portage (maybe).

ciao

luigi

On Fri, Feb 2, 2018 at 11:13 AM, Luigi Mantellini <
luigi.mantellini...@gmail.com> wrote:

> I think a trouble with ipv6.
> For now I disabled at all the portage tree verification adding
> "sync-rsync-verify-metamanifest = no" to repos.conf
>
> ciao
>
> luigi
>
> On Fri, Feb 2, 2018 at 11:11 AM, Helmut Jarausch 
> wrote:
>
>> Hi,
>>
>> I cannot run emerge --sync
>> I always get
>>
>>
>> ERROR:root:OpenPGP verification failed:
>> gpg: Signature made Fri 02 Feb 2018 09:38:18 AM UTC
>> gpg:using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590E
>> EAC9189250
>> gpg: Can't check signature: No public key
>>
>>
>> What might have been happened?
>>
>> Many thanks for a hint,
>> Helmut
>>
>
>
>
> --
> Luigi 'Comio' Mantellini
> R - Software
> Industrie Dial Face S.p.A.
> Via Canzo, 4
> 20068 Peschiera Borromeo (MI), Italy
>
> Tel.: +39 02 5167 2813 <+39%2002%205167%202813>
> Fax: +39 02 5167 2459 <+39%2002%205167%202459>
> web: www.idf-hit.com
> mail: luigi.mantell...@idf-hit.com
>



-- 
Luigi 'Comio' Mantellini
R - Software
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI), Italy

Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
web: www.idf-hit.com
mail: luigi.mantell...@idf-hit.com

Re: [gentoo-user] sync fails : ERROR:root:OpenPGP verification failed

[Floyd Anderson]

On Fri, 02 Feb 2018 11:11:38 +0100
Helmut Jarausch  wrote:

Hi,

I cannot run emerge --sync
I always get


ERROR:root:OpenPGP verification failed:
gpg: Signature made Fri 02 Feb 2018 09:38:18 AM UTC
gpg:using RSA key 
E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250

gpg: Can't check signature: No public key


What might have been happened?



Have a look at: 


--
Regards,
floyd

Re: [gentoo-user] sync fails : ERROR:root:OpenPGP verification failed

[Luigi Mantellini]

I think a trouble with ipv6.
For now I disabled at all the portage tree verification adding
"sync-rsync-verify-metamanifest = no" to repos.conf

ciao

luigi

On Fri, Feb 2, 2018 at 11:11 AM, Helmut Jarausch  wrote:

> Hi,
>
> I cannot run emerge --sync
> I always get
>
>
> ERROR:root:OpenPGP verification failed:
> gpg: Signature made Fri 02 Feb 2018 09:38:18 AM UTC
> gpg:using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
> gpg: Can't check signature: No public key
>
>
> What might have been happened?
>
> Many thanks for a hint,
> Helmut
>



-- 
Luigi 'Comio' Mantellini
R - Software
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI), Italy

Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
web: www.idf-hit.com
mail: luigi.mantell...@idf-hit.com

[gentoo-user] sync fails : ERROR:root:OpenPGP verification failed

[Helmut Jarausch]

Hi,

I cannot run emerge --sync
I always get


ERROR:root:OpenPGP verification failed:
gpg: Signature made Fri 02 Feb 2018 09:38:18 AM UTC
gpg:using RSA key  
E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250

gpg: Can't check signature: No public key


What might have been happened?

Many thanks for a hint,
Helmut

[gentoo-user] Re: [gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.

[the guard]

Среда, 27 марта 2013, 18:09 UTC от Alan Mackenzie a...@muc.de:
Hi, Gentoo!

Has anybody else seen this?  I did a sync, then emerge -puND world and
got a list of ~100 packages to merge.  About a third of them seem to be
new perl stuff, 13 packages with gnome, and a lot of this and that.

Most worrying is sys-fs/udisks-2.1.0.  Should I be worried about this
(all my other udev-ish stuff is up to date), or will it just work?

But getting such a large update, all at once, seems worrying.  Should I
worry about anything, or just plough ahead with the update?

-- 
Alan Mackenzie (Nuremberg, Germany).

depends on how long it's been since you had the last uodate

Re: [gentoo-user] Re: [gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.

[Alan Mackenzie]

On Thu, Mar 28, 2013 at 01:48:21PM +0400, the guard wrote:



 Среда, 27 марта 2013, 18:09 UTC от Alan Mackenzie a...@muc.de:
 Hi, Gentoo!

 Has anybody else seen this?  I did a sync, then emerge -puND world and
 got a list of ~100 packages to merge.  About a third of them seem to be
 new perl stuff, 13 packages with gnome, and a lot of this and that.

 Most worrying is sys-fs/udisks-2.1.0.  Should I be worried about this
 (all my other udev-ish stuff is up to date), or will it just work?

 But getting such a large update, all at once, seems worrying.  Should I
 worry about anything, or just plough ahead with the update?

 -- 
 Alan Mackenzie (Nuremberg, Germany).

 depends on how long it's been since you had the last uodate

A couple of days at most.  I've never seen such a large update, except
for when I'd just installed Gentoo.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: [gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.

[Mateusz Kowalczyk]

On 28/03/13 11:52, Alan Mackenzie wrote:
 On Thu, Mar 28, 2013 at 01:48:21PM +0400, the guard wrote:
 
 
 
 Среда, 27 марта 2013, 18:09 UTC от Alan Mackenzie a...@muc.de:
 Hi, Gentoo!
 
 Has anybody else seen this?  I did a sync, then emerge -puND world and
 got a list of ~100 packages to merge.  About a third of them seem to be
 new perl stuff, 13 packages with gnome, and a lot of this and that.
 
 Most worrying is sys-fs/udisks-2.1.0.  Should I be worried about this
 (all my other udev-ish stuff is up to date), or will it just work?
 
 But getting such a large update, all at once, seems worrying.  Should I
 worry about anything, or just plough ahead with the update?
 
 -- 
 Alan Mackenzie (Nuremberg, Germany).
 
 depends on how long it's been since you had the last uodate
 
 A couple of days at most.  I've never seen such a large update, except
 for when I'd just installed Gentoo.
 
I recently had ‘emerge -avutND’ throw 713 packages at me after not
updating for a couple of weeks. It took me a few days to get it back to
an updated state but I managed.

~100 packages is not unusual if you don't update for a week or so,
especially if something gets an update that other things depend on at
which point it might remerge all those packages as well.

I wouldn't worry.

-- 
Mateusz K.

[gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.

[Alan Mackenzie]

Hi, Gentoo!

Has anybody else seen this?  I did a sync, then emerge -puND world and
got a list of ~100 packages to merge.  About a third of them seem to be
new perl stuff, 13 packages with gnome, and a lot of this and that.

Most worrying is sys-fs/udisks-2.1.0.  Should I be worried about this
(all my other udev-ish stuff is up to date), or will it just work?

But getting such a large update, all at once, seems worrying.  Should I
worry about anything, or just plough ahead with the update?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.

[Paul Hartman]

On Wed, Mar 27, 2013 at 1:09 PM, Alan Mackenzie a...@muc.de wrote:
 Hi, Gentoo!

 Has anybody else seen this?  I did a sync, then emerge -puND world and
 got a list of ~100 packages to merge.  About a third of them seem to be
 new perl stuff, 13 packages with gnome, and a lot of this and that.

 Most worrying is sys-fs/udisks-2.1.0.  Should I be worried about this
 (all my other udev-ish stuff is up to date), or will it just work?

 But getting such a large update, all at once, seems worrying.  Should I
 worry about anything, or just plough ahead with the update?

You must not be a KDE user. Hundreds of upgraded packages at once is a
monthly routine... :)

I wouldn't worry about it. Sometimes if I have a really large list of
packages, I will upgrade @system first and then upgrade @world second,
but there's no real scientific reason to do so, just my own good
feelings...

Re: [gentoo-user] Sync and glsa-check from cron

[Alan McKinnon]

On Wednesday 20 June 2007, Nick wrote:
 Hi there,

 I'm planning to set my mother up with a very simple gentoo box, with
 only what she needs etc.

 Ideally it should require almost no interaction from me, and just
 keep itself working and secure.

 So, I'm planning to run sudo emerge --sync and sudo glsa-check -f
 new from a cron job, perhaps once a week.

 I can set up the sudoers part all fine, but is there anything I
 should watch out for / consider when running these maintenance tools
 from a cron job?

Why bother with sudo and /etc/sudoers? That's just an extra layer of 
unnecessary complexity. The usual assortment of cron daemons can all 
run commands as root. Write a script to run the commands you want, copy 
it to /etc/cron.d/weekly. It will run at 4:22 am every Sunday.

Log in as root, crontab -e also works. As does sudo crontab -e

You'll have to be aware of the usuaal limitations of cron jobs - they do 
not run under bash, and they seldom have the same environment variables 
set as what a r\egular user gets. So always include full paths to any 
command you run

alan


-- 
Optimists say the glass is half full,
Pessimists say the glass is half empty,
Developers say wtf is the glass twice as big as it needs to be?

Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Sync and glsa-check from cron

[Nick]

On Wed, Jun 20, 2007 at 09:50:04AM +0200, Alan McKinnon wrote:
 On Wednesday 20 June 2007, Nick wrote:
 
  So, I'm planning to run sudo emerge --sync and sudo glsa-check -f
  new from a cron job, perhaps once a week.
 
  I can set up the sudoers part all fine, but is there anything I
  should watch out for / consider when running these maintenance tools
  from a cron job?
 
 Why bother with sudo and /etc/sudoers? That's just an extra layer of 
 unnecessary complexity. The usual assortment of cron daemons can all 
 run commands as root. Write a script to run the commands you want, copy 
 it to /etc/cron.d/weekly. It will run at 4:22 am every Sunday.

Sounds good, I'll do that. For some reason I was under the
impression that root couldn't have its own crontab. Clearly I was
mistaken (just as well, that wouldn't make much sense...)

 You'll have to be aware of the usuaal limitations of cron jobs - they do 
 not run under bash, and they seldom have the same environment variables 
 set as what a r\egular user gets. So always include full paths to any 
 command you run

I'll probably be back here if I some variable reassignments or
whatever cause things to get confused, but it doesn't sound likely.

Thanks guys,

-Nick

-- 
GPG Key : www.njw.me.uk/nick.gpg.asc GPG Key ID: 04E4653F
  GPG Fingerprint: 9732 D7C7 A441 D79E FDF0 94F6 1F48 5674 04E4 653F


pgpTArsCht9nD.pgp
Description: PGP signature

[gentoo-user] Sync and glsa-check from cron

[Nick]

Hi there,

I'm planning to set my mother up with a very simple gentoo box, with
only what she needs etc.

Ideally it should require almost no interaction from me, and just
keep itself working and secure.

So, I'm planning to run sudo emerge --sync and sudo glsa-check -f
new from a cron job, perhaps once a week.

I can set up the sudoers part all fine, but is there anything I
should watch out for / consider when running these maintenance tools
from a cron job?

Thanks,

-Nick

-- 
GPG Key : www.njw.me.uk/nick.gpg.asc GPG Key ID: 04E4653F
  GPG Fingerprint: 9732 D7C7 A441 D79E FDF0 94F6 1F48 5674 04E4 653F


pgpEUC64gubsG.pgp
Description: PGP signature

Re: [gentoo-user] Sync and glsa-check from cron

[Joshua Doll]

Nick wrote:

Hi there,

I'm planning to set my mother up with a very simple gentoo box, with
only what she needs etc.

Ideally it should require almost no interaction from me, and just
keep itself working and secure.

So, I'm planning to run sudo emerge --sync and sudo glsa-check -f
new from a cron job, perhaps once a week.

I can set up the sudoers part all fine, but is there anything I
should watch out for / consider when running these maintenance tools
from a cron job?

Thanks,

-Nick

  

I think cron can run jobs as root.

--Joshua Doll
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Sync and glsa-check from cron

[Boyd Stephen Smith Jr.]

On Tuesday 19 June 2007 17:18:45 Nick wrote:
 So, I'm planning to run sudo emerge --sync and sudo glsa-check -f
 new from a cron job, perhaps once a week.

 I can set up the sudoers part all fine, but is there anything I
 should watch out for / consider when running these maintenance tools
 from a cron job?

Not these two, they shouldn't depend significantly on your environment 
variables.  Just make sure you are in the right group to run cron jobs.

-- 
Boyd Stephen Smith Jr. ,= ,-_-. =. 
[EMAIL PROTECTED]  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy   `-'(. .)`-' 
http://iguanasuicide.org/  \_/ 


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

Re: [gentoo-user] Sync and glsa-check from cron

[Boyd Stephen Smith Jr.]

On Tuesday 19 June 2007 17:26:15 Joshua Doll wrote:
 Nick wrote:
  I can set up the sudoers part all fine, but is there anything I
  should watch out for / consider when running these maintenance tools
  from a cron job?

Oh, and I forgot to mention it in my other direct reply:  You'll probably need 
to specify the full path to those commands.  $PATH is generally different or 
unset when tasks are run from cron.

 I think cron can run jobs as root.

Yes, /etc/cron.{hourly,daily,weekly,monthly} contains scripts to be run as 
root.  Also, some (most? all?) cron daemons allow root to have a crontab 
separate from the system crontab.  If you have root access you can even 
fiddle with the system crontab, but that's not the preferred solution.

Many cron daemons also allow jobs to be run as a user by maintaining a crontab 
for each user and su-ing to the correct user (and cleaning/setting the 
environment) before running the task.  If I'm reading the question correctly, 
he will be adding these actions to his user's crontab and then sudo-ing to 
run the script.  sudo can be set up to allow users to run tasks as root 
without a password.  sudo also cleans the environment by default, but that 
can be turned off or made less strict.

However, tasks run by cron (either as root or as another user) will have 
different environment variables set.  e.g. /etc/profile and $HOME/.profile 
are not sourced in the shell (generally cron jobs aren't run in a shell at 
all).  They will also generally not have a tty associated with them.  Again, 
if I'm reading the OP correctly, (s)he was wondering if those changes will 
affect those two commands.  Some commands / scripts are quite sensitive to 
the environment and may give different results (or not work at all) when run 
from a cron job.

-- 
Boyd Stephen Smith Jr. ,= ,-_-. =. 
[EMAIL PROTECTED]  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy   `-'(. .)`-' 
http://iguanasuicide.org/  \_/ 


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

[gentoo-user] Sync only installed and dependence packages with portage.

[Qian Qiao]

Hi,

As the title suggested, I've got a box with very limited disk space,
is it possible to sync only the packages currently installed and their
dependencies with the portage tree and leave out the rest?

TIA.

-- Joe

-- 
Money can't buy everything.
Sometimes money can't even buy a gun...

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Sync only installed and dependence packages with portage.

[Holly Bostick]

Qian Qiao schreef:
 Hi,
 
 As the title suggested, I've got a box with very limited disk space,
 is it possible to sync only the packages currently installed and their
 dependencies with the portage tree and leave out the rest?
 
 TIA.
 
 -- Joe
 

Hi,

I don't think so, but I don't think it makes such a huge amount of
difference. When you sync the Portage tree, you are only adding and
deleting ebuilds, which are very small.

On my system, 98,135 files in the Portage tree take up 296.5 MB-- which
is actually more than I expected; have to look into that. Oh... I did a
couple of qpkgs when I was unmerging that extra version of Python.
Without counting /usr/portage/packages, 97,919 files take up 93.5MB of
space, which is more like what I would have figured.

IMHO, if you don't even have that much room available, it's time to
start clearing out space, repartitioning, or considering getting a new
HDD anyway.

However, this is without counting /usr/portage/distfiles, which holds
the tarballs... if you don't mind re-downloading them if you decide to
reinstall a program previously installed (or installed, then
uninstalled), a more effective space-saving measure might be to delete
the contents of that folder, as well as backing any packages you may
have used qpkg to create off the drive. IIrc, there's a setting in
/etc/make.conf that will allow you to dump the tarballs automatically,
but you could always do so as a cron job.

HTH,
Holly
-- 
gentoo-user@gentoo.org mailing list