Open Source Developer

CMake-Modularised Boost fails to compile with g++ 4.6 (internal compiler error with intrusive_ptr)

2012-01-07T21:38:00.000+01:00

When building the CMake-modularised Boost on Fedora 16, g++ 4.6 crashes with the following error:


[97%] Building CXX object tools/quickbook/CMakeFiles/quickbook.dir/src/id_manager.cpp.o
In file included from <>/modules/libs/smart_ptr/include/boost/intrusive_ptr.hpp:16:0,
from <>/modules/tools/quickbook/src/fwd.hpp:15,
from <>/modules/tools/quickbook/src/values.hpp:20,
from <>/modules/tools/quickbook/src/id_manager.hpp:14,
from <>/modules/tools/quickbook/src/id_manager.cpp:9:
<>/modules/libs/smart_ptr/include/boost/smart_ptr/intrusive_ptr.hpp: In destructor ‘boost::intrusive_ptr::~intrusive_ptr() [with T = quickbook::file_info]’:
<>/modules/libs/smart_ptr/include/boost/smart_ptr/intrusive_ptr.hpp:94:5: internal compiler error: Segmentation fault

That error apparently comes from a regression in g++ 4.6.

VirtualBox failing to start on Fedora 16

2011-12-03T11:27:00.001+01:00

On Fedora 16, the user account IDs are now starting from 1000, instead of 500 as before.
Hence, when upgrading a Fedora distribution hosting a VirtualBox framework, the access rights should be updated for a few VirtualBox-related directories.
Otherwise, the following symptom may appear:

Failed to create the VirtualBox COM object.
The application will now terminate.
Callee RC: 
NS_ERROR_FACTORY_NOT_REGISTERED (0x80040154)

Let us assume that the user account is named 'build'. The following commands should therefore do the job:

chown -R build.build /home/build
chown -R build.build /tmp/.vbox-build-ipc

Permission denied when pushing to a SourceForge Git repository

2011-09-29T15:52:00.001+02:00

Sometimes, pushing to a SourceForge-hosted Git repository triggers a "permission denied" error.
For instance:

$ git init
$ touch README
$ git add README
$ git commit -m "First commit"
$ git remote add origin ssh://myuser@myproject.git.sourceforge.net/gitroot/myproject/myproject
$ git fetch origin
$ git push --verbose origin master
Pushing to ssh://myuser@myproject.git.sourceforge.net/gitroot/myproject/myproject
Counting objects: 3, done.
Writing objects: 100% (3/3), 215 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
error: insufficient permission for adding an object to repository database ./objects

fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://myuser@myproject.git.sourceforge.net/gitroot/myproject/myproject

    ! [remote rejected] master -> master (n/a (unpacker error))

error: failed to push some refs to 'ssh://myuser@myproject.git.sourceforge.net/gitroot/myproject/myproject'

If you are a developer for multiple SourceForge-hosted projects, it may come from a Linux limitation, as stated in the SourceForge Git help page:

For those developers who have git access enabled to more than 16 projects, you may need to include your PROJECTNAME as a part of the USERNAME (appended after a comma) in order to work around a Linux permission limitation:
ssh://USERNAME,PROJECTNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME (read/write)

So, when adding the Git remote repository, or when cloning it, and when you use the SSH protocol, you have to alter the URL. For instance:
$ git remote add origin ssh://myuser,myproject@myproject.git.sourceforge.net/gitroot/myproject/myproject

Note that there may be other causes (e.g., proper Unix rights on the SourceForge-hosted file-system), as seen in the following SourceForge tickets: #17295 and #4956.

file not recognized: File truncated

2011-08-22T14:15:00.000+02:00

The following error:

Linking CXX shared library libmylib.so

CMakeFiles/mylib.dir/MyCppClass.cpp.o: file not recognized: File truncated

collect2: ld returned 1 exit status

when the compilation line looks like:

c++ -Dmylib_EXPORTS -Wall -Werror -g -fPIC -I/home/user/dev/mygit/build -I/home/user/dev/mygit/src -o CMakeFiles/mylib.dir/MyCppClass.cpp.o -c /home/user/dev/mygit/src/MyCppClass.cpp

comes from the fact that, as stated, the generated object (.o) file is empty (or just truncated). A quick look can also tell it:

ls -l CMakeFiles/mylib.dir/

Now, when the issue remains even though you re-run the compilation line, it may come from the fact that the object (.o) file is empty/truncated within the compilation cache (ccache) itself. It may happen, for instance, when the machine/server is (abruptly) re-booted while a compilation is running.
Indeed, it is highly probable that your c++ command wraps the use of a compilation cache:

$ type c++

c++ is hashed (/usr/lib/ccache/c++)

If that is case, you can get rid of the compilation cache:

rm -rf ~/.ccache

You still have to delete the truncated files from the current generated directory:

rm -rf CMakeFiles/mylib.dir/

and to re-run your compilation line (e.g., 'make').

Display a Makefile variable

2011-08-16T18:53:00.000+02:00

It is often convenient to display a variable set within a Makefile.
A common way is to add a target echo-ing that variable, but it requires altering the Makefile.

Another elegant, non intrusive way, is to use the possibility of passing several Makefiles to the make command:

make -f Makefile -f - <<<'echo-foo:; @echo $(foo)' echo-foo

Fedora 15: Configuring a network without DHCP for the host and the VMs

