Re: SV: SV: SV: [Mono-list] PKCS#12 example
Hellan.Kim KHE wrote: I'll have a more in-depth look at this tonight if nobody do this until then. Thank you, I really appreciate that! Unfortunately, the code is more difficult for me to grasp than what i thought before reading it. Then, you'll have to wait to get some help from me. :-) However, trying to fix this problem might be a good idea to dig into the code, if nobody do it until then. -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: SV: SV: SV: SV: [Mono-list] PKCS#12 example
Hellan.Kim KHE wrote: I also took a look at the code, but I really don't know enough about crypto standards to be able to see what goes wrong. I guess that the code doesn't add the localKeyID attribute to the keyBag safeBag, but i may be wrong. -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: SV: [Mono-list] PKCS#12 example
Hellan.Kim KHE wrote: So whenever I try to install this PKCS#12, the certificate is put in the Other people category instead of Personal due to the missing private key. Have you tried to examine the PKCS#12 file with openssl pkcs12 to make sure that everything is in the right place ? Regards, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: SV: SV: [Mono-list] PKCS#12 example
Hellan.Kim KHE wrote: Thank for that advice. I can see that there definitely is something wrong with the PKCS#12 (no attributes). Yes, apparenlty the local key id is missing. But how do I set the correct attributes? I don't know. By quickly reading the code, i don't see where this attribute is set, so it _might_ not be set. I'll have a more in-depth look at this tonight if nobody do this until then. Regards, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Verifying certificate against root certs in store
Hellan.Kim KHE wrote: I'm looking for the correct way of verifying a X509Certificate (issuer) against all certificates in found in the LOCAL_MACHINE Trusted root authorities certificate store in Windows. Do you mean that you have a x509 end certificate (not a CA certificate) and that you want to control its validity against all trusted root authorities certificates stored in the Windows' key store ? Or do you want to compare a given x509 certificate with all trusted root authorities certificates stored in the same key store ? Regards, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Bug Day
Hello, Paul F. Johnson wrote: We had some good movement on this, but the idea seems to have gone dead. As for me, the idea hasn't gone dead, i'm waiting for comments from key developers. However, bringing this on the mono mailing lists again is a good idea :-). Are we going to have a Gnome style bug splatting day on the 3rd or 10th Sept? Not on the 3rd, probably not on the 10th neither if nobody among key developers speaks up. Maybe we should setup the first bug day without wating from comments and see if everything goes well. The only problem is that many of us won't have the needed credentials to modify bugs status, so we'd have to e-mail the developers and tell them we think that this bug should be marked as this, we were able to reproduce it on the following platform, under these conditions, etc.. It could be tedious, but it can't hurt the Mono project to have more people at a time looking at the bugzilla. Also, this first try would help us organize better for the first official bug day. What do you think about this ? -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Paul F. Johnson wrote: However, bringing this on the mono mailing lists again is a good idea :-). It was my son that reminded me - he thinks the idea of bugs in software is funny (he is 7 and to him, bugs are what you squish with a shoe!) :-). Are we going to have a Gnome style bug splatting day on the 3rd or 10th Sept? Not on the 3rd, probably not on the 10th neither if nobody among key developers speaks up. I think we should poke them with a stick. Not a nasty stick, possibly one with a feather on the end ;-) Does any developer read this thread ? If so, could you please tell us how relevant our idea is ? Maybe we should setup the first bug day without wating from comments and see if everything goes well. A dry run? Sounds like it could be interesting. A dry run, indeed. The only problem is that many of us won't have the needed credentials to modify bugs status, so we'd have to e-mail the developers and tell them we think that this bug should be marked as this, we were able to reproduce it on the following platform, under these conditions, etc.. Which is the idea of the triage (from my understanding). Bugs roll in, tested and if it fails due to not a programming fault, then it gets passed to the code doctors who know it's a genuine problem and not just someone messed up. I totally agree on that. As to having the credentials, you're right. In the past I've been part of a porting effort to get gcc onto RISC OS and parts of that were mind blowing! From what I've seen, mono is almost as bad, but does have the advantage of C# being quite an easy language which is simple enough to follow. By credentials, i meant that any non developer can't modify a bugs status, IIRC. This is annoying if we want to triage bugs, since we have to ask someone who has the right to modify bug status to do so. What I would suggest is this. If we can get one of the key developers (Jordi, Ben, Peter, Miguel or anyone else for that matter) and a couple of those who understand the compilers innards (patch submitters) and do a couple of dry run scenarios (say we take a random selection of bug reports), we try and get the faults to occur and then pass them over. and we tell them how we would modify the bug properties (branch concerned, milestone, component, priority, severity, etc.) These faults don't have to be real ones either. Can you tell us more about this ? I don't understand how we could use fake bugs. This will serve to do a couple of things. Firstly, it will help with time difference problems and any communication difficulties. It'll also demonstrate the work required plus give us (the non Novell people) a work out! Again, I totally agree with you. All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Paul F. Johnson wrote: These faults don't have to be real ones either. Can you tell us more about this ? I don't understand how we could use fake bugs. Basically, one of the developers reports a fault (under an assumed name of course) which on the surface looks completely correct, but has a very small fault in. It sounds like a good idea to me. -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Mono Bug Day
Paul F. Johnson wrote: On Thu, 2005-08-25 at 16:04 +0200, Paolo Molaro wrote: On 08/23/05 Julien Gilli wrote: There hasn't been any feedback from several core developers on this point. So I ask the same question again :-). Do you think that it's something that could be help mono development ? Yes, it would be useful. Who is going to step up and organize everything? What needs to be done? I think that putting the following couple of pages together on the Wiki : - General informations on bug days : * What is a bug day ? * Who can attempt ? * When does it take place ? - Detailed informations on what to do during a bug day : This can be split in two parts : bug squashing and bug triaging : * As for bug triaging : * How to find bug reports that are most important to triage ? * How to triage a bug report ? * As for bug squashing : * How to find bug confirmed bug reports that are most important to fix ? * How to fix a bug ? along with an IRC channel and a mailing-list to announce special events (like special bug days before a release, etc.) could be a good step forward :-). What do you think about this ? I can give some time to help organize these bug squashing/triaging thing. I can write the wiki pages too . However, I think we should discuss about conventions used by mono developers for the bugzilla system (like what version or milestone a bug report should be assigned to, etc.) before doing it. Looking forward to hear your comments. All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Hello, Paul F. Johnson wrote: I think that putting the following couple of pages together on the Wiki : - General informations on bug days : * What is a bug day ? * Who can attempt ? This would need to be split and preferably, peer mentored. I don't understand what you think should be peer mentored. Do you mean that attempting a bug day should be peer mentored ? Or were you mentionning writing up these pages should be peer mentored ? For example, user a may write and compile some code which clearly shows (say) MWF is broken for spot colours. This is submitted and a peer proofs the code to see that it's not user a who has made a boo-boo before submitting as a real bug. I totally agree with that, it is a typical use case of a bug day :-). * When does it take place ? Logistically, the third is the biggest one given the diversity of places people are (I'm in the UK for instance while Peter (say) is out by 6 hours from GMT). I'd suggest that the bug day would need to be split into two half days for when the developers are around. IIRC, the GNOME project has bug days from 15 PM to 21 PM UTC, which is nice during the week. I agree that bug days during the week-end would be fine too. Maybe we could split bug days with one in the middle of the week and one during the week-end ? - Detailed informations on what to do during a bug day : This can be split in two parts : bug squashing and bug triaging : * As for bug triaging : * How to find bug reports that are most important to triage ? * How to triage a bug report ? All bugs are important, just some more than others. I remember finding one very small bug in an application called TechWriterPro (it's a RISC OS app) which when investigated, proved to be massive and set back the release schedule by a month. I agree too, but there are some special cases for which you could want to focus your attention on a certain kind of bugs (just before a release, a feature freeze, whatever). * As for bug squashing : * How to find bug confirmed bug reports that are most important to fix ? * How to fix a bug ? Ideally, the developers, though others should never be discouraged. This is were the peer review comes into it's own - bugs which aren't bugs never get past the reviewer. I agree too : triaging bug is the primary goal, nevertheless fixing them is great :-). Would this bug day be best set on a saturday or sunday though? What do you think about the middle of the week/week-end schedule i mentionned above ? Maybe we should set a goal for the first milestone, like having a bug day next saturday, or on 09/10 ? By trying to get things done, we will probably come across some problems that we'll resolve, and then we can go from there for the future bug days. Again, looking forward to hearing from you :-). All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Paul F. Johnson wrote: This would need to be split and preferably, peer mentored. I don't understand what you think should be peer mentored. Do you mean that attempting a bug day should be peer mentored ? Or were you mentionning writing up these pages should be peer mentored ? The reports coming in. For example, if I was to submit a massive lump of code which demonstrated two bugs, neither of which depending on each other, then the reviewer would reject the code and ask for the smallest case of each to demonstrate the point. Ok, got it :-). All bugs are important, just some more than others. I remember finding one very small bug in an application called TechWriterPro (it's a RISC OS app) which when investigated, proved to be massive and set back the release schedule by a month. I agree too, but there are some special cases for which you could want to focus your attention on a certain kind of bugs (just before a release, a feature freeze, whatever). True. I'm assuming this will be a freeze before an official beta release (going by the time line). In that case, some order of importance needs to be given over - something like (most important) compiler and mono runtime - corelibs - MWF [inc. cairo/libgdiplus] - monodevelop - gtklibs - monodoc (least). I've distinguished between MWF and the corelibs as despite it being mega important, having the likes of Encoding, threading and IO streams working spot on is of greater importance as a whole. Again, I will refer to GNOME for this : they use the term showstopper for bugs that truly shows. That is, everybody get to see the consequence of the bug. As for GNOME, it can be for example the mouse pointer that get locked inside the panel, or evolution that can't send and e-mail. It must be highly reproductible, and affect many platforms. Briefly, the order of importance here is given by how many users can see the bug and how much it prevents them from doing what they want. For example, if there's a bug that prevent monodevelop from starting, it would be marked as a showstopper, whereas not being able to compile a given type of not so often used code with the compiler (which is more a core component than monodevelop) would not. Maybe we should set a goal for the first milestone, like having a bug day next saturday, or on 09/10 ? Next sat sounds fine, though will there be enough time to set things up and would it be an idea for there to be a default email address (say [EMAIL PROTECTED]) whereby test cases arrive to all the reviewers and if they pass, bugzilla them? We can go this way, or mark bug that have not been reviewed as UNAPROVED and then wait for either a developer or a bug day buddy to confirm it before working on a fix. Whatever we choose, we must have some agreement from the key developers to even start thinking about seting up what we are discussing now. All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Daniel Morgan wrote: Maybe a Pre-Release Days instead of Bug Day would be more appropriate for Mono. What do developers think about this ? I think that doing the hard work little by little is easier than having a big sprint once in a while, but I agree that prerelease days would be a great thing too :-). We could help with docs, update status info on the mono wiki, test building the pre-release tarballs, test a pre-release of the installers, etc... And of course, make sure any serious bugs are squashed so we can have an outstanding stable release. However, any pre-release tarballs, RPMs, or installers would not be downloadable from the Downloads page. Maybe only available as ftp and the word prerelease is in the tarball or installer's filename. Just some ideas... They sound great to me, however I don't think that prerelease days serve the same purpose as a bug day. I think that there is room for the two of them :-). -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Daniel Morgan wrote: Since GNOME is having a bug day, would it be possible that Mono have a Bug Day too? http://live.gnome.org/Bugsquad/BugDays There hasn't been any feedback from several core developers on this point. So I ask the same question again :-). Do you think that it's something that could be help mono development ? The bug squad days are good for GNOME development, one reason is because there are so many developers working from time to time on the code and so many bugs to squash, that everything get a bit messy quickly. Maybe this is not the case for Mono, and thus the idea of a Mono Bug Day is irrelevant. What do you think about this ? Best regards, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Daniel Morgan wrote: Since GNOME is having a bug day, would it be possible that Mono have a Bug Day too? FWIW, it sounds like a good idea to me. I would be glad to get involved if such a thing is set up. Best regards, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Examples of proprietary code developed on Mono
On Mon, 2005-04-04 at 20:54 -0400, Jonathan Pryor wrote: On Mon, 2005-04-04 at 14:36 +0200, Julien Gilli wrote: On Mon, 2005-04-04 at 06:48 -0400, Jonathan Pryor wrote: On Mon, 2005-04-04 at 12:33 +0200, Julien Gilli wrote: Generally speaking, if it's non-commercial it would be considered to be proprietary, even if source code is present, as the non-commercial aspect greatly limits the target audience (why work on something you can't possibly sell?). Well, it seems to me that many FOSS projects do it. As I mentioned, a commercial license means that the code *can* be sold and used in a commercial application. It seems all the confusion is due to my misunderstanding of your words (and my bad english). I thought that you meant *must* instead of *can*. Mea culpa. What does make such FOSS projects as gcc, the autotools, GNOME, Apache, OpenLDAP, and so on inherently commercial to you ? The fact that I have the option to *sell* these tools if I so choose. So again, we agree on this point. My point is that we shouldn't over simplificate our words when talking to somebody coming from the proprietary software world about the different ways to distribute FOSS software. I think that the answer to the following question : Was wondering if anybody could tell me of any instances where proprietary software has been developed using Mono? which was : The FAQ explicitly states that you can write commercial programs with Mono might confuse things a little bit by creating an identity relationship between commercial and proprietary software, which are two differents things (as you clearly mentionned above). Regards, -- Julien Gilli [EMAIL PROTECTED] IDEALX signature.asc Description: This is a digitally signed message part
Re: [Mono-list] Examples of proprietary code developed on Mono
On Sat, 2005-04-02 at 14:04 -0500, Miguel de Icaza wrote: Was wondering if anybody could tell me of any instances where proprietary software has been developed using Mono? The FAQ explicitly states that you can write commercial programs with Mono, My poor english might be causing a little bit of misunderstanding on my side, but aren't proprietary and commercial two unrelated terms ? Does the ability to write commercial programs imply that you can make them proprietary ? Regards, -- Julien Gilli [EMAIL PROTECTED] IDEALX signature.asc Description: This is a digitally signed message part
Re: [Mono-list] Examples of proprietary code developed on Mono
On Mon, 2005-04-04 at 06:48 -0400, Jonathan Pryor wrote: On Mon, 2005-04-04 at 12:33 +0200, Julien Gilli wrote: Generally speaking, if it's non-commercial it would be considered to be proprietary, even if source code is present, as the non-commercial aspect greatly limits the target audience (why work on something you can't possibly sell?). Well, it seems to me that many FOSS projects do it. I haven't seen much non-commercial software anywhere. What does make such FOSS projects as gcc, the autotools, GNOME, Apache, OpenLDAP, and so on inherently commercial to you ? Does the ability to write commercial programs imply that you can make them proprietary ? For a majority of companies, Commercial and Proprietary are one and the same, as a majority of companies aren't FOSS companies. So there is a strong implication that the ability to write commercial programs means you can write proprietary programs, which is why it usually isn't necessary to explicitly state that proprietary programs are allowed. My point is that, even if in most situations, the proprietary concept is not adequate (because, as you say, some companies do not have any FOSS activity), it is very much important to differentiate the two concepts (proprietary and commercial) when it makes sense. I think it makes sense when we talk about mono, doesn't it ? Regards, -- Julien Gilli [EMAIL PROTECTED] IDEALX signature.asc Description: This is a digitally signed message part
Re: [Mono-list] OutOfMemoryException
On Fri, 2005-03-18 at 15:29 +0300, Yury Serdyuk wrote: I've encountered problem trying allocate array of 1 Gb size on machine with 4 Gb RAM : What is the output of the execution of the following shell command : ulimit -d ? -- Julien Gilli [EMAIL PROTECTED] IDEALX signature.asc Description: This is a digitally signed message part
Re: [Mono-list] compile from cvs
Hi, On Thu, 2004-09-30 at 09:58 +0200, Roy M. wrote: I try to compile mono from cvs but when I do ./autogen.sh --prefix=/usr/local --with-preview I get the following error: Running autoheader... autoheader-2.5x: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' Running automake --gnu ... automake: mono/mini/Makefile.am: warning: automake does not support libmono_la_LDFLAGS being defined conditionally Can you tell us more about the version of the autotools you use (automake, autoheader, autoconf and libtool) ? Regards, -- Julien Gilli [EMAIL PROTECTED] IDEALX ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] compile from cvs
On Thu, 2004-09-30 at 10:47 +0200, Roy M. wrote: Sure. I use the following versions automake (GNU automake) 1.4-p6 I use automake 1.8.5-2 (from debian). Could you please try to upgrade your version of automake and run the autogen.sh script once more ? autoheader (GNU Autoconf) 2.59 autoconf (GNU Autoconf) 2.59 The autoconf version looks good, i use this one. Upgrading your automake version should allow you to go further into the compilation process. Regards, -- Julien Gilli [EMAIL PROTECTED] IDEALX ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
