Arch Linux User Repository

@MarsSeed and others, the package cannot be updated because there is no binary in the latest release, issue concerning this here. Only once that is fixed I can update the package, please do not mark it as out of date in the meantime.

@MarsSeed and others, the package cannot be updated because there is no binary in the latest release, issue concerning this here. Only once that is fixed I can update the package, please do not mark it as out of date in the meantime.

@tyjak it is working on my machine with the same kernel. What steps do you do exactly?

Not working: invalid memory address or nil pointer dereference (x86_64 Linux 6.7.6-arch1-2)

At the moment this package cannot be updated because the assets in the repo are missing. Once that is fixed I will update it. See issue #514

Thanks @gilcu3 for adopting this

you can avoid to use which that is an external binary that needs to be installed, use command -v that is built-in in bash and zsh

@NicholasAsimov, It doesn't seem like PKGBUILDs support "or" in the dependencies array, that is, i can't put "firefox or firefox-nightly". Putting it as an optional dependency alone won't make it build without wanting firefox. Typically these cases are avoided by having 'firefox-nightly' provide 'firefox', but here the firefox-nightly package isn't designed to replace firefox, but stay separate.

Unfortunately I don't have a solution for this, you'll need to change the depends line manually. Perhaps put in a feature request for dependency "or" support in PKGBUILDs?

Hello! Can this package also optionally depend on firefox-nightly from AUR?

And you found that bug in 1.4.9!

Not so much "found" as "spent a couple hours digging into how go/bindata works to decode the not-very-helpful error", because I too put the xpi in a different place (just left it in $srcdir), it was gnu strings that helped me find it, which I was using to try to make a binary without any absolute paths from the host machine.

Are you going to keep this as the canonical AUR Browsh package?

If you look around the AUR, you'll notice it's common to have 3 packages for foss, a normal from-source one with just the program name, a -bin for a pre-compiled version, and a -git (or -hg/-svn/etc) one for when you want to check out the absolute latest code.

now I can allow go-bindata to compress the XPI? I'm not sure that'll gain much

It took ~300k off the final binary of 1.4.9 (when not using UPX), not much, but not nothing, either. Do you have control over the compression level of the XPI? the zip format does allow for no compression, so you can instead use only bindata's gzip compression (or UPX instead of either). As you probably understand, it's best to compress once with the best format available, gzipping an uncompressed zip stream should be more effective than a compressed zip stream, if for no other reason than the gzip stream can compress the otherwise uncompressed metadata in the zip file.

it is perfectly possible to self-make the XPI without any intervention from Mozilla, the only caveat being that you have to disable addon signing checks in Firefox.

This is not unexpected. wouldn't that be at least per-/profile/, for which browsh uses it's own profile anyway? either way, this would be necessary for a -git package, and should be the default for the 'browsh' package as well (being a from-source package). If I can implement something to compare xpi sources, I could even toggle the option for an unsigned xpi only when modified sources are found, best of both sides.

Arch users really are a different breed! I've a pretty good idea what you went through getting this PKBUILD working, and it's not easy. And you found that bug in 1.4.9!

So what's the situation now. Are you going to keep this as the canonical AUR Browsh package? And do you want any web hook triggers from a post release?

That's a nice idea about providing a checksum for the XPI source code. Eg; could I hash the pre-minified, pre-packaged JS before it's bundled into the XPI. Then somehow that could be reversed engineered from the XPI and hashed again during PKGBUILD installation? BTW, I actually want to disable the minification because I want to have the correct line numbers for stacktraces in production.

Oh, right and now I can allow go-bindata to compress the XPI? I'm not sure that'll gain much as the XPI is already just a renamed .zip.

I don't think I mentioned it before, but it is perfectly possible to self-make the XPI without any intervention from Mozilla, the only caveat being that you have to disable addon signing checks in Firefox. Which as far as I know cannot be done on an individual addon basis. Requiring Browsh user's to downgrade their browser's security is not something I want to do. But I think it's totally fine as an option. I think I can even inject that preference automatically using Firefox's Marionette, so it could be as easy building Browsh with a conditionally set variable.

Yeah a browsh-git sounds great! That would actually be a perfect use case for that previous paragraph.