[gentoo-user] How to resume 'emerge -e @world' after grub fails?

[gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Grant Edwards]

I tried following the profile 17 upgrade instructions but now I'm
stuck.  After running for a day or so, the 'emerge -e @world' command
stopped when grub-0.97 failed to build.

How do I skip grub and continue?

Or do I have to tell emerge to start over from the beginning (skipping
grub)?  Assuming there are other packages that are going to fail also,
that could take weeks...

-- 
Grant

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[John Blinka]

On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
>
> How do I skip grub and continue?
>

emerge --skipfirst --resume

I had to do that several times in my 17.0 upgrades.

John Blinka

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Dale]

Grant Edwards wrote:
> I tried following the profile 17 upgrade instructions but now I'm
> stuck.  After running for a day or so, the 'emerge -e @world' command
> stopped when grub-0.97 failed to build.
>
> How do I skip grub and continue?
>
> Or do I have to tell emerge to start over from the beginning (skipping
> grub)?  Assuming there are other packages that are going to fail also,
> that could take weeks...
>


emerge --resume --skipfirst 

That should work.  If forced, using --exclude grub might could be
added.  I've never tried that with the --resume command tho. 

Dale

:-)  :-) 

[gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Grant Edwards]

On 2017-12-18, John Blinka <john.blinka@gmail.com> wrote:
> On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
><grant.b.edwards@gmail.com> wrote:
>>
>> How do I skip grub and continue?
>
>
> emerge --skipfirst --resume

Thanks, I just seconds ago finally tumbled across that in Google.

Oddly, the failing package (grub:0) wasn't the first one: it was about
5-6 packags down the list.  So I used --exclude instead.  We'll see
how far that gets...

--
Grant

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Dale]

Grant Edwards wrote:
> On 2017-12-18, John Blinka <john.blinka@gmail.com> wrote:
>> On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
>> <grant.b.edwards@gmail.com> wrote:
>>> How do I skip grub and continue?
>>
>> emerge --skipfirst --resume
> Thanks, I just seconds ago finally tumbled across that in Google.
>
> Oddly, the failing package (grub:0) wasn't the first one: it was about
> 5-6 packags down the list.  So I used --exclude instead.  We'll see
> how far that gets...
>
> --
> Grant
>

You tried it and it does work with --exclude.  lol  Now we know.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Mick]

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

On Monday, 18 December 2017 16:14:42 GMT Dale wrote:
> Grant Edwards wrote:
> > I tried following the profile 17 upgrade instructions but now I'm
> > stuck.  After running for a day or so, the 'emerge -e @world' command
> > stopped when grub-0.97 failed to build.
> > 
> > How do I skip grub and continue?
> > 
> > Or do I have to tell emerge to start over from the beginning (skipping
> > grub)?  Assuming there are other packages that are going to fail also,
> > that could take weeks...
> 
> emerge --resume --skipfirst 
> 
> That should work.  If forced, using --exclude grub might could be
> added.  I've never tried that with the --resume command tho. 
> 
> Dale
> 
> :-)  :-) 

Let's not forget the '--keep-going y' option too.  At the end it will print a 
list of all the packages that failed to emerge.

-- 
Regards,
Mick

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[David Haller]

Hello,

On Mon, 18 Dec 2017, Mick wrote:
>On Monday, 18 December 2017 16:14:42 GMT Dale wrote:
>> Grant Edwards wrote:
>> > I tried following the profile 17 upgrade instructions but now I'm
>> > stuck.  After running for a day or so, the 'emerge -e @world' command
>> > stopped when grub-0.97 failed to build.
>> > 
>> > How do I skip grub and continue?
>> > 
>> > Or do I have to tell emerge to start over from the beginning (skipping
>> > grub)?  Assuming there are other packages that are going to fail also,
>> > that could take weeks...
>> 
>> emerge --resume --skipfirst 
>> 
>> That should work.  If forced, using --exclude grub might could be
>> added.  I've never tried that with the --resume command tho. 
>> 
>> Dale
>> 
>Let's not forget the '--keep-going y' option too.  At the end it will print a 
>list of all the packages that failed to emerge.

Well, there's a catch though. I did:

$ emerge -e --keep-going @world
[some failed pkg(s)]
[Ctrl-C due to going to sleep etc.]
$ emerge -e --keep-going --resume @world
[Ctrl-C due to going to sleep etc.]
[some failed pkg(s)]
$ emerge -e --keep-going --resume @world
[Ctrl-C due to going to sleep etc.]
[2 more failed pkg(s)]
[emerge prints just those two failed pkgs that failed since the last
resume]

And no "failed pgks" were printed at those Ctrl-C...

Only trace was probably deep in the emerge logs and the leftovers in
/var/tmp/portage (-> you should not these down before you shut down if
that's a tmpfs ...)

I think something about this should be done / documented.

Luckily, it was no big deal, as I did a switch to gcc-7.2 / -pie at
the same time, so I ran my "check-pie" script (pie-only check
extracted from checksec) to find the packages that (might) need a
recompile. I've just a few biggies leftover to compile and a couple I
want to mess with. But those have updates pending anyway. So, I'm
about done.

BTW: in the process, I've collected binaries/packages that won't get
compiled as pie... e.g. gcc itself, grub and most (all?) haskell
stuff. ATM, it's a pretty badly ad-hoc script, but I could amend that.
Or at least share the list of "known non-pie-able" binaries, I guess.
Hm. One could also add an output that can be fed to emerge via xargs.

-dnh

-- 
"As a sysadmin, I suppose you're familiar with something called a
  'worst-case scenario'?"
"Isn't that what we call, "having a good day for a change"?"
   (Rik Steenwinkel and Graham Reed)

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Francisco Ares]

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

2017-12-18 17:02 GMT-02:00 David Haller <gentoo@dhaller.de>:

