Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Portage perl and FGLRX and ... deprecated?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7256
Location: almost Mile High in the USA

PostPosted: Sun Oct 23, 2016 6:41 pm    Post subject: Portage perl and FGLRX and ... deprecated? Reply with quote

The "recent" (dangit, yes I put it off...) stabilization of xorg-server-1.18 seems to have caused one heck of a lot of problems to my fglrx/ati-drivers box. Some of the problems included for whatever reason, the perl 5.20 to 5.22 update which portage got really confused about.

However after adding these masks:

>x11-base/xorg-server-1.17.49
>=x11-drivers/xf86-input-evdev-2.10
>=x11-base/xorg-drivers-1.18

even my perl problems in portage(2.3.0) went away automagically. I don't claim to understand why this fixed it but it did...

In any case I've heard that ati-drivers is pretty much deprecated now? Even for RadeonHD 5000-series GPU?

I'm still using an old RadeonHD 5770, and for now "just works" but perhaps I should switch to the OSS driver soon? Is it stable? All functionality backported to this old GPU? Including OpenCL?

[EDIT]

I just had another box that had a very strange perl slot conflict problem upgrading from 5.20 to 5.22. There was another block (grub-0 and grub-2), so I fixed one block by masking (>=grub-2), and magically the perl problem went away(!!!)

So it almost seems there's a portage bug here unless I'm missing something here, or at least the portage output is not clear what the real problem is...

[EDIT 2]

ANOTHER box I had fglrx installed upon and ALSO had grub0 installed. Masked the new versions of xorg-server that fglrx didn't like and ensured grub2 was masked, and magically perl slot conflict went away!

This box I was pretty close to (and probably will still do so) emerge --unmerge ati-drivers as it was causing the xorg blocks. I don't even have an ATI board in that box anymore, but left the driver there just in case... but all it's doing now is causing blocks...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
v_andal
Guru
Guru


Joined: 26 Aug 2008
Posts: 524
Location: Germany

PostPosted: Mon Oct 24, 2016 7:12 am    Post subject: Reply with quote

Well, I'm not very happy about conflict between newer xorg and fglrx but really, it did not prevented me from updating perl. Yes, there were conflicts but I could resolve them by manual updating of various perl modules. Perl is famous for causing blocks during update. Usually, these blocks happen because there are so many different modules for perl. It is not a "portage bug". It is rather "bug" of the perl ebuild, but I guess it is not so easy to track every single perl module that depends on perl.

So, I haven't masked newer xorg or anything else yet, I've just manually updated perl and now wait on what is going to happen about fglrx.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7186
Location: Austria

PostPosted: Mon Oct 24, 2016 10:46 am    Post subject: Reply with quote

Perl upgrades usually 'just work' these days as long as you do not have a mix of ~arch and arch packages installed.

fglrx is gone, dead, for good, it will not see another release from AMD. Switch to radeon and never look back.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7256
Location: almost Mile High in the USA

PostPosted: Mon Oct 24, 2016 3:28 pm    Post subject: Reply with quote

Yeah I've gotten a lot of slot conflicts on perl lately, but it was strange that all the slot conflicts "went away" when a seemingly totally unrelated block was resolved via masks. The reason why it seems like a portage bug or perhaps needs to be a portage enhancement is that if it was able to resolve the slot conflict after fixing the block, why did it give the error to begin with? And why didn't it fix it on its own? The manually masked packages were not unstable versions.

Maybe there was some hidden perl dependency on the block? But not sure, thought that grub and fglrx don't need perl...

---

It looks like that Ubuntu has deprecated fglrx, but AMD still hasn't totally given up on it, but the plan is to give up on it. The last fglrx release is almost a year old now, so yeah looks like it's almost dead. Will have to look into switching to amdgpu soon, hoping it's equally as good^H^H^H^H^H fast...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7256
Location: almost Mile High in the USA

PostPosted: Thu Oct 27, 2016 4:07 pm    Post subject: Reply with quote

Tried updating yet another box...this time with nvidia-drivers <341 .. same xorg-1.17 requirement, same perl-core slot conflict. There was also another block with tigervnc-1.6 that requires xorg-1.18.

I was thinking, ugh more perl-core slot conflicts...but maybe it could be fixed with fixing the other blocks.

I masked xorg-1.18 as the ati boxes...and lo and behold, the perl slot conflicts went away!

Weird.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7186
Location: Austria

PostPosted: Thu Oct 27, 2016 7:30 pm    Post subject: Reply with quote

Portage is very verbose in those cases; when it quits on a conflict, it shows all those others as well that it actually is able to auto-resolve. It's a good idea then to watch out for the capital 'B' in the packages list that signals a real blocker.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7256
Location: almost Mile High in the USA

PostPosted: Thu Oct 27, 2016 8:18 pm    Post subject: Reply with quote

I'll see if I have any more machines with perl slot conflicts that won't autoresolve without masking Xorg 1.18 and post the exact error, seems I had no less than 4 machines so far with the same problem. They all are showing up as slot conflicts for perl and version conflict (this package needs version X but this other set of package needs version Y) for the other packages. These aren't don't seem to be hard blocks per se, but rather just a conflict... just that there seems to exist a solution that meets all constraints (without using ~arch), if and only if some of the latest versions are ignored.

Also tried --backtrack 300 and even that didn't do anything.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Zucca
Veteran
Veteran


Joined: 14 Jun 2007
Posts: 1577
Location: KUUSANKOSKI, Finland

PostPosted: Thu Oct 27, 2016 8:29 pm    Post subject: Reply with quote

asturm wrote:
fglrx is gone, dead, for good, it will not see another release from AMD. Switch to radeon and never look back.
... and in most cases the open source radeon is in par with fglrx.
_________________
..: Zucca :..

Code:
ERROR: '--failure' is not an option. Aborting...
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7256
Location: almost Mile High in the USA

PostPosted: Sun Oct 30, 2016 4:08 am    Post subject: Reply with quote

Looks like someone ran into the same issue that I did:
https://forums.gentoo.org/viewtopic-p-7984119.html#7984119
Here you can see the xorg and ati-drivers slot conflict for 1.17 and 1.18 (expected as it's part of the ebuild) but the perl slot conflict I think is spurious. We'll see if mgnut57 is also able to resolve the perl slot conflict by simply masking xorg, too...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 206

PostPosted: Wed Nov 09, 2016 6:06 am    Post subject: Reply with quote

eccerr0r wrote:
We'll see if mgnut57 is also able to resolve the perl slot conflict by simply masking xorg, too...


I was.

I did update portage before trying a world update. I usually do this as quite often conflicts get fixed with an update to portage.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7186
Location: Austria

PostPosted: Wed Nov 09, 2016 11:28 am    Post subject: Reply with quote

Several people wrongly thinking they have a perl upgrade issue when it really is a severely outdated nvidia-drivers package or dead fglrx on the xorg-server upgrade... bad timing.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7256
Location: almost Mile High in the USA

PostPosted: Wed Nov 09, 2016 3:44 pm    Post subject: Reply with quote

asturm wrote:
Several people wrongly thinking they have a perl upgrade issue when it really is a severely outdated nvidia-drivers package or dead fglrx on the xorg-server upgrade... bad timing.

But why is Portage giving incorrect data? It shouldn't give out the perl problem.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7186
Location: Austria

PostPosted: Wed Nov 09, 2016 3:53 pm    Post subject: Reply with quote

It's not incorrect per se, it's a conflict as well that it is able to fix by itself. Any solution to this would need to be extra careful to not hide real issues instead.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7256
Location: almost Mile High in the USA

PostPosted: Wed Nov 09, 2016 4:08 pm    Post subject: Reply with quote

It's unnecessary data that can throw off the debugger - which indeed it does. Ideally it should give out the most important errors first - but perl shows up on top.

This and the fact that if xorg was automatically "held back," this should have been automatically resolved by portage without user intervention as there indeed a solution that exists with only stable packages.

Must be some heuristics involved that force certain packages...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum