Arch Linux User Repository

PSA: I've started hosting this and also many other packages I maintain in the AUR as prebuilt packages in my repository for those that want to install them using pacman without messing around with building from the AUR.

Thanks @alerque, for maintaining this package. I had an issue with the compilation, so I had to apply the next patch:

--- a/pjnath/src/pjnath/upnp.c
+++ b/pjnath/src/pjnath/upnp.c
@@ -423,7 +423,7 @@
 }

 /* UPnP client callback. */
-static int client_cb(Upnp_EventType event_type, const void *event,
+static int client_cb(Upnp_EventType event_type, void *event,
                      void * user_data)
 {
     /* Ignore if already uninitialized or incorrect user data. */

Are these deps needed alsa-lib libsamplerate util-linux?

Ahoj,

• what is the config_site.h used for?
• License identifier should be GPL-2.0-or-later, since the provided COPYING file states

  either version 2 of the License, or
  (at your option) any later version.

Regards and thanks for the package!

Thanks for the insights. Much clear now in my head.

..., though I guess pjsua would build slightly faster because it simply does less.

Yes. That is a good point worth considering for end users. These pjproject/pjsua tools always take a huuuuuuuuuuuuge time to build on my PC. Dont really know why (written in C ? that shouldnt be the case right ?)

Anyways

Non propietary, non GUI, non bloated, CLI friendly tools are a rare sight on Archlinux official and AUR packages.

But , like pjsua, they are a nightmare to configure to end users. I spent hours to finally make it work, with my user name, password and SIP provider. And I say this a very proficient command line user. Horrible documentation for configuring the client.

Inconsistent and imprecise instructions for configuring "addresses", "username" and "password" Is it "sip:xx@yyy:port" or "sip://user:pass@foo.bar" Or ... Slash, colon, @, port etc where exactly ? etc etc. The docs waste too much time in non essential stuff (tuning, proxys, codecs, bitrates ...) without a separate simple QUICKSTART.

I guess the original developers assume we must also be working in telephony, programming and setting up daily sip related tools. And be cozy and familiar with all those terms Real/Registar/STUN/resolver/etc ...

There are pages and pages of docs and READMES. But there is a lack of distinction in documentation for end users and documentation for developers.

The pjsua package only builds and installs the CLI tool itself. This package does that, and also installs the development headers (which you'd need for other applications using these libraries), and also builds the python bindings (as python-pjproject split package).

If you're only interested in the shipped CLI tool anyways, it functionally doesn't matter which one you install, though I guess pjsua would build slightly faster because it simply does less.

re checksum: Can confirm, I'll push an updated PKGBUILD shortly.

sha256sum of the 2.14 version has changed to 5805c1171acab4af9684d7ad096dcb92f71fc42809852144e97e1413468c9981

Could the maintainers please clarify ?

As an end user I am still confused. I am looking for the pjsua end user cli tool to install from the AUR or from official Archlinux packages. Not a library, not stuff for developers.

jfernandz commented on 2022-11-30 16:29 (UTC) (edited on 2022-11-30 16:30 (UTC) by jfernandz)

I'm not sure, but ... I'd say this package should have a conflict with pjsua package

alerque commented on 2023-02-23 10:40 (UTC)

There is no pjusa package listed in official Arch repos or the AUR, so .... ```

???

There is in fact, https://aur.archlinux.org/packages/pjsua.

I am still not quite sure what the goals and differences of the different PKGBUILD's "pjsua" and "pjproject" are.

Apart from some optional python dependencies ???

It would be nice if the PKGBUILD maintainers of both, collaborated, so that more eyes were available, and perhaps avoid reduplicating work. With enough "Votes" maybe this could one day turn into an official Archlinux package.

It would also be less confusing for AUR end users to know which PKGBUILD to install exactly.

shasum errors:

==> Making package: pjproject 2.14-1 (Sat 03 Feb 2024 12:15:13 AM WET)
==> Retrieving sources...
  -> Downloading pjproject-2.14.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
100  9.8M    0  9.8M    0     0   462k      0 --:--:--  0:00:21 --:--:-- 2191k
  -> Found 0001-Don-t-build-Java-bindings.patch
  -> Found config_site.h
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
    pjproject-2.14.tar.gz ... FAILED
    0001-Don-t-build-Java-bindings.patch ... Passed
    config_site.h ... Passed
==> ERROR: One or more files did not pass the validity check!
 -> error downloading sources: /dev/shm/aurydesty/pjproject
         context: exit status 1

Validating source files with sha256sums...
    pjproject-2.14.tar.gz ... FAILED

-sha256sums=('d90c225247f6c0e896c8b79130f3fb6ab4f9585670bc5f19edf79de4e024f511'
+sha256sums=('5805c1171acab4af9684d7ad096dcb92f71fc42809852144e97e1413468c9981'

@jfernandz The main project and the python bindings are built from the same sources released at the same time, hence the split package. This is the correct arrangement and your AUR tooling should be fixed to handle this, there are many such projects around.

There is no pjusa package listed in official Arch repos or the AUR, so there is no reason for this package to list it as a conflict. If there are externally built packages somewhere the onus is on them to mark conflicts with anything available in the Arch ecosystem. Anything installed from source is on you.