> Hello,
>
> On Mon, 18 Dec 2017, Mick wrote:
> >On Monday, 18 December 2017 16:14:42 GMT Dale wrote:
> >> Grant Edwards wrote:
> >> > I tried following the profile 17 upgrade instructions but now I'm
> >> > stuck.  After running for a day or so, the 'emerge -e @world' command
> >> > stopped when grub-0.97 failed to build.
> >> >
> >> > How do I skip grub and continue?
> >> >
> >> > Or do I have to tell emerge to start over from the beginning (skipping
> >> > grub)?  Assuming there are other packages that are going to fail also,
> >> > that could take weeks...
> >>
> >> emerge --resume --skipfirst
> >>
> >> That should work.  If forced, using --exclude grub might could be
> >> added.  I've never tried that with the --resume command tho.
> >>
> >> Dale
> >>
> >Let's not forget the '--keep-going y' option too.  At the end it will
> print a
> >list of all the packages that failed to emerge.
>
> Well, there's a catch though. I did:
>
> $ emerge -e --keep-going @world
> [some failed pkg(s)]
> [Ctrl-C due to going to sleep etc.]
> $ emerge -e --keep-going --resume @world
> [Ctrl-C due to going to sleep etc.]
> [some failed pkg(s)]
> $ emerge -e --keep-going --resume @world
> [Ctrl-C due to going to sleep etc.]
> [2 more failed pkg(s)]
> [emerge prints just those two failed pkgs that failed since the last
> resume]
>
> And no "failed pgks" were printed at those Ctrl-C...
>
> Only trace was probably deep in the emerge logs and the leftovers in
> /var/tmp/portage (-> you should not these down before you shut down if
> that's a tmpfs ...)
>
> I think something about this should be done / documented.
>
> Luckily, it was no big deal, as I did a switch to gcc-7.2 / -pie at
> the same time, so I ran my "check-pie" script (pie-only check
> extracted from checksec) to find the packages that (might) need a
> recompile. I've just a few biggies leftover to compile and a couple I
> want to mess with. But those have updates pending anyway. So, I'm
> about done.
>
> BTW: in the process, I've collected binaries/packages that won't get
> compiled as pie... e.g. gcc itself, grub and most (all?) haskell
> stuff. ATM, it's a pretty badly ad-hoc script, but I could amend that.
> Or at least share the list of "known non-pie-able" binaries, I guess.
> Hm. One could also add an output that can be fed to emerge via xargs.
>
> -dnh
>
> --
> "As a sysadmin, I suppose you're familiar with something called a
>   'worst-case scenario'?"
> "Isn't that what we call, "having a good day for a change"?"
>    (Rik Steenwinkel and Graham Reed)
>
>

I have a script for "-e" :


#! /bin/bash
LOG=/tmp/update.log
date > $LOG
echo ---- ---- Starting... >> $LOG

#looking for active gcc
N=1
A=`gcc-config -c`
B=$A
while [ $B != `echo $B | sed s/-//` ]
do
       N=$(( $N + 1 ))
       B=`echo $B | sed s/-//`
done
A=`echo $A | cut -d- -f$N-`
GCC_VER=`equery l sys-devel/gcc | grep $A`

nice -n 10 emerge -1v --keep-going --quiet-build =$GCC_VER
sys-devel/libtool 1>> $LOG 2>> $LOG && \
nice -n 10 emerge -1v --keep-going --quiet-build dev-libs/glib
sys-libs/glibc 1>> $LOG 2>> $LOG && \
nice -n 10 emerge -1vb --keep-going --quiet-build =$GCC_VER
sys-devel/libtool 1>> $LOG 2>> $LOG && \
nice -n 10 emerge -vbe --keep-going --quiet-build world 1>> $LOG 2>> $LOG
echo ---- ---- Resuming... >> $LOG
nice -n 10 emerge -vb --resume --keep-going --quiet-build 1>> $LOG 2>> $LOG
echo ---- ---- Resuming... >> $LOG
nice -n 10 emerge -vb --resume --keep-going --quiet-build 1>> $LOG 2>> $LOG
echo ---- ---- Resuming... >> $LOG
nice -n 10 emerge -vb --resume --skip-first --keep-going --quiet-build 1>>
$LOG 2>> $LOG
echo ---- ---- Resuming... >> $LOG
nice -n 10 emerge -vb --resume --keep-going --quiet-build 1>> $LOG 2>> $LOG
echo ---- ---- Resuming... >> $LOG
nice -n 10 emerge -vb --resume --skip-first --keep-going --quiet-build 1>>
$LOG 2>> $LOG
echo ---- ---- Finishing. >> $LOG
date >> $LOG
echo -n  >> $LOG
cat $LOG | mail -b -c -s "emerge -e results" your-email@your-domain



This usually ends up with too many resumes, but at least it gets to the end
of the builds as deep as possible.

Please note the "-b" flag, as I keep binary packages for an emergency.

Hope this helps,
Francisco

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[David Haller]

Hello,

On Mon, 18 Dec 2017, Francisco Ares wrote:
>2017-12-18 17:02 GMT-02:00 David Haller <gentoo@dhaller.de>:
>> On Mon, 18 Dec 2017, Mick wrote:
[..]
>> >Let's not forget the '--keep-going y' option too.  At the end it will
>> print a
>> >list of all the packages that failed to emerge.
>>
>> Well, there's a catch though. I did:
>>
>> $ emerge -e --keep-going @world
>> [some failed pkg(s)]
>> [Ctrl-C due to going to sleep etc.]
>> $ emerge -e --keep-going --resume @world
>> [Ctrl-C due to going to sleep etc.]
>> [some failed pkg(s)]
>> $ emerge -e --keep-going --resume @world
>> [Ctrl-C due to going to sleep etc.]
>> [2 more failed pkg(s)]
>> [emerge prints just those two failed pkgs that failed since the last
>> resume]
>>
>> And no "failed pgks" were printed at those Ctrl-C...
>>
>> Only trace was probably deep in the emerge logs and the leftovers in
>> /var/tmp/portage (-> you should not these down before you shut down if
>> that's a tmpfs ...)
>>
>> I think something about this should be done / documented.
[..]
>I have a script for "-e" :
>
>#! /bin/bash
[..]
>nice -n 10 emerge -1v --keep-going --quiet-build =$GCC_VER
>sys-devel/libtool 1>> $LOG 2>> $LOG && \
>nice -n 10 emerge -1v --keep-going --quiet-build dev-libs/glib
>sys-libs/glibc 1>> $LOG 2>> $LOG && \

I think you've got those reversed. glib depends on glibc. And, besides
being a lib that more and more (basic) packages depend on for utility,
has nothing to do with (g)libc. It's started as a basic utility lib
for the Gimp Toolkit (gtk) ... ;)

>nice -n 10 emerge -1vb --keep-going --quiet-build =$GCC_VER
>sys-devel/libtool 1>> $LOG 2>> $LOG && \

Is this rebuild of gcc / libtool intentional? And what about binutils?
Those are quite critical, IMO.

>nice -n 10 emerge -vbe --keep-going --quiet-build world 1>> $LOG 2>> $LOG
>echo ---- ---- Resuming... >> $LOG

Ah, yeah. Logging. I should've done that. But, as I said, I noticed
too late about that "problem" with resume and failed packages.

BTW: your script will be much easier to maintain if you rewrite is as
such:

====
exec 1>>$LOG
exec 2>>$LOG
# more redirs, e.g. for console output possible
====

and instead of all those

====
foo && \
bar && ...
====

write

====
foo || exit 1
bar || exit 2
...
====

or some such. And this stuff:

>nice -n 10 emerge -vb --resume --keep-going --quiet-build 1>> $LOG 2>> $LOG
>echo ---- ---- Resuming... >> $LOG
>nice -n 10 emerge -vb --resume --keep-going --quiet-build 1>> $LOG 2>> $LOG
>echo ---- ---- Resuming... >> $LOG
[..]
>echo ---- ---- Finishing. >> $LOG

could be wrapped in a loop... I don't know, but I'd hope emerge exits
with a status != 0 if packages failed. And if so, you could use

====
while ! nice -n 10 emerge ... ; do
    echo ---- ---- Resuming...
done
echo ---- ---- Finishing.
====

(assuming you've redirected fd1 to $LOG as mentioned above ;)

[..]
>Please note the "-b" flag, as I keep binary packages for an emergency.

So do I. And I keep a /stage3 dir around. If python/portage breaks,
I just need to point PATH & LD_LIBRARY_PATH and stuff to /stage3/bla
and can restart. BTDT when pulling 4-years abandoned gentoo up to date
last year...

>Hope this helps,

Yeah. Logging ;) And,

HTH, too,
-dnh

-- 
Sheridan: "I'll tell you one thing. If the primates that we came from had
known that some day politicians would come out of the gene pool, they'd have
stayed up in the trees and written evolution off as a bad idea!"
                                         -- Babylon 5, 2x04 - A Distant Star

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Dale]

Mick wrote:
> On Monday, 18 December 2017 16:14:42 GMT Dale wrote:
>> Grant Edwards wrote:
>>> I tried following the profile 17 upgrade instructions but now I'm
>>> stuck.  After running for a day or so, the 'emerge -e @world' command
>>> stopped when grub-0.97 failed to build.
>>>
>>> How do I skip grub and continue?
>>>
>>> Or do I have to tell emerge to start over from the beginning (skipping
>>> grub)?  Assuming there are other packages that are going to fail also,
>>> that could take weeks...
>> emerge --resume --skipfirst 
>>
>> That should work.  If forced, using --exclude grub might could be
>> added.  I've never tried that with the --resume command tho. 
>>
>> Dale
>>
>> :-)  :-) 
> Let's not forget the '--keep-going y' option too.  At the end it will print a 
> list of all the packages that failed to emerge.
>


I have to confess, I set most of this as defaults in make.conf.  The
most often commands I use, eix-sync and emerge -uaDN world.  Everything
else is in make.conf.  Listy for those who may be curious.

EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j5
--quiet-build=n -1 --unordered-display"

FEATURES="-usersync userpriv usersandbox buildpkg sandbox parallel-fetch"

Each of those were added as I noticed I needed them more often than
not.  The backtrack option started out at 50 but sometimes that wasn't
enough so I increased it to 100.  That has worked well so far.  The
--oneshot, (-1), option was to keep unneeded things from being added to
my world file.  Each option has some reason for being there. 

If someone reading this wants to copy that, may solve some problems at
least.  ;-) 

Dale

:-)  :-) 

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Adam Carter]

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

>
> I have to confess, I set most of this as defaults in make.conf.  The
> most often commands I use, eix-sync and emerge -uaDN world.  Everything
> else is in make.conf.  Listy for those who may be curious.
>
> EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j5
> --quiet-build=n -1 --unordered-display"
>
> FEATURES="-usersync userpriv usersandbox buildpkg sandbox parallel-fetch"
>
> Each of those were added as I noticed I needed them more often than
> not.  The backtrack option started out at 50 but sometimes that wasn't
> enough so I increased it to 100.  That has worked well so far.  The
> --oneshot, (-1), option was to keep unneeded things from being added to
> my world file.  Each option has some reason for being there.
>
>
Won't the -1 mean that --depclean will remove packages that you want?

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Dale]

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

Adam Carter wrote:
>
>     I have to confess, I set most of this as defaults in make.conf.  The
>     most often commands I use, eix-sync and emerge -uaDN world. 
>     Everything
>     else is in make.conf.  Listy for those who may be curious.
>
>     EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going
>     -v -j5
>     --quiet-build=n -1 --unordered-display"
>
>     FEATURES="-usersync userpriv usersandbox buildpkg sandbox
>     parallel-fetch"
>
>     Each of those were added as I noticed I needed them more often than
>     not.  The backtrack option started out at 50 but sometimes that wasn't
>     enough so I increased it to 100.  That has worked well so far.  The
>     --oneshot, (-1), option was to keep unneeded things from being
>     added to
>     my world file.  Each option has some reason for being there.
>
>
> Won't the -1 mean that --depclean will remove packages that you want?
>

If I emerge something and want to keep around, I use the --select y
option which overrides the -1 option in make.conf.  Sometimes I install
something, play with it and don't like it and then let --depclean remove
it.  If I emerge something and like it, I can use --select y -n to add
it to world, without compiling it again. 

The key thing, remembering to force it to be added to world, which is a
lot easier than remembering to use -1 for ALL those things I don't want
in the world file.  Before I added the -1 option, my world file was full
of all sorts of things that have no business being there at all.  It was
causing huge problems with upgrades and such. 

I just use what works for me.  Some may not like doing it this way but
some might. 

Dale

:-)  :-) 

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[David Haller]

Hello,

On Mon, 18 Dec 2017, Dale wrote:
>The key thing, remembering to force it to be added to world, which is a
>lot easier than remembering to use -1 for ALL those things I don't want
>in the world file.  Before I added the -1 option, my world file was full
>of all sorts of things that have no business being there at all.  It was
>causing huge problems with upgrades and such. 

Hm.

# wc -l /var/lib/portage/world
1140 /var/lib/portage/world

Am I doing something wrong? Looking it over, it looks right though.
And --depclean is hopelessly overeager here.

====
Packages installed:   3511
Packages in world:    1140
Packages in system:   43
Required packages:    2581
Number to remove:     930
====

Hm. I guess there's stuff missing from world (linux-gazette*?) or
something's broke. I guess I should quickpkg stuff, run a depclean and
go figure what's missing ;) adding to world/pruning whatever ;) I know
a lot of those "depcleaned" pkgs are wanted/needed, so I missed adding
stuff to world or deps are lacking... Oh well. Not while I'm cleaning
up after the profile-13/gcc-5.4 -> profile-17/gcc-7.2 stuff (I'd
already compiled most with gcc 6.4, with "std=c++14" for C++ stuff. So
not much change there besides pie/no-pie.

-dnh

-- 
Shin - Device for finding furniture in the dark.

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Dale]

David Haller wrote:
> Hello,
>
> On Mon, 18 Dec 2017, Dale wrote:
>> The key thing, remembering to force it to be added to world, which is a
>> lot easier than remembering to use -1 for ALL those things I don't want
>> in the world file.  Before I added the -1 option, my world file was full
>> of all sorts of things that have no business being there at all.  It was
>> causing huge problems with upgrades and such. 
> Hm.
>
> # wc -l /var/lib/portage/world
> 1140 /var/lib/portage/world
>
> Am I doing something wrong? Looking it over, it looks right though.
> And --depclean is hopelessly overeager here.
>
> ====
> Packages installed:   3511
> Packages in world:    1140
> Packages in system:   43
> Required packages:    2581
> Number to remove:     930
> ====
>
> Hm. I guess there's stuff missing from world (linux-gazette*?) or
> something's broke. I guess I should quickpkg stuff, run a depclean and
> go figure what's missing ;) adding to world/pruning whatever ;) I know
> a lot of those "depcleaned" pkgs are wanted/needed, so I missed adding
> stuff to world or deps are lacking... Oh well. Not while I'm cleaning
> up after the profile-13/gcc-5.4 -> profile-17/gcc-7.2 stuff (I'd
> already compiled most with gcc 6.4, with "std=c++14" for C++ stuff. So
> not much change there besides pie/no-pie.
>
> -dnh
>

I have KDE installed here plus other desktops as well.  While I use some
meta packages, I do some on their own as needed.  I have a lot of things
installed since I have a digital camera, burn CD/DVDs and all sorts of
other weird things.  Here is mine.

root@fireball / # wc -l /var/lib/portage/world
201 /var/lib/portage/world
root@fireball / #

The way I've done in the past and read others have done as well, make a
backup copy of world, go through the world file and remove anything you
didn't install directly for your use.  If you see anything that is a lib
package, odds are you don't need that in the world file because whatever
needs it will pull it in as a dependency.  What you can do, remove say
ten entries that you didn't install yourself directly, you can just put
a # in front to comment out that entry as well, then run --depclean -a
to see what it shows.  If you see something you use listed, add that to
the world file to keep it.  If not, then let it remove them.  Keep doing
that with whatever number you are comfy with until you get a clean world
file.  This could take a while.  The biggest thing, don't let it remove
any system packages.  It shouldn't but depending on what your system
requires, it could.  If in doubt, use eix to see what the package is. 

Also, it is rare that I install anything with a specific version.  I
actually found one listed in my world file and removed it.  No idea how
or why it was there.  The only exception to that, kernels.  Some of
those are done by version.  If you see a entry with a version, may want
to try to recall why because it could make that version stick and not
upgrade.  It's been a while since I did that.

There is a command that may help with this.  I've never used it and
would strongly recommend backing up your world file first.  There is no
help or options for it that show up here.

regenworld

Either way, doing it manually or using that command, you should end up
with a clean world file after some effort.  I would guess that updates
would be much easier.  Most of mine work first time with no problems. 
Any failures are usually from the build itself. 

Hope that helps.

Dale

:-)  :-) 

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Adam Carter]

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

>
> Hm.
>
> # wc -l /var/lib/portage/world
> 1140 /var/lib/portage/world
>
> Am I doing something wrong?


If you're emerging dependencies without -1, then yes, otherwise, no.


> Looking it over, it looks right though.
> And --depclean is hopelessly overeager here.
>

What makes you think that?


