On 03/01/2013 15:24, Autif Khan wrote: > On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon > <ajlen...@dynamicdevices.co.uk> wrote: >> On 02/01/2013 20:27, Autif Khan wrote: >>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan <autif.ml...@gmail.com> wrote: >>>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon >>>> <ajlen...@dynamicdevices.co.uk> wrote: >>>>> Hi all, Autif, >>>>> >>>>> I've been working to support .NET development on Linux >>>>> over the past few days. >>>>> >>>>> There is a Visual Studio plugin, MonoTools for Visual Studio >>>>> which provides support for local and remote debugging of >>>>> .NET applications with Mono. >>>>> >>>>> This requires a remote stub to be running on the target >>>>> platform, monotools-server. >>>>> >>>>> I've created a recipe to build monotools-server, which in >>>>> turn required me to pull in Openembedded Legacy recipes >>>>> for mono-xsp and gtk-sharp. >>>>> >>>>> As it stands I'm now able to build an X enabled image for >>>>> the Raspberry Pi and remote-debug some simple Windows >>>>> Forms .NET applications within the Visual Studio IDE. >>>>> >>>>> Recipes are hosted here in 'recipes-mono' >>>>> >>>>> g...@git.assembla.com:ciseco-eve.meta-eve.git >>> >>> I could not "git clone" the repo. >> >> Apologies. I should have given you the public r/o link. >> >> Originally I was trying to avoid modifying meta-mono, adding .bbappends >> into my own meta-eve layer instead, but since my last post to you I >> found I couldn't build against the current HEAD of Yocto due to some odd >> file location issues which I couldn't overlay. (i.e. it didn't seem to >> be able to pick up the patches where you had them - although was fine >> with an older commit of the Yocto core). >> >> As a result I've moved the original meta-mono patches that weren't being >> picked up by bitbake and merged my additions into a fork of meta-mono >> which is here: >> >> git://git.assembla.com/ciseco-eve.meta-mono.git > > Got it. > > I scanned thru the code and saw what you did to re-organize the > directory structure. > > When I get back, I will see if I can build libGDI+ and mono with > denzil (I am stuck with denzil for reasons beyond my control, or until > I find a show stopping bug in denzil for our project - unlikely) > > Meanwhile, I have no questions about changes for gk-sharp, mono, > mono-xsp and monotools-server. >
Good oh. > Presumably, you will take care of the "TODO: This needs fixing > properly and needs to be revisited" in mono_<version>.bb - I > definitely do not want unstripped binaries on my distribution - > presumably, this was needed for some debugging and is not meant to be > checked into production. Ah yes. I'd forgotten about that. I shall habe to revisit why that was erroring. > I could not understand the purpose of > libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch - > could you please help me understand what prompted these seemingly non > trivial changes. > Yes there seems to be a problem building libGDI against libpng15. It seems a known issue: https://github.com/mono/libgdiplus/pull/4 > Everything else looks good. > Good oh >> I'm coming up the curve on Git, as I migrate from mainly Subversion use. >> Can I issue a "pull request" to you or some such? > > Yes, a pull request should work. > >>> Presumably, you want to release the recipes with the MIT and/or GPLv2 >>> licenses. >>> >>> If the license is different for monotools-server or mono-xsp or >>> gtk-sharp, you will likely have to submit a patch for README file too. >>> Even otherwise, section 4 in README needs to be updated. If you have >>> any tasks left - please add them to section 10. >>> >> >> Will double check this. I am waiting for feedback from the >> monotools-server people on their license as there's nothing explicit in >> their source. > > Will wait for that. Might affect the README > I'll give them another nudge once I've worked our what's going on with the stripping, commit to my fork and then try to work out how to send you a pull req. >>> The guidelines for the Yocto project are very similar to other FOSS >>> projects including the Linux kernel. They are outlined here: >>> >>> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines >>> >>> I used the following as a guide when I have submitted my patches in >>> the past. This is for the Linux kernel, adapt as appropriate for >>> meta-mono. >>> >>> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/ >>> >>> Please submit separate patches for each of the recipes (presumably >>> there are no changes to the mono/libGDI+ recipes) >>> >>> Please add me to the "To:" recipient (I filter a lot of PATCH related >>> traffic) - this should allow the emails to be caught by the filter >>> instead of archiving. >>> >>> In case I do not respond within 72 hours, please email me with a >>> gentle reminder :-) >>> >>> I have not had the opportunity to integrate patches just yet, please >>> bear with me in case I screw up. >>> >>> Thanks again for contributing! >>> >>> PS #1: If you do not want to go thru the hassle - please email me the >>> tar.gz as an attachment and I will check it in directly - a bad side >>> effect of this would be that you will not get any "git" credit for >>> this >>> >>> PS #2: I am still on vacation, but had a few hours - the 72 hour clock >>> will start only after Monday :-) >>> >>> And finally, PS #3: >>> >>> http://marc.info/?l=linux-usb&m=135229956521385&w=2 >>> http://marc.info/?l=linux-usb&m=135119051922403&w=2 >>> http://marc.info/?l=linux-usb&m=134858043613838&w=2 >>> http://marc.info/?l=linux-usb&m=134791970203982&w=2 >>> ... many others ... >>> >>> Please refrain from top posting :-) >> >> Happy to try if that's the etiquette here - like this? >> >>> Autif >>> >>>>> If there is interest in migrating these recipes into meta-mono >>>>> and somebody will review them then I'll be pleased to make >>>>> whatever changes are needed to comply with relevant >>>>> Yocto policies. >>>> >>>> Absolutely! >>>> >>>> I am about to embark on a vacation returning to work on Jan 7. >>>> >>>> More then - Unfortunately, I will not have time to look at this today >>>> or until Jan 7. >>>> >>>> Working hard - then playing hard :-) >>>> >>>> I will dig into then when I return. >>>> >>>> (Side note - we gave up on GTK# recipe and decided that Windows forms >>>> are 'good enough' for us. This makes me glad :-) >>>> >>>>> >>>>> Best Regards, (& Happy Holidays) >>>>> >>>>> Alex >>>>> >>>>> >> _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
