* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-12 0:42 ` Alan Grimes
@ 2015-04-12 0:58 ` walt
2015-04-12 1:02 ` [gentoo-user] " Peter Humphrey
` (4 subsequent siblings)
5 siblings, 0 replies; 37+ messages in thread
From: walt @ 2015-04-12 0:58 UTC (permalink / raw
To: gentoo-user
On 04/11/2015 05:42 PM, Alan Grimes wrote:
> Byte me.
>
> Linux is crap, it takes all the talent I have to keep this piece of junk
> running.
I'll see your grumpy, and raise you two grumpies :p
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Machine completely broken; Ncursed!
2015-04-12 0:42 ` Alan Grimes
2015-04-12 0:58 ` [gentoo-user] " walt
@ 2015-04-12 1:02 ` Peter Humphrey
2015-04-12 1:58 ` Dale
` (3 subsequent siblings)
5 siblings, 0 replies; 37+ messages in thread
From: Peter Humphrey @ 2015-04-12 1:02 UTC (permalink / raw
To: gentoo-user
On Saturday 11 April 2015 20:42:20 Alan Grimes wrote:
> Linux is crap, it takes all the talent I have to keep this piece of junk
> running.
Just don't bother, and save the rest of us some earache.
[Apologies to those who recognised the troll.)
--
Rgds
Peter
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Machine completely broken; Ncursed!
2015-04-12 0:42 ` Alan Grimes
2015-04-12 0:58 ` [gentoo-user] " walt
2015-04-12 1:02 ` [gentoo-user] " Peter Humphrey
@ 2015-04-12 1:58 ` Dale
2015-04-12 9:12 ` J. Roeleveld
` (2 subsequent siblings)
5 siblings, 0 replies; 37+ messages in thread
From: Dale @ 2015-04-12 1:58 UTC (permalink / raw
To: gentoo-user
Alan Grimes wrote:
> Andreas K. Huettel wrote:
>
>> If you kept your system updated all the time, you shouldnt have any
>> problems.
> Byte me.
>
> Linux is crap, it takes all the talent I have to keep this piece of junk
> running. =( I'm the user here, I am not going to take any lip from you
> about how I run my system. =| I put a great deal more work into
> maintaining my system than most of the rest of you.
>
>
Gentoo is not like binary systems. Most binary systems, you can upgrade
even after years of not doing any upgrading. Gentoo doesn't like that.
Officially Gentoo is supposed to have a upgrade max of one year. Thing
is, that depends on what changes has taken place in that year. There
are times when some major changes happen and even if it hasn't been 6
months since a upgrade/update, a person is just as well off to reinstall
and keep their sanity. That could vary depending on how complex some
things may be to set up again.
So, if you plan to use Gentoo, keeping a system fairly up to date is the
best way to avoid having to deal with some problems that leave you
kicking and screaming for mercy. I've found that once a week does
fairly well. Some on this list have posted they go a month.
Hope that helps.
Dale
:-) :-)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Machine completely broken; Ncursed!
2015-04-12 0:42 ` Alan Grimes
` (2 preceding siblings ...)
2015-04-12 1:58 ` Dale
@ 2015-04-12 9:12 ` J. Roeleveld
2015-04-12 17:23 ` [gentoo-user] " »Q«
2015-04-12 9:31 ` [gentoo-user] " Neil Bothwick
2015-04-12 14:13 ` Andreas K. Huettel
5 siblings, 1 reply; 37+ messages in thread
From: J. Roeleveld @ 2015-04-12 9:12 UTC (permalink / raw
To: gentoo-user
On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
> Andreas K. Huettel wrote:
<snipped>
> > > 2. LD cannot find ncurses, -- It simply can't, in 64 bit mode either.
> > > That is the only error message it ever gives and vast amount of effort
> > > spent in sessions over the last year and a half have failed to find any
> > > solution. I only installed Gentoo on this machine four and a half years
> > > ago so it's hard to imagine what could have gotten this royally foobar
> > > in such a short period.
> >
> > If you kept your system updated all the time, you shouldnt have any
> > problems.
>
> Byte me.
>
> Linux is crap, it takes all the talent I have to keep this piece of junk
> running. =( I'm the user here, I am not going to take any lip from you
> about how I run my system. =| I put a great deal more work into
> maintaining my system than most of the rest of you.
If that is your opinion of Linux, why use it?
> > > The ncurses problem has been a low-level
> > > issue for a long time but, with tinfo set, 99% of packages worked.
> >
> > Define low-level issue. What was broken all the time that you ignored?
>
> Busybox, valgrind, a number of other minor packages.
Cause for these is in your make.conf, see below.
> > > 2. It sent out a profile that sets variable ABI_x86 with 32 bit enabled.
> > > ALARM: ABI_x86 should be set in exactly one place:
> > > /etc/portage/make.conf and nowhere else. But, nevertheless, ABI_x86 WAS
> > > set which broke the profile because my system cannot compile 32 bit
> > > executables. =( I tried the no-multilib profile but it didn't have a
> > > number of essential useflags and was foobar.
> >
> > You're still not providing the slightest bit of useful information.
> >
> > What happens if you try to generate a 32bit executable?
>
> Fails completely due to linking errors even though it should always be
> possible to compile something without its binary dependencies (with only
> the headers) because symbol resolution should take place at load time. =|
Cause is in your make.conf. See below.
> > What gcc are you using, with what settings?
>
> By all appearances, Emerge identifies the most broken version of
> everything it can find and uses that without providing any user feedback.
Cause is in your make.conf. See below.
> Here's my make.conf, some lines might be changed because I have been
> struggling to find a working configuration.
>
>
> /etc/portage # cat /etc/portage/make.conf
> # These settings were set by the catalyst build script that automatically
> # built this stage.
> # Please consult /usr/share/portage/config/make.conf.example for a more
> # detailed example.
> CFLAGS="-O3 -march=native -pipe "
Most people tend to put -O2. Not much point to use -O3.
> CXXFLAGS="${CFLAGS}"
>
> LDFLAGS="-lncurses "
You're forcing ncurses into every single package. Please remove this.
> MAKEOPTS="-j 6"
>
> # WARNING: Changing your CHOST is not something that should be done lightly.
> # Please consult http://www.gentoo.org/doc/en/change-chost.xml before
> changing.
> CHOST="x86_64-pc-linux-gnu"
>
> INPUT_DEVICES="keyboard mouse"
>
> LINGUAS="en en_US"
> ACCEPT_KEYWORDS="amd64 ~amd64"
You are running "unstable". This requires more effort on your part.
I would suggest switching back to "stable", eg. loose the " ~amd64 ".
NOTE: You either need to spend a lot of effort to bring everything back to
stable over time (see the archives) or start with a fresh installation.
> ACCEPT_LICENSE="*"
>
> # These are the USE flags that were used in addition to what is provided
> by the
> # profile used for building.
> USE="3dnow 3dnowext amr apache2 ares audiofile autoipd avahi bittorrent
> blender-game bmp boost c++0x caps cdio cg cgi clang cpudetection
> css curl
> custom-cflags custom-tune debugger declarative device-mapper dga
> discouraged dolbyinrec double-precision drm evdev expat extras fbcon
> ffcall ffmpeg fftw firmware fluidsynth fontconfig foomaticdb freeimage
> ftp g3dvl gbm gflags gfortran ggz gl glade glut gmp gnome gphoto2
> graphviz gsl gstreamer gtk3 heterogeneous high-ints hpijs hwdb icu ide
> imlib ithreads jadetex java jit joystick jpeg2k kde kdrive lame lapack
> libffi libkms libwww llvm-shared-libs lm_sensors lua lzo matroska
> mdnsresponder-compat metis midi minizip mmap mms mmxext mozilla mp3rtp
> mpeg2 multicore multilib multislot mysql nas natspec netpbm nowin
> nsplugin ode ogre ois okteta openal opencl openexr openssl opus orc pae
> parport pch pcre16 perl pgo plasma posix postproc povray
> private-headers
> pulseaudio python python3 qml qthelp quicktime r600-llvm-compiler
> reiserfs script sdk seamonkey secure-delete semantic-desktop server
> sftp
> sip smp soprano sql sqlite sse2 sse3 sse4 static-ppds subversion
> system-boost system-cairo system-icu system-jpeg system-libvpx
> system-sqlite t1lib theora threads threadsafe threadsonly tk
> unlock-notify upnp upnp-av userlocales utempter uuid uvm uxa v4l vcd
> video videos vnc webkit xine xmp xvfb xvmc yuv4mpeg zeroconf -bluetooth
> -bundled-libs -dso -examples -libav -odbc -samba -vlc tinfo"
Why do you add all these USE-flags into your make.conf?
Have you heard about "package.use" ?
> CPU_FLAGS_X86="mmx mmxext sse2_4way 3dnow 3dnowext sse sse2 sse3 sse4"
>
> RUBY_TARGETS="ruby20 ruby21 ruby22 ruby24"
These are set in your profile, please do not override this.
In other words, please remove this line.
> GRUB_PLATFORMS="pc efi-64"
>
> EMERGE_DEFAULT_OPTS="--jobs=1 --quiet-build=n --verbose"
>
> FEATURES="sandbox distlocks nostrip parallel-fetch userfetch userpriv
> usersandbox splitdebug -preserve-libs"
>
> PORTAGE_RSYNC_EXTRA_OPTS="--progress"
>
> VIDEO_CARDS="nvidia radeonsi radeon"
>
> source /var/lib/layman/make.conf
>
> PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
> PYTHON_SINGLE_TARGET="python2_7"
These are set in your profile, please do not override this.
In other words, please remove these 2 lines.
> ABI_X86="64 32"
>
> GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/"
>
> /etc/portage #
>
>
> Hmm, I don't remember when that ldflags got set, must have been a long
> time ago. =\
With the make.conf the way you set it, you caused all the breakages you have
been experiencing.
--
Joost
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-12 9:12 ` J. Roeleveld
@ 2015-04-12 17:23 ` »Q«
2015-04-12 18:35 ` Matti Nykyri
2015-04-12 20:07 ` J. Roeleveld
0 siblings, 2 replies; 37+ messages in thread
From: »Q« @ 2015-04-12 17:23 UTC (permalink / raw
To: gentoo-user
On Sun, 12 Apr 2015 11:12:38 +0200
"J. Roeleveld" <joost@antarean.org> wrote:
> On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
> > PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
> > PYTHON_SINGLE_TARGET="python2_7"
>
> These are set in your profile, please do not override this.
> In other words, please remove these 2 lines.
I'm not the OP. (I spend less time than him on maintaining my system.)
Should those variables really not be set in make.conf? I added them to
make.conf some time back because portage complained about them, and if I
comment them out, it complains again, like so:
$ emerge -puDv --changed-use @world
These are the packages that would be merged, in order:
Calculating dependencies |
!!! Problem resolving dependencies for sys-apps/util-linux from @system
... done!
!!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet requirements.
- sys-apps/util-linux-2.25.2-r2::gentoo USE="ncurses nls pam (policykit) python suid tty-helpers udev unicode -caps -cramfs -fdformat (-selinux) -slang -static-libs -systemd -test" ABI_X86="64 -32 -x32" PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4" PYTHON_TARGETS="-python2_7 -python3_3 -python3_4"
The following REQUIRED_USE flag constraints are unsatisfied:
python? ( exactly-one-of ( python_single_target_python3_3 python_single_target_python3_4 python_single_target_python2_7 ) )
The above constraints are a subset of the following complete expression:
python? ( exactly-one-of ( python_single_target_python3_3 python_single_target_python3_4 python_single_target_python2_7 ) python_single_target_python3_3? ( python_targets_python3_3 ) python_single_target_python3_4? ( python_targets_python3_4 ) python_single_target_python2_7? ( python_targets_python2_7 ) )
(dependency required by "@system" [set])
(dependency required by "@world" [argument])
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-12 17:23 ` [gentoo-user] " »Q«
@ 2015-04-12 18:35 ` Matti Nykyri
2015-04-13 1:07 ` »Q«
2015-04-12 20:07 ` J. Roeleveld
1 sibling, 1 reply; 37+ messages in thread
From: Matti Nykyri @ 2015-04-12 18:35 UTC (permalink / raw
To: gentoo-user@lists.gentoo.org
> On Apr 12, 2015, at 20:23, »Q« <boxcars@gmx.net> wrote:
>
> On Sun, 12 Apr 2015 11:12:38 +0200
> "J. Roeleveld" <joost@antarean.org> wrote:
>
>> On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
>
>>> PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
>>> PYTHON_SINGLE_TARGET="python2_7"
>>
>> These are set in your profile, please do not override this.
>> In other words, please remove these 2 lines.
>
> I'm not the OP. (I spend less time than him on maintaining my system.)
>
> Should those variables really not be set in make.conf? I added them to
> make.conf some time back because portage complained about them, and if I
> comment them out, it complains again, like so:
>
> $ emerge -puDv --changed-use @world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies |
>
> !!! Problem resolving dependencies for sys-apps/util-linux from @system
> ... done!
>
> !!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet requirements.
> - sys-apps/util-linux-2.25.2-r2::gentoo USE="ncurses nls pam (policykit) python suid tty-helpers udev unicode -caps -cramfs -fdformat (-selinux) -slang -static-libs -systemd -test" ABI_X86="64 -32 -x32" PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4" PYTHON_TARGETS="-python2_7 -python3_3 -python3_4"
>
> The following REQUIRED_USE flag constraints are unsatisfied:
> python? ( exactly-one-of ( python_single_target_python3_3 python_single_target_python3_4 python_single_target_python2_7 ) )
>
> The above constraints are a subset of the following complete expression:
> python? ( exactly-one-of ( python_single_target_python3_3 python_single_target_python3_4 python_single_target_python2_7 ) python_single_target_python3_3? ( python_targets_python3_3 ) python_single_target_python3_4? ( python_targets_python3_4 ) python_single_target_python2_7? ( python_targets_python2_7 ) )
>
> (dependency required by "@system" [set])
> (dependency required by "@world" [argument])
This is because you have set the "python" use flag in your make.conf (or package.use).
Remove the python useflag and the problem goes away. It is not set by the profile but by you. Do you really need it?
--
-Matti
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-12 18:35 ` Matti Nykyri
@ 2015-04-13 1:07 ` »Q«
2015-04-13 5:48 ` Alan McKinnon
0 siblings, 1 reply; 37+ messages in thread
From: »Q« @ 2015-04-13 1:07 UTC (permalink / raw
To: gentoo-user
On Sun, 12 Apr 2015 21:35:07 +0300
Matti Nykyri <matti.nykyri@iki.fi> wrote:
> > On Apr 12, 2015, at 20:23, »Q« <boxcars@gmx.net> wrote:
> >
> > On Sun, 12 Apr 2015 11:12:38 +0200
> > "J. Roeleveld" <joost@antarean.org> wrote:
> >
> >> On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
> >
> >>> PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
> >>> PYTHON_SINGLE_TARGET="python2_7"
> >>
> >> These are set in your profile, please do not override this.
> >> In other words, please remove these 2 lines.
> >
> > I'm not the OP. (I spend less time than him on maintaining my
> > system.)
> >
> > Should those variables really not be set in make.conf? I added
> > them to make.conf some time back because portage complained about
> > them, and if I comment them out, it complains again, like so:
> > The following REQUIRED_USE flag constraints are unsatisfied:
> > python? ( exactly-one-of ( python_single_target_python3_3
> > python_single_target_python3_4 python_single_target_python2_7 ) )
[snip]
> This is because you have set the "python" use flag in your make.conf
> (or package.use).
>
> Remove the python useflag and the problem goes away. It is not set by
> the profile but by you. Do you really need it?
I enabled it globally (in make.conf), but I think I only need it for one
or two packages. If I remove it from USE, I get portage complaining
about other things.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 1:07 ` »Q«
@ 2015-04-13 5:48 ` Alan McKinnon
2015-04-14 2:08 ` »Q«
0 siblings, 1 reply; 37+ messages in thread
From: Alan McKinnon @ 2015-04-13 5:48 UTC (permalink / raw
To: gentoo-user
On 13/04/2015 03:07, »Q« wrote:
> On Sun, 12 Apr 2015 21:35:07 +0300
> Matti Nykyri <matti.nykyri@iki.fi> wrote:
>
>>> On Apr 12, 2015, at 20:23, »Q« <boxcars@gmx.net> wrote:
>>>
>>> On Sun, 12 Apr 2015 11:12:38 +0200
>>> "J. Roeleveld" <joost@antarean.org> wrote:
>>>
>>>> On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
>>>
>>>>> PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
>>>>> PYTHON_SINGLE_TARGET="python2_7"
>>>>
>>>> These are set in your profile, please do not override this.
>>>> In other words, please remove these 2 lines.
>>>
>>> I'm not the OP. (I spend less time than him on maintaining my
>>> system.)
>>>
>>> Should those variables really not be set in make.conf? I added
>>> them to make.conf some time back because portage complained about
>>> them, and if I comment them out, it complains again, like so:
>
>>> The following REQUIRED_USE flag constraints are unsatisfied:
>>> python? ( exactly-one-of ( python_single_target_python3_3
>>> python_single_target_python3_4 python_single_target_python2_7 ) )
>
> [snip]
>
>> This is because you have set the "python" use flag in your make.conf
>> (or package.use).
>>
>> Remove the python useflag and the problem goes away. It is not set by
>> the profile but by you. Do you really need it?
>
> I enabled it globally (in make.conf), but I think I only need it for one
> or two packages. If I remove it from USE, I get portage complaining
> about other things.
>
>
USE="python" is one of those flags that has no accurate meaning in real
life, and the user needs to make an informed decision. It doesn't work
like USE="sse" for example, which means packages that can use the sse
instruction set will compile for it. It's a fairly exact meaning.
USE="python" means "use python to do stuff" but stuff is not defined and
it's usually hard to find out what it is for a given package. For some
it means to build optional extra tools that run under python, for some
it means to create python language bindings, and for others it could
even mean some critical system function that is implemented in python
and eats your kittens if not enabled. (sort of like how portage is
implemented in python; there's no USE for it but you get the idea).
Usually, USE="python" should be set per-package if you need what it
does. I had it in make.conf myself in my early days and kept getting
into circular dependencies. Sorting that out took some effort.
Portage will almost certainly complain if you take something with
far-reaching effects as USE="python" in make.conf and remove it.
So, take each thing it is complaining about and enable or disable it
based on what you need. Tweak as necessary to get the result you want.
--
Alan McKinnon
alan.mckinnon@gmail.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 5:48 ` Alan McKinnon
@ 2015-04-14 2:08 ` »Q«
0 siblings, 0 replies; 37+ messages in thread
From: »Q« @ 2015-04-14 2:08 UTC (permalink / raw
To: gentoo-user
On Mon, 13 Apr 2015 07:48:25 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 13/04/2015 03:07, »Q« wrote:
> > On Sun, 12 Apr 2015 21:35:07 +0300
> > Matti Nykyri <matti.nykyri@iki.fi> wrote:
> >
> >>> On Apr 12, 2015, at 20:23, »Q« <boxcars@gmx.net> wrote:
> >>>
> >>> On Sun, 12 Apr 2015 11:12:38 +0200
> >>> "J. Roeleveld" <joost@antarean.org> wrote:
> >>>
> >>>> On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
> >>>
> >>>>> PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
> >>>>> PYTHON_SINGLE_TARGET="python2_7"
> >>>>
> >>>> These are set in your profile, please do not override this.
> >>>> In other words, please remove these 2 lines.
> >>>
> >>> I'm not the OP. (I spend less time than him on maintaining my
> >>> system.)
> >>>
> >>> Should those variables really not be set in make.conf? I added
> >>> them to make.conf some time back because portage complained about
> >>> them, and if I comment them out, it complains again, like so:
> >
> >>> The following REQUIRED_USE flag constraints are unsatisfied:
> >>> python? ( exactly-one-of ( python_single_target_python3_3
> >>> python_single_target_python3_4 python_single_target_python2_7 ) )
> >
> > [snip]
> >
> >> This is because you have set the "python" use flag in your
> >> make.conf (or package.use).
> >>
> >> Remove the python useflag and the problem goes away. It is not set
> >> by the profile but by you. Do you really need it?
> >
> > I enabled it globally (in make.conf), but I think I only need it
> > for one or two packages. If I remove it from USE, I get portage
> > complaining about other things.
>
>
> USE="python" is one of those flags that has no accurate meaning in
> real life, and the user needs to make an informed decision. It
> doesn't work like USE="sse" for example, which means packages that
> can use the sse instruction set will compile for it. It's a fairly
> exact meaning.
>
> USE="python" means "use python to do stuff" but stuff is not defined
> and it's usually hard to find out what it is for a given package. For
> some it means to build optional extra tools that run under python,
> for some it means to create python language bindings, and for others
> it could even mean some critical system function that is implemented
> in python and eats your kittens if not enabled. (sort of like how
> portage is implemented in python; there's no USE for it but you get
> the idea).
>
> Usually, USE="python" should be set per-package if you need what it
> does. I had it in make.conf myself in my early days and kept getting
> into circular dependencies. Sorting that out took some effort.
>
> Portage will almost certainly complain if you take something with
> far-reaching effects as USE="python" in make.conf and remove it.
>
> So, take each thing it is complaining about and enable or disable it
> based on what you need. Tweak as necessary to get the result you want.
Thanks -- that all makes sense. I'm pretty sure I have USE="python"
because I thought something like "I'm going to have python, so I might
as well let things use it", which I now see to be muddle-headed at
best.
Since it's not causing me any troubles for now, I'll wean myself off of
USE="python" when there's some in which I can afford to fix whatever I
break during the process.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-12 17:23 ` [gentoo-user] " »Q«
2015-04-12 18:35 ` Matti Nykyri
@ 2015-04-12 20:07 ` J. Roeleveld
2015-04-13 1:15 ` »Q«
1 sibling, 1 reply; 37+ messages in thread
From: J. Roeleveld @ 2015-04-12 20:07 UTC (permalink / raw
To: gentoo-user
On Sunday, April 12, 2015 12:23:56 PM »Q« wrote:
> On Sun, 12 Apr 2015 11:12:38 +0200
>
> "J. Roeleveld" <joost@antarean.org> wrote:
> > On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
> > > PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
> > > PYTHON_SINGLE_TARGET="python2_7"
> >
> > These are set in your profile, please do not override this.
> > In other words, please remove these 2 lines.
>
> I'm not the OP. (I spend less time than him on maintaining my system.)
>
> Should those variables really not be set in make.conf? I added them to
> make.conf some time back because portage complained about them, and if I
> comment them out, it complains again, like so:
>
> $ emerge -puDv --changed-use @world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies |
>
> !!! Problem resolving dependencies for sys-apps/util-linux from @system
> ... done!
>
> !!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet
> requirements. - sys-apps/util-linux-2.25.2-r2::gentoo USE="ncurses nls pam
> (policykit) python suid tty-helpers udev unicode -caps -cramfs -fdformat
> (-selinux) -slang -static-libs -systemd -test" ABI_X86="64 -32 -x32"
> PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4"
> PYTHON_TARGETS="-python2_7 -python3_3 -python3_4"
>
> The following REQUIRED_USE flag constraints are unsatisfied:
> python? ( exactly-one-of ( python_single_target_python3_3
> python_single_target_python3_4 python_single_target_python2_7 ) )
>
> The above constraints are a subset of the following complete expression:
> python? ( exactly-one-of ( python_single_target_python3_3
> python_single_target_python3_4 python_single_target_python2_7 )
> python_single_target_python3_3? ( python_targets_python3_3 )
> python_single_target_python3_4? ( python_targets_python3_4 )
> python_single_target_python2_7? ( python_targets_python2_7 ) )
>
> (dependency required by "@system" [set])
> (dependency required by "@world" [argument])
I have never set them and don't remember having an issue.
From the above, it looks like they are all unset when you remove that line.
Which profile are you using?
And what is the rest of your make.conf?
--
Joost
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-12 20:07 ` J. Roeleveld
@ 2015-04-13 1:15 ` »Q«
2015-04-13 1:24 ` Alec Ten Harmsel
0 siblings, 1 reply; 37+ messages in thread
From: »Q« @ 2015-04-13 1:15 UTC (permalink / raw
To: gentoo-user
On Sun, 12 Apr 2015 22:07:20 +0200
"J. Roeleveld" <joost@antarean.org> wrote:
> On Sunday, April 12, 2015 12:23:56 PM »Q« wrote:
> > On Sun, 12 Apr 2015 11:12:38 +0200
> >
> > "J. Roeleveld" <joost@antarean.org> wrote:
> > > On Saturday, April 11, 2015 08:42:20 PM Alan Grimes wrote:
> > > > PYTHON_TARGETS="${PYTHON_TARGETS} python2_7 python3_4"
> > > > PYTHON_SINGLE_TARGET="python2_7"
> > >
> > > These are set in your profile, please do not override this.
> > > In other words, please remove these 2 lines.
> >
> > I'm not the OP. (I spend less time than him on maintaining my
> > system.)
> >
> > Should those variables really not be set in make.conf? I added
> > them to make.conf some time back because portage complained about
> > them, and if I comment them out, it complains again, like so:
[snip]
> > The following REQUIRED_USE flag constraints are unsatisfied:
> > python? ( exactly-one-of ( python_single_target_python3_3
> > python_single_target_python3_4 python_single_target_python2_7 ) )
> I have never set them and don't remember having an issue.
>
> From the above, it looks like they are all unset when you remove that
> line.
I think that's right.
> Which profile are you using?
default/linux/amd64/13.0/desktop/kde
> And what is the rest of your make.conf?
Before you pore through it, I guess I should point out that it's not
causing me any problems -- I was just curious about why it would be a
bad idea for me to manage those PYTHON_* variables myself. I guess the
most notable thing about my make.conf is that I'm one of those crazy
USE="-*" people.
$ cat /etc/portage/make.conf
# Please consult /usr/share/portage/config/make.conf.example for a detailed example.
CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# weird load averages, maybe this will help
# 7.2 used to be right
MAKEOPTS="--jobs=8 --load-average=11.2"
PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"
PORT_LOGDIR="/var/log/portage"
# layman expands and empty variable, then we postpend
# the main tree to it. This should give the main tree
# precendence.
PORTDIR_OVERLAY=""
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="$PORTDIR_OVERLAY $PORTDIR"
PORTAGE_ELOG_CLASSES="info warn error"
PORTAGE_ELOG_SYSTEM="echo:warn,error save"
PORTAGE_SYNC_STALE=10
FEATURES="binpkg-logs buildsyspkg collision-protect downgrade-backup
fail-clean fixlafiles news parallel-fetch parallel-install
preserve-libs sandbox strict unknown-features-warn userfetch
userpriv usersandbox usersync"
# see note above about MAKEOPTS
EMERGE_DEFAULT_OPTS="--ask-enter-invalid --jobs=8 --load-average 11.2 --with-bdeps y"
LINGUAS="en_US en"
ABI_X86="64"
CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3"
GRUB_PLATFORMS="efi-64"
PYTHON_TARGETS="python2_7 python3_4"
USE_PYTHON="2.7"
PYTHON_SINGLE_TARGET="python2_7"
RUBY_TARGETS="ruby20"
CURL_SSL="openssl"
CALLIGRA_FEATURES="author braindump flow karbon kexi krita plan sheets stage words"
INPUT_DEVICES="evdev mouse keyboard synaptics"
# **** need to add the intel card ****
VIDEO_CARDS="intel i965 v4l vesa"
#VIDEO_CARDS="nvidia v4l vesa"
# without this, grub:0 ebuilds mess with /boot
DONT_MOUNT_BOOT=1
USE="-* 64bit X a52 aac aalib accessibility acl acpi additions agg alsa apng
archive asf aspell audio aura avahi avcodec avformat avx bash-completion
bluetooth bookmarks boost branding bzip2 cairo calendar canlock cdda cddb
cdio cdparanoia cdr center-tilde chatzilla chert city classic clucene
color colordiff consolekit cover cracklib crypt cryptsetup css cups curl
cxx dbus declarative dga dillo distinct-l dri dts dvd dvdr edit eigen
encode exif expat extensions extra-cardsets extraengine fam fbcon ffmpeg
filters flac fluidsynth fontconfig fontforge foomatic foomaticdb fortran
ftp gdbm gif glew glib gmp gnutls gost gpl gpm graphviz gstreamer gudev
handbook hbci hddtemp holidays hwdb iconv icu id3tag idn imagemagick imap
inotify input_uvc int-quality ipc ipv6 isag javascript jit joystick jpeg
json kde kdenlive kdepim kerberos kipi kmod ladspa lame lcms libass libev
libkms libnotify libsecret libvisual lm_sensors lzma mad magic matroska
mdnsresponder-compat melt midi mikmod minizip mjpeg mmx mmxext mng mod
modplug mouse mp3 mp4 mpd mpeg mplayer mudflap musepack musicbrainz mysql
nano-syntax natspec ncurses netifrc nls nntp nptl nsplugin ntfsprogs
offensive offlinehelp ofx ogg okular opengl openmp openrc openssl opus
orc output_autofocus output_file output_http output_rtsp output_udp pam
pcf pci pcre pdf perl pm-utils png policykit portmon postproc psf ptpax
pyqt4 python2 qt3support qt4 quicktime raptor readline recursion-limit
redland rss rtc sasl script scripts sdk sdl sdl-image sdl-sound
secure-delete security semantic-desktop sensord session sha512
shared-glapi shorten skins smime smp sna soprano sound spell sql sqlite
sse sse2 sse3 sse4_1 ssl ssse3 startup-notification stereo stl svg
swscale symlink syslog system-cairo system-icu system-jpeg system-libvpx
taglib tcpd themes theora threads thumbnail tiff tk tls-heartbeat tremor
truetype tty-helpers udev udisks unicode units_cur upower usb uudeview
v4l vaapi vamp vcd vcdx vdpau video virtuoso vlm vorbis wav weather-metar
weather-xoap webdav webgl webkit wifi xcb xface xml xorg xosd xpm
xscreensaver xv xvfb xvmc yaml zeroconf zlib -cacert -libav"
# The SYNC variable is deprecated (2014 Sept). See man 5 portage for info
# about sync-type and sync-uri, both for repos.conf
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
GENTOO_MIRRORS="http://gentoo.cites.uiuc.edu/pub/gentoo/ http://gentoo.mirrors.easynews.com/linux/gentoo/ http://mirror.lug.udel.edu/pub/gentoo/"
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 1:15 ` »Q«
@ 2015-04-13 1:24 ` Alec Ten Harmsel
2015-04-13 1:38 ` »Q«
0 siblings, 1 reply; 37+ messages in thread
From: Alec Ten Harmsel @ 2015-04-13 1:24 UTC (permalink / raw
To: gentoo-user
On 04/12/2015 09:15 PM, »Q« wrote:
>
> Before you pore through it, I guess I should point out that it's not
> causing me any problems -- I was just curious about why it would be a
> bad idea for me to manage those PYTHON_* variables myself. I guess the
> most notable thing about my make.conf is that I'm one of those crazy
> USE="-*" people.
>
It's not a bad idea to manage the PYTHON_TARGETS, PYTHON_SINGLE_TARGET,
and RUBY_TARGET variables if you *need* a specific version of python or
ruby. If you do not, I would say it is bad. These are set in the profile
so that the maintainers can decide when to update to a new stable
version. Since all of the various python and ruby libraries are
installed from source, it's generally a good idea to wait for the
maintainers to stabilize a certain version since that means the library
support is also good.
Also, using the KDE profile and having USE="-*" seem contrary. One of
the main reasons to use a profile is to get a relevant set of USE flags.
Alec
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 1:24 ` Alec Ten Harmsel
@ 2015-04-13 1:38 ` »Q«
2015-04-13 1:52 ` Alec Ten Harmsel
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: »Q« @ 2015-04-13 1:38 UTC (permalink / raw
To: gentoo-user
On Sun, 12 Apr 2015 21:24:48 -0400
Alec Ten Harmsel <alec@alectenharmsel.com> wrote:
> On 04/12/2015 09:15 PM, »Q« wrote:
> >
> > Before you pore through it, I guess I should point out that it's not
> > causing me any problems -- I was just curious about why it would be
> > a bad idea for me to manage those PYTHON_* variables myself. I
> > guess the most notable thing about my make.conf is that I'm one of
> > those crazy USE="-*" people.
>
> It's not a bad idea to manage the PYTHON_TARGETS,
> PYTHON_SINGLE_TARGET, and RUBY_TARGET variables if you *need* a
> specific version of python or ruby. If you do not, I would say it is
> bad. These are set in the profile so that the maintainers can decide
> when to update to a new stable version. Since all of the various
> python and ruby libraries are installed from source, it's generally a
> good idea to wait for the maintainers to stabilize a certain version
> since that means the library support is also good.
How can I find out whether the profile is setting those variables?
ISTM the emerge errors I posted earlier, which happen if I get rid of
those variables in make.conf, indicate that they are not being set at
all.
When a new version of python (or ruby, I guess) is stabilized, I do
have to spend some time making sure those variables are sanely set, and
I'd rather just leave it up to the devs.
> Also, using the KDE profile and having USE="-*" seem contrary. One of
> the main reasons to use a profile is to get a relevant set of USE
> flags.
I don't want the profile's USE flags, but I still thought it best to
select the profile that matches what I use the machine for.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 1:38 ` »Q«
@ 2015-04-13 1:52 ` Alec Ten Harmsel
2015-04-14 1:55 ` »Q«
2015-04-13 5:52 ` Alan McKinnon
2015-04-13 7:51 ` Neil Bothwick
2 siblings, 1 reply; 37+ messages in thread
From: Alec Ten Harmsel @ 2015-04-13 1:52 UTC (permalink / raw
To: gentoo-user
On 04/12/2015 09:38 PM, »Q« wrote:
> On Sun, 12 Apr 2015 21:24:48 -0400
> Alec Ten Harmsel <alec@alectenharmsel.com> wrote:
>
>> On 04/12/2015 09:15 PM, »Q« wrote:
>>> Before you pore through it, I guess I should point out that it's not
>>> causing me any problems -- I was just curious about why it would be
>>> a bad idea for me to manage those PYTHON_* variables myself. I
>>> guess the most notable thing about my make.conf is that I'm one of
>>> those crazy USE="-*" people.
>> It's not a bad idea to manage the PYTHON_TARGETS,
>> PYTHON_SINGLE_TARGET, and RUBY_TARGET variables if you *need* a
>> specific version of python or ruby. If you do not, I would say it is
>> bad. These are set in the profile so that the maintainers can decide
>> when to update to a new stable version. Since all of the various
>> python and ruby libraries are installed from source, it's generally a
>> good idea to wait for the maintainers to stabilize a certain version
>> since that means the library support is also good.
> How can I find out whether the profile is setting those variables?
> ISTM the emerge errors I posted earlier, which happen if I get rid of
> those variables in make.conf, indicate that they are not being set at
> all.
You can find all the defaults here:
/usr/portage/profiles/base/make.defaults. I don't think the KDE profile
overrides any of the python/ruby stuff, just USE. It's strange that you
are getting that error from util-linux; I would recommend getting rid of
the USE_PYTHON="2.7" line from make.conf and, personally, avoid having
so many USE flags in make.conf.
Alec
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 1:52 ` Alec Ten Harmsel
@ 2015-04-14 1:55 ` »Q«
0 siblings, 0 replies; 37+ messages in thread
From: »Q« @ 2015-04-14 1:55 UTC (permalink / raw
To: gentoo-user
On Sun, 12 Apr 2015 21:52:07 -0400
Alec Ten Harmsel <alec@alectenharmsel.com> wrote:
> On 04/12/2015 09:38 PM, »Q« wrote:
> > How can I find out whether the profile is setting those variables?
> > ISTM the emerge errors I posted earlier, which happen if I get rid
> > of those variables in make.conf, indicate that they are not being
> > set at all.
>
> You can find all the defaults here:
> /usr/portage/profiles/base/make.defaults. I don't think the KDE
> profile overrides any of the python/ruby stuff, just USE. It's
> strange that you are getting that error from util-linux; I would
> recommend getting rid of the USE_PYTHON="2.7" line from make.conf
> and, personally, avoid having so many USE flags in make.conf.
Thanks. My /usr/portage/profiles/base/make.defaults has
PYTHON_TARGETS="python2_7 python3_3"
PYTHON_SINGLE_TARGET="python2_7"
The error message was
The following REQUIRED_USE flag constraints are unsatisfied:
python? ( exactly-one-of ( python_single_target_python3_3
python_single_target_python3_4 python_single_target_python2_7 ) )
It looks to me like make.defaults sets exactly one of those. Is it
possible my USE="-* wipes out use_expand things as well?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 1:38 ` »Q«
2015-04-13 1:52 ` Alec Ten Harmsel
@ 2015-04-13 5:52 ` Alan McKinnon
2015-04-14 3:38 ` »Q«
2015-04-13 7:51 ` Neil Bothwick
2 siblings, 1 reply; 37+ messages in thread
From: Alan McKinnon @ 2015-04-13 5:52 UTC (permalink / raw
To: gentoo-user
On 13/04/2015 03:38, »Q« wrote:
> On Sun, 12 Apr 2015 21:24:48 -0400
> Alec Ten Harmsel <alec@alectenharmsel.com> wrote:
>
>> On 04/12/2015 09:15 PM, »Q« wrote:
>>>
>>> Before you pore through it, I guess I should point out that it's not
>>> causing me any problems -- I was just curious about why it would be
>>> a bad idea for me to manage those PYTHON_* variables myself. I
>>> guess the most notable thing about my make.conf is that I'm one of
>>> those crazy USE="-*" people.
>>
>> It's not a bad idea to manage the PYTHON_TARGETS,
>> PYTHON_SINGLE_TARGET, and RUBY_TARGET variables if you *need* a
>> specific version of python or ruby. If you do not, I would say it is
>> bad. These are set in the profile so that the maintainers can decide
>> when to update to a new stable version. Since all of the various
>> python and ruby libraries are installed from source, it's generally a
>> good idea to wait for the maintainers to stabilize a certain version
>> since that means the library support is also good.
>
> How can I find out whether the profile is setting those variables?
> ISTM the emerge errors I posted earlier, which happen if I get rid of
> those variables in make.conf, indicate that they are not being set at
> all.
>
> When a new version of python (or ruby, I guess) is stabilized, I do
> have to spend some time making sure those variables are sanely set, and
> I'd rather just leave it up to the devs.
>
>> Also, using the KDE profile and having USE="-*" seem contrary. One of
>> the main reasons to use a profile is to get a relevant set of USE
>> flags.
>
> I don't want the profile's USE flags, but I still thought it best to
> select the profile that matches what I use the machine for.
A profile is indeed intended to match the intended use of the machine,
and to do that it does two things:
- enables or disables some software (the minor feature)
- sets some sane default USE (the major feature)
USE="-*" essentially undoes the profile entirely rendering it useless.
You'd be better off just setting your profile to default and doing all
the heavy lifting yourself instead of going with the maintainers
suggestions implemented in the profile.
--
Alan McKinnon
alan.mckinnon@gmail.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 5:52 ` Alan McKinnon
@ 2015-04-14 3:38 ` »Q«
0 siblings, 0 replies; 37+ messages in thread
From: »Q« @ 2015-04-14 3:38 UTC (permalink / raw
To: gentoo-user
On Mon, 13 Apr 2015 07:52:54 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 13/04/2015 03:38, »Q« wrote:
> > On Sun, 12 Apr 2015 21:24:48 -0400
> > Alec Ten Harmsel <alec@alectenharmsel.com> wrote:
> >> Also, using the KDE profile and having USE="-*" seem contrary. One
> >> of the main reasons to use a profile is to get a relevant set of
> >> USE flags.
> >
> > I don't want the profile's USE flags, but I still thought it best to
> > select the profile that matches what I use the machine for.
>
> A profile is indeed intended to match the intended use of the machine,
> and to do that it does two things:
>
> - enables or disables some software (the minor feature)
> - sets some sane default USE (the major feature)
>
> USE="-*" essentially undoes the profile entirely rendering it useless.
> You'd be better off just setting your profile to default and doing all
> the heavy lifting yourself instead of going with the maintainers
> suggestions implemented in the profile.
I rarely have to mess with changing USE flags as it is now, but setting
them up from scratch (something I haven't done in many years) after
clobbering the profile's defaults was heavy lifting, for me at least.
If I ever have to do it again, I'll check out using a simpler profile
without clobbering its USE.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 1:38 ` »Q«
2015-04-13 1:52 ` Alec Ten Harmsel
2015-04-13 5:52 ` Alan McKinnon
@ 2015-04-13 7:51 ` Neil Bothwick
2015-04-14 3:51 ` »Q«
2 siblings, 1 reply; 37+ messages in thread
From: Neil Bothwick @ 2015-04-13 7:51 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
On Sun, 12 Apr 2015 20:38:17 -0500, »Q« wrote:
> > It's not a bad idea to manage the PYTHON_TARGETS,
> > PYTHON_SINGLE_TARGET, and RUBY_TARGET variables if you *need* a
> > specific version of python or ruby. If you do not, I would say it is
> > bad. These are set in the profile so that the maintainers can decide
> > when to update to a new stable version. Since all of the various
> > python and ruby libraries are installed from source, it's generally a
> > good idea to wait for the maintainers to stabilize a certain version
> > since that means the library support is also good.
>
> How can I find out whether the profile is setting those variables?
By removing USE="-*". At the moment it doesn't matter which profile you
use or what it sets as you are then telling portage to ignore all its
settings, even the critical ones. As portage evolves and the devs update
the profiles to keep in line, your system will be come gradually more
broken, as happened when PYTHON_TARGET variables were introduced.
--
Neil Bothwick
The modem is the message.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-13 7:51 ` Neil Bothwick
@ 2015-04-14 3:51 ` »Q«
2015-04-14 7:47 ` Neil Bothwick
0 siblings, 1 reply; 37+ messages in thread
From: »Q« @ 2015-04-14 3:51 UTC (permalink / raw
To: gentoo-user
On Mon, 13 Apr 2015 08:51:57 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:
> On Sun, 12 Apr 2015 20:38:17 -0500, »Q« wrote:
>
> > > It's not a bad idea to manage the PYTHON_TARGETS,
> > > PYTHON_SINGLE_TARGET, and RUBY_TARGET variables if you *need* a
> > > specific version of python or ruby. If you do not, I would say it
> > > is bad. These are set in the profile so that the maintainers can
> > > decide when to update to a new stable version. Since all of the
> > > various python and ruby libraries are installed from source, it's
> > > generally a good idea to wait for the maintainers to stabilize a
> > > certain version since that means the library support is also
> > > good.
> >
> > How can I find out whether the profile is setting those variables?
>
> By removing USE="-*". At the moment it doesn't matter which profile
> you use or what it sets as you are then telling portage to ignore all
> its settings, even the critical ones.
I'm getting conflicting info on this. Do profiles really only set USE
flags or do they do something else as well? (Or does USE="-*" affect
things *other* than USE?)
> As portage evolves and the devs update the profiles to keep in line,
> your system will be come gradually more broken, as happened when
> PYTHON_TARGET variables were introduced.
Following this list and -dev seems to keep me up-to-date on the
changes, as happened when the PYTHON_ variables were introduced.
AFAICS, the only brokenness so far is that I'm complicating my life
more than several people here think I should be.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-14 3:51 ` »Q«
@ 2015-04-14 7:47 ` Neil Bothwick
2015-04-15 3:09 ` »Q«
0 siblings, 1 reply; 37+ messages in thread
From: Neil Bothwick @ 2015-04-14 7:47 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]
On Mon, 13 Apr 2015 22:51:58 -0500, »Q« wrote:
> > > How can I find out whether the profile is setting those variables?
> >
> > By removing USE="-*". At the moment it doesn't matter which profile
> > you use or what it sets as you are then telling portage to ignore all
> > its settings, even the critical ones.
>
> I'm getting conflicting info on this. Do profiles really only set USE
> flags or do they do something else as well? (Or does USE="-*" affect
> things *other* than USE?)
Things like PYTHON_TARGETS, X86_ABI and VIDEO_CARDS are implemented as
USE variables, so yes, -* clobbers them too.
> > As portage evolves and the devs update the profiles to keep in line,
> > your system will be come gradually more broken, as happened when
> > PYTHON_TARGET variables were introduced.
>
> Following this list and -dev seems to keep me up-to-date on the
> changes, as happened when the PYTHON_ variables were introduced.
> AFAICS, the only brokenness so far is that I'm complicating my life
> more than several people here think I should be.
A lot more complicated if you have to follow a mailing list just to keep
your system working. You have essentially put your system into a
firefighting mode where you have to deal with each change as it breaks
things. The real problems occur when the cause of the issue that you are
suffering is not clear, and others cannot help because they use a profile
so do not experience it.
If you comment out your USE line and run "emerge --changed-use -p
@world" (do not use -v!) you will see what you actually need to set. Then
you can ad those to make.conf or package.use. It may take you half an
hour, but you'll end up with a system that maintains itself to a greater
extent.
--
Neil Bothwick
I just bought a microwave fireplace... You can spend an evening in
front of it in only eight minutes...
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-14 7:47 ` Neil Bothwick
@ 2015-04-15 3:09 ` »Q«
2015-04-15 8:24 ` Neil Bothwick
0 siblings, 1 reply; 37+ messages in thread
From: »Q« @ 2015-04-15 3:09 UTC (permalink / raw
To: gentoo-user
On Tue, 14 Apr 2015 08:47:01 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 13 Apr 2015 22:51:58 -0500, »Q« wrote:
>
> > > > How can I find out whether the profile is setting those
> > > > variables?
> > >
> > > By removing USE="-*". At the moment it doesn't matter which
> > > profile you use or what it sets as you are then telling portage
> > > to ignore all its settings, even the critical ones.
> >
> > I'm getting conflicting info on this. Do profiles really only set
> > USE flags or do they do something else as well? (Or does USE="-*"
> > affect things *other* than USE?)
>
> Things like PYTHON_TARGETS, X86_ABI and VIDEO_CARDS are implemented as
> USE variables, so yes, -* clobbers them too.
Thanks.
> A lot more complicated if you have to follow a mailing list just to
> keep your system working. You have essentially put your system into a
> firefighting mode where you have to deal with each change as it breaks
> things.
I'd be reading this list anyway. The time I spend heading off
and/or dealing with breakage due to *- is negligible, certainly nothing
like being in constant firefighting mode. I guess I've spent more time
in this thread, in which my system is neither broken nor in danger of
breaking, than I've spent on problems due to *- over the past five
years.
I don't want to advocate for *-. I don't recommend it to anybody. I
don't particularly want to argue about how good/bad/ugly it is with
anybody, but it's it's tough not to argue when people are telling me
I'm causing myself problems and I'm not seeing any such problems.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Re: Machine completely broken; Ncursed!
2015-04-15 3:09 ` »Q«
@ 2015-04-15 8:24 ` Neil Bothwick
0 siblings, 0 replies; 37+ messages in thread
From: Neil Bothwick @ 2015-04-15 8:24 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
On Tue, 14 Apr 2015 22:09:34 -0500, »Q« wrote:
> I don't want to advocate for *-. I don't recommend it to anybody. I
> don't particularly want to argue about how good/bad/ugly it is with
> anybody, but it's it's tough not to argue when people are telling me
> I'm causing myself problems and I'm not seeing any such problems.
That's fair enough. I have no problem with your using -*, it's your
system. Advocating it is another matter, but you're not doing that.
--
Neil Bothwick
Velilind's Laws of Experimentation:
1. If reproducibility may be a problem, conduct the test only once.
2. If a straight line fit is required, obtain only two data points.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Machine completely broken; Ncursed!
2015-04-12 0:42 ` Alan Grimes
` (3 preceding siblings ...)
2015-04-12 9:12 ` J. Roeleveld
@ 2015-04-12 9:31 ` Neil Bothwick
2015-04-12 14:13 ` Andreas K. Huettel
5 siblings, 0 replies; 37+ messages in thread
From: Neil Bothwick @ 2015-04-12 9:31 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
On Sat, 11 Apr 2015 20:42:20 -0400, Alan Grimes wrote:
> Linux is crap, it takes all the talent I have to keep this piece of junk
> running. =(
So you either need less hacks in make.conf or more talent, you decide
which...
--
Neil Bothwick
BBS: (n.) a system for connecting computers and exchanging gossip,
facts, and uninformed speculation under false names.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [gentoo-user] Machine completely broken; Ncursed!
2015-04-12 0:42 ` Alan Grimes
` (4 preceding siblings ...)
2015-04-12 9:31 ` [gentoo-user] " Neil Bothwick
@ 2015-04-12 14:13 ` Andreas K. Huettel
5 siblings, 0 replies; 37+ messages in thread
From: Andreas K. Huettel @ 2015-04-12 14:13 UTC (permalink / raw
To: gentoo-user
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Sonntag, 12. April 2015, 02:42:20 schrieb Alan Grimes:
>
> /etc/portage # emerge --info
> [[: error while loading shared libraries: libtinfo.so.5: cannot open
> shared object file: No such file or directory
> Failed to validate a sane '/dev'.
> bash process substitution doesn't work; this may be an indication of a
> broken '/dev/fd'.
> /etc/portage #
OK. That means your system is seriously broken now, but I gather you already
know that. I doubt there is a way to get back to a working system without
tricks/extra downloads.
Most of the comments below are now mostly "trying to find out what happened".
I'm leaving out stuff where I dont see anything problematic.
> > > The ncurses problem has been a low-level
> > > issue for a long time but, with tinfo set, 99% of packages worked.
> >
> > Define low-level issue. What was broken all the time that you ignored?
>
> Busybox, valgrind, a number of other minor packages.
OK, now what was wrong there? Do you still have any old build logs maybe?
> > > 2. It sent out a profile that sets variable ABI_x86 with 32 bit
> > > enabled. ALARM: ABI_x86 should be set in exactly one place:
> > > /etc/portage/make.conf and nowhere else. But, nevertheless, ABI_x86 WAS
> > > set which broke the profile because my system cannot compile 32 bit
> > > executables. =( I tried the no-multilib profile but it didn't have a
> > > number of essential useflags and was foobar.
> >
> > You're still not providing the slightest bit of useful information.
> >
> > What happens if you try to generate a 32bit executable?
>
> Fails completely due to linking errors even though it should always be
> possible to compile something without its binary dependencies (with only
> the headers) because symbol resolution should take place at load time. =|
Well... Yes it is possible to compile things. But they also need to get
linked, and for that the libraries need to be present. No you cannot build
something against a library without the library being present.
> CFLAGS="-O3 -march=native -pipe "
> CXXFLAGS="${CFLAGS}"
- -O3 is not a good idea. -O2 is safe.
> LDFLAGS="-lncurses "
I hope you forced that in only at the end when things were already broken and
you tried to fix them. Wrong. Bad. Wrong. Bad.
> ACCEPT_KEYWORDS="amd64 ~amd64"
Should not be a big problem (since ~amd64 is pretty well maintained these
days), but in general you'll likely hit more bugs if you run unstable. In this
case it's definitely an advantage if you are familiar with bug reporting
procedures and frequent our bugzilla.
> USE="...
> c++0x
No. Just no, since you may run into all sorts of trouble with C++ programs.
(There was a news item about this recently.) I doubt that it is related to
your problems though.
> custom-cflags
No. Again. Just no. Do this and you get to keep the pieces. I dont dare to do
that myself. Especially in combination with -O3 it's, well,...
> discouraged
Read it and despair.
> sse2 sse3 sse4
Unproblematic but outdated. Also a recent news item.
So, now about getting back to a working system. There are many ways, none of
them really 100% clean given the amount of breakage, and I'm not really a
specialist. Some ideas, unverified and untested; I've never done this myself.
* Boot from a rescue system
* Mount your gentoo installation somewhere
* Copy your setup (/etc, /var/lib/portage/world) to a safe place (usb stick)
* For an amd64 multilib system doublecheck that both in /usr and / the "lib"
entry is a symlink to "lib64" in the same directory.
* Download the newest amd64 multilib stage3 and untar it over your system.
* restore your make.conf, *sanitized*
CFLAGS="-march=native -O2 -pipe"
* chroot into the system, and run emerge -eav system
* then reboot normally and run emerge -eav world (you may have to repeat this
a few times, since some packages may still be broken and portage won't
necessarily rebuild them in the correct order)
* then restore your old world file and repeat the last step
IF YOU HAVE A SPARE PARTITION, there is a much better way- do a new install
there, instead of all the above steps.
Good luck.
- --
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVKn2dAAoJEB9VdM6hupKV2ZsP/Asgl66mmh8/Lzd0mVwNQkts
GSszMvt7RNUb2k4lQetXR0psyr9Up7NDrp0plmAAguNJMtZOdgIVZsJ5sTvtWDxT
0fxM7EXD2QLzpKIUF0uQFLQ1O+68GYTK0UOai+7OzN99HwALM7U5H9k9hYIrEVY6
ZtueUazbfOgWmAM//ZPQltj4GYBeSiW9TLJUbZNHzQFqJkP+uPimYWN9QIkcGyVP
UJUlU1IJP9IOF7Ing10zisK1CT3+tEXnyeU930bnaCW1rLAUcm797BmwKWZX9RfW
MYqTe6jjWAmnK+n6ScAeCtcwmwZ5MeQQBD7SK8FySSpegev2dEZzrHaI9hvMajtZ
4L3i/CCwSwxUs3hjh+cn9kCb1Cs6BUqtXfR9Jt/rSZFOWVE7TbRrIssW0ZEw92x4
jKAO//H41EjK830QB6WzWLJxfYSdQ1SEaEW2WHNSdYd4vaxHv9YQp3sdm3zKxWel
hY0pEJ5NtQMWGkte0XU0DgowAuDnBMn7Xac//rcOwWsSZiWIn8SmdpxvR43/xAZt
Ln4k7xxJhb3a4w9Uocm3vPMOxIgRo2xFrdYNN18VGGz9zVNNyOZhECJDy9EZEtF1
liswCUhLUQMhKBau8F/DSpoL4AzZzyHciMNVVVG5PbAeYCr749KKjyp5H7zmPwhC
Vbe4Ykem3g/4BnMW1+6e
=AjWC
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 37+ messages in thread