> ====
> Packages installed:   3511
> Packages in world:    1140
> Packages in system:   43
> Required packages:    2581
> Number to remove:     930
> ====
>
> Hm. I guess there's stuff missing from world (linux-gazette*?) or
> something's broke. I guess I should quickpkg stuff, run a depclean and
> go figure what's missing ;) adding to world/pruning whatever ;) I know
> a lot of those "depcleaned" pkgs are wanted/needed, so I missed adding
> stuff to world or deps are lacking...


Yeah reviewing the output of a --pv --depclean sounds like a good idea.
Then you can add anything that's obviously missing to world before a real
--depclean. When i depclean i use -av --depclean --exclude gcc --exclude
gentoo-sources, since i like keep 2 gcc's around and I look after sources
manually.

AFAIK missing dependencies are rare as they are quickly identified by the
breakage.


> Oh well. Not while I'm cleaning
> up after the profile-13/gcc-5.4 -> profile-17/gcc-7.2 stuff (I'd
> already compiled most with gcc 6.4, with "std=c++14" for C++ stuff. So
> not much change there besides pie/no-pie.
>

I ended up rebuilding two machines, partly due to self induced
hardened/PIE/PIC pain, and also to start with empty USE and
/etc/portage/package.* files which were full of crap after many years. I
now have;
$ wc -l /var/lib/portage/world
63 /var/lib/portage/world

and emerge -pe says "Total: 1024 packages"

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Neil Bothwick]

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

On Tue, 19 Dec 2017 16:51:27 +1100, Adam Carter wrote:

> When i depclean i use -av --depclean --exclude gcc --exclude
> gentoo-sources, since i like keep 2 gcc's around and I look after
> sources manually.

You can prevent depclean from removing gcc and kernel like this

% cat /etc/portage/sets.conf
[kernels]
class = portage.sets.dbapi.OwnerSet
world-candidate = False
files = /usr/src

[gcc]
class = portage.sets.dbapi.OwnerSet
world-candidate = False
files = /usr/x86_64-pc-linux-gnu/gcc-bin

Then add @kernels and @gcc to world_sets. I do this and now those
packages have to be unmerged manually. 

Having said that, everything built with gcc-7.2.0 after the profile switch
so I now have only one gcc installed for the first time in years.


-- 
Neil Bothwick

I don't know if I can assimilate one more Borg Tagline!

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Neil Bothwick]

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

On Tue, 19 Dec 2017 04:06:52 +0100, David Haller wrote:

> # wc -l /var/lib/portage/world
> 1140 /var/lib/portage/world
> 
> Am I doing something wrong? Looking it over, it looks right though.

It sounds a lot, but only you know what you need. For comparison I have
217 packages in world plus about another 70 in some sets, under 300 in
total on a fairly busy KDE box.

Look through your world file, it should contain only packages that you use
directly. grep lib /var/lib/portage/world should return very little.

> And --depclean is hopelessly overeager here.
> 
> ====
> Packages installed:   3511
> Packages in world:    1140
> Packages in system:   43
> Required packages:    2581
> Number to remove:     930

I think you need to clean that up first, although it may be that things
are bad enough to warrant renaming the world file then doing emerge -n
for each package you need. Then run depclean -p and look for anything
else you need, add it with emerge -n, rinse and repeat until nothing you
use directly appears in the depclean output.

A quickpkg of the entire system before you start may be wise.


-- 
Neil Bothwick

To be sure of hitting the target, shoot first and call whatever you hit
the target.

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Helmut Jarausch]

On 12/19/2017 10:15:46 AM, Neil Bothwick wrote:
> Having said that, everything built with gcc-7.2.0 after the profile  
> switch
> so I now have only one gcc installed for the first time in years.

In addition. I keep gcc-6.4.0 since it can generate PIE-enabled  
executables AND it it the last compiler with 'gcj'.

I don't understand why 'pdftk' and packages depending on that have been  
masked.

They build and run fine here (profile 17.0)

Just my 2 cents,
Helmut

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Dale]

Neil Bothwick wrote:
> On Tue, 19 Dec 2017 16:51:27 +1100, Adam Carter wrote:
>
>> When i depclean i use -av --depclean --exclude gcc --exclude
>> gentoo-sources, since i like keep 2 gcc's around and I look after
>> sources manually.
> You can prevent depclean from removing gcc and kernel like this
>
> % cat /etc/portage/sets.conf
> [kernels]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/src
>
> [gcc]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/x86_64-pc-linux-gnu/gcc-bin
>
> Then add @kernels and @gcc to world_sets. I do this and now those
> packages have to be unmerged manually. 
>
> Having said that, everything built with gcc-7.2.0 after the profile switch
> so I now have only one gcc installed for the first time in years.
>
>


I thought at one time we could specify versions or slots in the world
file.  Has that changed? 

Dale

:-)  :-)

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Bas Zoutendijk]

On Tue 19 Dec 2017 at 16:45:15 +0100, Helmut Jarausch wrote:
> In addition. I keep gcc-6.4.0 since it can generate PIE-enabled  
> executables AND it it the last compiler with 'gcj'.
> 
> I don't understand why 'pdftk' and packages depending on that have been  
> masked.
> 
> They build and run fine here (profile 17.0)

  If I read the =app-text/pdftk-2.02 ebuild correctly,  it actually uses
GCC 5.4.0,  regardless  of  what  your  system  compiler  is  (6.4.0 for
profile 17.0):

        # We need gcc-5 because of Java
        export PATH="$(gcc-config -B 5.4.0):${PATH}"

                                                              Sincerely,

                                                                 Bas

-- 
Sebastiaan L. Zoutendijk | slzoutendijk@gmail.com

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Neil Bothwick]

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

On Tue, 19 Dec 2017 11:45:58 -0600, Dale wrote:

> > You can prevent depclean from removing gcc and kernel like this
> >
> > % cat /etc/portage/sets.conf
> > [kernels]
> > class = portage.sets.dbapi.OwnerSet
> > world-candidate = False
> > files = /usr/src
> >
> > [gcc]
> > class = portage.sets.dbapi.OwnerSet
> > world-candidate = False
> > files = /usr/x86_64-pc-linux-gnu/gcc-bin
> >
> > Then add @kernels and @gcc to world_sets. I do this and now those
> > packages have to be unmerged manually. 

> I thought at one time we could specify versions or slots in the world
> file.  Has that changed? 

AFAIK you still can, but that means having to add each version to @world.
This way automates it and needs no further action from you once it's set
up.


-- 
Neil Bothwick

We can sympathize with a child who is afraid of the dark, but the
tragedy of life is that most people are afraid of the light.

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Adam Carter]

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

On Tue, Dec 19, 2017 at 8:15 PM, Neil Bothwick <neil@digimed.co.uk> wrote:

> On Tue, 19 Dec 2017 16:51:27 +1100, Adam Carter wrote:
>
> > When i depclean i use -av --depclean --exclude gcc --exclude
> > gentoo-sources, since i like keep 2 gcc's around and I look after
> > sources manually.
>
> You can prevent depclean from removing gcc and kernel like this
>
> % cat /etc/portage/sets.conf
> [kernels]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/src
>
> [gcc]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/x86_64-pc-linux-gnu/gcc-bin
>
> Then add @kernels and @gcc to world_sets. I do this and now those
> packages have to be unmerged manually.
>

Nice. I feel like i should look into that an learn more about Gentoo, but
then;

alias depclean="emerge -av --depclean --exclude gcc --exclude
gentoo-sources"

And the motivation is gone.

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

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Helmut Jarausch]

