From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A90C013828B for ; Sat, 28 May 2016 19:54:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1E26C23400A; Sat, 28 May 2016 19:54:15 +0000 (UTC) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8EBE9234004 for ; Sat, 28 May 2016 19:54:13 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id n129so34191426wmn.1 for ; Sat, 28 May 2016 12:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=lsKoP5FGDJOU4CcEDQwJEKDpoT6wkF2F8Zte9LIcaTg=; b=C8FXHoOswv/LK6TrQCCujTXomfSRSuXBHjJhynRZ/kM2jT+g+9OBt5EtqlFv1ANoeX jiw6AvG99sJ4MwUvSo4Sz+72xsWlT+Ux9SIpK7imlWEU8TN3GZ3RzddLZHn/3klubMxk Wy4LUKXqIZE5r96rk2+3A7lfCLgi8h0MKSIznWsdZI0vTJAsZc52KRBGfyku1AanWDkp Ckfa2hxhU5uukpaUaH2BzYXrZ67FKrQ5EEcArh0x7NzozRvNnVbIf3JJZ3AVIT5LMomO knPHjd6MHmKdOkGXTWHR4uo+Sx9pH1HhOQmp5XnXXLnT89zqo4EjjZhN2eLvoMdtQOAT +gyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=lsKoP5FGDJOU4CcEDQwJEKDpoT6wkF2F8Zte9LIcaTg=; b=KhArTe95KGTRF5Ll2KBE35GbuvVh+rnAJdo/XTAx01baaP0sqCIIzvmNGdvzvOX4f3 hRynqndmA/fUPPeoK2xl1n1Z8C8N205zl+sJgbBxX7pwd+tMkRxKN6UuHqnqTiXGBosi m97/e7K8DobVYiwrq2VOYwm7kFw3nTyYtS1mHFn1WF0FbokquEQP2Ueofs0He1fiDL4G AEFuxffJ0uXpB7Kcu9cBxjiL1NgcKWpMl2ncfLMKolLqNZPPIJBUW70kQHDDFN7hh+DO FwJpty010PP0XnkrZeVSE6dBlU7XmoXQvnOlyqxUXJNc7prQzNDzaibhfPTlQOrXZEcu Nheg== X-Gm-Message-State: ALyK8tKPKePbyJ3gqpiPacPVoJebk9Lhsp2r+WvzmAufTnVewbfquYXXVbkgqvEvbyzW9A== X-Received: by 10.194.107.233 with SMTP id hf9mr19548959wjb.156.1464465252114; Sat, 28 May 2016 12:54:12 -0700 (PDT) Received: from [192.168.178.21] (p5B0C5C43.dip0.t-ipconnect.de. [91.12.92.67]) by smtp.googlemail.com with ESMTPSA id uq7sm848351wjc.19.2016.05.28.12.54.10 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 May 2016 12:54:11 -0700 (PDT) Subject: Re: [gentoo-user] Re: [OT] How to be a penguin. To: gentoo-user@lists.gentoo.org References: <5749C1AE.5020905@verizon.net> <20160528111929.503f9bbd@sepulchrave.remarqs> <5749D00C.4030408@gmail.com> <5749E469.7020601@gmail.com> <5749E832.1030404@gmail.com> From: Volker Armin Hemmann Message-ID: <5749F761.7020803@googlemail.com> Date: Sat, 28 May 2016 21:54:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <5749E832.1030404@gmail.com> Content-Type: multipart/alternative; boundary="------------080303070403020007000300" X-Archives-Salt: f363f9b6-4d20-4428-bdfb-c9c09d615083 X-Archives-Hash: 8665ff5839a2f6be06d6cf89fc52d96a This is a multi-part message in MIME format. --------------080303070403020007000300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 28.05.2016 um 20:49 schrieb Dale: > Dale wrote: >> Gregory Woodbury wrote: >>> Has Alan ever posted his "jackhammer" script for some experts to >>> look at? >>> >>> I get by really well with a small script that reads the eix outputs, >>> finds the "[U]" >>> tagged packages, and then runs "emerge -u1" on that list. >>> >>> Doing anything more than that will be a cause of pain and suffering. >>> >>> If a package needs patches for something special, it is better to >>> make a local >>> repository with modified ebuilds and distfiles, rather than try to >>> force the gentoo repo >>> into your own mess. I do this for a few tthings that Gentoo doesn't >>> ship. Portage >>> is actuallly quite flexible underneath, itt just takes a bit of >>> learning. >>> >>> -- >>> G.Wolfe Woodbury >>> redwolfe@gmail.com >> >> >> He did a while back. Some very experienced Gentoo users here >> explained to him that his script was the problem. From memory which >> isn't all that good, it syncs the tree which is fine. After that, it >> gets bad. I think it did the updates and then repeated that several >> times within the script. That is done without him looking to see if >> anything needs to be changed, USE flags etc, or if something >> shouldn't be updated at all. I'm pretty sure that it then deletes >> all the logs of what was done, which means anything broken is broke >> and no record of what or even why. >> >> Yes, some things can be done with a script. However, there needs to >> be a point in there where the user, the real brain of what is wanted, >> looks at the list of what will be updated. Only a human can look and >> see if there is USE flag changes or other issues that need a config >> file to be edited. Alan skips all that. >> >> If you want, I can go dig it out and post it. I should have a copy >> of the script in my local email. I keep them for like 2 years or >> something then it deletes the old stuff. I'm not sure if you will >> laugh your head off or cry tho. >> >> Dale >> >> :-) :-) > > > What the heck. I went back and found it. It only took a few > minutes. The rest of this message is the email where he has his > script. I'll do my usual sign off at the bottom, rest is his post. > For those who have already seen it, you might want to skip past the > rest. No need torturing yourself again. > > >> I use two scripts for all emerge use, the goal is to run one command and >> then walk away: >> >> Standard general update script: >> ####################### >> tortoise ~ # cat sysupdate >> >> #they must have moved or removed the logs, might have to track them down >> again... >> #rm /var/log/emerge* >> >> # cache /usr/portage >> echo "caching /usr/portage. This will take a long time." >> time ls -R /usr/portage > /dev/null >> >> emerge --sync >> layman --sync ALL >> >> emerge --update --verbose portage >> emerge --update --newuse --deep --with-bdeps=y system --keep-going >> emerge --update --newuse --deep --with-bdeps=y world --keep-going >> >> rm -f /var/cache/revdep-rebuild/*.rr >> revdep-rebuild >> emerge --skipfirst --resume >> emerge --skipfirst --resume >> etc-update >> eclean-dist >> ######################## >> >> The eclean line was added just a few days ago from this thread... >> >> This one is intended to be a nice gentle update script. >> It caches the portage tree, then syncs everything, then updates >> everything starting with critical system packages, then all world >> packages... >> >> Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too >> hard.... >> >> >> This next script is what I use when emerge starts giving me shit: >> >> ################## >> tortoise ~ # cat keepgoing >> emerge --update --newuse --deep --with-bdeps=y system >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> >> emerge --update --newuse --deep --with-bdeps=y world >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> >> rm /var/cache/revdep-rebuild/*.rr >> revdep-rebuild >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> emerge --skipfirst --resume --nodeps >> >> etc-update >> ################### >> >> It's basically the same as the working section of the above but instead >> of letting emerge do it's thing, it jackhammers that bitch as hard as >> possible to get as much updated as possible, but it requires emerge to >> do something and not error out for no good reason... I expect prune and >> depclean to be useless but I kinda need update to basically work every >> time. =\ >> Whatever fails on this script, I just live with until next week/month. >> >> ################### >> tortoise ~ # ./pretendupdate >> >> These are the packages that would be merged, in order: >> >> Calculating dependencies / >> >> !!! Problem resolving dependencies for sys-apps/util-linux from @system >> ... done! >> >> !!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet >> requirements. >> - sys-apps/util-linux-2.27.1::gentoo USE="caps cramfs ncurses nls pam >> python readline suid udev unicode -build -fdformat -kill (-selinux) >> -slang -static-libs -systemd -test -tty-helpers" ABI_X86="32 64 -x32" >> PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4" >> PYTHON_TARGETS="python2_7 python3_4 -python3_3" >> >> The following REQUIRED_USE flag constraints are unsatisfied: >> python? ( exactly-one-of ( python_single_target_python2_7 >> python_single_target_python3_3 python_single_target_python3_4 ) ) >> >> The above constraints are a subset of the following complete expression: >> python? ( exactly-one-of ( python_single_target_python2_7 >> python_single_target_python3_3 python_single_target_python3_4 ) >> python_single_target_python2_7? ( python_targets_python2_7 ) >> python_single_target_python3_3? ( python_targets_python3_3 ) >> python_single_target_python3_4? ( python_targets_python3_4 ) ) >> >> (dependency required by "@system" [set]) >> (dependency required by "@world" [argument]) >> >> tortoise ~ # cat ./pretendupdate >> emerge --update --newuse --deep --with-bdeps=y world --verbose --pretend >> tortoise ~ # >> >> ########### >> >> Google is not being helpful with this... =( > > Dale > > :-) :-) thanks a lot. My eyes are bleeding. --------------080303070403020007000300 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 28.05.2016 um 20:49 schrieb Dale:
Dale wrote:
Gregory Woodbury wrote:
Has Alan ever posted his "jackhammer" script for some experts to look at?

