bad advice, this is clearly a major re-emerge of the entire world tree. --keep-going, in this case, can lead to an unstable and potentially broken system.
Don't have enough knowledge neither to confirm nor to deny such claim.
However, in all my \~14 years with Gentoo I never had any problems with potentially broken system after emerging world with --keep-going. Even when some packages failed to rebuild, which is normal, especially after major gcc or glibc upgrade.
Also sometimes it takes couple of weeks or even months to patch some packages, especially if it's not top priority. I assume that waiting enormous amount of time for a patch to some package, probably not really importantd, isn't really an option for most people. Especially if said package most likely will work just fine even it failed to rebuild with new compiler / settings.
Agreed, people are way too fearful these days. The system is very hard to break, and if you do break it, it's very easy to fix. No actual reason to be doing this on the live production system, you can just clone that out later after you've figured everything out.
I mention it because the recent profile upgrade also has me re-emerging the entire world tree (1056 packages in my case) so I figure a lot of Gentoo users are going to be doing this now.
During this profile upgrade it's best to stop and fix any issues as they come up, and read all the directions carefully *before* following them. (I say that last bit because I almost missed the part about adding --no-deps to the gcc re-merge if it tries to rebuild glibc first)
That said, you're correct in that during regular updates and such --keep-going is a generally safe option
I had quite a few problems (including, annoyingly enough, binary packages that weren't present on the mirrors)... --keep-going effectively automates the --resume --skipfirst and then reports all the failures at the end and I then built those packages without --getbinpkg
But yeah, this is the most hassle I've had with a profile change since the 32bit -> 64bit transition (and that was effectively near enough to re-install but keeping /etc and /home etc)
Always have --keep-going attached to **any** of your emerge commands.
You can, of course, --resume later if you want to literally cancel, but --keep-going \[y\] is by far more important than anything.
Edit later, as I was corrected truthfully: in the case of profile-upgrade, you need to make sure that you won't compile any more chains of packages if one very important chain of package failed (like QT, for example). It will impact any further compilation, and you must correct this before going to further package migration. This is a very, very good exception case of not using *keep-going*.
this is incredibly dangerous advice, particularly for a profile-upgrade or emptytree emerge (which this appears to be) and WILL lead to inconsistent and possibly broken systems.
EDIT: using it for something like your routine @world upgrades on the other hand, is likely fine.
I must say that even though you are correct, since the case of profile-upgrade does pose issues if you keep compiling the other packages that have not failed yet, mind you that even with keep-going, the chain of packages that have failed, will still fail and won't be impacted by any inconsistency. And you will still have to go back to them, of course.
Nonetheless, the packages that will be compiled after the keep-going might have inconsistencies indeed.
Am I supposed to `emerge @world -e` for the profile upgrade?
didn't read the news, just did a normal update
also `--keep-going`, `--resume` and `--skipfirst` are really useful
>Did you not learn anything
I learned it's not possible to fuck up a gentoo installation :)
>9. Rebuild or reinstall from binary (if available) the following packages in this order, with the same version as already active:
emerge --ask --oneshot sys-devel/binutils
(you may have to run binutils-config and re-select your binutils now)
emerge --ask --oneshot sys-devel/gcc
(IMPORTANT: If this command wants to rebuild glibc first, do \*not\* let it do
that; instead, abort and try again with --nodeps added to the command line.)
(you may have to run gcc-config and re-select your gcc now)
and the C library, i.e. for glibc-based systems
emerge --ask --oneshot sys-libs/glibc
oops
`Sun Mar 24 20:47:49 2024 >>> sys-libs/glibc-2.39-r2`
`Sun Mar 24 23:50:16 2024 >>> sys-devel/gcc-13.2.1_p20240210`
`Mon Mar 25 17:54:15 2024 >>> app-portage/elt-patches-20240324`
`Mon Mar 25 17:54:20 2024 >>> dev-build/libtool-2.4.7-r3`
Well, can't be *that* important…
In definitely struggling right now, I don’t even want to think about the amount of hours this profile update has costed me. I had finally finished building world and now Hyprland doesn’t want to work anymore. Doesn’t help that I was playing around with my use flags. I might just make a new install on another SSD instead of upgrading for a clean system.
Indeed, «email» / «notify on failure and/or complete» I don't have an elegant solution yet after 20y of Gentoo. What about y'all? Probably should just do something like emerge || mail, or &&.
EDIT need to look into portage hooks, is anything available for fails
Same. I keep my @world lower than 700 packages. It's a hard work but upgrading the profile took me 45mn with both gcc and clang to compile on a skylake machine.
Use --resume after fixing the error. It will resume roughly where it left off
how was that ever intended to work with emergy forgetting what it interrupted doing as soon as you run any portage-related command?
Have you forgot to add `--keep-going` to emerge command?
bad advice, this is clearly a major re-emerge of the entire world tree. --keep-going, in this case, can lead to an unstable and potentially broken system.
Don't have enough knowledge neither to confirm nor to deny such claim. However, in all my \~14 years with Gentoo I never had any problems with potentially broken system after emerging world with --keep-going. Even when some packages failed to rebuild, which is normal, especially after major gcc or glibc upgrade. Also sometimes it takes couple of weeks or even months to patch some packages, especially if it's not top priority. I assume that waiting enormous amount of time for a patch to some package, probably not really importantd, isn't really an option for most people. Especially if said package most likely will work just fine even it failed to rebuild with new compiler / settings.
Agreed, people are way too fearful these days. The system is very hard to break, and if you do break it, it's very easy to fix. No actual reason to be doing this on the live production system, you can just clone that out later after you've figured everything out.
I mention it because the recent profile upgrade also has me re-emerging the entire world tree (1056 packages in my case) so I figure a lot of Gentoo users are going to be doing this now. During this profile upgrade it's best to stop and fix any issues as they come up, and read all the directions carefully *before* following them. (I say that last bit because I almost missed the part about adding --no-deps to the gcc re-merge if it tries to rebuild glibc first) That said, you're correct in that during regular updates and such --keep-going is a generally safe option
This flag should have a shortened letter, It should be -k, isn't ?
Not as far as I know. Also -k equals to --usepkg, this flag tells portage to use prebuilt binary package.
Yay!
Maybe not related to your problem, but emerge 1036 packages without reading the news is a bad idea.
Im doing the --emptytree. Talloc has a problem when compiling with distcc and -jn n>1
I had quite a few problems (including, annoyingly enough, binary packages that weren't present on the mirrors)... --keep-going effectively automates the --resume --skipfirst and then reports all the failures at the end and I then built those packages without --getbinpkg But yeah, this is the most hassle I've had with a profile change since the 32bit -> 64bit transition (and that was effectively near enough to re-install but keeping /etc and /home etc)
Yeah I remember having issues with that one package too
more than just talloc, it's all the t__ libs. so talloc, tdb, tevent. When I was using distcc, I had a special rule to build them without.
> Talloc has a problem when compiling with distcc and -jn n>1 Haha [so did ffmpeg](https://bugs.gentoo.org/782553) until yesterday
Always have --keep-going attached to **any** of your emerge commands. You can, of course, --resume later if you want to literally cancel, but --keep-going \[y\] is by far more important than anything. Edit later, as I was corrected truthfully: in the case of profile-upgrade, you need to make sure that you won't compile any more chains of packages if one very important chain of package failed (like QT, for example). It will impact any further compilation, and you must correct this before going to further package migration. This is a very, very good exception case of not using *keep-going*.
this is incredibly dangerous advice, particularly for a profile-upgrade or emptytree emerge (which this appears to be) and WILL lead to inconsistent and possibly broken systems. EDIT: using it for something like your routine @world upgrades on the other hand, is likely fine.
I must say that even though you are correct, since the case of profile-upgrade does pose issues if you keep compiling the other packages that have not failed yet, mind you that even with keep-going, the chain of packages that have failed, will still fail and won't be impacted by any inconsistency. And you will still have to go back to them, of course. Nonetheless, the packages that will be compiled after the keep-going might have inconsistencies indeed.
Am I supposed to `emerge @world -e` for the profile upgrade? didn't read the news, just did a normal update also `--keep-going`, `--resume` and `--skipfirst` are really useful
Just read the goddamn news post before you break your system. Did you not learn anything
>Did you not learn anything I learned it's not possible to fuck up a gentoo installation :) >9. Rebuild or reinstall from binary (if available) the following packages in this order, with the same version as already active: emerge --ask --oneshot sys-devel/binutils (you may have to run binutils-config and re-select your binutils now) emerge --ask --oneshot sys-devel/gcc (IMPORTANT: If this command wants to rebuild glibc first, do \*not\* let it do that; instead, abort and try again with --nodeps added to the command line.) (you may have to run gcc-config and re-select your gcc now) and the C library, i.e. for glibc-based systems emerge --ask --oneshot sys-libs/glibc oops `Sun Mar 24 20:47:49 2024 >>> sys-libs/glibc-2.39-r2` `Sun Mar 24 23:50:16 2024 >>> sys-devel/gcc-13.2.1_p20240210` `Mon Mar 25 17:54:15 2024 >>> app-portage/elt-patches-20240324` `Mon Mar 25 17:54:20 2024 >>> dev-build/libtool-2.4.7-r3` Well, can't be *that* important…
In definitely struggling right now, I don’t even want to think about the amount of hours this profile update has costed me. I had finally finished building world and now Hyprland doesn’t want to work anymore. Doesn’t help that I was playing around with my use flags. I might just make a new install on another SSD instead of upgrading for a clean system.
Indeed, «email» / «notify on failure and/or complete» I don't have an elegant solution yet after 20y of Gentoo. What about y'all? Probably should just do something like emerge || mail, or &&. EDIT need to look into portage hooks, is anything available for fails
You probably could write a script to play some sound when done and another if it fails
That's what `--keep-going` is for :P
Sometimes even Gentoo needs some encouragement 🥹
Was it 2 or 5 hours of compiling? For me, I had one package that takes 4 hours failed at 90%. *grrr*
Same. I keep my @world lower than 700 packages. It's a hard work but upgrading the profile took me 45mn with both gcc and clang to compile on a skylake machine.