On 12/19/2017 07:13:55 PM, Bas Zoutendijk wrote:
> On Tue 19 Dec 2017 at 16:45:15 +0100, Helmut Jarausch wrote:
> > In addition. I keep gcc-6.4.0 since it can generate PIE-enabled
> > executables AND it it the last compiler with 'gcj'.
> >
> > I don't understand why 'pdftk' and packages depending on that have  
> been
> > masked.
> >
> > They build and run fine here (profile 17.0)
> 
>   If I read the =app-text/pdftk-2.02 ebuild correctly,  it actually  
> uses
> GCC 5.4.0,  regardless  of  what  your  system  compiler  is  (6.4.0  
> for
> profile 17.0):
> 
>         # We need gcc-5 because of Java
>         export PATH="$(gcc-config -B 5.4.0):${PATH}"
> 

Yes, but you can change this to

RDEPEND="sys-devel/gcc:6.4.0[gcj]"


which works just fine.

[gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Grant Edwards]

On 2017-12-18, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2017-12-18, John Blinka <john.blinka@gmail.com> wrote:
>> On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
>><grant.b.edwards@gmail.com> wrote:
>>
>>> How do I skip grub and continue?
>>
>> emerge --skipfirst --resume

[...]

> Oddly, the failing package (grub:0) wasn't the first one: it was about
> 5-6 packags down the list.  So I used --exclude instead.  We'll see
> how far that gets...

It took a couple days, but after "resuming" the emerge three times, it
finished.  The three failures were grub:0, matplotlib, and crrcsim.

Each time the failed package was around 5th on the list when I did a
resume.  And, each time emerge insisted on rebuilding gcc and glibc
first.  [I don't remember what else preceded the failed packages when
I did the resumes.]

I think I'll postpone upgrading to profile 17 on my "real work"
computers where I have a lot more packages installed.

-- 
Grant Edwards               grant.b.edwards        Yow! I hope something GOOD
                                  at               came in the mail today so
                              gmail.com            I have a REASON to live!!

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[David Haller]

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

Hello,

On Wed, 20 Dec 2017, Helmut Jarausch wrote:
>On 12/19/2017 07:13:55 PM, Bas Zoutendijk wrote:
>> On Tue 19 Dec 2017 at 16:45:15 +0100, Helmut Jarausch wrote:
>> > In addition. I keep gcc-6.4.0 since it can generate PIE-enabled
>> > executables AND it it the last compiler with 'gcj'.
>> >
>> > I don't understand why 'pdftk' and packages depending on that have been
>> > masked.
>> >
>> > They build and run fine here (profile 17.0)
>> 
>>   If I read the =app-text/pdftk-2.02 ebuild correctly,  it actually uses
>> GCC 5.4.0,  regardless  of  what  your  system  compiler  is  (6.4.0 for
>> profile 17.0):
>> 
>>         # We need gcc-5 because of Java
>>         export PATH="$(gcc-config -B 5.4.0):${PATH}"
>
>Yes, but you can change this to
>
>RDEPEND="sys-devel/gcc:6.4.0[gcj]"
>
>which works just fine.

But should suffice to be

DEPEND="sys-devel/gcc[gcj]"
RDEPEND="${DEPEND}"

i.e. DEPEND not RDEPEND. The 6.4.x part is implicit by 7.x lacking the
gcj USE-flag. OTOH, in my ebuild I explicitly depend on 6.4.0 (but
only because I gcc-config'ed to gcc-7.2), so... If you have 6.4.0
selected, that explicit dep could be killed. It's just a matter of
'gcj' and 'gcjh' being in the path and found (and a matching gcc too).

And BTW, you can't change to java/icedtea, I've looked at the code,
it'd be a major rewrite, pdftk uses lots of gcj specific stuff.

I'll attach my whole diff to the original 2.02.ebuild.

HTH,
-dnh

-- 
"Here, in the bare dark face of night /  A calm unhurried eye draws sight
 -- We see in what we think we fear / The cloudings of our thought made clear"
"A most interesting contribution, we're sure, but can we keep this just a
little more focused?" -- GSV "Wisdom Like Silence" to LSV "Serious Callers Only"

[-- Attachment #2: pdftk-2.02-gcc6-ebuild.patch --]
[-- Type: text/x-patch, Size: 1250 bytes --]

--- /usr/portage/app-text/pdftk/pdftk-2.02.ebuild	2017-12-16 02:20:47.000000000 +0100
+++ pdftk-2.02.ebuild	2017-12-20 23:20:27.139925178 +0100
@@ -13,24 +13,31 @@
 SLOT="0"
 KEYWORDS="amd64 ~arm ppc x86 ~amd64-linux"
 
-RDEPEND="sys-devel/gcc:5.4.0[gcj]"
-DEPEND="${RDEPEND}
-	sys-devel/gcc-config
-"
+DEPEND="sys-devel/gcc:6.4.0[gcj]"
+RDEPEND="${DEPEND}"
 
 S="${WORKDIR}/${P}-dist/${PN}"
 
 src_prepare() {
 	epatch "${FILESDIR}"/${P}-flags.patch
+
+	export PATH="$(gcc-config -B 6.4.0):${PATH}"
+	host=$(gcj -dumpmachine)
+	gcj_ver=$(gcj -dumpversion)
+	gcc_ver=$(gcc -dumpversion)
+	sed -i.orig \
+	    -e "/CPP\|CXX/s@\$(VERSUFF)@-${gcc_ver}@" \
+	    -e "/GCJ\|GCJH/s@\$(VERSUFF)@-${gcj_ver}@" \
+	    -e "/LIBGCJ=/s@.*@export LIBGCJ=/usr/share/gcc-data/${host}/${gcc_ver}/java/libgcj-${gcj_ver}.jar@" \
+	    -e '/GJAR=/s/$(VERSUFF)//' \
+	    Makefile.Debian
 }
 
 src_compile() {
 	# Settings by java-config break compilation by gcj.
 	unset CLASSPATH
 	unset JAVA_HOME
-
-	# We need gcc-5 because of Java
-	export PATH="$(gcc-config -B 5.4.0):${PATH}"
+	export GCJFLAGS="${GCJFLAGS} -Wno-deprecated"
 
 	# Parallel make fails; confirmed, still not fixed in version 2.02.
 	emake -j1 -f "${S}"/Makefile.Debian || die "Compilation failed."

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[David Haller]

Hello,

On Mon, 18 Dec 2017, Dale wrote:
>David Haller wrote:
>> On Mon, 18 Dec 2017, Dale wrote:
>>> The key thing, remembering to force it to be added to world, which is a
>>> lot easier than remembering to use -1 for ALL those things I don't want
>>> in the world file.  Before I added the -1 option, my world file was full
>>> of all sorts of things that have no business being there at all.  It was
>>> causing huge problems with upgrades and such. 
>> Hm.
>>
>> # wc -l /var/lib/portage/world
>> 1140 /var/lib/portage/world
>>
>> Am I doing something wrong? Looking it over, it looks right though.
>> And --depclean is hopelessly overeager here.
>>
>> ====
>> Packages installed:   3511
>> Packages in world:    1140
>> Packages in system:   43
>> Required packages:    2581
>> Number to remove:     930
>> ====
[..]
>I have KDE installed here plus other desktops as well.  While I use some
>meta packages, I do some on their own as needed.  I have a lot of things
>installed since I have a digital camera, burn CD/DVDs and all sorts of
>other weird things.  Here is mine.
>
>root@fireball / # wc -l /var/lib/portage/world
>201 /var/lib/portage/world
>root@fireball / #

That's not much ;)

[..]
>There is a command that may help with this.  I've never used it and
>would strongly recommend backing up your world file first.  There is no
>help or options for it that show up here.
>
>regenworld

Ah, thanks, didn't know that one.

>Either way, doing it manually or using that command, you should end up
>with a clean world file after some effort.  I would guess that updates
>would be much easier.  Most of mine work first time with no problems. 
>Any failures are usually from the build itself. 

I guess I just have too many little stuff in @world. E.g. I explicitly
want the x265 commandline tool, so I have media-libs/x265 in @world.
Same goes for e.g. ffmpeg (for /usr/bin/ffmpeg), etc. pp. Or just
this:

# grep -c app-arch/ /var/lib/portage/world
42      (sic! ;)

Lots of app-{x,}emacs/, app-shells/, app-portage/, app-text/,
games-*/, media-*/...

I'm reather overeager emerging with -1 :) Hah! Got one: --depclean
suggested dev-haskell/x509-validation. Ok, removed it and it is still
used. Ok, let's see if rebuilding depending stuff
(dev-haskell/connection and dev-haskell/tls) helps:

Doesn't seem like it:

 * ghc-pkg check: 'checking for other broken packages:'
There are problems in package connection-0.2.5:
  dependency "x509-validation-1.6.5-9d1Itw2kfW6JXBlF0ahQsB" doesn't exist
There are problems in package tls-1.3.9:
  dependency "x509-validation-1.6.5-9d1Itw2kfW6JXBlF0ahQsB" doesn't exist
[..]
>>> Failed to emerge dev-haskell/connection-0.2.5,

So, remerging dev-haskell/x509-validation. That's one example of the
"overeager" --depclean... (and no, neither dev-haskell/connection
dev-haskell/tls has the "profile"-USE-flags set, but it seems the
build does actually need it).

Whoa, --depclean wants to remove a bunch of eselects too, e.g.
app-eselect/eselect-package-manager and app-eselect/eselect-pdftex.
Ok, I don't have texlive-core in world, but it is pulled in by various
other stuff...

Oh well, I'll have to check what depclean's doing wrong better.

-dnh

-- 
What got my attention one time, however, was the list that included
both "chicken" and "chicken meat" as distinct ingredients.
                                                   -- Kenneth Brody

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[David Haller]

Hello,

On Tue, 19 Dec 2017, Adam Carter wrote:
>> # wc -l /var/lib/portage/world
>> 1140 /var/lib/portage/world
>>
>> Am I doing something wrong?
>
>If you're emerging dependencies without -1, then yes, otherwise, no.

Actually, it's been a long time I've not merged anything without '-1' ;)
Only new stuff I explicity want in world gets the honor of me omitting
the -1.

>> Looking it over, it looks right though.
>> And --depclean is hopelessly overeager here.
>
>What makes you think that?

e.g. the haskell x509-validation example in my other mail.

[..]
>Yeah reviewing the output of a --pv --depclean sounds like a good idea.
>Then you can add anything that's obviously missing to world before a real
>gentoo-sources, since i like keep 2 gcc's around and I look after sources
>manually.
>
>AFAIK missing dependencies are rare as they are quickly identified by the
>breakage.

Actually, I guess it's more missing stuff in world, but there's some
stuff that definitely does not belong in world, but depclean wants to
remove it. Again, the haskell sample works. Basically, I only have
pandoc installed that uses anything haskell, so any haskell stuff
installed is because pandoc (indirectly) depends on it. And depclean
wants to remove part of that "stack". Ok, I checked again, it does
look more like "all of it"... Ooops. Pandoc is not in world. Let's
see... (emerge -Ok app-text/pandoc)...

$ emerge -p --depclean | grep haskell

it still want's to remove about half the haskell stack (which is only
installed because of pandoc's deps). Well, 32 out of 134 (according to
'eix -Ic dev-haskell/') or so... And I just reinstalled all that stuff
from scratch (removing all of dev-haskell/ plus ghc itself, and start
from scratch with "emerge --pretend --tree app-text/pandoc').

I'd have to test and remove just the haskell stuff that depclean
suggests, and then start testing... It's a fine example, as it's a
single app pulling in quite a bit that depclean or I or both get
confused about[1] ;)

That's what I call "overeager". There's other stuff. Might have missed
having some in @world, but with most stuff I'm rather sure it's pulled
in via deps of stuff in @world.

>> Oh well. Not while I'm cleaning
>> up after the profile-13/gcc-5.4 -> profile-17/gcc-7.2 stuff (I'd
>> already compiled most with gcc 6.4, with "std=c++14" for C++ stuff. So
>> not much change there besides pie/no-pie.
>
>I ended up rebuilding two machines, partly due to self induced
>hardened/PIE/PIC pain, and also to start with empty USE and
>/etc/portage/package.* files which were full of crap after many
>years.

Sound's familiar ;)

>I now have;
>$ wc -l /var/lib/portage/world
>63 /var/lib/portage/world
>and emerge -pe says "Total: 1024 packages"

Wow. You don't use much, eh? ;)

-dnh

[1] Normally I would not install such a large stack because of one
    program, e.g. I've masked all stuff mono/sharp etc. but I'm
    interested in haskell in itself, so that's ok :)

-- 
Auch wieder richtig, aber zum bloed posten brauch ich kein Hirn.
Ausserdem tipp ich schneller, als ich denke :).     -- Klaus Muth

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Dale]

Grant Edwards wrote:
> On 2017-12-18, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>> On 2017-12-18, John Blinka <john.blinka@gmail.com> wrote:
>>> On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
>>> <grant.b.edwards@gmail.com> wrote:
>>>
>>>> How do I skip grub and continue?
>>> emerge --skipfirst --resume
> [...]
>
>> Oddly, the failing package (grub:0) wasn't the first one: it was about
>> 5-6 packags down the list.  So I used --exclude instead.  We'll see
>> how far that gets...
> It took a couple days, but after "resuming" the emerge three times, it
> finished.  The three failures were grub:0, matplotlib, and crrcsim.
>
> Each time the failed package was around 5th on the list when I did a
> resume.  And, each time emerge insisted on rebuilding gcc and glibc
> first.  [I don't remember what else preceded the failed packages when
> I did the resumes.]
>
> I think I'll postpone upgrading to profile 17 on my "real work"
> computers where I have a lot more packages installed.
>


I'm not sure why or what all this involves but there is a thread on -dev
about a 17.1 profile coming at some point.  One may want to consider
waiting to do to much for that.  Some of the messages make it seem to be
a really large process to upgrade to it.  I'm hoping some or even most
of it is just the devs testing things.  o_O

Just a thought. 

Dale

:-)  :-) 

Re: [gentoo-user] How to resume 'emerge -e @world' after grub fails?

[Dale]

David Haller wrote:
> Hello,
>
> On Mon, 18 Dec 2017, Dale wrote:
>> David Haller wrote:
>>> On Mon, 18 Dec 2017, Dale wrote:
>>>> The key thing, remembering to force it to be added to world, which is a
>>>> lot easier than remembering to use -1 for ALL those things I don't want
>>>> in the world file.  Before I added the -1 option, my world file was full
>>>> of all sorts of things that have no business being there at all.  It was
>>>> causing huge problems with upgrades and such. 
>>> Hm.
>>>
>>> # wc -l /var/lib/portage/world
>>> 1140 /var/lib/portage/world
>>>
>>> Am I doing something wrong? Looking it over, it looks right though.
>>> And --depclean is hopelessly overeager here.
>>>
>>> ====
>>> Packages installed:   3511
>>> Packages in world:    1140
>>> Packages in system:   43
>>> Required packages:    2581
>>> Number to remove:     930
>>> ====
> [..]
>> I have KDE installed here plus other desktops as well.  While I use some
>> meta packages, I do some on their own as needed.  I have a lot of things
>> installed since I have a digital camera, burn CD/DVDs and all sorts of
>> other weird things.  Here is mine.
>>
>> root@fireball / # wc -l /var/lib/portage/world
>> 201 /var/lib/portage/world
>> root@fireball / #
> That's not much ;)
>
> [..]


It results in this which is all I need and then some.

Packages installed:   1576
Packages in world:    199
Packages in system:   43
Required packages:    1576
 
Notice how my required packages and installed package match up? 


>> Either way, doing it manually or using that command, you should end up
>> with a clean world file after some effort.  I would guess that updates
>> would be much easier.  Most of mine work first time with no problems. 
>> Any failures are usually from the build itself. 
> I guess I just have too many little stuff in @world. E.g. I explicitly
> want the x265 commandline tool, so I have media-libs/x265 in @world.
> Same goes for e.g. ffmpeg (for /usr/bin/ffmpeg), etc. pp. Or just
> this:
>
> # grep -c app-arch/ /var/lib/portage/world
> 42      (sic! ;)
>
> Lots of app-{x,}emacs/, app-shells/, app-portage/, app-text/,
> games-*/, media-*/...


I have quite a few of those as well but they are things I installed
directly.  Given that some of them are pulled in by virtuals which could
be dependencies, I may can remove some of the ones I have.  May test
that one day when I'm bored. 


>
> I'm reather overeager emerging with -1 :) Hah! Got one: --depclean
> suggested dev-haskell/x509-validation. Ok, removed it and it is still
> used. Ok, let's see if rebuilding depending stuff
> (dev-haskell/connection and dev-haskell/tls) helps:
>
> Doesn't seem like it:
>
>  * ghc-pkg check: 'checking for other broken packages:'
> There are problems in package connection-0.2.5:
>   dependency "x509-validation-1.6.5-9d1Itw2kfW6JXBlF0ahQsB" doesn't exist
> There are problems in package tls-1.3.9:
>   dependency "x509-validation-1.6.5-9d1Itw2kfW6JXBlF0ahQsB" doesn't exist
> [..]
>>>> Failed to emerge dev-haskell/connection-0.2.5,
> So, remerging dev-haskell/x509-validation. That's one example of the
> "overeager" --depclean... (and no, neither dev-haskell/connection
> dev-haskell/tls has the "profile"-USE-flags set, but it seems the
> build does actually need it).
>
> Whoa, --depclean wants to remove a bunch of eselects too, e.g.
> app-eselect/eselect-package-manager and app-eselect/eselect-pdftex.
> Ok, I don't have texlive-core in world, but it is pulled in by various
> other stuff...
>
> Oh well, I'll have to check what depclean's doing wrong better.
>
> -dnh
>

I have several eselect packages installed here and not one entry in my
world file.  All of them are pulled in by the packages that need them. 

If it were my system, I'd be pulling the broom out of my closet. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Mart Raudsepp]

On K, 2017-12-20 at 17:28 -0600, Dale wrote:
> Grant Edwards wrote:
> > On 2017-12-18, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> > > On 2017-12-18, John Blinka <john.blinka@gmail.com> wrote:
> > > > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
> > > > <grant.b.edwards@gmail.com> wrote:
> > > > 
> > > > > How do I skip grub and continue?
> > > > emerge --skipfirst --resume
> > [...]
> > 
> > > Oddly, the failing package (grub:0) wasn't the first one: it was
> > > about
> > > 5-6 packags down the list.  So I used --exclude instead.  We'll
> > > see
> > > how far that gets...
> > It took a couple days, but after "resuming" the emerge three times,
> > it
> > finished.  The three failures were grub:0, matplotlib, and crrcsim.
> > 
> > Each time the failed package was around 5th on the list when I did
> > a
> > resume.  And, each time emerge insisted on rebuilding gcc and glibc
> > first.  [I don't remember what else preceded the failed packages
> > when
> > I did the resumes.]
> > 
> > I think I'll postpone upgrading to profile 17 on my "real work"
> > computers where I have a lot more packages installed.
> > 
> 
> 
> I'm not sure why or what all this involves but there is a thread on
> -dev
> about a 17.1 profile coming at some point.  One may want to consider
> waiting to do to much for that.  Some of the messages make it seem to
> be
> a really large process to upgrade to it.  I'm hoping some or even
> most
> of it is just the devs testing things.  o_O
> 
> Just a thought. 

It's about making /usr/lib not be a symlink to lib64 anymore on amd64.

I wouldn't wait for it, could get complicated and messy to do both at
once. If 17.1 pans out (or well, maybe "18.0" when going out of
experimental testing phase next year..), it won't need a full rebuild,
at most only things that have /usr/lib/ entries (instead of /usr/lib64
or /usr/lib32) in portage CONTENTS file in VDB to fix those things up
after the migration tool.

And I don't see anything overeager in --depclean. Maybe a dependency
was removed later, so with still default "--dynamic-deps y" you get
them removed now. If this breaks something, then there's an automagic
dep involved (which should have a bug report and be fixed), or some
changes done to some ebuild without proper revbump.
I think --with-bdeps toggling might let it remove build-time only deps,
though. I didn't observe that being used in the thread here in a way
that lets these build-time only deps get removed, for that to be it.

[gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Jörg Schaible]

Hi,

Am Mon, 18 Dec 2017 11:07:08 -0500 schrieb John Blinka:

> On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
> <grant.b.edwards@gmail.com> wrote:
>>
>> How do I skip grub and continue?
>>
>>
> emerge --skipfirst --resume

This is unfortunately really dangerous, because "emerge --resume" will recalculate the order of the 
outstanding packages and you have no guarantee that the first one will be the one that failed the last run. In 
that case you skip an arbitrary package and you may increase your problems.

You can use --skipfirst only if you have restarted emerge with --resume only and you have ensured that it will 
really continue with the failing package. You may abort the build then with CTRL-C and restart emerge with 
both options.

> I had to do that several times in my 17.0 upgrades.

Maybe more times than necessary ;-)

Cheers,
Jörg

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Marc Joliet]

[-- Attachment #1.1: Type: text/plain, Size: 2038 bytes --]

Am Donnerstag, 21. Dezember 2017, 10:45:41 CET schrieb Jörg Schaible:
> Hi,
> 
> Am Mon, 18 Dec 2017 11:07:08 -0500 schrieb John Blinka:
> > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
> > 
> > <grant.b.edwards@gmail.com> wrote:
> >> How do I skip grub and continue?
> > 
> > emerge --skipfirst --resume
> 
> This is unfortunately really dangerous, because "emerge --resume" will
> recalculate the order of the outstanding packages and you have no guarantee
> that the first one will be the one that failed the last run. In that case
> you skip an arbitrary package and you may increase your problems.
> 
> You can use --skipfirst only if you have restarted emerge with --resume only
> and you have ensured that it will really continue with the failing package.
> You may abort the build then with CTRL-C and restart emerge with both
> options.

That clashes with my understanding, so I looked it up, and it turns out I was right.  From 
emerge(1):

>  --skipfirst
>  
>               This option is only valid when used with --resume.  It removes
>               the first package in the resume list. Dependencies are
>               recalculated for remaining packages and any that have
>               unsatisfied dependencies or are masked will be automatically
>               dropped. Also see the related --keep-going option.

Note the "remaining dependencies" part.  Otherwise, what would be the point of --skipfirst if 
it were so unpredictable?

> > I had to do that several times in my 17.0 upgrades.
> 
> Maybe more times than necessary ;-)

Really, sometimes I wonder why I keep seeing people on this list who clearly haven't heard 
of the --keep-going option.  It's there for a reason.  And don't tell me anybody actually *likes* 
having to manually continue the emerge process, because that's just so, so tedious.

> Cheers,
> Jörg

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


[-- Attachment #1.2: Type: text/html, Size: 9523 bytes --]

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

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[John Covici]

On Thu, 21 Dec 2017 07:00:47 -0500,
Marc Joliet wrote:
> 
> [1  <multipart/alternative (7bit)>]
> [1.1  <text/plain; iso-8859-1 (quoted-printable)>]
> [1.2  <text/html; iso-8859-1 (quoted-printable)>]
> Am Donnerstag, 21. Dezember 2017, 10:45:41 CET schrieb Jörg Schaible:
> 
> > Hi,
> 
> > 
> 
> > Am Mon, 18 Dec 2017 11:07:08 -0500 schrieb John Blinka:
> 
> > > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
> 
> > > 
> 
> > > <grant.b.edwards@gmail.com> wrote:
> 
> > >> How do I skip grub and continue?
> 
> > > 
> 
> > > emerge --skipfirst --resume
> 
> > 
> 
> > This is unfortunately really dangerous, because "emerge --resume" will
> 
> > recalculate the order of the outstanding packages and you have no guarantee
> 
> > that the first one will be the one that failed the last run. In that case
> 
> > you skip an arbitrary package and you may increase your problems.
> 
> > 
> 
> > You can use --skipfirst only if you have restarted emerge with --resume only
> 
> > and you have ensured that it will really continue with the failing package.
> 
> > You may abort the build then with CTRL-C and restart emerge with both
> 
> > options.
> 
> That clashes with my understanding, so I looked it up, and it turns out I was right. From emerge(1):
> 
> > --skipfirst
> 
> > 
> 
> > This option is only valid when used with --resume. It removes
> 
> > the first package in the resume list. Dependencies are
> 
> > recalculated for remaining packages and any that have
> 
> > unsatisfied dependencies or are masked will be automatically
> 
> > dropped. Also see the related --keep-going option.
> 
> Note the "remaining dependencies" part. Otherwise, what would be the point of --skipfirst if it were so unpredictable?
> 
> > > I had to do that several times in my 17.0 upgrades.
> 
> > 
> 
> > Maybe more times than necessary ;-)
> 
> Really, sometimes I wonder why I keep seeing people on this list who clearly haven't heard of the --keep-going option. It's there for a reason. And don't tell me anybody actually *likes* having to manually continue the emerge process,
> because that's just so, so tedious.
> 
> > Cheers,
> 
> > Jörg
> 
> Greetings
> 
> -- 
> 
> Marc Joliet
> 

I have been doing explicit packages as stated in another thread here
and I just delete all the lines before the one that fails.  I did not
want to use --keep-going because I really did want to fix things as
they came up, in case they might effect some packages further down on
the list.  What I did was to do
emerge -ep @world | awk '/ebuild/ {print "="$4}' >a

Once I had that a file, I just put emerge -1a before the first line
and put \ at the end of each line and I was off to the slow races!
Its been about a week with the bugs I had to research and the ebuilds
I had to patch, etc. but its going now and there is only 1-200
packages to go out of 1500 or so.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici wb2una
         covici@ccs.covici.com

[gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Jörg Schaible]

Am Thu, 21 Dec 2017 13:00:47 +0100 schrieb Marc Joliet:

> Am Donnerstag, 21. Dezember 2017, 10:45:41 CET schrieb Jörg Schaible:
>> Hi,
>> 
>> Am Mon, 18 Dec 2017 11:07:08 -0500 schrieb John Blinka:
>> > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
>> > 
>> > <grant.b.edwards@gmail.com> wrote:
>> >> How do I skip grub and continue?
>> > 
>> > emerge --skipfirst --resume
>> 
>> This is unfortunately really dangerous, because "emerge --resume" will
>> recalculate the order of the outstanding packages and you have no
>> guarantee that the first one will be the one that failed the last run.
>> In that case you skip an arbitrary package and you may increase your
>> problems.
>> 
>> You can use --skipfirst only if you have restarted emerge with --resume
>> only and you have ensured that it will really continue with the failing
>> package. You may abort the build then with CTRL-C and restart emerge
>> with both options.
> 
> That clashes with my understanding, so I looked it up, and it turns out
> I was right.  From emerge(1):
> 
>>  --skipfirst
>>  
>>               This option is only valid when used with --resume.  It
>>               removes the first package in the resume list.
>>               Dependencies are recalculated for remaining packages and
>>               any that have unsatisfied dependencies or are masked will
>>               be automatically dropped. Also see the related
>>               --keep-going option.
> 
> Note the "remaining dependencies" part.  Otherwise, what would be the
> point of --skipfirst if it were so unpredictable?

Well, that's the difference between theory and practice. I've been bitten more than once, but you may do as 
you want, it's your system ...

Cheers,
Jörg

[gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Grant Edwards]

On 2017-12-21, Marc Joliet <marcec@gmx.de> wrote:

> Really, sometimes I wonder why I keep seeing people on this list who
> clearly haven't heard of the --keep-going option.

I know about the option and choose not to use it.  I don't want it to
"keep going" until I've looked at what failed and why.

> It's there for a reason.  And don't tell me anybody actually *likes*
> having to manually continue the emerge process, because that's just
> so, so tedious.

You think manually controlling things is "tedious" and you run Gentoo?

-- 
Grant

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Marc Joliet]

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

Am Donnerstag, 21. Dezember 2017, 18:02:22 CET schrieb John Covici:
> I have been doing explicit packages as stated in another thread here
> and I just delete all the lines before the one that fails.  I did not
> want to use --keep-going because I really did want to fix things as
> they came up, in case they might effect some packages further down on
> the list.  What I did was to do
> emerge -ep @world | awk '/ebuild/ {print "="$4}' >a
> 
> Once I had that a file, I just put emerge -1a before the first line
> and put \ at the end of each line and I was off to the slow races!
> Its been about a week with the bugs I had to research and the ebuilds
> I had to patch, etc. but its going now and there is only 1-200
> packages to go out of 1500 or so.

Fair enough, I suppose I've simply been overly irritable lately.

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

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

Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?

[Marc Joliet]

[-- Attachment #1.1: Type: text/plain, Size: 2232 bytes --]

Am Donnerstag, 21. Dezember 2017, 18:13:21 CET schrieb Jörg Schaible:
> Am Thu, 21 Dec 2017 13:00:47 +0100 schrieb Marc Joliet:
> > Am Donnerstag, 21. Dezember 2017, 10:45:41 CET schrieb Jörg Schaible:
> >> Hi,
> >> 
> >> Am Mon, 18 Dec 2017 11:07:08 -0500 schrieb John Blinka:
> >> > On Mon, Dec 18, 2017 at 11:00 AM, Grant Edwards
> >> > 
> >> > <grant.b.edwards@gmail.com> wrote:
> >> >> How do I skip grub and continue?
> >> > 
> >> > emerge --skipfirst --resume
> >> 
> >> This is unfortunately really dangerous, because "emerge --resume" will
> >> recalculate the order of the outstanding packages and you have no
> >> guarantee that the first one will be the one that failed the last run.
> >> In that case you skip an arbitrary package and you may increase your
> >> problems.
> >> 
> >> You can use --skipfirst only if you have restarted emerge with --resume
> >> only and you have ensured that it will really continue with the failing
> >> package. You may abort the build then with CTRL-C and restart emerge
> >> with both options.
> > 
> > That clashes with my understanding, so I looked it up, and it turns out
> > 
> > I was right.  From emerge(1):
> >>  --skipfirst
> >>  
> >>               This option is only valid when used with --resume.  It
> >>               removes the first package in the resume list.
> >>               Dependencies are recalculated for remaining packages and
> >>               any that have unsatisfied dependencies or are masked will
> >>               be automatically dropped. Also see the related
> >>               --keep-going option.
> > 
> > Note the "remaining dependencies" part.  Otherwise, what would be the
> > point of --skipfirst if it were so unpredictable?
> 
> Well, that's the difference between theory and practice. I've been bitten
> more than once, but you may do as you want, it's your system ...

Ah, but I *don't* use "--resume --skipfirst", so I'm in the clear :-) .

But if this is truly something that happens, have you filed a bug yet (if you haven't done so 
already)?

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


[-- Attachment #1.2: Type: text/html, Size: 10457 bytes --]

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