This afternoon, Caramelle died from a fulgurant flue after 2 years of happy pouic pouics.
I was going to the vet when she died, and it must have been terrible for her.
And that, one hour after the starting of the symptoms.
R.I.P. Caramelle.
]]>
Now the recipe can display some information about which wanted this distribution.
This is even more useful that it support up to 6 dependencies levels from direct to parents !
Here is an example:
Processing ssl-for-setuptools-1.10.tar.gz
Unpacking ssl-for-setuptools-1.10 to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10
Unpacking ssl-for-setuptools-1.10/PKG-INFO to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/PKG-INFO
Unpacking ssl-for-setuptools-1.10/setup.py to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/setup.py
Unpacking ssl-for-setuptools-1.10/ssl to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl
Unpacking ssl-for-setuptools-1.10/ssl/2.3.6 to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.3.6
Unpacking ssl-for-setuptools-1.10/ssl/2.3.6/socketmodule.h to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.3.6/socketmodule.h
Unpacking ssl-for-setuptools-1.10/ssl/2.5.1 to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.5.1
Unpacking ssl-for-setuptools-1.10/ssl/2.5.1/socketmodule.h to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.5.1/socketmodule.h
Unpacking ssl-for-setuptools-1.10/ssl/__init__.py to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/__init__.py
Unpacking ssl-for-setuptools-1.10/ssl/_ssl2.c to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/_ssl2.c
Unpacking ssl-for-setuptools-1.10/test to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test
Unpacking ssl-for-setuptools-1.10/test/badcert.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/badcert.pem
Unpacking ssl-for-setuptools-1.10/test/badkey.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/badkey.pem
Unpacking ssl-for-setuptools-1.10/test/https_svn_python_org_root.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/https_svn_python_org_root.pem
Unpacking ssl-for-setuptools-1.10/test/keycert.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/keycert.pem
Unpacking ssl-for-setuptools-1.10/test/nullcert.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/nullcert.pem
Unpacking ssl-for-setuptools-1.10/test/test_ssl.py to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/test_ssl.py
Running ssl-for-setuptools-1.10/setup.py bdist_egg --dist-dir /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/egg-dist-tmp-NfSQin
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 1714, in main
with_ei_usage(lambda:
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 1695, in with_ei_usage
return f()
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 1718, in <lambda>
distclass=DistributionWithoutHelpCommands, **kw
File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 236, in run
self.easy_install(spec, not self.no_deps)
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 452, in easy_install
return self.install_item(None, spec, tmpdir, deps, True)
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 501, in install_item
dists = self.install_eggs(spec, download, tmpdir)
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 680, in install_eggs
return self.build_and_install(setup_script, setup_base)
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 957, in build_and_install
self.run_setup(setup_script, setup_base, args)
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 946, in run_setup
run_setup(setup_script, args)
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/sandbox.py", line 29, in run_setup
lambda: execfile(
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/sandbox.py", line 70, in run
return func()
File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/sandbox.py", line 31, in <lambda>
{'__file__':setup_script, '__name__':'__main__'}
File "setup.py", line 11, in <module>
def read(rnames):
ValueError: This extension should not be used with Python 2.6 or later (already built in), and has not been tested with Python 2.3.4 or earlier.
- Failed specs: ssl-for-setuptools==1.10
- required by:
- [Requirement.parse('zc.ssl==1.1')]
- required by:
- [Requirement.parse('zc.authorizedotnet==1.3')]
- required by:
- [Requirement.parse('easyshop.core==0.1a1')]
- Failed specs: ssl-for-setuptools==1.10
- required by:
- [Requirement.parse('zc.ssl==1.1')]
- required by:
- [Requirement.parse('zc.authorizedotnet==1.3')]
- required by:
- [Requirement.parse('easyshop.core==0.1a1')]
While:
Installing zopepy.
We see at first shot that easyshop give us trouble ! Without, its hard to know which distribution want ssl-for-setuptools :)
]]>What an heck while dealing with the 'minitage env' file which mix the system and project environment resulting in a mixin of the system and project python.
Normally, there are no problem, unless your pythons come with different UCS flavors.
Cool thing is that those errors are not silent, and you see them if you are hitted by this flaw :
ImportError: /bar.egg/module/_foo.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8 or ImportError: /bar.egg/module/_foo.so: undefined symbol: PyUnicodeUCS2_DecodeUTF8
Making some searches showed me that upstream as in python-dev supports only UCS2 by default (issue discussed on their mailing around 2008) but all distros i am aware of package their distros with UCS==4.
For now, I prefered to stick with upstream (UCS==2), but i think that for the user experience, UCS==4 will be better.
Sad thing is that for existing minitage installations if you want to rebuild your python, do also that:
rm -rf minitage/eggs/cache/*-Major.minor*egg rm -rf minitage/eggs/*/.installed.cfg
To let minitage rebuild any stuff using UCS2.
See http://en.wikipedia.org/wiki/Universal_Character_Set for reference on UCS.
]]>For this, i wanted to add all repositories, what a heck for 200 repos...
Time to create minitage.ohloh to create the repositories for me using some fake browser ;-).
This package uses lxml (XPath), zope.testbrowser (fake browser) and urllib (some handmade http requests) to make the work done.
The result is there : https://www.ohloh.net/p/minitage/enlistmentswith more than 100 repos created :D !
And sorry ohloh Team for flooding ohloh.net :p
.
]]>>>> from datetime import date
>>> date(1800,1,1).strftime('%d%m%Y')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: year=1800 is before 1900; the datetime strftime() methods require year >= 1900
Quite annoying heh ?
There is a bug related on the python bugtracker here : http://bugs.python.org/issue1777412
The work here was to integrate the working patch in the bugreport to py24 and py26 python packages which are in minitage.
So now, with minitage's pythons, you can work with very old dates by default !!!
Just issue:
virtualenv --no-site-packages --distribute minitage source minitage/bin/activate minimerge -s minimerge -v python-2.6 (or 2.4)
And you can use the following interpreter which support those old ages:
minitage/python-2.6/parts/part/bin/python
And of course the related patch does not break anything:
$ svn info URL : http://svn.python.org/projects/python/branches/release24-maint Révision : 75208 $../parts/part/bin/python Lib/test/test_datetime.py ... ---------------------------------------------------------------------- Ran 230 tests in 0.858s OK $ pwd /home/kiorky/minitage/dependencies/python-2.6/Python-2.6.4 $../parts/part/bin/python Lib/test/test_datetime.py ... ---------------------------------------------------------------------- Ran 245 tests in 0.791s OK
]]>
You can know select to build all dependencies but not the package.
For exemple, to build all python-2.4 dependencies but not python-2.4 itself, you can do:
minimerge -v --only-dependencies python-2.4
For 'eggs' packages, the default was to make come in dependencies all python avaiable in minitage and to build the 'site-packages-Major.Minor' part if it was a buildout build..
It is know rearranged to be a little more subtile.
Look the following:
minimerge -v mypythonpackage # will be mypythonpackage against all python as usual minimerge -v mypythonpackage python-2.4# will be mypythonpackage against only python-2.4
]]>
As a note, you must have all SDK installed, specially the 10.4!
]]>
You have :
Enjoy running:
easy_install -U minitage.paste paster create -t minitage.instances.nginx myproject #deploy some nginx instance (init scripts, logrotates, docroot) paster create -t minitage.instances.apacher myproject #deploy some nginx instance (init scripts, logrotates, docroot)]]>
For example, to initiate a great hudson (contineous integration), you can run the following:
If you are not inside a minitage environment:
easy_install -U minitage.paste.extras paster create -t minitage.instances.tomcat myproject # it will ask you for the location of a tomcat extracted tarball paster create -t minitage.instances.hudson myproject
And if you are not inside a minitage environment, to deploy in a myproject subdirectory
easy_install -U minitage.paste.extras paster create -t minitage.instances.tomcat myproject inside_minitage=no paster create -t minitage.instances.hudson myproject inside_minitage=no
Requirements:
As i want minitage.paste to depend on barely nothing else that paster and the minitage core, i have splitted such 'instances' in an additionnal egg.
minitage.paste.extras was born.
This package borrow 2 instances at the moment:
Those instances make some nice things as generating on the flag SSL certificates for enabling secured connections to your instance(s).
]]>
Profils have been renamed to instances as it is more relevant.
for example:paster create -t minitage.profils.env project
become:
paster create -t minitage.instances.env project]]>
The tested platform is a FreeBSD-7.1 RELEASE 64 bits.
]]>
Now, there are some new profils out there:
There also some changes on the postgresql profile.
Now:
]]>
More as an habit than a conviction, my source files where header pollutated by the GPL License.
For me, and in my opinion, the GPL is not as free as it claims to.
Why ? Because the final user cannot do what he want with your code.
Some debate will qualify that as communism (GPL) vs anarchy (BSD). I prefer anarchy :).
Of course i use the "modified BSD license" which is compatible with the GPL.
Some on the concerned:
Python-MapScript are the python bindings to the underlying mapserver library.
Where the pain begins is that there is no egg available for it, but an old fashioned distutils distribution;.
My bits there were to make some quickly egg compatible on most unixes. My will is to make it nicer and be integrated on the mapserver trunk code.
You can find the code there : http://git.minitage.org/git/others/mapscript/
And play with the egg:
easy_install mapscript
You must know that mapserver-config must be available in your $PATH.
]]>
Naturally, the idea to set up some tinderbox like buidbot comes to my mind.
More over, i had a though of generating some binaries to avoid the compilation time for users who don't want to/can't compile.
The lead was to use collective.buildbot, a great recipe to integrate buildbot with zc.buildout deployment.
The result is there : http://git.minitage.org/git/minitage/buildbot/
The idea was to generate a "collective.buildbot" project per dependency. To achieve that, i made a script to generate those projects from the current official minilays.
Compilation is triggered via manual activation (irc, web) but also by a cron scheduler (nearly each 3 hours)
I made a patch to the recipe to have multiple hours values (* 1,2,3 * * *) cron entries, see http://git.minitage.org/git/minitage/buildbot/tree/collective.buildbot.multiple.patch
The buildbot can be viewed there : http://www.minitage.org/buildbot/waterfall
Next steps are to finnish the "binaries dealing" in minitage.core and the mirrors setup, and minitage users will be able to use binaries and no compilation anymore :)
]]>I was surprised to not see a lot of breakages. Most of the packages build fine right now.
I was just anooyed with 'MACOSX_DEPLOYMENT_TARGET' bugs i introduced with previous minitage versions, where i didnt know already all the impact of using it.
So, now, is minitage ready for mac ?
I think, Yes as almost everything inside minitage can install without problems. But ..., it needs to be tested a lot more :)
And think, that you must run OSX Leopard. Prior versions of MacOSX wont be supported. Indeed, i need some linker features which need a lot of rewrites of minitage composants to be compliant with the old mac linker. (-Wl,-rpath -Wl,... -> -rpath something). Whereas, now, a lot can be fixed in one place, the project has history and there is a lot of places to fix and test to rewrite this "flag issue". But if you want, port it ;)
One recommandation if you use minitage on OSX is to use the boostrapper to get the base python compiled with the right options.
If you get some obscure errors like:
distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure
use the bootstrapper ;)
You ll need also xcode and some tools installed, see on the minitage installation documentation : http://minitage.org/installation.html
]]>
The guest OS is a debian etch 64.
There were some trivial fixes, mainly the whole packages compiled without any problems.
]]>
Thx gentoo and thx gentoo developpers :-)
]]>
It's definitivly seems to run fine with python >= 2.5.
Points of the merge were large:
But, something i hadn't tested, ..., was the python 2.4 support. Both zc.testbrowser and mozrunner have problems with it...
I will try to make the next commits fix that if possible.
As it's not yet officially released., you can try the code there:
svn://svn.zope.org/repos/main/zc.testbrowser/branches/fastreal_screenshots_mozrunner_proxys
]]>
The goals were to integrate its way to work, with setting some DJANGO_SETTINGS_MODULE key in the environment and launch the "bidule", and letz play.
The challenge was, ..., to be simple or this workmate will never use this stuff. She was used to tell only about django-admin runserver :).
One part of the challenge was to show some interessant things that we can do with paste configurations, like having different but closer configurations for production or development mode.
Thus, including showing the nice "WebError#eval" application where you can debug your messy code though the web with an interactive debugger.
But, right to the topic, the dj.paste stuff:
]]>
- It enables you to have multiple tracs in the same pipeline
- You can integrate it in an exiting paste configuration, it's the goal after all :)
- It 's simple to use, an a sample paste configuration can be:
[composite:main]
use = egg:Paste#urlmap
/ = foo
[app:foo]
use=egg:dj.paste
django_settings_module=foo.settings
Minitage 1.0 is out for a week now.
All are paster (see PasteScripts on pypi) templates.
Projects target to quickstart an application or a project like a plone3 or a django website.
Profiles, on the other side, are a piece of integration, targeted to be in general integrated into a minitage based project. That can be a postgresql database instance, or a shell environement file with has all minitage dependencies, that you can source when playing with your project.
]]>After successfully upgrading the system to Freebsd 7.1 this week end, at 3.30AM, i can't boot :(
The driver want to go UDMA, the disk doesn't understand.
No mean in the bios to force that... And no more internet because this box is the home router !
What to do ?
Go to use my 3G phone to get my ISP DNS because ... the funny "freebox" is customizable throught the web, on the free.fr website.
You have no local access on it.
So now, i have some route and DNS setted up, i can go to read
man loader(8) man ata(4)
And now, i know some interresting new things:
Disable dma:
set hw.ata.ata_dma=0
Prompt for root partition when the partition location changed:
set boot_askname]]>
Its done, now instead of calling minimerge, you can use either:
]]>
- minimerge
- yasty
- apty
- pacmerge
The failure here is that my git fetcher is not very sympathic with older versions of git (<1.5).
But on debian and red hat legacy, it's a pain in the ass to have relativly new stuff !!!
To resolve that, with workmates, we come to the decision to fetch packages over http.
And now, it's done. Minimerge codebase is 'HttpCompliant' in sense that defaults minilays and packages are fetched via the minitage static fetcher.
This one just use urllib, and you can even set proxies in your minimerge.cfg
To be up-to-date:
easy_install -U minitage.core mv etc/minimerge.cfg etc/minimerge.cfg.old cd minilays mkdir ../old mv meta misc eggs dependencies ../old minimerge -s
]]>
This afternoon, Caramelle died from a fulgurant flue after 2 years of happy pouic pouics.
I was going to the vet when she died, and it must have been terrible for her.
And that, one hour after the starting of the symptoms.
R.I.P. Caramelle.
]]>
"/usr/bin/ld: cannot find -l_renderPM_libart"
Here is a sample buildout using either minitage.recipe:egg or zc.recipe.egg to
install it:
[buildout]
versions=versions
parts=
eggs
zceggs
[versions]
reportlab=2.3
[eggs]
recipe=minitage.recipe:egg
eggs=
reportlab
find-links=
http://distfiles.minitage.org/public/externals/minitage/
[zceggs]
recipe=zc.recipe.egg
eggs=
reportlab
find-links=
http://distfiles.minitage.org/public/externals/minitage/
[1] http://distfiles.minitage.org/public/externals/minitage/reportlab-2.3.tar.gz
]]>
Here is a little list of what minitage can offer to you:
And next to come:
I worked on collective.anonymousbrowser to allow the use of proxys and proxy balancing over zc.testbrowser proxys.
Another interressant feature fir the project was also to retry urls if there were errors.
I made also some bugfix and improvments on the zc.testbrowser.real.Browser side like using mozrunner to control firefox, loading directly the js file if we are local..
What i want to do now is to port all the interresting things back to zc.testbrowser.
Hope i will have time for that this week.
]]>/me just got another subtitle via the opensubtitles.org smplayer's menu entry.
I really need this feature as i am not already fluent in japanese :(
]]>So feel free to install and test the brand new zope3 template.
In an activated minitage instance:
easy_install minitage.paste paster create -t minitage.zope3 z3 minimerge z3 cd zope/z3 bin/z3-ctl fg
Plone32 was written before the recipes rewrite, it should work but i must revisite it. Should be alvalaible tomorow!
If you didnt know minitage.paste, you can also check the other templates and projects
paster create --list-templates|grep minitage
And visit the pypi and minitage.org page :)
]]>Now, those recipes share the same API and you an use them "really" as the original zc.recipes..
Another iinterresting point is that i never liked the way to compute dependencies.
Another point was to allow easy_install to get automaticly our stuff out.
To correct all that weird, i have rewritten the dependencies calculation not to let easy_install
do anything but install one thing at a time, and with versions and extras checks.
A part of the improvments:
]]>
- versions are really fixed, imperative way.
- dependencies are better handled
- egg's extras requirements (like something.foo [test, zcml]) are really well installed with all their dependencies
- develop eggs get also their dependencies
This is a little extension for buildout that enables you to override/monkey patch some buildout stuff to use minitage internals instead.
If you like minitage, if you like the minitage recipes, you ll enjoy it!
See http://pypi.python.org/pypi/buildout.minitagificator for more information :)
]]>
Those are the features i ll release on the next days:
TODO as an though for contributors:
]]>
We are using Pylons for the framework part, and i played this afternoon at setting up some testing environnement for doing doctests.
This test is a proof of concept, it 's code extracted from our internal application, it's just a starter for you. The whole is working with some tweaks.
controllers/mycontroller.py, a simple controller doing simple stuff
class MyController(XMLRPCController):
"""controller."""
def index(self):
return '\_o<'
lib/base.py, Please add the XMLRPCController import
lib/base.py:from pylons.controllers import WSGIController, XMLRPCController
Then, we are setted up to continue with tests
First of all, the doctest boilerplate:
tests/test_doctest_files.py
import doctest
from doctest import DocFileSuite
from myproject.tests import setUp, tearDown
flags = (doctest.ELLIPSIS | doctest.NORMALIZE_WHITESPACE | doctest.REPORT_ONLY_FIRST_FAILURE)
def test_suite():
return DocFileSuite(
"test.txt",
setUp = setUp,
tearDown = tearDown,
optionflags = flags
)
setUp and tearDown will have a central place as they are intialising the application.
As we can't use paste.fixture.TestApp objects with XMLRPC because it does not bind everywhere, the idea is
import os
import sys
import re
import threading
from ConfigParser import ConfigParser
from unittest import TestCase
import paste.fixture
import paste.script.appinstall
from paste.deploy import loadapp
from paste.httpserver import serve
from routes.util import url_for
here_dir = os.path.dirname(os.path.abspath(__file__))
conf_dir = os.path.dirname(os.path.dirname(here_dir))
test_file = os.path.join(here_dir, 'test.ini')
cmd = paste.script.appinstall.SetupCommand('setup-app')
cmd.run([test_file])
def setUp(test, *args, **kwargs):
print "\t-----------------------------------------------------------------"
print "\t--- Setting up database test environment, please stand by. ---"
print "\t-----------------------------------------------------------------"
config = ConfigParser()
config.read(
os.path.join(os.path.dirname(sys.argv[0]), '..', 'etc', 'config.ini')
)
infos = ConfigParser()
infos.read(test_file)
sinfos = infos._sections['server:main']
wsgiapp = loadapp('config:test.ini', relative_to = here_dir)
server = test.globs['server'] = serve(wsgiapp,
t = threading.Thread(target=server.serve_forever)
t.setDaemon(True)
t.start()
test.globs['app'] = paste.fixture.TestApp(wsgiapp)
def url_for_wrapper(*args, **kwargs):
lkwargs = {'protocol': 'http' ,'host': "%s:%s" % (server.server_name, server.server_port)}
lkwargs.update(kwargs)
return url_for(*args, **lkwargs)
test.globs['url_for'] = url_for_wrapper
test.globs['url_for_orig'] = url_for
def tearDown(test):
test.globs['server'].server_close()
class TestController(TestCase):
def __init__(self, *args, **kwargs):
wsgiapp = loadapp('config:test.ini', relative_to = here_dir)
self.app = paste.fixture.TestApp(wsgiapp)
TestCase.__init__(self, *args, **kwargs)
And finally, letz play with our doctest
tests/text.txt
>>> create_url = url_for(controller='mycontroller') >>> import xmlrpclib >>> s = xmlrpclib.Server(create_url) >>> s.index() '\\_o<']]>
It permits you to generate with some code logics a full set of files.
You can for example create a buildout, apache configurations files and etc.
The documentation for profils are in the official minitage documentation : http://www.minitage.org/doc/rst/
What is interesting there is that i use it into minitage to generate stuff inside.
There are 2 main sort of templates:
To get those templates in a minitage instance:
source minitage/bin/activate easy_install -U minitage.paste paster create --list-templates
After you can for example create a plone31 projet:
paster create -t minitage.plone31zeo myproject
And after that, because plone is slow, put inside a varnish instance
paster create -t minitage.profils.varnish myproject
Because you need svn 1.5 but it is not packaged on your debian potatoe, just reference it in the dependencies part of your project minibuild:
dependencies=...pilwotk-1.1.6.4 ... install_method=buildout src_uri=http://hg.foo.net/myproject src_type=hg category=zope homepage=http://foo.net description= a plone 3.1 buildout for myproject
And install the minitage.env template:
paster create -t minitage.profils.env myproject
This profil will create for you a small bash script that will change your environnemnent according to 'myproject' needs. PATH, LD_LIBRARY_PATH and so will be feeded with all minitage dependencies. That will enable you to use svn-1.5 when you source it (like source bin/activate)
source zope/myproject/sys/share/minitage/minitage.env which svn /minitage/dependencies/subversion-1.5/parts/part/bin/svn
Another interresting integrations are the zope3 and tubogears projects.
You can see the full documentation there : http://www.minitage.org/doc/rst/tg_project.html
]]>
So, something nice is that i have dropped away the ugly patch.
see : http://bzr.cryptelium.net in action.
What's next?
Michael Hudson, the main developper, told me that the idea is to drop away the loggerhead.conf and to use serve-branches as the main thing to use.
That's a good idea. Usage is simple, nothing to worry about configuration, it just does publishing after all.
Little bits i can see as improvments (always reported/planned):
]]>
The goal of the week end was to set up some repositories and a source browser on top of them.
In bazaar world, there is not much choice to achieve that. In other terms, you re really encouraged to use loggerhead.
So, i began to set up a repository, file access and so on... Then look at the loggerhead documentation. Great, there is some sort of auto publishing feature.
This is a mechanism like our beloved mercurial's hgwebdir.cgi to autopublish branches inside a top level directory.
So, the procedure i used was really simple:
Grab it
bzr branch http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/ loggerhead.dev
Edit and point to my top level directory
cp loggerhead.conf* loggerhead.conf vi loggerhead.conf
Set up a gentoo init script to start it and schedule for starting after apache2
$ cat /etc/init.d/loggerhead
#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
depend() {
need net apache2
}
start() {
ebegin "Starting $server_name server"
start-stop-daemon --start --user $user --quiet --background \
-p $pid_file -m --exec "$py" -- "$start_cmd"
eend $?
}
stop() {
ebegin "Stopping $server_name server"
"$py" -- "$stop_cmd" 2>&1 >> /dev/null
eend $?
}
$ cat /etc/conf.d/loggerhead
start_cmd=/path/loggerhead.dev/start-loggerhead
stop_cmd=/path/loggerhead.dev/stop-loggerhead
pid_file="/path/loggerhead.dev/loggerhead.pid"
user="apache"
py=`which python`
server_name="Loggerhead"
Configure apache for serving both bazaar and loggerhead on the same vhost
...
Vhost basic and directories directives
...
# setting an alias to point to the bazaar directory
Alias /repos/ /path/repos/
RewriteEngine on
# mapping to /repos if we are not browsing on loggerhead or if we are directly "branching"
RewriteCond %{REQUEST_URI} !^(/repos/.*)$
RewriteCond %{REQUEST_URI} ^(.*\.bzr.*)$
RewriteRule ^/(.*)$ /repos/$1 [R,L]
# mapping to loggerhead otherwise
RewriteCond %{REQUEST_URI} !^(.*\.bzr.*)$
RewriteCond %{REQUEST_URI} !^(/repos/.*)$
RewriteCond %{REQUEST_URI} !^(/icons/.*)$
RewriteRule ^/(.*) http://bzr.cryptelium.net:1337/$1 [P]
RewriteCond %{REQUEST_URI} !^(.*\.bzr.*)$
RewriteCond %{REQUEST_URI} !^(/repos/.*)$
RewriteCond %{REQUEST_URI} !^(/icons/.*)$
RewriteRule ^/(.*)/$ http://bzr.cryptelium.net:1337/$1 [P]
# The two [P] RewriteRules are just ProxyPass rules which allow to redirect to the loggerhead server.
Unfortunatly not.
Loggerhead is stupid and will not publish two branches with same name.
Another thing is that it will take the branch name for display in UI.
I REALLLY do not like that. I prefer to see full pathes in the UI. That helps my little brain with tree view focus to function properly.
This cannot be served (just b/c will be):
a/c b/c
b/c/d
Results in
d
For my own use, i make my own fix :)
But i upstreamed the result there:https://bugs.launchpad.net/loggerhead/+bug/254411
This allows me to publish my repositories with path views :)
]]>
IT s done now, my blog is open :)
Stay tuned for new entries.
What will may be next: