[Mono-dev] [ccnet-devel] Re: 1.4.1 -> 1.4.2 transition breaks CCNet on Linux

[Leszek Ciesielski]

Cross-posting from CruiseControl.Net devel group. Is there any chance
of this patch making it into Mono 2.2?

On Wed, Dec 17, 2008 at 5:09 PM, Alex <A.Alex.Hutton at gmail.com> wrote:
>
> Will that patch make the next release of Mono then?
>
> On Dec 17, 9:54 am, "Leszek Ciesielski" <skol... at gmail.com> wrote:
>> And if anyone's interested, I'm now running 'stock' CCNet 1.4.2 on
>> Linux with patched Mono.
>>
>>
>>
>>
>>
>> On Wed, Dec 17, 2008 at 2:50 PM, Leszek Ciesielski <skol... at gmail.com> wrote:
>> > Mono bug now has a patch attached. I have talked to Alex (he is using
>> > customized CCNet 1.4.1), the same bug (well, missing Mono
>> > functionality) affects OS X as well.
>>
>> > On Tue, Dec 16, 2008 at 4:30 PM, Leszek Ciesielski <skol... at gmail.com> wrote:
>> >> I have filled a bug with mono:
>> >>https://bugzilla.novell.com/show_bug.cgi?id=459450,
>> >> it probably won't get fixed in time to get into Mono 2.2, as 3rd
>> >> release preview has already been out.
>>
>> >> On Tue, Dec 16, 2008 at 3:23 PM, Daniel Hommel
>> >> <daniel.hom... at it-designers.de> wrote:
>>
>> >>> Leszek,
>>
>> >>> see the following thread:
>> >>>http://groups.google.com/group/ccnet-user/browse_thread/thread/1851e3...
>>
>> >>> It looks like Alex was using Mono 2.0 RC1 to test the fix for the
>> >>> threading issue.
>>
>> >>> regards,
>>
>> >>> Daniel
>>
>> >>> Leszek Ciesielski schrieb:
>> >>>> Hi,
>>
>> >>>> the deadlock cause: process.Exited event is raised properly, but
>> >>>> DataReceivedEventHandler for OutputDataReceived and ErrorDataReceived
>> >>>> do not get a null string, thus never raise their EventHandles. This is
>> >>>> on Linux, Mono 2.0.1. If I understood correctly, this has been tested
>> >>>> on OS X? On what Mono version?
>>
>> >>>> On Tue, Dec 16, 2008 at 1:05 AM, David Cameron <dave... at gmail.com> wrote:
>> >>>>> Hi Ruben
>>
>> >>>>> My intention was to change the trunk to be 1.4.2 when I merge the
>> >>>>> changes from RB_1_4_1 back to trunk. Then nightly builds will have a
>> >>>>> 1.4.2.34** number, while the 1.4.2 release was only 1.4.2.14.
>>
>> >>>>> It sounds like the 1.4.2 fixes are likely to break things on Linux
>> >>>>> though. Unfortunately, the original changes were motivated by trying
>> >>>>> to fix things on OS X. The challenge will be getting all 3 operating
>> >>>>> systems working at the same time.
>>
>> >>>>> Dave
>>
>> >>>>> On Tue, Dec 16, 2008 at 5:46 AM, Ruben Willems <ruben.will... at gmail.com> wrote:
>> >>>>>> Hi
>>
>> >>>>>> 1.4.2 is a bug fix on the 1.4.1 branch,
>> >>>>>> so there is not further development in 1.4.2
>>
>> >>>>>> maybe it is best that the number should be set to 1.4.3 to indicate that one
>> >>>>>> got the latest source.
>>
>> >>>>>> with kind regards
>> >>>>>> Ruben Willems
>>
>> >>>>>> On Mon, Dec 15, 2008 at 6:15 PM, Leszek Ciesielski <skol... at gmail.com>
>> >>>>>> wrote:
>> >>>>>>> On Mon, Dec 15, 2008 at 4:25 PM, Leszek Ciesielski <skol... at gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>> Hi,
>>
>> >>>>>>>> I have been using custom compiles of CCNet on Linux for quite a long
>> >>>>>>>> time. As 1.4.1 contains fixes for all the bugs (excluding CCNET-1292,
>> >>>>>>>> but my company replaced cvs with svn, so that no longer affects us)
>> >>>>>>>> that pushed me to custom builds in the first place, I hoped that
>> >>>>>>>> finally I will be able to run out-of-the-box version. And I can (good
>> >>>>>>>> job!) - as long as I stay with 1.4.1. The fix for process executor in
>> >>>>>>>> 1.4.2 seems to have broken things again - builds on Linux forever stay
>> >>>>>>>> in CheckingModifications state (both cvs and svn). Is this a problem
>> >>>>>>>> with my setup, or can anyone else confirm this?
>>
>> >>>>>>>> Regards,
>>
>> >>>>>>>> Leszek 'skolima' Ciesielski
>>
>> >>>>>>> I did a fresh svn build with some debugs added, and it works fine.
>> >>>>>>> Strange thing is - version of this build (which is supposed to be
>> >>>>>>> svn-head) is still shown as 1.4.1.3823 , which probably means
>> >>>>>>> something is wrong with my checkout?