gmane.comp.web.zope.opencore.devel

Re: Re: Moving more stuff to github, (temporarily?)shutting down SVN and Trac

Paul Winkler — 2011-12-08T19:53:51

Thanks, I just updated the links on the project front page,
although it looks like the "getting started" guide needs an update
too.


On Wed, Dec 07, 2011 at 11:07:37AM -0500, Ethan Jucovy wrote:

Re: Re: Moving more stuff to github, (temporarily?)shutting down SVN and Trac

Ethan Jucovy — 2011-12-07T16:07:37

Hey,

https://svn.socialplanning.org/svn/opencore/
point to

Sorry, I keep putting off replying to this because I didn't have an
answer...

...but now I think I do.  I've now rebuilt the live Coactivate installation
with SVN down, using all-github repositories, and I've also pushed code
changes -- even to the git-9UaJU3cA/F/QT0dZR+AlfA< at >public.gmane.org:socialplanning/opencore.git
repository, which is the one that's always terrified me to think about
moving off SVN.

So, I think we may as well call the migration to Github permanent at this
point.

Eventually I may put the SVN repo back online somewhere in read-only form,
just in case .. but all the history should be preserved in the various
github repos.  As for Trac, I'm not sure if I'll end up using Github Issues
or a Trac site but either way it'll eventually come back up in at least a
read-only form.

FYI, for anyone trying to build an opencore site, the best requirements
profile for fassembler is now published at
http://dist.socialplanning.org/build/requi

Re: Moving more stuff to github,(temporarily?) shutting down SVN and Trac

Paul Winkler — 2011-11-03T15:15:03

Hiya, just wondering what the status of this is. 
I recently wanted to look at something in the opencore source (don't remember
what) and it took me a while to find it, because I forgot you were doing this
move, and the source and trac links on
http://www.coactivate.org/projects/opencore/project-home are currently
non-functional.... 
source just points to https://svn.openplans.org/svn/opencore/ which has a
README-MOVED file which points to https://svn.socialplanning.org/svn/opencore/
which is of course currently down.   Should I update README-MOVED to point to
Github, or is that temporary, or what?

Thanks,

- PW

On Sep 10, 2011 02:40 PM, Ethan Jucovy wrote:
https://github.com/socialplanning,




--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2011/11/1320333303473
To unsubscribe send an email with subject "unsubscribe" to opencore-dev< at >lists.coactivate.org.  Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpCm6D+HspMUB< at >public.gmane.orgg for questions.

Moving more stuff to github,(temporarily?) shutting down SVN and Trac

Ethan Jucovy — 2011-09-10T14:40:25

Hey,

I'm going to be shifting servers for a bunch of stuff over the next few
weeks, mainly in preparation for moving CoActivate.org to a new hosting
provider.  One of the first steps I'd like to take is shutting down the
Slicehost server that's currently hosting the SVN and Trac sites for
OpenCore & friends.  I'll probably set them up again once all the new
servers are in place, but for the moment it'll be much more convenient for
me to just keep them archived on my laptop, until everything has settled.

So, my hazy plan, which I'd like to at least start moving on this weekend,
is something like this:

1) Finish moving all active projects from https://svn.socialplanning.org/svnto
https://github.com/socialplanning, including the opencore repository itself.

2) Make sure opencore builds work properly from Github.

3) Take https://svn.socialplanning.org/svn offline and copy its full
repository to my laptop.

4) Make sure opencore builds still work properly from Github with SVN
totally offline.

5) Release a lo

Re: dist.socialplanning.org now on github

Ethan Jucovy — 2011-06-21T15:19:45

Slight update:

Cloning the dist.socialplanning.org git repo to make small changes was
annoying (because of the huge ./eggs/ directory) and I want to be able to
add other things to dist.socialplanning.org in the future without trouble
(like requirements profiles)

I realized Github Pages supports submodules.  So I created a new repo for
the eggs themselves: https://github.com/socialplanning/eggs -- and added
that as a submodule in
https://github.com/socialplanning/dist.socialplanning.org.  So now it's
possible to clone dist.socialplanning.org.git lightly (by not using the
--recursive flag) and everything still works.  The only catch is that before
running rebuild_egg_index.py you need to make sure the submodule is cloned;
and after running it you need to push the changes to the eggs repo, and then
update the submodule reference to the new head.

Note that opencore users should not need to know these details; they only
matter for anyone who might want to change the files on the
dist.socialplanning.org website

dist.socialplanning.org now on github

