Pale Moon forum

So after 29.0.0 released I asked current palemoon package maintainer what to do with -gtk2 -gtk3 names and he said that he has no interests in compiling gtk3 package. So i created palemoon-gtk3 which uses gtk3 and palemoon still uses gtk2 as before the update.

Question 1: Should palemoon be renamed to palemoon-gtk2?



There is also palemoon-bin package which used gtk2
Questions 2/3
Should there be just new palemoon-gtk3-bin and palemoon-bin still uses gtk2 ?
or
Should there be both -gtk2- and -gtk3- for naming consistency with upstream binary?

I will provide official answers from this topic to maintainers of these packages.

If you have control of them then perhaps not else you will cut off current users.

I only have control over palemoon-gtk3 which I created yesterday. I think your answer means to let palemoon and palemoon-bin be gtk2. I will create `palemoon-gtk3-bin` then if current palemoon-bin maintainer does not respond. Thanks for quick response.

The AUR Community is rather hostile to us so maybe you shouldn't do that.

I've went through comments from last year from palemoon and palemoon-bin packages and have not seen any hostility (or negativity) besides problems with PGP keys (but as this is Arch Linux wide problem, you can see such comments on every popular packages which has PGP checks). I am saddened you had negative experiences with us. But I still plan to make -gtk3-bin, because there are sure people who would find this very convenient.

Some of them invaded the IRC channels after the bsd incident trying to trap us in a series of confrontational questions designed to take statements out of context and trap us in a web of circular illogic. I saw through the scheme and then there was a succession of harassment and bullshit accusations broadly at the project and specifically to me.

Aside from that there is a history of not following branding rules for how to build the software. But they afaik are currently compliant or have abandoned the effort.

Ah, Thanks for clarification I am not IRC user so I was not exposed to that.

Also really the last question which I forgot to ask in my first post. There is also https://aur.archlinux.org/packages/palemoon-git/ , it has not been updated in long time, no one stepped up to update so it seems like noone builds that. Is it fine to update it (+ eventually change the build to gtk3) or should it rather be deleted from AUR?

Well it would be best if someone non-hostile and bothers to interact and work with us were to gain control of those.

Sure, I will add it to my TODO list, will post updates in this thread if that's fine.

Ok, so it was trivial to do, claimed package just in case, but before I push changes, should it be based on master or release branch?

(In meantime I'll make and push palemoon-gtk3-bin)

What did it do before other than abuse our infrastructure?

Master branch.

Small update. updated palemoon-gtk3 to 29.0.1 (and currently building on my machine), made palemoon-gtk3-bin and just waiting for platform update on git with fix for Linux build so I can finally push updated pkgbuild for palemoon-git

Please make sure to never release anything before we do.

For AUR i just need to bump git hash since then it's build on user's machine so as soon as I saw email with notification about newest release I just updated. But will remember for future to only bump after official LINUX binary is released.

Well you are just cutting it close on an emergency release is all.

I really need to look at what you are telling it to do as well. Kinda hoped you'd hold off until you got the ok first but yeah.

Ok, before I do any wrong moves in the future, here is the PKGBUILD for current version alongside with mozconfig. I will now only start pushing updates when someone from official team reviews it and says it is okay.
Any questions are appreciated.



The PKGBUILD for -git version is exactly the same with the exception that is has source so it checks for any updates on master branch and the version is generated using

So it looks as follow: 29.1.0a1+r(x)(y)
where x is number of commits and y is git hash

Thanks for bearing with me

The release branch. Infact it would be best if you used the release tag and ensured the platform relbase tag is used as well unless you are going to trust the submodule commit pointer which is valid if you use the release tag on the application repo. Especially because sometimes tags are moved ahead of final release.

The release branch.

So you mean to use it for -git version? The release branch (or rather commits from it) are always what the stable build is build from.

Infact it would be best if you used the release tag and ensured the platform relbase tag is used as well unless you are going to trust the submodule commit pointer which is valid if you use the release tag on the application repo.

The commit hash is always taken so it's same for release, example: 29.0.1_Release has sha a4137e3a09 (which is used in PKGBUILD) and 29.0.0_Release had 79ff7796e5 (which was used for the 29.0.0 version)
Here is trust to the submodule commit pointer. So it should be valid because the sha I use always equals the tag.

Especially because sometimes tags are moved ahead of final release.

I do not understand what you mean by that.

Every once in a while the release tag gets moved to a different commit.. Maybe a last minute change, a mistake, or some such. That is why we use the tags in the first place.

Which is also why we warn not to jump the gun.