Matthias Beyer | 19 Mar 21:14 2016

Is this project still alive?


I'm looking for text based bug tracking software and BE looks promising, though
there are no commits since 2013... so...

Is this project still alive?
Is it usable?


Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.
Be-devel mailing list
Be-devel <at>
Dave MacFarlane | 13 Jan 01:07 2016

Bugs in BE


I've been interested in BE for a while, but never a big user of it. I've been writing my own distributed bug tracking software to address (what I think are) some of the shortcomings and wanted to look towards BE for some inspiration, but I've encountered a couple of bugs with the be client. (Be version 1.1.1 installed with apt-get on a relatively clean Ubuntu 15.10 install.)

1. It doesn't work if the user doesn't have the PAGER environment variable set when they log in. (even just running "be help" crashes with a stack trace.) Oddly, setting PAGER, and then unsetting it works fine. But if it was never set, BE crashes on just about everything and is unusable. 
2. "be commit" commits any staged files that are unrelated to BE, not just the .be directory
3. The "Live HTML bug repository" link on the web page is, ironically, broken.
4. In fact, all the links to BE on the website are broken, including the git clone URL, because they seem to mostly be pointing to gitorious (which is why I just installed it with apt-get and didn't verify if the bugs were present on the current development tip.)

Unrelated to these bugs, I have a question:

I'm trying to import a BE database into my own issue tracker, and everything in BE seems to be in the bug's comments/ directory, one subdirectory per comment with the metadata stored in a JSON file. The date on the comments appears to always be in RFC 822 format, which doesn't collate very well.

Does this mean that to display an bug be needs to load the JSON for all the comments on the bug, parse the date into something sortable, sort the bugs, and then display the comments, or is there an easier way to get the comments in chronological order that I'm missing?

- Dave
Be-devel mailing list
Be-devel <at> | 26 May 02:02 2015

Bug and target listing utilities

Hi everyone,

I just spent some time working out the best way to list my targets, their blockers, and bugs without targets.

These seem like basic functions that would best be rolled into the default commands but I implemented them quickly in shell (relying partially on bash-specific functionality but it'd be easy to make more-portable).

Hopefully, other people find the attached useful. I just include it in my .bashrc.

Attachment (be-utils.bash): application/octet-stream, 3363 bytes
Be-devel mailing list
Be-devel <at>
Mike Evans | 5 May 11:00 2015

Stil active? Also gitorious is shutting down


I've just cloned your repo on gitlab.  I looks an interesting project.  I've applied PR17-unicode-warnings
with no issues and I'm looking at the others.

I've also "fixed" sorting by making the latest bug appear at the bottom of the list.  Not committed yet.

I's like to see dates in the list view too, looking into that.

Mike Evans


Anti NSA?  Use PGP.  

Be-devel mailing list
Be-devel <at>
John N Pham | 29 Mar 21:37 2015

Stil active? Also gitorious is shutting down


Is this project dead? There seems to be no commits since 2013 and no
mailing list replies in the last year.

Also, gitorious is shutting down and the project will have to be
migrated to gitlab or github.


Sebastian | 12 Sep 01:50 2014

How to remove custom extra-strings from a bug? (import-xml seems buggy to me)


To add a custom extra string to a bug I use "be show --xml <bug>", add  
an XML tag like


and then import this file with "be import-xml -r <bugdir> <file>".  
This works just fine.

But how do I remove such a custom extra-string? The documentation of  
"import-xml" says:

     *.extra_strings recieves special treatment, and if --add-only is not
     set, the resulting list concatenates both source lists and removes

My understanding is that if I supply an XML file which has the above  
line *twice* will remove the extra string from the bug ("removes  
repeats"). But this is not happening (it is still there, but not  
duplicated). Am I doing something wrong, is the help misleading, or is  
the implementation buggy?

Furthermore, if extra-strings is not supposed to be used for *custom*  
strings, is there something different to use / abuse to add  
functionality without altering "be" itself? I'd like to use  
extra-strings to add effort estimations to bugs. Note that I use "be"  
via an own interface, so the set of commands required can be ugly, as  
long as it works. ;)

Any help appreciated in advance!


Luis Belmar-Letelier | 28 Jul 18:47 2014

cli to set active_status



  be set inactive_status

I have from .be/xxx/settings a JSON dict::

  $ more .be/ac6291d0-cb37-48b4-9868-1c7e83e77150/settings
   "extra_strings": [
    "SUBSCRIBE:W. Trevor King <wking <at>>\tall\t*"],
   "inactive_status": [
     "The bug is no longer relevant."],
     "The bug should no longer occur."],
     "It's not a bug, it's a feature."],
     "Unknown meaning.  For backwards compatibility with old BE bugs."]

$ be set active_status '{"severity_def":[["Very Very Urgent", "bla bla"]'

Did not work, is the setttings edition the only way to edit them ?


Be-devel mailing list
Be-devel <at>
Luis Belmar-Letelier | 28 Jul 18:44 2014

Bug with different locals


I get this bug, when I use BE from different locals.

Here how to reproduce it


$ be init
Using git for revision control.
BE repository initialized.

$ echo $LANG
$ be new -aluis issue33
Created bug with ID d87/da5

$ be show d8/da5
          ID : da559b28-cca0-467d-aded-1dd1772a2c8e
  Short name : d87/da5
    Severity : minor
      Status : open
    Assigned : luis
    Reporter : Luis Belmar-Letelier <luis <at>>
     Creator : Luis Belmar-Letelier <luis <at>>
     Created : Mon, 28 Jul 2014 17:19 (Mon, 28 Jul 2014 15:19:35 +0000)

$ export LANG=fr_FR.utf8
(lab) [][luis <at> spinoza test]$ be show d8/da5
Traceback (most recent call last):
  File "/home/luis/lab/bin/be", line 26, in <module>
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/ui/", line 393, in main
    ret = dispatch(ui, command, args)
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/ui/", line 305, in dispatch
    ret =, options, args)
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/command/", line 590, in run
    return, args)
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/command/", line 302, in run
    self.status = self._run(**params)
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/command/", line 118, in _run
    with_comments=not params['no-comments'])
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/command/", line 186, in output
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/", line 334, in string
    if self.time == None:
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/", line 210, in _get_time
    self._cached_time = utility.str_to_time(self.time_string)
  File "/home/luis/lab/lib/python2.7/site-packages/libbe/util/", line 162, in str_to_time
    time_val = calendar.timegm(time.strptime(str_time, RFC_2822_TIME_FMT))
  File "/usr/lib/python2.7/", line 467, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.7/", line 325, in _strptime
    (data_string, format))
ValueError: time data u'Mon, 28 Jul 2014 15:19:35 +0000' does not match format '%a, %d %b %Y %H:%M:%S +0000'
(lab) [][luis <at> spinoza test]$

Be-devel mailing list
Be-devel <at>
Luis Belmar-Letelier | 23 Jul 21:46 2014
Picon gone 502 again


The web demo
has gone 502 again

Be-devel mailing list
Be-devel <at>
Antony Lee | 11 Feb 03:44 2014

Various issues

(First part of the message is re-posted from a previous email that I sent as a non-member and got lost somewhere...)

- Bugs could record local timezone instead of displaying timestamps as +0000.

- Regarding the messages saying that BE crashes on different locales due to strptime failure, I think BE should set the locale to C when serializing timestamps anyways (possibly retranslating them back to the user-defined locale when displaying them to the user), as there is no guarantee that all participants to a project use the same locale.

- I tried to make BE work under Windows (cygwin, to be precise) using a repo first created under Linux, but there is (at least...) an issue with the path separator (entries in id-cache do not match paths constructed with os.path.join/os.path.sep) -- probably some normalization always using posixpath is necessary (after all "/" is a valid pathsep under Windows too).


Be-devel mailing list
Be-devel <at>
spam | 25 Jan 16:24 2014

storage of time information is local dependent

Dear All,

I'm completely new to BE, but am very interesting in getting it to work 
as I really like the concept.
I tried the latest release (1.1.1) a few weeks ago, but after getting 
database corruption, I decided to try the latest from git (commit 49808..).

I immediately got problem though, when trying "be init", followed by "be 
new test1":
C:\utv\eget\t>be new test1
'utf8' codec can't decode byte 0xf6 in position 1: invalid start byte
You should set a locale that supports unicode, e.g.
   export LANG=en_US.utf8
See for details

as you can see from my command prompt, I tried this on Windows. 
Win7/64-bit with Swedish locale to be more specific.

After some research, I found the offending part it in 
libbe/util/, line 105:
RFC_2822_TIME_FMT = "%a, %d %b %Y %H:%M:%S +0000"

this is later used in
def time_to_str(time_val):

I believe that the problem is that on Windows, the C library used by 
python emits an ansi-encoded string. The %a format gives the Swedish 
abbreviation which is "lö" today. Later on, the json serialization has 
problem with this.
My first thought was to try to get a unicode string instead of a more or 
less arbitrary encoded string, but after digging around a little more, I 
found out that the generated string is actually used in the stored database:
C:\utv\eget\t>grep time .be -r
"time": "25 jan 2014 15:03:59 +0000"
"time": "25 jan 2014 13:24:13 +0000"
[I patched the RFC_2822_TIME_FMT format string to get be running, by 
removing the %a]

My main question after the somewhat lengthy explanation is if it really 
is by intention that the serialized format for dates should be locale 
dependent? My guess is that it could cause problem for users running 
different locales, who are accessing the same data? My suggestion would 
be to stick to the offset_since_epoch format (in UTC) for storage, and 
use the formatted version solely for user interaction.

As I'm completely new to BE, I hesitate a little before trying to 
suggest a patch which changes the internal storage format. But if above 
seems like a good idea and maybe if I could get some pointers/ideas from 
someone more experienced with the codebase, I could try to make a fix 
for the above problem.

Sidenote: I see an email on Nov 25, "Crash when showing a bug in a 
different locale", which I suspect could be because of the same problem.

Best Regards,