I get by really well with a small script that reads the eix outputs, finds the "[U]"
tagged packages, and then runs "emerge -u1" on that list.

Doing anything more than that will be a cause of pain and suffering.

If a package needs patches for something special, it is better to make a local 
repository with modified ebuilds and distfiles, rather than try to force the gentoo repo 
into your own mess. I do this for a few tthings that Gentoo doesn't ship. Portage
is actuallly quite flexible underneath, itt just takes a bit of learning.

-- 
G.Wolfe Woodbury


He did a while back.  Some very experienced Gentoo users here explained to him that his script was the problem.  From memory which isn't all that good, it syncs the tree which is fine.  After that, it gets bad.  I think it did the updates and then repeated that several times within the script.  That is done without him looking to see if anything needs to be changed, USE flags etc, or if something shouldn't be updated at all.  I'm pretty sure that it then deletes all the logs of what was done, which means anything broken is broke and no record of what or even why. 

Yes, some things can be done with a script.  However, there needs to be a point in there where the user, the real brain of what is wanted, looks at the list of what will be updated.  Only a human can look and see if there is USE flag changes or other issues that need a config file to be edited.   Alan skips all that. 

If you want, I can go dig it out and post it.  I should have a copy of the script in my local email.  I keep them for like 2 years or something then it deletes the old stuff.  I'm not sure if you will laugh your head off or cry tho. 

Dale

:-)  :-) 


What the heck.  I went back and found it.  It only took a few minutes.  The rest of this message is the email where he has his script.  I'll do my usual sign off at the bottom, rest is his post.   For those who have already seen it, you might want to skip past the rest.  No need torturing yourself again.  


I use two scripts for all emerge use, the goal is to run one command and
then walk away:

Standard general update script:
#######################
tortoise ~ # cat sysupdate

#they must have moved or removed the logs, might have to track them down
again...
#rm /var/log/emerge*

# cache /usr/portage 
echo "caching /usr/portage.  This will take a long time."
time ls -R /usr/portage > /dev/null

emerge --sync
layman --sync ALL

emerge --update --verbose portage
emerge --update --newuse --deep --with-bdeps=y system --keep-going
emerge --update --newuse --deep --with-bdeps=y world --keep-going

rm -f /var/cache/revdep-rebuild/*.rr
revdep-rebuild
emerge --skipfirst --resume
emerge --skipfirst --resume
etc-update
eclean-dist
########################

The eclean line was added just a few days ago from this thread...

This one is intended to be a nice gentle update script.
It caches the portage tree, then syncs everything, then updates
everything starting with critical system packages, then all world
packages...

Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too
hard....


This next script is what I use when emerge starts giving me shit:

##################
tortoise ~ # cat keepgoing
emerge --update --newuse --deep --with-bdeps=y system
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps

emerge --update --newuse --deep --with-bdeps=y world
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps

rm /var/cache/revdep-rebuild/*.rr
revdep-rebuild
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps
emerge --skipfirst --resume --nodeps

etc-update
###################

It's basically the same as the working section of the above but instead
of letting emerge do it's thing, it jackhammers that bitch as hard as
possible to get as much updated as possible, but it requires emerge to
do something and not error out for no good reason... I expect prune and
depclean to be useless but I kinda need update to basically work every
time. =\
Whatever fails on this script, I just live with until next week/month.

###################
tortoise ~ # ./pretendupdate

These are the packages that would be merged, in order:

Calculating dependencies /

!!! Problem resolving dependencies for sys-apps/util-linux from @system
... done!

!!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet
requirements.
- sys-apps/util-linux-2.27.1::gentoo USE="caps cramfs ncurses nls pam
python readline suid udev unicode -build -fdformat -kill (-selinux)
-slang -static-libs -systemd -test -tty-helpers" ABI_X86="32 64 -x32"
PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4"
PYTHON_TARGETS="python2_7 python3_4 -python3_3"

  The following REQUIRED_USE flag constraints are unsatisfied:
    python? ( exactly-one-of ( python_single_target_python2_7
python_single_target_python3_3 python_single_target_python3_4 ) )

  The above constraints are a subset of the following complete expression:
    python? ( exactly-one-of ( python_single_target_python2_7
python_single_target_python3_3 python_single_target_python3_4 )
python_single_target_python2_7? ( python_targets_python2_7 )
python_single_target_python3_3? ( python_targets_python3_3 )
python_single_target_python3_4? ( python_targets_python3_4 ) )

(dependency required by "@system" [set])
(dependency required by "@world" [argument])

tortoise ~ # cat ./pretendupdate
emerge --update --newuse --deep --with-bdeps=y world --verbose --pretend
tortoise ~ #

###########

Google is not being helpful with this... =(

Dale

:-)  :-) 

thanks a lot. My eyes are bleeding.
--------------080303070403020007000300--