Piotras' blog: Archive

Building Midgard 1.9 for maemo

Posted on 2007-10-03 10:27:25 UTC.

I should say trying to build instead of building it for maemo. Though libmidgard10 and libapache2-mod-midgard are already installed on my N800. Again, list of dependencies is the key for success.

I changed debian files ( rules and control ), so rules file generates control file correctly when package is built. For example when I build package for maemo a section is replaced with user/libs' and architecture type witharmelinstead ofi386` which is generated when I build package for x86 architecture

Big issue with packages builds is naming convetion, so it's impossible to create correct debian files ( mostly Depends: section ) for every architecture. Your package might depends on apache2-mpm-prefork, while someone called it just httpd for maemo. This package also includes header files, so you do not have to install apache2-prefork-dev, and also apr binaries, but weird thing is that it doesn't include apr header files.

Workaround for this is ( easiest I found ):

cp -r /usr/include/apr-1.0 /scratchbox/users/pp/targets/SDK_ARMEL/usr/include/

As maemo packages are built as debian packages, one could also keep any naming convention so apxs2 could stay apxs2 and apr includes could be defined for apr-1.0, and not for apr-1.

MySQL used everywhere on debian distros with version 5.0 is build with version 4.1 for maemo.

Those are issues, one might and can to resolve quite quickly. But the real problem I found with php5-fastcgi package. To build php extension I need header files ( those I can just copy ) and phpize tool. Lack of latter is an issue :)

I need to investigate it more. And for those interested I used these packages:

• https://garage.maemo.org/projects/mysqldatabase/
• https://garage.maemo.org/projects/apache/

And debian repository:

deb http://maemo-hackers.org/apt bora main

BTW, if you need to install php5-fastcgi in your scratchbox, you might to want to change default httpd port. I changed mine from 80 to 8080. Without it I got `Permission denied' when being logged in as fakeroot and "wanted to bind" to port 80.

"Maemo Application Manager" I do not like you

Posted on 2007-10-03 11:00:28 UTC.

Why?

If package's control files has:

Section: libs

is easy installable via repository, while it's incompatible while installed via file file manager with double click. In such case, package has to have:

Section: user/libs

Does it mean that when I double "click" (doubleknock) on package file I invoke different Application Manager?

midgard-php on maemo

Posted on 2007-10-03 21:26:29 UTC.

It's just today when I thought that phpize is a big issue when I tried to install php5-midgard and midgard-data package on N800. I thought that simplest solution could be the best and just copied all required files ( like phpize, php-config, and few others ) directly to my armel target host.

And now it looks like it's not best solution because php-config should clearly points to extension_dir for example and this is quite weird ( in debian sense ) in php5-fastcgi package. At least this package could provide php-config to save plenty of other's time.

Anyway, at last I finally installed all midgard packages.

Even tried datagard, but this one fails because of lack of pear:

And I wrote simple php script which loads midgard extension via dl and prints midgard version:

Midgard Query Builder - fresh breath

Posted on 2007-10-12 11:00:18 UTC.

Last few days I spent on redesigning and starting to refactor Midgard Query Builder. Already made work is initial but very promising. Mostly, I wanted to fix all remaining issues from 1.9 branch, but code itself clearly told me that fix is impossible, and refactoring is quite excellent idea.

I had to port plenty of code from trunk ( aka Midgard2 ), but for example 1-9 branch got midgard_metadata support in midgard_reflection property "free of charge".

So first of all there's quite interesting new method for midgard_query_builder: add_constraint_with_property. Unlike add_constraint method it accepts only properties as third parameter ( instead of values ), so comparison may be done on database provider level without any need to know what value is hold by particular constraint.

add_constraint_with_property("metadata_publised", "<", "metadata_revised");

or more complex one:

add_constraint_with_property("topic.metadata.published", ">", "creator.metadata.created");

And second cool feature is that constraints added to Query Builder soon will be "moveable", which means that any constraint added to Query Builder can be removed before or after execution and builder itself will be able to perform different executions depending on collected constraints. New constraints also holds "join" like information so once constraint is added it forces internal join constraints and remove them once, it's removed itself.

Such code:

$qb = new midgard_query_builder("midgard_article");
$qb->add_constraint_with_property("topic.metadata.published", ">", "creator.metadata.created");
$qb->add_constraint_with_property("topic.metadata.revised", ">", "up.contentcreated");
$qb->add_constraint("name", "<>", "");
$qb->execute();

generates this SQL:

FROM article, topic, person, article_i WHERE article.name <> '' AND
topic.metadata_published > person.metadata_created AND article.topic = 
topic.id AND article.creator = person.id AND topic.metadata_revised > 
article_i.created AND article.topic = topic.id AND article.up = article.id
AND article.id=article_i.sid

Midgard and Ubuntu and segfaults

Posted on 2007-10-25 19:43:53 UTC.

Few days ago, Andreas reported segfaults on Ubuntu. Today I built ubuntu getsy packages for latest Midgard and was surprised when I saw "Segmentation Fault" in apache's error log file. Just after I made first request.

Hold on, this is Midgard 1.8 stable release. I know how it's designed and written and in most cases it's the last part of software I could blame for acting up on my ( on any ) server. A bit shameless, but true.

Gdb and newly written test script clearly pointed to dba_open which I started to blame a bit earlier, and just few minutes ago I found this bug report.

I must check if db4 upgrade can help.

Updated (2007-10-26): There are two ways to fix an issue. One is to update MidCOM from trunk, as this version doesn't use php dba functionality. Seems to be easiest but not recommended for production server , especially when you are not midcom developer.

Another solution is to rebuild php packages with flatfile dba support. To make this just download php5 source packages:

apt-get source php5
cd php5-5.2.3

Add --with-flatfile ( debian/rules ) to COMMON_CONFIG.

dpkg-buildpackage -b

Then, install php5-cli and libapache2-mod-php5. Update midcom code ( in file: /usr/share/php/midcom/lib/midcom/services/cache/backend/dba.php ) :

if (in_array('db4', $handlers))
{
    $this->_handler = 'flatfile';
}

I know it's not best solution but the quickest I found as temporary solution before ubuntu maintainers will update php and dba packages.