[gentoo-user] Re: update fails, but I don't see why
On 2020-12-14, antlists wrote: > What I would do is find out whatever -march fits the oldest chip, and > then set that for all the machines. Especially if, as you say, they're > all AMD the chances are the newer chips will be a superset of the old, FWIW, that's not always the case. Instructions sometiems go away from one CPU generation to the next. -- Grant
Re: [gentoo-user] Re: update fails, but I don't see why
On 14/12/2020 12:55, n952162 wrote: On 12/14/20 11:17 AM, Wols Lists wrote: On 14/12/20 08:51, Dale wrote: If you are able, maybe you can compile the bigger packages on a faster system? If it is a option, it may help. If I have multiple similar machines, I create a shared a shared local repository. Then I run emerge with the settings (can't remember what they are) "use binary if it's there, create binary". That way, especially the big ones, only get built on one machine. Oh man! That would be wonderful. How similar do they need to be? All my x86 machines are currently AMD, I think, but probably from different generations. What I would do is find out whatever -march fits the oldest chip, and then set that for all the machines. Especially if, as you say, they're all AMD the chances are the newer chips will be a superset of the old, so by compiling for the oldest it *should* (famous last words) work everywhere. Cheers, Wol
Re: [gentoo-user] Re: update fails, but I don't see why
On Monday, 14 December 2020 12:55:33 GMT n952162 wrote: > On 12/14/20 11:17 AM, Wols Lists wrote: > > On 14/12/20 08:51, Dale wrote: > >> If you are able, maybe you can compile the bigger packages on a faster > >> system? If it is a option, it may help. > > > > If I have multiple similar machines, I create a shared a shared local > > repository. Then I run emerge with the settings (can't remember what > > they are) "use binary if it's there, create binary". > > > > That way, especially the big ones, only get built on one machine. > > > > Cheers, > > Wol > > Oh man! That would be wonderful. How similar do they need to be? All > my x86 machines are currently AMD, I think, but probably from different > generations. It depends on the different instruction sets between the CPUs. You could try compiling one package as a test with the existing $COMMON_FLAGS on the fast host and emerge '--buildpkg y', or '--buildpkgonly', then emerge it as a binary on the slow host with '--usepkgonly y'. If the binary package does not emerge/run on the slow host, then you can try again, but use COMMON_FLAGS="-march" instead of "-march=native" to compile it on the fast host. The same binary package could then be installed on all slow hosts. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: update fails, but I don't see why
On 12/14/20 11:17 AM, Wols Lists wrote: On 14/12/20 08:51, Dale wrote: If you are able, maybe you can compile the bigger packages on a faster system? If it is a option, it may help. If I have multiple similar machines, I create a shared a shared local repository. Then I run emerge with the settings (can't remember what they are) "use binary if it's there, create binary". That way, especially the big ones, only get built on one machine. Cheers, Wol Oh man! That would be wonderful. How similar do they need to be? All my x86 machines are currently AMD, I think, but probably from different generations.
Re: [gentoo-user] Re: update fails, but I don't see why
On 14/12/20 08:51, Dale wrote: > If you are able, maybe you can compile the bigger packages on a faster > system? If it is a option, it may help. If I have multiple similar machines, I create a shared a shared local repository. Then I run emerge with the settings (can't remember what they are) "use binary if it's there, create binary". That way, especially the big ones, only get built on one machine. Cheers, Wol
Re: [gentoo-user] Re: update fails, but I don't see why
n952162 wrote: > > On 12/14/20 4:54 AM, Grant Edwards wrote: >> On 2020-12-13, n952162 wrote: >>> On 12/13/20 9:18 AM, Neil Bothwick wrote: Nearly 2 months, quite a long time in Gentoo update terms. >>> Okay, is the solution then to re-install? >> That's _a_ solution, and might be less work. >> >> But, if you're not going to update more regularly, you're probably >> going to keep running into situations like this. They will require a >> methodical approach, a good understanding of how portage works, and >> will end up taking up more of your time that would updating once a >> week. >> >> -- >> Grant >> >> > > One thing about frequent updating... I thought I was following the > advice here by developing a procedure to update at the start of every > month. When I did that, llvm, rust, clang, firefox, and thunderbird > would rebuild every time, for an average of 4 to 8 hours a piece. If > those things - or their dependencies - are triggered that often, then > it's likely I'll be building them almost every week instead of every > month. > > > > I run unstable on Firefox and it seems to update here about every two weeks or so. It does vary tho. If you run stable, it may not update as often. If build times are a problem, there is a binary version available. I'm not sure what the default settings are for it tho. It seems rust updates about once a month but it to varies a bit. I'm almost certain I run unstable on it as well. For llvm, it goes a while without a update. I show one in May, one in July, one is September and the last one in November. About every other month it seems. It seems we perceive some packages to update more often than they do. I guess we remember having to wait for them more than we do small packages. This is where genlop -t comes in. It will tell you the compile time and shows dates it was done. I used to swear that OOo was updated every week. It took some looking to figure out, it just seemed that way. If you are able, maybe you can compile the bigger packages on a faster system? If it is a option, it may help. Dale :-) :-)
Re: [gentoo-user] Re: update fails, but I don't see why
On Mon, 14 Dec 2020 07:54:55 +0100, n952162 wrote: > One thing about frequent updating... I thought I was following the > advice here by developing a procedure to update at the start of every > month. When I did that, llvm, rust, clang, firefox, and thunderbird > would rebuild every time, for an average of 4 to 8 hours a piece. If > those things - or their dependencies - are triggered that often, then > it's likely I'll be building them almost every week instead of every > month. The more frequently you update, the fewer packages will need to be emerged on each update. Although frequent updates may mean more work overall, they break it into small chunks that are easy to manage, and can also avoid the long lists of warning messages like you have been seeing. -- Neil Bothwick This message has been cruelly tested on sweet little furry animals. pgpeRCwDnb6Vb.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: update fails, but I don't see why
On 12/14/20 4:54 AM, Grant Edwards wrote: On 2020-12-13, n952162 wrote: On 12/13/20 9:18 AM, Neil Bothwick wrote: Nearly 2 months, quite a long time in Gentoo update terms. Okay, is the solution then to re-install? That's _a_ solution, and might be less work. But, if you're not going to update more regularly, you're probably going to keep running into situations like this. They will require a methodical approach, a good understanding of how portage works, and will end up taking up more of your time that would updating once a week. -- Grant One thing about frequent updating... I thought I was following the advice here by developing a procedure to update at the start of every month. When I did that, llvm, rust, clang, firefox, and thunderbird would rebuild every time, for an average of 4 to 8 hours a piece. If those things - or their dependencies - are triggered that often, then it's likely I'll be building them almost every week instead of every month.
[gentoo-user] Re: update fails, but I don't see why
On 2020-12-13, n952162 wrote: > On 12/13/20 9:18 AM, Neil Bothwick wrote: >> >> Nearly 2 months, quite a long time in Gentoo update terms. > > Okay, is the solution then to re-install? That's _a_ solution, and might be less work. But, if you're not going to update more regularly, you're probably going to keep running into situations like this. They will require a methodical approach, a good understanding of how portage works, and will end up taking up more of your time that would updating once a week. -- Grant
[gentoo-user] Re: update fails, but I don't see why
On 2020-12-13, Dale wrote: > I been using Gentoo for a good long while and most of the time, I still > can't understand what it spits out onto my screen. I know what you mean. I've been running Gentoo on mutliple machines for 20 years now, and I'm still baffled by much of what "emerge" spews. But, I have developed some heuristics to deal with it. Though it's frustrating at times, it's still far less frustrating than Ubuntu, RedHat, SuSe, etc. It seems like when emerge "highly recommends" running 'emerge --oneshot portage', emerge will cryptically refuse to do so about half of the time. :) -- Grant
