[gentoo-amd64] backups and world updates

[gentoo-amd64] backups and world updates

[Mark]

Thanks to everyone who helped me get my system back after a couple of
world update snafus. Now of course I'm a little gun-shy about using
options like emerge --update world. So what's my best bet to keep my
system up to date, while protecting it from my own lack of
understanding of updating config files?

Here's what I'm intending to do so far:

1. Prior to running any large system update, back up /etc to another location
2. use dispatch-conf instead of etc-update

Can anyone make any other suggestions? Which emerge options are best
for full system updates? Thanks
-- 
Mark
[unwieldy legal disclaimer would go here - feel free to type your own]

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] backups and world updates

[Brett Johnson]

Mark wrote:
> Thanks to everyone who helped me get my system back after a couple of
> world update snafus. Now of course I'm a little gun-shy about using
> options like emerge --update world. So what's my best bet to keep my
> system up to date, while protecting it from my own lack of
> understanding of updating config files?
> 
> Here's what I'm intending to do so far:
> 
> 1. Prior to running any large system update, back up /etc to another location
> 2. use dispatch-conf instead of etc-update
> 
> Can anyone make any other suggestions? Which emerge options are best
> for full system updates? Thanks

I would suggest doing updates on a very regular basis. I saw a script in
the gentoo forums once, where the script ran every night and updated the
portage tree, downloaded and built all the new packages (but not install
them) and emailed the list of packages to be installed. I have not
gotten that ambitious yet, I just update my portage tree every night,
and try run an "emerge -puvD world" once a week on all my systems to see
what needs to be updated. If you stay on top of updates, they are much
easier to handle. (I know this because I have neglected my laptop for
about 6 months now, and now I have been stuck updating it for the past 2
days....)

I have also found that using dispatch-conf with rcs and colordiff helps
a lot too. http://gentoo-wiki.com/TIP_Colorized_Config_Management shows
how to colorize the diff for etc-update and dispatch.conf.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] emerge of neverwinter nights fails

[Mark Creamer]

thought i'd try playing neverwinter nights, but the emerge is failing. 
It downloads OK, but then has a md5 error. When I try again, I get:


spitfire mark # emerge nwn
Calculating dependencies ...done!
 >>> emerge (1 of 1) games-rpg/nwn-1.65-r1 to /
 >>> md5 files   ;-) nwn-1.65-r1.ebuild
 >>> md5 files   ;-) files/nwn
 >>> md5 files   ;-) files/nwn-1.65-fixinstall
 >>> md5 files   ;-) files/digest-nwn-1.65-r1
 >>> md5 files   ;-) files/nwn.png

!!! Digest verification Failed:
!!!    /usr/portage/distfiles/nwclient129.tar.gz
!!! Reason: Failed on MD5 verification

Anybody seen this issue with nwn?
Thanks
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[shimi]

On Sunday 31 July 2005 06:48, Mark Creamer wrote:
> thought i'd try playing neverwinter nights, but the emerge is failing.
> It downloads OK, but then has a md5 error. When I try again, I get:
>
>
> spitfire mark # emerge nwn
> Calculating dependencies ...done!
>
>  >>> emerge (1 of 1) games-rpg/nwn-1.65-r1 to /
>  >>> md5 files   ;-) nwn-1.65-r1.ebuild
>  >>> md5 files   ;-) files/nwn
>  >>> md5 files   ;-) files/nwn-1.65-fixinstall
>  >>> md5 files   ;-) files/digest-nwn-1.65-r1
>  >>> md5 files   ;-) files/nwn.png
>
> !!! Digest verification Failed:
> !!!    /usr/portage/distfiles/nwclient129.tar.gz
> !!! Reason: Failed on MD5 verification
>
> Anybody seen this issue with nwn?
> Thanks

Two options: download failed, or archive does not meet signature in portage. 
delete the offending file and try to download again, if it still happens, 
it's probably a bad signature in portage (or a man-in-the-middle attack on 
you or the server you're downloading from). Usually it's the bad signature 
thing. an emerge sync tends to fix this. If not, file a bug report...

-- 
Shimi
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[Michal Žeravík]

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

shimi wrote:

>On Sunday 31 July 2005 06:48, Mark Creamer wrote:
>  
>
>>thought i'd try playing neverwinter nights, but the emerge is failing.
>>It downloads OK, but then has a md5 error. When I try again, I get:
>>
>>
>>spitfire mark # emerge nwn
>>Calculating dependencies ...done!
>>
>> >>> emerge (1 of 1) games-rpg/nwn-1.65-r1 to /
>> >>> md5 files   ;-) nwn-1.65-r1.ebuild
>> >>> md5 files   ;-) files/nwn
>> >>> md5 files   ;-) files/nwn-1.65-fixinstall
>> >>> md5 files   ;-) files/digest-nwn-1.65-r1
>> >>> md5 files   ;-) files/nwn.png
>>
>>!!! Digest verification Failed:
>>!!!    /usr/portage/distfiles/nwclient129.tar.gz
>>!!! Reason: Failed on MD5 verification
>>
>>Anybody seen this issue with nwn?
>>Thanks
>>    
>>
>
>Two options: download failed, or archive does not meet signature in portage. 
>delete the offending file and try to download again, if it still happens, 
>it's probably a bad signature in portage (or a man-in-the-middle attack on 
>you or the server you're downloading from). Usually it's the bad signature 
>thing. an emerge sync tends to fix this. If not, file a bug report...
>
>  
>
or run ebuild `equery w =games-rpg/nwn-1.65-r1` digest
and emerge again

michal

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

Re: [gentoo-amd64] emerge of neverwinter nights fails

[Peter Humphrey]

Michal Žeravík wrote:

> or run ebuild `equery w =games-rpg/nwn-1.65-r1` digest
 > and emerge again

Good idea, but here it causes:

Calculating dependencies  ...done!
 >>> emerge (1 of 1) games-rpg/nwn-1.65-r1 to /
 >>> md5 files   ;-) nwn-1.65-r1.ebuild
 >>> md5 files   ;-) files/nwn
 >>> md5 files   ;-) files/nwn-1.65-fixinstall
 >>> md5 files   ;-) files/digest-nwn-1.65-r1
 >>> md5 files   ;-) files/nwn.png
 >>> md5 src_uri ;-) nwclient129.tar.gz
 >>> md5 src_uri ;-) linuxclientupdate1xxto165eng.tar.gz
 >>> md5 src_uri ;-) NWNEnglish1.65dialog.zip
 >>> Unpacking source...
 >>> Unpacking nwclient129.tar.gz to /var/tmp/portage/nwn-1.65-r1/work/nwn
tar: Skipping to next header

gzip: stdin: invalid compressed data--format violated


So I guess the problem is in the package, not the digest. Time for a bug 
report...

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[phil]

On Sun, 2005-07-31 at 10:51 +0100, Peter Humphrey wrote:
> Michal Žeravík wrote:
> 
> > or run ebuild `equery w =games-rpg/nwn-1.65-r1` digest
>  > and emerge again
> 
> Good idea, but here it causes:
> 
> Calculating dependencies  ...done!
>  >>> emerge (1 of 1) games-rpg/nwn-1.65-r1 to /
>  >>> md5 files   ;-) nwn-1.65-r1.ebuild
>  >>> md5 files   ;-) files/nwn
>  >>> md5 files   ;-) files/nwn-1.65-fixinstall
>  >>> md5 files   ;-) files/digest-nwn-1.65-r1
>  >>> md5 files   ;-) files/nwn.png
>  >>> md5 src_uri ;-) nwclient129.tar.gz
>  >>> md5 src_uri ;-) linuxclientupdate1xxto165eng.tar.gz
>  >>> md5 src_uri ;-) NWNEnglish1.65dialog.zip
>  >>> Unpacking source...
>  >>> Unpacking nwclient129.tar.gz to /var/tmp/portage/nwn-1.65-r1/work/nwn
> tar: Skipping to next header
> 
> gzip: stdin: invalid compressed data--format violated
> 
> 
> So I guess the problem is in the package, not the digest. Time for a bug 
> report...
> 
> -- 
> Rgds
> Peter Humphrey
> Linux Counter 5290, Aug 93.
> 
> 
Had the same problem as you and thought id try the package from
somewhere else , nwclient129.tar.gz is fine from fileshack so must be
something wrong with the bioware server.
oh and when you install follow the emerge instructions but also as root
touch /etc/env.d/91nwn
echo LDPATH=opt/nwn/miles > /etc/env.d/91nwn
env-update

Happy Gaming :)

P.Marples


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[Michal Žeravík]

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

Very strange, because I'm running =games-rpg/nwn-1.65-r1
without any problem on amd64.
Try to delete distfile (probably nwclient129.tar.gz)
and emerge again.

michalz


phil wrote:

>On Sun, 2005-07-31 at 10:51 +0100, Peter Humphrey wrote:
>  
>
>>Michal Žeravík wrote:
>>
>>    
>>
>>>or run ebuild `equery w =games-rpg/nwn-1.65-r1` digest
>>>      
>>>
>> > and emerge again
>>
>>Good idea, but here it causes:
>>
>>Calculating dependencies  ...done!
>> >>> emerge (1 of 1) games-rpg/nwn-1.65-r1 to /
>> >>> md5 files   ;-) nwn-1.65-r1.ebuild
>> >>> md5 files   ;-) files/nwn
>> >>> md5 files   ;-) files/nwn-1.65-fixinstall
>> >>> md5 files   ;-) files/digest-nwn-1.65-r1
>> >>> md5 files   ;-) files/nwn.png
>> >>> md5 src_uri ;-) nwclient129.tar.gz
>> >>> md5 src_uri ;-) linuxclientupdate1xxto165eng.tar.gz
>> >>> md5 src_uri ;-) NWNEnglish1.65dialog.zip
>> >>> Unpacking source...
>> >>> Unpacking nwclient129.tar.gz to /var/tmp/portage/nwn-1.65-r1/work/nwn
>>tar: Skipping to next header
>>
>>gzip: stdin: invalid compressed data--format violated
>>
>>
>>So I guess the problem is in the package, not the digest. Time for a bug 
>>report...
>>
>>-- 
>>Rgds
>>Peter Humphrey
>>Linux Counter 5290, Aug 93.
>>
>>
>>    
>>
>Had the same problem as you and thought id try the package from
>somewhere else , nwclient129.tar.gz is fine from fileshack so must be
>something wrong with the bioware server.
>oh and when you install follow the emerge instructions but also as root
>touch /etc/env.d/91nwn
>echo LDPATH=opt/nwn/miles > /etc/env.d/91nwn
>env-update
>
>Happy Gaming :)
>
>P.Marples
>
>
>  
>


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

Re: [gentoo-amd64] emerge of neverwinter nights fails

[Mark Creamer]

Michal Žeravík wrote:

> Very strange, because I'm running =games-rpg/nwn-1.65-r1
> without any problem on amd64.
> Try to delete distfile (probably nwclient129.tar.gz)
> and emerge again.
>
> michalz
>
>
> phil wrote:
>
>>On Sun, 2005-07-31 at 10:51 +0100, Peter Humphrey wrote:
>>  
>>
>>>Michal Žeravík wrote:
>>>
>>>    
>>>
>>>>or run ebuild `equery w =games-rpg/nwn-1.65-r1` digest
>>>>      
>>>>
>>> > and emerge again
>>>
>>>Good idea, but here it causes:
>>>
>>>Calculating dependencies  ...done!
>>> >>> emerge (1 of 1) games-rpg/nwn-1.65-r1 to /
>>> >>> md5 files   ;-) nwn-1.65-r1.ebuild
>>> >>> md5 files   ;-) files/nwn
>>> >>> md5 files   ;-) files/nwn-1.65-fixinstall
>>> >>> md5 files   ;-) files/digest-nwn-1.65-r1
>>> >>> md5 files   ;-) files/nwn.png
>>> >>> md5 src_uri ;-) nwclient129.tar.gz
>>> >>> md5 src_uri ;-) linuxclientupdate1xxto165eng.tar.gz
>>> >>> md5 src_uri ;-) NWNEnglish1.65dialog.zip
>>> >>> Unpacking source...
>>> >>> Unpacking nwclient129.tar.gz to /var/tmp/portage/nwn-1.65-r1/work/nwn
>>>tar: Skipping to next header
>>>
>>>gzip: stdin: invalid compressed data--format violated
>>>
>>>
>>>So I guess the problem is in the package, not the digest. Time for a bug 
>>>report...
>>>
>>>-- 
>>>Rgds
>>>Peter Humphrey
>>>Linux Counter 5290, Aug 93.
>>>
>>>
>>>    
>>>
>>Had the same problem as you and thought id try the package from
>>somewhere else , nwclient129.tar.gz is fine from fileshack so must be
>>something wrong with the bioware server.
>>oh and when you install follow the emerge instructions but also as root
>>touch /etc/env.d/91nwn
>>echo LDPATH=opt/nwn/miles > /etc/env.d/91nwn
>>env-update
>>
>>Happy Gaming :)
>>
>>P.Marples
>>
>>
>>  
>>
>
I was able to get the installation complete with Phil's suggestion of 
getting the file from another source. One question though, at the end, 
there are a few steps to complete. The first one says:

Copy the following directories/files from your installed and
* patched (1.65) Neverwinter Nights to /opt/nwn:

What exactly is the "installed and patched" directory it's referring to?
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[Chuck Milam]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> What exactly is the "installed and patched" directory it's referring to?

