Re: [gentoo-user] Re: Heads Up - switching to profile 17.1 is not as easy as it sounds
On Tue, Jun 11, 2019 at 7:00 PM Nikos Chantziaras wrote: > > On 11/06/2019 13:34, Helmut Jarausch wrote: > > I had some trouble switching to the new profile 17.1. > > Following the advice in the news item didn't suffice. > > I'm not sure if switching to 17.1 would get me anything. I assume 17.0 > will still be there for a long time to come? Eventually it will go away, likely without much warning (just as there was little warning with the recent move to get rid of 13.0). However, you're probably fine for many months. There is a small risk that something might break on 17.0 because nobody will be testing with that config. Other than that I don't see much obvious benefit from the change. It is mostly to bring Gentoo more in line with what has emerged as the standard way of doing things. A lot of the old design predates the standards. -- Rich
[gentoo-user] Re: Heads Up - switching to profile 17.1 is not as easy as it sounds
On 11/06/2019 13:34, Helmut Jarausch wrote: I had some trouble switching to the new profile 17.1. Following the advice in the news item didn't suffice. I'm not sure if switching to 17.1 would get me anything. I assume 17.0 will still be there for a long time to come?
Re: [gentoo-user] AMD RX GPU in Gentoo
On Tue, Jun 11, 2019, at 10:56, Emmanuel Vasilakis wrote: > Hi! > > So, assuming I would get an RX550/560 card, how well do the amdgpu > drivers (open source) work? Are they ok for steam games? Do they provide > KMS (switching to a Ctrl+Alt+F1 is always garbled now). ? Are they > completely tear free? They work pretty well for me. I have an RX 570 (and a Ryzen 5 1600), works great for the most part but in all honesty it did take me a while to find a stable kernel. I'm not sure if that's due to the CPU or the GPU, or just me not knowing what I'm doing. All I play is CS:GO, which runs very well. I've played a bit of Rust too, which also works well. > Plus, my current GT730 is passively cooled. Are there any RX cards that > at least spin down the fans when I'm working on desktop (no > plasma/gnome, simple Openbox with no heavy gpu requirements). I really > like silence! :-) I can't hear mine at all right now. Hope this helps, Alec
Re: [gentoo-user] AMD RX GPU in Gentoo
On 6/11/19 7:56 AM, Emmanuel Vasilakis wrote: Hi! I'm running a pretty old PC. A Core2Duo E8400 and a GT730 nvidia card. Now, this is ok for what I need: work (emacs and bunch of terminals) and some little Kerbal Space Program. I'm thinking of upgrading some time in the next months to a 3600 AMD Ryzen when they are available, but in the mean time, I was also thinking about changing to an AMD gpu too. The nvidia driver although ok, is giving me some trouble mostly when suspending to ram. Sometimes it wont work, and the culprit from dmesg is likely the nvidia blob. So, assuming I would get an RX550/560 card, how well do the amdgpu drivers (open source) work? Are they ok for steam games? Do they provide KMS (switching to a Ctrl+Alt+F1 is always garbled now). ? Are they completely tear free? Plus, my current GT730 is passively cooled. Are there any RX cards that at least spin down the fans when I'm working on desktop (no plasma/gnome, simple Openbox with no heavy gpu requirements). I really like silence! :-) Thanks, Emmanuel I am currently setting up a new computer for a friend's parents. It's a 2400G with the Vega graphics. I installed gentoo to stress test the system (compiling mostly, did system and a full KDE desktop) and have had no problems but I haven't tried games. HDMI out works, VGA out works, HDMI audio works. I just had to get a kernel > 4.15 (I think it's 4.18.x right now) and select the amdgpu options. It seems that the default profile installs amdgpu for X automatically, didn't even have to do anything there. I did check X and it is using the amdgpu drivers. I streamed 1080 video from youtube for a couple of hours and I didn't notice any glitches. amdgpu requires modesetting, if you do a 'nomodeset' option all you get is a black screen. Now, I haven't tried them with the RX cards, but for the Vega graphics they are OK. Dan
[gentoo-user] AMD RX GPU in Gentoo
Hi! I'm running a pretty old PC. A Core2Duo E8400 and a GT730 nvidia card. Now, this is ok for what I need: work (emacs and bunch of terminals) and some little Kerbal Space Program. I'm thinking of upgrading some time in the next months to a 3600 AMD Ryzen when they are available, but in the mean time, I was also thinking about changing to an AMD gpu too. The nvidia driver although ok, is giving me some trouble mostly when suspending to ram. Sometimes it wont work, and the culprit from dmesg is likely the nvidia blob. So, assuming I would get an RX550/560 card, how well do the amdgpu drivers (open source) work? Are they ok for steam games? Do they provide KMS (switching to a Ctrl+Alt+F1 is always garbled now). ? Are they completely tear free? Plus, my current GT730 is passively cooled. Are there any RX cards that at least spin down the fans when I'm working on desktop (no plasma/gnome, simple Openbox with no heavy gpu requirements). I really like silence! :-) Thanks, Emmanuel
Re: [gentoo-user] Heads Up - switching to profile 17.1 is not as easy as it sounds
On Tue, Jun 11, 2019 at 8:42 AM Davyd McColl wrote:
>
> On Tue, 11 Jun 2019 at 14:23, Rich Freeman wrote:
>>
>> I think a big part of that is that before I did ANYTHING I took a lot
>> of steps to clean up...
>
> I guess YMMV. I regularly:
> - emerge --sync
> - emerge --update --newuser --deep @world @preserved-rebuild -a
> - emerge --depclean -a
> (by regularly, I mean at least twice a week). If I uninstall anything, I
> clean out
> package.{use|accept_keywords|licence} where appropriate. AFAIK I followed
> the news item pedantically, following it step-by-step until I got to
> re-merging /lib32
> & /usr/lib32, when things came a little unstuck.
>
> Doesn't mean I'm couldn't miss something, just that I'm not leaving this
> machine out-of-date for months at a time or expecting miracles.
It was just intended as general advice for anybody else doing the
upgrade, not as finger-pointing. Despite my care I still ran into
some minor issues.
> I appreciate all the help and experience available from this list
> and would appreciate any input on my updating procedures above,
> in particular, anything which would have made this transition smoother.
You're not really doing anything wrong. I think this is just the
difference between washing your hands before dinner and washing your
hands before going into surgery. And simply doing everything right
doesn't guarantee a lack of issues for something like this.
> Mostly, I find portage to be very capable, though it's taken me quite a while
> to make heads-or-tails of the error output, but I'm getting better at it.
Portage error output is often cryptic, and usually literally following
its advice is the worst thing you can do. It is fine for a lot of
one-offs but when you get 800 lines of error output and a suggestion
to stick something in a config file I'd make sure you understand what
is going on first.
As with most software it is literally trying to solve a problem it
thinks you asked it to solve. Unfortunately, sometimes the fastest
way to get rid of a disease is to drown the patient in disinfectant so
you could call this 3-laws safe. :)
--
Rich
Re: [gentoo-user] Heads Up - switching to profile 17.1 is not as easy as it sounds
On Tue, 11 Jun 2019 at 14:23, Rich Freeman wrote:
> On Tue, Jun 11, 2019 at 7:21 AM Davyd McColl wrote:
> >
> > On Tue, 11 Jun 2019 at 12:34, Helmut Jarausch
> wrote:
> >>
> >> I had some trouble switching to the new profile 17.1.
> >> Following the advice in the news item didn't suffice.
> >>
> >
> > first off, `emerge -v1 /lib /lib32` didn't work out because I had an old
> library in there I
> > had to remove with `emerge --depclean` first. I also have an old install
> of sickbeard, which
> > I had to remove from world for the same reason: `emerge -v1 /lib /lib32`
> would just complain
> > about not being able to find an installable source (my words -- can't
> remember the original
> > terms), but it didn't really look like an error -- all green text.
>
> I've updated two hosts. One went very smoothly, but it is a fairly
> dedicated host. One had a few issues, and it has a LOT of history.
>
> I found that anything 32-bit tended to cause more trouble, and I had a
> few orphans as well. It wasn't a huge deal.
>
> I think a big part of that is that before I did ANYTHING I took a lot
> of steps to clean up. I ran depclean and revdep-rebuild as a start.
> I reviewed all the migration tool output and anything that looked
> non-essential was depcleaned. When I did the 32-bit rebuild anything
> that was giving me trouble was traced back to whatever pulled it in
> and depcleaned (I forget if I did that up-front or if I just deleted
> the offending library and depcleaned the rev dep later - obviously
> don't do that for anything you care about).
>
> On a more dedicated host/container/etc I suspect you won't have many
> issues, because you're not going to have a huge pile of legacy stuff
> lying around with complicated dependency relationships.
>
> Some of my rebuild and depclean issues were resolved with --backtrack
> and --with-bdeps=y.
>
> In general a good principle is that anytime you want to change
> profiles take some time to do some housekeeping. The less junk you
> have on your system, the less there is that can go wrong.
>
> On my one host I also took the opportunity to decide whether I REALLY
> needed wine. That is a TON of 32-bit stuff you otherwise probably
> don't need. After removing it you need to clean out package.use
> because we don't have soft USE dependencies yet.
>
> And of course before I did anything I took a zfs snapshot of my root
> filesystem which only contains the OS for the most part. So, if I ran
> into serious issues a rollback would probably have been a one-liner
> (I'm guessing that I'd do that from a rescue disk just to keep daemons
> with stuff in /var from going nuts).
>
> Overall it went better than I was anticipating actually. We haven't
> had a migration like this one in a while, but I do think that the
> risk-level of this one was a bit undersold. Restructuring all your
> libraries is obviously a risky task and while you shouldn't be
> alarmist it is something that has a lot of potential to go wrong. To
> be fair, the news item does say that you should do a backup.
>
I guess YMMV. I regularly:
- emerge --sync
- emerge --update --newuser --deep @world @preserved-rebuild -a
- emerge --depclean -a
(by regularly, I mean at least twice a week). If I uninstall anything, I
clean out
package.{use|accept_keywords|licence} where appropriate. AFAIK I followed
the news item pedantically, following it step-by-step until I got to
re-merging /lib32
& /usr/lib32, when things came a little unstuck.
Doesn't mean I'm couldn't miss something, just that I'm not leaving this
machine out-of-date for months at a time or expecting miracles. I also had
to ditch `wine-any` (for now, at least). I _do_, however, have abi_x86_32
set
on for */*, which speaks to your point about "mo' 32-bit, mo' problems". I
run
Steam, so I expect to find enough 32-bit dependencies that if I know that a
requirement for libfoo _always_ includes the 32-bit artifact, I might have
an
easier time with some game I got on Humble Bundle. I also do use a small
number of overlays, but try to keep that to a minimum as common sense tells
me that many overlays is a quick way to get into trouble. I'll only use an
overlay
if I _really_ want/need something (like dotnet core).
I appreciate all the help and experience available from this list
and would appreciate any input on my updating procedures above,
in particular, anything which would have made this transition smoother.
Mostly, I find portage to be very capable, though it's taken me quite a
while
to make heads-or-tails of the error output, but I'm getting better at it.
Coming
from Debian or a derivative for around 16 years, I truly appreciate Gentoo
and
the freedom it provides, not to mention the community and help that I've
received.
-d
> --
> Rich
>
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you
Re: [gentoo-user] Heads Up - switching to profile 17.1 is not as easy as it sounds
On Tue, Jun 11, 2019 at 7:21 AM Davyd McColl wrote: > > On Tue, 11 Jun 2019 at 12:34, Helmut Jarausch wrote: >> >> I had some trouble switching to the new profile 17.1. >> Following the advice in the news item didn't suffice. >> > > first off, `emerge -v1 /lib /lib32` didn't work out because I had an old > library in there I > had to remove with `emerge --depclean` first. I also have an old install of > sickbeard, which > I had to remove from world for the same reason: `emerge -v1 /lib /lib32` > would just complain > about not being able to find an installable source (my words -- can't > remember the original > terms), but it didn't really look like an error -- all green text. I've updated two hosts. One went very smoothly, but it is a fairly dedicated host. One had a few issues, and it has a LOT of history. I found that anything 32-bit tended to cause more trouble, and I had a few orphans as well. It wasn't a huge deal. I think a big part of that is that before I did ANYTHING I took a lot of steps to clean up. I ran depclean and revdep-rebuild as a start. I reviewed all the migration tool output and anything that looked non-essential was depcleaned. When I did the 32-bit rebuild anything that was giving me trouble was traced back to whatever pulled it in and depcleaned (I forget if I did that up-front or if I just deleted the offending library and depcleaned the rev dep later - obviously don't do that for anything you care about). On a more dedicated host/container/etc I suspect you won't have many issues, because you're not going to have a huge pile of legacy stuff lying around with complicated dependency relationships. Some of my rebuild and depclean issues were resolved with --backtrack and --with-bdeps=y. In general a good principle is that anytime you want to change profiles take some time to do some housekeeping. The less junk you have on your system, the less there is that can go wrong. On my one host I also took the opportunity to decide whether I REALLY needed wine. That is a TON of 32-bit stuff you otherwise probably don't need. After removing it you need to clean out package.use because we don't have soft USE dependencies yet. And of course before I did anything I took a zfs snapshot of my root filesystem which only contains the OS for the most part. So, if I ran into serious issues a rollback would probably have been a one-liner (I'm guessing that I'd do that from a rescue disk just to keep daemons with stuff in /var from going nuts). Overall it went better than I was anticipating actually. We haven't had a migration like this one in a while, but I do think that the risk-level of this one was a bit undersold. Restructuring all your libraries is obviously a risky task and while you shouldn't be alarmist it is something that has a lot of potential to go wrong. To be fair, the news item does say that you should do a backup. -- Rich
Re: [gentoo-user] Heads Up - switching to profile 17.1 is not as easy as it sounds
On Tue, 11 Jun 2019 at 12:34, Helmut Jarausch wrote:
> I had some trouble switching to the new profile 17.1.
> Following the advice in the news item didn't suffice.
>
> I had to reinstall some packages "by hand", e.g.
> I had to reinstall util-linux quite early.
> I had to reinstall x11-libs/libva without the opengl USE flag, since it
> couldn't find libopenGL otherwise.
>
> After reinstalling mesa (which depends on libva), I'll try to reinstall
> x11-libs/libva with the opengl USE flag.
>
> Currently I'm reemerging gcc bintuils glibc before I proceed with the
> other packages selected by
> emerge -v1 /usr/lib/gcc /lib32 /usr/lib32
>
> Perhaps, it's only me.
>
> It isn't. It took me a few days to switch up to 17.1/plasma (because of
pesky things like sleep and work).
first off, `emerge -v1 /lib /lib32` didn't work out because I had an old
library in there I
had to remove with `emerge --depclean` first. I also have an old install of
sickbeard, which
I had to remove from world for the same reason: `emerge -v1 /lib /lib32`
would just complain
about not being able to find an installable source (my words -- can't
remember the original
terms), but it didn't really look like an error -- all green text.
I thought I'd just hitch on to the recommended line after that in the news
item: `emerge -ev @world`,
which would periodically break, usually in the configure stage. I didn't
know this before, but it seems
that `emerge -e @world` does not merge in dependency order. (Is there a way
to make it do so?)
I started with hunting down and applying `emerge -1` with deps which didn't
work, eg:
`eix {whatever the last thing complained about}`
(look for package which is already installed, and "seems right")
`emerge -1 {whatever I found}`
However, it seems that a bigger hammer may have just worked as well, as I
resorted to this after about 20
or so hand-helped packages:
`emerge -ev @world --keep-going`
followed by
`emerge --resume`
as many times as were necessary until there were no errors in the output.
I also had to manually remove a symlink for libidns.so.11, which was in
/usr/lib64, but pointing at /usr/lib
(so ld was complaining after every install) and I had to manually remove
/lib32, after doing `equery b /lib32`
and all the results mentioning `(lib)` in the line, so I _assumed_ that
meant that equery was dereferencing
/lib32.
On that note, does anyone know of a way to figure out what atom a symlink
belongs to? Not what it points at
-- `equery b /usr/lib64/libidn.so.11` told me that it belonged to libidns,
probably because it was dereferencing
to /usr/lib/libidn.so, which eventually dereferences to
/usr/lib/libidn.so.12.6.0, which _does_ belong to libidn,
but what finally gave me the confidence to delete it was to spelunk through
the output of `emerge -1 libidn`
and see that there was no `.11.so` symlink, so I deleted it, and, out of
paranoia, rebuilt -- and it didn't re-appear.
It would have been great to have been able to run `equery b
/usr/lib64/libidn.so.11` and get back nothing, to know
"for sure" that it's an invalid link, and I assume there's a way to do so
that I'm just not aware of?
-d
Helmut
>
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY
*Quidquid latine dictum sit, altum sonatur. *
[gentoo-user] Heads Up - switching to profile 17.1 is not as easy as it sounds
I had some trouble switching to the new profile 17.1. Following the advice in the news item didn't suffice. I had to reinstall some packages "by hand", e.g. I had to reinstall util-linux quite early. I had to reinstall x11-libs/libva without the opengl USE flag, since it couldn't find libopenGL otherwise. After reinstalling mesa (which depends on libva), I'll try to reinstall x11-libs/libva with the opengl USE flag. Currently I'm reemerging gcc bintuils glibc before I proceed with the other packages selected by emerge -v1 /usr/lib/gcc /lib32 /usr/lib32 Perhaps, it's only me. Helmut
