PiOS Bookworm Incompatibilities about pi-apps HOT 28 CLOSED

bluej java ide also has a bug that can only be fixed upstream since the deb itself depends on openjdk-11-jdk

Installing BlueJ Java IDE...

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 bluej : Depends: openjdk-11-jdk (>= 11) but it is not installable
         Depends: libopenjfx-java (>= 11) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Failed to install BlueJ Java IDE!

edit: I have opened a bug upstream k-pet-group/BlueJ-Greenfoot#2249

from pi-apps.

bluej package has been removed by piOS devs since it did not work on bookworm. now it won't show in pi-apps list and is thus not an issue anymore.

long term investigate packaging ourselves new versions if someone really wants this

from pi-apps.

bluej package has been by piOS devs

Did you mean to say it has been removed by the devs?

from pi-apps.

Did you mean to say it has been removed by the devs?

nah just "has been by the devs". Implying that the devs made the package only exist in the past....
yes I meant to write removed

from pi-apps.

@Botspot bookworm's chromium does not appear to work with chrome sync from better chromium
I checked and believe that the environment variables are getting picked up. Are you able to confirm or deny if it works for you or not?

from pi-apps.

@Botspot bookworm's chromium does not appear to work with chrome sync from better chromium I checked and believe that the environment variables are getting picked up. Are you able to confirm or deny if it works for you or not?

I think a while back in the forums a dev raised the idea of disabling sync from their sourcecode since it didn't work at the time. It's possible that change was implemented but its effects were delayed.
I will flash a new card with Bookworm and try it. It is also possible Debian was given a new key and we just need to update it.

from pi-apps.

the keys are certainly still good. We use the same ones at switchroot (on chromium 112 because its hard to build chromium on bionic so we don't update every version) and I just checked and no issues.

from pi-apps.

@Botspot I checked the debian bookworm deb and indeed the GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET have changed.

that means that google is likely doing server side checks on what version the browser is running (looking at the user agent) and disallowing the old keys on newer browser versions. both debian bullseye and bookworm are on chromium 115 now and use the new keys. piOS bookworm is also on chromium 115

from pi-apps.

I will check and see if the new keys work on both older browser and 115 or if we need to do detection to add the correct keys

from pi-apps.

new keys don't work on piOS bookworm either. I made a mistake above though. piOS bookworm is only on chromium 113, not 115. debian bullseye and bookworm are on 115, that was correct.

from pi-apps.

@Botspot not working in piOS bullseye either (also on chromium 113). they updated to that in May. Maybe it has been broken since then?

from pi-apps.

Nothing obvious seems to have broken it in their most recent May commit. RPi-Distro/chromium-browser@02890bf#diff-cdb69093f12e3e227e964a5803793eb7a4f4c6a0fbf153997e2b1097896e3257

from pi-apps.

@theofficialgman, in your testing, did you get as far as the google.com sign-in page for chrome sync?

I did after several changes. Not sure which of those changes are necessary and I will begin to backtrack. But I am interested to know if you got to this point.

from pi-apps.

@theofficialgman, in your testing, did you get as far as the google.com sign-in page for chrome sync?

no, the "turn on sync" button is actually just totally missing. I just tried clicking "add" at the bottom and then sign in and then always got an error code.

from pi-apps.

OK first you need to go to chrome://settings/syncSetup and "allow chromium sign-in". then relaunch the browser and it should be possible to reach where I am.

However, I got this error in the terminal after signing in to google:

[203077:203077:0731/214705.345808:ERROR:turn_sync_on_helper.cc(243)] Cannot turn Sync On for invalid account.

from pi-apps.

That error is solved by reverting to the current apikeys file in Better Chromium. The Cannot turn Sync On for invalid account. error only occurred on my Bullseye system when using the latest Debian apikeys values.
Sync appears to work for me without any script changes, although enabling that obscure setting in the UI is a necessary first step.

from pi-apps.

just figure out what file it edits when enabling that in the UI
chromium/chrome has lots of config files where you can set default options.

from pi-apps.

@Botspot its piOS devs.... https://github.com/RPi-Distro/chromium-browser/blob/master/debian/patches/0017-disable-browser-sign-in-feature-by-default.patch

that patch got added in the 113 release...

from pi-apps.

ok we can do this and it will work:
https://stackoverflow.com/questions/67689442/turn-off-chrome-signin-with-selenium-programmatically

we just can't change the system profile because the piOS dev chromium patch always sets it to false for new user creation

from pi-apps.

we just can't change the system profile because the piOS dev chromium patch always sets it to false for new user creation

I had assumed that those registry changes were just adding lines to their rpi-chromium-mods /etc/chromium/master_preferences file, but I do not see those lines there.
By using meld alongside jq before and after changing that setting, I confirmed that this section in the Preferences file is changed:

  "signin": {
    "AccountReconcilor": {
      "kDiceMigrationOnStartup2": true
    },
    "allowed": true,
    "allowed_on_next_startup": true
  },

when disabled:

"signin": {
    "AccountReconcilor": {
      "kDiceMigrationOnStartup2": true
    },
    "allowed": false,
    "allowed_on_next_startup": false
  },

ok we can do this and it will work:
https://stackoverflow.com/questions/67689442/turn-off-chrome-signin-with-selenium-programmatically

According to chatgpt, selenium webdriver is only accessible from writing a compiled program. Not sure if that is true or not, but it seems like excessive effort if true.

from pi-apps.

this is what I plan on adding

  # we could edit this with jq (as it is a json file), but avoid doing so to not have to install dependencies
  [ -f "$HOME/.config/chromium/Default/Preferences" ] && ( sed -i 's/"signin":{"allowed":false}/"signin":{"allowed":true,"allowed_on_next_startup":true}/g' "$HOME/.config/chromium/Default/Preferences"; sed -i 's/"signin":{"allowed":false,"allowed_on_next_startup":false}/"signin":{"allowed":true,"allowed_on_next_startup":true}/g' "$HOME/.config/chromium/Default/Preferences"; )

its the only way to change the value for the Default user when it is already created is to actually change that file. this is the same thing as clicking the toggle button.

from pi-apps.

selenium webdriver

wth is chatgpt talking about? what is selenium webdriver?

from pi-apps.

selenium webdriver

wth is chatgpt talking about? what is selenium webdriver?

from pi-apps.

its the only way to change the value for the Default user when it is already created is to actually change that file. this is the same thing as clicking the toggle button.

That seems to be correct, as changing master_preferences had no effect when creating a new user. I will take this from here. I will make it apply to all profiles and re-run on every chromium launch similar to how I did it for reduce_writes.

from pi-apps.

oop, too late I already pushed 5 mintues ago.

I will make it apply to all profiles

that is harder than you think. the folder that contains Default also contains many other folders. so you can't simply work on every folder and I am not sure if its safe to operate on other users.

and re-run on every chromium launch similar to how I did it for reduce_writes.

thats kinda gross but I get the desire. We should probably just ask piOS to not be so invasive with their patch. they should be able to ship those defaults as part of their config I think and not touch the code.

I don't understant why they are removing the apikeys though... that part just doesn't make sense to me.

from pi-apps.

I have pushed my implementation in commit 681b3ff.

from pi-apps.

Thanks for all the work you do for Chromium sync. It is something that i can't live without under RPI. All my bookmarks and passwords to all my online accounts, basically my gateway to the internet. We don't really have much of a choice when it comes to web browsers under RPI OS. I think now they also "modified" Firefox in bookworm to make it snappier and better with video-playback, which is good news, and they also enabled widewine support. So at last we have a second usable web browser option. The only problem now is to migrate all my password data to Firefox. I hope it is somewhat usable compared to Chromium. Chromium is snappy under RPI OS.

from pi-apps.

closing since all known issues have been solved downstream or upstream.
veracrypt has not packaged armhf/arm64 bookworm packages but I have done so for pi-apps and upsteam will likely do so on the next release

from pi-apps.