64-bit LibreOffice for OS X
As such, it has been possible for a long time to build LibreOffice for OS X with a current Xcode 4.x and its Clang compiler, also as 64-bit code.
LibreOffice has traditionally used the ATSUI API to display text on Mac OS X. ATSUI was deprecated years ago and superseded by CoreText. ATSUI is still present in the OS, but only for 32-bit code. 64-bit code has to use CoreText. Which is a good thing, of course; it forces developers to finally stop using obsolete API if they want to produce 64-bit code.
Naturally, CoreText is also what iOS provides, so it was necessary to get the CoreText engine into shape also for the benefit of the iOS porting effort.
Note that this work has been available in the LibreOffice source code repository continuously, even while known to be far from usable. I don't believe in the "check in the code when it is ready" way of working in an Open Source community.
There are still some known glitches. For instance, the placement of glyphs on a line that you are editing is slightly "nervous". Glyphs might jump back and forth a pixel when you add or remove characters. I will work on fixing this.
Those who are interested can find daily builds. ("Daily" should be taken with a grain of salt; whether builds have been uploaded for a given day or not depends on whether I remember to keep my tinderbox running, and in what shape the master branch is.)
If you want to build a CoreText-using LibreOffice yourself, use the --enable-coretext option. To build a 64-bit LibreOffice, use --enable-64-bit.
Thanks to Norbert Thiebaud for his initial work on using CoreText.
Member
tserongHackweek 9: Ceph Appliance Odyssey
This week is SUSE Hack Week 9. I wanted to spend some time working on a Ceph appliance image to make it easy to play with Ceph on openSUSE and/or SLES.
I tried making a SLES 11 SP2 appliance with SUSE Studio. I had to add the filesystems and devel:libraries:c_c++ repos from OBS to get reasonably up-to-date Ceph 0.56 and libboost_thread.so.1.49.0, but on boot when the appliance tried to expand its root filesystem, it died claiming it couldn’t load libe2p.so.2. Studio claims to be pulling in e2fsprogs from both the SP2 Updates and filesystems repo, so maybe that’s the problem. It seems impossible to choose one or the other, as they are the same version. (Update: it was just pointed out to me that you can click the little box next to the version number to choose which one is installed – must try again.)
So I left that alone and tried an openSUSE 12.3 appliance. The filesystems/ceph build for 12.3 is disabled, so I branched it and kicked off a build which failed with an exciting OOM error:
[ 3831s] [ 3803.167109] Out of memory: Kill process 16364 (cc1plus) score 254 or sacrifice child [ 3831s] [ 3803.167959] Killed process 16364 (cc1plus) total-vm:825128kB, anon-rss:168760kB, file-rss:4kB [ 3831s] g++: internal compiler error: Killed (program cc1plus) [ 3831s] Please submit a full bug report, [ 3831s] with preprocessed source if appropriate. [ 3831s] See for instructions.
Guess I should do what it says and file a bug. But I really did want something to play with immediately, so I added http://ceph.com/rpm/opensuse12/x86_64/ as a repo, and pulled in the upstream Ceph 0.56 RPMs. This seems to have worked and given me an openSUSE 12.3 image I can use to run through the Ceph 5-Minute Quick Start, Block Device Quick Start and CephFS Quick Start. So, here’s my extremely terse openSUSEified version of those quick start documents:
5-Minute Quick Start
Deploy the Appliance Image
I’m doing this with a couple of VMs, so in my case I make a couple of copies of the image:
# cp ~/openSUSE_12.3_Ceph_0.56.x86_64-0.0.3.qcow2 \
/var/lib/libvirt/images/ceph-quickstart-server.qcow2
# cp ~/openSUSE_12.3_Ceph_0.56.x86_64-0.0.3.qcow2 \
/var/lib/libvirt/images/ceph-quickstart-client.qcow2
Then I use virt-manager to create two VMs, backed by those images. Boot ’em up, log in (root password is “linux”), run yast network and set sensible hostnames (“ceph-client” and “ceph-server” instead of “linux-kjqd”, although admittedly those names wouldn’t be very sensible in a real deployment with more than one node).
Edit the Configuration File
The appliance image includes the /etc/ceph/ceph.conf file from the original 5-minute quick start, so log in to ceph-server, edit that file and replace {hostname} and {ip-address} with their real values, then copy the configuration file to ceph-client:
# scp /etc/ceph/ceph.conf ceph-client:/etc/ceph/
Deploy the Configuration
On ceph-server, create directories for each daemon:
# mkdir -p /var/lib/ceph/osd/ceph-0 # mkdir -p /var/lib/ceph/osd/ceph-1 # mkdir -p /var/lib/ceph/mon/ceph-a # mkdir -p /var/lib/ceph/mds/ceph-a
Still on ceph-server, run the following:
# cd /etc/ceph # mkcephfs -a -c /etc/ceph/ceph.conf -k ceph.keyring
Start Ceph
On ceph-server:
# chkconfig ceph on # rcceph start # ceph health
This will initially show something like:
HEALTH_ERR 576 pgs stuck inactive; 576 pgs stuck unclean; no osds
Eventually it will say HEALTH_OK and you’re good to go.
Copy the Keyring to the Client
This is necessary for authentication:
# scp /etc/ceph/ceph.keyring ceph-client:/etc/ceph/
Block Device Quick Start
On ceph-client:
# rbd create foo --size 4096 # modprobe rbd # rbd map foo --pool rbd --name client.admin # mkfs.ext4 -m0 /dev/rbd1 # mkdir /mnt/myrbd # mount /dev/rbd1 /mnt/myrbd
(Why is this /dev/rbd1, not /dev/rbd/rbd/foo as in the original quick start?)
CephFS Quick Start
On ceph-client (kernel driver, not FUSE):
# mkdir /mnt/mycephfs
# mount -t ceph -o name=admin,secret=$(ceph-authtool \
--name client.admin /etc/ceph/ceph.keyring --print-key) \
ceph-server:/ /mnt/mycephfs
Interestingly, this gives “mount: error writing /etc/mtab: Invalid argument”, but still seems to actually mount the filesystem.
Also note that it appears I have 32GB of space for Ceph to use, even though ceph-server only has a 16GB root partition. I rather think that’s because there’s two OSDs, but both are just running off the root filesystem, they’re not separate disks/filesystems. I assume this is one of those Don’t Try This At Home things.
Icecream 1.0.0 released
Yes, it's been almost a decade with us. And as it usually is with versions 1.0.0 after such a long time, it doesn't actually bring anything breadth-taking. But there of course have been some fixes and improvements since version 0.9.7, and in fact even one larger feature found its way in, out-of-the-box support for the Clang compiler, including support for its plugins. Written by yours truly, after finding out about this compiler and finding out it was pretty difficult to get it to work with 0.9.7 icecream at least in some way. And also being the reason for repeatedly bugging Coolo about another icecream release :) .
And, on the way to 1.0.0, the development repository has been moved to GitHub. Which should be good, as IMO the fact that it used to be developed in the KDE SVN helped to make the false impression that it is somehow specific to KDE, limiting its use among developers of other projects. This is probably actually the biggest feature of the 1.0.0 release.
So, thanks to everyone who has helped to make compiling a much more pleasant experience (possibly even with the added colors in the icecream monitor ;) ).
Dark Leaf Wallpaper
Here is another wallpaper proposal for the 13.1 complimentary wallpaper package. The idea here is to form a nice transparency effect with words that relate to the world of Open Source and openSUSE, or course.
I also added a dark leaf in the center to add some green to the image. However the green leaf can be taken out easily if you think it doesn't work well. For the effects and purposes of keeping a dark background design in the pile of complimentary wallpapers.
Please keep your wallpaper submissions, projects and ideas coming. We are gathering your suggestions so please send them in. If you need help creating a wallpaper and submitting it to our project, given that you may not understand the formatting criteria, please contact me or anyone else at the #opensuse-artwork channel on IRC.
For now, here is the new wallpaper (I followed some tutorials online for this one) :D
Anditosan
KDE Platform, Workspaces and Applications 4.10.2 packages available for openSUSE
KDE has released its monthly update for the 4.10 release, and after a brief wait while the Open Build Service worked over the released tarballs, the openSUSE KDE team is pleased to announce the availability of the 4.10.2 release packages for openSUSE 12.2 and 12.3.
[]({{ site.url }}/images/2013/04/757111961.png)
Despite being a minor release, more than 100 bugs were fixed, in particular there were many KDEPIM fixes touching both the low level stack and KMail/KAddressbook/Kontact. Some highlights on the fixed issues:
-
Issues creating IMAP folders with KDEPIM (KDE bugs 291143, 292418, 305987)
-
Issues with encrypted mails in KDEPIM (KDE bugs 301088, 313478)
-
KMail not creating required folders at startup (KDE bug 303117)
-
Crashes when using the semantic desktop framework (KDE bug 313478)
-
Improvements to CalDAV support in KDEPIM
And this is just a small part of the complete list.
As usual, packages live in the KDE:Release:410 (openSUSE 12.3, openSUSE 12.2) repository. You can add the repositories through zypper or YaST.
The KDE:Distro:Factory repository has also been updated. If you want to contribute and help KDE packaging in openSUSE, use the KDE:Distro:Factory version, otherwise stick to the KDE:Release:410.
The package manager may complain about needing a downgrade of the branding packages: it is harmless, as some packages were splitted and as such they report a lower version number. Just accept the downgrade in the branding packages and all will be well.
Report bugs in packaging to Novell’s Bugzilla, and bugs in the software directly to KDE.
Have fun with 4.10.2!
Wayland/Weston on oS-12.3
After Richards recent patch about adding a colour management system to wayland, I was interested to build a Oyranos CMS connection module for wayland. The patch is in a initial stage, but might get to a similar level like what is already in CompICC and KWin colour servers.
First I substituted all openSUSE-12.3 distro packages with the adequate packages from tobijk and obtained a version 1.0.6 . Keeping the distro Mesa package resulted in a missed EGL Wayland extension and some crashes. On the Wayland website are some instructions on how to setup the environment. Especially the XDG_RUNTIME_DIR variable needs attention. I skipped the part of adding a special weston-lauch group and run the application simply by root. However the a symbol in cairo was missed “cairo_egl_device_create”. After cloning and building pixman and cairo following the Wayland instructions everything went fine. Here a simple ~/.config/weston.ini file to start with:
[wayland-desktop-shell]
locking=true
[launcher]
icon=/usr/share/icons/oxygen/32×32/apps/utilities-terminal.png
path=/usr/bin/weston-terminal
Weston launches on my system into a multi monitor setup with nouveau. There is still heave tearing, while moving the terminal. After Strg+Alt+Entf (Ctrl+Alt+Del) weston quits.
Tidy home, tidy Build Service
Anyone using the Open Build Service in the last couple of weeks will notice how hopelessly overloaded it is. I blame the ARM lads ;). But there is something that we should all do as responsible community members: delete or disable your old stuff.
I’ve just spent 15 minutes going through my Open Build Service home:wstephenson project, deleting unfinished works in progress, finished branches that were never deleted, inherited repositories in branched projects that aren’t relevant to the tweaks I’m making, and I think I’ve saved about 100 repositories for the OBS scheduler to recalculate and look at publishing.
Time for you to spring clean too?
Xen live migration in OpenStack Grizzly
I recently experimented with live migration in an OpenStack Grizzly cluster of Xen compute nodes and thought it useful to write a short blog post for the benefit of others interested in OpenStack Xen deployments.
My OpenStack Grizzly cluster consisted of three nodes: One controller node hosting most of the OpenStack services (rabbitmq, mysql, cinder, keystone, nova-api, nova-scheduler, etc.) and two Xen compute nodes running nova-compute, nova-network, and nova-novncproxy. All nodes were running fully patched SLES11 SP2. devstack was used to deploy the OpenStack services.
For the most part, I used the OpenStack documentation for configuring live migration to setup the environment. The main configuration tasks include
- Configuring shared storage on the compute nodes involved in live migration. I took the simple approach and used NFS for shared storage between the compute nodes, mounting an NFS share at /opt/stack/data/nova/instances in each compute node.
- Ensure that the UID and GID of your nova (or stack) and libvirt users are identical between each of your servers. This ensures that the permissions on the NFS mount will work correctly.
- Ensure the shared directory has ‘execute/search’ bit set, e.g. chmod o+x /opt/stack/data/nova/instances
- Ensure firewall is properly configured to allow migrations. For Xen, port 8002 needs to be open. This is the port xend listens on for migration requests.
In addition to the steps described in the OpenStack documentation, the following configuration needs to be performed on the Xen compute nodes
- Enable migration (aka relocation) in /etc/xen/xend-config.sxp: (xend-relocation-server yes)
- Define a list of hosts allowed to connect to the migration port in /etc/xen/xend-config.sxp. To allow all hosts, leave the list empty: (xend-relocation-hosts-allow ”)
- Set the ‘live_migration_flag’ option in /etc/nova/nova.conf. In the legacy xm/xend toolstack, xend implements all of the migration logic. Unlike the libvirt qemu driver, the libvirt legacy xen driver can only pass the migration request to the Xen toolstack, so the only migration flags needed are VIR_MIGRATE_LIVE and VIR_MIGRATE_UNDEFINE_SOURCE: live_migration_flag=VIR_MIGRATE_LIVE,VIR_MIGRATE_UNDEFINE_SOURCE
- Set the live_migration_uri option in /etc/nova/nova.conf. The default for this option is ‘qemu+tcp://%s/system’. For Xen, this needs to be ‘xenmigr://%s/system’: live_migration_uri = xenmigr://%s/system
After these configuration steps, restart xend and nova-compute on the Xen compute nodes to reload the new configuration. Your OpenStack Xen cluster should now be able to perform live migration as per the OpenStack Using Migration documentation.
On my small cluster, xen71 is the controller node and xen76 and xen77 are the Xen compute nodes. I booted an instance of a SLES11 SP2 Xen HVM image that was provisioned on xen76.
stack@xen71:~> nova list
+--------------------------------------+------------------------+--------+--------------------+
|ID | Name | Status | Networks |
+--------------------------------------+------------------------+--------+--------------------+
| 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a | sles11sp2-xen-hvm-test | ACTIVE | private=10.4.128.2 |
+--------------------------------------+------------------------+--------+--------------------+
stack@xen71:~> nova show 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-04-05T17:27:16Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | xen76 |
| key_name | None |
| image | SLES11SP2-xen-hvm (5b39e6b3-bc3f-4fb0-81a0-b115cb8ada80) |
| private network | 10.4.128.2 |
| hostId | cca619a77da34c0c26001fb2438d7cce6a5da6408ae8ec111401f627 |
| OS-EXT-STS:vm_state | active |
| OS-EXT-SRV-ATTR:instance_name | instance-0000000a |
| OS-EXT-SRV-ATTR:hypervisor_hostname | xen76.virt.lab.novell.com |
| flavor | m1.tiny (1) |
| id | 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a |
| security_groups | [{u'name': u'default'}] |
| user_id | 86b77dee688e4eff957865205d27464a |
| name | sles11sp2-xen-hvm-test |
| created | 2013-04-05T17:10:04Z |
| tenant_id | 0833047bb70d4b38874328aad83b7140 |
| OS-DCF:diskConfig | MANUAL |
| metadata | {} |
| accessIPv4 | |
| accessIPv6 | |
| progress | 0 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-AZ:availability_zone | nova |
| config_drive | |
+-------------------------------------+----------------------------------------------------------+
Now let’s migrate the instance to the xen77 compute node
stack@xen71:~> nova live-migration 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a xen77
While the migration is in progess, we can see the status and task state as migrating
stack@xen71:~> nova show 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | MIGRATING |
| updated | 2013-04-05T20:16:27Z |
| OS-EXT-STS:task_state | migrating |
| OS-EXT-SRV-ATTR:host | xen76 |
| key_name | None |
| image | SLES11SP2-xen-hvm (5b39e6b3-bc3f-4fb0-81a0-b115cb8ada80) |
| private network | 10.4.128.2 |
| hostId | cca619a77da34c0c26001fb2438d7cce6a5da6408ae8ec111401f627 |
| OS-EXT-STS:vm_state | active |
| OS-EXT-SRV-ATTR:instance_name | instance-0000000a |
| OS-EXT-SRV-ATTR:hypervisor_hostname | xen76.virt.lab.novell.com |
| flavor | m1.tiny (1) |
| id | 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a |
| security_groups | [{u'name': u'default'}] |
| user_id | 86b77dee688e4eff957865205d27464a |
| name | sles11sp2-xen-hvm-test |
| created | 2013-04-05T17:10:04Z |
| tenant_id | 0833047bb70d4b38874328aad83b7140 |
| OS-DCF:diskConfig | MANUAL |
| metadata | {} |
| accessIPv4 | |
| accessIPv6 | |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-AZ:availability_zone | nova |
| config_drive | |
+-------------------------------------+----------------------------------------------------------+
Once the migration completes, we can see that the instance is now running on xen77
stack@xen71:~> nova show 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-04-05T20:11:37Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | xen77 |
| key_name | None |
| image | SLES11SP2-xen-hvm (5b39e6b3-bc3f-4fb0-81a0-b115cb8ada80) |
| private network | 10.4.128.2 |
| hostId | cabdc8468130edd0f85440f1b2922419b359b3da36a40de98713dbda |
| OS-EXT-STS:vm_state | active |
| OS-EXT-SRV-ATTR:instance_name | instance-0000000a |
| OS-EXT-SRV-ATTR:hypervisor_hostname | xen76.virt.lab.novell.com |
| flavor | m1.tiny (1) |
| id | 6b45baa2-3dc2-420c-a7ab-aad25fc1aa2a |
| security_groups | [{u'name': u'default'}] |
| user_id | 86b77dee688e4eff957865205d27464a |
| name | sles11sp2-xen-hvm-test |
| created | 2013-04-05T17:10:04Z |
| tenant_id | 0833047bb70d4b38874328aad83b7140 |
| OS-DCF:diskConfig | MANUAL |
| metadata | {} |
| accessIPv4 | |
| accessIPv6 | |
| progress | 0 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-AZ:availability_zone | nova |
| config_drive | |
+-------------------------------------+----------------------------------------------------------+
You might notice a small bug here in that OS-EXT-SRV-ATTR:hypervisor_hostname is not updated with the xen77 host now running the instance. A minor issue that I will add to my list of bugs needing investigation.
Wallpaper Proposal for openSUSE 13.1
The artwork team is now taking submissions for a default wallpaper and a wallpaper collection package for the upcoming openSUSE 13.1. However, you may be wondering, why now? 12.3 was just released!
The reason is that artwork being the face of openSUSE on the desktop needs a long time to mature. It will be a while before the team decides on what will go for defaults and so on, therefore we need to submit our ideas early enough to allow the whole process to evolve and be ready for prime time.
Take into account that submitting images is not a simple task, the format measures need to be met and the image will likely need tweaking, even after it has been chosen as part of the final distribution. Also, the wallpaper has generally marked the main source of inspiration for the rest of the distribution, splash screens, login screens, KDE plasma theme, all depend on the good communication they can have with the wallpaper.
For now, I am leaving this proposal with you and hope that you can also make your submissions soon. Please write and link your image to opensuse-artwork@opensuse.org
Thank you
Andy (anditosan)
A two-dimensional interval over integers
A two-dimensional interval over integersHmm, two-dimensional, but bounded by a lower and an upper value? And the Wikipedia article it refers to says that
This is most easily depicted as a set of integers, bounded by a lower and an upper value - but excluding the upper value. All inbetween values are included in the set. (see also http://en.wikipedia.org/wiki/Interval_%28mathematics%29)
In mathematics, a (real) interval is a set of real numberswhile the above talks about integers. But oh well.
Got it yet? There's more:
The set is half-open, i.e. the lower bound is included, the upper bound not (if you're used to the notation - we're talking about [a,b) here, compared to closed [a,b] or fully open intervals (a,b)).This again sounds a bit one-dimensional, but let's put that down as a case of copy/paste joy, and let's assume that the reader is able to extrapolate into two dimensions.
Does it sound familiar yet? Oh well, finally it says:
Alternatively, consider this a rectangle, where the rightmost pixel column and the bottommost pixel row are excludedOh. Sure, the concept of "rectangle" is so unfamiliar to programmers that it isn't worth mentioning except after some impressive-sounding mathematics jargon (that perhaps is not really useful in the case of finite, integer, ranges, but I digress). And yeah, let's mention pixels, too, all of a sudden. Of course, giving what apparently tries to be a strict mathematical definition, no need to mention whether the pixels here are centered on integer coordinates, or bounded by them. But I guess it's the former, as otherwise it would make little sense, or would it?
And what is right here, and especially, what is bottom? In mathematics, the y axis usually is depicted as pointing upwards, isn't it?
To make it even more fun, the data structure that this documents contains neither "range" or "rectangle" in its name, but "box"...