Re: [gentoo-user] \ \ \ 2021 / / /
It's not quite the new year for everyone yet. Still got a little under 8
hours here. But still, I reciprocate. Happy new year everyone!
On 12/31/2020 9:26 AM, bobwxc wrote:
在 2020/12/25 下午7:00, Michael 写道:
On Thursday, 24 December 2020 20:11:19 GMT the...@sys-concept.com wrote:
{@} * {@} * {@} Merry X-mas and a Happy New Year!
{@} * {@} * {@} * {@} Wish you all extra ordinary good luck!
{@} * {@} * {@}
\ \ \ 2021 / / /
And thank you all for the help you trying to provide.
That is what distinguish Gentoo community from other forums.
Best festive wishes to all Gentoo users and devs! :-)
Now is 2021! Happy New Year!
Hope all of us and the world will get better in 2021.
--
Dan Egli
From my Test Server
Re: [gentoo-user] USE flag "unsupported" for "sci-libs/hdf5"
Hi, Le 31/12/20 à 17:54, Dr Rainer Woitok a tapoté : > Anybody having an educated guess what the risk would be? Is it save > to set a USE flag even if its name is "unsupported"? Full story here : https://bugs.gentoo.org/710986
[gentoo-user] USE flag "unsupported" for "sci-libs/hdf5"
Greetings, after having decided to globally set the "threads" USE flag I get the following: These are the packages that would be merged, in order: Calculating dependencies... done! !!! The ebuild selected to satisfy "sci-libs/hdf5[mpi]" has unmet requirements. - sci-libs/hdf5-1.10.5-r1::gentoo USE="fortran hl mpi threads zlib -cxx -debug -examples -szip -unsupported" ABI_X86="(64)" The following REQUIRED_USE flag constraints are unsatisfied: !unsupported? ( threads? ( !mpi !fortran !hl ) ) The above constraints are a subset of the following complete expression: !unsupported? ( at-most-one-of ( cxx mpi ) threads? ( !cxx !mpi !fortran !hl ) ) (dependency required by "sci-libs/flann-1.9.1-r3::gentoo[mpi]" [installed]) ... Since USE flag "mpi" is required by at least one other package, it seems I have exactly two options: - Set "-threads" for this package thus leaving everything as is, - set "unsupported" for this package, without really knowing what the consequences would be. Asking "equery" isn't really enlighting in this case, is it? $ equery --no-color --no-pipe uses sci-libs/hdf5 [ Legend : U - final flag setting for installation] [: I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sci-libs/hdf5-1.10.5-r1: U I - - cxx : Build support for C++ (bindings, extra libraries, code generation, ...) - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.ge ntoo.org/wiki/Project:Quality_Assurance/Backtraces - - examples: Install examples, usually source code + + fortran : Add support for fortran + + hl : Enable high level API (https://support.hdfgroup.org/HDF5/doc/HL/index.html) + + mpi : Add MPI (Message Passing Interface) layer to the apps that support it - - szip: Use the szip compression library + - threads : Add threads support for various packages. Usually pthreads - - unsupported : Enable unsupported combinations of configuration options + + zlib: Add support for zlib (de)compression $ Anybody having an educated guess what the risk would be? Is it save to set a USE flag even if its name is "unsupported"? Sincerely, Rainer
Re: [gentoo-user] \ \ \ 2021 / / /
在 2020/12/25 下午7:00, Michael 写道:
On Thursday, 24 December 2020 20:11:19 GMT the...@sys-concept.com wrote:
{@} * {@} * {@} Merry X-mas and a Happy New Year!
{@} * {@} * {@} * {@} Wish you all extra ordinary good luck!
{@} * {@} * {@}
\ \ \ 2021 / / /
And thank you all for the help you trying to provide.
That is what distinguish Gentoo community from other forums.
Best festive wishes to all Gentoo users and devs! :-)
Now is 2021! Happy New Year!
Hope all of us and the world will get better in 2021.
--
bobwxc
F645 5C7A 08E8 A637 24C6 D59E 36E9 4EAB B53E 516B
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-user] could there be a problem with acct-group/lp?
On 12/31/20 2:34 AM, n952162 wrote: cups was already installed. I considered removing it, but several other things, like ghostscript (!) are dependent on it. I'm using --keep-going for now. I suspect a bug in acct-group/lp that will get cleared up. If it's a bug in the acct-user eclass, it's a rare one. It would help if you could pin down the root cause. It's not something easy like "it fails if the user already exists." Every user and group ebuild is already at "-r1", which means they've been reinstalled at least once on most peoples' machines.
Re: [gentoo-user] could there be a problem with acct-group/lp?
On Thursday, 31 December 2020 09:31:13 GMT Neil Bothwick wrote: > On Thu, 31 Dec 2020 08:34:42 +0100, n952162 wrote: > > Why do you specify -1? That's the most common advice I get for avoiding > > slot-conflicts, but I can't imagine a system without cups. > > To avoid adding to your world file. If a package needs to be in @world, > it will already be there to -1 will be harmless. In the case of CUPS, you > don't want it in world as it is a dependency of any program that wants to > be able to print. Yes, what Neil sagely advised. :-) I suggest you make it a rule to always run emerge for any individual package atom with -1, unless you *really* intend to install such a package yourself and it has not been already installed as a dependency for other package(s). If you do not use -1 the package you emerge will be added in your world file and then you could end up fighting against portage sooner or later. Imagine a hypothetical scenario where one day CUPS is deprecated and replaced by the oh-so-marvellous latest and greatest CUPS-ng. You try to update your system, but come up against a blocker because the recently deprecated old CUPS now clashes with CUPS-ng. The old CUPS is in your world file, because you added it there by running emerge without -1 and consequently portage cannot override your choice and unmerge it to replace it with CUPS-ng. Portage will now throw a wobbly, alerting you to a blocker you must resolve yourself. This is why you were advised in previous messages related to the recent python updates to make sure among other things no python packages have inadvertently ended up in your world file. Unless you're a developer with specific python requirements, you would not want python which is both a @system set and potentially @world set dependency to end up in there. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] could there be a problem with acct-group/lp?
On Thu, 31 Dec 2020 08:20:22 +0100, n952162 wrote: > > Is this a new install or reinstall? All the logic is in the eclass > > which does have the comment "Creates the group if it does not exist." > > > > > I was looking for that ... I didn't find groupadd in > /var/db/pkg/acct-group/lp-0. Where should I look? As Jack said, it's in the eclass, $PORTDIR/eclass/acct-group.eclass -- Neil Bothwick Power corrupts - absolute power is even more fun. pgpoOQvp1W_Nk.pgp Description: OpenPGP digital signature
Re: [gentoo-user] could there be a problem with acct-group/lp?
On Thu, 31 Dec 2020 08:34:42 +0100, n952162 wrote: > Why do you specify -1? That's the most common advice I get for avoiding > slot-conflicts, but I can't imagine a system without cups. To avoid adding to your world file. If a package needs to be in @world, it will already be there to -1 will be harmless. In the case of CUPS, you don't want it in world as it is a dependency of any program that wants to be able to print. -- Neil Bothwick Those who live by the sword get shot by those who don't. pgpeDzk609B0a.pgp Description: OpenPGP digital signature