I believe this means the installed and patched (updated via the game
update/patch function) files from a Windows install of NWN.

- ---
Chuck Milam
chuck@milams.net
http://chuck.milams.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC7kbulh+fpI+PkrcRArhiAKCU32Ad+O+Yaa8ntEAL1NIaahSwGgCaApz9
2dvzQHPZgGDhkDeu4WsskYs=
=pWZ2
-----END PGP SIGNATURE-----

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[Peter Humphrey]

Chuck Milam wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
>>What exactly is the "installed and patched" directory it's referring to?
> 
> 
> I believe this means the installed and patched (updated via the game
> update/patch function) files from a Windows install of NWN.

Yes; a perusal of the nwn Web site shows that you have to have bought a copy 
of the Windows program, or else you must buy a licence for it which I assume 
will cost the same. Guess who's lost interest suddenly  :-(

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[Chuck Milam]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Humphrey wrote:

> Yes; a perusal of the nwn Web site shows that you have to have bought a
> copy of the Windows program, or else you must buy a licence for it which
> I assume will cost the same. Guess who's lost interest suddenly  :-(

I'm excited to learn there is an ebuild for it and that some have
success in getting it to run under gentoo-amd64.  I'm going to try it
out later this week.  I've been booting into Windows for little NWN
breaks from the Perl scripting grind, it'll be nice to be able to stay
in Linux.

Obviously, I purchased the Windows version, I consider it $40 well
spent.  I do regret the Bioware/Atari/WoC/whoever/etc requires you to
purchase/have a Windows installation in order to run it from Linux.  I
am glad however, that they kept to their word and did release (the
original game) for Windows, MacOS, and Linux.  That alone led me to
purchase the game and register on their site as a Linux user.  I suspect
that NWN2 (in development by a different outfit) will not be
multi-platform, but alas, such is the state of the gaming market.

Those of you running NWN on gentoo-amd64:  I've got an eMachines M6809
that I run NWN on (Windows).  I suspect I'll have to get the ATI drivers
working in Linux in order to have any hope of getting the game to run
smoothly, yes?  How painful is it to get the ATI drivers installed and
working on the eMachines M68xx series of laptops?

- ---
Chuck Milam
chuck@milams.net
http://chuck.milams.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC7leSlh+fpI+PkrcRAvkLAJ4/qQPXjjB2r7+hmHVpI9jpR+87bACfTtMp
OBfWCZxQVGTI+Bs/IvfsPXE=
=JiBt
-----END PGP SIGNATURE-----

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[phil]

I have an nvidia card so my life is easy, however i did notice a lot of
ati/neverwinter threads on forum so it would be a good idea to search on
there 

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] emerge of neverwinter nights fails

[phil]

On Mon, 2005-08-01 at 17:11 +0100, Peter Humphrey wrote:
> Chuck Milam wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > 
> >>What exactly is the "installed and patched" directory it's referring to?
> > 
> > 
> > I believe this means the installed and patched (updated via the game
> > update/patch function) files from a Windows install of NWN.
> 
> Yes; a perusal of the nwn Web site shows that you have to have bought a copy 
> of the Windows program, or else you must buy a licence for it which I assume 
> will cost the same. Guess who's lost interest suddenly  :-(
> 
> -- 
> Rgds
> Peter Humphrey
> Linux Counter 5290, Aug 93.
Of course if you emerge with USE="nowin" emerge will download the
relevant files for you, 1.1Gb or so though :-( . Also you still need a
cd key for first run. I was assuming you owned a copy, searching on
amazon it is available for a very cheap £4.96 which isnt bad i suppose.


-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: emerge of neverwinter nights fails

[Duncan]

Mark Creamer posted <42EC4A20.6040002@adelphia.net>, excerpted below,  on
Sat, 30 Jul 2005 22:48:48 -0500:

> Anybody seen this issue with nwn?

No, but I see someone hijacking a thread on a totally different topic!

Next time, please start a NEW thread, rather than replying to an old one
(backups and world updates, in this case), and changing the topic.  The
"reply" /is/ still a reply, still containing the references header
pointing to its parent, so a good client will thread it under the old
thread as it should, regardless of what the subject says (altho some have
an option to break thread if the subject changes).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] backups and world updates

[Roy Wright]

Howdy,

What I do is run a nightly script that:
* cleans up tmp files
* runs revdep-rebuild
* runs emerge --sync
* runs eupdatedb
* runs update-eix
* runs a pretend emerge -uDNvp world
* runs a fetchonly emerge -uDNq --fetchonly world
* greps the ebuilds for einfo, ewarn, and eerror lines
* runs glsa-check
The output of everything is then mailed to me.
I originally got the script from the gentoo-users list
but didn't save the link (maybe scan the archives for
portage.cron or if you want I can post what I have).

Then I review the email and decide when to update.

A red flag is if the einfo mentions revdep-rebuild.
In that case I emerge that package by name allowing
dependencies, then do the revdep-rebuild, then
the emerge world.

Most of the time, I just open an konsole and do the
update.  Occasionally I'll postpone if the update looks
really large or time consuming.  For major gui components
like KDE or xorg, I'll exit KDE and emerge from the
command line over the weekend (ok, probably overly
cautious, but I was burned once).

Occasionally I'll get a blocking condition.  I really think
twice now before just unblocking via package.keywords.
I've found that waiting a day or two might result in
portage handling the unblocking.

HTH,
Roy

Mark wrote:

>Thanks to everyone who helped me get my system back after a couple of
>world update snafus. Now of course I'm a little gun-shy about using
>options like emerge --update world. So what's my best bet to keep my
>system up to date, while protecting it from my own lack of
>understanding of updating config files?
>
>Here's what I'm intending to do so far:
>
>1. Prior to running any large system update, back up /etc to another location
>2. use dispatch-conf instead of etc-update
>
>Can anyone make any other suggestions? Which emerge options are best
>for full system updates? Thanks
>  
>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] backups and world updates

[Mark]

Hi Roy, I wasn't able to find it. Can you post your version? This
sounds like the approach I'd like to take. Thanks!

On 7/28/05, Roy Wright <royw@cisco.com> wrote:
> Howdy,
> 
> What I do is run a nightly script that:
> * cleans up tmp files
> * runs revdep-rebuild
> * runs emerge --sync
> * runs eupdatedb
> * runs update-eix
> * runs a pretend emerge -uDNvp world
> * runs a fetchonly emerge -uDNq --fetchonly world
> * greps the ebuilds for einfo, ewarn, and eerror lines
> * runs glsa-check
> The output of everything is then mailed to me.
> I originally got the script from the gentoo-users list
> but didn't save the link (maybe scan the archives for
> portage.cron or if you want I can post what I have).
> 
> Then I review the email and decide when to update.
> 
> A red flag is if the einfo mentions revdep-rebuild.
> In that case I emerge that package by name allowing
> dependencies, then do the revdep-rebuild, then
> the emerge world.
> 
> Most of the time, I just open an konsole and do the
> update.  Occasionally I'll postpone if the update looks
> really large or time consuming.  For major gui components
> like KDE or xorg, I'll exit KDE and emerge from the
> command line over the weekend (ok, probably overly
> cautious, but I was burned once).
> 
> Occasionally I'll get a blocking condition.  I really think
> twice now before just unblocking via package.keywords.
> I've found that waiting a day or two might result in
> portage handling the unblocking.
> 
> HTH,
> Roy
> 
> Mark wrote:
> 
> >Thanks to everyone who helped me get my system back after a couple of
> >world update snafus. Now of course I'm a little gun-shy about using
> >options like emerge --update world. So what's my best bet to keep my
> >system up to date, while protecting it from my own lack of
> >understanding of updating config files?
> >
> >Here's what I'm intending to do so far:
> >
> >1. Prior to running any large system update, back up /etc to another location
> >2. use dispatch-conf instead of etc-update
> >
> >Can anyone make any other suggestions? Which emerge options are best
> >for full system updates? Thanks
> >
> >
> --
> gentoo-amd64@gentoo.org mailing list
> 
> 


-- 
Mark
[unwieldy legal disclaimer would go here - feel free to type your own]

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] backups and world updates

[Roy Wright]

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

Mark wrote:

>Hi Roy, I wasn't able to find it. Can you post your version? This
>sounds like the approach I'd like to take. Thanks!
>  
>
Here it is.  After reading Matt's post, looks like I need to try
dispatch-conf instead of etc-update.  Learn something new
everyday here.  ;-)

Disclaimor, these scripts are starting points.  Customization
is highly recommended.  :-)

Scripts:

/etc/cron.daily/portage.cron
/usr/local/sbin/einfo

Have fun,
Roy


[-- Attachment #2: portage.cron --]
[-- Type: text/plain, Size: 2092 bytes --]

#!/bin/sh
#
# Remove downloads older than 14 days
# Remove directories from /var/tmp/portage older than 2 days
# Remove ._mrg* files left over from dispatch-conf
# Sync the portage tree
# Update the database used by esearch
# See what would be updated and estimate how long
# Depends on cron to mail results to root
#
# Dependencies:
#	>=sys-apps/portage-2.0.51
#	>=app-portage/gentoolkit-0.2.1_pre3
#	app-portage/esearch
#	app-portage/genlop
#	app-admin/tmpwatch

#echo "Portage Tree not Updated"; exit 0

export PATH=$PATH:/usr/sbin
export NOCOLOR="true" 	# Turn off color for "emerge"

echo "Starting portage.cron at: $(date)" >> /var/log/portage.cron.log

#echo "Finding and cleaning older distfiles..."
#tmpwatch --atime --mtime --ctime --verbose 168 /usr/portage/distfiles

echo "Cleaning /var/tmp/portage..."
#tmpwatch --atime --mtime --ctime --verbose 48 --exclude /var/tmp/portage/homedir /var/tmp/portage
tmpwatch --atime --mtime --ctime 48 --exclude /var/tmp/portage/homedir /var/tmp/portage

echo "Cleaning up old merge files from dispatch-conf"
find / -xdev -name "._mrg*" -exec rm {} \;

echo "Running revdep-rebuild"
revdep-rebuild --ignore --pretend --no-color
rm -f /.revdep-rebuild.*

echo "Syncing portage tree..."
emerge --sync 2>> /var/log/portage.cron.log > /dev/null
status=$?

if [ $status -ne 0 ]; then
	echo "Portage sync failed, exiting update."
	exit $status
fi

echo "Running eupdatedb..."
eupdatedb --quiet --nocolor 2> /dev/null

echo "Running update-eix..."
update-eix --quiet

echo "Checking for updates..."
/usr/local/sbin/einfo --update --deep --newuse world
emerge --update --deep --pretend --verbose --nospinner --newuse world > /tmp/emerge.output
emerge --update --deep --fetchonly --quiet --nospinner --newuse world >> /tmp/emerge.output

echo "Estimated time for updates..."
cat /tmp/emerge.output | genlop -n --pretend
rm -f /tmp/emerge.output

echo "Checking Gentoo Linux Security Advisories (GLSA) ..."
for glsa in `glsa-check -t all 2>/dev/null | grep -v GLSA`
do
	glsa-check --pretend $glsa 2>/dev/null
	glsa-check --print $glsa 2>/dev/null
done


[-- Attachment #3: einfo --]
[-- Type: text/plain, Size: 1112 bytes --]

#!/usr/bin/perl

# this script will run emerge with the given command line options plus
# "--pretend".  It will then grep all of the packages to be merged looking
# for einfo, ewarn, and eerror lines to display.
# Thanks to Peter.Ruskin@dsl.pipex.com for the ewarn and error suggestions.

$portage = '/usr/portage';
$emerge = "emerge @ARGV --pretend";

open(EMERGE, "$emerge|") || die "unable to open $emerge\n";
while(<EMERGE>) {
	if(/\[[^\]]+\]\s+(\S+)\/(\S+)\-(\d\S*)\s/) {
		findInfo($1,$2,$3);
	}
}
close(EMERGE);

exit 0;

sub findInfo
{
	local ($package,$name,$ver) = @_;
	local $pkgDir = "$portage/$package/$name";
	local $ebuild = "$pkgDir/$name-$ver.ebuild";
	print "$ebuild\n";
	if(-T $ebuild) {
		open(EBUILD, "<$ebuild") || warn "unable to read $ebuild\n";
		while(<EBUILD>) {
			if(/(einfo.*)$/) {
				print "  $1\n";
			}
                        if(/(ewarn.*)$/) {
                                print "  $1\n";
                        }
                        if(/(eerror.*)$/) {
                                print "  $1\n";
                        }
		}
		close(EBUILD);
	}
	print "\n";
}

Re: [gentoo-amd64] backups and world updates

[Matt Randolph]

Roy Wright wrote:

> Most of the time, I just open an konsole and do the
> update.  Occasionally I'll postpone if the update looks
> really large or time consuming.  For major gui components
> like KDE or xorg, I'll exit KDE and emerge from the
> command line over the weekend (ok, probably overly
> cautious, but I was burned once).


I have emerged kde and xorg-x11 from within kde without any problems.  I 
was even emerging firefox while surfing the web.  I probably played some 
Doom III too.

> Occasionally I'll get a blocking condition.  I really think
> twice now before just unblocking via package.keywords.
> I've found that waiting a day or two might result in
> portage handling the unblocking.

Firefox is a good example.  When mozilla-firefox-1.0.5 came out in ~arch 
in response to a GLSA, it hit +arch within the next 24-36 hours, if I 
recall.  I would just "ACCEPT_KEYWORDS='~amd64' emerge -a 
mozilla-firefox" in these situations rather than messing with 
package.keywords.  Then, I'd just keep an eye out for new stable 
packages and emerge them as appropriate.  If you unblock via 
package.keywords you will be resigning yourself to always using a 
testing version, thus exposing yourself to more new bugs than if you 
stayed in stable. 

However, if you simply wait a day or two, you are leaving yourself 
susceptible to exploits for that entire time.  Think about how many 
spams arrive in thunderbird in that amount of time.  It would only take 
one hastily written spam exploiting the right vulnerability and then 
POW!  As unlikely as that may be, I'd rather install security updates 
the very instant I find out about them instead.

-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] backups and world updates

