You are not logged in.
Pages: 1
The opal package is currently using version 3.10.11. According to the upstream site listed in the package (http://www.opalvoip.org), the latest stable release is "Stable 2" of 3.16 (3.16.2).
Similarly, ptlib is currently version 2.10.11, but upstream's latest stable release is 2.16.2.
I tried flagging both packages out-of-date per the documentation:
"If you notice that a package is out-of-date (i.e., there is a newer *stable* release available), then please notify us by using the Flag button in the Package Details screen. This will notify the maintainer(s) responsible for that package so they can update it."
I had noticed the "stable" qualification and made sure to check that first - upstream explicitly labels the new release as "Stable".
However, it looks like the flag was removed from both packages and they're still on the older versions. I'm guessing there's some additional context I'm missing - could someone here help?
The reason I ask is that I'm working on an AUR package for FreeSWITCH 's mod_opal, and it requires at least version 3.12.8 of opal.
Thanks,
David
Last edited by opencode (2016-10-27 00:22:20)
Offline
You could always use the Arch Build System to build a newer version yourself. Get a PKGBUILD out of it, and often all you have to do is to change the version numbers in there to successfully create a new package.
Offline
To get some more context, I'd probably try sending an email to the mailing list, or potentially just contacting the maintainer directly to find out what's going on.
Offline
I suppose it's being held back by ekiga. That wouldn't justify unflagging it though, since it is indeed out of date. IMO in these cases (package update being deliberately held back and third party software requiring a newer version) it should be acceptable to add an AUR package (opal3.12) with the newer version.
Offline
The only reason why we have opal and ptlib in extra is because of ekiga. Ekiga cannot work with a newer version, so we cannot and will not upgrade opal/ptlib.
If we decide to drop ekiga from the repositories because upstream doesn't care about releases, we'll drop opal/ptlib with it.
Offline
Thanks for the context - that makes sense.
What would you think about naming the packages opal310 and ptlib210 to reflect the fact that they intentionally provide an older version? That could help clarify when you'd want them to be flagged as out-of-date.
https://wiki.archlinux.org/index.php/Ar … age_naming
https://wiki.archlinux.org/index.php/Py … d_versions
Then I could create opal and ptlib packages in AUR as dependencies for freeswitch, and they could float with the latest stable version as normal. (And if anything were added to community or extra that needs either of these packages, the naming would work out like it does for packages like qtlib or python.)
Thanks,
David
Offline
Pages: 1