Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
~amd64
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
rzdndr
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jul 2024
Posts: 77

PostPosted: Fri Aug 02, 2024 10:34 am    Post subject: ~amd64 Reply with quote

Hello

Would you recommend installing packages that are in testing stage (packages which have the ~amd64 keyword)?
Back to top
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3329

PostPosted: Fri Aug 02, 2024 10:55 am    Post subject: Reply with quote

Testing Gentoo is actually pretty stable. I think the most issues arise when you mix stable with testing, as it makes resolving dependencies trickier and can put you into a less tested territory than other users.
I mean, it is OK to accept_keyword a few testing packages on a stable system, but as you get more and more of them, at some it's just better to switch completely. Like if you wanted to use freecad for example; it didn't have any stable version and was notoriously difficult to install on a mostly stable system, but worked fine on testing.
You can go with either, really.
_________________
Make Computing Fun Again
Back to top
View user's profile Send private message
rzdndr
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jul 2024
Posts: 77

PostPosted: Fri Aug 02, 2024 11:16 am    Post subject: Reply with quote

szatox wrote:
Testing Gentoo is actually pretty stable. I think the most issues arise when you mix stable with testing, as it makes resolving dependencies trickier and can put you into a less tested territory than other users.
I mean, it is OK to accept_keyword a few testing packages on a stable system, but as you get more and more of them, at some it's just better to switch completely. Like if you wanted to use freecad for example; it didn't have any stable version and was notoriously difficult to install on a mostly stable system, but worked fine on testing.
You can go with either, really.


The reason I was asking is this.

Currently I am using firefox-bin. The version of of firefox in that package is 128.0.3. It uses mesa. But mesa version 24.0.7 (newer than this) causes firefox to close the window abruptly. The reason for that is the mesa version. This has been resolved with mesa version 24.1.4. But that package is in testing.

Now I am building firefox (not the -bin, which is version 115.13.0). If that version would not have problems, I will be using that instead of introducing a testing package to my system, at this moment. I can wait until that version of mesa is free to merge. If that does not work, I would like to install the test version of mesa (24.1.4).

So, on a stable system, to just install mesa 24.1.4, I could do ACCEPT_KEYWORD="~amd64" emerge --ask --verbose =mesa-24.1.4 and this would just install the version of mesa into the system. When the system is unstable, or something else does not work, I could then downgrade mesa version to 24.3.1, the way it was. To do this downgrade I think I would do emerge --ask --verbose =mesa-24.1.3.

Would that be a correct way of merging the testing version of mesa, and downgrading it in case of trouble?
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4842
Location: Bavaria

PostPosted: Fri Aug 02, 2024 11:41 am    Post subject: Reply with quote

rzdndr wrote:
The reason I was asking is this.

[...]

So, on a stable system, to just install mesa 24.1.4, I could do ACCEPT_KEYWORD="~amd64" emerge --ask --verbose =mesa-24.1.4 and this would just install the version of mesa into the system. When the system is unstable, or something else does not work, I could then downgrade mesa version to 24.3.1, the way it was. To do this downgrade I think I would do emerge --ask --verbose =mesa-24.1.3. [...]


As @szatox already said, it is possible to use some testing packages in a stable environment IF you check before what would happen. I suggest to do this NOT with a specific version ->
Code:
$ ACCEPT_KEYWORDS="~amd64" emerge -1pv mesa

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 2.16 s (backtrack: 0/20).

[ebuild     U  ] dev-util/intel_clc-24.1.5::gentoo [24.1.3::gentoo] USE="-debug" LLVM_SLOT="18 -16 -17" 28.458 KiB
[ebuild     U  ] media-libs/mesa-24.1.5::gentoo [24.1.3::gentoo] USE="X llvm lm-sensors (opengl) proprietary-codecs vaapi vulkan wayland zstd -d3d9 -debug -opencl -osmesa (-selinux) -test -unwind -valgrind -vdpau -vulkan-overlay -xa" CPU_FLAGS_X86="sse2" LLVM_SLOT="18 -15 -16 -17" VIDEO_CARDS="intel -d3d12 (-freedreno) -lavapipe (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware -zink" 0 KiB

Total: 2 packages (2 upgrades), Size of downloads: 28.458 KiB

You see we have now 24.1.5 as latest testing version.

If you want switch back to the stable version, just delete the line (*) in your /etc/portage/package.accept_keywords and do a simple "emerge -1v mesa"


*) You surely know that giving a ACCEPT_KEYWORDS="~amd64" in the command line is only temporary; you have to add "media-libs/mesa" to /etc/portage/package.accept_keywords


P.S.: I am using also a stable system and some packages you can get ONLY as testing:
Code:
$ more /etc/portage/package.accept_keywords
sys-firmware/intel-microcode
sys-kernel/gentoo-sources
sys-kernel/linux-headers
x11-apps/igt-gpu-tools
app-crypt/ima-evm-utils
games-board/xboard
games-board/polyglot
games-board/stockfish
app-admin/kernel-hardening-checker
games-strategy/wesnoth
app-arch/7zip

(yes I always want the latest kernel :lol: )
_________________
https://wiki.gentoo.org/wiki/User:Pietinger
Back to top
View user's profile Send private message
rzdndr
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jul 2024
Posts: 77

PostPosted: Fri Aug 02, 2024 12:09 pm    Post subject: Reply with quote

pietinger wrote:
rzdndr wrote:
The reason I was asking is this.

[...]

So, on a stable system, to just install mesa 24.1.4, I could do ACCEPT_KEYWORD="~amd64" emerge --ask --verbose =mesa-24.1.4 and this would just install the version of mesa into the system. When the system is unstable, or something else does not work, I could then downgrade mesa version to 24.3.1, the way it was. To do this downgrade I think I would do emerge --ask --verbose =mesa-24.1.3. [...]


As @szatox already said, it is possible to use some testing packages in a stable environment IF you check before what would happen. I suggest to do this NOT with a specific version ->
Code:
$ ACCEPT_KEYWORDS="~amd64" emerge -1pv mesa

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 2.16 s (backtrack: 0/20).

[ebuild     U  ] dev-util/intel_clc-24.1.5::gentoo [24.1.3::gentoo] USE="-debug" LLVM_SLOT="18 -16 -17" 28.458 KiB
[ebuild     U  ] media-libs/mesa-24.1.5::gentoo [24.1.3::gentoo] USE="X llvm lm-sensors (opengl) proprietary-codecs vaapi vulkan wayland zstd -d3d9 -debug -opencl -osmesa (-selinux) -test -unwind -valgrind -vdpau -vulkan-overlay -xa" CPU_FLAGS_X86="sse2" LLVM_SLOT="18 -15 -16 -17" VIDEO_CARDS="intel -d3d12 (-freedreno) -lavapipe (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware -zink" 0 KiB

Total: 2 packages (2 upgrades), Size of downloads: 28.458 KiB

You see we have now 24.1.5 as latest testing version.

If you want switch back to the stable version, just delete the line (*) in your /etc/portage/package.accept_keywords and do a simple "emerge -1v mesa"


*) You surely know that giving a ACCEPT_KEYWORDS="~amd64" in the command line is only temporary; you have to add "media-libs/mesa" to /etc/portage/package.accept_keywords


P.S.: I am using also a stable system and some packages you can get ONLY as testing:
Code:
$ more /etc/portage/package.accept_keywords
sys-firmware/intel-microcode
sys-kernel/gentoo-sources
sys-kernel/linux-headers
x11-apps/igt-gpu-tools
app-crypt/ima-evm-utils
games-board/xboard
games-board/polyglot
games-board/stockfish
app-admin/kernel-hardening-checker
games-strategy/wesnoth
app-arch/7zip

(yes I always want the latest kernel :lol: )


If I do an emerge with -1 (oneshot), the next time I upgrade/update (emerge --sync, emerge -auvUD @world) my system, wouldn't it delete the installed package, since it will not be in the world set?

The reason it was on the command line is that I did not want to add this to my make.conf.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4842
Location: Bavaria

PostPosted: Fri Aug 02, 2024 12:20 pm    Post subject: Reply with quote

rzdndr wrote:
If I do an emerge with -1 (oneshot), the next time I upgrade/update (emerge --sync, emerge -auvUD @world) my system, wouldn't it delete the installed package, since it will not be in the world set?

No, it will not be deleted because "someone" needs it ;-) ... dependencies will not be removed.