2011-07-10T18:23:00.007+02:00

First, a few good references:

Configuring a bridge on the host: http://www.linux-kvm.com/content/using-bridged-networking-virt-manager
Architecture illustration: http://www.libvirt.org/archnetwork.html
Examples of configuration: http://www.libvirt.org/formatnetwork.html#examples
Detailed description for a bridged network (but with DHCP-ed VMs): http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging
Detailed description for a bridged network (without DHCP): http://www.howtoforge.com/virtualization-with-kvm-on-a-fedora-11-server

In my case, as mentioned in http://www.linux-kvm.com/content/using-bridged-networking-virt-manager, I had to name the bridge vnet0, rather than br0, and I had to configure the guest VMs to share the physical device (mentionning "Bridge vnet0").
More specifically, in the virt-manager application (GUI), display the configuration panel of the guest VM, select the virtual network interface item (usually referenced by something like: 'NIC :0a:10:14' or something like that). Then, in the right-hand panel:

Select something like "Host device p10p1 (Bridge 'vnet0')" in the drop-down list associated to the "Source device" entry.
Select "virtio" in the "Device model" entry.
Click on the "Apply" button at the bottom right hand of the panel.

Configuration of the host
One can check that the bridge is working:
brctl show
and:
brctl showmacs vnet0

Content of /etc/sysconfig/network-scripts/ifcfg-p10p1 (change 'p10p1' by 'ethX' if appropriate on your computer):

DEVICE=p10p1
HWADDR=xx:xx:xx:xx:xx:xx
TYPE=Ethernet
NAME="System p10p1"
ONBOOT=yes
# Bridge
BRIDGE=vnet0
NM_CONTROLLED=no
IPV6INIT=no
IPV4_FAILURE_FATAL=yes
USERCTL=no

Note that the HWADDR line is optional. In particular, if you do not know/remember the MAC address, you can comment it, run 'service network restart' (or 'systemctl restart network.service' on Fedora 15) and check its value with 'ifconfig'.

Content of /etc/sysconfig/network-scripts/ifcfg-vnet0 file:

DEVICE=vnet0
TYPE=Bridge
ONBOOT=yes
DELAY=0
BOOTPROTO=static
DNS1=81.253.149.9
DNS2=8.8.8.8
GATEWAY=192.168.0.1
IPADDR=192.168.0.60
NETMASK=255.255.255.0
SEARCH="mydomain.com"
USERCTL=yes
NM_CONTROLLED=no
IPV6INIT=no
NAME="Bridge 0"
PEERNTP=yes

Configuration of the guest VM
Content of /etc/sysconfig/network-scripts/ifcfg-eth0 (change 'eth0' by what is appropriate on your guest VM; check the content of the '/sys/class/net' directory):

DEVICE=eth0
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
HWADDR=xx:xx:xx:xx:xx:xx
PEERDNS=yes
PEERROUTES=yes
IPADDR=192.168.0.103
GATEWAY=192.168.0.1
NETMASK=255.255.255.0
DNS1=81.253.149.9
DNS2=8.8.8.8

Fedora 15: Wired network interface named by udev p10p1 rather than standard eth0

2011-07-10T18:18:00.000+02:00

From Fedora 15, the default wired network interface may no longer be named eth0. Thanks to udev, it may be named according to the physical network interface, for instance p10p1 for a pci1000 card.

In fact, it is a feature (sic): https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming

Traces of the renaming can be seen within the logs:

dmesg | less
=> udev[556]: renamed network interface eth0 to p10p1

In any case, you can see which network interfaces have been set up on the computer:

ls -l /sys/class/net/

Signing on Wikimedia-based Pages

2011-06-23T20:19:00.000+02:00

Font
font-family
font-size
font-style
font-variant
font-weight
letter-spacing
line-height
text-decoration
text-align
text-indent
text-transform
white-space
word-spacing
color
Background
bg-attachment
bg-color
bg-image
bg-position
bg-repeat
Box
width
height
border-top
border-right
border-bottom
border-left
margin
padding
max-height
min-height
max-width
min-width
outline-color
outline-style
outline-width
Positioning
position
top
bottom
right
left
float
display
clear
z-index
List
list-style-image
list-style-type
list-style-position
Table
vertical-align
border-collapse
border-spacing
caption-side
empty-cells
table-layout
Effects
text-shadow
-webkit-box-shadow
border-radius
Other
overflow
cursor
visibility

The short version is, just add ~~~~ (four tildes), and Wikimedia will replace those four tildes by your username and the date-time at which you have made the change.

For more elaborate signatures, just read the following article on Wikipedia.

Linux "Connect: Network not reachable"

2011-06-12T19:03:00.002+02:00

On Linux home PCs/laptops (behind xDSL boxes, for instance), sometimes, the internal network can be reached (with a ping or through ssh, for instance), but the Internet can not. The error message is like following:

Connect: Network not reachable

Check that you have configured your gateway (usually, your xDSL box on the internal network) correctly. For instance:

ip route | grep via
default via 192.168.0.1 dev eth0  proto static

Here, 192.168.0.1 represents the gateway (it can have other IP addresses, but it usually ends with ".1").
If the gateway is not configured, just add it within the ethX (usually, eth0) interface.

On Fedora/Redhat/CentOS, edit the /etc/sysconfig/network-scripts/ifcfg-eth0, and just add a line such as GATEWAY=192.168.0.1 (replace with the IP address of your own gateway/ADSL box). Then restart the network with service network restart.
On Debian/Ubuntu, edit the /etc/network/interfaces, and add a line like gateway 192.168.0.1 (again, replace with the IP address of your own gateway/ADSL box). Then restart the network with /etc/init.d/networking restart.

Restify Django

2011-05-19T20:22:00.000+02:00

A few projects and documentation, in order to "restify" Django applications:

django-rest-interface with a good short introduction: http://code.google.com/p/django-rest-interface/wiki/RestifyDjango
Django REST framework with good documentation, numerous examples and even a sandbox.
A good tutorial on using Django Piston: http://www.robertshady.com/content/creating-very-basic-api-using-python-django-and-piston
django-rest-api with not so much documentation and code: https://bitbucket.org/schinckel/django-rest-api
And, at last, the worst practices (to be avoided): http://jacobian.org/writing/rest-worst-practices/

Repair the Bash Completion for files and directories

2011-05-09T16:06:00.001+02:00

The issue is well described in https://bugzilla.redhat.com/show_bug.cgi?id=702329 and https://bugzilla.redhat.com/show_bug.cgi?id=677446

A bug has been submitted to the Adobe forum: http://forums.adobe.com/thread/745833

Installing MS Windows Version of Google Picasa on Linux

2011-02-05T09:24:00.001+01:00

A few documents: http://wiki.winehq.org/picasa, http://groups.google.com/group/google-labs-picasa-for-linux/msg/27e2a3d8f7b0dfca?

No X11 Forwarding with SSH

2010-08-20T16:39:00.000+02:00

After a fresh installation of a Linux distribution (especially with a minimal installation), it may happen that the X11 (graphical) forwarding be absent. A symptom is that the DISPLAY environment variable is unset, where it should usually be set to something like localhost:10.0.
It is possible that the xauth utility is missing. In Fedora/RedHat, it corresponds to the xorg-x11-xauth package.
After having installed that package, also be sure to have the following line uncommented in the /etc/ssh/sshd_config configuration file:
X11Forwarding yes

Restart the SSH daemon (service):

sudo service sshd restart (Fedora/RedHat)

invoke-rc.d sshd restart (Debian)
and you should be done.

Missing PackageKit Module

2010-08-20T16:23:00.002+02:00

When launching some graphical (X11) applications (e.g., emacs) on Fedora, the following error message may appear:

Gtk-Message: Failed to load module "pk-gtk-module": 
libpk-gtk-module.so: cannot open shared object file: 
No such file or directory

The missing module corresponds to a PackageKit module for GTK, namely PackageKit-gtk-module.

Just install that module, and the error message will disappear.

How to share chunks of text (logs, code, configuration files, etc.)?

2010-07-20T16:31:00.000+02:00

During instant messaging (IRC, Skype, Google Talk, Facebook, etc.) chat sessions, it can be convenient to share chunks of text (for instance, debugging logs, source code, configuration files).

To share source code, codepad.org is a very good place (it even run the corresponding code, after having compiled it if necessary). For instance, the classical "Hello World!" code sample: http://codepad.org/oo9iA516

To share just text, fpaste.org is a good place, even though the volume of data is rather limited.

Time-out Issue with the Command-Line Koji Client

2010-07-20T16:20:00.001+02:00

References

Message on the Fedora packaging mailing list, and its follow up.
Ticket tracking that issue on the Fedora Infrastructure Web site

Issue Description
Koji (client) timed out (with error code 110) on my home machine, whatever the Fedora release (thanks to VirtualBox) and whatever the Unix user account I used. (I had even created a new Unix user account from scratch, just to make sure no historical configuration was in the way.)

I had tried from a network hosted server (very same Fedora 13 64bits as at home), and it worked without any problem.

Thus, all was like as if a firewall were in the way. My home machine is NATed (behind the ISP ADSL box). So, I tried with the Linux firewall de-activated, without more success. Nothing really changed since the last time I successfully connected with Koji.

A work around for building SRPM packages (by uploading them) was to force the authorisation type to "noauth". But, then, when I used the 'koji build' on a remote CVS-tagged package, koji failed with the "GenericError: task must have an owner" exception (because, of course, I was not authenticated).

Following is the exact command and corresponding error:
$ koji -d --debug-xmlrpc --authtype=ssl build dist-rawhide 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/R-msm/devel#R-msm-0_9_5-2_fc14' send: 'POST /kojihub/ssllogin HTTP/1.1\r\nHost: koji.fedoraproject.org:443\r\nAccept-Encoding: identity\r\nHost: koji.fedoraproject.org\r\nUser-Agent: pyOpenSSL_XMLRPC/0.12 - xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 140\r\n\r\n' Traceback (most recent call last): File "/usr/bin/koji", line 5077, in rv = locals()[command].__call__(options, session, args) File "/usr/bin/koji", line 757, in handle_build activate_session(session) File "/usr/bin/koji", line 5043, in activate_session session.ssl_login(options.cert, options.ca, options.serverca, proxyuser=options.runas) File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1628, in ssl_login sinfo = self.callMethod('sslLogin', proxyuser) File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1673, in callMethod return self._callMethod(name, args, opts) File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1698, in _callMethod return proxy.__getattr__(name)(*args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/lib64/python2.6/xmlrpclib.py", line 1235, in request self.send_content(h, request_body) File "/usr/lib64/python2.6/xmlrpclib.py", line 1349, in send_content connection.endheaders() File "/usr/lib64/python2.6/httplib.py", line 892, in endheaders self._send_output() File "/usr/lib64/python2.6/httplib.py", line 764, in _send_output self.send(msg) File "/usr/lib64/python2.6/httplib.py", line 743, in send self.sock.sendall(str) File "/usr/lib/python2.6/site-packages/koji/ssl/SSLConnection.py", line 107, in sendall raise socket.timeout((110, "Operation timed out.")) socket.timeout: (110, 'Operation timed out.')

