Re: External Deps: update pwlib and opal version

[guenther <guenther rudersport de>]

Please Cc me on every reply. Since I am not a RT member, I am not
permitted to subscribe to this list -- and thus limited to the archive,
including for this reply.


On Thu, 2007-06-07 at 09:37 +0200, Damien Sandras wrote:
> Le mercredi 06 juin 2007  20:05 -0600, Elijah Newren a crit :

Apart from the original issue (updating external dep versions), which
has been covered by Elijah already, there is another issue lurking here.

> > > > We need to either get updated pwlib/opal tarballs, or downgrade ekiga
> > > > temporarily.  Actually, I think I switched jhbuild to just build ekiga
> > > > from tarballs precisely due to this super-strict pwlib & opal version
> > > > dependency issue.  Maybe that should just be reflected in the wiki,
> > > > with the understanding that it can and will update quite often?
> > >
> > > I plan to provide up to date tarballs of OPAL and PWLIB for the stable
> > > branch of Ekiga (I am actually doing it).

This is good. I'm glad my efforts to negotiate will all the involved
parties worked out. Thanks, again.

> > > However, the unstable branch of Ekiga (ie SVN Trunk) depends on the
> > > unstable branch of PWLIB and OPAL (ie CVS HEAD) for which there are
> > > rarely tarballs.

This, however, is bad.

AFAIK, if there are no unstable releases during the development period,
the version can not be updated to a new stable version for the next
GNOME release, either.

No unstable releases means no smoketesting. GARNOME depends on tarball
releases, as do the official jhbuild modulesets. And I doubt much
distros would go down the ripping-from-SVN path... This is a recurring
topic, and we even have seen already approved, newly proposed tarballs
being dropped off the list, just because they failed to roll a tarball.


> > > I will do what you will suggest.
> > 
> > Is there any way you can fix your dependencies to be e.g., opal >=
> > OPAL_REQUIRED rather than opal == OPAL_REQUIRED?  That would be the
> > optimal fix.
> 
> I can do that, but OPAL and PWLIB's API changes between different major
> versions. 
> 
> So trying to compile Ekiga 2.0.x against CVS HEAD of OPAL and PWLIB
> won't work and compiling Ekiga SVN against lower versions of OPAL and
> PWLIB is not a good idea either, because in that case, people complain
> of bugs that are in the libs and not in Ekia.
> 
> > Alternatively, if you could get unstable opal and pwlib tarballs
> > uploaded and hopefully rolled more often (whenever ekiga needs
> > something newer), that would at least allow us a path forward using
> > ekiga trunk, though the '>=' thing would be a far better solution.
> 
> I will ask on the Ekiga mailing list if somebody can do it to help.
> 
> (The problem is not my unwilling to upload those tarballs, but it
> consumes time, and I don't have much spare time anymore so I prefer
> devoting it to coding.)

If you can find someone on your list, who can roll unstable Ekiga, opal
and pwlib tarballs, that would be great. In case they don't have a
gnome.org shell account, I am positive we will find volunteers to upload
the tarballs to f.g.o. I know I would -- feel free to ping me.

Even in case you don't find one to do these unstable tarballs, we most
likely can handle this, too. Since I am not a RT member, I won't offer
this, however, here is an IRC quote:

  <vuntz> and tell that if they need help to do tarballs, we can
probably find someone to do them



-- 
char *t="\10pse\0r\0dtu\0  ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}