(Using -1 is actually only necessary for slotted packages ... but it is not wrong to use it for everything - to be on a safe side - which is a dependency of an other package)

rzdndr wrote:
The reason it was on the command line is that I did not want to add this to my make.conf.

? ... make.conf ... ?

Do you mean package.accept_keywords ?

If you do not add it to this file, THEN the next world-update will downgrade the package to its stable version.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger
Back to top
View user's profile Send private message
rzdndr
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jul 2024
Posts: 77

PostPosted: Fri Aug 02, 2024 12:30 pm    Post subject: Reply with quote

pietinger wrote:
rzdndr wrote:
If I do an emerge with -1 (oneshot), the next time I upgrade/update (emerge --sync, emerge -auvUD @world) my system, wouldn't it delete the installed package, since it will not be in the world set?

No, it will not be deleted because "someone" needs it ;-) ... dependencies will not be removed.

(Using -1 is actually only necessary for slotted packages ... but it is not wrong to use it for everything - to be on a safe side - which is a dependency of an other package)

rzdndr wrote:
The reason it was on the command line is that I did not want to add this to my make.conf.

? ... make.conf ... ?


Sorry for the confusion that I may have caused. I meant my /etc/portage/make.conf. Adding this to the make.conf file would be making this a global change. I did not want to do that.

pietinger wrote:
Do you mean package.accept_keywords ?

If you do not add it to this file, THEN the next world-update will downgrade the package to its stable version.


Hmm. Then will add that to my package.accept_keywords directory (it is a directory on my system, will do what is written in https://wiki.gentoo.org/wiki/Knowledge_Base:Accepting_a_keyword_for_a_single_package#Using_directories).

This is also quite nice. Not adding it to the package.accept_keywords initially, and testing that package if it works or not. If it does not work do an emerge -1v package to revert back to the original/stable version. If it works, update your package.accept_keywords file or directory.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4842
Location: Bavaria

PostPosted: Fri Aug 02, 2024 12:37 pm    Post subject: Reply with quote

rzdndr wrote:
This is also quite nice. Not adding it to the package.accept_keywords initially, and testing that package if it works or not. If it does not work do an emerge -1v package to revert back to the original/stable version. If it works, update your package.accept_keywords file or directory.

Yes. 8)

If you would add ACCEPT_KEYWORDS="~amd64" to your make.conf THEN you would switch the whole system to testing ... and the way back to a stable system is difficult ... (I do not recommend it for the time being)
_________________
https://wiki.gentoo.org/wiki/User:Pietinger
Back to top
View user's profile Send private message
logrusx
Advocate
Advocate


Joined: 22 Feb 2018
Posts: 2164

PostPosted: Fri Aug 02, 2024 12:39 pm    Post subject: Reply with quote

rzdndr wrote:

Currently I am using firefox-bin. The version of of firefox in that package is 128.0.3. It uses mesa. But mesa version 24.0.7 (newer than this) causes firefox to close the window abruptly. The reason for that is the mesa version. This has been resolved with mesa version 24.1.4. But that package is in testing.


I think your problem is not with mesa version:

Code:
# emerge -pvO firefox mesa

These are the packages that would be merged, in order:

[ebuild   R   ~] www-client/firefox-128.0.3:rapid::gentoo  USE="X clang dbus gmp-autoupdate hwaccel jumbo-build openh264 pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp telemetry wayland -debug -eme-free -hardened -jack -libproxy -lto -pgo (-selinux) -sndio -system-png (-valgrind) -wifi" L10N="bg -ach -af -an -ar -ast -az -be -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fur -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -sc -sco -si -sk -skr -sl -son -sq -sr -sv -szl -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW" LLVM_SLOT="18 -17" 0 KiB
[ebuild   R    ] media-libs/mesa-24.1.3::gentoo  USE="X llvm (opengl) proprietary-codecs vaapi vdpau vulkan wayland zstd -d3d9 -debug -lm-sensors -opencl -osmesa (-selinux) -test -unwind -valgrind -vulkan-overlay -xa" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="18 -15 -16 -17" VIDEO_CARDS="radeonsi -d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 -radeon (-v3d) (-vc4) -virgl (-vivante) -vmware -zink" 0 KiB

Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB


As you see I have 24.1.3 and I have no such problem, the only difference being I built firefox, rather than using firefox-bin.

And yes, it's possible to use a mixture of testing and stable packages. However although Gentoo testing is pretty stable these days, I don't recommend going fully testing. At least not until you start feeling in your own waters with Gentoo. (I hope this phrase does not sound odd in English).

If you build firefox, better build the testing version. It requires bringing a few other packages to testing version, but it's coll most of the time, only occasionally complaining you need to bring a higher version of those.

Best Regards,
Georgi


Last edited by logrusx on Fri Aug 02, 2024 12:45 pm; edited 2 times in total
Back to top
View user's profile Send private message
rzdndr
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jul 2024
Posts: 77

PostPosted: Fri Aug 02, 2024 12:41 pm    Post subject: Reply with quote

pietinger wrote:
rzdndr wrote:
This is also quite nice. Not adding it to the package.accept_keywords initially, and testing that package if it works or not. If it does not work do an emerge -1v package to revert back to the original/stable version. If it works, update your package.accept_keywords file or directory.

Yes. 8)

If you would add ACCEPT_KEYWORDS="~amd64" to your make.conf THEN you would switch the whole system to testing ... and the way back to a stable system is difficult ... (I do not recommend it for the time being)


I am currently test driving gentoo for a week now. Have installed all the packages that I had on my other system. So far so good. :)

As someone new to gentoo, I will not do that. Want a stable system. But for solving a problem with firefox, and if it is just confined to just a few packages, I might try using packages from test.
Back to top
View user's profile Send private message
rzdndr
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jul 2024
Posts: 77

PostPosted: Sat Aug 03, 2024 9:17 am    Post subject: Reply with quote

logrusx wrote:
rzdndr wrote:

Currently I am using firefox-bin. The version of of firefox in that package is 128.0.3. It uses mesa. But mesa version 24.0.7 (newer than this) causes firefox to close the window abruptly. The reason for that is the mesa version. This has been resolved with mesa version 24.1.4. But that package is in testing.


I think your problem is not with mesa version:

Code:
# emerge -pvO firefox mesa

These are the packages that would be merged, in order:

[ebuild   R   ~] www-client/firefox-128.0.3:rapid::gentoo  USE="X clang dbus gmp-autoupdate hwaccel jumbo-build openh264 pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp telemetry wayland -debug -eme-free -hardened -jack -libproxy -lto -pgo (-selinux) -sndio -system-png (-valgrind) -wifi" L10N="bg -ach -af -an -ar -ast -az -be -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fur -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -sc -sco -si -sk -skr -sl -son -sq -sr -sv -szl -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW" LLVM_SLOT="18 -17" 0 KiB
[ebuild   R    ] media-libs/mesa-24.1.3::gentoo  USE="X llvm (opengl) proprietary-codecs vaapi vdpau vulkan wayland zstd -d3d9 -debug -lm-sensors -opencl -osmesa (-selinux) -test -unwind -valgrind -vulkan-overlay -xa" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="18 -15 -16 -17" VIDEO_CARDS="radeonsi -d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 -radeon (-v3d) (-vc4) -virgl (-vivante) -vmware -zink" 0 KiB

Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB


As you see I have 24.1.3 and I have no such problem, the only difference being I built firefox, rather than using firefox-bin.

And yes, it's possible to use a mixture of testing and stable packages. However although Gentoo testing is pretty stable these days, I don't recommend going fully testing. At least not until you start feeling in your own waters with Gentoo. (I hope this phrase does not sound odd in English).

If you build firefox, better build the testing version. It requires bringing a few other packages to testing version, but it's coll most of the time, only occasionally complaining you need to bring a higher version of those.

Best Regards,
Georgi


I have a radeon graphics card. It is really strange why you are not having that problem (it looks like you have a readonsi flag). Maybe it is with the type of card, I am not sure. I have the same problem on my other disto. After I have installed mesa 24.1.4, it went away.

I have filed bug reports on that particular problem with mesa and with firefox (their bug reporint gsites repectively) some time ago.

Building the test version may be an alternative.

Regards
Back to top
View user's profile Send private message
logrusx
Advocate
Advocate


Joined: 22 Feb 2018
Posts: 2164

PostPosted: Sat Aug 03, 2024 10:17 am    Post subject: Reply with quote

I think it's Vega, it comes with Ryzen 7 5800H, hybrid graphics with Nvidia.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming 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