[gentoo-amd64] Did devs change phonon flags without rev'ing package?

[gentoo-amd64] Did devs change phonon flags without rev'ing package?

[Mark Knecht]

Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
decisions about multilib stuff. This morning I did an eix-sync and now
I think I'm seeing new flags and rebuilding packages that are already
installed. Why?

I'm wondering if the package dev/maintainer might have changed flags
without rev'ing the package?

[SIGH]
After yesterday's updates I actually found myself thinking about
looking for a new distro. I'm not sure Gentoo is really for me
anymore, albeit it would be a big upset after using it for 12 years...
[/SIGH]

Thanks,
Mark

c2RAID6 ~ # emerge -fDuN @world
Calculating dependencies... done!
[ebuild     U  ] sys-devel/gnuconfig-20150304 [20140728]
[ebuild   R    ] app-arch/cabextract-1.4  USE="-extras% (-extra-tools%)"
[ebuild   R    ] dev-qt/designer-4.8.5  USE="kde%* phonon*"
[ebuild   R    ] media-libs/phonon-4.7.2  USE="designer*"
[ebuild     U  ] app-admin/sudo-1.8.12 [1.8.11_p1]

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by dev-qt/designer-4.8.5[kde,phonon]
# required by kde-base/kubrick-4.14.3
# required by kde-base/kdegames-meta-4.14.3
# required by kde-base/kde-meta-4.14.3
# required by @selected
# required by @world (argument)
=media-libs/phonon-4.7.2 designer

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.
c2RAID6 ~ #

Re: [gentoo-amd64] Did devs change phonon flags without rev'ing package?

[Volker Armin Hemmann]

Am 30.03.2015 um 21:15 schrieb Mark Knecht:
> Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
> decisions about multilib stuff. This morning I did an eix-sync and now
> I think I'm seeing new flags and rebuilding packages that are already
> installed. Why?

after 12 years you should be able to figure that one out yourself.

>
> I'm wondering if the package dev/maintainer might have changed flags
> without rev'ing the package?

no, they didn't. And a quick look at media-libs/phonon/Changelog OR the
ebuild would have told you that.

Really, 12 years? Still asking those questions?

>
> [SIGH]
> After yesterday's updates I actually found myself thinking about
> looking for a new distro. I'm not sure Gentoo is really for me
> anymore, albeit it would be a big upset after using it for 12 years...
> [/SIGH]

well, if you are so resistant to progressing your skills, I assume NO
distribution would be right for you.

> Thanks,
> Mark
>
> c2RAID6 ~ # emerge -fDuN @world
> Calculating dependencies... done!
> [ebuild     U  ] sys-devel/gnuconfig-20150304 [20140728]
> [ebuild   R    ] app-arch/cabextract-1.4  USE="-extras% (-extra-tools%)"
> [ebuild   R    ] dev-qt/designer-4.8.5  USE="kde%* phonon*"
> [ebuild   R    ] media-libs/phonon-4.7.2  USE="designer*"
> [ebuild     U  ] app-admin/sudo-1.8.12 [1.8.11_p1]
>
> The following USE changes are necessary to proceed:
>  (see "package.use" in the portage(5) man page for more details)
> # required by dev-qt/designer-4.8.5[kde,phonon]
> # required by kde-base/kubrick-4.14.3
> # required by kde-base/kdegames-meta-4.14.3
> # required by kde-base/kde-meta-4.14.3
> # required by @selected
> # required by @world (argument)
> =media-libs/phonon-4.7.2 designer

and there it tells you why it wants that flag to be set. Seriously.
Learn to read. And think a bit. A tiny, tiny bit.

Re: [gentoo-amd64] Did devs change phonon flags without rev'ing package?

[Frank Peters]

On Mon, 30 Mar 2015 12:15:55 -0700
Mark Knecht <markknecht@gmail.com> wrote:

> Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
> decisions about multilib stuff.
>

Is it still necessary to be using multilib?

I've been using pure AMD64 for so long I tend to forget that
32-bit stuff still exists.

Frank Peters

Re: [gentoo-amd64] Did devs change phonon flags without rev'ing package?

[Mark Knecht]

On Mon, Mar 30, 2015 at 2:04 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Mon, 30 Mar 2015 12:15:55 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>> Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
>> decisions about multilib stuff.
>>
>
> Is it still necessary to be using multilib?
>
> I've been using pure AMD64 for so long I tend to forget that
> 32-bit stuff still exists.
>
> Frank Peters

Hi Frank,
   Honestly, I really don't know and figure the answer is probably no,
but it was when I set the machine up this way 5 or so years ago. Even
today I still see messages from things like Virtualbox drivers saying
they are using 32-bit modes, but what do I know? When emerge threw all
this stuff at me Sunday I figured I had no reason to break a machine
that has been working well so I let it do everything it wanted to do.
I don't have any problems with them getting rid of emulation libraries
and having everything built into the packages. I just wasn't prepare
for the time it required yesterday.

   If I was to build a machine from scratch today I'd certainly
investigate the question more closely but with an i7 980x, 24GB &
about 5TB of storage I have no plans on new hardware at this time.
Even with 3 Win 7 VMs running I seldom get above about 40% CPU usage.
I get close to running out of DRAM at times so I'm careful. My disk
subsystem is too slow but I've talked about that in the past. I just
haven't done much about it.

Cheers,
Mark

Re: [gentoo-amd64] Did devs change phonon flags without rev'ing package?

[Barry Schwartz]

Mark Knecht <markknecht@gmail.com> skribis:
> On Mon, Mar 30, 2015 at 2:04 PM, Frank Peters <frank.peters@comcast.net> wrote:
> > On Mon, 30 Mar 2015 12:15:55 -0700
> > Mark Knecht <markknecht@gmail.com> wrote:
> >
> >> Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
> >> decisions about multilib stuff.
> >>
> >
> > Is it still necessary to be using multilib?
> >
> > I've been using pure AMD64 for so long I tend to forget that
> > 32-bit stuff still exists.
> >
> > Frank Peters
> 
> Hi Frank,
>    Honestly, I really don't know and figure the answer is probably no,
> but it was when I set the machine up this way 5 or so years ago. Even
> today I still see messages from things like Virtualbox drivers saying
> they are using 32-bit modes, but what do I know? When emerge threw all
> this stuff at me Sunday I figured I had no reason to break a machine
> that has been working well so I let it do everything it wanted to do.
> I don't have any problems with them getting rid of emulation libraries
> and having everything built into the packages. I just wasn't prepare
> for the time it required yesterday.

I’m still working on it, myself. Various problems. Nothing I won’t be
able to figure out. My list of things to build ~amd64 instead of amd64
is growing a bit, for instance. Had to fix one of my overlay
ebuilds. Etc. Removed some 32-bit stuff at least temporarily. I do not
use 32-bit stuff very often.

The main problem at this case is emerge wanting to install libav
despite that I’m set up for ffmpeg. These things happen.

At least if you use emerge as your package manager, it’s probably safe
to go ahead and uninstall the emul packages, if you haven’t. The
binaries will stay in place until you build the replacements.

Re: [gentoo-amd64] Did devs change phonon flags without rev'ing package?

[Mark Knecht]

On Mon, Mar 30, 2015 at 3:10 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Mark Knecht <markknecht@gmail.com> skribis:
>> On Mon, Mar 30, 2015 at 2:04 PM, Frank Peters <frank.peters@comcast.net> wrote:
>> > On Mon, 30 Mar 2015 12:15:55 -0700
>> > Mark Knecht <markknecht@gmail.com> wrote:
>> >
>> >> Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
>> >> decisions about multilib stuff.
>> >>
>> >
>> > Is it still necessary to be using multilib?
>> >
>> > I've been using pure AMD64 for so long I tend to forget that
>> > 32-bit stuff still exists.
>> >
>> > Frank Peters
>>
>> Hi Frank,
>>    Honestly, I really don't know and figure the answer is probably no,
>> but it was when I set the machine up this way 5 or so years ago. Even
>> today I still see messages from things like Virtualbox drivers saying
>> they are using 32-bit modes, but what do I know? When emerge threw all
>> this stuff at me Sunday I figured I had no reason to break a machine
>> that has been working well so I let it do everything it wanted to do.
>> I don't have any problems with them getting rid of emulation libraries
>> and having everything built into the packages. I just wasn't prepare
>> for the time it required yesterday.
>
> I’m still working on it, myself. Various problems. Nothing I won’t be
> able to figure out. My list of things to build ~amd64 instead of amd64
> is growing a bit, for instance. Had to fix one of my overlay
> ebuilds. Etc. Removed some 32-bit stuff at least temporarily. I do not
> use 32-bit stuff very often.
>
> The main problem at this case is emerge wanting to install libav
> despite that I’m set up for ffmpeg. These things happen.
>
> At least if you use emerge as your package manager, it’s probably safe
> to go ahead and uninstall the emul packages, if you haven’t. The
> binaries will stay in place until you build the replacements.
>

Hi Barry,
   Yes, uninstalling the emulation libraries is exactly what I did
yesterday. It all seemed to work. Everything (nearly 300 packages)
built cleanly, and then following that there were another 250 or so
that had to be rebuilt I guess to be relinked or something. Anyway, it
took a few hours but everything went fine.

   In my case I've been slowly converting my machine back to nearly
100% stable. I don't need anything more than that in my daily work
these days and would greatly prefer fewer updates. In the old days
when I ran a lot of Gentoo pro-audio overlay stuff I stay to stay
leading edge all the time but these days I don't do that and life
should be easier.

   The libav vs ffmpeg thing was an issue for me also but I eventually
got through that a couple of weeks ago. As part of 'going stable' I've
removed use flags in make.conf and package.use and then basically let
portage do its thing. Everything worked fine once I got it all to
build. handbrake/makemkv/vlc and (I think) xine are all working now
but they weren't for a few days.

   I was thinking back about my 32-bit usage when I built the machine.
In those days (and it's likely still true) to run Windows VST plugins
you had to have 32-bit support. I was doing a lot of software synth
stuff a decade ago and suspect that was my main need in that area. I
don't intentionally use 32-bit for anything so likely I don't need it
at all as per Frank's comment but I also didn't feel like I really
wanted to deal with that right now.

Cheers,
Mark

Re: [gentoo-amd64] Did devs change phonon flags without rev'ing package?

[Barry Schwartz]

Mark Knecht <markknecht@gmail.com> skribis:
>    In my case I've been slowly converting my machine back to nearly
> 100% stable. I don't need anything more than that in my daily work
> these days and would greatly prefer fewer updates. In the old days
> when I ran a lot of Gentoo pro-audio overlay stuff I stay to stay
> leading edge all the time but these days I don't do that and life
> should be easier.

A few years ago I proved it is possible to go from ~amd64 to amd64 but
often I bump something to ~amd64 to overcome problems.

(For instance it turned out libav was being pulled in because the
~amd64 version of ffmpeg I had allowed was no longer in portage. I had
to bump the version.)

>    I was thinking back about my 32-bit usage when I built the machine.
> In those days (and it's likely still true) to run Windows VST plugins
> you had to have 32-bit support. I was doing a lot of software synth
> stuff a decade ago and suspect that was my main need in that area. I
> don't intentionally use 32-bit for anything so likely I don't need it
> at all as per Frank's comment but I also didn't feel like I really
> wanted to deal with that right now.

The processor is made to handle 32-bit so better to have it than not,
from my point of view. (The whole multilib thing might have gone
smoothly years ago, and with nomultilib a trivial difference, if we
merely had had the sense to stick with Gentoo’s original filesystem
layout for libraries. But this is my view in retrospect. We sometimes
pay a big price for following the leads of other distros.)

[gentoo-amd64] Re: Did devs change phonon flags without rev'ing package?

[Duncan]

Frank Peters posted on Mon, 30 Mar 2015 17:04:58 -0400 as excerpted:

> On Mon, 30 Mar 2015 12:15:55 -0700 Mark Knecht <markknecht@gmail.com>
> wrote:
> 
>> Yesterday I was emerge -DuN @world clean. It took hours due to Gentoo
>> decisions about multilib stuff.
>>
>>
> Is it still necessary to be using multilib?

If you're running 100% freedomware, almost certainly not -- if you look 
at the per-arch package coverage stats in the gentoo newsletter, amd64 
actually has higher coverage now than x86, and the trend is certainly 
downward for x86.

[x86 32-bit-only diversion]

Actually, as some probably know I follow the gentoo-dev list as well, and 
just last week there was a short (only a handful of posts, maybe 3-5) 
discussion on demoting x86 to minor arch status, with the comment that 
all i86 based cpus have been 64-bit for some years now.

Before the rumors get out of hand, however, the very quick conclusion was 
that now wasn't the time for that, but at the same time, that there's a 
real chance that conclusion will change in a few years...  But note that 
as I said, the subthread was very short.  I expect that if it had been a 
serious proposal, there would have been a few devs effectively saying 
"Over my dead body!", as they have for a few other proposals over the 
years.  That, BTW, is why gentoo continues to have a very solid 
commitment to openrc, even as systemd is now well supported as 
effectively an equal option.  There's some very core devs and some of 
gentoo's donated hosting running openrc on installations of hundreds or 
thousands of machines, and as long as that's the case, openrc support 
won't be going anywhere, because if it did, gentoo would suddenly find 
itself forked and much smaller!  I have a feeling the resistance to 
dropping x86 to minor at this point would be very similar, tho I think 
everyone agrees now that the time is likely to eventually (perhaps 5-10 
years out) come.

Meanwhile, personally, I /did/ have a 32-bit-only original atom n270 
netbook and thus could have cared, but as I said in the recommendations 
thread, I loaned it out and don't expect to ever get it back (tho I'm not 
actually too upset about it), and also as I said in that thread I'm 
basically standardizing on amd64 for everything now, so no big deal for 
me personally, tho I definitely agree with the conclusion above, now is 
not the time.  

[end diversion]

Back to the 32-bit multilib on otherwise 64-bit amd64, tho...

As I said, freedomware only, 64-bit-only is almost certainly easiest.  
If, however, you're running servantware binaries of any sort, well, the 
signature quote says it, you're effectively a slave to whatever whims the 
master of that binary may have, and if they've never come out with 64-bit 
or if you've never chosen to do whatever upgrade at whatever cost might 
be required to get it, well...

But, for those where it's possible to go 64-bit only, I'd strongly 
recommend it.

Back when I originally made the switch on my main machine, if you weren't 
actually running anything 32-bit it only mattered for a few core 
packages, glibc and gcc being big ones.  But glibc in particular went 
from being a big deal to build, to just another package, because building 
it for 32-bit as well effectively doubled the package build time.  (And 
back then, nptl was still new and many things still defaulted to Linux-
threads instead of native-posix-thread-library, so big parts of glibc 
were already built twice, once for lt once for nptl, and building for 32-
bit also actually doubled /that/, so people with multilib were actually 
building glibc FOUR times!!  Of course that was on much slower equipment, 
when dual-core was new too, so it was a **BIG** deal!)

But, while the emul-* thing was definitely faster for other packages, it 
was faster in the binary-distro sense of being pre-built, and thus, not 
really all that gentooish at all!  Which is why, for people that wanted 
to do it the /real/ gentoo way, there was the 32-bit chroot guide.  Which 
is what I expanded on when I did the 32-bit chroot buildroot for my 32-
bit netbook, on my 64-bit main machine.  Basically, the original 32-bit 
chroot guide was setup as a nearly full 32-bit x86, minus the stuff where 
the 64-bit native side provided the services -- the kernel, most system 
services like syslog, cron, etc.  The point being, people could then 
actually  build the 32-bit stuff themselves, as any real gentooer likely 
wanted anyway as the control it allows is the /point/ of gentoo, instead 
of installing the multilib stuff and using the un-gentoo pre-built-binary 
emul-* solution.  Of course, since I was building a complete solution for 
a 32-bit machine, not just for running 32-bit apps in a chroot, I built 
the extra packages, kernel, services, etc, as well, in the chroot, and 
then transferred them to the 32-bit netbook.  (Originally I rsynced by 
thumb-drive "sneakernet", which was how I did the initial install on the 
netbook.  Then after I set up ssh, rsync over the LAN via SSH -- the 
netbook itself never actually had a copy of the gentoo tree as I never 
actually ran emerge on it at all, not even for binary packages, I simply 
rsynced from the 32-bit buildroot chroot.)

What the new multilib solution enables is thus far more "gentooish" than 
emul-* /ever/ was, but by the very SAME token, it's ALSO a lot more work, 
because you're effectively building a lot more stuff twice, once each for 
32-bit and 64-bit.

If you still actually NEED the multilib, that's great, you get far more 
control now by actually building it yourself!

But if you do *NOT* need multilib, you're now building MUCH more stuff 
twice, entirely USELESSLY, simply because you're still setup for multilib 
and that's what it does, even tho you don't actually NEED it.

Thus, as I said, if your use-case is such that you can do so, it's 
STRONGLY beneficial to go no-multilib, 64-bit only -- you'll save 
yourself LOTS of time and CPU cycles avoiding the double-builds.  OTOH, 
if your use-case requires multilib, great, you now have it in a far more 
gentooish way than was ever possible with the emul-* solution!

> I've been using pure AMD64 for so long I tend to forget that 32-bit
> stuff still exists.

Same here.  Except that...

Since I follow the gentoo-dev list, I saw all the new multilib stuff 
being hashed out there.  Plus, I had a lot of otherwise useless revision-
rebuilds to do, that was simply churn due to enabling the new multilib 
stuff that didn't affect me directly at all other than all the rebuilds 
(which I still did instead of simply blocking, because while I don't have 
Mark's 12-core monster, even with a 6-core first-gen amd bulldozer fx6100, 
it's less hassle and sometimes faster too, to simply do the rebuild than 
to fiddle with masking it because it's a multilib-only rebuild.  But as 
I'm ~amd64 and even newer (overlays, live-git packages...), even most of 
those rebuilds happened months ago, far enough back in history that the 
details are already going fuzzy, for me.

But yeah, pretty hard to forget the 32-bit stuff when you're doing a 
bunch of personally useless rebuilds due to the new multilib stuff that 
doesn't otherwise affect you at all...

Just makes me even /more/ glad I'm no-multilib and don't have to worry 
about that stuff any longer! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Did devs change phonon flags without rev'ing package?

[Frank Peters]

On Tue, 31 Mar 2015 05:02:17 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 
> As I said, freedomware only, 64-bit-only is almost certainly easiest.  
> If, however, you're running servantware binaries of any sort, well, the 
> signature quote says it, you're effectively a slave to whatever whims the 
> master of that binary may have, and if they've never come out with 64-bit 
> or if you've never chosen to do whatever upgrade at whatever cost might 
> be required to get it, well...
> 

I am still very surprised that the mighty Intel Corporation has
not yet released a pure 64-bit ICC compiler for Linux -- and this
has been true for many, many years.  It would be interesting to try
out compiling some things with icc and the associated math performance
libraries, but the gentoo emerge always chokes with same "multilib
required" message whenever I try to build icc.

One possible workaround for those who may require the rare 32-bit
package at rare times would be to use the Gentoo LiveDVD which is
multilib in nature.  I am considering booting with LiveDVD whenever
I need to use a single 32-bit image processing program (which by the
way I have not been successful in converting to 64-bit even though
I have the full source code).  The Gentoo LiveDVD is nice bacause
it allows changes to persist.  One can incorporate custom configurations
and programs and expect to see them after the next boot.  The builders
of Gentoo LiveDVD did a great job with the latest release.

Frank Peter

Re: [gentoo-amd64] Re: Did devs change phonon flags without rev'ing package?

[Barry Schwartz]

Duncan <1i5t5.duncan@cox.net> skribis:
> > Is it still necessary to be using multilib?
> 
> If you're running 100% freedomware, almost certainly not ...

Firefox binaries are 32-bit. QED.

(I rarely run Firefox binaries or even keep them installed, but it
does occasionally happen.)

Re: [gentoo-amd64] Re: Did devs change phonon flags without rev'ing package?

[David M. Fellows]

On Tue, 31 Mar 2015 11:40:44 -0500 
Barry Schwartz wrote -
> Duncan <1i5t5.duncan@cox.net> skribis:
> > > Is it still necessary to be using multilib?
> > 
> > If you're running 100% freedomware, almost certainly not ...
> 
> Firefox binaries are 32-bit. QED.

More accurately:
32-bit Firefox binaries are 32 bit
64-bit Firefox binaries are 64 bit

From firefox-bin-35.0.ebuild (others are similar):
SRC_URI="${SRC_URI}
        amd64? ( ${MOZ_FTP_URI}/${MOZ_PV}/linux-x86_64/en-US/${MOZ_P}.tar.bz2 -> ${PN}_x86_64-${PV}.tar.bz2 )
        x86? ( ${MOZ_FTP_URI}/${MOZ_PV}/linux-i686/en-US/${MOZ_P}.tar.bz2 -> ${PN}_i686-${PV}.tar.bz2 )"

QED.

> 
> (I rarely run Firefox binaries or even keep them installed, but it
> does occasionally happen.)
> 


Dave F

[gentoo-amd64] Re: Did devs change phonon flags without rev'ing package?

[Duncan]

David M. Fellows posted on Tue, 31 Mar 2015 16:43:13 -0300 as excerpted:

> On Tue, 31 Mar 2015 11:40:44 -0500 Barry Schwartz wrote -
>> Duncan <1i5t5.duncan@cox.net> skribis:
>> > > Is it still necessary to be using multilib?
>> > 
>> > If you're running 100% freedomware, almost certainly not ...
>> 
>> Firefox binaries are 32-bit. QED.
> 
> More accurately:
> 32-bit Firefox binaries are 32 bit 64-bit Firefox binaries are 64 bit
> 
> From firefox-bin-35.0.ebuild (others are similar):
> SRC_URI="${SRC_URI}
>         amd64? (
>         ${MOZ_FTP_URI}/${MOZ_PV}/linux-x86_64/en-US/${MOZ_P}.tar.bz2 ->
>         ${PN}_x86_64-${PV}.tar.bz2 )
>         x86? (
>         ${MOZ_FTP_URI}/${MOZ_PV}/linux-i686/en-US/${MOZ_P}.tar.bz2 ->
>         ${PN}_i686-${PV}.tar.bz2 )"
> 
> QED.

Yes.

Since I always build from source it doesn't directly affect me, but I 
recall reading an article (FLOSS commentary) sometime last year I 
believe, that wondered why Mozilla still insisted on directing Linux 
binary downloaders to the 32-bit binary in this day and age, when the 64-
bit binary is available.

There's something about support as well; apparently Mozilla supports 
users running the 32-bit binary to a larger extent than they do the ones 
running the 64-bit binary, too.  Maybe it has to do with the way 
proprietary plugins (like flash) are supported... obviously not something 
someone like me who couldn't legally (due to EULA) run such things if 
they tried would be too concerned about or likely to know the details 
of...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

I can run 32-bit stuff and you can't (was Re: [gentoo-amd64] Re: Did devs change phonon flags without rev'ing package?)

[Barry Schwartz]

I expected quibbling on the ‘need’ to run a 32-bit binary. Fact is,
‘need’ is up to the user, and not up to others. If you want to install
the main Firefox binary it is 32-bit; and that’s just one
example. Substitute any software name you like in there, as a 32-bit
binary; the hardware can run it. Only software can prevent that.

As I say, the distinction is mainly due to Gentoo having botched
multilib support on AMD64. We should have stuck with the original
layout, whereby there was no profile distinction and everything 64-bit
went in lib. There should be no need to install 32-bit toolchain if
you do not want it, regardless of a profile supporting multilib.