Re: [Mono-dev] Mono 2.8 (trunk) compiling on Mac OS X 10.6 (SL)
On 24.04.2011 02:09, nmccready wrote: Also what do I have to do to get MonoDevelop to look for new install? Use the script at http://www.mono-project.com/Parallel_Mono_Environments to setup the environment for using an alternate installation location. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at WienUID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: Wien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Test suite failures (Mono 2.10.2)
On 24/06/11 19:02, Rodrigo Kumpera wrote: It's hard to do such a thing when you factor in that mono supports many dozens of targets and configurations and that sometimes those breaks were caused my maintainers - I have my share of faults. I know how annoying it is to wait for unit tests to run before comitting. It's much better to send that off to some server and code on :) Thing is, right now the team at Xamarin has tons of stuff on its hand so getting the build infrastructure back on track, which helps us a lot, won't happen without community help. A good first step would be to get CI back working at least on linux. S, if someone wants to rebuild the continuous integration farm over linode (or other VPS) please speak up. Non-functional unit tests are *the* major frustration for me when trying to work on mono. Since I'm building a product which also should run on mono, I do have a big interest in getting mono development back on track, and improve the release quality (e.g. by avoiding regressions through a working test infrastructure). I've got extensive experience adminning Debian, a few years on RedHat, and I'm responsible for the CC.NET server at my company. So, please just tell me how I can help! Best Regards, David On Thu, Jun 23, 2011 at 4:05 PM, Steve Bjorg ste...@mindtouch.com mailto:ste...@mindtouch.com wrote: Here's a thought: only accept code changes that pass all tests? Just saying... - Steve -- Steve G. Bjorg http://mindtouch.com http://twitter.com/bjorg On Jun 23, 2011, at 11:43 AM, Zoltan Varga wrote: Hi, Our test suite contains 1000s of tests, written by dozens of people, its a bit hard to keep them all passing. Zoltan On Thu, Jun 23, 2011 at 7:44 PM, Harry Wilkinson hwilkin...@mdsol.com mailto:hwilkin...@mdsol.com wrote: Hi, I'm encountering some test failures with the Mono 2.10.2 source tarball distributed at http://ftp.novell.com/pub/mono/sources/mono/ Basically I'm trying to package it for deployment on Ubuntu 10.04.2 servers in a cloud configuration. So far I've been building from source and encountered no significant problems other than the long build time. I'd like to be able to reduce that by building it once and deploying a compiled package. So I'm using dpkg-buildpackage. However, now that I'm packaging rather than just building and installing, it seems that the test suite is run and there are some test failures. The first and most obvious one is that it appears that a file is missing from the source tarball: mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs The file is there in the Git repo under the 2.10.2 tag, but it's not in the tarball. Unfortunately it's referenced in the associated Makefile (mcs/class/corlib/Makefile). The same applies to 2.10.1, so I'm guessing the file is omitted from whatever process builds the tarballs. I switched to compiling from the source taken from Git, checkout out the 2.10.2 tag, and I get a different error (which is also what I get with the tarball version if I just hack the makefile): make[8]: Entering directory `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData' MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19): error CS0507: `MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot change access modifiers when overriding `protected' inherited member `System.Web.UI.Control.CreateChildControls()' /home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location of the symbol related to previous error) Compilation failed: 1 error(s), 0 warnings make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1 It looks like this could well be an incorrect preprocessor definition 'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not) in mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs. Is this expected? I had sort of assumed that a released version would have a passing test suite. Am I doing something wrong? Any advice (well, almost) would be gratefully received. Thanks. Harry Wilkinson ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com
Re: [Mono-dev] Test suite failures (Mono 2.10.2)
On 24/06/11 21:14, Harry Wilkinson wrote: Okay, so I guess this answers 2 of the questions - the test failures are expected, and I'm not doing anything wrong. Please correct me if you think otherwise. I would still really like to know: how is Mono packaged if the test suite fails? This is important to me because I would like to build my own package so I don't have to compile Mono every time I deploy a Mono app. Is there a straightforward way to ignore the tests? don't run make check and/or do not use --enable-nunit-tests ? Debian (courtsy of meeby and friends) is currently working on getting 2.10 ready for testing. Current packages are in experimental. Take a look at the source at: http://anonscm.debian.org/gitweb/?p=pkg-mono/packages/mono.git Best Regards, David Thanks. Harry Date: Fri, 24 Jun 2011 15:12:12 -0300 From: Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com Subject: Re: [Mono-dev] Test suite failures (Mono 2.10.2) To: Kocsis L?szl? kocsis1...@gmail.com mailto:kocsis1...@gmail.com Cc: mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com Message-ID: banlktinxujqsmhyu8jy48jxetzcxzfj...@mail.gmail.com mailto:banlktinxujqsmhyu8jy48jxetzcxzfj...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I think you misundestood my email. It's the opposite, right now we, at Xamarin, can't really afford the time to bring the mono CI infrastructure back so someone from the community needs to step up and do it. On Fri, Jun 24, 2011 at 3:07 PM, Kocsis L?szl? kocsis1...@gmail.com mailto:kocsis1...@gmail.com wrote: Hi Rodrigo, Good news the guys at Xamarin are working hard on getting the build infrastructure back. Would you please give us an estimate about when will it be up and running again? I would like to work on bugs in the Windows version of mono, but I could not even compile it. I hope the automatic build and test system will solve such problems and mono will compile and pass all tests at least on every major platform. Or am I naive and this cannot be expected? Best, Laszlo 2011/6/24, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com: It's hard to do such a thing when you factor in that mono supports many dozens of targets and configurations and that sometimes those breaks were caused my maintainers - I have my share of faults. Thing is, right now the team at Xamarin has tons of stuff on its hand so getting the build infrastructure back on track, which helps us a lot, won't happen without community help. A good first step would be to get CI back working at least on linux. S, if someone wants to rebuild the continuous integration farm over linode (or other VPS) please speak up. On Thu, Jun 23, 2011 at 4:05 PM, Steve Bjorg ste...@mindtouch.com mailto:ste...@mindtouch.com wrote: Here's a thought: only accept code changes that pass all tests? Just saying... - Steve -- Steve G. Bjorg http://mindtouch.com http://mindtouch.com/ http://twitter.com/bjorg On Jun 23, 2011, at 11:43 AM, Zoltan Varga wrote: Hi, Our test suite contains 1000s of tests, written by dozens of people, its a bit hard to keep them all passing. Zoltan On Thu, Jun 23, 2011 at 7:44 PM, Harry Wilkinson hwilkin...@mdsol.com mailto:hwilkin...@mdsol.comwrote: Hi, I'm encountering some test failures with the Mono 2.10.2 source tarball distributed at http://ftp.novell.com/pub/mono/sources/mono/ Basically I'm trying to package it for deployment on Ubuntu 10.04.2 servers in a cloud configuration. So far I've been building from source and encountered no significant problems other than the long build time. I'd like to be able to reduce that by building it once and deploying a compiled package. So I'm using dpkg-buildpackage. However, now that I'm packaging rather than just building and installing, it seems that the test suite is run and there are some test failures. The first and most obvious one is that it appears that a file is missing from the source tarball: mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs The file is there in the Git repo under the 2.10.2 tag, but it's not in the tarball. Unfortunately it's referenced in the associated Makefile (mcs/class/corlib/Makefile). The same applies to 2.10.1, so I'm guessing the file is omitted from whatever process builds the tarballs. I switched to compiling from the source taken from Git, checkout out the 2.10.2 tag, and I get a different error (which is also what I get with the tarball version if I just hack the makefile): make[8]: Entering directory `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData'
[Mono-dev] CI results
Hi *, I've set up a prototypical monkeywrench for mono. It's running on xsp2, spit and thread at http://office.dasz.at:8123/ . Currently there is some I've created lanes for mono-2-6, mono-2-10 and master in three flavours each: build-only which only does autogen and make, the full build including a make check and something I've named project-green where I've started to put small fixes to get over some initial humps for mono-2-10. Here are the results: master-build-only: no error master: Testing delegate-invoke.exe... failed 256 (1) signal (0). mono-2-10-build-only: no error mono-2-10: Fails to build tests: MCS [net_2_0] System.Data.Services_test_net_2_0.dll mono-2-10-project-green: Tests run: 39531, Failures: 2025, Not run: 397, Time: 453.79s Then hangs and dies on System.Windows.Forms_test_net_2_0.dll, which needs X mono-2-6-build-only: no error mono-2-6: Testing cattr-object.exe... failed 34304 (134) signal (0). The monkeywrench and builder are running on Debian Squeeze in the same linux-vserver container on an amd64 host. All changes I made are online on github at https://github.com/DavidS/monkeywrench and https://github.com/DavidS/mono Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] No rule to make target `../mini/libmono-2.0.la', needed by `monograph'.
On 24.09.2011 17:33, Jeff Bakst wrote: I am building mono from snapshot. All is good with the exception of make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/jbakst/mono-2.10.5/mono/dis' Making all in monograph make[3]: Entering directory `/home/jbakst/mono-2.10.5/mono/monograph' -- make[3]: *** No rule to make target `../mini/libmono-2.0.la http://libmono-2.0.la/', needed by `monograph'. Stop. make[3]: Leaving directory `/home/jbakst/mono-2.10.5/mono/monograph' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jbakst/mono-2.10.5/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jbakst/mono-2.10.5' make: *** [all] Error 2 Any ideas what I might have missed? Are you using parallel make? I seem to remember that I've seen that intermittently when using make -j. If not, it's probably necessary to state the configure/autogen, make invocations, and versions you used for building it. Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] WCF: BasicHttpBinding
Hi, when configuring a WCF service with BasicHttpBinding (works on .net) Mono 2.10 throws the following exception: System.InvalidOperationException: Only MessageVersion.None is allowed for WebHttpBehavior at System.ServiceModel.Description.WebHttpBehavior.ValidateBinding (System.ServiceModel.Description.ServiceEndpoint endpoint) [0x000b8] in [...]/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs:306 at System.ServiceModel.Description.WebHttpBehavior.Validate (System.ServiceModel.Description.ServiceEndpoint endpoint) [0x00052] in [...]/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs:290 at System.ServiceModel.Description.ServiceEndpoint.Validate () [0x0005f] in [...]/mcs/class/System.ServiceModel/System.ServiceModel.Description/ServiceEndpoint.cs:124 at System.ServiceModel.ServiceHostBase.ValidateDescription () [0x00064] in [...]/mcs/class/System.ServiceModel/System.ServiceModel/ServiceHostBase.cs:489 at System.ServiceModel.ServiceHostBase.InitializeRuntime () [0x0] in [...]/mcs/class/System.ServiceModel/System.ServiceModel/ServiceHostBase.cs:447 at System.ServiceModel.ServiceHostBase.OnOpen (TimeSpan timeout) [0x6] in [...]/mcs/class/System.ServiceModel/System.ServiceModel/ServiceHostBase.cs:567 at System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) [0x6] in [...]/mcs/class/System.ServiceModel/System.ServiceModel.Channels/CommunicationObject.cs:170 at System.ServiceModel.Channels.CommunicationObject.Open () [0x0] in [...]/mcs/class/System.ServiceModel/System.ServiceModel.Channels/CommunicationObject.cs:164 This is the app.config fragment I'm using: behaviors serviceBehaviors behavior name=TestService_Behaviour serviceMetadata httpGetEnabled=true httpGetUrl=[someUrl] / !-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information. Hint from http://geekswithblogs.net/frankw/archive/2008/03/12/includeexceptiondetailinfaults-in-wcf-service-configuration.aspx -- serviceDebug includeExceptionDetailInFaults=true httpHelpPageEnabled=true httpHelpPageUrl=[someUrl]/Help/ !-- We are using sessions! Not realy sessions like ASP.NET sessions, we do not have state at the server. But the configurated security mode establishes a session. Thus we have to increse the maxConcurrentSessions throttle. 200 because WCF 4.0 uses 100 * processor count for session and 16 * processor count for calls -- serviceThrottling maxConcurrentSessions=200 / /behavior behavior name=Test.Server.BootstrapperServiceBehavior serviceMetadata httpGetEnabled=true / serviceDebug includeExceptionDetailInFaults=true / /behavior /serviceBehaviors /behaviors services service name=Test.Server.TestService behaviorConfiguration=TestService_Behaviour endpoint address=[someUrl] binding=basicHttpBinding bindingConfiguration=TestService_Binding contract=Test.API.ITestService name=TestService_Endpoint / host baseAddresses add baseAddress=[someUrl]/ /baseAddresses /host /service service name=Test.Server.BootstrapperService behaviorConfiguration=Test.Server.BootstrapperServiceBehavior endpoint address=Bootstrapper.svc binding=webHttpBinding contract=Test.Server.IBootstrapperService / endpoint address=mex binding=mexHttpBinding contract=IMetadataExchange / host baseAddresses add baseAddress=[someBaseAddress]/ /baseAddresses /host /service /services I'm running a locally compiled version from the 2.10 branch. Is this intentionally not implemented or should I file a bug? Also, where can I start looking to implement this? Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Centralized MonoStore
On 20.01.2012 12:50, jaysonp wrote: My question is, on the new Windows client machine, how will I map/mount the shared main mono cert store, in such a way that the client machine will treat this as its machine mono cert store? To hopefully clarify, here are some scenarios: 1. Running certmgr /add /c /m Trustcertificate on the client machine *will mean adding the certificate on the shared main mono cert store rather than adding it on its local %PROGRAMDATA%* 2. Running chktrust on the client machine *will mean chktrust will connect to the shared main mono cert store to verify the validity of the certificate rather than connecting on its locat %PROGRAMDATA%* Again, both main mono store and client are hosted on a Windows Machine. Mounting a UNC to a directory (instead of a drive letter) is pretty basic win-admin stuff. See for example this answer on sf: http://serverfault.com/a/107301 Regards, D. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On 2012-01-24 02:32, Robert Vesse wrote: If it is the case that you have unmanaged resources that you need to clean up that you should really be using the IDisposable interface and calling Dispose() on the class when you are done with it. If it is possible for code paths to 'forget' to call Dispose() then you can include a finalizer as well, if you do this you need to make sure that when Dispose() is explicitly called you call GC.SuppressFinalize() on that object so the finalizer can be skipped Ths MSDN has very comprehensive guidelines on implementing IDisposable and finalizers correctly: http://msdn.microsoft.com/en-us/library/system.idisposable.aspx There is also a simpler guide at http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx without using a finalizer, which is enough if you have only managed resources. Best Regards, D. Rob On Jan 23, 2012, at 4:22 PM, Konrad M. Kruczyński wrote: Thanks for the answer. Here is the case: Let's say I have a class which contains some data in temporary file (for example some kind of cache which should not stay in memory). I'd like to have this file removed when object of this class dies. I can implement a finalizer but if I do this, object will be reclaimed later than it should, also putting additional pressure on GC. Problems of objects with finalizers which are not manually invoked are generally known. And this is scenario where such object can be shared and does not fit into any kind of using block. I think that mentioned API can resolve that kind of problems, because I can set up a callback which deletes temporary file *after* object's death. Therefore it is processed like any other object, without being in special collection for disposable objects. I think it would bring significant performance gain, especially if objects are created often and we expect they die soon. It should be measured, but for that I need some kind of API. What do you think? We've thought about exporting such interface, but the maintenance burden made us back off. This interface has some short-coming and exposing it to managed code has it's problems. For example, it doesn't support unregistering. But, if you make your case on why such a feature would help you, I can look into it. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Removing obsolete Npgsql
Hi, Npgsql in mono seems to be long dead. Judging from the contained RELEASENOTES.txt, this version is from 2004. https://bugzilla.xamarin.com/show_bug.cgi?id=737 this claims that applications should bring their own anyways. Since Npgsql is even added as system assembly in mono/metadata/assembly.c, replacing it is not as straight-forward as with other libraries. Also, this leads to things like http://packages.debian.org/search?keywords=npgsql where people blindly package up what upstream brings along, crippling the mono platform along the way. All in all, I'd say that the upcoming 2.11/3.0 release would be a good time to get rid of this. If there's a chance of getting this merged I'd be willing to create a patch removing mcs/class/Npgsql and all references to it. Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono? - I give up (Not proceeding)
On 2012-05-01 03:44, Rob Wilkens wrote: Ok, So i'll get to where i'm at now: 1) I did an apt-get source mono ran an autogen, make. (and eventually make install) -- figuring this would get me the same version that i was running. When working with Debian packages, you need to inspect the debian/rules file to see how the package is actually built. Since this build is intended for packaging, it will not be usable without building and installing the actual .deb packages. For local building of source packages, I recommended dpkg-buildpackage to drive the process. See http://www.debian.org/doc/manuals/maint-guide/build.en.html Also, you might be missing some of the build-dependencies, which can also easily installed with apt-get build-dep mono. -Direct from the command line without 'mono' command: It works fine, but i suspect that this is using the /usr/bin version There is an explanation on the mono page, describing how to use multiple versions of mono: http://www.mono-project.com/Parallel_Mono_Environments I realize i'm on my own with building from apt-get source, as these are ubuntu files and not mono project files. I'm currently building from the mono-2-10 branch from git, primarily doing a autogen --prefix=... make make install and it worked for me. Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Restart my fork?
Rob,
if you want to go the advanced-git-route, you can always rebase your
patch on top of the current master.
This gives you a clean patch in the face of upstream changes, even in
the same area of code. On the downside, it changes the commit-hashes and
creates a break in the history of your branch.
Please read these docs for an in-depth explanation:
http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
http://git-scm.com/book/en/Git-Branching-Rebasing
If you prefer a more manual method, you can create a new branch, like
Alan described and use cherry-picking and amending to re-apply the
patches from the old branch onto the new master in the correct order.
Thanks for your time and work!
Best Regards, David
On 18.06.2012 04:08, Rob Wilkens wrote:
Thanks very much -- I started a branch for bug 2663 fixes this way just
now. But i need to test it against the latest source to make sure it
still works (there's no reason it shouldn't, but for sanity). I will
probably finish this testing tomorrow since i need to test 'before' and
'after' my patch to make sure (1) the unit tests still pass (2) other
unit tests don't fail unless they were failing before.
-Rob
On 06/17/2012 11:10 AM, Alan wrote:
Generally speaking every time you want to fix something new which is
unrelated to existing patches which have not been upstreamed you can
simply do:
# Lets assume this step is already done and the mono repository is
called 'mono_repo' in your fork
git remote add mono_repo git://github.com/mono/mono.git
# Pull all the latest commits from mono_repo
git fetch mono_repo
# Create a new branch based on the latest commit in mono_repo in the
master branch
git checkout -b NEW_BRANCH_TO_FIX_FOOBAR mono_repo/master
That's the simplest way to get a 100% clean and up-to-date branch
every time you want to make a new fix. When you are done you can push
the new local branch to your fork using the syntax:
git push origin NEW_BRANCH_TO_FIX_FOOBAR
That pushes the curreny branch to a remote branch of the specified name.
Hope that helps,
Alan
On 17 June 2012 15:29, Stifust...@free.fr wrote:
One fix = one patch + one test (if possible).
As for the lock you added, just merge that with your earlier patch, so that
the patch really fully fixes the problem.
If some patch requires another patch first, just specify that here. I'll
probably review the easiest patches first, to get them out of the way. If
you want to suggest a certain review order, go ahead.
Rob Wilkens wrote
I was going to plan to break this up into individual commits, but
instead when i get to this i may break it up into each file's worth of
changes (or in the case of some commits, set of files) and document what
fixes what in each, if that is ok with you? i.e. i'll try to document
what was changed line by line or set of lines, and specifically when
documenting it cover the 'why'.
The reason for this is that i have some changes i made in earlier
commits which 'worked' but every so often crashed while adding an idle
handler i later found, and i fixed this with a lock (this) {} in a later
commit around a very small section of code (2-4 lines).. But that was
after i made unrelated changes elsewhere (the datagrid changes).
Or if you prefer i get it commit by commit i'll do that, but in that
cases, at least some of the commits will have to be applied in the same
order because they have a dependency on a previous commit going through.
-Rob
On 06/17/2012 09:34 AM, Stifu wrote:
Alright, I'm not in a hurry.
Rob Wilkens wrote
I won't have time to do that right now, but will later, please be
patient.. I wouldn't wait around the keyboard right now for an e-mail
because i'm next in line for the shower then we're heading out for
morning.
The bug reports are listed on the pull page, but i will try to separate
the changes out into what fixes what.
-Rob
On 06/17/2012 09:26 AM, Stifu wrote:
Please separate each patch, so I can review them one by one. This is
just
too
big to review, and I don't know even know what it's trying to fix.
Also, please give me the concerned bug reports, if any.
Robert Wilkens wrote
Ok, if you are willing to look at it, i've attached it if i did it
right...
I did a git diffcommit just before first commit last commit
That should have the whole range of changes of all the commits,
hopefully i've attached the right file too.
This should align with the following pull request on github.com:
https://github.com/mono/mono/pull/322
Which originally was a closed pull request which i cancelled when i
needed to make additional changes:
https://github.com/mono/mono/pull/312
I'm probably not going to be home all day today, so if you have
questions, i am willing to answer them but i may be delayed. I'll try
to bring my laptop if i do go out.
-Rob
On 06/17/2012 08:21 AM, Stifu wrote:
Can't really give Git-related advices, I suck at it, but I can easily
review
WinForms patches if you simply attach them to your messages
Re: [Mono-dev] Mono.Posix question
On 2012-06-22 15:35, Rob Wilkens wrote: Do you know where i can find documentation for Mono.Posix? I was looking at the following problem report: https://bugzilla.xamarin.com/show_bug.cgi?id=1970 And I saw that Mono.Unix.UnixDirectoryInfo(1).Create(FileAccessPermissions.AllPermissions); Was honoring umask, because that's what the system call for mkdir does. (That is: Create() just calls mkdir with the permissions.) Should it be honoring umask when it creates the directory, or should we, after the call to mkdir, separately set the permissions as part of the Create call (the equivalent of a call to chmod). My non-normative feeling is that Mono.*Posix* should also behave posixly[1]. So if the reporter want's[1] to chmod after mkdir he can[1] do so - as his report aptly demonstrates. Best Regards, David [1] I don't claim that POSIX was designed for human developers. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono wcf
On 01.08.2012 01:57, icorderi wrote: @Rob Yes localhost is translated to 127.0.0.1 on hosts. But regardless of that, if the wcf service is hosted as net.tcp://localhost:8081 it should work as expected. I would expect it to use localhost if localhost is specified. An easy workaround is to change the config to net.tcp://machine name:8081. I can live with that workaround although localhost should work as expected. I have to deploy the system to 50k servers, although adding a script to change the config post-deployment to match the machine name is an easy workaround it shouldnt be the way to do this. If you're deploying your development config to 50k Servers, changing the URL *afterwards* is probably the least of your problems. Isn't there a wildcard syntax or something like that? Hmm: Fourth hit on Google: http://stackoverflow.com/q/10649078/4918 The point is to replace host name in base address with * symbol (wildcard). It will be changed with actual host name in run time. Tested it and it worked great. Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MoMA
Hi, could someone please remove or update the wikipage at http://www.mono-project.com/MoMA ? the download there only can check against 2.8 and File MoMA bugs still links to the novell bugzilla. Thanks love, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Basic question
On 16.11.2012 02:09, Fasiuddin Mohammed wrote: I got this stupid question in my mind, even though i strictly follow what is being mentioned above, there is a 100% probability that I may end up developing something which is exactly the same as Microsoft has developed. So will that cause a problem? Copyright only concerns *copying.* If you come to the same solution on your own, you are OK. The guidelines you quoted ensure that this is what actually happens. Also the last statement mentions that published documentation should be referred before implementation, so does it mean published documentation by Microsoft or by Mono. if it is the latter, then the documentation by Mono does not contain the information that i am looking for. In that case how should I proceed? I interpret that last statement to refer to Microsoft's documentation: The documentation describes an interface and not an implementation. Therefore it is safe to look at. I am not a lawyer, this is not legal advice, in your jurisdiction everything might be different. Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Status of Win32/SystemEvents
On 25.12.2012 18:08, ma...@manfbraun.de wrote: How does other software handle this [pre-shutdown notification, time-chnages and so on] ?? I've just read about upstart. Is there a common API to that, so I could start to write one or the other function/API call with Interop ?? No, the proper way under mono is to implement System.ServiceProcess.ServiceBase and install a init script (and/or upstart job, and/or systemd unit file) to run the service under mono-service. This way the native init system will signal to mono-service, which in turn will shutdown your service properly. This will also help you under Windows. Does probably have the java guys more system wrappers, so that I should evaluate java ?? But now, I understand, why all my desktop apps - that, I saw until now, never saves anythings, if I log off Best regards, ++mabra -Original Message- From: Oskar Berggren [mailto:oskar.bergg...@gmail.com] Sent: Tuesday, December 25, 2012 4:57 PM To: ma...@manfbraun.de Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Status of Win32/SystemEvents Many of those events do not have simple one-to-one counterparts on Linux or anything besides Windows, because there is a greater variety in how things are done, e.g. different desktop envirorments (or none at all). Several of the things you mention can probably be detected from GNOME or KDE respectively (to give just two examples). Time changed should probably be detected below the layer of GNOME/KDE. /Oskar 2012/12/25 ma...@manfbraun.de: Hi All ! Just trying to port some C# proggis from Windows to Linux. Astoundingly, they fail miserably ... I found, that all Win32.SystemEvents are not working. I have had a look to the API status page and saw TODO ... Can someone probably tell me, what I can expect ?? I am a linux beginner and I am unable to port this by myself. Are there any examples, which shows alternatives for: - user prefs changed - time changed - logoff - shutdown Any help would really be very great! Best regards, ++mabra ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ObservableCollection and BindingList Serialization
On 12.03.2013 10:47, Robert Jordan wrote: In addition, Windows serializes a variable name _busyCount whereas Mono defines _count. Also, I note that BindingList serialization on Mono has different and missing variable names compared to the .NET equivalent. For example, allow_new is allowNew in .NET. In addition, do those serialized variables need to be public or should they be declared as private? They must have the same visibility as in MS.NET. Usually, when a class does not implement ISerializable, Mono's implementation must be changed to match MS down to member naming. It's a tedious work given that we don't look at MS' source code... Shouldn't it be possible to extract clean room serialization descriptors from the MS implementation without having to look at the source? Extracting that into some kind of stable text format then would enable automated comparisons, no? Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ObservableCollection and BindingList Serialization
On 12.03.2013 13:43, Andres G. Aragoneses wrote: On 12/03/13 11:08, David Schmitt wrote: On 12.03.2013 10:47, Robert Jordan wrote: In addition, Windows serializes a variable name _busyCount whereas Mono defines _count. Also, I note that BindingList serialization on Mono has different and missing variable names compared to the .NET equivalent. For example, allow_new is allowNew in .NET. In addition, do those serialized variables need to be public or should they be declared as private? They must have the same visibility as in MS.NET. Usually, when a class does not implement ISerializable, Mono's implementation must be changed to match MS down to member naming. It's a tedious work given that we don't look at MS' source code... Shouldn't it be possible to extract clean room serialization descriptors from the MS implementation without having to look at the source? I think you could automate that via mono-api-info with the --abi flag. That looks interesting, although it does not seem to preserve ordering information, and with a quick I've not been able to get it to inspect the native mscorlib when installed on windows 7. Extracting that into some kind of stable text format then would enable automated comparisons, no? Yes, however, this wouldn't guarantee binary serialization compatibility as far as I understand. It would be just the first step, right? Exactly. But measuring is always the first step to improvement. Best Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] DateTime.ToBinary / TZ differences between windows and linux
Hi, I've used DateTime.ToBinary() to serialize dates between linux (mono) and windows (ms.net). All dates are in CEST (central european standard time), but the timezone's definitions differs between mono and ms.net, causing the wrong time to be displayed. On a recent mono 3.x: csharp new DateTime(1979,6,30).IsDaylightSavingTime() false csharp new DateTime(1980,6,30).IsDaylightSavingTime() true csharp ms.net on the other hand returns true for both calls. This in turn leads to ToUniversal() to return different times. mono's implementation is arguably more correct with regards to reality, as 1979-06-30 really did *not* have DST and 1980-06-30 really *did* have DST. Of course, the best way to work around this would be to convert the complete application and database to use UTC, except when displaying to the user. This is already on the roadmap for other reasons. ;-) The questions for mono-devel are rather: * Is this behavior intentional? * Is there a quick workaround to match mono's and ms.net's behavior? Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Shipping NuGet with MonoDevelop/Xamarin
On 2014-01-24 06:10, Stephen Shaw wrote: I can't speak for the monodevelop project, but one of the problems with nuget is it has a heavy dependency on powershell which is only available on windows. Having said that there is an addin, but as I understand it it has a custom nuget.exe binary in it that just simply ignores all powershell calls. For example, if you install something like entity framework (I think) it has a bunch of powershell script stuff. It would add the dlls, but not run any of the scripts. That said, using nuget to get packages already installed into a solution works flawlessly. Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug with Ssl cert validation
On 2014-03-19 01:55, Greg Young wrote: Just off the top of my head... maybe a summer of code would be better spent on these kinds of issues and improving the throughput of donations as opposed to the next interesting technical topic. +1. The complexities (no obvious build files, no csproj, no visible documentation (e.g. pointed to via README), numerous warnings on default compiles) in building mcs and running tests has also kept me from contributing except in the most trivial ways. Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] crn.com: »Sources: Microsoft In Talks To Acquire Mobile App Development Startup Xamarin«
I love how people jump to assuming the worst outcomes from the rumor mongering of a -- possibly fictional -- anonymous source. Regards, David On 2014-03-20 09:55, Ian Norton wrote: whaat!? article looks far from clear though. does this mean monodevelop is going to quietly die? or a license change? :/ On 19 Mar 2014 23:07, theUser BL theuse...@hotmail.com mailto:theuse...@hotmail.com wrote: Microsoft is in the final stages of negotiations that could lead to either an acquisition or major investment in Xamarin, ... More at http://www.crn.com/news/mobility/300072056/sources-microsoft-in-talks-to-acquire-mobile-app-development-startup-xamarin.htm Greatings theuserbl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] crn.com: »Sources: Microsoft In Talks To Acquire Mobile App Development Startup Xamarin«
I see both. There is enormous potential for mono and -- without further details -- an equal amount of risks. I choose to trust in Miguel's integrity for now :-) Regards, David On 2014-03-20 11:00, Bryan Crotaz wrote: It would be excellent for Xamarin users to get MS cash poured into bug fixing and ease of use (eg the compilation thread). Bryan Crotaz Silver Curve On 20 Mar 2014, at 09:56, Ian Norton inor...@gmail.com wrote: Yeah, maybe I panicked a little. Still, I think it would be a bad thing for mono (in free software terms), but I can see why it would be a good thing for MS from a strategic point of view. On 20 March 2014 09:16, David Schmitt da...@dasz.at wrote: I love how people jump to assuming the worst outcomes from the rumor mongering of a -- possibly fictional -- anonymous source. Regards, David On 2014-03-20 09:55, Ian Norton wrote: whaat!? article looks far from clear though. does this mean monodevelop is going to quietly die? or a license change? :/ On 19 Mar 2014 23:07, theUser BL theuse...@hotmail.com mailto:theuse...@hotmail.com wrote: Microsoft is in the final stages of negotiations that could lead to either an acquisition or major investment in Xamarin, ... More at http://www.crn.com/news/mobility/300072056/sources-microsoft-in-talks-to-acquire-mobile-app-development-startup-xamarin.htm Greatings theuserbl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
My Jenkins built 6d405d4fd9575881920d398f54817cfb9c2054d5 successfully on Mar 19. Regards, David On 20.03.2014 18:08, Greg Young wrote: Before go searching for what happening and whether its something odd here can anyone build trunk right now? I can build 3.2.8 no problem -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] crash with nunit
Hi, I've finally updated to 3.2.8 (recompiled from debian experimental) and am now triggering the attached segfault approximately every second run. For further analysis I could run this under master; try to upgrade nunit; try to get more debugging symbols into the package; try to reduce the amount of code running to trigger the problem. The project is open source, so if that would be easier I can provide public repro steps too. Please advise, Thanks David Stacktrace: Native stacktrace: /usr/bin/mono() [0x4b0a1a] /usr/bin/mono() [0x508fcf] /usr/bin/mono() [0x4231c7] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030) [0x7fc464c80030] /usr/bin/mono() [0x5d0869] /usr/bin/mono() [0x5d1d2c] /usr/bin/mono() [0x5d3b65] /usr/bin/mono() [0x5d4182] /usr/bin/mono() [0x5d7677] /usr/bin/mono(mono_gc_collect+0x28) [0x5d7cf8] /usr/bin/mono() [0x59e3bb] /usr/bin/mono() [0x61e871] /usr/bin/mono() [0x62e810] /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7fc464c77b50] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fc4649c20ed] Debug info from gdb: [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fc460cfe700 (LWP 10197)] [New Thread 0x7fc460eff700 (LWP 10196)] [New Thread 0x7fc4588ab700 (LWP 10174)] [New Thread 0x7fc45a467700 (LWP 10173)] [New Thread 0x7fc46007b700 (LWP 10171)] [New Thread 0x7fc46013f700 (LWP 10170)] [New Thread 0x7fc461cfd700 (LWP 10162)] [New Thread 0x7fc461efe700 (LWP 10159)] [New Thread 0x7fc4620ff700 (LWP 10158)] [New Thread 0x7fc46289b700 (LWP 10157)] 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 Id Target Id Frame 11 Thread 0x7fc46289b700 (LWP 10157) mono 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 10 Thread 0x7fc4620ff700 (LWP 10158) mono 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 9Thread 0x7fc461efe700 (LWP 10159) mono 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 8Thread 0x7fc461cfd700 (LWP 10162) mono 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 7Thread 0x7fc46013f700 (LWP 10170) mono 0x7fc4649c2743 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 6Thread 0x7fc46007b700 (LWP 10171) mono 0x7fc464c7ecec in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 5Thread 0x7fc45a467700 (LWP 10173) mono 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 4Thread 0x7fc4588ab700 (LWP 10174) mono 0x7fc464c7e511 in sem_timedwait () from /lib/x86_64-linux-gnu/libpthread.so.0 3Thread 0x7fc460eff700 (LWP 10196) mono 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 2Thread 0x7fc460cfe700 (LWP 10197) mono 0x7fc464c7fc1d in waitpid () from /lib/x86_64-linux-gnu/libpthread.so.0 * 1Thread 0x7fc465729780 (LWP 10156) mono 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 Thread 11 (Thread 0x7fc46289b700 (LWP 10157)): #0 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x005cd42c in suspend_thread (context=0x7fc46289a900, info=0x18359f0) at sgen-os-posix.c:113 #2 suspend_handler (sig=optimized out, siginfo=optimized out, context=0x7fc46289a900) at sgen-os-posix.c:131 #3 signal handler called #4 0x7fc464c7e41e in sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00629ef8 in mono_sem_wait (sem=sem@entry=0x9725a0, alertable=alertable@entry=1) at mono-semaphore.c:119 #6 0x005a5fa5 in finalizer_thread (unused=unused@entry=0x0) at gc.c:1073 #7 0x00589ca2 in start_wrapper_internal (data=0x1839630) at threads.c:643 #8 start_wrapper (data=0x1839630) at threads.c:688 #9 0x0061e871 in thread_start_routine (args=args@entry=0x17bd448) at wthreads.c:294 #10 0x0062e810 in inner_start_thread (arg=0x18394d0) at mono-threads-posix.c:49 #11 0x7fc464c77b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #12 0x7fc4649c20ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 #13 0x in ?? () Thread 10 (Thread 0x7fc4620ff700 (LWP 10158)): #0 0x7fc464918824 in sigsuspend () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x005cd42c in suspend_thread (context=0x7fc4620fe500, info=0x1a84730) at sgen-os-posix.c:113 #2 suspend_handler (sig=optimized out, siginfo=optimized out, context=0x7fc4620fe500) at sgen-os-posix.c:131 #3 signal handler called #4 0x7fc464c7f3cb in accept () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00615fdd in _wapi_accept (fd=3, addr=addr@entry=0x0, addrlen=addrlen@entry=0x0) at sockets.c:221 #6 0x0057c433 in ves_icall_System_Net_Sockets_Socket_Accept_internal (sock=optimized out, error=0x7fc4620fea74,
Re: [Mono-dev] crash with nunit
Thanks to guidance from Greg Young, I've been able to isolate a proper
backtrace from nunit-console:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffef97a700 (LWP 26908)]
slow_object_get_size (o=0x7fffea860010, vtable=optimized out) at
../../mono/metadata/sgen-gc.h:722
722 } else if (klass-rank) {
(gdb) backtrace
#0 slow_object_get_size (o=0x7fffea860010, vtable=optimized out) at
../../mono/metadata/sgen-gc.h:722
#1 sgen_par_object_get_size (o=0x7fffea860010, vtable=optimized out) at
../../mono/metadata/sgen-gc.h:766
#2 sgen_safe_object_get_size (obj=0x7fffea860010) at
../../mono/metadata/sgen-gc.h:777
#3 sgen_major_is_object_alive (object=0x7fffea860010) at sgen-gc.c:3589
#4 sgen_is_object_alive_for_current_gen (object=0x7fffea860010
\b\020\206\352\377\177) at sgen-gc.c:3624
#5 mark_ephemerons_in_range (ctx=...) at sgen-gc.c:3802
#6 0x005d1d2c in finish_gray_stack (generation=generation@entry=1,
queue=0x972f00) at sgen-gc.c:1931
#7 0x005d3b65 in major_finish_collection (reason=0x705072 user
request, old_next_pin_slot=108, scan_mod_union=0) at sgen-gc.c:3164
#8 0x005d4182 in major_do_collection (reason=optimized out) at
sgen-gc.c:3305
#9 major_do_collection (reason=0x705072 user request) at sgen-gc.c:3287
#10 0x005d7677 in sgen_perform_collection
(requested_size=requested_size@entry=0,
generation_to_collect=generation_to_collect@entry=1,
reason=reason@entry=0x705072 user request,
wait_to_finish=wait_to_finish@entry=1) at sgen-gc.c:3499
#11 0x005d7cf8 in mono_gc_collect (generation=1) at sgen-gc.c:4623
#12 0x0059e3bb in unload_thread_main (arg=0x4a50380) at appdomain.c:2334
#13 0x0061e871 in thread_start_routine (args=args@entry=0x9cfbb0) at
wthreads.c:294
#14 0x0062e810 in inner_start_thread (arg=0x4a4d5b0) at
mono-threads-posix.c:49
#15 0x77539b50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#16 0x772840ed in clone () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x in ?? ()
(gdb)
I'll retry with master next.
Regards, David
On 25.03.2014 15:56, Zoltan Varga wrote:
Hi,
Could you try with master or the mono-3.4.0-branch ? If the problem
is still there, please log a bug report with reproduction instructions/a
testcase if possible.
Zoltan
On Tue, Mar 25, 2014 at 10:44 AM, David Schmitt da...@dasz.at
mailto:da...@dasz.at wrote:
Hi,
I've finally updated to 3.2.8 (recompiled from debian experimental)
and am now triggering the attached segfault approximately every
second run.
For further analysis I could run this under master; try to upgrade
nunit; try to get more debugging symbols into the package; try to
reduce the amount of code running to trigger the problem.
The project is open source, so if that would be easier I can provide
public repro steps too.
Please advise,
Thanks David
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] some weirdness after landing the
Hi, Since one of the following patches, my automatic mono master build fails when calling mozroots afterwards: [build] Staged setup for building assemblies with cyclic dependencies (detail) [System.Core] Add explicit cycle dependency tracking to System.Core (detail) Use LOCAL_MCS_FLAGS to prepend the directories (detail) Drop the extra separator (detail) [build] Prevent cyclic targets from being built in parallel (detail) [build] Drop most uses of LIBRARY_USE_INTERMEDIATE_FILE, clean debug targets (detail) [build] Untangle the System.Web build, just like System and System.Core (detail) Last of the cycles is gone (detail) Adjust the path for Mono.Security (detail) [corlib] Fix ClaimsIdentity default ctor. (detail) [System] Throw IOE in more cases when dealing with an invalid Process object. Fixes #19864 (detail) [build/Facades] Parallelize the Facades directory build (detail) mozroots --import --sync says: Mozilla Roots Importer - version 3.4.1.0 Download and import trusted root certificates from Mozilla's MXR. Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed. Downloading from 'http://mxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1'... Couldn't retrieve the file using the supplied information. Missing method System.Configuration.IConfigurationSectionHandler::Create(object,object,object) in assembly /var/lib/jenkins/mono/mono-master/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll, referenced in assembly /var/lib/jenkins/mono/mono-master/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Update on Build System
On 2014-05-24 04:58, Miguel de Icaza wrote: Hey guys, #1 Makefile Build System Update So the clean staged setup has been added to mono/master and in practice most of you will never notice an improvement. Those working on libraries that had cross dependencies will enjoy reliable and working builds. If you make a change in say System, and you type make in mcs/class/System, it will make sure that all the dependencies are properly compiled and the result will be stable. Awesome news :-) improving the libraries is THE easiest way for us mere mortals to start contributing, and any improvement in the build system is very welcome. Please make sure that the appropriate docs are also updated. Thank you for your time and work! Regards, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
