boost 1.53 breaks monotone build

[Richard Hopkins-2]

Current nvm head, and it seems monotone 1.0 too, fail to build with
boost 1.53.  Several instances can be found by searching the web
e.g. http://thread.gmane.org/gmane.os.openbsd.ports/60562

> monotone fails with:
> keys.cc:47: error: 'boost::shared_dynamic_cast' has not been declared
> keys.cc: In function 'boost::shared_ptr<Botan::RSA_PrivateKey>
> get_private_key(lua_hooks&, const rsa_keypair_id&, const
> base64<rsa_priv_key>&, bool)':
> keys.cc:266: error: 'shared_dynamic_cast' was not declared in this
> scope

It also seems there a patch to fix it, but how (if we need to)
should we keep compatibility with older boost?

http://alt.linux.kiev.ua/ru/srpm/Sisyphus/monotone/patches/0

Richard


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

Richard,

On 03/14/2013 07:58 PM, Richard Hopkins wrote:
> It also seems there a patch to fix it, but how (if we need to)
> should we keep compatibility with older boost?

To me, it looks like dynamic_pointer_cast is old enough to be usable for
us. At least according to their documentation, it is included since 1.34:

http://www.boost.org/doc/libs/1_34_0/libs/smart_ptr/pointer_cast.html

The oldest installed boost I had lying around was 1.46. And monotone
compiled just fine there. Having all instance of shared_dynamic_cast
replaced with dynamic_pointer_cast. And I can confirm it works with
boost 1.53, so I committed this change in dfe4b51c...

If somebody has an ancient boost ready to test against, please try that
revision. We can still add a check against BOOST_VERSION.

Regards

Markus Wanner

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Richard Hopkins-2]

--- On Fri, 15/3/13, Markus Wanner <[hidden email]> wrote:
> To me, it looks like dynamic_pointer_cast is old enough to
> be usable for
> us. At least according to their documentation, it is
> included since 1.34:
>
One of my installs has boost 1.36 and your commit (dfe4b)
compiles fine on it.

My vote is for a release soon ;-)

Richard

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Hendrik Boom-2]

On Fri, Mar 15, 2013 at 10:35:29PM +0000, Richard Hopkins wrote:

> --- On Fri, 15/3/13, Markus Wanner <[hidden email]> wrote:
> > To me, it looks like dynamic_pointer_cast is old enough to
> > be usable for
> > us. At least according to their documentation, it is
> > included since 1.34:
> >
> One of my installs has boost 1.36 and your commit (dfe4b)
> compiles fine on it.
>
> My vote is for a release soon ;-)

For reference, Debian stable has libboost packages with versin number 1.42.0-4.

-- hendrik

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

On 03/15/2013 11:35 PM, Richard Hopkins wrote:
> One of my installs has boost 1.36 and your commit (dfe4b)
> compiles fine on it.

Thanks for testing.

> My vote is for a release soon ;-)

I'd also like to see a monotone-1.1 release soon-ish. I'd be much more
comfortable with a working buildbot, though. Who's in charge of the
buildbot master?

On my local machine, resolve_conflicts_dropped_modified_1 fails
constantly. From the extra suite, ciabot fails intermittently. On my
hurd test box, I get failures for mail-notify. All of that is not quite
with the most recent rev, though.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Richard Hopkins-2]

>
> On my local machine, resolve_conflicts_dropped_modified_1
> fails
> constantly.
Same here! Glad I'm not the only one; I was seriously starting to doubt
my hardware, OS, or config, especially as I had it succeed once or twice,
the backtrace kept changing, and that it hasn't failed yet on Windows.

http://lists.gnu.org/archive/html/monotone-devel/2012-12/msg00032.html

I agree though, before releasing I'd like to see full test results from
all our supported platforms/OS's. I can provide results for SLED 11 SP2
for definite, OpenSUSE most probably, and probably Windows XP SP3 +
Windows 7 SP1 and OpenBSD.

As a bonus, after a release, hopefully it means integration with
package managers will be easier. I'd like to send a port update to
OpenBSD and somehow get the SUSE/OpenSUSE package updated - their
next releases will be due later this year giving us a few months.


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Richard Hopkins <[hidden email]> writes:

>>
>> On my local machine, resolve_conflicts_dropped_modified_1
>> fails
>> constantly.
> Same here! Glad I'm not the only one; I was seriously starting to doubt
> my hardware, OS, or config, especially as I had it succeed once or twice,
> the backtrace kept changing, and that it hasn't failed yet on Windows.

In 79e73d6882ea68c70abd5891f47806eabe5d0f10 on 16 March 2013 (3 days
ago), I fixed a bug related to that; there was this snippet of code in
merge_content.cc:

      else
        {
          parents.erase (i);
          set<revision_id> more_parents;
          db.get_revision_parents(*i, more_parents);
          parents.insert(more_parents.begin(), more_parents.end());
        }

This has *i after erase (i), which can have random effects depending on
the stack/heap content.

It is now:

      else
        {
          set<revision_id> more_parents;
          db.get_revision_parents(*i, more_parents);
          parents.erase (i);
          parents.insert(more_parents.begin(), more_parents.end());
        }

This fixed a hang on Windows for me.

Let me know if it fixes your problems.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Frédéric Praca-2]

Le Mon, 18 Mar 2013 22:27:35 +0000 (GMT),
Richard Hopkins <[hidden email]> a écrit :

> >
> > On my local machine, resolve_conflicts_dropped_modified_1
> > fails
> > constantly.
> Same here! Glad I'm not the only one; I was seriously starting to
> doubt my hardware, OS, or config, especially as I had it succeed once
> or twice, the backtrace kept changing, and that it hasn't failed yet
> on Windows.
Well, I just tested it on Ubuntu 12.10 on x86-64 and it worked :)
I'll give it a try on FreeBSD8-STABLE on x86 at home.
 
> http://lists.gnu.org/archive/html/monotone-devel/2012-12/msg00032.html
>
> I agree though, before releasing I'd like to see full test results
> from all our supported platforms/OS's. I can provide results for SLED
> 11 SP2 for definite, OpenSUSE most probably, and probably Windows XP
> SP3 + Windows 7 SP1 and OpenBSD.

I could probably provide results on FreeBSD 8-STABLE from time to time
and a Ubuntu 12.10 almost all time (week-end excluded :)) if it helps.

> As a bonus, after a release, hopefully it means integration with
> package managers will be easier. I'd like to send a port update to
> OpenBSD and somehow get the SUSE/OpenSUSE package updated - their
> next releases will be due later this year giving us a few months.
 
Fred

> _______________________________________________
> Monotone-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/monotone-devel


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Richard Hopkins-2]

> In 79e73d6882ea68c70abd5891f47806eabe5d0f10 on 16 March ...
> ...
> This fixed a hang on Windows for me.
>
> Let me know if it fixes your problems.

It does. resolve_conflicts_dropped_modified_1 now passes
successfully - tested with 5934509c86e975ce771c66a1511671620eceb6d0 (descendant of 79e...) several times.

All tests pass now on SLED 11 SP2.

Richard

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

On 03/19/2013 05:11 AM, Stephen Leake wrote:
> This has *i after erase (i), which can have random effects depending on
> the stack/heap content.

Good catch.

> This fixed a hang on Windows for me.
>
> Let me know if it fixes your problems.

Seems to fix issues on my amd64 box. And my hurd boxen just crawled
through the entire test suite just fine as well.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Markus Wanner <[hidden email]> writes:

> On 03/19/2013 05:11 AM, Stephen Leake wrote:
>> This has *i after erase (i), which can have random effects depending on
>> the stack/heap content.
>
> Good catch.

Thanks.

Of course, I'm the one that wrote the bad code in the first place :(.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Lapo Luchini]

Markus Wanner wrote:
> And I can confirm it works with
> boost 1.53, so I committed this change in dfe4b51c...

OK, this commit also fixed recent breakage caused by 1.52 -> 1.55
upgrade of FreeBSD's boost.

http://www.freshports.org/devel/monotone/

cheers,

--
Lapo Luchini - http://lapo.it/


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel