This patch allows you to put your externally visible objects on a specific NIC as identified by IP address. A patch will be attached ASAP. The patch applies cleanly on top of http://bugs.gentoo.org/attachment.cgi?id=131771. The patch has already been committed to Gnome svn. Please consider. Thanks, jules
Created attachment 131775 [details, diff] Halfway endpoint support
Is it just me or this patch breaks ABI? (I'm at work and can't try the patch yet) Not that I would mind, but if it does, it'd be nice to warn people first.
How should it break the ABI?
I saw it added an enum type and thought that it would break ABI ... I didn't think it through :) my bad
That's OK, I do that a lot ;-)
Since there has been a lot of patches for this package recently, I feel like asking for additional regression tests for these if possible. I'm willing to take patches fixing bugs but it'd be nice if tests would cover the new found failure case. This particular bug is about adding something to the API, I'd prefer to wait either for a new release or for a program actually using that feature in gentoo.
Please instead of asking us to include patches that add new library features persuade upstream to make a new release. For example we can't be sure that this new enum will stay as it is before an upstream release is finished. If it doesn't stay as in this patch, we have an ABI break on our hands between our 2.14.9-r1 and future 2.14.10 or 2.16.0, while not for upstream as they never released this new ABI.
(In reply to comment #6) > Since there has been a lot of patches for this package recently, Yes, I feel it is only polite to notify the Gentoo developers as I fix bugs or add features in ORBit2, as Gentoo is my platform of choice. The reason for the big number of changes in ORBit2 lately is that my package (evolution-brutus) is a heavy ORBit2 user so I fix bugs and add features directly in gnome svn on a regular basis. >I feel like > asking for additional regression tests for these if possible. I'm willing to > take patches fixing bugs but it'd be nice if tests would cover the new found > failure case. I assume that you are referring to the ref count bug that is fixed by bug #193640? That particular bug is hard to add a regression test for as it only surface if you are communicating over an actual NIC. Most other fixes/features are covered by additional 'make check' tests. > This particular bug is about adding something to the API, I'd prefer to wait > either for a new release or for a program actually using that feature in > gentoo. Yes, I can understand that. As an enhancement it isn't that important and it will be included in the next release. I never put anything into gnome svn unless it is trivial or approved by Michael.
(In reply to comment #7) > Please instead of asking us to include patches that add new library features > persuade upstream to make a new release. Sure, I can do that. But, as said in my reply to comment 3, this is an enhancement so it is not as important as a bug fix. So I do not push too much in these cases. > For example we can't be sure that this new enum will stay as it is before an > upstream release is finished. If it doesn't stay as in this patch, we have an > ABI break on our hands between our 2.14.9-r1 and future 2.14.10 or 2.16.0, > while not for upstream as they never released this new ABI. I'm fairly certain it will stay as is. My patch could naturally be reverted from svn, but it is customary to fix an addition in ORBit2 instead of removing it.
(In reply to comment #8) > (In reply to comment #6) > > Since there has been a lot of patches for this package recently, > > Yes, I feel it is only polite to notify the Gentoo developers as I fix bugs or > add features in ORBit2, as Gentoo is my platform of choice. The reason for the > big number of changes in ORBit2 lately is that my package (evolution-brutus) Which, BTW, is bug #144629.
(In reply to comment #9) > (In reply to comment #7) > > Please instead of asking us to include patches that add new library features > > persuade upstream to make a new release. > > Sure, I can do that. But, as said in my reply to comment 3, this is an > enhancement so it is not as important as a bug fix. So I do not push too much > in these cases. Yeah, same reason for not feeling a big need to put this into Gentoo already too (In reply to comment #10) > Which, BTW, is bug #144629. Cool :)
Fixed in the new 2.14.10 release.
