Ready for a release?

As I mentioned previously, the unit tests are all passing. I'd like to 
make a release soon, perhaps 0.3.5. Since the "partition manually" code 
has some major bugs that we don't have automated tests for and that will 
take at least a few months to fix, I propose to disable that button on 
the "Partition" page for this release (Easy Partition appears OK and 
passes the unit tests).

For the Live CD/USB, the network interfaces config needs to be switched 
back to 192.168.0.23, devel-features.sh needs to be removed, and other 
trivial changes; otherwise it's serviceable.

I also think bugs #213, #214 (verify fix in svn), and (ideally) #221 
should be resolved before the release.

Is anything else not ready?

--

-- 
Sincerely,
James Crofts
jcrofts@...

Unit tests pass!

The currently implemented unit tests all show up as "OK". I've made a 
point of following the "fix the code, not the test" principle, but there 
are some remaining bugs that the unit tests don't check for, in addition 
to some like:

"Change netmask address. ... ToDo: Implement this!
OK"

The unit test output is attached. I'm wondering if it would be a good 
idea to have a second test class similar to CommonTestClass, but with a 
different set of assumptions about the disks. In particular, the 
"partition manually" code in partition.py is quite complex, is known to 
contain bugs, and is not covered by the unit tests at all as far as I 
can tell.

--

-- 
Sincerely,
James Crofts
jcrofts@...

cryptobox <at> cryptobox:~/upstream$ bin/do_unittests.sh
check the find_major_minor_of_device function ... OK
check the is_part_of_blockdevice function ... OK

----------------------------------------------------------------------
Ran 2 tests in 1.126s
OK
Check various broken configurations ... OK

Unit test progress & questions

I've nearly got my unit test setup perfected (4 errors remaining, plus 
the bugs I know about for which unit tests don't exist.

I'm trying to hunt down some bugs/inconsistencies regarding the logging 
system. Specifically, I observed that __set_device() in sites.py doesn't 
output the warnings and debug statements it should even when the cbox's 
preferences as output by the log show it's set to Level=debug. Using 
print() statements in the code, I noticed that in this context (i.e. 
__set_device()), Python thinks its log level for the "Cryptobox" logger 
object is set to 40 (defined by Python as "ERROR", according to Python 
help(logging)).

There are other cases where the log priorities aren't quite meshing; I 
just gave one example.

Do you guys have any hints to offer as to what I'm missing?

--

-- 
Sincerely,
James Crofts
jcrofts@...
GnuPG Public Key ID 0xF1A60347
Fingerprint 29B9 6231 94D6 AAB9 486F  C731 9763 08B3 F1A6 0347

Should we have a CAPTCHA on the website?

There have been some spam defacements of individual pages on the website 
recently (see http://devel.cryptobox.org/timeline). They seem to be 
occurring every few weeks or so. If there's an easy way to add a "human 
test" or CAPTCHA to the site that might be an option, or even a trivial 
way to roll back undesirable changes would make this less annoying.

Right now the easiest way I know of is to copy the contents of the last 
"good" version to a text editor, edit out all the line numbers that 
shouldn't really be part of the source code in the "fixed" version, copy 
the corrected text back into the wiki editor text box, and finally 
submit the corrected replacement version. Is there an easier way I'm 
missing?

--

-- 
Sincerely,
James Crofts
jcrofts@...

Do you have any newer cryptonas-server package for debian?

Hi,

Do you have any newer cryptonas-server package for debian?

I tested cryptobox-server_0.3.4.5-1_i386.deb with lenny.
The following patches were necessary to use the package.

# diff -Naur /usr/lib/python2.5/site-packages/cryptobox/core/settings.py.org
/usr/lib/python2.5/site-packages/cryptobox/core/settings.py
--- /usr/lib/python2.5/site-packages/cryptobox/core/settings.py.org	2009-04-15
15:32:10.000000000 +0900
+++ /usr/lib/python2.5/site-packages/cryptobox/core/settings.py	2009-04-15
15:33:20.000000000 +0900
@@ -557,8 +557,8 @@
 [Locations]
 MountParentDir = directoryExists(default="/var/cache/cryptobox-server/mnt")
 SettingsDir = directoryExists(default="/var/cache/cryptobox-server/settings")
-TemplateDir = directoryExists(default="/usr/share/cryptobox-server/template")
-DocDir = directoryExists(default="/usr/share/doc/cryptobox-server/www-data")
+TemplateDir = directoryExists(default="/usr/share/cryptobox-server/templates")
+DocDir = directoryExists(default="/usr/share/cryptobox-server/www-data")
 PluginDir = listOfExistingDirectories(default=list("/usr/share/cryptobox-server/plugins"))
 EventDir = string(default="/etc/cryptobox-server/events.d")

Debugging question

I was wondering if there's an easy way to get the python console to be 
connected to the CryptoNAS webserver task so I can print out variables' 
contents and try out syntax snippets without restarting the server.

Failing that, what's the best way to print out debugging information to 
the console or to the log? Is there a particular function you guys use 
for printf()-style debug statements?

--

-- 
Sincerely,
James Crofts
jcrofts@...

Re: Epydoc documentation for browsing online

Lars wrote:
>> *My development virtual machine on my laptop is already set up for generating
>> docs, building images, etc.
>>     
>
> this is great. I just thought, you meant the unittests, when you mentioned
> twill.
> Anyway: I guess, we need a stable platform for unittests to finally progress in
> solving the remaining test failures. If your setup does this, then it is great.
> But a local ressource is hard to share. Maybe we can move it to our server, to
> make mutual testing/fixing easier?
>   
I mentioned Twill only because I happened to remember it's one of the 
Python modules epydoc complains about not being able to find.
I don't have an automated unit testing script at present. Recall that my 
unit test setup didn't use UML. Did you compare the unit test log I sent 
out with the one you did? If they're fairly similar, it might be 
reasonable to do unit tests the way you know how more often and in the 
Live CD environment less often. The Live CD testing could be automated 
but would probably be a bit more work. I explained my unit testing 
approach when we had the live chat session a while back.

--

-- 
Sincerely,
James Crofts
jcrofts@...

Epydoc documentation for browsing online

I've created epydoc documentation for the project using Epydoc 3.0.1 and 
a script to generate this documentation automatically. (I find Epydoc 
with "--show-sourcecode" increases my efficiency dramatically.) I'd like 
to post this where other developers can find it, either on the project 
website or my own. The CryptoNAS project site is in SVN, but the Epydoc 
output doesn't really need to be in SVN since it can be auto-generated.

Where is the best place for me to upload
1) the folder with epydoc's html output, for browsing online
2) a .tgz archive of the html for downloading and viewing offline?

If I use my website for this, a *.cryptonas.org DNS entry might make sense.

By the way, the Alioth application was denied.

--

-- 
Sincerely,
James Crofts
jcrofts@...

Running epydoc on CryptoNAS code

How are you guys running epydoc on the CryptoNAS code? It looks like 
CryptoNAS might have to be installed (not just present in a sandbox) on 
the same system as epydoc for everything (class inheritance and so on) 
to be captured properly.

--

-- 
Sincerely,
James Crofts
jcrofts@...

Trouble with Alioth registration

When trying to register for Debian Alioth, I keep getting the following 
(automated) error message:

      "Please describe your Registration Purpose in a more comprehensive
      manner"

I've already increased the "purpose and summarization" description to 
more than 5700 characters. Will you please send me the previous Alioth 
application so I can gauge the length/subject matter they are looking for?

--

-- 
Sincerely,
James Crofts
jcrofts@...

Reminder: Unit test setup help?

I have a lot of travel for work coming up very soon. I can get a lot of 
work done on the plane, *if* I can get the unit test framework working 
on my computer by then. I've installed:
Debian Etch
cryptsetup
clearsilver
testoob
Twill

on my development virtual machine, but I'm still getting a bunch of 
Python exceptions that don't really look like Testoob output (i.e. 
Testoob isn't running properly for any of the tests).
Some of the error messages complain about /dev/loop, but /dev/loop1 is 
what we should be interested in, right?

I've done the "/sbin/losetup /dev/loop1 test.img" setup and I'm running 
the unit test script as "bin/do_unittests.sh" as root from the svn 
"trunk" directory. What am I doing wrong?

--

-- 
Sincerely,
James Crofts
jcrofts@...