$ koji -d --debug-xmlrpc --authtype=noauth build dist-rawhide 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/R-msm/devel#R-msm-0_9_5-2_fc14' send: 'POST /kojihub HTTP/1.0\r\nHost: koji.fedoraproject.org\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 107\r\n\r\n' send: "\n\ngetAPIVersion\n\n\n\n" reply: 'HTTP/1.1 200 OK\r\n' header: Date: Sat, 17 Jul 2010 23:45:14 GMT header: Server: Apache/2.2.3 (Red Hat) header: Content-Length: 121 header: AppTime: D=239216 header: AppServer: koji01.phx2.fedoraproject.org header: Connection: close header: Content-Type: text/xml body: "\n\n\n\n1\n\n\n\n" successfully connected to hub send: 'POST /kojihub HTTP/1.0\r\nHost: koji.fedoraproject.org\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 170\r\n\r\n' send: "\n\ngetBuildTarget\n\n\ndist-rawhide\n\n\n\n" reply: 'HTTP/1.1 200 OK\r\n' header: Date: Sat, 17 Jul 2010 23:45:15 GMT header: Server: Apache/2.2.3 (Red Hat) header: Content-Length: 597 header: AppTime: D=243000 header: AppServer: koji01.phx2.fedoraproject.org header: Connection: close header: Content-Type: text/xml body: "\n\n\n\n\n\nname\ndist-rawhide\n\n\nbuild_tag\n122\n\n\nbuild_tag_name\ndist-f14-build\n\n\ndest_tag_name\ndist-f14\n\n\nid\n10\n\n\ndest_tag\n117\n\n\n\n\n\n" send: 'POST /kojihub HTTP/1.0\r\nHost: koji.fedoraproject.org\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 147\r\n\r\n' send: "\n\ngetTag\n\n\n117\n\n\n\n" reply: 'HTTP/1.1 200 OK\r\n' header: Date: Sat, 17 Jul 2010 23:45:16 GMT header: Server: Apache/2.2.3 (Red Hat) header: Content-Length: 657 header: AppTime: D=251135 header: AppServer: koji01.phx2.fedoraproject.org header: Connection: close header: Content-Type: text/xml body: "\n\n\n\n\n\nmaven_support\n0\n\n\nlocked\n0\n\n\nname\ndist-f14\n\n\nid\n117\n\n\narches\ni686 x86_64\n\n\nmaven_include_all\n0\n\n\nperm_id\n\n\n\n\n\n" send: 'POST /kojihub HTTP/1.0\r\nHost: koji.fedoraproject.org\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 526\r\n\r\n' send: "\n\nbuild\n\n\ncvs://cvs.fedoraproject.org/cvs/pkgs?rpms/R-msm/devel#R-msm-0_9_5-2_fc14\n\n\ndist-rawhide\n\n\n\n\n\n\n\n\npriority\n\n\n__starstar\n1\n\n\n\n\n\n" reply: 'HTTP/1.1 200 OK\r\n' header: Date: Sat, 17 Jul 2010 23:45:16 GMT header: Server: Apache/2.2.3 (Red Hat) header: Content-Length: 281 header: AppTime: D=282895 header: AppServer: koji01.phx2.fedoraproject.org header: Connection: close header: Content-Type: text/xml body: "\n\n\n\n\nfaultCode\n1000\n\n\nfaultString\ntask must have an owner\n\n\n\n\n" Traceback (most recent call last): File "/usr/bin/koji", line 5077, in rv = locals()[command].__call__(options, session, args) File "/usr/bin/koji", line 796, in handle_build task_id = session.build(source, target, opts, priority=priority) File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1468, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1718, in _callMethod raise err koji.GenericError: task must have an owner

There was apparently an issue with the SSL connection. Though, when I used exactly the same certificates and SSH keys from another machine, it worked without any issue.

Solution

Thanks to mmcgrath, that issue could be solved... simply by changing the MTU value on my home desktop network card:
$ ip link set eth0 mtu 1400

To set it automatically, edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file, and add the following line:
MTU=1400

The MTU was set by default to 1500, which is apparently too big for an Internet connection with a low bandwidth, located far from the (Koji) server. Wikipedia quote:

Large packets can occupy a slow link for some time, causing greater delays to following packets and increasing lag and minimum latency. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer (and hence over most of the Internet), ties up a 14.4k modem for about one second.
Large packets are also problematic in the presence of communications errors. Corruption of a single bit in a packet requires that the entire packet be retransmitted. At a given bit error rate larger packets are more likely to be corrupted. Retransmissions of a larger packet takes longer.

Linux Firefox Personas

2010-06-24T09:28:00.000+02:00

Linux Firefox Personas
Tux: http://www.getpersonas.com/en-US/persona/56280
Debian Lenny: http://www.getpersonas.com/en-US/persona/1692
Ubuntu: http://www.getpersonas.com/en-US/persona/2418
Open Suse: http://www.getpersonas.com/en-US/persona/2845
Tux and Firefox: http://www.getpersonas.com/en-US/persona/2982

autopoint (gettext package) and CVS

2010-06-18T18:28:00.000+02:00

Sometimes, when running Autotools with NLS (National Language Support), the following error may happen:

$ autopoint --force
cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/remote/users2/darnaud' cvs [checkout aborted]: /remote/users2/darnaud/dev/latussvn/trunk/latus/tmpcvs4066/CVSROOT: No such file or directory find: `archive': No such file or directory find: `archive': No such file or directory find: `archive': No such file or directory autopoint: *** infrastructure files for version 0.14 not found; this is autopoint from GNU gettext-tools 0.17 autopoint: *** Stop.

In fact, the AM_GNU_GETTEXT_VERSION([xxx]) macro (within the configure.ac file) triggers the autopoint tool (part of the gettext package), which for some reason needs CVS in order to work. A developer gives a work-around in a bug report:

export AUTOPOINT=/bin/true

which seems to work just fine.

New default ciphering algorithm for cryptsetup in Fedora 13

2010-06-17T19:27:00.003+02:00