Ethan Jucovy — 2011-06-07T15:16:47

Just a heads up -- I've moved http://dist.socialplanning.org from my
Slicehost account to a Github Pages site.  Hopefully this will make builds
faster, and be more maintainable.  And save me space. :)

The git repo that's being served lives here:
https://github.com/socialplanning/dist.socialplanning.org

There's a rebuild_egg_index.py script there which should be re-run whenever
a new file is added to the repo -- since Github Pages doesn't serve
Apache-style dynamic index pages if there's no index.html file.

The repo is over the Github soft size limit for an account (0.3G; it's
closer to 0.9G) but hopefully they won't mind; Github staff have said in
various forums that they don't worry much about the size limit for free
software projects.

Also, if you want to be added to the socialplanning Github Organization,
just ping me or rmarianski.

-Ethan


--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2011/06/1307459829237
To unsubscribe send an email with subject "unsubscribe"

Invitation: Federated Social Web - Conference Europe &W3C Group

elf Pavlik — 2011-05-15T23:43:30

Hello,

I would like to invite you to join us for the upcoming Federated Social Web Europe Conference - June 3-5th in Berlin
http://d-cent.org/fsw2011/

And also consider joining W3C Federated Social Web incubator group (soon changing into community group)
http://www.w3.org/2005/Incubator/federatedsocialweb/

We send invites to various projects working on protocols for federated social networking and developers of open source platforms implementing them. You can see growing list of invites here:
http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/FSWE2011_-_Sent_Invitations

If you would like to join us for the conference but need help with organizing your travel and stay in Berlin, please add yourself to the list on this page:
http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/FSWE2011_-_Travel_Support_Requests

Please also feel invited to take a closer look on the wiki of our group, still in it's early stage but already providing some information about group participants, related protocols and s

Re: Moving stuff to Github

Ethan Jucovy — 2011-04-24T21:36:43


I just finished an opencore git export:
https://github.com/socialplanning/opencore

I had to do it differently.  Don't really understand it, definitely don't
understand why.  The objects in .git/refs/remotes were missing after a git
svn clone, and I eventually realized it was because `git svn clone` was
auto-running `git gc` after the import, and `git gc` was removing those
files.  The result was that `git branch -r` still knew about all the
branches and tags, but `git chechout some-branch-name` put me in detached
HEAD state, and `git push github --all` never uploaded any branch
information.

The solution was to turn off auto-gc by first init'ing the repo, then
setting some config variables, then running the import:

$ git svn init --stdlayout
https://svn.socialplanning.org/svn/opencoreopencore.git
$ cd opencore.git
$ git config --add gc.autopacklimit 0
$ git config --add gc.auto 0
$ git svn fetch --authors-file=../users.txt

After that I was able to move the remote branches and tags from
.git/refs/remotes

Re: Moving stuff to Github

Ethan Jucovy — 2011-04-23T20:17:23

Small correction:

On Sat, Apr 23, 2011 at 10:00 AM, Ethan Jucovy <ethan.jucovy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:


The above line is wrong -- it should be

cp -Rf .git/refs/remotes/* .git/refs/heads

Otherwise branches are missing.  (It's possible to fix ex post facto by
manually moving all the branch refs into ./heads and doing a git push --all

Moving stuff to Github

Ethan Jucovy — 2011-04-23T14:00:36

I'm starting to move stuff to Github under an organization here:
https://github.com/socialplanning -- starting with the smaller / more
standaloney things from SVN.  Let me know if you want to be added to the
organization.

So far I've moved:

* fassembler / opencore-fassembler_boot / opencore-fassembler_projects
* sven / svenweb
* libopencore
* flunc

Also Deliverance now lives here:
https://github.com/deliverance/Deliverance/ (as
of a few weeks now)

I don't have any plans to shut down the SVN repository, but I'd like to get
actively maintained stuff over to Github.  I'm planning on keeping
trac.socialplanning.org for issue/task tracking.

For posterity, here's how I'm porting the projects:

  $ git svn clone --stdlayout -A users.txt
https://svn.socialplanning.org/svn/flunc /tmp/flunc.git
  $ cd /tmp/flunc.git
  $ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/
  $ rm -Rf .git/refs/remotes/tags
  $ cp -Rf .git/refs/remotes/* .git/refs/
  $ rm -Rf .git/refs/remotes
  $ git branch -l  # check that it looks sa

Re: Xinha upgrade coming soon,and flexible WYSIWYG configurations

Ethan Jucovy — 2010-12-27T17:31:26

Update on this:

OpenCore trunk is now using the latest copy of Xinha trunk (which will
become Xinha 0.97).  We have a local import of the newest Xinha code in
oc-js and OpenCore now uses it.  CoActivate is now running the new Xinha for
all users.

I believe I've caught all of our local modifications and applied them to the
new version.  I was able to refactor them all into new extension points in
Xinha core, plus structured plugin packages in OpenCore's distribution.  I
submitted patches upstream for the extension points.

During the process, Xinha's lead developer James (gogo) gave me commit
access to the Xinha core repository, so I was able to apply the patches
upstream myself.  I'm going to see about making a Xinha 0.97 release to
coincide with the next OpenCore release so that we can depend on a known
tag.

-Ethan

On Sat, Sep 4, 2010 at 5:46 PM, Ethan Jucovy <ethan.jucovy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:



--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archiv

BZR/wiki explorations

Ethan Jucovy — 2010-12-17T04:39:04


I checked in some code on trunk which converts a project wiki history to a
bzr repository.  The immediate goal is just getting a complete history for
project export, but if this continues to seem promising I'll be looking into
using it for live backups as well.

Sorting all commits globally by date across a given project is important to
me.  This is tricky, because CMFEditions storage is CVS-like (no global
revision number) so an in-memory sort really doesn't work for large wikis.
 Instead, I do the procedure in two phases: first, store all the commits'
metadata in a sqlite db; then, retrieve them, sorted by timestamp, from the
rdb and commit them to a bzr repo in order.  This is working surprisingly
well.

http://trac.socialplanning.org/opencore/browser/opencore/trunk/opencore/nui/wiki/bzrbackend.py

I've tested it against some pretty difficult data from Coactivate: nearly
up-to-date copies of the opencore project wiki; another large and
long-running wiki; and a smaller/younger wiki with lots of non-ASCII

Re: Do you use Listen 0.7 (trunk)?

Ethan Jucovy — 2010-12-15T17:05:53

As promised, I've gone for the fork/splinter option, since it seems like the
least messy option I've come up with.  I've unimaginatively named the
package opencore-listen and made a first release on PyPI:

http://pypi.python.org/pypi/opencore-listen/0.8a

<http://pypi.python.org/pypi/opencore-listen/0.8a>It's based on the 0.6
branch.  The code is at

https://svn.socialplanning.org/svn/opencore-listen/trunk/

I'll be updating opencore to use this version.

On Fri, Dec 3, 2010 at 7:40 PM, Ethan Jucovy <ethan.jucovy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:



--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/12/1292432782652
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-81qHHgoATdGNjXQcXLqYpFN6ohzGQtmt< at >public.gmane.org  Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+b< at >public.gmane.org for questions.

Do you use Listen 0.7 (trunk)?

Ethan Jucovy — 2010-12-04T00:40:38

Hi,

I'm wondering if there are many people using the Listen 0.7 series, which is
Listen trunk and has had two PyPI releases (most recent:
http://pypi.python.org/pypi/Products.listen/0.7.1 in Feb 2009)

The reason I ask is that I've been making changes on the 0.6 branch - mostly
i18n bugfixes, but, more recently, an increasing number of other changes
that aren't just one-line bugfixes.

I've been periodically making new bugfix releases of the Listen 0.6 series
(most recent: http://pypi.python.org/pypi/Products.listen/0.6.4 in July
2010) but now that I'm making changes that are less like strict bugfixes,
I'd much rather be making more "significant" releases.

Background: I've been changes to Listen as needed in OpenCore, the software
that runs CoActivate.org and some other sites.  AFAIK the needs of OpenCore
have generally driven Listen development for most of its history and the
Listen committers have mostly been developers working on OpenCore.  Listen
0.7 provides a revamped user interface.  Unfortunately,

Re: Managing the email queue

Ethan Jucovy — 2010-11-29T16:11:08

I just had to look up this information which turned out to be in my email
offlist, so I thought I'd post it on the list --

On Thu, Jul 23, 2009 at 1:27 PM, Robert Marianski
<rmarianski-FT8GhGvzL34gsBAKwltoeQ< at >public.gmane.org>wrote:


The command to run is:

$ cd /path/to/opencore/installation/var/maildrop-spool/spool
$ find -mtime +4 -exec mv {} ../quarantine/{} \;


--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/11/1291047100352
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-81qHHgoATdGNjXQcXLqYpFN6ohzGQtmt< at >public.gmane.org  Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+b< at >public.gmane.org for questions.

Two zcmlloader targets

Ethan Jucovy — 2010-11-21T14:40:36

A little while ago Paul checked in some changes to the zcml-autoinclusion
stuff.  His checkins explain what's going on, but I wanted to mention it on
the list too where it'll be easier to find later on.

Paul found that distribute and setuptools don't iterate over entrypoints in
the same order.  The result was that if you install opencore with
distribute, things break.  Some plugins (opencore.cabochon I think) were
trying to use the IProvideSiteConfig utility during their own component
initialization.  But the IProvideSiteConfig utility is itself registered by
a plugin (fassembler.configparser) -- so there was an implicit ordering
dependency, that fassembler.configparser's ZCML had to be loaded before
opencore.cabochon's.

The order in which plugins are loaded within a single <topp:includePlugins>
directive is based on the order of items yielded from iter_entry_points.
 With setuptools, fassembler.configparser's [topp.zcmlloader] entrypoint
happened to appear first, but with distribute, it happened not to.

Re: Re: Build failures

Paul Winkler — 2010-11-09T17:23:32

If that's still happening somewhere (I haven't seen it but that
doesn't mean it's not happening :-)), a safer fix would be to
acquisition-wrap it, something like:

    sa = sa.__of__(em.context)

Re: Re: Build failures

Robert Marianski — 2010-11-09T17:11:40

Of course the exact specifics escape me now, but I vaguely remember
that it was needed to generate paths/urls for message catalog brains.
I've found that the brain expects to be able to get to the request
through acquisition, which it normally picks up from the catalog but
for whatever reason it wasn't here in one of the code paths. If the
export code through all the paths works without it though, I say
remove it.

Robert


--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/11/1289322705579
To unsubscribe send an email with subject "unsubscribe" to opencore-dev< at >lists.coactivate.org.  Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpCm6D+HspMUB< at >public.gmane.orgg for questions.

Re: Re: Build failures

Ethan Jucovy — 2010-11-09T16:01:59


It looks like you actually cargo-culted that from Listen trunk:

http://dev.plone.org/collective/changeset/106320/Products.listen/trunk/Products/listen/extras

rmarianski's log message was "add workaround for no request in acquisition
wrapper when exporting messages"

I don't know when that situation was occurring, or whether it's still
occurring .. but if opencore's export is working for you, that's as good a
test as any we've got.

Rob, do you happen to remember anything about that changeset in listen or
what bug it was working around?  I'll probably need to remove that line from
listen as well.  (But, it doesn't matter for opencore ATM, since Paul's code
is avoiding calling that method for memory reasons.  I think I'm going to
try porting Paul's workarounds there to Listen as well.)


--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/11/1289318541941
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-81qHHgoATdGNjXQcXLqYpFN6ohzGQtmt< at >public.gmane

Re: Re: Build failures

Paul Winkler — 2010-11-08T19:53:17

(snip)
(snip)

And, as happens so often, the light bulb went on a minute later :-p

Fixed in r27763. The log message:

"Fix for mystery pickling errors in project export view: Don't assign
REQUEST on a persistent object that normally acquires it, or else
you'll end up trying to save the request object in the ZODB, which a)
is stupid and b) blows up if REQUEST.set_lazy(method) has ever been
called, since you can't pickle an instancemethod.  I probably
cargo-culted that from some test code, sigh."

Considering that ZODB works by pickling whatever crap you throw at it,
I'm actually impressed that this doesn't happen more often.

Re: Re: Build failures

Paul Winkler — 2010-11-08T19:44:17


Unfortunately, this means that production logs will be filled with
pickling errors every 30 seconds or so.  These appear to be harmless
(hence why I put in that transaction.abort() in the first place, to
suppress them) but I can't for the life of me figure out the root
cause. Here's what I know:

After reading
http://stackoverflow.com/questions/569754/how-to-tell-for-which-object-attribute-pickle-fails
I hacked the copy_reg module as suggested, which led me to this
slightly improved error:

TypeError: can't pickle instancemethod objects (<bound method SessionDataManager.getSessionData of <SessionDataManager at /session_data_manager>>)
 
So, something has a reference to that getSessionData bound
method. Okay, but what has the reference?  Stepping through with pdb
reveals that the object we're trying to pickle at the time is the
mailing list's mail_catalog attribute.  

So it appears that somehow, the bound method getSessionData is
attached to mail_catalog - but I've no idea where or how that happens,
and gr