[Dev] [prosody-community-modules] proposed package for prosody's modules

Wael Karram wael at waelk.tech
Wed Aug 17 15:44:13 GMT 2022

On Wed, 17 Aug 2022 15:41:43 +0200
Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:

> On Mon, 15 Aug 2022 19:26:25 +0200
> Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:
> > PS: Note that it is also possible to send patches for review. This
> > way we can reuse your commit message, so if you have interesting
> > things to add there they get included in the commit.  
> By patches I meant something like sending a single patch to add the
> prosody-community-modules PKGBUILD in abslibre. 
> If the patch is not pushed (yet) in abslibre and needs modifications,
> it's usually easier for maintainers to review a new version of that
> patch/PKGBUILD instead of having to review patches on top of the first
> PKGBUILD being sent.

I see, then I'll just send in the two different PKGBUILDs for now, once I fix
the issues in both.
> On Wed, 17 Aug 2022 10:20:48 +0300
> Wael Karram <wael at waelk.tech> wrote:
> > Here is the PKGBUILD for the package that'd go in nonprism.
> > I've also attached the whole list of modules that I've excluded.  
> Did you manage to make the PKGBUILD clone a specific mercurial
> revision, or did I miss that? 
> This is important because otherwise users and people building this
> PKGBUILD will expect a specific revision (0.12.1) of the
> prosody-community-modules and will instead get the last revision at the
> time the package was built.
> If the idea is to have the latest revision, this brings several issues.
> Aur has packages that use the latest (usually git) revisions, so when
> users automatically builds them, they get the latest revision at the
> time they build it. 
> Parabola doesn't have something like that so we end up having to use a
> fixed revision at least for the packages we ship. And some Parabola
> contributor(s) really want PKGBUILDS to use known releases.
> If your goal is to always have the latest revision, we can try to find
> solutions for that, like publishing the PKGBUILD in a separate
> repository in abslibre but letting users build it with makepkg.
> In that case the PKGBUILD would also need to be modified to communicate
> that to users. In pcr/omap-u-boot-utils-git/PKGBUILD, there is an
> example that shows how to set pkgver and pkgname for git.
I guess I'll have to figure out the equivalent for mercurial, I think Arch Wiki
had something about it.
> As for the information in modules_requiring_special_treatment, it is
> very useful, so it would be sad to loose it. To avoid that it could be
> added as-is in the PKGBUILD inside comments.
> It also has comments like that inside
> > mod_pubsub_feeds: seems to include unlicensed code.  
> Here if we don't use mksource(), Parabola would end up shipping
> binary packages without mod_pubsub_feeds (as you removed it if I recall
> well), but it would also ship the mod_pubsub_feeds source code.
> So it's probably easier to use mksource() to make sure that Parabola
> doesn't accidentally redistribute code that could make Parabola liable.
> There are also other options for that but they are more complicated.
I've tried the mksource approach now, we'll see if it is enough.
I've attached the PKGBUILD to the email, this is the stricter version that
removes all modules interacting with non-free code of any form (mostly "cloud"
> Denis.

Kind Regards,
Wael Karram.
-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/octet-stream
Size: 1727 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220817/0de42e7c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220817/0de42e7c/attachment.sig>

More information about the Dev mailing list