[Matt Randolph]

Mark wrote:

>Thanks to everyone who helped me get my system back after a couple of
>world update snafus. Now of course I'm a little gun-shy about using
>options like emerge --update world. So what's my best bet to keep my
>system up to date, while protecting it from my own lack of
>understanding of updating config files?
>
>Here's what I'm intending to do so far:
>
>1. Prior to running any large system update, back up /etc to another location
>2. use dispatch-conf instead of etc-update
>
>Can anyone make any other suggestions? Which emerge options are best
>for full system updates? Thanks
>  
>
dispatch-conf is probably the single biggest change you can make to 
reduce the chance of future borking (etc-update is bad news; stay away 
from it).  If the diff from dispatch-conf shows nothing but gobbledygook 
before and after, then it's very likely you should simply use the new 
version.

One thing you might do is add a comment whenever you make changes to a 
configuration file by hand:

# added by Mark 7-28-05
foo="bar"

Then the diff will show you clearly that you need to merge the files.  
Obviously, this won't work if the manual change was made through some 
utility.  But then, you can probably just use that utility again to 
re-make the changes.

One other thing I strongly recommend is that you clean up your world 
file.  You really should have only the bare minimum number of packages 
in the world file to avoid problems like circular dependencies.  I 
remember once, long ago, I had both kdebase AND the kde-meta packages in 
my world file (don't ask me how).  I couldn't upgrade much of anything 
kde related until I cleared that up.  Everything was blocking everything 
else.

Use the dep script to clean up your world file.  It's located here:
http://forums.gentoo.org/viewtopic.php?p=907101

The one thing I would add about the dep script is that you still need to 
use your head when it comes to listening to it's recommendations.  dep 
told me to remove quake3 because I had quake3-wop (which depends on 
quake3) and, thus, quake3 was redundant.  I have decided to keep both 
packages in my world file because I may choose to unmerge the quake3-wop 
mod, but I'd probably still want to have quake3 installed.

Other than in cases like that, I strongly suggest you listen to what dep 
tells you and consider making the recommended changes to your world file 
(and copy world to [.]world.bak before you make any changes, of course).

I do an "emerge -Dup world" every day right after I "glsa-check."  I do 
a "revdep-rebuild -p" whenever I wind up upgrading more than a few packages.

If things go wrong during an emerge world, I have found it useful to 
emerge --metadata before resuming.  Also, delete 
/root/.revdep-rebuild*.?_* if revdep-rebuild is acting strange.  Then 
just try again.

Also, bear in mind that revdep-rebuild doesn't work properly with binary 
packages like mozilla-firefox-bin and openoffice-bin.  I always do a 
"revdep-rebuild -p" and then emerge the broken packages by hand.

Oh, and remember to use the --oneshot flag when you're emerging a single 
package to fix a dependency.  Otherwise, you'll wind up with redundant 
entries in your world file again.  You'll have to keep your wits about 
you here again to decided whether a given package belongs in your world 
file or not.

-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: backups and world updates

[Duncan]

Mark posted <1f81f7e005072806534ed43866@mail.gmail.com>, excerpted below, 
on Thu, 28 Jul 2005 09:53:20 -0400:

> Thanks to everyone who helped me get my system back after a couple of
> world update snafus. Now of course I'm a little gun-shy about using
> options like emerge --update world. So what's my best bet to keep my
> system up to date, while protecting it from my own lack of understanding
> of updating config files?
> 
> Here's what I'm intending to do so far:
> 
> 1. Prior to running any large system update, back up /etc to another
> location 2. use dispatch-conf instead of etc-update
> 
> Can anyone make any other suggestions? Which emerge options are best for
> full system updates? Thanks

One of the most useful things I've found here, is to add "buildpkg" to
your make.conf FEATURES line.  Portage will then emerge as normal thru the
compile and fake-install stages, then instead of qmerging directly to your
live file system, it will tarball up the resulting fake-install, attach
the ebuild and some useful metadata to to make merging it easier, and file
away the resulting binary package in your portage ${PKGDIR}
(${PORTDIR}/packages, by default).  It will then untar the binpkg it just
created, and merge that, thereby ensuring the binpkg works as intended
(thus avoiding the nasty surprise of a dud binpkg if you end up needing it
later).

This way, eventually, you'll have several back-versions of each package
available in binary form, so if a new version of a package fails, you can
simply emerge --packageonly your previous, known working, version, without
having to go thru all the trouble recompiling what was just on your system
before you merged the broken version!

Among other things, this protects you from a gcc failure, as it'll be a
simple matter to just remerge your last working gcc from the binary
package, which won't require a working gcc to compile since it's a
precompiled binary package!

If portage itself (or python, which portage needs to function) breaks,
again, no problem, because altho you can't use the broken portage to
remerge itself, the binary package is actually just a tbz2 (tar.bz2)
tarball including the files themselves, with that bit of portage metadata
glued onto the end.  Thus, (after backing up any config files you want to
keep), simply extract the tarball over root, and it'll deploy a working
portage once again.  At that point, the portage database will have
incorrect information about what version of portage (or python) itself is
merged, but since portage is now working again, you'll be able to emerge
--packageonly the package over itself, to get the portage database back in
line with reality again, and clean up the loose ends.

If tar or bzip2 break, you'll be unable to remerge them directly, using
this technique, because portage needs them to extract the binary package. 
However, again, that's not an insurmountable problem.  There are in fact
two solutions.  First, both those packages are comparatively easy to
remerge the conventional way, from source, if necessary.  Thus, you can
do FEATURES=-buildpkg emerge bzip2 (or tar), to remerge without having
portage try to use the broken binary packaging ability.  Alternatively,
you can copy working copies of the appropriate executable from your rescue
partition or the LiveCD, over top of the borked copies, then use emerge -K
to remerge your last previously working version.

FEATURES=buildpkg comes in handy for other things as well, particularly
for troubleshooting.  Since I have a backup copy saved, if something quits
working, it's easy for me to temporarily remerge and old version to check
if it worked with it or if something else (possibly a library or other
dependency) caused the breakage.

***  VERY HANDY within the context of broken config files, since the
binary packages save the default configs, if I want to see how my existing
config compares to the default config, all I have to do is grab the
default config out of the binary package and compare it with my existing
version.

Likewise, I can quickly compare scripts and default configs between
versions, and compare files existing in the various versions with what's
on my live system.

Space required to store all those binary packages?  1-5 gigs, depending on
how often you want to clean out all the old binary packages, how many
packages you have installed, and whether you run amd64 or ~amd64 (the
latter updating more frequently, resulting in more package versions to
store).  I have my $PKGDIR on its own dedicated partition, 1 gig, but
running ~amd64, have to clean out old versions more frequently than I'd
like.  A 5 gig partition would have allowed me to do it only once a year
or so.

So, what if you like this idea, but haven't been doing it, and want to
jumpstart your binary package collection with the packages you have
currently merged?  That's where quickpkg comes in.  quickpkg allows you to
make binary packages based on what's on your system at the moment, thus,
avoiding having to recompile to get the binary package.  Use "equery
list" to get a list of what's currently merged.  The list it returns isn't
really formatted as we want, however, but with a bit of text processing
wizardry...

equery list|cut -d" " -f2|grep -v ^\*$ > package.list

(The cut command cuts out the second field, -f2, with fields delineated by
a space -d" ".  The grep command is there to remove what otherwise ends up
as the first line, after the cut, a single "*".  The result is redirected
to the file package.list.)

That gives you a list of packages.  You may want to open it in an editor
and check it out, or split it into several smaller lists, to process one
at a time.  When you are satisfied, try this (substituting the filenames
for the smaller lists if appropriate):

for pkg in `cat package.list` ; do quickpkg $pkg; done

(This simply creates a bash for loop, iterating over all the lines in the
cat-ed file, executing quickpkg for each line.)

quickpkg spits out info about what is doing, and will deal with slotted
packages as needed, quickpkg-ing all merged versions, so that should do
it.  Keep in mind, however, that it's still a big job, even if it's not
having to actually compile all those packages, so it'll take some time,
which is why I suggested splitting up the list, above.  Of course, you
could simply do it while you were sleeping or away at work or something,
if desired.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list