Re: bug 592 - be confused by _darcs/prefs/author

On Mon, Mar 29, 2010 at 05:03:28PM +0100, Eric Kow wrote:
> The attached patch creates a bug pointing out that be is confused when
> people use email addresses like "Eric Kow <eric.kow <at> gmail.com>" in
> _darcs/prefs/author.

Thanks for the report.  It's now fixed in my branch:
  http://www.physics.drexel.edu/~wking/code/bzr/be
  wking <at> drexel.edu-20100519111736-uwhrh7hqvxn3ogg9

Chris,
Bump for merge & release ;).

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: bug 592 - be confused by _darcs/prefs/author

Hi Trevor,

   > Chris, Bump for merge & release ;).

Thanks, merged.  I'm getting a crash in the test suite, with Fedora's
bzr-2.1.0-1.fc14.x86_64:

Recursive remove should empty the tree. ...
/usr/lib64/python2.6/site-packages/bzrlib/lockable_files.py:61:UserWarning:
'LockableFiles(<bzrlib.transport.local.LocalTransport
url=file:///tmp/BEtestpVoIKk/.bzr/checkout/≥)' was gc'd while locked
/usr/lib64/python2.6/site-packages/bzrlib/lock.py:163: UserWarning: lock on <open file
u'/tmp/BEtestpVoIKk/.bzr/checkout/dirstate', mode 'rb+' at 0x2d24ed0> not released

<hang>

Any ideas?

- Chris.
--

-- 
Chris Ball   <cjb <at> laptop.org>
One Laptop Per Child

Bzr LockableFiles error in recursive remove

On Wed, May 19, 2010 at 12:21:26PM -0400, Chris Ball wrote:
> Thanks, merged.  I'm getting a crash in the test suite, with Fedora's
> bzr-2.1.0-1.fc14.x86_64:
> 
> Recursive remove should empty the tree. ...
/usr/lib64/python2.6/site-packages/bzrlib/lockable_files.py:61:UserWarning:
'LockableFiles(<bzrlib.transport.local.LocalTransport
url=file:///tmp/BEtestpVoIKk/.bzr/checkout/≥)' was gc'd while locked
> /usr/lib64/python2.6/site-packages/bzrlib/lock.py:163: UserWarning: lock on <open file
u'/tmp/BEtestpVoIKk/.bzr/checkout/dirstate', mode 'rb+' at 0x2d24ed0> not released
> 
> <hang>

Hmm.  I have no problems with my

  Bazaar (bzr) 2.0.1
  Python interpreter: /usr/bin/python2.6 2.6.4

Searching around, it seems the Bazaar people have been having garbage
collection issues recently:
  https://bugs.launchpad.net/bzr/+bug/391024
  https://bugs.launchpad.net/bzr/+bug/438378
You can try running
  bzr selftest --no-plugins
following bzr bug 438378 and see if you get the same exception in the
Bazaar test suite.  Anyhow, I imagine it's a bzr issue...

If you want to troubleshoot it,
  libbe.storage.vcs.base._recursive_remove
only uses (from libbe.storage.vcs.bzr)

Re: Bzr LockableFiles error in recursive remove

On Wed, May 19, 2010 at 01:56:07PM -0400, W. Trevor King wrote:
> You can try running
>   bzr selftest --no-plugins

I just did this myself and I got some very similar errors:

  /usr/lib/python2.6/site-packages/bzrlib/lockable_files.py:62: UserWarning:
'LockableFiles(<bzrlib.transport.local.LocalTransport
url=file:///tmp/testbzr-Ya3ef_.tmp/bzrlib.tests.per_bzrdir.test_bzrdir.TestBzrDir.test_format_initialize_on_transport_ex_force_new_repo_False%28BzrDirFormat5%29/work/repo/branch/.bzr/>)'
was gc'd while locked
    warnings.warn("%r was gc'd while locked" % self.repr)
  /usr/lib/python2.6/site-packages/bzrlib/lock.py:163: UserWarning: lock on <open file
u'/tmp/testbzr-Ya3ef_.tmp/bzrlib.tests.per_bzrdir.test_bzrdir.TestBzrDir.test_format_initialize_on_transport_ex_force_new_repo_False(BzrDirFormat5)/work/repo/branch/.bzr/branch-lock',
mode 'rb+' at 0xfa06700> not released
    warn("lock on %r not released" % self.f)

If it's a race condition in Bazaar, that might explain why I didn't
have problems when I ran the BE tests earlier.

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org

Re: Releases and versions

Ben Finney <bignose+hates-spam <at> benfinney.id.au> writes:

> "W. Trevor King" <wking <at> drexel.edu> writes:
>
> > I've written up a little release script that bundles all the steps
> > we've mentioned so far into a single command. Of course, we'll still
> > have to keep NEWS up to date on our own.
> >
> > The output prints a trace of what's going on:
> […]
>
> That looks like it's doing all the right things. Great to see
> automation being used where it makes sense. I'm looking forward to a
> release resulting from this when you guys are ready.

Ping.

Six months later, how are we looking for a first version of Bugs
Everywhere? Where should I expect to see the source tarball when it's
released?

--

-- 
 \     “Men never do evil so completely and cheerfully as when they do |
  `\        it from religious conviction.” —Blaise Pascal (1623–1662), |
_o__)                                                   Pensées, #894. |
Ben Finney

_______________________________________________
Be-devel mailing list

Re: Releases and versions

Hi,

   > Six months later, how are we looking for a first version of Bugs
   > Everywhere? Where should I expect to see the source tarball when
   > it's released?

Hm.  I guess I'm not convinced of the value in making a release unless
we can include a web interface, but I haven't found time to help
integrate cfbe.  I'd want us to make a lot of noise about a first
release, and I think we'd be making a mistake to attract new people
over to us while we're still without cfbe or similar -- we wouldn't
get so much publicity again, so I think we should make ourselves as
attractive as possible.

(I realize that there's a chicken and egg problem here, whereby we
aren't making releases because we want more code first, yet making a
release would hopefully draw more people into helping us with code.)

This might be a good time for me to offer to step down and let someone
else take over handling the stable branch/releases, since I'm not
putting enough time into it.  That said, if we can get cfbe integrated
I'd be happy to handling making a formal release after that.

What do folks think?

Thanks,

- Chris.
--

-- 
Chris Ball   <cjb <at> laptop.org>

Re: Releases and versions

On Wed, May 19, 2010 at 07:56:21PM -0400, Chris Ball wrote:
> Hm.  I guess I'm not convinced of the value in making a release unless
> we can include a web interface, but I haven't found time to help
> integrate cfbe.

Perhaps it's time for a 1.0 target bug with some dependencies ;).  I
certainly felt like everything was ready to go, and you'd just been
too busy to get around to it.

We discuss CFBE integration periodically (see Steve's comments on Thu,
Jul 23, 2009, and on Tue, 17 Nov 2009 (with extensive follow-up)), but
we tend to get sidetracked and talk about the versioning process
instead of integration specifics.  The confusion about the recommended
path head + lack of time and GUI interest tends to keep things the way
they are.  If it's really a blocking issue for you, add (a) bug(s)
explaining what it would take for you to move things forward ;).

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: Releases and versions

I have nothing to add on much of the rest, but I wanted to put forth a
suggestion:

"W. Trevor King" <wking <at> drexel.edu> writes:

> The confusion about the recommended path head + lack of time and GUI
> interest tends to keep things the way they are.

If there is acutally a lack of interest in the GUI, perhaps we're not
talking about a 1.0 version. From my perspective, a version 0.1 or
version 0.5 or whatever, *without* the GUI, would be just as good or
potentially better because it would be simpler and sooner.

--

-- 
 \         “What is it that makes a complete stranger dive into an icy |
  `\   river to save a solid gold baby? Maybe we'll never know.” —Jack |
_o__)                                                           Handey |
Ben Finney

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: Releases and versions

On Wed, May 19, 2010 at 07:56:21PM -0400, Chris Ball wrote:
> Hi,
> 
>    > Six months later, how are we looking for a first version of Bugs
>    > Everywhere? Where should I expect to see the source tarball when
>    > it's released?
> 
> Hm.  I guess I'm not convinced of the value in making a release unless
> we can include a web interface, but I haven't found time to help
> integrate cfbe.  I'd want us to make a lot of noise about a first
> release, and I think we'd be making a mistake to attract new people
> over to us while we're still without cfbe or similar -- we wouldn't
> get so much publicity again, so I think we should make ourselves as
> attractive as possible.

I am not sure that to have an official release we need cfbe merged. 
We can just make a release (0.1 ? 0.2 ? the last one in debian is the
0.0.193+bzr.r217-2, I suppose a little old) and then go on to merge cfbe and 
other features, perhaps with some more manpower.

> What do folks think?

+1 to have a 0.5 release even without cfbe.

bye
Gianluca

Stable branch and release.

Hello

I have a little proposal about the stable release/stable branch.

Given that it seems necessary a GUI and a web interface (with read/write
possibilities), I agree that it can be too early for a 1.0 release.

So my proposal is to merge the Trevor's tree into the stable branch (if
it's ok for Trevor and Chris of course) and than make available a new 
development version as a tar file.

This way we can continue to work on cfbe/gui/whatever and in the same time
we can give the packagers something to package (that hopefully can attract
some more people).

bye
Gianluca