You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(4) |
May
(4) |
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(54) |
Oct
(57) |
Nov
(23) |
Dec
(24) |
2009 |
Jan
(23) |
Feb
(14) |
Mar
(3) |
Apr
|
May
(7) |
Jun
(24) |
Jul
(26) |
Aug
(24) |
Sep
(16) |
Oct
(4) |
Nov
(10) |
Dec
(22) |
2010 |
Jan
(12) |
Feb
(34) |
Mar
(32) |
Apr
(2) |
May
(6) |
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
(1) |
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(38) |
Sep
(1) |
Oct
(20) |
Nov
(2) |
Dec
(12) |
2012 |
Jan
(2) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(10) |
Jun
(11) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: postmaster <cs...@ch...> - 2016-10-20 05:57:51
|
这是一封 HTML 格式的邮件,请以网页方式查看邮件。 |
From: Allen W. <wi...@kd...> - 2015-02-17 04:52:04
|
Thanks for the report Carlos. A couple things: 1) the repo on sourceforge is dead. please refer to github.com/libical for the up-to-date code. 2) the mailing lists on sourceforge are dead. please use mailing lists shown on our new web page at http://libical.github.io/libical/ look under the "Get Involved" section 3) If you are interested in more errors like the ones you reported, we also have a Coverity Scan available for libical at https://scan.coverity.com/projects/2367 if you want to see the defects, go to that url and ask to become a member of the project We're always looking for more people to help us, so thanks and if you want to help even more we'd be happy to have you. On Thursday, January 22, 2015 12:51:25 AM Carlos Olmedo Escobar wrote: > Hi, > > I've just found some problems with the code (thanks to cppcheck): > > - [libical/src/libicalcap/icalcap_rr.c:512]: (error) Uninitialized variable: ret > The variable ret is useless in icalcap_message_sync_send_rr(), but > can cause problems. > > [libical/src/libicalss/icalbdbset.c:168] -> > [libical/src/libicalss/icalbdbset.c:167]: (warning) Possible null > pointer dereference: options - otherwise it is redundant to check it > against null. > This code makes no sense and should be removed: > if (options == NULL) > *options = icalbdbset_options_default; > > [libical/src/libicalss/icalcstpserver.c:230]: (error) Possible null > pointer dereference: data > The pointer 'data' in icalcstps_process_incoming() is being used but > has no effect. Actually its value is always invalid. > > Regards. > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > Freeassociation-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeassociation-devel |
From: Carlos O. E. <car...@gm...> - 2015-01-21 23:51:31
|
Hi, I've just found some problems with the code (thanks to cppcheck): - [libical/src/libicalcap/icalcap_rr.c:512]: (error) Uninitialized variable: ret The variable ret is useless in icalcap_message_sync_send_rr(), but can cause problems. [libical/src/libicalss/icalbdbset.c:168] -> [libical/src/libicalss/icalbdbset.c:167]: (warning) Possible null pointer dereference: options - otherwise it is redundant to check it against null. This code makes no sense and should be removed: if (options == NULL) *options = icalbdbset_options_default; [libical/src/libicalss/icalcstpserver.c:230]: (error) Possible null pointer dereference: data The pointer 'data' in icalcstps_process_incoming() is being used but has no effect. Actually its value is always invalid. Regards. |
From: Art C. <roo...@un...> - 2014-06-09 13:13:31
|
I sent a couple of messages to the list about the transition, but I see they didn't make it there. I'm totally in agreement and looking forward to working in the new environment. When I have some time later I'll gather up everything I can get my hands on. > Mon Jun 09 2014 09:11:15 AM EDT from "Allen Winter" <wi...@kd...> >Subject: Fwd: Re: Freeassociation mailing list mbox'es > > Art, > Sorry to spam all your Citadel accounts :) didn't know which, if any, would >work. > Since you are the admin of the old freeassociation mailing lists, would it >be possible > to send a subscribers list to David? > > |
From: Kent S. <ks...@it...> - 2014-06-09 05:58:41
|
Looks like you have to sign in to view the report. Do you have an easy way to post a copy of the report somewhere? On Jun 6, 2014, at 4:45 PM, Allen Winter <wi...@kd...> wrote: > You might be able to access the Outstanding Defects report at: > https://scan8.coverity.com:8443/reports.htm#v16495/p10812 > > On Friday, June 06, 2014 04:32:02 PM Allen Winter wrote: >> The Coverity Scan for libical is now setup. >> >> If you want to be involved with helping to cleanup the Coverity errors in libical >> please send me your email address and I will invite you. >> >> Kent: I already invited you >> >> All coverity fixes should be committed into the new coverity_scan branch. >> >> We only are permitted a small number of scans per day so the idea >> is to batch up a few fix commits into the coverity_scan branch before pushing. >> >> Once we have a set of fixes we know work ok, we can cherry-pick them to master. >> >> PS. there are surprisingly few errors found by Coverity. many of them are in the >> test programs where we leak memory with abandon. Some of the low-priority >> warnings are not readily fixable since it would mean changing the API. >> >> Anyway, if you have any interest in helping out please let me know. >> >> -Allen >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech >> _______________________________________________ >> Freeassociation-devel mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeassociation-devel > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Freeassociation-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeassociation-devel |
From: Allen W. <wi...@kd...> - 2014-06-06 20:45:41
|
You might be able to access the Outstanding Defects report at: https://scan8.coverity.com:8443/reports.htm#v16495/p10812 On Friday, June 06, 2014 04:32:02 PM Allen Winter wrote: > The Coverity Scan for libical is now setup. > > If you want to be involved with helping to cleanup the Coverity errors in libical > please send me your email address and I will invite you. > > Kent: I already invited you > > All coverity fixes should be committed into the new coverity_scan branch. > > We only are permitted a small number of scans per day so the idea > is to batch up a few fix commits into the coverity_scan branch before pushing. > > Once we have a set of fixes we know work ok, we can cherry-pick them to master. > > PS. there are surprisingly few errors found by Coverity. many of them are in the > test programs where we leak memory with abandon. Some of the low-priority > warnings are not readily fixable since it would mean changing the API. > > Anyway, if you have any interest in helping out please let me know. > > -Allen > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Freeassociation-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeassociation-devel |
From: Allen W. <wi...@kd...> - 2014-06-06 20:32:19
|
The Coverity Scan for libical is now setup. If you want to be involved with helping to cleanup the Coverity errors in libical please send me your email address and I will invite you. Kent: I already invited you All coverity fixes should be committed into the new coverity_scan branch. We only are permitted a small number of scans per day so the idea is to batch up a few fix commits into the coverity_scan branch before pushing. Once we have a set of fixes we know work ok, we can cherry-pick them to master. PS. there are surprisingly few errors found by Coverity. many of them are in the test programs where we leak memory with abandon. Some of the low-priority warnings are not readily fixable since it would mean changing the API. Anyway, if you have any interest in helping out please let me know. -Allen |
From: Allen W. <wi...@kd...> - 2014-06-03 14:54:08
|
On Monday, June 02, 2014 08:45:58 AM Allen Winter wrote: > https://travis-ci.org/libical/libical > > l think we can add a Mac platform to the CI builds. but no Windows, afaict > I added a Mac build yesterday. seems to work fine. to bad travis-ci can't do Windows yet. there are some pretty cool browser plugins for travis-ci that helps monitor build status. I installed "My Travis" to monitor the libical/libcal builds. Next I'm going to try and setup Coverity scans. that should show us a crapload of problems, I suspect. |
From: David W. <dw...@in...> - 2014-06-02 19:18:42
|
> David, would it be possible to somehow transfer the archives from > freeassociation to infradead? Yeah, if you can get an archive in mbox form that's relatively simple to arrange. -- dwmw2 |
From: Allen W. <wi...@kd...> - 2014-06-02 18:38:04
|
On Sunday, June 01, 2014 10:10:55 PM David Woodhouse wrote: > On Sat, 2014-05-31 at 18:08 -0400, Allen Winter wrote: > > I don't think GitHub provides mailing lists, so I think we need to > > keep SourceForge simply for mailing lists. unless someone has a better > > idea. > > You're welcome to use lists.infradead.org if that's preferable to > SourceForge. > Another possibility is to use google groups. I see there is a libcal on google groups already, but it contains mostly spam. and then there's the problem of what to do with the archives. David, would it be possible to somehow transfer the archives from freeassociation to infradead? |
From: Allen W. <wi...@kd...> - 2014-06-02 12:46:13
|
https://travis-ci.org/libical/libical l think we can add a Mac platform to the CI builds. but no Windows, afaict |
From: Allen W. <wi...@kd...> - 2014-06-01 21:39:03
|
So now I committed lots of extra compiler warnings (for gcc and clang). I may have gone overboard; there are now almost 500 compiler warnings. most of them are of the unsed variable or set-and-unused variable type. but there are plenty of others that deserve a review and probably fixup. if anyone feels like cleaning up this old code, please do. make a pull request on github. |
From: David W. <dw...@in...> - 2014-06-01 21:11:06
|
On Sat, 2014-05-31 at 18:08 -0400, Allen Winter wrote: > I don't think GitHub provides mailing lists, so I think we need to > keep SourceForge simply for mailing lists. unless someone has a better > idea. You're welcome to use lists.infradead.org if that's preferable to SourceForge. -- dwmw2 |
From: Allen W. <wi...@kd...> - 2014-06-01 21:01:36
|
On Saturday, May 31, 2014 07:14:33 PM Allen Winter wrote: > On Saturday, May 31, 2014 06:08:28 PM Allen Winter wrote: > > Howdy, > > > > The github import of the freeassociation code from SourceForge is done. > > See https://github.com/libical > > > > I created an organization called "libical" (unfortunately "freeassociation" was already taken) > > Inside the "libical" organization we have 2 repos: libical and vzic > > > > Lots of cleanup remains and I would like to transfer the bugs, patches and stuff to GitHub as well. > > > > If you want to become a member of the "libical" organization (team) please create an account > > on GitHub (if needed) and send me your username. > > > > I don't think GitHub provides mailing lists, so I think we need to keep SourceForge simply > > for mailing lists. unless someone has a better idea. > > > > If anyone wants to help with the transition please speak up. I can use all the help I can get. > > > > As far as I'm concerned, the SourceForge SVN repo is frozen, so please start using > > the git repos. We can create feature branches now. yay! <- Kent let's do that for RSCALE stuff. > > > > Regards, > > Allen > > We now have a github home page at http://libical.github.io/libical/ > > Also I imported all the issues, bugs, feature requests, support requests and patches. > You will find all those merged together in https://github.com/libical/libical/issues > too bad they are all owned/submitted by me :) > Remember, if you want to monitor commits (I made a few so far today) you'll need to follow the libical/libical project on github. and you'll need to setup your notifications. make sure your notification email is verified. if you join the team (send me your github username) then you should automatically be following. The freeassociation commits mailing list still exists, but should be dead from here forward. |
From: Allen W. <wi...@kd...> - 2014-05-31 23:14:45
|
On Saturday, May 31, 2014 06:08:28 PM Allen Winter wrote: > Howdy, > > The github import of the freeassociation code from SourceForge is done. > See https://github.com/libical > > I created an organization called "libical" (unfortunately "freeassociation" was already taken) > Inside the "libical" organization we have 2 repos: libical and vzic > > Lots of cleanup remains and I would like to transfer the bugs, patches and stuff to GitHub as well. > > If you want to become a member of the "libical" organization (team) please create an account > on GitHub (if needed) and send me your username. > > I don't think GitHub provides mailing lists, so I think we need to keep SourceForge simply > for mailing lists. unless someone has a better idea. > > If anyone wants to help with the transition please speak up. I can use all the help I can get. > > As far as I'm concerned, the SourceForge SVN repo is frozen, so please start using > the git repos. We can create feature branches now. yay! <- Kent let's do that for RSCALE stuff. > > Regards, > Allen We now have a github home page at http://libical.github.io/libical/ Also I imported all the issues, bugs, feature requests, support requests and patches. You will find all those merged together in https://github.com/libical/libical/issues too bad they are all owned/submitted by me :) |
From: Allen W. <wi...@kd...> - 2014-05-31 22:08:45
|
Howdy, The github import of the freeassociation code from SourceForge is done. See https://github.com/libical I created an organization called "libical" (unfortunately "freeassociation" was already taken) Inside the "libical" organization we have 2 repos: libical and vzic Lots of cleanup remains and I would like to transfer the bugs, patches and stuff to GitHub as well. If you want to become a member of the "libical" organization (team) please create an account on GitHub (if needed) and send me your username. I don't think GitHub provides mailing lists, so I think we need to keep SourceForge simply for mailing lists. unless someone has a better idea. If anyone wants to help with the transition please speak up. I can use all the help I can get. As far as I'm concerned, the SourceForge SVN repo is frozen, so please start using the git repos. We can create feature branches now. yay! <- Kent let's do that for RSCALE stuff. Regards, Allen |
From: Allen W. <wi...@kd...> - 2014-05-25 20:43:49
|
On Thursday, May 08, 2014 06:25:12 PM Allen Winter wrote: > Howdy, > > I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub. > > I'd rather be using git than subversion. > I'd like be able to have git feature branches where people can work on bigger features. > > And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system. > Maybe sourceforge has a free CI system, but I can't find such a thing. > > Comments about moving from SourceForget to GitHub? > Pull requests with code review too. So since nobody objects I will plan to make this move happen. -Allen |
From: Milan C. <mc...@re...> - 2014-05-15 17:55:41
|
Hello, I would like to ask, whether it would be acceptable by libical project to provide also GObject introspactable interface for the library, as part of the sources, with optional compilation, to not add a hard dependency on GLib due to it. The reason is that we've got a GSoC 2014 project to complete introspection of calendar part of evolution-data-server, which is using libical and exposes it in public API, but the libical as such is not introspectable, thus we have basically bad luck. The current idea is, instead of doing some ugly hacks on the evolution-data-server side, define GObject-based interface for libical, which will be fully introspectable. This interface would be nice to have as part of libical sources, thus more people interested in it would be able to use it. The tasks for the student will be: - create GObject based interface for structures provided by libical - properly annotate the interface, thus it'll be usable both by the introspection interface generator and by the gtk-doc (thus a nice developer help pages will be created from it too) - provide python3 tests of the introspection interface, with as large coverage as possible, which would be possible to run during 'make check' There will be probably involved some scripts for build-time, for example for enums, to generate them from libical sources, rather than hard-code them and miss any future changes. A script which would check whether any public API function is not missing in the GObject-interface would be also nice. Who knows, if there will be some pattern found, then many of the work would be semi-automated. That all is to be figured out. I do not want to go too much into detail now, nothing is set in the stone. So, would be libical developers willing to include GObject introspection interface of libical in the sources? Thanks and bye, Milan P.S.: I CC'ed also Miao Yu, whom is the student which will do the work. P.P.S.: In case you are not sure, introspection interface allow running the code in languages like python or javascript, which seem to be quite popular, thus the interface may bring more interested users to libical. |
From: IGnatius T F. <roo...@un...> - 2014-05-10 18:14:04
|
>I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub. > >I'd rather be using git than subversion. >I'd like be able to have git feature branches where people can work on bigger features. > >And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system. >Maybe sourceforge has a free CI system, but I can't find such a thing. > >Comments about moving from SourceForget to GitHub? Works for me. I'd much rather see us on git than subversion. Not a fan of SourceForge either. -- Art |
From: Wilfried G. <roo...@un...> - 2014-05-09 23:26:40
|
<html><body> <p>Hi everyone...</p> <p>I've migrated the repo from CVS to SVN way back then because of the first time I looked into 'cvs log' it made me barf.</p> <p>About 15 months later we migrated citadel from SVN to GIT.</p> <p>Clearly git is prefereable over SVN. Probably the sf.net git doesn't provide the neccesary infrastructure like the CI or bugtracker etc?</p> <p>I'm all in for migrating.</p> <p>Please make shure there is a last commit to SVN laying breadcrumbs to the new location.</p> <p> </p> <p>Cheers, Willi</p> <blockquote> <div class="message_header"><span>Fri May 09 2014 08:26:32 EDT</span> <span>from "Allen Winter" <wi...@kd...> </span> <span class="message_subject">Subject: Re: [Freeassociation-devel] Move to GitHub</span></div> <div class="message_content"><tt>On Thursday, May 08, 2014 10:48:29 PM Daniel Corbe wrote:</tt><br /> <blockquote><tt>Allen Winter <wi...@kd...> writes:</tt><br /> <tt></tt><br /> <blockquote><tt>Howdy,</tt><br /> <tt></tt><br /> <tt>I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub.</tt><br /> <tt></tt><br /> <tt>I'd rather be using git than subversion.</tt><br /> <tt>I'd like be able to have git feature branches where people can work on bigger features.</tt><br /> <tt></tt><br /> <tt>And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system.</tt><br /> <tt>Maybe sourceforge has a free CI system, but I can't find such a thing.</tt><br /> <tt></tt><br /> <tt>Comments about moving from SourceForget to GitHub?</tt><br /> <tt></tt><br /> <tt></tt></blockquote> <tt>You realize that git has an SVN module, right?</tt><br /> <tt></tt></blockquote> <tt>Sure and I considered that. but only helps a little.</tt><br /> <tt>It's not just git I want (full featured git), but gitHub so I can use their CI.</tt><br /> </div> </blockquote> <p> </p> </body></html> |
From: Allen W. <wi...@kd...> - 2014-05-09 12:26:49
|
On Thursday, May 08, 2014 10:48:29 PM Daniel Corbe wrote: > Allen Winter <wi...@kd...> writes: > > > Howdy, > > > > I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub. > > > > I'd rather be using git than subversion. > > I'd like be able to have git feature branches where people can work on bigger features. > > > > And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system. > > Maybe sourceforge has a free CI system, but I can't find such a thing. > > > > Comments about moving from SourceForget to GitHub? > > > > You realize that git has an SVN module, right? Sure and I considered that. but only helps a little. It's not just git I want (full featured git), but gitHub so I can use their CI. |
From: Kent S. <ks...@it...> - 2014-05-09 05:06:17
|
I'm all for this. I already use the project as a submodule through git-svn, so being native to git would make things easier for me. Branches and pull requests would make change tracking significantly easier as well. Having CI would also be very nice, as it'd encourage me to write tests directly for the project. I currently have a small set of tests that I run parallel in my own project. GitHub also has that intangible friendlier feel than SourceForge. Kent On May 8, 2014, at 6:25 PM, Allen Winter <wi...@kd...> wrote: > Howdy, > > I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub. > > I'd rather be using git than subversion. > I'd like be able to have git feature branches where people can work on bigger features. > > And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system. > Maybe sourceforge has a free CI system, but I can't find such a thing. > > Comments about moving from SourceForget to GitHub? > > > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > Freeassociation-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeassociation-devel |
From: Daniel C. <co...@co...> - 2014-05-09 03:02:32
|
Allen Winter <wi...@kd...> writes: > Howdy, > > I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub. > > I'd rather be using git than subversion. > I'd like be able to have git feature branches where people can work on bigger features. > > And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system. > Maybe sourceforge has a free CI system, but I can't find such a thing. > > Comments about moving from SourceForget to GitHub? > You realize that git has an SVN module, right? |
From: Allen W. <wi...@kd...> - 2014-05-08 22:42:25
|
Howdy, I'm thinking we should migrate from Subversion at SourceForge to Git at GitHub. I'd rather be using git than subversion. I'd like be able to have git feature branches where people can work on bigger features. And a really big thing I want is CI, and GitHub projects can leverage the travis-ci.org system. Maybe sourceforge has a free CI system, but I can't find such a thing. Comments about moving from SourceForget to GitHub? |
From: Ken M. <mu...@an...> - 2014-03-15 16:41:58
|
When running some tests on my server, I found that a VFREEBUSY component with a DTSTAMP was incorrectly being rejected. I audited restrictions.csv against RFCs 5545 and 5546 and came up with the attached diff. At some point, I will audit all of the components/methods, but I have bigger fish to fry at the moment. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University |