Re: [gentoo-user] Again, emerge -e @world related questions...
tu...@posteo.de wrote: > Hi, > > what could fail, when doing the change to PIE-enabled applications > on base of the regular updates? > Compilation may fail, if libs are included and not flagged as to be > recompiled, which are of the "old standard"... > What else can fail? What may be the worst scenario? > > Is there a way to do a "emerge -e @world" but only for the system > applications? That would be emerge -e @system. Keep in mind, depending on USE flags and such, that can pull in a lot of what we would consider non-system packages. Here, KDE packages are bad to get pulled in. > > Would it be possible to do a "emerge -e @world" for the system > applications and then update the rest of the applications via the > regular updates of the system (and recompile failing components > manually because one obviously already know the reason) ? > > Do I have to do a "emerge -e @world" from a certain kind of > "reduced system" i.e. starting the system without a desktop > first or boot into an even more reduced state aka "maintance > mode" (via grub) and make the disk rw by hand? > Or is even a much more esoteric doing necessary? > > Cheers > Meino I guess you could do emerge -e @system and then try not doing the rest but from my understanding, you could run into things not working right or not at all. Depending on which packages that applies to, you could have some problems that break things or just things that annoy you. Dale :-) :-)
[gentoo-user] Again, emerge -e @world related questions...
Hi, what could fail, when doing the change to PIE-enabled applications on base of the regular updates? Compilation may fail, if libs are included and not flagged as to be recompiled, which are of the "old standard"... What else can fail? What may be the worst scenario? Is there a way to do a "emerge -e @world" but only for the system applications? Would it be possible to do a "emerge -e @world" for the system applications and then update the rest of the applications via the regular updates of the system (and recompile failing components manually because one obviously already know the reason) ? Do I have to do a "emerge -e @world" from a certain kind of "reduced system" i.e. starting the system without a desktop first or boot into an even more reduced state aka "maintance mode" (via grub) and make the disk rw by hand? Or is even a much more esoteric doing necessary? Cheers Meino
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
On Mon, Dec 04, 2017 at 02:18:30AM +0100, Heiko Baums wrote > Some packages already failed to build but I don't know yet which. But > usually `emerge --keep-going` prints a list of the failed packages at > the end. If you've got it set up, try... ll -rt /var/log/portage/elog/ -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Am Sun, 3 Dec 2017 19:08:25 -0600 schrieb Dale : > I hope that makes sense because it can be rather complicated if it > doesn't click as to what I'm describing. It does. > Based on all the threads, I'm sticking with the old profile until next > week or maybe two weeks. Let some of this settle. It seems things > are going pretty well but there does seem to be a few hiccups here > and there. I'm doing it right now on two PCs with --keep-going since almost one day. At least one night more to go. Some packages already failed to build but I don't know yet which. But usually `emerge --keep-going` prints a list of the failed packages at the end. Heiko
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Heiko Baums wrote: > Am Sun, 3 Dec 2017 06:55:59 -0600 > schrieb Dale : > >> I hope I understood what you meant with all this. I disturbed quite a >> few electrons and stuff with this. lol > I think you understood what I meant even if I didn't think about doing > some other stuff with emerge in between another emerge. And I think > even Meino was more concerned about a power failure in between `emerge > -e @world`. > > Nevertheless interesting to know that `emerge --resume` even works or > at least has once worked after another emerge. > > Heiko > > Just keep in mind, you have to start the resume in another console/konsole first. It's been a good while since I've had to do that but it should work. The biggest thing, starting the process so that the resuming emerge already knows what to do before doing anything else in another terminal. That's what prevents it from clearing out what you want to resume. That said, if fixing something requires a USE flag change or some other environmental change, all bets are off. That will lead to other changes that will not apply to the already loaded resume command. I hope that makes sense because it can be rather complicated if it doesn't click as to what I'm describing. Based on all the threads, I'm sticking with the old profile until next week or maybe two weeks. Let some of this settle. It seems things are going pretty well but there does seem to be a few hiccups here and there. Dale :-) :-)
[gentoo-user] palemoon and gcc [Was: Emerge does want to tell me...what?]
On 2017-12-03 22:45, Simon Thelen wrote: > It might be that palemoon has issues with certain > optimizations/instruction sets that are aggravated by using newer gcc > versions (which could turn on optimizations by default etc). Yes, this is my provisional explanation too. > I tried checking when/why the GCC_SUPPORTED_VERSIONS was added to the > palemoon overlay ebuilds, but can't find an issue or commit introducing > it (didn't spend that long checking), but if I'm not the only one > affected by this it might be worth it to open an issue with upstream. Unfortunately I'm a really shy person and I'm easily turned off by any shade of hostility. And this is what I meant by my "good luck" remark. Upstream isn't quite overtly hostile but still I sense the message that the Linux port is a stepchild, just as it is with Firefox. All of which is a way of saying: if it's worth raising an issue, I'd rather not be the one to do it. > If you are on Ryzen (or potentially any architecture that isn't > Nehalem-Haswell) you could try seeing if it's the same issue I > experienced (testing with `ulimit -c unlimited', recompiling with -O1), > otherwise you could try out the ebuild I maintain at [1] which may have > some differences from the one in the palemoon overlay. My cpu is AMD Phenom. I'll do both of these things at some point when things are quiet here. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
[gentoo-user] Re: New profile & gcc update
On 12/03/17 10:29, Daniel Frey wrote: Well, I moved to the new profile and started emerging gcc on about eight computers or so. I use distcc to speed up the compile process on the slower machines, so I need to keep the versions in sync. I forgot to prefix `emerge -1 gcc` with `FEATURES="-distcc"` and am wondering if the sys-devel/gcc ebuild itself disables distcc on itself. It's been running a while now and it hasn't thrown up its hands in disgust yet, so I'd rather not interrupt it if I don't have to. I took a quick look in the ebuild, and don't see anything obvious. Anyone know? Dan So I left it for a while and the ones I forgot to prefix disabling distcc failed. That answers my question: the gcc ebuild doesn't disable distcc. Dan
Re: [gentoo-user] Re: Emerge does want to tell me...what?
On 17-12-03 at 12:06, Ian Zimmerman wrote: > On 2017-12-03 18:58, Simon Thelen wrote: > > > Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the > > ebuild you're using requires an older gcc it's either wrong or doing > > something weird. > It builds, but the result binary crashes every 10 minutes. Have you > tried it? I have had similar issues, but gcc 6.4.0 isn't the (sole) reproducer. I have 2 systems, a haswell laptop and a Ryzen desktop. Palemoon works fine built using gcc 6.4.0 on the laptop. On the desktop, however, I had regularly occurring segfaults that occurred whenever I ran palemoon and had the ulimit for core dumps set to 0 (ulimit -c to any other value and the segfaults would not occur). I managed to "fix" the segfaulting by compiling palemoon with CFLAGS="-O1" instead of "-O2". I never tried reproducing with an older gcc or clang as the issue only popped up when I rebuilt my desktop for the Ryzen CPU (switched from Nehalem where everything worked fine). Another person I know who uses palemoon on Gentoo has also had no issues with palemoon built against gcc 6.4.0 on an Xeon with Haswell architecture. I assumed this was an issue just with my machine since I could not reproduce it anywhere else. It might be that palemoon has issues with certain optimizations/instruction sets that are aggravated by using newer gcc versions (which could turn on optimizations by default etc). I tried checking when/why the GCC_SUPPORTED_VERSIONS was added to the palemoon overlay ebuilds, but can't find an issue or commit introducing it (didn't spend that long checking), but if I'm not the only one affected by this it might be worth it to open an issue with upstream. > The ebuild from the palemoon overlay explicitly checks for the gcc > version and refuses to proceed if it's newer then 4.9.4. I have > wondered why, but now I know. If you are on Ryzen (or potentially any architecture that isn't Nehalem-Haswell) you could try seeing if it's the same issue I experienced (testing with `ulimit -c unlimited', recompiling with -O1), otherwise you could try out the ebuild I maintain at [1] which may have some differences from the one in the palemoon overlay. [1]: https://git.c-14.de/landsraad.git/tree/www-client/palemoon/palemoon-27.6.2.ebuild -- Simon Thelen
Re: [gentoo-user] Am I in trouble now?
Am Sonntag, 3. Dezember 2017, 19:56:19 CET schrieb tu...@posteo.de: > Hi, > > From the news I did everything to switch to the 17th profile EXCEPT > emerge -e @world. > > One application which was recompiled was gcc-7.20. > > From my undertsand/point of view gcc now has to have the PIE-feature > > gcc-bin/7.2.0>l > total 6676 > lrwxrwxrwx 1 root root 23 2017-12-02 16:36 c++ -> > x86_64-pc-linux-gnu-c++ lrwxrwxrwx 1 root root 23 2017-12-02 16:36 cpp > -> x86_64-pc-linux-gnu-cpp lrwxrwxrwx 1 root root 23 2017-12-02 16:36 > g++ -> x86_64-pc-linux-gnu-g++ lrwxrwxrwx 1 root root 23 2017-12-02 > 16:36 gcc -> x86_64-pc-linux-gnu-gcc -rwxr-xr-x 2 root root 26896 > 2017-12-02 16:36 gcc-ar > -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 gcc-nm > -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 gcc-ranlib > lrwxrwxrwx 1 root root 24 2017-12-02 16:36 gcov -> > x86_64-pc-linux-gnu-gcov -rwxr-xr-x 1 root root 495400 2017-12-02 16:36 > gcov-dump > -rwxr-xr-x 1 root root 515944 2017-12-02 16:36 gcov-tool > lrwxrwxrwx 1 root root 28 2017-12-02 16:36 gfortran -> > x86_64-pc-linux-gnu-gfortran -rwxr-xr-x 2 root root 1002192 2017-12-02 > 16:36 x86_64-pc-linux-gnu-c++ -rwxr-xr-x 1 root root 998096 2017-12-02 > 16:36 x86_64-pc-linux-gnu-cpp -rwxr-xr-x 2 root root 1002192 2017-12-02 > 16:36 x86_64-pc-linux-gnu-g++ -rwxr-xr-x 1 root root 998096 2017-12-02 > 16:36 x86_64-pc-linux-gnu-gcc lrwxrwxrwx 1 root root 23 2017-12-02 > 16:36 x86_64-pc-linux-gnu-gcc-7.2.0 -> x86_64-pc-linux-gnu-gcc -rwxr-xr-x 2 > root root 26896 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc-ar -rwxr-xr-x 2 > root root 26896 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc-nm -rwxr-xr-x 2 > root root 26896 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc-ranlib > -rwxr-xr-x 1 root root 639312 2017-12-02 16:36 x86_64-pc-linux-gnu-gcov > -rwxr-xr-x 1 root root 1002192 2017-12-02 16:36 > x86_64-pc-linux-gnu-gfortran > > > solfire:gcc-bin/7.2.0>checksec --file x86_64-pc-linux-gnu-c++ > RELRO STACK CANARY NXPIE RPATH > RUNPATH FORTIFY Fortified Fortifiable FILE Partial RELRO Canary > found > NX enabledNo PIE No RPATH No RUNPATH > Yes 8 21 x86_64-pc-linux-gnu-c++ > > > > So...No PIE it says. > > /root #>eselect profile show > Current /etc/portage/make.profile symlink: > default/linux/amd64/17.0/no-multilib > > Before I start the rebuild of 2000++ packages ... > Is this all correct up to this point? Keep in mind that the news item literally says: "2) Where supported, GCC will now build position-independent executables (PIE) by default." Note the "Where supported" bit. I don't know if that means "CPUs that this works with" or "profiles that support this", but it looks like the "pie" USE flag is forced globally in the profile and not deactivated in any of its sub- profiles, so I'm tending to the former. Of course, that doesn't mean that things are correct on your end, though. On one of my computers, checksec does say "PIE enabled". Maybe you should try compiling something else and verifying it. After all, there's probably a reason why the "emerge -e @world" bit doesn't exclude any of the packages previously rebuilt. I'll try to verify that on my desktop, though, which is the one out of three computers I haven't migrated yet -- both my home server and laptop have completed their "emerge -e @world" already (thankfully almost, but not entirely, without problems). > Cheers > Meino HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Emerge does want to tell me...what?
On 2017-12-03 18:58, Simon Thelen wrote: > Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the > ebuild you're using requires an older gcc it's either wrong or doing > something weird. It builds, but the result binary crashes every 10 minutes. Have you tried it? The ebuild from the palemoon overlay explicitly checks for the gcc version and refuses to proceed if it's newer then 4.9.4. I have wondered why, but now I know. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
[gentoo-user] Am I in trouble now?
Hi, >From the news I did everything to switch to the 17th profile EXCEPT emerge -e @world. One application which was recompiled was gcc-7.20. >From my undertsand/point of view gcc now has to have the PIE-feature gcc-bin/7.2.0>l total 6676 lrwxrwxrwx 1 root root 23 2017-12-02 16:36 c++ -> x86_64-pc-linux-gnu-c++ lrwxrwxrwx 1 root root 23 2017-12-02 16:36 cpp -> x86_64-pc-linux-gnu-cpp lrwxrwxrwx 1 root root 23 2017-12-02 16:36 g++ -> x86_64-pc-linux-gnu-g++ lrwxrwxrwx 1 root root 23 2017-12-02 16:36 gcc -> x86_64-pc-linux-gnu-gcc -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 gcc-ar -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 gcc-nm -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 gcc-ranlib lrwxrwxrwx 1 root root 24 2017-12-02 16:36 gcov -> x86_64-pc-linux-gnu-gcov -rwxr-xr-x 1 root root 495400 2017-12-02 16:36 gcov-dump -rwxr-xr-x 1 root root 515944 2017-12-02 16:36 gcov-tool lrwxrwxrwx 1 root root 28 2017-12-02 16:36 gfortran -> x86_64-pc-linux-gnu-gfortran -rwxr-xr-x 2 root root 1002192 2017-12-02 16:36 x86_64-pc-linux-gnu-c++ -rwxr-xr-x 1 root root 998096 2017-12-02 16:36 x86_64-pc-linux-gnu-cpp -rwxr-xr-x 2 root root 1002192 2017-12-02 16:36 x86_64-pc-linux-gnu-g++ -rwxr-xr-x 1 root root 998096 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc lrwxrwxrwx 1 root root 23 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc-7.2.0 -> x86_64-pc-linux-gnu-gcc -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc-ar -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc-nm -rwxr-xr-x 2 root root 26896 2017-12-02 16:36 x86_64-pc-linux-gnu-gcc-ranlib -rwxr-xr-x 1 root root 639312 2017-12-02 16:36 x86_64-pc-linux-gnu-gcov -rwxr-xr-x 1 root root 1002192 2017-12-02 16:36 x86_64-pc-linux-gnu-gfortran solfire:gcc-bin/7.2.0>checksec --file x86_64-pc-linux-gnu-c++ RELRO STACK CANARY NXPIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE Partial RELRO Canary found NX enabledNo PIE No RPATH No RUNPATH Yes 8 21 x86_64-pc-linux-gnu-c++ So...No PIE it says. /root #>eselect profile show Current /etc/portage/make.profile symlink: default/linux/amd64/17.0/no-multilib Before I start the rebuild of 2000++ packages ... Is this all correct up to this point? Cheers Meino
Re: [gentoo-user] How to check for PIE-code ?
You can use app-admin/checksec to see if different security features are enabled or not. On Sun, Dec 3, 2017 at 8:06 PM, wrote: > Hi, > > is there any way to check, whether a compilated binary is using > the position-independant-code feature or is still build according > to old standards? > > Cheers > Meino > > > >
[gentoo-user] New profile & gcc update
Well, I moved to the new profile and started emerging gcc on about eight computers or so. I use distcc to speed up the compile process on the slower machines, so I need to keep the versions in sync. I forgot to prefix `emerge -1 gcc` with `FEATURES="-distcc"` and am wondering if the sys-devel/gcc ebuild itself disables distcc on itself. It's been running a while now and it hasn't thrown up its hands in disgust yet, so I'd rather not interrupt it if I don't have to. I took a quick look in the ebuild, and don't see anything obvious. Anyone know? Dan
[gentoo-user] How to check for PIE-code ?
Hi, is there any way to check, whether a compilated binary is using the position-independant-code feature or is still build according to old standards? Cheers Meino
Re: [gentoo-user] Re: Emerge does want to tell me...what?
On 17-12-03 at 09:52, Ian Zimmerman wrote: > On 2017-12-03 06:46, Heiko Baums wrote: > > > 1. It can't find >=sys-devel/gcc-6.4.0 but only older gcc versions. > > > > 2. You have installed a package that depend on sys-devel/gcc-5.4.0-r3 > > or sys-devel/gcc-4.9.4. > > > > I already explained what you can do in the first case. In the second > > case I would try to fix (uninstall, rebuild, upgrade or whatever) > > those packages which depend on an outdated gcc. I guess equery is your > > friend. > Those include palemoon. GL with fixing that. Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the ebuild you're using requires an older gcc it's either wrong or doing something weird. -- Simon Thelen
[gentoo-user] Re: Emerge does want to tell me...what?
On 2017-12-03 06:46, Heiko Baums wrote: > 1. It can't find >=sys-devel/gcc-6.4.0 but only older gcc versions. > > 2. You have installed a package that depend on sys-devel/gcc-5.4.0-r3 > or sys-devel/gcc-4.9.4. > > I already explained what you can do in the first case. In the second > case I would try to fix (uninstall, rebuild, upgrade or whatever) > those packages which depend on an outdated gcc. I guess equery is your > friend. Those include palemoon. GL with fixing that. I'm keeping the old profile for now, but when I switch I'll have to unmask one of the old compilers. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
On Sun, 3 Dec 2017 15:39:31 +0100, Heiko Baums wrote: > But it's actually "--keep-going y". y is the default, so "--keep-going" and "--keep-going y" do the same thing. -- Neil Bothwick Drive not ready: (R)etry (G)o to Impulse (C)all Engineering pgpAV8PgaVH97.pgp Description: OpenPGP digital signature
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
On Sunday, 3 December 2017 14:39:31 GMT Heiko Baums wrote: > Am Sun, 3 Dec 2017 15:16:26 +0100 > > schrieb tu...@posteo.de: > > what is about emerge -e @world --keep-going > > instead? > > That would do something like a --resume --skipfirst automatically with > the difference that it first recalculates the dependency tree in case > another package would depend on the package that failed to build. > > But it's actually "--keep-going y". Depends where you specify it. # alias emerj alias emerj='emerge --jobs --load-average=36 --keep-going --nospinner' I use that all the time; being a command on the command line, it overrides any environment values set in make.conf. -- Regards, Peter.
Re: [gentoo-user] grub-0.97-r16 and profile 17.0 change
On 03-12-2017 ,10:57:33, Peter Humphrey wrote: > On Saturday, 2 December 2017 12:30:57 GMT Mick wrote: > > I'm getting this error after I changed my profile as per > > '2017-11-30-new-17- > > profiles' news item: > > >>> Compiling source in /data/tmp_var/portage/sys-boot/grub-0.97-r16/work/ > > [...] > > > However, sys-boot/grub-0.97-r17 installed fine once keyworded on this > > (mostly) stable system. This may save time for others who come across > > the same problem. > > It has. Thanks Mick. > > -- > Regards, > Peter. Unfortunately, an older system with only 50MB /boot partition did not have enough space to allow sys-boot/grub-0.97-r17 to install all its files and fs drivers. I ended up restoring /boot from a back up. YMMV.
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Am Sun, 3 Dec 2017 15:16:26 +0100 schrieb tu...@posteo.de: > what is about emerge -e @world --keep-going > instead? That would do something like a --resume --skipfirst automatically with the difference that it first recalculates the dependency tree in case another package would depend on the package that failed to build. But it's actually "--keep-going y". Heiko
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Am Sun, 3 Dec 2017 09:09:37 -0500 schrieb "Spackman, Chris" : > emerge --resume --skipfirst `emerge --resume --skipfirst` is necessary if you don't use --keep-going y, a package fails to build and you want to manually resume the actual emerge. Not using --skipfirst wouldn't make much sense, because the broken package will fail to build again anyway. Maybe Dales suggestion would work here. In this case you shouldn't use --skipfirst after fixing the reasons why the package failed to build. If you run `emerge -e @world` e.g. and get a power failure then you shouldn't use --skipfirst because then you want to build the package which was currently built during the power failure again. If you want to do have emerge doing a --resume --skipfirst automatically then you should use --keep-going y in the original emerge command like `emerge -e --keep-going y @world` or `emerge -uDN --keep-going y @world`. Heiko
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Am Sun, 3 Dec 2017 06:55:59 -0600 schrieb Dale : > I hope I understood what you meant with all this. I disturbed quite a > few electrons and stuff with this. lol I think you understood what I meant even if I didn't think about doing some other stuff with emerge in between another emerge. And I think even Meino was more concerned about a power failure in between `emerge -e @world`. Nevertheless interesting to know that `emerge --resume` even works or at least has once worked after another emerge. Heiko
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
On 12/03 09:09, Spackman, Chris wrote: > On 2017/12/03 at 06:55am, Dale wrote: > > > I think I get what you are saying. If for example you start a > > emerge -e world, a emerge -uDN world or something and then stop it > > before it finishes, running emerge --resume should pick up where you > > left off. > > Another helpful option, which I don't think has been mentioned yet, is > --skipfirst. With --resume, this is helpful when a relatively > unimportant package fails to compile. Emerge will skip the one that > failed (because it would be the first one in the resumed emerge) and > continue on. Later, I go back and see about getting the failed package > to work. I don't think that --skipfirst is a good idea if an important > package (one that will affect many other packages) fails. But, I am > not an expert on that stuff. > > So, if: > > emerge -e @world > > fails (on a relatively unimportant package), you could use: > > emerge --resume --skipfirst > > to continue. I am actually almost 75% done with the system rebuild and > have had to do this so far with cdrdao and spideroak-bin (which > probably doesn't matter as it is a -bin package). > > -- > Chris Spackman > > GNU Terry Pratchett > > Hi, what is about emerge -e @world --keep-going instead? Cheers Meino
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
On 2017/12/03 at 06:55am, Dale wrote: > I think I get what you are saying. If for example you start a > emerge -e world, a emerge -uDN world or something and then stop it > before it finishes, running emerge --resume should pick up where you > left off. Another helpful option, which I don't think has been mentioned yet, is --skipfirst. With --resume, this is helpful when a relatively unimportant package fails to compile. Emerge will skip the one that failed (because it would be the first one in the resumed emerge) and continue on. Later, I go back and see about getting the failed package to work. I don't think that --skipfirst is a good idea if an important package (one that will affect many other packages) fails. But, I am not an expert on that stuff. So, if: emerge -e @world fails (on a relatively unimportant package), you could use: emerge --resume --skipfirst to continue. I am actually almost 75% done with the system rebuild and have had to do this so far with cdrdao and spideroak-bin (which probably doesn't matter as it is a -bin package). -- Chris Spackman GNU Terry Pratchett
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Heiko Baums wrote: > Am Sun, 03 Dec 2017 09:53:21 + > schrieb Peter Humphrey : > >> On Sunday, 3 December 2017 04:15:25 GMT Heiko Baums wrote: >> >>> Like I said before. emerge always calculates the dependency tree, >>> which is a lot faster in case of `emerge -e @world` than in case of >>> `emerge -uDN @world`. And then it knows which packages have already >>> been installed and which are not. >>> >>> That said I haven't run an `emerge -e @world` before. So I'm >>> actually not sure if this works the same way as with an `emerge >>> -uDN @world`. >> Nope. Empty-tree means empty-tree. That is, whenever you emerge -e >> world, you start from the beginning every time, regardless of >> anything you were doing just before that. > Actually I was talking about the behavior of `emerge --resume` in the > case of `emerge -e @world` compared to `emerge -uDN @world`. Sorry, if > this was unclear. > > Heiko > > I think I get what you are saying. If for example you start a emerge -e world, a emerge -uDN world or something and then stop it before it finishes, running emerge --resume should pick up where you left off. In the past, I have done that after a reboot. I'm not sure if having some things on tmpfs has a effect on that tho. That said, if you start one of those commands, emerge -e world for example, and then do some other command besides --resume, then most likely that will clear whatever emerge was doing before which means --resume won't work because it has been reset/cleared with the second command. As a workaround, I have been known to go to another terminal/konsole and do a emerge --resume -a and let it get to the point where I need to hit "y" and enter. I let it sit there and go back to the original terminal and emerge with whatever options I need for whatever package needs attention. Then when I'm done, I go to the other terminal/konsole and tell emerge yes to the --resume command. Once that command figures out what it needs to do, it already has its list to work with. However, I can emerge something in another terminal to fix things and hopefully carry on with the --resume. Sometimes doing that doesn't work but it could be worth a try. It's been a while since I've had the need to do that too. Generally, if a package fails, it will fail until something is fixed so that in can complete the process. As I've said before, emerge and how it does things has come a long ways in recent years. I hope I understood what you meant with all this. I disturbed quite a few electrons and stuff with this. lol Dale :-) :-)
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Am Sun, 03 Dec 2017 09:53:21 + schrieb Peter Humphrey : > On Sunday, 3 December 2017 04:15:25 GMT Heiko Baums wrote: > > > Like I said before. emerge always calculates the dependency tree, > > which is a lot faster in case of `emerge -e @world` than in case of > > `emerge -uDN @world`. And then it knows which packages have already > > been installed and which are not. > > > > That said I haven't run an `emerge -e @world` before. So I'm > > actually not sure if this works the same way as with an `emerge > > -uDN @world`. > > Nope. Empty-tree means empty-tree. That is, whenever you emerge -e > world, you start from the beginning every time, regardless of > anything you were doing just before that. Actually I was talking about the behavior of `emerge --resume` in the case of `emerge -e @world` compared to `emerge -uDN @world`. Sorry, if this was unclear. Heiko
Re: [gentoo-user] grub-0.97-r16 and profile 17.0 change
On Saturday, 2 December 2017 12:30:57 GMT Mick wrote: > I'm getting this error after I changed my profile as per > '2017-11-30-new-17- > profiles' news item: > >>> Compiling source in /data/tmp_var/portage/sys-boot/grub-0.97-r16/work/ [...] > However, sys-boot/grub-0.97-r17 installed fine once keyworded on this > (mostly) stable system. This may save time for others who come across > the same problem. It has. Thanks Mick. -- Regards, Peter.
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
On Sun, 3 Dec 2017 04:45:59 +0100, tu...@posteo.de wrote: > Suppose one would do an emerge @world...and then BOOOM! a powerfailyre > would stop the whole thing. Further suppose the filesystem, the > hardware and anything has survived luckily -- only emerge @world needs > to be restarted. > And one does NOT an emerge --resume but an emerge @world. > In this particular case...how does emerge knows from the previous > emerge @world what packages has been recompiled already and are "PIE"? Of course it doesn't, it only does what you tell it to do. If you tell it to resume where it left off, it will do that. If you tell it to rebuild everything, with emerge -e @world, it will do that. Portage, like any other program, does not know what you want it to do, only what you tell it to do. If you want to know which packages have already been rebuilt, use qlop or check the timestamp of /var/db/pkg/cat/name-ver/environment.bz2. -- Neil Bothwick If at first you don't succeed, call in an airstrike. pgprAr6B5cwg0.pgp Description: OpenPGP digital signature
Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
On Sunday, 3 December 2017 04:15:25 GMT Heiko Baums wrote: > Like I said before. emerge always calculates the dependency tree, which > is a lot faster in case of `emerge -e @world` than in case of `emerge > -uDN @world`. And then it knows which packages have already been > installed and which are not. > > That said I haven't run an `emerge -e @world` before. So I'm actually > not sure if this works the same way as with an `emerge -uDN @world`. Nope. Empty-tree means empty-tree. That is, whenever you emerge -e world, you start from the beginning every time, regardless of anything you were doing just before that. -- Regards, Peter.
Re: [gentoo-user] Emerge does want to tell me...what?
On Sun, Dec 3, 2017 at 3:43 PM, wrote: > Hi, > > I started emerge -e @world > > and it stops with this message: > > The following mask changes are necessary to proceed: > (see "package.unmask" in the portage(5) man page for more details) > # required by @selected > # required by @world (argument) > # /usr/portage/profiles/releases/17.0/package.mask: > # Andreas K. Huettel (27 May 2017) > # In the 17.0 profiles we assume that our system compiler uses C++14 > # or later as default language setting. This means it has to be at > # least GCC 6. If you need an older compiler for specific purposes, > # feel free to unmask it, however, using it for normal emerging of > # packages is neither recommended nor supported in any way. > =sys-devel/gcc-5.4.0-r3 > # required by @selected > # required by @world (argument) > # /usr/portage/profiles/releases/17.0/package.mask: > # Andreas K. Huettel (27 May 2017) > # In the 17.0 profiles we assume that our system compiler uses C++14 > # or later as default language setting. This means it has to be at > # least GCC 6. If you need an older compiler for specific purposes, > # feel free to unmask it, however, using it for normal emerging of > # packages is neither recommended nor supported in any way. > =sys-devel/gcc-4.9.4 > If they are installed, make sure they are not active, then uninstall them.
Re: [gentoo-user] CFLAGS for both AMD64 and Intel?
On Sat, Dec 02, 2017 at 11:23:10PM -0800, Manuel McLure wrote > Here's the situation. I have a system that's been running for many years > with an Athlon 5050e processor. The system is built with > > CFLAGS="-march=k8-sse3 -O2 -pipe -msse3" > CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3" > > I have the possibility of upgrading the system to a first-generation > Intel Core i5 which should give a nice speed boost, but of course the > Intel chip doesn't understand 3dnow or 3dnowext, so I'll have to do > a system rebuild before I switch out the motherboard/processor. It > seems pretty obvious that I have to take "3dnow 3dnowext" out of > CPU_FLAGS_X86, but what CFLAGS would be recommended for a system > that will still run with the AMD processor but won't fall over when > I switch to the Intel processor? Once I have the Intel in place I > can rebuild with options more suited for that chip, but I want to > make sure I don't end up in a catch-22 situation. https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/x86-Options.html#x86-Options lists what instruction sets gcc expects for any "-march=" I would suggest rebuilding with... CFLAGS="-march=nocona -O2 -pipe" CPU_FLAGS_X86="mmx sse sse2 sse3" nocona was the first Intel cpu to support AMD64 instructions, and it's the newest Intel that does not exceed your AMD. The next Intel cpu, the "core2" supports ssse3 which your AMD does not (count the "s"'s... very carefully; sse3 != ssse3). -- Walter Dnes I don't run "desktop environments"; I run useful applications
