build and install script addition

[beadon]

• 06-29-2023 14:50 PST beadon - script created for building and installation
• installation script updates

[hoehermann]

Thank you for the suggestion, but I do not want this script in the repository. It implicitly removes the build cache which triggers a re-download and re-build of all go packages every time (on my system, that takes minutes). In my opinion, the build instructions in the README are sufficient for users to adjust for their needs.

[beadon]

oh, yes, the first step removes the build directory. This can be changed.

I am attempting to make it slightly easier for the beginner to install the plugin. Classic linux software and build installations have always been : ./configure ; make ; make install today these steps are quite muddled with lots of different toolchains and languages.

Perhaps a better way to keep the cache would be proposed changes to the cmake/make files. From here, control to add different targets like : clean ; install ; and modify the default target to manage the build directories accordingly ?

From here, it's a shorter hop to packaging concepts to get it into systems like apt.

Are you open to a proposal to a more more native way to manage build directories ?

[hoehermann]

Before I can make up my mind, I need to understand the problem and how the script is going to solve it.

For the Ubuntu users who do not want to compile themselves, I offer pre-built binaries. They also work on reasonably recent versions of Debian.

For everyone else, there are build instructions. The ./configure ; make ; make install has been well established in the 90s. Indeed, today, there are many other tools. However, cmake .. ; make ; make install is also well known. It is literally only the configuration step that is different.

If the script exists, people will want to use it. But does it work on Debian? How about Arch or Alpine Linux? Gentoo? Why does it automate the build (which are trivial), but not fetch the dependencies (which are annoying to resolve)? I do not want to maintain it. Do you?

Experts on the other hand, will not use it because they are comfortable with the build instructions. I think the demographic that may benefit from the script is very small. For these reasons, I would rather not have the script to make clear: Either use the pre-built binaries or build it yourself, but expert knowledge is required.

[beadon]

Oh I see the pre-built binaries now. I was not aware this was available!!

It's possible I missed the documentation for the binary releases, but on re-reading I don't see this in the README.

I am running Ubuntu 23.04 and didn't have an option to install this plugin via apt, so I dutifully took steps to improve the processes leading towards binary creation and ultimately packaged apt releases.

The problem I want to solve is:

• spur increased adoption of this plugin by making it easier to use and install, making any regular(?) updates simple for development purposes
• selfishly -- reduce the number of concurrent messaging applications a person needs to have open ( discord, whatsapp, telegram, SMS, IRC, Slack .. to name a few, with a few different personas on each platform )

Including Ubuntu into this should assist with the fairly large audience to cover the issue of #1 - increasing adoption and make software updates easier for the end-user.

So , to tackle the root of this then I am proposing : a package script driven via cmake to turn the binaries you have into an apt package available for Ubuntu 23.04 and beyond.

Note: It appears that the binaries supported today cover only through 22.04. The naming convention with Ubuntu is easier than it looks , the 2-digits out front indicate the year (23 = 2023 ) and the 2 digits at the back indicate the month 04 = April. These bus-stop releases mean that there are 2 major releases a year, with one in April and one in December. Which just means there are a maximum of 2 places per year where packages should be tested/recompiled as needed.

What do you think ?

[hoehermann]

What do you think?

I am grateful for your input.

I don't see this in the README

It is there, in the section "Build". I can move the link to the top, so it becomes more visible.

easier to use and install

Installing won't get any easier than "download into folder and restart Pidgin", I am afraid.
Ease of use is another topic. The plug-in is mostly geared to how I want it to be. I have been working together with Peter to identify features for other (especially blind) users. What would you like to see?

reduce the number of (…) messaging applications

That is precisely why this plug-in exists. :)

(…) there are a maximum of 2 places per year where packages should be tested/recompiled as needed.

Unfortunately, it is a bit more complicated than that. This plug-in is using whatsmeow, which – as far as I understood – is a reverse-engineered variant of the WhatsApp Business API. Every time there is an update to the official WhatsApp client, whatsmeow needs an update and consequently this plug-in needs an update. This happens roughly twice a month. On the buildbot, you can see this with version whatsmeow_1.11.1r221. I did not change anything in the plug-in, yet there were about twenty updates to whatsmeow. Sure, some changes are non-breaking and you can get away with using an old version for quite some time, but it definitely is more than "twice a year". 😐

option to install this plugin via apt apt package available for Ubuntu 23.04 and beyond

This has been requested numerous times (last time in #116). Keep in mind that I am a single guy who maintains this plug-in in his spare time. I simply have no resources to provide packages. I guess I would need:

• increased diligence while developing, maybe code-reviews
• a build environment for each distribution (and version) I want to support (that would be Ubuntu, Debian and Arch, maybe Gentoo and Alpine)
• an automated testing environment for each of them, including an Android emulator to test the linking process against the official client
• money to pay for all that
• time and will to maintain the entire system
• become a maintainer in the targeted distributions

If you want to do that, I am completely game. You already have read access to this repository. Set-up the systems, apply for becoming a maintainer, handle the communication,… for me it is way out of scope. I am sorry.

[beadon]

Ok, I can take steps along this maintainer path -- I am unsure of the time commitment I can offer right now.

Immediately I can offer:

• increased diligence while developing, maybe code-reviews --- Happy to code review, this helps me stay sharp.

• a build environment for each distribution (and version) I want to support (that would be Ubuntu, Debian and Arch, maybe Gentoo and Alpine) -- I would recommend we prioritize these, I can move along this path once a testing framework is agreed. Initial suggestion is jinja, more research required.

• an automated testing environment for each of them, including an Android emulator to test the linking process against the official client -- Could explore this, unsure why we need to link to the official android client ?

• money to pay for all that --- Not seeing a cost here other than just time ?

• time and will to maintain the entire system -- I can provide some time :) Happy to be a "cheerleader" too to get that "will" portion up :)

• become a maintainer in the targeted distributions -- I will need to do a bit more research here for certain distributions - Ubuntu / apt packaging being the primary target. Not impossible, just unsure of the time commitment just yet.

[hoehermann]

Your enthusiasm sounds good.

build environment for each distribution I would recommend we prioritize these

My suggestion: You start with current Ubuntu LTS + newer non-LTS releases.

an automated testing environment why we need to link to the official android client?

The linking process is one of the flaky parts. Some test cases include:

• delete account in Pidgin, link "for the first time"
• log-out via Pidgin action, link again
• log-out via phone, link again
• delete whatsapp.db, but not account, link again
• more extreme: reset App on phone, link again

Normally, I have to sit there and click on buttons, hold my phone to the screen for scanning the QR-code. Very tedious. I think we need to have that automated. I do not even know what is necessary to feed the QR code into a virtual webcam which will then be available within an emulated Android.

Further test cases include:

• establish a connection
• pull contacts from the server for the first time
• pull contacts from the server updating existing buddies
• add a contact to the buddy list
• initiate a direct conversation
• initiate a group conversation
• receive a message initiating a new conversation (group and direct)
• receive a message for a currently active conversation (group and direct)
• receive a message of every type (cross product with the cases above)
• send a message of every type we want to support (cross product with the cases above)
• be added to a group conversation
• try to participate in a group conversation we have been kicked out of
• check for consistency of list of participants
• and many more

Currently, I skip most of the testing, hoping for the best. However, this way I introduced many bugs I did not catch. This is okay for a "some guy on github" project, but not for an officially packaged product.

money to pay for all that Not seeing a cost here other than just time

I only run one server (hehoe.de – the one that offers the buildbot). It costs 60 € per year, but cannot do virtual machines (so limited to producing builds for the Ubuntu version it itself is running at). Machines for the systems mentioned above will cost money, too.

time and will to maintain the entire system get that "will" portion up

If you manage to cure my depression, that would be great. Being the pessimist that I am, I do not expect that, though.

become a maintainer in the targeted distributions unsure of the time commitment just yet.

There are some people describing their work here: https://www.reddit.com/r/linux/comments/kmat5j/what_exactly_is_expected_of_a_package_maintainer/
You can expect that being the maintainer of this plug-in is more time-consuming once it is available as a package.

On average, I spend about five hours per week on this project. That includes communicating with users (like writing this message right now). With that, I am at my limit (bear in mind that I have other hobbies and projects, too). I cannot do any more work. Consequently, every request that is coming in via the Debian/Ubuntu issue system would need to be addressed by you. You are in that position for as long as the package is listed. That is the commitment you will get yourself into. You will receive virtually no payment except for kind messages and maybe a small donation once a year, but occasionally someone will insult you. I am in no position to help you there. In case I quit my day job and miraculously find a sponsor who pays my rent while I do open-source development I could do that, but I do not see that happen. ;)

[hoehermann]

How about starting slowly (it just came to my mind): Instead of a build-script, you could look into supporting dpkg-buildpackage. That would be a good first step towards providing packages. I never figured out how write the control files.

[beadon]

Sure, crawl before running sounds good. I should have some time this weekend to dig in a bit more.

[beadon]

step 1 ... https://packaging.ubuntu.com/html/getting-set-up.html

[beadon]

step 2- fixing gpg local keys -- running down the path of an approved package manager for Ubuntu since it cover the packaging process and best practices.

step3 - using pbuilder to build a local packaging environment. sudo pbuilder create --distribution lunar

[beadon]

step4 - register with launchpad, import keys, etc ..

[beadon]

step5 - using bzr , begin packaging ..

[beadon]

bzr is ... strange.

[beadon]

notably -- found an example pidgin plugin packaged and delivered with apt. skype4pigdin --- reference: https://github.com/EionRobb/skype4pidgin/blob/master/skypeweb/README.md

checking into the cpack target in their cmake files ..

[beadon]

notably -- found an example pidgin plugin packaged and delivered with apt. skype4pigdin --- reference: https://github.com/EionRobb/skype4pidgin/blob/master/skypeweb/README.md

checking into the cpack target in their cmake files ..

After MUCH digging, it looks like their packaging system is broken ... raised an issue over there, will chase.

[beadon]

Fixed the skype4pidgin issues with cpack -- seems there was a just a typo in their config which prevented the package system from doing the right thing ! (no errors indicating a problem either!). anyhow -- building a similar cpack now for purple-gowhatsapp -- making good progress.

[beadon]

Good news ! I was able to get cpack working properly with a little bit of work. Pushed a PR for inspection, I think the libs are going to the right places -- double check please.