Re: [gentoo-user] sci-libs/scipy-1.1.0 fails to compile (SOLVED)
I can't answer why it works in this particular case, but the generic answer is that using a -j greater than one risks the launching of a job that requires some output of another job not yet completed, or even run. I suspect if you hunt through the build log, you will find the missing file now created before it is used. If you look at the specific line that created the file, you probably won't find it in the log of the build that failed. My assumption is that assuring correct ordering of tasks during a build is non-trivial in some (many?) cases, and instead of configuring make (or whatever build system is used) to do so, the developers just assume -j1. I'm pretty sure there are (or used to be) some ebuilds which explicitly override and -j greater than one, in cases where it is known to frequently fail. Again, if you're looking for the reason this is so - I can't help. Jack On 2020.05.07 19:20, Victor Ivanov wrote: In case anyone encounters the same issue, the problem was solved by single threaded build using MAKEOPTS="-j1". No other config changes. Why this works but not otherwise remains a mystery. I also had the same problem earlier today with dev-python/matplotlib-2.2.2-r1 except the linker was complaining about an incompatible version of libc. Again solved by -j1 and no other config modifications. I have sometimes experienced this with some packages but exceptionally rarely which is why it's not on usually on my "to try" list. If anyone has any insights as to why this might be happening (in general), I would be grateful and happy to expand my knowledge :) Cheers, Victor On 07/05/2020 15:53, Victor Ivanov wrote: > Ah, thanks for pointing this out! It appears I'm blind ... > > It's rather surprising though, as sci-libs/lapack was neither upgraded > nor rebuilt. Since sci-libs/scipy wasn't upgraded either it ought to > link just fine as it had previously been built against the same version > of sci-libs/lapack. I'm quite baffled. > > Rebuilding sci-libs/lapack didn't help and neither did ~amd64 keywording > it. The error remains the same, which would make sense as there's not > really a new version of sci-libs/lapack. > > Cheers, > Victor > > On 07/05/2020 15:04, Peter Humphrey wrote: >> On Thursday, 7 May 2020 14:31:41 BST Victor Ivanov wrote: >>> Hi all, >>> >>> For some reason SciPy fails to compile after today's Python 3.6 -> >>> Python 3.7 global update. It was the only package that failed out of all. >>> >>> Normally build.log (attached) is helpful enough to get me to resolve the >>> issue. However, it fails with a surprisingly unhelpful message during a >>> call to gfortran. Or maybe I'm unable to spot the proper error message. >> >> Isn't this the cause? >> >> x86_64-pc-linux-gnu-gcc: /var/tmp/portage/sci-libs/scipy-1.1.0/temp/tmpeyMzsQ/ >> source.c >> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: >> /var/tmp/portage/sci-libs/scipy-1.1.0/temp/ccGtNhqg.o: in function `main': >> source.c:(.text.startup+0x8c): undefined reference to `cblas_ddot' >> collect2: error: ld returned 1 exit status >> >
Re: [gentoo-user] sci-libs/scipy-1.1.0 fails to compile (SOLVED)
In case anyone encounters the same issue, the problem was solved by single threaded build using MAKEOPTS="-j1". No other config changes. Why this works but not otherwise remains a mystery. I also had the same problem earlier today with dev-python/matplotlib-2.2.2-r1 except the linker was complaining about an incompatible version of libc. Again solved by -j1 and no other config modifications. I have sometimes experienced this with some packages but exceptionally rarely which is why it's not on usually on my "to try" list. If anyone has any insights as to why this might be happening (in general), I would be grateful and happy to expand my knowledge :) Cheers, Victor On 07/05/2020 15:53, Victor Ivanov wrote: > Ah, thanks for pointing this out! It appears I'm blind ... > > It's rather surprising though, as sci-libs/lapack was neither upgraded > nor rebuilt. Since sci-libs/scipy wasn't upgraded either it ought to > link just fine as it had previously been built against the same version > of sci-libs/lapack. I'm quite baffled. > > Rebuilding sci-libs/lapack didn't help and neither did ~amd64 keywording > it. The error remains the same, which would make sense as there's not > really a new version of sci-libs/lapack. > > Cheers, > Victor > > On 07/05/2020 15:04, Peter Humphrey wrote: >> On Thursday, 7 May 2020 14:31:41 BST Victor Ivanov wrote: >>> Hi all, >>> >>> For some reason SciPy fails to compile after today's Python 3.6 -> >>> Python 3.7 global update. It was the only package that failed out of all. >>> >>> Normally build.log (attached) is helpful enough to get me to resolve the >>> issue. However, it fails with a surprisingly unhelpful message during a >>> call to gfortran. Or maybe I'm unable to spot the proper error message. >> >> Isn't this the cause? >> >> x86_64-pc-linux-gnu-gcc: >> /var/tmp/portage/sci-libs/scipy-1.1.0/temp/tmpeyMzsQ/ >> source.c >> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: >> >> /var/tmp/portage/sci-libs/scipy-1.1.0/temp/ccGtNhqg.o: in function `main': >> source.c:(.text.startup+0x8c): undefined reference to `cblas_ddot' >> collect2: error: ld returned 1 exit status >> > signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Firefox/Watefox and jack?
Am Dienstag, 5. Mai 2020, 18:38:26 CEST schrieb tu...@posteo.de: > On 05/05 11:22, Matt Connell (Gmail) wrote: > > On 2020-05-05 10:38, tu...@posteo.de wrote: > > > Is Firefox/Waterfox able to interface with jackd? > > > > Disclaimer, I do not use Jack. > > > > Firefox builds, in my personal experience, are intended to be used with > > pulseaudio and only pulseaudio. Some people have made some shims for making > > it worth with alsa, but they don't look sustainable. > > > > As the other poster said, this endeavor is likely to result in frustration. > > You may get it to 'work' for some value of that word, but depending on > > expectations, it may not be worth your while. > > > > HI all, > > thanks for the repsonse. > > I am using waterfox, which is not in portage. The mentioning of > Forefox was onlu to make its heritage clear. > > I already have some "experiences" make, when it comes to other things > for audio than alsa. > > Background to my question: > I am still searching for a equalizer solution, which does not > uses the eq provided by the hardware (I am using a DAC, which > does nothing else, than converting PCM into an analog signal. > No processing whatsoever. > > So the eq has to have some sort of DSP funktionality build in. > > And it should be made for background processing. > > Anu helpful alsa-based idea is very appreciated... > > Cheers! > Meino I use Jack and I use Firefox with Jack. It works (mostly) without any problems. Only when you have really a lot sound related tabs (maybe more than 6 active sound sources or so, Firefox makes new jack channels per tab), Firefox slows down a little bit. I also very much recommend to use media-sound/cadence together with jack. There is also a version compatible with ladish (a jack session manager) in the audio-overlay [1]. media-sound/jack-rack for example provides certain equalizers. Best, Gerion [1] https://github.com/gentoo-audio/audio-overlay/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Is Gentoo dead?
Michael wrote: > On Thursday, 7 May 2020 16:11:03 BST Dale wrote: >> Neil Bothwick wrote: >>> On Wed, 6 May 2020 22:31:54 -0500, Dale wrote: There used to be a package that caused some serious problems with upgrades. It was really tricky but I can't recall the name of it since it was ages ago. >>> expat? I recall that causing some hair loss. >> It's possible but it doesn't ring a bell. I recall that the devs did a >> guide for the upgrade. We didn't have the news thingy at the time so >> people sort of ran into it like a train hitting a concrete wall. It >> could get ugly real fast. >> >> Dale >> >> :-) :-) > I remember Dale running into some problems many moons ago, specific to his > hardware detection, but a portage upgrade was not to blame at the time: > > https://xkcd.com/1586/ > > The image alt text is even funnier! :-)) That sounds like hal. Let's not go there. That nerve is still a bit touchy. ;-) That pic makes me wonder. lol Dale :-) :-)
Re: [gentoo-user] Is Gentoo dead?
On Thursday, 7 May 2020 16:11:03 BST Dale wrote: > Neil Bothwick wrote: > > On Wed, 6 May 2020 22:31:54 -0500, Dale wrote: > >> There used to be a package that caused some serious problems with > >> upgrades. It was really tricky but I can't recall the name of it since > >> it was ages ago. > > > > expat? I recall that causing some hair loss. > > It's possible but it doesn't ring a bell. I recall that the devs did a > guide for the upgrade. We didn't have the news thingy at the time so > people sort of ran into it like a train hitting a concrete wall. It > could get ugly real fast. > > Dale > > :-) :-) I remember Dale running into some problems many moons ago, specific to his hardware detection, but a portage upgrade was not to blame at the time: https://xkcd.com/1586/ The image alt text is even funnier! :-)) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Is Gentoo dead?
Petr Vaněk wrote: > On Thu, May 07, 2020 at 10:23:34AM -0500, Dale wrote: >> Petr Vaněk wrote: >>> On Thu, May 07, 2020 at 10:15:39AM -0500, Dale wrote: I'll dig out my magnifying glass in a bit. lol >>> https://linuxfiend.files.wordpress.com/2009/12/gentoo10-19.jpg >> Now that is better. I tried clicking some stuff on the old link, even >> tried ctrl + to increase the size, but nothing helped. >> cute tho. :-D > I just removed ?w=525 from the original image link :) > > Petr > > Well it sure helped these bad old eyes. Sometimes I feel like this. -_- Dale :-) :-)
Re: [gentoo-user] Is Gentoo dead?
On Thu, May 07, 2020 at 10:23:34AM -0500, Dale wrote: > Petr Vaněk wrote: > > On Thu, May 07, 2020 at 10:15:39AM -0500, Dale wrote: > >> I'll dig out my magnifying glass in a bit. lol > > https://linuxfiend.files.wordpress.com/2009/12/gentoo10-19.jpg > > Now that is better. I tried clicking some stuff on the old link, even > tried ctrl + to increase the size, but nothing helped. > cute tho. :-D I just removed ?w=525 from the original image link :) Petr
Re: [gentoo-user] Is Gentoo dead?
Petr Vaněk wrote: > On Thu, May 07, 2020 at 10:15:39AM -0500, Dale wrote: >> I'll dig out my magnifying glass in a bit. lol > https://linuxfiend.files.wordpress.com/2009/12/gentoo10-19.jpg > > Now that is better. I tried clicking some stuff on the old link, even tried ctrl + to increase the size, but nothing helped. That's pretty cute tho. :-D Dale :-) :-)
Re: [gentoo-user] Is Gentoo dead?
On Thu, May 07, 2020 at 10:15:39AM -0500, Dale wrote: > I'll dig out my magnifying glass in a bit. lol https://linuxfiend.files.wordpress.com/2009/12/gentoo10-19.jpg
Re: [gentoo-user] Is Gentoo dead?
hitachi303 wrote: > Am 07.05.2020 um 05:39 schrieb Dale: >> Well, it is about Gentoo and the perception someone had that Gentoo >> is dying, which has been claimed for many, many years now. > > > Personally I like this graphic about gentoo being extinct. > > https://linuxfiend.wordpress.com/2009/12/05/is-gentoo-dying/ > > I wish it was big enough I could actually see it. I'll dig out my magnifying glass in a bit. lol Dale :-) :-)
Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
Neil Bothwick wrote: > On Wed, 6 May 2020 22:31:54 -0500, Dale wrote: > >> There used to be a package that caused some serious problems with >> upgrades. It was really tricky but I can't recall the name of it since >> it was ages ago. > expat? I recall that causing some hair loss. > > It's possible but it doesn't ring a bell. I recall that the devs did a guide for the upgrade. We didn't have the news thingy at the time so people sort of ran into it like a train hitting a concrete wall. It could get ugly real fast. Dale :-) :-)
Re: [gentoo-user] Is Gentoo dead?
On 5/6/20 11:39 PM, Dale wrote: Pengcheng Xu wrote: Sorry for possible necroposting, but I'm pretty interested what's happening in this thread, as there seems to be detailed discussion on topics under this "Is Gentoo dead?" clickbait subject. The whole conversation list does not even fit in a single screen... Would someone kindly provide some clue what's going on? Regards, Well, it is about Gentoo and the perception someone had that Gentoo is dying, which has been claimed for many, many years now.� Then the thread started taking off into other directions.� It got slightly off topic, very off topic a couple times and then back on topic. These threads tend to bring out quite a few responses and most can't resist posting, myself included in that as well.� I might add, there threads are usually started by a newcomer and typically they disappear when they realize how active Gentoo really is.� The OP for this thread posted for a couple days and I don't see any posts after that.� Most likely, unsubscribed and long gone. If you enjoy using Gentoo, or if you don't, if you skip this thread, you won't be missing a whole lot.� I don't recall any breaking news or life saving tips in it.� ROFL Dale :-)� :-) Spot on. Similarly, folks, mostly youngsters, have been predicting the death of 'C'. There are a multitude of reasons C is still the go to language and ought to be mandatory for folks to learn BEFORE any other language. C gives us freedom, and with C, there is no Unix, BSD, or linux, ymmv. Go read this before bashing an old computer scientist: "Programming language C is back in the number one spot" https://www.tiobe.com/tiobe-index/ So I wonder how many of the Gentoo naysayers, actually have written any significant code in C? Pointer please. Arguably the hottest piece of code, was written (mostly) by a Gentoo aficionado: none other that Jason Donefeld, in guess what language? C Gentoo is C centric, since the beginning, whilst enabling a plethora of other languages, that have their place and are, for the most part, wonderful. Anyone attacks, or speaks poorly of Gentoo, is pretty much clueless. Last time I looked, it's still rated as one of the top Linux distros, of all time, when you consider a 20 year perspective. Today, Gentoo seeks to run off the lazy, the inept and those that want to trivialize computational complexities.Ubuntu, Mint and others are more well suited for the masses, the lazy and the inept. Not to mention Gentoo was the foundation of CoreOS. CoreOS advance many 'hot swap kernel' tricks and was purchased by Redhat, as Traditional Redhat is arcane, crusty and bloated. IBM, on their deathbed, has purchased Redhat(basically a gentoo derivative now) and is failing in most of their other business dealings; because they lack real computer scientists in their upper management. Gentoo was, always has, and is still 'kicking ass'; real coders know this, they just keep silent, cause they are MAKING MONEY, off of Gentoo. Gentoo Embedded is a whole other EMPIRE, where folks take credit for building products on embedded systems. GENTOO is still the world's greatest secret in computer science. Here's a tidbit: The hacker, from the inside, that's right an IBM employee at Watson, used Gentoo to hack the shit out of AIX. That was at the point, the main reason, IBM abandoned that looser distro call AIX. Now IBM, via purchasing RedHat (coreOS <== Gentoo) has taken over 20 years, to realize GENTOO is the greatest linux distro of all time. So I cannot help but feel sorry, for the kids, that the universities do not teach C/Unix/BSD/Linux with any dose of credibility. New is sexy, but statistically, 99% of new fades, often rapidly. Just look at the bone-yard of linux distros and fancy programming languages. The (IBM) stench is deep. 'Smarty Pants' has recently left his creation of CoreOS; I guess even the IBM stench was too much for even him, despite making millions and millions. GENTOO IS THE GREATEST DISTRO EVER! Only the original, historical unix distros come close. Unix is the real reason AT was broken up. All that other noise is just a smoke screen, financial maneuvering and just big business. GTE and Honeywell quickly rolled their own 'unix', and the rest is history the universities do not teach, sadly. Don't even get me started on SunOS, and the evil that pursued those lawyers. be blessed, James
Re: [gentoo-user] sci-libs/scipy-1.1.0 fails to compile
Ah, thanks for pointing this out! It appears I'm blind ... It's rather surprising though, as sci-libs/lapack was neither upgraded nor rebuilt. Since sci-libs/scipy wasn't upgraded either it ought to link just fine as it had previously been built against the same version of sci-libs/lapack. I'm quite baffled. Rebuilding sci-libs/lapack didn't help and neither did ~amd64 keywording it. The error remains the same, which would make sense as there's not really a new version of sci-libs/lapack. Cheers, Victor On 07/05/2020 15:04, Peter Humphrey wrote: > On Thursday, 7 May 2020 14:31:41 BST Victor Ivanov wrote: >> Hi all, >> >> For some reason SciPy fails to compile after today's Python 3.6 -> >> Python 3.7 global update. It was the only package that failed out of all. >> >> Normally build.log (attached) is helpful enough to get me to resolve the >> issue. However, it fails with a surprisingly unhelpful message during a >> call to gfortran. Or maybe I'm unable to spot the proper error message. > > Isn't this the cause? > > x86_64-pc-linux-gnu-gcc: /var/tmp/portage/sci-libs/scipy-1.1.0/temp/tmpeyMzsQ/ > source.c > /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > > /var/tmp/portage/sci-libs/scipy-1.1.0/temp/ccGtNhqg.o: in function `main': > source.c:(.text.startup+0x8c): undefined reference to `cblas_ddot' > collect2: error: ld returned 1 exit status > signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Daily update fails
On 07.05.20 13:59, Franz Fellner wrote: On Thu May 7 10:04:37 2020, Dan Johansson wrote: Today when I tried to do my daily "emerge --update ... @world", portage spitted out a lot of "Multiple package instances within a single package slot have been pulled" messages. So THIS would have been the issue you should have given us to solve. Instead you borked your package.use by globally deactivating py2.7 and asked us to point you to that. So please: Revert the python changes you did in your package.use, rerun your update command and post the error you get with that. Please post the whole output, including the exact command you used. And also add "--tree --verbose" to the emerge options, this usually requires less guessing. Neil's suggestion made me add "PYTHON_SINGLE_TARGET: python2_7" to seven packages and now my box is happily compiling (will take some time as there are some "big" packages in there, i.e. firefox, chromium, ...). As per your suggestion I will remove */* PYTHON_TARGETS: python3_6 python3_7 */* PYTHON_SINGLE_TARGET: -* python3_6 and my "PYTHON_SINGLE_TARGET: python2_7" when finished and retry my emerge. If it fails I can certainly post the Output here. -- Dan Johansson, *** This message is printed on 100% recycled electrons! ***
Re: [gentoo-user] Is Gentoo dead?
Am 07.05.2020 um 05:39 schrieb Dale: Well, it is about Gentoo and the perception someone had that Gentoo is dying, which has been claimed for many, many years now. Personally I like this graphic about gentoo being extinct. https://linuxfiend.wordpress.com/2009/12/05/is-gentoo-dying/
Re: [gentoo-user] sci-libs/scipy-1.1.0 fails to compile
On Thursday, 7 May 2020 14:31:41 BST Victor Ivanov wrote: > Hi all, > > For some reason SciPy fails to compile after today's Python 3.6 -> > Python 3.7 global update. It was the only package that failed out of all. > > Normally build.log (attached) is helpful enough to get me to resolve the > issue. However, it fails with a surprisingly unhelpful message during a > call to gfortran. Or maybe I'm unable to spot the proper error message. Isn't this the cause? x86_64-pc-linux-gnu-gcc: /var/tmp/portage/sci-libs/scipy-1.1.0/temp/tmpeyMzsQ/ source.c /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sci-libs/scipy-1.1.0/temp/ccGtNhqg.o: in function `main': source.c:(.text.startup+0x8c): undefined reference to `cblas_ddot' collect2: error: ld returned 1 exit status -- Regards, Peter.
Re: [gentoo-user] Daily update fails
On Thu May 7 10:04:37 2020, Dan Johansson wrote: > Today when I tried to do my daily "emerge --update ... @world", portage > spitted out a lot of "Multiple package instances within a single package > slot have been pulled" messages. So THIS would have been the issue you should have given us to solve. Instead you borked your package.use by globally deactivating py2.7 and asked us to point you to that. So please: Revert the python changes you did in your package.use, rerun your update command and post the error you get with that. Please post the whole output, including the exact command you used. And also add "--tree --verbose" to the emerge options, this usually requires less guessing. Thx Franz
Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, 6 May 2020 22:31:54 -0500, Dale wrote: > There used to be a package that caused some serious problems with > upgrades. It was really tricky but I can't recall the name of it since > it was ages ago. expat? I recall that causing some hair loss. -- Neil Bothwick "Ubuntu" is an ancient African word, meaning "I can't configure Slackware". pgpe_Y7voVbYu.pgp Description: OpenPGP digital signature
Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Thursday, May 7, 2020 6:35 AM, Rich Freeman wrote: > On Wed, May 6, 2020 at 10:14 PM Caveman Al Toraboran > toraboracave...@protonmail.com wrote: > > > are you referring to python's dependence on expat > > and glibc? > > More like bash's dependence. Well, and in the case of glibc just > about everything. When those break you're basically stuck recovering > from a rescue disk. or have sash somewhere around? > Fortunately we haven't had glibc/gcc break ABI in quite a while, and > preserved-rebuild covers a lot of the other issues. > > In any case, if you have a solution other than statically building > half the system I'm sure patches will be welcome. FWIW Gentoo is > about as hassle-free to use as it has ever been. It isn't debian > stable, and it is unlikely to ever be that way... why not? surely not as a 1st step, but it's not like 50% of the system apps are sacred or anything. imo right approach is this: 1. make portage statically linked. enjoy the removed python inconveniences. 2. if the bottleneck of inconvenience becomes bash's use glibc (a great milestone to celebrate btw), then we see how to fix that. 3. a component at a time, we eventually approach linux utopia. ``step (1) is not a utopia yet'' is no excuse to not start the journey of removing inconveniences.
Re: [gentoo-user] Daily update fails
On Thu, 7 May 2020 10:04:37 +0200, Dan Johansson wrote: > Today when I tried to do my daily "emerge --update ... @world", portage > spitted out a lot of "Multiple package instances within a single > package slot have been pulled" messages. > > I thought this could be due to the depreciation of python3_6 so I added > */* PYTHON_TARGETS: python3_6 python3_7 > */* PYTHON_SINGLE_TARGET: -* python3_6 > ,as per the news item published, to my package.use and now I get the > following instead: > > !!! The ebuild selected to satisfy "app-office/scribus" has unmet > requirements. > - app-office/scribus-1.5.5-r1::gentoo USE="boost minimal pdf templates > -debug -examples -graphicsmagick -hunspell -osg -scripts -tk" > ABI_X86="(64)" PYTHON_SINGLE_TARGET="-python2_7" > python_single_target_python2_7 >The following REQUIRED_USE flag constraints are unsatisfied: > python_single_target_python2_7 > >The above constraints are a subset of the following complete > expression: exactly-one-of ( python_single_target_python2_7 ) tk? ( > scripts ) > > I tried to unmerge scribus but that just made another package complain > about "python_single_target_python2_7". You have globally masked python_single_target_python2_7 in package.use, so now you need to unmask it for individual packages, starting with scribus. It's a bit of a game of whack-a-mole, add a package, emerge world, get another failure, add that package, rinse and repeat. I'd suggest putting all these changes in a separate file in package.use so it is easy(er) to track and undo these, hopefully, temporary, changed. I had no issues with the changeover on systems running purely testing, those running stable with a few testing packages required some attention. If you are running such a system, you may find it easier to temporarily unmask testing versions of some packages rather than play around with USE flags. -- Neil Bothwick Top Oxymorons Number 37: Sanitary landfill pgpKjBhQVpk98.pgp Description: OpenPGP digital signature
[gentoo-user] Daily update fails
Today when I tried to do my daily "emerge --update ... @world", portage spitted out a lot of "Multiple package instances within a single package slot have been pulled" messages. I thought this could be due to the depreciation of python3_6 so I added */* PYTHON_TARGETS: python3_6 python3_7 */* PYTHON_SINGLE_TARGET: -* python3_6 ,as per the news item published, to my package.use and now I get the following instead: !!! The ebuild selected to satisfy "app-office/scribus" has unmet requirements. - app-office/scribus-1.5.5-r1::gentoo USE="boost minimal pdf templates -debug -examples -graphicsmagick -hunspell -osg -scripts -tk" ABI_X86="(64)" PYTHON_SINGLE_TARGET="-python2_7" python_single_target_python2_7 The following REQUIRED_USE flag constraints are unsatisfied: python_single_target_python2_7 The above constraints are a subset of the following complete expression: exactly-one-of ( python_single_target_python2_7 ) tk? ( scripts ) I tried to unmerge scribus but that just made another package complain about "python_single_target_python2_7". Any suggestions on how to proceed? -- Dan Johansson, *** This message is printed on 100% recycled electrons! ***
Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Thursday, May 7, 2020 7:31 AM, Dale wrote: > Rich Freeman wrote: > > OP, odds are the emerge failure is what triggered the problem. If it had > completed without failure, it would likely have been a clean update. This is > why I set up a chroot and do my updates there and use the -k option to > install on my actual system. It takes very little time and so far, no > breakages on my real system. If any thing fails, it's more likely to be in > the chroot which won't hurt anything. If you able, may be a option worth > thinking about for yourself as well. > > Dale > > :-) :-) ya. i said it already. emerge's update failed with some package midways (some package needed some USE flag change), but then layman stopped working in this incomplete state. also the issue was simple. but i pointed out that the inconvenience of having a fancy dependency on a pms is still there.
Re: [gentoo-user] Is Gentoo dead?
On Thursday, 7 May 2020 04:50:41 BST Caveman Al Toraboran wrote: > On Thursday, May 7, 2020 7:31 AM, Dale wrote: > > Rich Freeman wrote: > > > > OP, odds are the emerge failure is what triggered the problem. If it had > > completed without failure, it would likely have been a clean update. This > > is why I set up a chroot and do my updates there and use the -k option to > > install on my actual system. It takes very little time and so far, no > > breakages on my real system. If any thing fails, it's more likely to be > > in the chroot which won't hurt anything. If you able, may be a option > > worth thinking about for yourself as well. > > > > Dale > > > > :-) :-) > > ya. i said it already. emerge's update failed > with some package midways (some package needed > some USE flag change), but then layman stopped > working in this incomplete state. > > also the issue was simple. but i pointed out that > the inconvenience of having a fancy dependency on > a pms is still there. Our portage sync cycles are different. I updated some python packages during yesterday's resync on a stable system. Today there was no packages needing update, but portage was unable to resolve layman: == These are the packages that would be merged, in order: Calculating dependencies \ !!! Problem resolving dependencies for app-portage/layman from @selected ... done! !!! The ebuild selected to satisfy "app-portage/layman" has unmet requirements. - app-portage/layman-2.4.2-r1::gentoo USE="git -cvs (-darcs) (-g-sorcery) -gpg -mercurial -sqlite -squashfs -subversion -sync-plugin-portage -test" PYTHON_TARGETS="-python3_6" The following REQUIRED_USE flag constraints are unsatisfied: python_targets_python3_6 The above constraints are a subset of the following complete expression: any-of ( python_targets_python3_6 ) === Python3.6 is still installed so layman works as intended and in the near future when >=layman-2.4.3 is stabilised in the tree, a regular update will resolve the above issue. Since neither layman nor portage are functionally borked, I don't perceive the above as a problem. Nevertheless, I followed the original thread with interest. Technology and programming languages evolve apace, so I understand a PMS running on python for decades may be deemed suboptimal today, if other more suitable solutions are now available. Unless someone skilled in those hypothetically better technologies rocks up and contributes, something I think most would welcome, I don't see the portage 'solution' moving away from python soon. I understand Paludis was such an endeavour, but its attempt to dethrone python didn't survive the test of time - or was it internal politics? I am less exercised regarding the static Vs dynamic libraries argument, which I also followed in the thread. I don't recall portage breaking here in what must have been hundreds of upgrades on mostly stable systems, for more than 17 years. What I'm saying is, it has worked for me and I thank the devs and maintainers for a job well done. :-) signature.asc Description: This is a digitally signed message part.
Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Thursday, May 7, 2020 5:43 AM, Rich Freeman wrote: > Are you overriding something, or were you running this right in the > middle of an update? emerge was updating, then some ebuild failed and i didn't have --keep-going. then next time i tried to sync layman it failed. i'm now re-running emerge and it seems to work normally. > > layman-2.4.2 strictly requires python 3.6 and the system wouldn't let > you remove that version of python unless you forced it to. The newer > version of layman is compatible with the newer versions of python, but > of course needs to be rebuilt for it. i have layman-2.4.3, emerged with python3_6, and is now about to be moved to python3_7. no biggie. i can fix it. but, my point is, this hassle is needless and keeps coming. > If you read the news on the update you'd see this. If you just do a > regular emerge -uD @world then while it was in the middle of updating > some things would break. There are instructions in the news for how > to do a more seamless upgrade by enabling both the older and newer > versions of python in parallel, in which case there won't be any point > where things break. That does require rebuilding everything twice > (not necessarily at the same time). true, but needless hassle imo. > Really though this is pretty tame. There have been some updates to > expat and especially glibc in the past that were pretty hairy. are you referring to python's dependence on expat and glibc? yeah, so many layers of mistakes get born when one relies on python as a dependency for a system app that manages other apps (including itself).
