Beryllium beta iso available for testing

johnraff · 2022-11-20 06:55:22

unklar wrote:

Unfortunately responsible people don't want to or can't understand this when it comes to 'upgrading the existing lithium to the new beryllium':
full-upgrade/dist-upgrade works just like upgrade, except that it removes a package already installed on the system when the system upgrade requires it. The normal upgrade command, on the other hand, does not do this.
Therefore, is second command,
apt[-get] upgrade
as I said, is nonsense in this context.

Debian isn't a monolith - it's made of thousands of volunteers. The organization is very carefully put together so that packages get checked before they are added to the repositories, but maintainers do sometimes make mistakes with corner cases when upgrading, especially between package versions that are a more that one upgrade apart.

Users do sometimes build their own packages and forget they're installed, or install from backports or private repositories. Those packages' maintainer scripts might not exactly match.

All this - very slightly - increases the chance of an error when doing a 'full-upgrade'. On a server, even a tiny risk can't be taken, so Debian recommend the absolutely safest course they can think of. A very inexperienced user might also get into trouble.

For most people who know roughly what they're doing, with single-user systems that are regularly rebooted, it's probably fine to go straight from 'apt update' to 'apt full-upgrade', but the 'apt upgrade' in between does absolutely no harm, and in tutorials aimed at a wide range of users it's best to include it.

johnraff · 2022-11-21 06:02:07

johnraff wrote:

1.3.2 Remove obsolete packages should happen in section 2 after the apt update/upgrade.
Of course it does no harm in section 1 too, if there are some long-standing obsolete packages on the system.

Now I think about it a bit more, removing obsolete packages should be done in section 1, before the system upgrade. The fewer doubtful packages there are on the system, the lower the chance of getting problems with the upgrade. In fact it's probably a good idea to uninstall all unnecessary or seldom-used packages before system upgrade - they can always be re-installed later.

But there's still a need to check for obsolete packages after system upgrade too. Changing the Debian repository will have resulted in some packages no longer being available. However, if they're installed on the system, 'apt full-upgrade' will only remove them if they're holding up some other package's upgrade. Otherwise they'll just remain, and should be removed by hand before they cause trouble.

hhh · 2022-11-21 06:28:18

johnraff wrote:

Now I think about it a bit more, removing obsolete packages should be done in section 1, before the system upgrade. The fewer doubtful packages there are on the system, the lower the chance of getting problems with the upgrade. In fact it's probably a good idea to uninstall all unnecessary or seldom-used packages before system upgrade - they can always be re-installed later.

Yes. Also, the upgrade will take less time. Run...

sudo apt update

If there is a package you recognize there... GIMP, Thunderbird, Synaptic, whatever... and you don't use it, don't run the upgrade yet. Remove the package first, then upgrade. Example...

sudo apt purge thunderbird

...or if you're sure you'll never use the package...

sudo apt purge --autoremove thunderbird

Then run...

sudo apt update && sudo apt upgrade

Or just sudo apt upgrade, I'm being cautious for this post.

hhh · 2022-11-21 06:41:11

The Debian Wiki is a hot mess (try the Arch Wiki), but the Debian Handbook is solid as a rock (go Raphael Hertzog!)

https://debian-handbook.info/browse/sta … grade.html

johnraff · 2022-11-21 06:48:41

hhh wrote:

Example...
sudo apt purge thunderbird
...or if you're sure you'll never use the package...
sudo apt purge --autoremove thunderbird

I would say, if you're not sure you'll never use the package again, better not to use 'purge' or else all the settings will be gone. Just:

sudo apt remove thunderbird

hhh · 2022-11-21 06:57:49

^ Right

https://manual.siduction.org/sys-admin- … e-packages

I always purge --autoremove, I figure if I re-install I should start fresh. I hate that I have to check my Home folder for .config, .cache and .local.

johnraff · 2022-11-21 07:13:54

^Purge will only remove the system-wide settings. I don't think there's anything you can say to apt to get it to remove stuff in $HOME.

hhh · 2022-11-21 07:49:10

^There isn't. Hence me hating looking in 3 locations. Catfish is nice for that, though. Just enable "Show hidden files", search for the program, ignore the icon results, done.

Of course, there are (more powerful) cli ways to do that as well.

unklar · 2022-11-21 10:19:42

johnraff wrote:

But there's still a need to check for obsolete packages after system upgrade too. Changing the Debian repository will have resulted in some packages no longer being available. However, if they're installed on the system, 'apt full-upgrade' will only remove them if they're holding up some other package's upgrade. Otherwise they'll just remain, and should be removed by hand before they cause trouble.

If you correct your command, then your statement is correct with apt[-get] upgrade.

To the further discussion:
I don't care in principle in the meantime which way one or the other chooses, with man apt; the debian-wiki or manual. I found my way thanks to siduction and its former developer, @agaida.

apt update
apt dist-upgrade
apt clean and, if necessary
apt autoremove

which happens almost every week because a new kernel appears (I only keep two).
(BTW, I practice this with every debian)

As for purge or remove packages, I always use purge.
Because, what do I have of configuration files in the system, which are obsolete anyway due to transitions (eg now perl).

And finally, since systemd I do it all on X, I no longer do it in tty. Because fortunately I never had nvidia in my computers.

el_koraco · 2022-11-21 15:02:03

unklar wrote:

If you correct your command, then your statement is correct with apt[-get] upgrade.
To the further discussion:
I don't care in principle in the meantime which way one or the other chooses, with man apt; the debian-wiki or manual. I found my way thanks to siduction and its former developer, @agaida.
apt update
apt dist-upgrade
apt clean and, if necessary
apt autoremove
which happens almost every week because a new kernel appears (I only keep two).
(BTW, I practice this with every debian)
As for purge or remove packages, I always use purge.
Because, what do I have of configuration files in the system, which are obsolete anyway due to transitions (eg now perl).

And finally, since systemd I do it all on X, I no longer do it in tty. Because fortunately I never had nvidia in my computers.

There is a lot more to upgrade from point release to point release than there is in regular sid upgrades.

Last edited by el_koraco (2022-11-21 15:02:21)

unklar · 2022-11-21 16:58:40

el_koraco wrote:

There is a lot more to upgrade from point release to point release than there is in regular sid upgrades.

Yes, and from one point release to the other point release a new installation is always recommended (at most with takeover of the own $HOME).

So, what's with the stinginess.

el_koraco · 2022-11-21 20:17:05

unklar wrote:

el_koraco wrote:
There is a lot more to upgrade from point release to point release than there is in regular sid upgrades.
Yes, and from one point release to the other point release a new installation is always recommended (at most with takeover of the own $HOME).

Not according to the Bullseye release notes. The entire section linked here describes how to upgrade from Buster to Bullseye.

rbh · 2022-11-21 21:45:28

unklar wrote:

from one point release to the other point release a new installation is always recommended (at most with takeover of the own $HOME).

The Bunsenlabs team, recomends new install. But, it is possible to upgrade if you take precautions. There is advantages and disadvatages with both routes. Which you choose, is very depended of your situation.

Bunselabs team provides a tutorial based on debian recomendations howto upgrade from Lithium/Buster to Beryllium/Bullseye.

el_koraco · 2022-11-21 22:38:31

Ah, you meant for Bunsen. This is understandable, there is no way Bunsen can get enough users to test out an upgrade, at least until more people realize that this is the best Debian derivative.

ekzotic · 2022-11-23 14:27:57

Hello all! Just installed latest Bunsenlabs on the laptop with Ryzen 5500u, integrated amd graphics. Installation went smooth. Needed to fix tearing (amd tear free) and sleep (disable modern sleep in bios). Pretty much everything is fixed now.
Couple questions:
1) Watching YouTube is not as smooth as my Nvidia desktop, is there a way to make it better? (Vsync?)
2) Everything is too small on the display because of the higher dpi. Is there a quick way to adjust theme? Also with default theme chrome top icons (close, minimize) disappear when chrome is not active window. And in focus they look odd.

el_koraco · 2022-11-23 15:13:19

ekzotic wrote:

H
1) Watching YouTube is not as smooth as my Nvidia desktop, is there a way to make it better? (Vsync?)

