From: Mart Raudsepp <leio@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: How to resume 'emerge -e @world' after grub fails?
Date: Thu, 21 Dec 2017 10:43:33 +0200 [thread overview]
Message-ID: <1513845813.7322.4.camel@gentoo.org> (raw)
In-Reply-To: <d8ad17b8-8e03-5988-9fc8-1507ec8c85dd@gmail.com>
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.
next prev parent reply other threads:[~2017-12-21 8:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 16:00 [gentoo-user] How to resume 'emerge -e @world' after grub fails? Grant Edwards
2017-12-18 16:07 ` John Blinka
2017-12-18 16:14 ` [gentoo-user] " Grant Edwards
2017-12-18 16:45 ` Dale
2017-12-20 20:16 ` Grant Edwards
2017-12-20 23:28 ` Dale
2017-12-21 8:43 ` Mart Raudsepp [this message]
2017-12-21 9:45 ` Jörg Schaible
2017-12-21 12:00 ` Marc Joliet
2017-12-21 17:02 ` John Covici
2018-01-07 12:39 ` Marc Joliet
2017-12-21 17:13 ` Jörg Schaible
2018-01-07 12:41 ` Marc Joliet
2017-12-21 17:32 ` Grant Edwards
2017-12-18 16:14 ` [gentoo-user] " Dale
2017-12-18 17:55 ` Mick
2017-12-18 19:02 ` David Haller
2017-12-18 19:31 ` Francisco Ares
2017-12-18 20:05 ` David Haller
2017-12-18 22:49 ` Dale
2017-12-18 23:05 ` Adam Carter
2017-12-18 23:38 ` Dale
2017-12-19 3:06 ` David Haller
2017-12-19 4:03 ` Dale
2017-12-20 22:54 ` David Haller
2017-12-21 4:49 ` Dale
2017-12-19 5:51 ` Adam Carter
2017-12-19 9:15 ` Neil Bothwick
2017-12-19 15:45 ` Helmut Jarausch
2017-12-19 18:13 ` Bas Zoutendijk
2017-12-20 8:08 ` Helmut Jarausch
2017-12-20 22:27 ` David Haller
2017-12-19 17:45 ` Dale
2017-12-19 20:22 ` Neil Bothwick
2017-12-20 2:04 ` Adam Carter
2017-12-20 23:18 ` David Haller
2017-12-19 9:21 ` Neil Bothwick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1513845813.7322.4.camel@gentoo.org \
--to=leio@gentoo.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox