Brave Portable Stopped Updating

[PeteAir]

Today Brave stopped updating. It gets the update but does not install. I amd stuck on 1.73.97. It downloads `1.74.51, but does not install..
Thanks, Pete

[fredx181]

@PeteAir I just tested and updating to v1.74.51 works fine for me.
Also as double check I downloaded and extract again Mike's share from Mega here: viewtopic.php?p=59662#p59662
And then ran ./UpdateBrave and again got installed the newest v1.74.51 ok .
Could it be that you had Brave running while updating ? It probably needs to be closed first.

edit edit: Tested now on BookwormPup and the newest version doesn't run indeed.
Got;

Code: Select all

# ./LAUNCH
chrome_crashpad_handler: --database is required
Try 'chrome_crashpad_handler --help' for more information.
[6676:6676:0201/165118.018442:ERROR:socket.cc(120)] recvmsg: Connection reset by peer (104)
Trace/breakpoint trap

Also @BarryK noticed earlier:
https://bkhome.org/news/202109/cannot-r ... -spot.html

Running Brave as root works from my test, tell me if that's okay for you and I can probably help with modifying LAUNCH script for that.

[fredx181]

Tested some more and turns out for me that even earlier Brave versions won't run with run-as-spot on BookwormPup64.
On FossaPup all is ok.

[Marv]

I'm running Brave-portable64/brave-browser-1.74.48, stock portable, run-as-spot, in fossapup64 9.5 (small-5f), the current Voidpup64, NoblePup64, and LxPupSc64 installs with no issues. I'm currently not running BW64 so no test there. Pretty much daily use in all 3, counting my users, and no complaints from them. Updates have been normal here also with an occasional glitch on Braves part, usually remedied in a day or less.

[mikewalsh]

Pretty much the same story here. Just updated to 1.74.51 a few moments ago.....running here in a somewhat modified Tahr64; glibc 2.19 -> 2.28, and running Xenialpup64's original k4.9.58, though largely stock for the most part aside from the official 460.84 Nvidia driver for the GT 710. Fired straight up from the standard 'run-as-spot' wrapper, no issues.

Posting this from it now.

Mike.

[radky]

Tested some more and turns out for me that even earlier Brave versions won't run with run-as-spot on BookwormPup64.
On FossaPup all is ok.

@fredx181

Proposal for run-as-spot change: viewtopic.php?p=136162#p136162

I don't use Chromium browsers but based on the discussion in the above post, the following was added to the run-as-spot script in BW64 10.0.9 to address failed opening of the filechooser in Chromium-based browsers.

Code: Select all

#test for chromium-based browsers (if true, launch with dbus-launch rather than exec)
CBB=$(echo "$CMD" | grep -Ei -- 'chrome|chromium|brave|iron|opera|slimjet|vivaldi|microsoft-edge')
[ -n "${CBB}" ] && EXE=dbus-launch || EXE=exec
export EXE
...
$EXE '"${SANDBOX}"' '"$CMD"'

Could running Brave with dbus-launch potentially interfere with updating the browser ?

Thanks

[fredx181]

Tested some more and turns out for me that even earlier Brave versions won't run with run-as-spot on BookwormPup64.
On FossaPup all is ok.

@fredx181

Proposal for run-as-spot change: viewtopic.php?p=136162#p136162

I don't use Chromium browsers but based on the discussion in the above post, the following was added to the run-as-spot script in BW64 10.0.9 to address failed opening of the filechooser in Chromium-based browsers.

Code: Select all

#test for chromium-based browsers (if true, launch with dbus-launch rather than exec)
CBB=$(echo "$CMD" | grep -Ei -- 'chrome|chromium|brave|iron|opera|slimjet|vivaldi|microsoft-edge')
[ -n "${CBB}" ] && EXE=dbus-launch || EXE=exec
export EXE
...
$EXE '"${SANDBOX}"' '"$CMD"'

Could running Brave with dbus-launch potentially interfere with updating the browser ?

Thanks

No, tested by changing dbus-launch to exec (as it used to be in older BWpup) and made no difference.

But now looked at ownership of some folders in /home/spot:

Code: Select all

# ls -lA
-rwxr-xr-x 1 spot    spot  295 Dec  8 16:45 .bashrc
drwxr-xr-x 1 webuser 1004 4096 Dec 10 10:56 .cache
drwxr-xr-x 1 webuser 1004 4096 Dec 10 10:56 .config
drwx------ 3 webuser 1004 4096 Dec 10 10:56 .dbus
drwxr-xr-x 2 spot    spot   47 Dec  8 16:45 .didiwiki
lrwxrwxrwx 1 spot    spot    8 Dec  8 16:45 .DirIcon -> spot.png
drwxr-xr-x 2 spot    spot    3 Dec  8 16:47 Downloads
drwxr-xr-x 1 webuser 1004 4096 Dec  8 17:43 .local
-rw-r--r-- 1 spot    spot  580 Dec  8 16:45 README.txt
-rw-r--r-- 1 spot    spot 9868 Dec  8 16:45 spot.png
-rw-r--r-- 1 root    root    0 Feb  2 09:34 .Xauthority

I have no idea why some folders were owned by "webuser" and "1004", can't remember what I did that could have caused that.

Anyway, ran in terminal chown -R spot:spot /home/spot and that fixed the problem for Brave-portable.
@PeteAir perhaps that will fix it for you too.

Later, tested starting fresh with new savefolder and all fine too.

[mikewalsh]

@fredx181 :-

We could always add a stanza to the 'LAUNCH' script, just after where it sets permissions for the 'mini-spot' directory (and others) contained within the portable itself, thus:-

Code: Select all

mkdir -p "$HERE/PROFILE/spot/Brave-Browser" 2> /dev/null
#
chown -R spot:spot "$HERE/brave"
chown -R spot:spot "$HERE/lib"
chown -R spot:spot "$HERE/PROFILE/spot"
#
if [ -d "/home/spot" ]
then
	chown -R spot:spot /home/spot
fi

.....which should take care of that, going forward.

Mike.

[fredx181]

@fredx181 :-

We could always add a stanza to the 'LAUNCH' script, just after where it sets permissions for the 'mini-spot' directory (and others) contained within the portable itself, thus:-

Code: Select all

....
if [ -d "/home/spot" ]
then
	chown -R spot:spot /home/spot
fi

Well, yes, could do no harm, I guess, but in this case I think it was probably me doing something uncommon that caused the wrong ownership.

I have no idea why some folders were owned by "webuser" and "1004", can't remember what I did that could have caused that.

(could be that I modified the savefolder by e.g. copying from using another system, not sure though)

[bigpup]

I tested on a clean install of BookwormPup64 10.0.9
Using a save folder.

Downloaded the Brave portable from here:
viewtopic.php?t=6150
Downloaded Brave-portable64.tar.xz and UN-compressed it.

Opened the Brave-portable64 directory that was made by the UN-compressing.
Inside this directory right clicked on the UpdateBrave script file and selected to run in terminal.
This downloaded the latest version of Brave browser and updated it.

Left clicked on the LAUNCH script file and Brave browser opens and runs.

Notice all of this update is done with Brave browser not running.
.

Screenshot.png (42.45 KiB) Viewed 2186 times

.
.
Note:
Running the LAUNCH script file in a terminal, does show some errors, but Brave browser seems to start and run OK.
The errors are about kwallet and kde.klauncher, which are not in Puppy Linux.
.
.

[mikewalsh]

Note:
Running the LAUNCH script file in a terminal, does show some errors, but Brave browser seems to start and run OK.
The errors are about kwallet and kde.klauncher, which are not in Puppy Linux.

@bigpup :-

Heh. Yeah, well.....every Chromium-based browser in existence does that. It's endemic to the breed, and is directly due to the way the Chromium Project have developed the source code, right from day one.

The browser was always intended to display an on-going debug session when started from the terminal, ALL THE TIME THE BROWSER IS RUNNING. It's meant as a trouble-shooting aid for their devs, so they can pin-point issues & get patches sorted out ASAP.

Even when it's running A-OK, it's still rabbiting away in the console. I've never yet seen a distro where one of these browsers DOESN'T do this, because they're designed to "comment" on every single line of code, AS it's executed.

999 times out of 1000, you can safely ignore all this........except for the rare occasions when something obviously IS wrong. Then it actually comes in useful!

Mike.

[PeteAir]

Thanks guys, up and running, with the spot terminal

Pete