Apply what is said here: https://wiki.archlinux.org/title/firefo … celeration
See also: https://wiki.debian.org/Firefox#Hardwar … celeration

hhh · 2022-11-24 08:28:33

A newer kernel than what's in stock Bullseye might help...

https://forums.linuxmint.com/viewtopic.php?t=365185

BunsenLabs still uses xorg (@ El_K), does it not?

For your second question, a screenshot would help us. Print screen button, then choose "Host on Imgur", copy and paste the thumbnail link and tell us what we're looking for.

el_koraco · 2022-11-24 09:42:10

Mint people. Radeon Vega 11 and 7 graphics have been in the mainline kernel since 5.2 or something. The amdgpu driver supports VA-API hardware acceleration, no issues there. What the OP needs to do is enable acceleration in Firefox itself. The Arch wiki article is good because it explains how to check whether Firefox is running the accelerated or software renderer, and the Debian wiki article explains Debian specific tweaks. The Debian wiki is catching up to the Arch one pretty good. There is also no need to install many additional packages for Debian, because most are all included in the default X install - libva-drm2 and libva-x11. The only package needed for VA-API on Radeons is mesa-va-drivers.

So, to summarize,
install mesa-va-drrivers

about:config tweaks are as follows:

gfx.webrender.all true

media.ffmpeg.vaapi.enabled true

Thsi should be enough, but additional tweaks are

media.ffvpx.enabled false
media.av1.enabled false

Add to /etc/environment

MOZ_X11_EGL=1

Restart X, this should be enough.

Last edited by el_koraco (2022-11-24 10:02:29)

johnraff · 2022-11-25 02:32:09

WRT upgrading existing systems, here's an example of how even high-level Debian devs have to work to make dist-upgrades "more predictable and robust":
https://bugs.debian.org/cgi-bin/bugrepo … bug=986651
https://bugs.debian.org/cgi-bin/bugrepo … bug=993947

ekzotic · 2022-12-06 20:24:49

Thank you all for your support! It took some time to test out. For some reason "tear free" hurts my eyes so I disabled it. But I fixed tearing in compositor and installed latest kernel + packages from the posts above. It's almost perfect now. Now I think how to reduce power consumption (possibly disable cores) and fix scaling because everything is too small.
Here are the screenshots of chrome title bar (gtk):

out of focus

How it looks in lithium:

Last edited by ekzotic (2022-12-08 13:02:03)

#81 2022-11-20 06:55:22

Re: Beryllium beta iso available for testing

#82 2022-11-21 06:02:07

Re: Beryllium beta iso available for testing

#83 2022-11-21 06:28:18

Re: Beryllium beta iso available for testing

#84 2022-11-21 06:41:11

Re: Beryllium beta iso available for testing

#85 2022-11-21 06:48:41

Re: Beryllium beta iso available for testing

#86 2022-11-21 06:57:49

Re: Beryllium beta iso available for testing

#87 2022-11-21 07:13:54

Re: Beryllium beta iso available for testing

#88 2022-11-21 07:49:10

Re: Beryllium beta iso available for testing

#89 2022-11-21 10:19:42

Re: Beryllium beta iso available for testing

#90 2022-11-21 15:02:03

Re: Beryllium beta iso available for testing

#91 2022-11-21 16:58:40

Re: Beryllium beta iso available for testing

#92 2022-11-21 20:17:05

Re: Beryllium beta iso available for testing

#93 2022-11-21 21:45:28

Re: Beryllium beta iso available for testing

#94 2022-11-21 22:38:31

Re: Beryllium beta iso available for testing

#95 2022-11-23 14:27:57

Re: Beryllium beta iso available for testing

#96 2022-11-23 15:13:19

Re: Beryllium beta iso available for testing

#97 2022-11-24 08:28:33

Re: Beryllium beta iso available for testing

#98 2022-11-24 09:42:10

Re: Beryllium beta iso available for testing

#99 2022-11-25 02:32:09

Re: Beryllium beta iso available for testing

#100 2022-12-06 20:24:49

Re: Beryllium beta iso available for testing

Board footer