Re: External Deps: update pwlib and opal version

[guenther <guenther rudersport de>]

[ Please ignore the previous, unfinished mail. Fumbly fingers sent too early. ]

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 with 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
help by the RT, 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

The RT frequently rolls tarballs in similar cases. So if all that's
needed is this part, we likely can arrange that. Just remember, unstable
tarballs during the GNOME unstable timeframe are important to test the
code, before it can go in into a stable release. SVN isn't sufficient.

  guenther  (aka Karsten Br�elmann)


-- 
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; }}}