Basilisk 2022.08.06 Released!

[Basilisk-Dev]

Basilisk 2022.08.06 has been released! This is the first release by the new Basilisk Development Team and we thank everyone who's helped make this possible.

This is the first release since January. There have been a significant number of changes to the UXP platform during that time. See the release notes for more information.

As part of this release we have restored 32-bit Windows builds.

IMPORTANT: The vendor has changed from "moonchild productions" to "basilisk-dev". To transfer your existing profile to the new Basilisk versions moving forward please do the following:
On Windows: Copy %appdata%\Moonchild Productions\Basilisk to %appdata%\Basilisk-Dev\Basilisk
On Linux: Copy $HOME/.moonchild productions/basilisk to $HOME/.basilisk-dev/basilisk

Autoupdates will not work from Moonchild Productions releases to Basilisk Development Team releases due to changes in the compression algorithm used for the autoupdate files. You will need to manually perform an update from a Moonchild Productions version of Basilisk to our version. After this one-time manual update autoupdates will work again.

[Michaell]

It's working. FWIW to anyone who may use it, Classic Theme Restorer is causing some problems in addons manager. Tried 2 versions of CTR. Got it working. In CTR, uncheck "Addons list: show addons version" (this is with CTR ver 1.59 but may work the same in other vers).

[micwoj92]

Anyone on Arch based distro using this? I could reupload and maintain AUR packages if there is demand.

[smallhagrid]

Ubuntu Mate user here.

Got this new build - extracted it - tried to open it.
The executable was not 'application/x-executable' but had the correct permissions.

Please tell me how I may fix this so as to get it working ??

Thanks.

[andyprough]

Ubuntu Mate user here.

Got this new build - extracted it - tried to open it.
The executable was not 'application/x-executable' but had the correct permissions.

Please tell me how I may fix this so as to get it working ??

Thanks.

Open a terminal and cd inside the folder that you extracted, then do:

Code: Select all

./basilisk

That should run it.

If you are trying to double-click on the executable in a file manager like Mate's caja, the file manager may not be set up to automatically run it as an executable.

[smallhagrid]

OK...you are saying to run it as if it is a script file, but I still wonder=>
Why is the latest version not set up with the same 2 files natively executable as it has been right along ??

[Basilisk-Dev]

Anyone on Arch based distro using this? I could reupload and maintain AUR packages if there is demand.

I have no issues with you creating an AUR package that installs the official binaries on the user's system. If you're doing anything other than re-releasing the official binaries in your AUR package you will need to compile a build with --disable-official-branding. You have permission to create a .desktop file so that Basilisk shows in the desktop environment's application menus.

[andyprough]

OK...you are saying to run it as if it is a script file, but I still wonder=>
Why is the latest version not set up with the same 2 files natively executable as it has been right along ??

Not sure, I've been executing files like that from the command line for quite a long time, probably 20+ years. I'm not knowledgeable about how distros or file managers decide which files are executable using a mouse click. Maybe someone wiser than me can weigh in.

[smallhagrid]

Simple...and since Basilisk is my most used browser I prefer NOT to need to use the CLI to open it.

Desktop launcher with the correct icon:

Name: Basilisk
Type: Link to executable (application/x-executable)
Link target: /home/user/apps/basilisk/basilisk
Location: /home/user/Desktop

The 2 correctly marked files in the older version have different properties than the 2 in the latest version.

[micwoj92]

I have no issues with you creating an AUR package that installs the official binaries on the user's system. If you're doing anything other than re-releasing the official binaries in your AUR package you will need to compile a build with --disable-official-branding. You have permission to create a .desktop file so that Basilisk shows in the desktop environment's application menus.

I'm well aware of this limitation. I have used old .desktop from before it was deleted.

Question, is gtk2 still needed at runtime?

[loxodont]

Thanks for the good news, but as much I appreciate an updated Basilisk 32-bit build, the setup on Win7-32 tells me it can only be installed on a 64-bit system.

[smallhagrid]

Glad that I can just stay with the older & correctly opening & functioning version.
Perhaps this will get fixed in some later version.

[Moonchild]

Thanks for the good news, but as much I appreciate an updated Basilisk 32-bit build, the setup on Win7-32 tells me it can only be installed on a 64-bit system.

This will require some small adjustments in the installer script - I believe some specific changes were made to it when 32-bit support was removed from Basilisk (it's been a while). Should be simple enough to just revert that commit in that case.

[Basilisk-Dev]

This will require some small adjustments in the installer script - I believe some specific changes were made to it when 32-bit support was removed from Basilisk (it's been a while). Should be simple enough to just revert that commit in that case.

Thanks for pointing that out. I wasn't aware of that change. I did test the 32-bit build but I tested it on a 64-bit OS so I didn't run into this issue during install.

Thanks for the good news, but as much I appreciate an updated Basilisk 32-bit build, the setup on Win7-32 tells me it can only be installed on a 64-bit system.

I will make sure to test on a 32-bit Windows OS in the future, as I mentioned above I did test the 32 bit installer but I tested it on a 64 bit OS. This will be fixed in the next release.

In the meantime you can run the standalone Basilisk Win32 binaries located here. After you extract the 7z archive run basilisk.exe and it should work for you.

Glad that I can just stay with the older & correctly opening & functioning version.
Perhaps this will get fixed in some later version.

I have not installed the MATE desktop to see if I can replicate your issue but I did test in Thunar and PCManFM and TDE's version of Konqueror. Double clicking the basilisk binary did indeed launch basilisk in all three of those file managers. This is either an issue with Mate or with your specific configuration. Sorry that I can't help further as I don't have access to your specific machine.

[Moonchild]

I wasn't aware of that change.

I looked it up, you should have a look at commit 143b0fff0bbea33499d4a1f08036431dde2bc76b

[GWL894]

I have not installed the MATE desktop to see if I can replicate your issue but I did test in Thunar and PCManFM and TDE's version of Konqueror. Double clicking the basilisk binary did indeed launch basilisk in all three of those file managers. This is either an issue with Mate or with your specific configuration. Sorry that I can't help further as I don't have access to your specific machine.

FWIW, I have same issue with Mint and Cinnamon desktop. I see that there are three files in the old Basilisk --- “basilisk”, “basilisk-bin”, and “plugin-container” --- that the file explorer shows as “Type: Program (application/x-executable)”, but in the new release those three files are identified as “Type: shared library (application/x-sharedlib)”.

[loxodont]

This will require some small adjustments in the installer script - I believe some specific changes were made to it when 32-bit support was removed from Basilisk (it's been a while). Should be simple enough to just revert that commit in that case.

Thanks for pointing that out. I wasn't aware of that change. I did test the 32-bit build but I tested it on a 64-bit OS so I didn't run into this issue during install.

Thanks for the good news, but as much I appreciate an updated Basilisk 32-bit build, the setup on Win7-32 tells me it can only be installed on a 64-bit system.

I will make sure to test on a 32-bit Windows OS in the future, as I mentioned above I did test the 32 bit installer but I tested it on a 64 bit OS. This will be fixed in the next release.

In the meantime you can run the standalone Basilisk Win32 binaries located here. After you extract the 7z archive run basilisk.exe and it should work for you.
...

Thanks very much again ... the standalone Win32 binaries run fine and seem to play very well with my old profiles, themes and add-ons

Greets

[Nigaikaze]

FWIW, I have same issue with Mint and Cinnamon desktop. I see that there are three files in the old Basilisk --- “basilisk”, “basilisk-bin”, and “plugin-container” --- that the file explorer shows as “Type: Program (application/x-executable)”, but in the new release those three files are identified as “Type: shared library (application/x-sharedlib)”.

I am also seeing this exact same thing on KDE Neon, which is using KDE 5.25.4 and is based on Ubuntu 20.04.

This is either an issue with Mate or with your specific configuration.

No. You now have reports of it happening on a at least three different flavors of desktops (MATE, Cinnamon and now KDE) and I can assure you there is no problem with the configuration of any of my KDE systems. This only started happening on my systems with your new release of Basilisk, and this has only happened with your new release of Basilisk. No other recent software updates have changed files from executables to shared libraries. All I did here was extract those three files from your tar.xz into a temp folder and look at their properties, so this is how they are being distributed in your .tar.xz file. Something in your release engineering process for Linux is different than how Moonchild did it and is causing this, because when I extract those same three files from one of Moonchild's old .tar.xz files they end up identified as "executable," not as "shared library."

[jobbautista9]

That's strange. Here on my XFCE, Thunar recognizes them as "executable", not "shared library". As you can see in the ICU file, I'm using the new Basilisk.

EDIT: Ah, didn't see the post by Basilisk-Dev about it working fine in Thunar. Still strange that three different file managers don't recognize them as executables though...

[Moonchild]

because when I extract those same three files from one of Moonchild's old .tar.xz files they end up identified as "executable," not as "shared library."

I didn't do anything special when building Basilisk. Just built from the command-line with ./mach build which placed everything proper in the dist/bin folder, then used ./mach package to wrap it up in the .tar.xz. I did however build in CentOS, which may be something causing a difference? I'm by no means a Linux expert so I really don't know about those kinds of oddball oddities. How is the file MIME type stored in a .tar.xz, anyway?