Packaging pjproject

Packaging pjproject

[Jan]

Hello,
I have hard time trying to fix the pjproject package - something is
broken in our version of pjproject, which makes Jami crash.
pjproject-jami works, because we disable some unused dependencies, but
pjproject alone never actually worked.
The problem is there are dependencies packed in third_party folder and
the build system wants to have them there. I tried removing the
"make dep" phase, modifying Makefiles, etc, but no matter what I do,
the build system still complains about not having dependencies, for
example speex, even though it is present in the propagated inputs field.
How do we deal with problems like this?


Jan Wielkiewicz

Re: Packaging pjproject

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Jan <tona_kosmicznego_smiecia@interia.pl> writes:

> Hello,
> I have hard time trying to fix the pjproject package - something is
> broken in our version of pjproject, which makes Jami crash.
> pjproject-jami works, because we disable some unused dependencies, but
> pjproject alone never actually worked.
> The problem is there are dependencies packed in third_party folder and
> the build system wants to have them there. I tried removing the
> "make dep" phase, modifying Makefiles, etc, but no matter what I do,
> the build system still complains about not having dependencies, for
> example speex, even though it is present in the propagated inputs field.
> How do we deal with problems like this?

Unfortunately there is no single approach for dealing with these kinds
of problems, as they are typically highly package-specific.

I must admit that I'm a little confused between pjproject and
pjproject-jami.  Is it correct to assume that the latter exists only
because the former fails to build?  Why are you trying to switch?

Would it make sense to get rid of pjproject entirely (nothing depends on
it) in favor of pjproject-jami?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging pjproject

[Jan]

On Fri, 31 Jan 2020 17:05:28 +0100
Marius Bakke <mbakke@fastmail.com> wrote:
> 
> Unfortunately there is no single approach for dealing with these kinds
> of problems, as they are typically highly package-specific.
Do I have to learn GNU Make to be able to deal with it?

> I must admit that I'm a little confused between pjproject and
> pjproject-jami.  Is it correct to assume that the latter exists only
> because the former fails to build?  Why are you trying to switch?
Both pjproject and pjproject-jami are Pierre's work.
pjproject is unmodified, but never worked, while pjproject-jami is
pjproject with Savoir-faire Linux patches - they introduce some serious
modifications, which are usable only for Jami. That's why
pjproject-jami exists. pjproject-jami works only because configure
flags disable unused dependencies, yet somehow our Jami package crashes
because of something connected to pjproject.
https://git.jami.net/savoirfairelinux/jami-packaging/issues/63
 
> Would it make sense to get rid of pjproject entirely (nothing depends
> on it) in favor of pjproject-jami?
We could do it, but why do so, if most of the work has been done? Guix
System is incremental work and even if nothing needs pjproject now, it
could be useful for someone in the future. It just needs to be fixed.



Jan Wielkiewicz

Re: Packaging pjproject

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Jan <tona_kosmicznego_smiecia@interia.pl> writes:

> Both pjproject and pjproject-jami are Pierre's work.

To be more specific, I have never touched pjproject.  I was the 4th
person so work on the Jami patch and I fixed pjproject-jami.  I sadly
have no experience with pjproject beyond that.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Packaging pjproject

[Jan Wielkiewicz]

Dnia 2020-01-31, o godz. 18:12:07
Pierre Neidhardt <mail@ambrevar.xyz> napisał(a):

> To be more specific, I have never touched pjproject. 
Sorry, didn't know that.
> I was the 4th person so work on the Jami patch and I fixed pjproject-jami.  
> I sadly have no experience with pjproject beyond that.
Now thats scary :D
pjproject is a ghost package.

I can try nagging people on pjproject mailing list, but don't know, if
I'm up to the task. What should I ask them? "How to build pjproject
without running make dep" or "Can I build pjproject using system
libraries"? Should I learn more about build systems to be able to fix
this, or is it implementation-dependent? My experience with packaging
so far tells me there is no standard for build systems and every
package is different.


Jan Wielkiewicz

Re: Packaging pjproject

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

On Fri, Jan 31, 2020 at 08:35:00PM +0100, Jan Wielkiewicz wrote:
> Dnia 2020-01-31, o godz. 18:12:07
> Pierre Neidhardt <mail@ambrevar.xyz> napisał(a):
> 
> > To be more specific, I have never touched pjproject. 
> Sorry, didn't know that.
> > I was the 4th person so work on the Jami patch and I fixed pjproject-jami.  
> > I sadly have no experience with pjproject beyond that.
> Now thats scary :D
> pjproject is a ghost package.
> 
> I can try nagging people on pjproject mailing list, but don't know, if
> I'm up to the task. What should I ask them? "How to build pjproject
> without running make dep" or "Can I build pjproject using system
> libraries"? Should I learn more about build systems to be able to fix
> this, or is it implementation-dependent? My experience with packaging
> so far tells me there is no standard for build systems and every
> package is different.

Debian does a lot of work with unbundling software, I'd check with them
first if they've patched anything to make it work.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Packaging pjproject

[Jan]

On Sun, 2 Feb 2020 20:42:49 +0200
Efraim Flashner <efraim@flashner.co.il> wrote:
> 
> Debian does a lot of work with unbundling software, I'd check with
> them first if they've patched anything to make it work.
> 

Checked Debian and it doesn't look good.
They removed pjproject from Buster.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925263

"- pjsip is a library where a lot of functionality and behaviour is
  selected at compile time using #define statements. Most of these
  define statements alter the ABI due to changing structs, which makes
  it ill-suited as a system wide library to be used by several programs.
  - Consequently, src:ring (now called jami) has always been built
  against an embedded copy and src:asterisk also switched to an
  embedded copy, both tailored to their needs. There are no other
  source packages depending on src:pjproject left"

I picked the worst thing to maintain, didn't I :D
I guess we can remove pjproject then and use only pjproject-jami, but
that doesn't fix the bug. I'll try checking how is pjproject-jami
different from what Jami devs build, but have no clue whatsoever.



Jan Wielkiewicz

Re: Packaging pjproject

[Jan]

But it seems Gentoo has pjproject package, I can't read it though. I
could try reading this, but it'll take some time for me to understand.
https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/pjproject/pjproject-2.9-r1.ebuild


Jan Wielkiewicz