What ekiga version are you taking about?  3.2.4 should be fine with ptlib/opal uploaded on gnome site (there was however a problem with 3.2.2 and 3.2.3, that's why 3.2.4 was uploaded right afterwards).

As (almost) set in the "Version" field, I am talking about git master.

Frederic, sorry, I do not understand.

ptlib/opal dependencies change the version right after the release, so they have now 2.6.3/3.6.3.  ekiga master works only with trunk ptlib/opal (well, it does work right now with 2.6.2/3.6.2 too, but sooner or later ptlib/opal will add a feature, and ekiga will need that feature, so it will depend on 2.6.3/3.6.3).

The purpose of bug is that ekiga master be changed so that it depend on released version (2.6.2/3.6.2) of ptlib/opal??  Or is it just a reminder for when ekiga releases, its ptlib/opal deps (2.6.3/3.6.3) be uploaded to gnome too?

GNOME policy is to depend on declared and released external dependencies (ptlib, opal in the case of ekiga), this is necessary to get a buildable GNOME stack at all times (before that policy we often had build failures caused by development versions of external deps, such as cairo).

Currently Ekiga configure.ac checks for ptlib 2.7.0 and opal 3.7.0, versions that do not match the requirements outlined earlier.

But I know from past experience Ekiga won't conform to GNOME policies, so the whole purpose of this bug is not to discuss policies, but to be notified of the time Ekiga gets buildable.

So, when a new ekiga version is released and corresponding ptlib/opal are uploaded to gnome, this bug is to be closed?  Anyway, I check that before releasing.

One of the points of the buildbots is "continuous integration", to be able to test things *before* a version is released.

If the current development version works with released ptlib and opal versions, it is therefore much better not to bump their version numbers in configure.ac.

I understand now, you're right.  I cannot do it for 3.7.0, there were some API changes.

But couldn't gnome people, for the continuous integration, compile also ptlib/opal trunk when they compile ekiga?

Like I wrote earlier the policy is to use tarballs; changes to the policy, or exceptions, could certainly be discussed in desktop-devel-list.

Would it be acceptable if we generated daily tarballs ourselves or should they come from upstream?

The point is more about "release" than "tarball", so daily tarballs wouldn't cut it, sorry if I was not clear about this.

*** Bug 585037 has been marked as a duplicate of this bug. ***

*** Bug 607049 has been marked as a duplicate of this bug. ***

Maybe you can convince ptlib devels to make a release? Current ekiga jhbuild compilation is still broken

We have recently decided that ekiga master use current stable branches of ptlib/opal.  Ekiga currently compiles with these.

Is it possible to modify jhbuild according to that?

If not, we could use tarballs for ptlib/opal, since they made a release from this branch one month ago.  It is ptlib 2.8.1 and opal 3.8.1.  Should I upload them on gnome ftp site?

Great,

yeah, the process to bump external dependencies is described here: http://live.gnome.org/TwoPointThirtyone/ExternalDependencies

Then, you have to update jhbuild moduleset to retrieve the new opal and ptlib versions:

opal: http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-external-deps-3.0.modules#n391

ptlib: http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-external-deps-3.0.modules#n437

Dont know if you have to upload the tarballs to gnome ftp or it can be retrieved from sourceforge directly.

Eugen, please upload new versions to GNOME FTP, thanks.

Sorry for the delay, I am really busy these times.

I have just uploaded ptlib 2.8.1 and opal 3.8.1 on master.gnome.org.  Note that we do not yet know if ekiga release for gnome 3.0 will be based on master (with 2.8.1/3.8.1) or on stable branch (gnome-2-26).

Should jhbuild be modified in this case too?  If yes, I need to check out jhbuild master and made the two modifications from the previous comment, is that right?

Right, just checkout master and update the gnome-external-deps-3.0.modules file, thanks again!

Done: http://git.gnome.org/browse/jhbuild/commit/?id=5e0698d0dd9eef83f30542d39d13011a4be34900

I think it is better to let this bug open, because the compilation problem between ekiga and ptlib/opal can always appear.

Engen, once again there has been a bump of ptlib/opal version numbers without consideration for the established gnome processes…

Anyway could you please go and update the gnome-apps-3.0.modules file in jhbuild to match new ekiga requirements?

Thanks.

(if 3.0 shouldn't follow ekiga master, please tell the release team)

I think I will never understand how this works :o)

What have I done wrong?  Is it:
- because I uploaded new ptlib/opal,
- or because I have not yet updated gnome-apps-3.0.modules,
- or because I have not informed desktop-devel-list ("If you want to add a new dependency or want one of the minimum versions updated, make a good case for it on desktop-devel-list (this may only require a few sentences)." from http://live.gnome.org/TwoPointThirtyone/ExternalDependencies)?

We still do not know if gnome 3.0 will be based on ekiga 3.3.x (master), or on the old 3.2.7 (gnome 2_26 branch), probably the former will be used.

(In reply to comment #21)
> What have I done wrong?  Is it:
> - or because I have not informed desktop-devel-list ("If you want to add a new
> dependency or want one of the minimum versions updated, make a good case for it
> on desktop-devel-list (this may only require a few sentences)." from
> http://live.gnome.org/TwoPointThirtyone/ExternalDependencies)?

Yes, that one, though http://live.gnome.org/TwoPointNinetyone/ExternalDependencies now. :)

Ok, I will do it from now on.

I updated also gnome-apps-3.0.modules.

As per bug #678958, ekiga depends now on unreleased versions of ptlib/opal, so closing this bug.

*** This bug has been marked as a duplicate of bug 678958 ***