If you have encrypted some disks or partitions with the cryptsetup utility (part of the dm-crypt tool-set: http://code.google.com/p/cryptsetup/, and the older one: http://www.saout.de/misc/dm-crypt/), you may have been scared when discovering that the newest cryptsetup version (from version 1.1.0) did not recognise those encrypted devices.

For instance, let us assume you had prepared a partition like that:

cryptsetup create homeBackup /dev/sdb # The formatting of the partition should be done only once, of course mkfs.ext4 /dev/mapper/homeBackup mount /dev/mapper/homeBackup /mnt/homeBackup # Do something on the mounted partition... cp -a /home /mnt/homeBackup umount /mnt/homeBackup cryptsetup remove homeBackup

In fact, previous to version 1.1.0 of cryptsetup, the default cipher algorithm was aes-cbc-plain; it is now aes-cbc-essiv:256.

So, a disk encrypted with a version of cryptsetup lower than 1.1.0 (including, for instance, 1.1.0-rc3, which is used on Fedora 12) has now to be unlocked with the following command with cryptsetup from version 1.1.0 (which is, for instance, the version used on Fedora 13):
cryptsetup -c aes-cbc-plain -s 256 create homeBackup /dev/sdb

The change logs of cryptsetup 1.1.0 state that: http://code.google.com/p/cryptsetup/wiki/Cryptsetup110

SSL/TLS Error with a Subversion (SVN) client

2009-11-30T19:01:00.000+01:00

For the newest versions of the Apache server (from version 2.2.13 on Fedora 12, in the my case), the SSL-enabled WebDAV mode of Subversion now refuses to serve the (Subversion) client when the host name in the URL sent by that latter is not the same as the host name served by the Apache server, even though both host names point to the same IP address.

Following is the typical error sent back by the Subversion server (Apache in WebDAV mode):

$ svn up
svn: OPTIONS of 'https://svn.olddomain.com/svn/my-svnroot/myproject': SSL handshake failed: SSL error: A TLS warning alert has been received. (https://svn.olddomain.com)

The solution, in that case, is to re-set the repository of the Subversion client, according to the host name known by the Apache server.

$ svn switch --relocate https://svn.olddomain.com https://svn.newdomain.com

MPL-Related Compilation Errors with Boost 1.40.0 and CMake2

2009-10-26T19:23:00.003+01:00

When compiling Boost, prepared with CMake of the 1.40.0-cmake2 version, with a GCC 4.4.1 compiler on a 64bit Linux platform, there are two MPL-related errors:

Building CXX object libs/mpi/src/CMakeFiles/boost_mpi-mt-shared.dir/broadcast.cpp.o
In file included from /home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/detail/mpi_datatype_cache.hpp:14,
                 from /home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/datatype.hpp:28,
                 from /home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/communicator.hpp:21,
                 from /home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/collectives.hpp:22,
                 from /home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/collectives_fwd.hpp:20,
                 from /home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/collectives/broadcast.hpp:12,
                 from /home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/libs/mpi/src/broadcast.cpp:10:
/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/detail/mpi_datatype_oarchive.hpp: In member function âvoid boost::mpi::detail::mpi_datatype_oarchive::save_enum(const T&, mpl_::true_)â:
/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/detail/mpi_datatype_oarchive.hpp:65: error: expected primary-expression before âenumâ
/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/mpi/detail/mpi_datatype_oarchive.hpp:65: error: expected â;â before âenumâ
make[2]: *** [libs/mpi/src/CMakeFiles/boost_mpi-mt-shared.dir/broadcast.cpp.o] Error 1
make[1]: *** [libs/mpi/src/CMakeFiles/boost_mpi-mt-shared.dir/all] Error 2
make: *** [all] Error 2

For that error, the line 64 of $BOOST/boost/mpi/detail/mpi_datatype_oarchive.hpp must be changed, so that:
BOOST_MPL_ASSERT((sizeof(T)==sizeof(int_type)));
be replaced by:
BOOST_MPL_ASSERT_RELATION( sizeof(T), ==, sizeof(int_type) );

And:

Building CXX object libs/graph_parallel/src/CMakeFiles/boost_graph_parallel-mt-shared.dir/mpi_process_group.cpp.o

In file included from
/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/mpi_process_group.hpp:808,

                 from
/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/libs/graph_parallel/src/mpi_process_group.cpp:14:

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:
In function âint boost::graph::distributed::receive(const
boost::graph::distributed::mpi_process_group&, int, int, T&)â:

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:723:
error: âstderrâ was not declared in this scope

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:725:
error: there are no arguments to âfprintfâ that depend on a template
parameter, so a declaration of âfprintfâ must be available

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:725:
note: (if you use â-fpermissiveâ, G++ will accept your code, but
allowing the use of an undeclared name is deprecated)

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:
In function âtypename
boost::enable_if,
std::pair >::type
boost::graph::distributed::receive(const
boost::graph::distributed::mpi_process_group&, int, int, T*,
size_t)â:

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:744:
error: âstderrâ was not declared in this scope

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:746:
error: there are no arguments to âfprintfâ that depend on a template
parameter, so a declaration of âfprintfâ must be available

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:
In function âint boost::graph::distributed::receive(const
boost::graph::distributed::mpi_process_group&, int, int, T&)
[with T = int]â:

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:610:  
instantiated from âvoid
boost::graph::distributed::mpi_process_group::global_trigger_launcher::receive(const
boost::graph::distributed::mpi_process_group&, int, int,
boost::graph::parallel::trigger_receive_context, int) const [with Type
= int, Handler = void (*)(const
boost::graph::distributed::mpi_process_group&, int, int, int,
bool)]â

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/libs/graph_parallel/src/mpi_process_group.cpp:1111:  
instantiated from here

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:723:
error: âfprintfâ was not declared in this scope

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:
In function âint boost::graph::distributed::receive(const
boost::graph::distributed::mpi_process_group&, int, int, T&)
[with T =
boost::graph::distributed::mpi_process_group::outgoing_messages]â:

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:610:  
instantiated from âvoid
boost::graph::distributed::mpi_process_group::global_trigger_launcher::receive(const
boost::graph::distributed::mpi_process_group&, int, int,
boost::graph::parallel::trigger_receive_context, int) const [with Type
= boost::graph::distributed::mpi_process_group::outgoing_messages,
Handler = void (*)(const
boost::graph::distributed::mpi_process_group&, int, int,
boost::graph::distributed::mpi_process_group::outgoing_messages&,
bool)]â

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/libs/graph_parallel/src/mpi_process_group.cpp:1111:  
instantiated from here

/home/build/dev/fedorasvn/reviews/boost_529563/boost-1.40.0.cmake2/boost/graph/distributed/detail/mpi_process_group.ipp:723:
error: âfprintfâ was not declared in this scope

make[2]: *** [libs/graph_parallel/src/CMakeFiles/boost_graph_parallel-mt-shared.dir/mpi_process_group.cpp.o] Error 1

make[1]: *** [libs/graph_parallel/src/CMakeFiles/boost_graph_parallel-mt-shared.dir/all] Error 2

make: *** [all] Error 2

For that error, a header file inclusion is missing around the line 22 of $BOOST/boost/graph/distributed/detail/mpi_process_group.ipp:
#include

I attach the corresponding patch on the Boost-CMake ticket. To apply it, just go to the $BOOST directory, copy the patch (boost-mpl-compilation-fix.patch file) into there, and type something like:
patch -p1 --dry-run < boost-mpl-compilation-fix.patch
and, if everything seems fine:
patch -p1 < boost-mpl-compilation-fix.patch

Network Configuration for Qemu on Fedora

2009-10-25T19:16:00.000+01:00

# Update the eth0 configuration
cat > /etc/sysconfig/network-scripts/ifcfg-eth0 << _EOF
# Networking Interface
DEVICE=eth0
HWADDR=00:24:8C:BA:7E:5E
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
NM_CONTROLLED=yes
USERCTL=yes
IPV6INIT=no
PEERDNS=yes
PEERROUTES=yes
NAME="System eth0"
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
_EOF

# Update the eth0:1 configuration
cat > /etc/sysconfig/network-scripts/ifcfg-eth0\:1 << _EOF
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
GATEWAY=192.168.0.1
DNS1=81.253.149.9
DEVICE=eth0:1
BOOTPROTO=none
NETMASK=255.255.255.0
DNS2=80.10.246.132
TYPE=Ethernet
IPADDR=192.168.0.49
ONPARENT=yes
NM_CONTROLLED=yes
IPV6INIT=no
USERCTL=yes
BRIDGE=br0
_EOF

# Create a br0 interface:
cat > /etc/sysconfig/network-scripts/ifcfg-br0 << _EOF
DEVICE=br0
TYPE=Bridge
ONBOOT=yes
IPADDR=192.168.0.50
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
_EOF
# In /etc/qemu-ifup
cat > /etc/qemu-ifup << _EOF
bridge=virbr0
ifconfig $1 0.0.0.0 up
brctl addif $bridge $1 || true
_EOF

# In /etc/qemu-ifdown
cat > /etc/qemu-ifdown << _EOF
bridge=virbr0
brctl delif $bridge $1 || true
ifconfig $1 down
_EOF

Packaging Boost (with MPI) with CMake under Fedora

2009-10-25T01:47:00.001+02:00

A change request has been submitted to Fedora Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=529563

The purpose is to deliver Boost.MPI, along with the other Boost libraries, under Fedora Linux distributions.

And, on the way to build the Boost RPM, Boost.Build (and BJam) proved to be a nightmare, as testified by GNU-Boost author (http://boost-extras.sourceforge.net/gnu-boost/gnu-boost.html). Hence, Benjamin Koznik suggested to use CMake (https://svn.boost.org/trac/boost/wiki/CMake), instead of Boost.Build/BJam.

Moreover, I had to fix a compilation bug related to namespace usage within the example program for the accumulators library (https://svn.boost.org/trac/boost/ticket/3543).

S. Vinoski new interests

2009-09-29T15:58:00.000+02:00

It seems like some gurus are deeply changing their way of thinking...

There was already Tom DeMarco article (200KB PDF) in IEEE software, "Software Engineering:
An Idea Whose Time Has Come and Gone?"

Steve Vinoski, one of the once OOP-savvy advocates also publishes some kind of a bomb, still in IEEE software. By the way, his other articles are worth reading too: http://steve.vinoski.net/blog/internet-computing-columns/, for instance the article about Multilingual Programming (160KB PDF).

Lowercase Transformation with Unicode and Python

2009-09-27T19:15:00.001+02:00

A simple Python script to transform input data (strings) into lower (resp. upper) cases:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

query = u'ЙЦУКЕНГШЩЗХЪ ФЫВАПРОЛДЖЭ ЯЧСМИТЬБЮ Ё ЇІЄ'
query_input = raw_input()
if query_input != '':
        query = unicode(query_input,encoding='utf-8')

print 'Original query: ' + query
print 'Lower-cased query: ' + query.lower()
print 'Upper-cased query: ' + query.upper() + '\n'

Example of use (Cyrillic, more specifically Russian and Ukrainian characters, letters are transformed into lower and upper cases):

$ ./pytolower.py 

Original query: ЙЦУКЕНГШЩЗХЪ ФЫВАПРОЛДЖЭ ЯЧСМИТЬБЮ Ё ЇІЄ
Lower-cased query: йцукенгшщзхъ фывапролджэ ячсмитьбю ё їіє
Upper-cased query: ЙЦУКЕНГШЩЗХЪ ФЫВАПРОЛДЖЭ ЯЧСМИТЬБЮ Ё ЇІЄ

Check that a (Unix Shell) script is launched from a given directory

2009-09-14T19:24:00.000+02:00

To check that a Unix Shell script is launched from a given directory, you can issue the following command:

if test ! "$(givenDirectory)" -ef "$(pwd)"; then echo "This script must be executed directly from the $(givenDirectory) directory." exit -1
fi

In particular, when the script should be launched from the directory in which it is located:

if test ! "$(dirname $0)" -ef "$(pwd)"; then echo "This script must be executed directly from the source directory." exit -1
fi

Airport Search

2009-09-13T21:07:00.001+02:00

The new Airport Search service seems to work. Do not hesitate to send me your comments!

It relies on the OpenTrep library. Do not hesitate to contribute, either :)

Boost.Python needs python-numarray

2009-09-13T16:07:00.005+02:00

When trying to compile an example with Boost.Python, I got the following kind of errors:

[...]
/usr/include/boost/python/detail/make_tuple.hpp:25: error: there are no arguments to ‘PyTuple_SET_ITEM’ that depend on a template parameter, so a declaration of ‘PyTuple_SET_ITEM’ must be available /usr/include/boost/python/detail/make_tuple.hpp:25: error: ‘class boost::python::tuple’ has no member named ‘ptr’ /usr/include/boost/python/detail/make_tuple.hpp:25: error: ‘class boost::python::api::object’ has no member named ‘ptr’ /usr/include/boost/python/detail/make_tuple.hpp:25: error: there are no arguments to ‘PyTuple_SET_ITEM’ that depend on a template parameter, so a declaration of ‘PyTuple_SET_ITEM’ must be available In file included from /usr/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:117,                  from /usr/include/boost/python/tuple.hpp:65,                  from /usr/include/boost/python/dict.hpp:12,                  from /usr/include/boost/python.hpp:24,                  from pyopentrep.cpp:11: /usr/include/boost/python/detail/make_tuple.hpp: In function ‘boost::python::tuple boost::python::make_tuple(const A0&, const A1&, const A2&, const A3&, const A4&, const A5&, const A6&, const A7&, const A8&, const A9&, const A10&, const A11&, const A12&, const A13&)’: /usr/include/boost/python/detail/make_tuple.hpp:24: error: ‘::PyTuple_New’ has not been declared /usr/include/boost/python/detail/make_tuple.hpp:25: error: ‘class boost::python::tuple’ has no member named ‘ptr’ /usr/include/boost/python/detail/make_tuple.hpp:25: error: ‘class boost::python::api::object’ has no member named ‘ptr’
[...]
In file included from /usr/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:117,                  from /usr/include/boost/python/tuple.hpp:65,                  from /usr/include/boost/python/dict.hpp:12,                  from /usr/include/boost/python.hpp:24,                  from pyopentrep.cpp:11: /usr/include/boost/python/detail/make_tuple.hpp: In function ‘boost::python::tuple boost::python::make_tuple(const A0&, const A1&, const A2&, const A3&, const A4&, const A5&, const A6&, const A7&, const A8&, const A9&, const A10&, const A11&, const A12&, const A13&) [with A0 = long int, A1 = long int, A2 = long int, A3 = long int, A4 = long int, A5 = long int, A6 = long int, A7 = long int, A8 = long int, A9 = long int, A10 = long int, A11 = long int, A12 = long int, A13 = long int]’: /usr/include/boost/preprocessor/iteration/detail/local.hpp:76:   instantiated from here /usr/include/boost/python/detail/make_tuple.hpp:25: error: ‘PyTuple_SET_ITEM’ was not declared in this scope In file included from /usr/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:122,                  from /usr/include/boost/python/tuple.hpp:65,                  from /usr/include/boost/python/dict.hpp:12,                  from /usr/include/boost/python.hpp:24,                  from pyopentrep.cpp:11: /usr/include/boost/python/detail/make_tuple.hpp: In function ‘boost::python::tuple boost::python::make_tuple(const A0&, const A1&, const A2&, const A3&, const A4&, const A5&, const A6&, const A7&, const A8&, const A9&, const A10&, const A11&, const A12&, const A13&, const A14&) [with A0 = long int, A1 = long int, A2 = long int, A3 = long int, A4 = long int, A5 = long int, A6 = long int, A7 = long int, A8 = long int, A9 = long int, A10 = long int, A11 = long int, A12 = long int, A13 = long int, A14 = long int]’: [...]
/usr/include/boost/preprocessor/iteration/detail/local.hpp:79:   instantiated from here /usr/include/boost/python/detail/make_tuple.hpp:25: error: ‘PyTuple_SET_ITEM’ was not declared in this scope In file included from /usr/include/boost/python/args.hpp:25,                  from /usr/include/boost/python.hpp:11,                  from xxx.cpp:11: /usr/include/boost/python/object_core.hpp: In constructor ‘boost::python::api::object::object(const T&) [with T = boost::python::tuple]’: /usr/include/boost/python/numeric.hpp:121:   instantiated from ‘void boost::python::numeric::array::resize(const Sequence&) [with Sequence = boost::python::tuple]’ /usr/include/boost/preprocessor/iteration/detail/local.hpp:37:   instantiated from here /usr/include/boost/python/object_core.hpp:315: error: ‘object_base_initializer’ was not declared in this scope

As some errors may suggest, we just need the NumArray Python module. For instance, with Fedora:
yum -y install python-numarray

Fedora Rawhide (F11/F12) Update

2009-09-13T13:05:00.007+02:00

When trying to update the Fedora Rawhide on my desktop, I came across a RPM compression issue, as lzma (compression) now uses xz.
The error was:
Running rpm_check_debug ERROR with rpm_check_debug vs depsolve: rpmlib(PayloadIsXz) <= 5.2-1 is needed by kernel-firmware-2.6.31-2.fc12.noarch rpmlib(PayloadIsXz) <= 5.2-1 is needed by kernel-2.6.31-2.fc12.x86_64 Complete!

Thanks to the Fedora-Developer forum, and after adaption of the suggested workaround (the RPM packages have moved, after a few days, from the fedora-updates-testing repository to fedora-updates), the issue has been solved with the following command:
yum --enablerepo=updates --disablerepo=rawhide update rpm*
Explanation: the RPM packages of Fedora 11 have been upgraded so as to be compatible with the new xz compression utility. So, Rawhide should be upgraded with the RPM packages of Fedora 11.

Then, we may have to check that Fedora 11 Yum repositories are disabled:
grep "enabled=1" /etc/yum.repos.d/*
which should yield on fedora-rawhide.repo
If other Yum repositories are enabled, we have to disable them (e.g., vi /etc/yum.repos.d/fedora-updates.repo and change enabled=1 into enabled=0) at this stage.

Then, I had an issue with the Python urandom() function used by Yum:

  File "/usr/lib/python2.6/os.py", line 693, in urandom
    raise NotImplementedError("/dev/urandom (or equivalent) not found")
NotImplementedError: /dev/urandom (or equivalent) not found

That function makes use of the /dev/urandom special device, which was not present on my desktop (and Ihave no idea why)...
In order to re-create it, I had to issue the following command:
mknod --mode=g+w /dev/urandom /dev/urandom c 1 9 # char device, with major nb=1 and minor nb=9

Then, Yum was working back again, and I could first update the kernel:
yum -y update kernel* && reboot
Then, after a reboot, all the rest:
yum -y update

Introduction

2009-09-13T12:26:00.003+02:00

Just to clear any ambiguity, FOSS means Free and Open Source Software.

I have been a Linux user since 1994, when a friend asked me for help installing a Slackware distribution with already a working X server. Then, I switched to RedHat and Fedora, keeping an eye on Mandriva, Ubuntu and, of course, Debian.

I am mainly a C++ developer, but keen to program in any fun language, be it script (JavaScript, PHP, Python, Ruby, Caml, etc.), compiled (Java, C, C++, etc.) or specialised (SQL, XML, HTML, IDL, Prolog, Logo, OpenCL?, Erlang?).

When dealing with open source software for my own work and research activities, I am often confronted to issues, which I usually eventually overcome after much time and energy, thanks to the Internet community. If, as a feedback, I can in turn contribute to that human being-owned knowledge, it is great.