@mjw, Yes, “libicu76” Is what I’m using, per @Wade_Oram 's comments (below)
That’s a pity, testing your with the specific distro you have been suppling may have helped to identify this issue before it hit production. I hope you get it resolved ASAP and can get back to enjoying the music.
Yes I did see. That is why I suggested that if ‘apt install libicu76’ does not work (because that version is not available on bookworm) you should use ‘apt list libicu*’ to find out what versions are available.
This would likely have told you that libicu74 (note: 74 not 76) is available and thus ‘apt install libicu74’ (again 74 not 76) would have fixed your issue on bookworm without updating/reflashing to trixie.
Now I need to fix Bridge on my NUC8i7 running DietPi. 
Thanks.
Also, in my post:
I gave a link to a DietPi article on how to use a DietPi supplied script to migrate from Bookworm to Trixie without re-flashing.
This is the procedure that I used to migrate all four of my Raspberry Pi 4s to Trixie when DietPi introduced support for it. Three of my RPI’s were originally flashed with Bookworm and haven’t been re-flashed since. The fourth was originally flashed with the debian release before Bookworm (Buster?) and then migrated to Bookworm and then Trixie using scripts.
The migration script takes a while to run but, in my experience at least, worked well and was easier than re-flashing.
1 Like
@Wade_Oram , one more huge Thank You for your patience and help. I as able to run “apt install libicu76” on my NUC8i7 running DietPi (Trixie) and get it working again. This is a huge relief since I use this Bridge to test other “stuff” (I tested “74” regardless).
I owe you some beers.
“Bookworm” → 74; “Trixie → 76”. 
2 Likes
If you decide to do EA testing and your feedback gets dismissed please ping me.
Some of the testing we did on raspberry pi was on trixie. We had one device on something older, but it was so old (several versions back) that they upgraded it to trixie and so this issue wasn’t caught.
Raspberry Pis aren’t cheap these days and so I have a limited number of devices I can test against.
(If that wasn’t bad enough one of my pi 4s decided to up and die on me 
)
I’ll try and add some of these versions mentioned to my list of things to watch for in the future.
1 Like
@Jeff_P needs to open the Roon purse then 
2 Likes
I hope that at least something happens with it. I’ve left EA testing as well, and now I’ve spent a large part of yesterday on fixing an issue that has been created by Roon: plain wrong information with respect to dependencies.
At least own up to the fact that you created this situation. And maybe I missed it (busy with fixing stuff), but I can’t find the message that starts with “sorry guys, we *** up”.
4 Likes
I have discovered why the Roon Bridge update on the one Dietpi system here failed when the other three succeeded.
As we have already discussed, the issue was that there was no libicu version installed (libicu76 on Trixie based systems and libicu74 on Bookworm based systems).
The reason it was missing on this system is that, on this particular system, I had not installed either the Samba client or server packages (contrary to what I wrote earlier from memory). These have a dependency on samba-libs which in turn has a dependency on libicu76 (Trixie). Thus, if I had installed samba client or server on this system, it would have pulled in libicu76 and the Roon Bridge update would not have been an issue.
@spockfish Whilst I don’t use Ropieee, presumably this explains why Ropieee also had the issue prior to your latest fix - I assume Ropieee does not include the Samba Client or Server (I can’t see why it would need it) and thus would have had no need to include libicu.
1 Like
Not entirely, but almost. RoPieee is not based on Debian, but is a custom build Linux appliance. That means that there is no mechanism where you can rely on (native) package management. And that means I, as integrator, need to be able to rely on provided information. When I was asked, months ago, if this update would cause issues for RoPieee my answer was “no”, because RoPieee has a full up to date stack: the dependencies that where mentioned (glibc and openssl) are and where covered for a long time already.
And while I can accept the issue itself (I work in the software industry for quite a few years and have been responsible for *** ups myself quite a few times ), I’ve got issues with Roon’s lack of ownership here. Especially considering that RoPieee (and other community driven projects) are based upon goodwill, and nothing else.
4 Likes
Well said, Harry
1 Like
FWIW, the majority of RPi’s I’ve supplied to people have RoPieee installed (and I only collected the exact cost I paid). Common sense told me this was the right move back when Harry switched to his own Linux build, and terminated SSH. This Bridge upgrade proved it was the right decision.
What matters here is each RPi I shipped included a note asking the person to support the RoPieee project. That was also the right thing to do.
Cheers.
1 Like
@spockfish I’m sorry this update has caused you so many headaches. I’m the person that did the work on modernizing Roon Bridge. I take personal responsibility for this and the lack of communication from me to those that were sharing this information.
Needing libicu wasn’t a new Roon dependency, but a new dependency as a by-product of moving Roon Bridge from running on mono/.net framework to dotnet (net10.0 in this case). Not using this as an excuse or anything, just that it got lost in the shuffle and I should have done a better job of letting everyone know about it.
I’m trying to create a list all of these various pieces and see if I can add them to my test matrix. I’m still fairly new to the Roon community.
If you are willing to test out future EA releases I’d greatly appreciate it and welcome any direct feedback.
16 Likes
@Stephen you have nothing to apologise for. There was a hidden dependency issue which survived EA testing - which others in this thread could have participated in to surface this bug early - but chose not to. The fix is simple and in the spirit of the DIY / open source community. After all it’s not a Roon Bridge problem but an open source packaging problem. God knows how many hours I’ve lost over the years to “Dependency Hell” - it has a nickname for a reason, Keep up the great work, thank you for making Roon better.
3 Likes
Which part of the fix is simple for someone that doesn’t have any idea what “SSH” is? I have three phone calls this weekend to address this exact issue. I put two SDCards in the mail yesterday and have a number of them in the mail to me so I can fix the issue. Some of us enjoy helping others…
While your comments are directed at me, I’ll refrain from adding anything more. Perhaps you could contribute to the Community instead of criticizing others.
Moving on.
1 Like
As I said before, the issue is not that hard to solve. Just install the required dependency packages. On my case, I did it on a container in order to keep the Volumio system safe.
What is wrong is the release notes. It should have correctly specified the dependencies and their versions. Before this Bridge release, I had it installed as a plugin on my Volumio device.
Before allowing bridge to be auto-updated, I checked the Release Notes to be sure the new version was compatible but the update killed it.
Also, I think for regular users that are not into IT, the auto-install should perform a compatibilty check to avoid disabling the old version if the device is not ready for new release.
1 Like
@Bozon , my apologies for hijacking your Volumio post. I should have started a separate post.
Cheers.
Thank you for the apology. It was confusing seeing all those posts but I realized that was because the platform and the codebase on the Volumio device are the same. I am an IT guy, so not really a problem for me. It was kind of fun.
1 Like