Arch Linux User Repository

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.

Well that wasn't easy... Go is really fussy about where it wants things. I also got caught up regarding how go-bindata works (browsh was complaining about not finding /browsh.xpi).

Anyway, it works now. I also included UPX support as an option. (@tombh, it seems you forgot to remove "-nocompress" from your go-bindata command when you decided to remove UPX compression)

Next step browsh-git? (that is, a versionless package that pulls up-to-the-moment sources from git, this will require some way of self-making the xpi to make sense...)

PKGBUILDs are as simple as they come, they're just a bash script which sets some variables (basic package information), and defines one or more functions related to putting the package together, with the only required one being package(), all it does it put stuff in $pkgdir (./pkg), as if it's root (/). If you can install something manually on the command line, you can read and write a PKGBUILD. I'll see if I can put together a 'browsh' package now.

There's no need to avoid optimisation of the files in the .xpi, but I would like to add something in the PKGBUILD to compare it with the provided sources, to ensure they're identical, this can be done if the PKGBUILD included the same optimisation tasks you use.

Okay, I've refactored the build process now. I think it's in a few readable steps: https://github.com/browsh-org/browsh/blob/master/interfacer/contrib/build_browsh.sh It just depends on Golang and curl. Although I'm a regular AUR user myself, I have to admit I've never actually really looked at any build scripts. Does this one look okay?

Edit: @Mikurok: yes you're right about the .xpi format, it's just a zip file with JS source files in it. Although at the moment the JS is minified, I'm going to undo that, it shouldn't make any difference to the size anyway as it's zipped.

@tombh, That sounds great. From what I understand, the xpi contains only scripts taken uncompiled from the original sources, right? so that would at least make the whole package auditable/readable. While I'm not an authority on this, I'd have to agree that would be enough for a non-bin package. Is it really absolutely necessary for a webext to pass through mozilla to be usable, even with browser modification?

Something I still don't like about this is the fact that part of the source code cannot be changed, not without presumably having to go through whatever steps are needed to make a new webext with mozilla. This may not be your fault, though.