Search Results: "ed"

6 February 2014

John Goerzen: How to fix fstrim: Operation not supported under KVM?

Maybe someone out there will have some ideas. I have a KVM host running wheezy, with wheezy-backports versions of libvirt and qemu. I have defined a guest, properly set discard=unmap in the domain XML file for it, verified that s being passed to the guest, but TRIM/DISCARD is just not working. Mounting the ext4 filesystem with discard has no effect, and fstrim / always reports: fstrim: /: FITRIM ioctl failed: Operation not supported Every single time. I ve tried with the virtio, IDE, and SCSI (both default and virtio-scsi) backend drivers. The guest is also running wheezy (i386 version; the host is amd64) and I ve tried the latest 3.12 backported kernel for it. No dice. If I shut down the VM and mount the filesystem on the host, fstrim works fine. Everything says this should work. But it doesn t. Any ideas?

Neil Williams: iMX53 in the home lab

The iMX53 Quick Start Board has been a mainstay of the Debian armhf port and has been part of LAVA until recently. It s a natural choice for seeing how LAVA and Debian can work together more closely. So, in the first steps to getting my home lab running, I set about restoring two of these boards to LAVA support. I will be looking into each of the possible boot methods with these boards, but the way to start is with a LAVA master image on an SD card. With the pause in iMX53 development within LAVA, this raises a couple of issues: LAVA master image on iMX53 The LAVA master image is more recent and can fix these problems. See lava-image-creation preparing a master image
$ git clone git://git.linaro.org/lava/lava-master-image-scripts.git
$ cd lava-master-image-scripts

Use patch -p1 to apply this patch (apologies for the line wrapping in the blog):
diff --git a/lava-create-master b/lava-create-master
index 2e1d0e8..a1e6131 100755
--- a/lava-create-master
+++ b/lava-create-master
@@ -366,7 +366,7 @@ make_master()  
         verbose " * Building vanilla image with linaro-media-create..."
         if ! linaro-media-create \
             --dev $LMC_DEV \
-            --rootfs ext4 \
+            --rootfs ext3 \
             --image-file $CACHE_DIR/pristine-images/$dev-vanilla.img \
             --image-size 1G \
             --align-boot-part \
$ sudo ./lava-create-master imx53 Without the patch applied, I simply removed the SD card, mounted the third partition on my main machine and created a tarball of the contents:
$ sudo mount /dev/mmcblk0p3 /mnt/
$ pushd /mnt
$ sudo tar -czf /tmp/imx53-rootfs.tgz ./*
$ popd
$ sudo umount /mnt/
Reformat p3 to ext3 (or ext2 if you prefer)
$ sudo mkfs.ext3 /dev/mmcblk0p3
Put the rootfs back onto the replacement ext3 partition.
$ sudo mount /dev/mmcblk0p3 /mnt/
$ pushd /mnt
$ sudo tar -xzvf /tmp/imx53-rootfs.tgz
$ popd
$ sudo sync
$ sudo umount /mnt/
The bootscript is buggy, so run:
> run loaduimage
> run mmcboot
Then fix bootscript or you won t be able to reboot: Simplest way may be to set u-boot to ignore boot.scr
> setenv script
> saveenv
> reset
Device configuration in LAVA I found screen to be a bit awkward as a serial connection, (use Ctrl-A : quit) to quit. I tried autologin for the lucid image but that was not needed for the master image which uses the linaro overlay. The PDU commands are for my own setup. The daemon (the machine running the pdu daemon scripts), hostname (the hostname or IP of the PDU itself) and the port numbers will change between labs. Again, the blog has changed the line endings.
device_type = mx53loco
hostname = imx53-01
connection_command = telnet hobbes 4002
#login_prompt = lucid-desktop login:
#password_prompt = Password:
#username = lucid
#password = lucid
hard_reset_command = /usr/bin/pduclient --daemon localhost --hostname pdu --command reboot --port 05
power_off_cmd = /usr/bin/pduclient --daemon localhost --hostname pdu --command off --port 05
power_on_cmd = /usr/bin/pduclient --daemon localhost --hostname pdu --command on --port 05
testboot_offset = 3
Critical testboot_offset is currently undocumented. Without it, you will see:
 ** Partition 4 not valid on device 0 **
You can trace this back in a LAVA test log to:
  setenv bootcmd "fatload mmc 0:4 0x70000000 uImage; fatload mmc 0:4 0x72000000 uInitrd; fatload mmc 0:4 0x71ff0000 board.dtb; bootm 0x70000000 0x72000000 0x71ff0000"
The correct line needs to use mmc 0:5 in each case.
This is what testboot_offset modifies the default is 2.
  setenv bootcmd "fatload mmc 0:4 0x70000000 uImage; fatload mmc 0:5 0x72000000 uInitrd; fatload mmc 0:5 0x71ff0000 board.dtb; bootm 0x70000000 0x72000000 0x71ff0000"
Hacking session in LAVA A hacking session in LAVA is a way of getting an SSH login directly into a deployed test image, as root. It s a test image, so look around, trash stuff, build stuff, reboot the board When you are done, use stop-hacking and the test completes, leaving the master image unchanged, ready for the next rootfs to go onto the test image you were using. This will be improved in later blog entries but as a starter and so that you can play with the SATA drive with a recent installation, this is the JSON for a LAVA job which gives you an SSH session inside the LAVA test image on an iMX53. The test image comes from Linaro releases 12.01. I haven t set up a proxy yet, so to save time, I downloaded it once and used a local file:// URL in the testjob. Note the rootfstype parameter without this, LAVA will helpfully format the partition onto which the rootfs is installed to ext4, with predictable results. (This bug is currently being fixed in LAVA so that LAVA uses the same filesystem as the downloaded image. All part of making LAVA less presumptive.) The smoke-tests-basic testdef is gratuitous and can be removed but this particular run won t be quick it took over an hour to get into the hacking session, but future topics here will improve that so the extra few minutes for the smoke-tests is not a big win. Change the value for GATEWAY to something sane for your network, change the value for PUB_KEY to your SSH public key. Change the image location to something which works for your setup.
 
 "health_check": false,
 "job_name": "iMX53-hacking",
 "logging_level": "DEBUG",
 "device_type": "mx53loco",
 "timeout": 900,
 "actions": [
 
 "command": "deploy_linaro_image",
 "parameters": 
 "image": "file:///home/linaro/lava/mx53loco-ubuntu-desktop.img.gz",
 "rootfstype": "ext3"
 
 ,
 
 "command": "lava_test_shell",
 "parameters": 
 "testdef_repos": [
 
 "git-repo": "git://git.linaro.org/qa/test-definitions.git",
 "testdef": "ubuntu/smoke-tests-basic.yaml"
 ,
 
 "git-repo": "http://git.linaro.org/git/lava-team/hacking-session.git",
 "parameters": 
 "GATEWAY": "10.15.0.1",
 "PUB_KEY": "...."
 ,
 "testdef": "hacking-session-debian.yaml"
 
 ],
 "timeout": 18000
 
 ,
 
 "command": "submit_results_on_host",
 "parameters": 
 "server": "http://sylvester.codehelp/RPC2/",
 "stream": "/anonymous/codehelp/"
 
 
 ]
 
(Use http://jsonlint.com to reformat.) I was part of the way through running debootstrap on the SATA drive when ser2net timed out because I hadn t changed the values at that time. Configuring set2net for LAVA ser2net can run on any machine capable of providing the serial connections, including a dedicated device. Decide on a port range to use on the machine running ser2net. If the device has more than one network interface, ensure that ser2net only offers connections on the relevant interface by prefixing the port with the IP address or hostname. telnet is generally the easiest ser2net state to use with LAVA.
#  ::::
#     TCP port
#            Name   or  number of the TCP/IP port to accept con-
#            nections from for this device.  A port number may
#            be of the form [host,]port, such as 127.0.0.1,2000
#            or localhost,2000.  If this is specified, it will
#            only bind to the IP address specified. Otherwise
#            it will bind to all the ports on the machine.
# 10.15.0.1,4000:telnet:600:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner
Clear the timeout or long running jobs will fail.
10.15.0.1,4000:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner
10.15.0.1,4001:telnet:0:/dev/ttyUSB1:115200 8DATABITS NONE 1STOPBIT banner
I ve tried relatively carefully to preserve the instructions here from my notes. However, if you do try this yourself and there are problems, let me know and I ll update. I m also planning on putting all of the config files, patches, JSON examples and other code into a git repo fairly soon to make things easier.

Thorsten Glaser: KISS

Just saw this in my INBOX:

    B. The default init system for jessie will be a single /etc/rc script
 

I d certainly vote that


In unrelated news, jupp 2.8 for DOS runs on cable3, which means it ll still run on an original 8088/8086 Update 10.02.2014: The unobfuscated version of cable3 is called 8086tiny under the MIT licence. Thanks to the author for doing that (and not just dumping the IOCCC code) and to RT from the mksh(1) IRC channel for finding it on the net!

Johannes Schauer: botch updates

My last update about ongoing development of botch, the bootstrap/build ordering tool chain, was three months ago with the announcement of bootstrap.debian.net. Since then a number of things happened, so I thought an update was due.

New graphs for port metrics By default, a dependency graph is created by arbitrarily choosing an installation set for binary package installation or source package compilation. Installation set vertices and source vertices are connected according to this arbitrary selection. Niels Thykier approached me at Debconf13 about the possibility of using this graph to create a metric which would be able to tell for each source package, how many other source packages would become uncompilable or how many binary packages would become uninstallable, if that source package was removed from the archive. This could help deciding about the importance of packages. More about this can be found at the thread on debian-devel. For botch, this meant that two new graph graphs can now be generated. Instead of picking an arbitrary installation set for compiling a source package or installing a binary package, botch can now create a minimum graph which is created by letting dose3 calculate strong dependencies and a maximum graph by using the dependency closure.

Build profile syntax in dpkg With dpkg 1.17.2 we now have experimental build profile support in unstable. The syntax which ended up being added was:
Build-Depends: large (>= 1.0), small <!profile.stage1>
But until packages with that syntax can hit the archive, a few more tools need to understand the syntax. The patch we have for sbuild is very simple because sbuild relies on libdpkg for dependency parsing. We have a patch for apt too, but we have to rebase it for the current apt version and have to adapt it so that it works exactly like the functionality dpkg implements. But before we can do that we have to decide how to handle mixed positive and negative qualifiers or whether to remove this feature altogether because it causes too much confusion. The relevant thread on debian-dpkg starts here.

Update to latest dose3 git Botch heavily depends on libdose3 and unfortunately requires features which are only available in the current git HEAD. The latest version packaged in Debian is 3.1.3 from October 2012. Unfortunately the current dose3 git HEAD also relies on unreleased features from libcudf. On top of that, the GraphML output of the latest ocamlgraph version (1.8.3) is also broken and only fixed in the git. For now everything is set up as git submodules but this is the major blocker preventing any packaging of botch as a Debian package. Hopefully new releases will be done soon for all involved components.

Writing and reading GraphML Botch is a collection of several utilities which are connected together in a shell script. The advantage of this is, that one does not need to understand or hack the OCaml code to use botch for different purposes. In theory it also allows to insert 3rd party tools into a pipe to further modify the data. Until recently this ability was seriously hampered by the fact that many botch tools communicated with each other through marshaled OCaml binary files which prevent everything which is not written in OCaml from modifying them. The data that was passed around like this were the dependency graphs and I initially implemented it like that because I didnt want to write a GraphML parser. I now ended up writing an xmlm based GraphML parser so as of now, botch only reads and writes ASCII text files in XML (for the graphs) and in rfc822 packages format (for Packages and Sources files) which can both easily be modified by 3rd party tools. The ./tools directory contains many Python scripts using the networkx module to modify GraphML and the apt_pkg module to modify rfc822 files.

Splitting of tools To further increase the ability to modify program execution without having to know OCaml, I split up some big tools into multiple smaller ones. Some of the smaller tools are now even written in Python which is probably much more hackable for the general crowd. I converted those tools to Python which did not need any dose3 functionality and which were simple enough so that writing them didnt take much time. I could convert more tools but that might introduce bugs and takes time which I currently dont have much of (who does?).

Gzip instead of bz2 Since around January 14, snapshot.debian.org doesnt offer bzip2 compressed Packages and Sources files anymore but uses xz instead. This is awesome for must purposes but unfortunately I had to discover that there exist no OCaml bindings for libxz. Thus, botch is now using gzip instead of bz2 until either myself or anybody else finds some time to write a libxz OCaml binding.

Self hosting Fedora Paul Wise made me aware of Harald Hoyer's attempts to bootstrap Fedora. I reproduced his steps for the Debian dependency graph and it turns out that they are a little bit bigger. I'm exchanging emails with Harald Hoyer because it might not be too hard to use botch for rpm based distributions as well because dose3 supports rpm. The article also made me aware of the tred tool which is part of graphviz and allows to calculate the transitive reduction of a graph. This can help making horrible situations much better.

Dose3 bugs I planned to generate such simplified graphs for the neighborhood of each source package on bootstrap.debian.net but then binutils stopped building binutils-gold and instead provided binutils-gold while libc6-dev breaks binutils-gold (<< 2.20.1-11). This unfortunately triggered a dose3 bug and thus bootstrap.debian.net will not generate any new results until this is fixed in dose3. Another dose3 bug affects packages which Conflicts/Replaces/Provides:bar while bar is fully virtual and are Multi-Arch:same. Binaries of different architecture with this property can currently not be co-installed with dose3. Unfortunately linux-libc-dev has this property and thus botch cannot be used to analyze cross builds until that bug is fixed in dose3. I hope I get some free time soon to be able to look at these dose3 issues myself.

More documentation Since I started to like the current set of tools and how they work together I ended up writing over 2600 words of documentation in the past few days. You can start setting up and running botch by reading the first steps and get more detailed information by reading about the 28 tools that botch makes use of as of now. All existing articles, thesis and talks are linked from the wiki home.

Steve Kemp: External Comments, updated

The simple external-comments code is now complete enough for me to stop poking it on a daily basis: All in all I'm pretty happy with the way it works, and the server-code. The client-side Javascript is less good, but I'm probably done poking that too. In an ideal world the client-side code should be a jQuery plugin, but I've not worked out how to make a static method (the JSONP callback) be a member of a jQuery plugin-object. So without that I have to re-pass the options around too many places, rather than making them a member of "this". Meh, pull requests welcome for adding new storage back-ends (redis and sqlite are supported by default), and similarly for cleanups. Links:

Tim Retout: FOSDEM 2014

I attended FOSDEM this year. As always, it was very busy, and the Brussels transport system was as confusing as ever. This time it was nice to accidentally bump into so many people I know from years past. Lunar's talk on reproducible builds of Debian packages was interesting - being able to independently verify that a particular binary package was built from a particular source package is quite attractive. Also Mailpile declared an alpha release. The bit in the talk that I didn't know already was the description of exactly how the search function works. Seeing how they integrate GPG into the contacts/compose features brought home how lacking most (all?) other mail clients are when it comes to usable encryption. On Sunday afternoon I managed to grab a seat in the Go devroom, to hear about crazy things like how YouTube are putting a daemon called Vitess in front of MySQL to abstract away sharding (at the cost of some transaction guarantees). You would have thought Google would already have a scalable data store of some sort? Other bits I remember: Michael Meeks talking about GPU-enabling spreadsheet formulae calculations. And hearing Wietse Venema talk about Postfix was pretty awesome.

Russ Allbery: New init system feature!

The Debian Technical Committee has concluded that all of the available init systems were missing a key technical feature, and, in the spirit of free software, has gone ahead and fixed that lack. All init systems currently packaged for Debian can now double as test case generators for Condorcet vote analysis. I'm not sure if this counts as an NMU. In the event that the Debian project votes on a General Resolution on the default init system, this blog post should be considered striken in its entirety and replaced by the most complex email message from Anthony Towns that the reader can find.

Andrew Pollock: [life] Day 10, Playgroup again

I was bracing myself for a rough night, but Zoe slept through until almost 6am. Today was playgroup again, so we just took a slow start to the day and headed out on the bike a bit after 9am. There was a mix of new faces and people from last week. I packed a lunchbox this time instead of relying on the snack collection in my "Dad Bag" backpack. We worked on trying to approach other girls to get them to play. Unfortunately they're all that little bit younger and more shy, so we haven't had a huge success. Zoe's been pretty happy just playing with the various toys and playing with me. Parachute time was a big hit again. I think there were about 25 adults there (I was the only Dad this week), with many with multiple children. The youngest baby I saw was a 7 week old. Zoe had been asking me what a honeydew was, so after Playgroup we dropped by the Hawthorne Garage and grabbed half a honeydew and a couple of tomatoes and I made some fritters for lunch with leftover corned beef from dinner the other night. Zoe wasn't too impressed with them. I think she didn't like the diced tomato. She declared that the honeydew was just like rockmelon. We read a story in the hammock and she went down pretty easily for nap after that. I'd just started doing the dishes when my mate Steve gave me a call. He was in the area, and he dropped in. That worked out well, because I'd been meaning to pick his brain about my little electronics project. We geeked it up for a bit. Zoe's mini lab coat arrived in the mail, and when she finally woke up after 3pm, I asked her if she wanted to go out to Bunnings to get a pair of kids-sized safety glasses, but she said she wanted to do something "fun" instead. When I asked her what she wanted to do, she initially wanted to go to Wet and Wild, but that's an all day outing and we're going next Wednesday, so she settled on going to Colmslie pool again instead. So we quickly got organised and jumped on the bike and biked over to the pool. We started out in the kid's play area, which had a couple of small slides and some fountains and whatnot, and then we gravitated over to the 50 metre pool, where Zoe practised her diving for a bit and generally quite confidently navigated the 1.5m deep end of the pool. It was good, because at least I could just stand up instead of tread water while she practised diving in off the blocks. We had a post-swim ice cream and biked home, and then I whipped up dinner and it was bathtime and bedtime. I'm going to have to start tracking my weekly kilometres with Zoe on the bike, because I think it'll be a reasonable distance.

5 February 2014

Andrew Shadura: Clearlooks-Ph nix update

Once upon a time, GTK+ 3.0 was released. That release brought at least one Bad Thing : incompatibility with GTK+ 2.x themes. At the same time, previously popular Clearlooks theme hasn t been ported. Many people didn t like that, but only one decided to DTRT to do the Right Thing. Jean-Philippe Fleury wrote Clearlooks-Ph nix (originally, Clearwaita), a GTK+ 3 theme which was supposed to have a look and feel as close as possible to the original Clearlooks. He based his work on an engine of a new GTK+ default, Adwaita theme. Quite soon, however, GTK+ 3 theme API has changed, and it became easily possible to rewrite the theme without using any additional theming engines, with just plain GTK+ stuff involved. Then GTK+ 3.6 came and broke the API once more. Jean-Philippe fixed stuff to work with newer GTK+ again, and everyone was happy again. But Empire striked back: GTK+ 3.8 brought more disruptive changes, rendering menus as ugly as never before. Unfortunately, Jean-Philippe was unable to cope with changes alone, he set up a mailing list to collectively develop Clearlooks-Ph nix, but that didn t help, and no fix has been released during more than half a year. As a maintainer and a user of Clearlooks-Ph nix, I had to do something with this, as more and more things needed recent GTK+ 3 to work. After spending some time studying CSS code and playing with its knobs, I found a solution which proved to be quite simple, and uploaded an updated package. Unfortunately, the changes aren t in the upstream package yet. Now, with GTK+ 3.10, stuff is not quite working again. Some changes in GTK+ internals lead to menu bars not being coloured properly. At the moment of this writing, an updated package is already available in unstable.

Daniel Pocock: Debian SIP without reading the manual

Most people don't have time to read manuals. The Debian SIP service has a reasonably thorough user guide with screenshots but some people may just want to have this level of detail if they really have to troubleshoot a problem. WebRTC is the fastest way to start Just set up your db.debian.org RTC password and use it to log in to the https://rtc.debian.org site. It all runs in the browser, no plugin or configuration required. Firewall/NAT trouble The current range of WebRTC browsers seem to work well for consumer and small office networks with NAT routers or mobile/cell networks. Corporate networks with an outright block on UDP will be supported soon. Supported browsers The Chromium 31 package on wheezy appears to work fine and was used in some of the demos at DebConf13 For Iceweasel/Firefox users, it is not possible to use the version 17 package from wheezy at all. At the time of writing, Iceweasel 24 is in jessie and sid while version 27 is available upstream. Mozilla gradually introduced WebRTC support on both desktop and Android between versions 20 to 24 and it is still evolving. If you don't want to use Chromium and don't want to upgrade your desktop/laptop beyond wheezy, consider trying Firefox on an Android device. Your friends can call you too There is no excuse for them to pester you with proprietary solutions any more. They can dial your debian.org SIP address from https://freephonebox.net. You can even link to it from your web site or blog by adding the dial parameter to the URL, like https://freephonebox.net?dial=pocock%40debian.org Please complain Bug reports and questions are always welcome. A good place for questions or complaints where the cause of the bug is not obvious is the Free-RTC mailing list.

Thomas Koch: shared infrastructure coop

I'm working in a very small web agency with 4 employees, one of them part time and our boss who doesn't do programming. It shouldn't come as a surprise, that our development infrastructure is not perfect. We have many ideas and dreams how we could improve it, but not the time.
Now we have two obvious choices: Either we just do nothing or we buy services from specialized vendors like github, atlassian, travis-ci, heroku, google and others.
Doing nothing does not work for me. But just buying all this stuff doesn't please me either. We'd depend on proprietary software, lock-in effects or one-size-fits-all offerings.
Another option would be to find other small web shops like us, form a cooperative and share essential services. There are thousands of web shops in the same situation like us and we all need the same things: As I said, all of the above is available as commercial offerings. But I'd prefer the following to be satisfied:
Does something like that already exists? There already is the German cooperative hostsharing which is kind of similar but does provide mainly hosting, not services. But I'll ask them next after writing this blog post.
Is your company interested in joining such an effort? Does it sound silly?




Wouter Verhelst: "Nuclear precision weapons"

Now that the madness is mostly over, I have some time to catch up on reading my newspaper. Last week, one article in De Standaard talks about the nuclear weapons on Belgian soil which officially didn't exist (until wikileaks proved otherwise) and which are now apparently going to be modernized. The newer model would be "nuclear precision weapons". Ignoring the question of whether today's world still requires nuclear bombs (this may or may not be true, I don't care), I question the logic which leads to that phrase. A nuclear weapon is a weapon of mass destruction. By definition, a weapon of mass destruction causes collateral damage. By definition, a precision weapon is a weapon that does not cause collateral damage or, at the very lease, where every effort is made to limit the amount of collateral damage. Even the very first nuclear bombs were capable of destroying entire cities. Today's nuclear weapons, even the smaller ones, are far more powerful than those. Don't get me wrong: I'm not a peace activist. In fact, I have been contracted by companies who produce military equipment, and don't feel bad about that. But to claim that it is possible to create "nuclear precision weapons" is to deceive oneself. A nuclear weapon is not very precise.

Sune Vuorela: CMake skeleton for small Qt projects

For small Qt-projects, I have for a long time been using qmake, mostly because qmake -project gives me a working build in most cases, but once the project grows a bit, I have switched to cmake because there is just things there I like better. So, I thought how to start with cmake instead, and ended up writing a small script. I guess I should share it:
#! /bin/sh # Simple script that generates a cmake project file for a Qt project #
# Copyright (c) 2013 Sune Vuorela
#
# Permission is hereby granted, free of charge, to any person
# obtaining a copy of this software and associated documentation
# files (the Software ), to deal in the Software without
# restriction, including without limitation the rights to use,
# copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following
# conditions:
#
# The above copyright notice and this permission notice shall be
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED AS IS , WITHOUT WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
# OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
# OTHER DEALINGS IN THE SOFTWARE.
# CPPFILES= $(ls *.cpp 2>/dev/null) UIFILES= $(ls *.ui 2>/dev/null) QRCFILES= $(ls *.qrc 2>/dev/null) NAME= $(basename $(pwd)) error()
echo ERROR: $@
exit 1
debug()
[ -z "$ DEBUG " ] && return
echo DEBUG: $@ 1>&2
# sanity checks if [ -e "CMakeLists.txt" ]
then
error CMakeLists.txt found. Doing nothing.
fi if [ -z "$ CPPFILES " ]
then
error No cpp files found
fi debug NAME $ NAME
debug CPPFILES $ CPPFILES
debug UIFILES $ UIFILES
debug QRCFILES $ QRCFILES # First part of cmake files
cat >> CMakeLists.txt << __EOHEADER__
project($ NAME ) cmake_minimum_required(VERSION 2.8.11) find_package(Qt5 CONFIG REQUIRED Widgets) set(CMAKE_AUTOMOC ON)
set(CMAKE_INCLUDE_CURRENT_DIR ON) __EOHEADER__ # Handle ui files if any
if [ -n "$ UIFILES " ]
then
cat >> CMakeLists.txt << __EOUI__
set($ NAME _ui $ UIFILES )
qt5_wrap_ui($ NAME _wrapped_ui \$ $ NAME _ui ) __EOUI__ UIWRAPPED="\$ $ NAME _wrapped_ui "
debug prepared UIWRAPPED $ UIWRAPPED
fi # Handle qrc files if any
if [ -n "$ QRCFILES " ]
then cat >> CMakeLists.txt << __EOQRC__
set($ NAME _qrc $ QRCFILES )
qt5_add_resources($ NAME _wrapped_qrc \$ $ NAME _qrc ) __EOQRC__ QRCWRAPPED="\$ $ NAME _wrapped_qrc "
debug prepared QRCWRAPPED $ QRCWRAPPED
fi # Build the actual library
cat >> CMakeLists.txt << __EOCPP__
set($ NAME _src $ CPPFILES ) add_executable($ NAME \$ $ NAME _src $ UIWRAPPED $ QRCWRAPPED ) target_link_libraries($ NAME Qt5::Widgets )
__EOCPP__
I ve saved it locally as cmake-qtproject and it works with at least cmake 2.8.11. I hope wordpress doesn t make too much mess of it. Have fun.

Ricardo Mones: Fixing partridge eggs with industrial duct tape

Human nature is hard to change. Very hard. We can talk about it for ages, but mistakes repeat again and again. In the end it's mostly by mistakes how we learn, so I doubt this could ever be changed without losing our own nature. One of these is trying to fix some social issue with a technical measure. Unfortunately, given the technical orientation of most of the developers, this appears from time to time in our Debian private mailing list, and yesterday I realized it's our own version of Godwin's law:

As a social problem discussion grows longer in debian-private the probability of some developer proposing a technical solution aproaches one.

Not discussing about this problems in debian-private would be a good start, but of course that would only change the name of the list in the above sentence ;-).

Andrew Pollock: [life] Day 9, Kindergarten and cleaning

Another busy day today. I saw my girlfriend off in the morning, and then got stuck into cleaning the bathrooms. I ducked out to Jaycar to have another attempt at getting components. Got home, did some more cleaning, and had my chiropractic adjustment. Then I had my exit interview for work via video conference, and did some administrivia while I still had my work computer. Then the guy from Pack & Send came to take all the work equipment away. Now I feel very disconnected. Had some lunch, did more cleaning. Mum and Dad came around to go with me for pick up today, so they could see the new Kindergarten. Zoe was again fast asleep at pick up, and the kids who were awake were all in the other room eating birthday cake, so we let Zoe wake up as gently as possible and then collected Megan and squeezed everyone into the car and headed home. Zoe and Megan had a great time playing with each other again, and Megan's Dad picked her up at about 4:30pm and I started on dinner. We all had dinner and then Mum and Dad headed off, and I gave Zoe a bath and put her to bed. She was a bit emotional at bedtime, so it took a while to get her settled. Here's hoping she sleeps okay tonight.

4 February 2014

Enrico Zini: debops

Debops What I like the most about being a Developer is building tools to (hopefully) make someone's life better. I like it when my software gets used, and people thank me for it, because there was a need they had that wasn't met before, and thanks to my software now it is being met. I am maintaining software for meteorological research that is soon going to be 10 years old, and is still evolving and getting Real Work done. I like to develop software as if it is going to become a part of human cultural heritage, developing beyond my capacity, eventually surviving me, allowing society to declare that the need, small as it was, is now met, and move on to worry about some other problem. I feel that if I'm not thinking of my software in that way, then I am not being serious. Then I am not developing something fit for other people to use and rely on. This involves Development as much as it involves Operations: tracking security updates for all the components that make up a system. Testing. Quality assurance. Scalability. Stability. Hardening. Monitoring. Maintenance requirements. Deployment and upgrade workflows. Security. I came to learn that the requirements put forward by sysadmins are to be taken seriously, because they are the ones whose phone will ring in the middle of the night when your software breaks. I am also involved in more than one software project. I am responsible for about a dozen web applications deployed out there in the wild, and possibly another dozen of non-web projects, from terabyte-sized specialised archival tools to little utilities that are essential links in someone's complex toolchain. I build my software targeting Debian Stable + Backports. At FOSDEM I noticed that some people consider it uncool. I was perplexed. It provides me with a vast and reasonably recent set of parts to use to build my systems. It provides me with a single bug tracking system for all of them, and tools to track known issues in the systems I deployed. It provides me with a stable platform, with a well documented upgrade path to the next version. It gives me a release rhythm that allows me to enjoy the sweet hum of spinning fans thinking about my next mischief, instead of spending my waking time chasing configuration file changes and API changes deep down in my dependency chain. It allows me to rely on Debian for security updates, so I don't have to track upstream activity for each one of the building blocks of the systems I deploy. It allows me not to worry about a lot of obscure domain specific integration issues. Coinstallability of libraries with different ABI versions. Flawless support for different versions of Python, or Lua, or for different versions of C++ compilers. It has often happened to me to hear someone rant about a frustrating situation, wonder how come it had never happened to me, and realise that someone in Debian, who happens to be more expert than I can possibly be, had thought hard about how to deal with that issue, years before. I know I cannot be an expert of the entire stack from bare iron all the way up, and I have learnt to stand on the shoulders of giants. 'Devops' makes sense for me in that it hints at this cooperation between developers and operators, having constructive communication, knowing that each side has their own needs, trying their best to meet them all. It hints at a perfect world where developers and operators finally come to understand and trust each other's judgement. I don't know that perfect world, but I, a developer, do like to try to understand and trust the judgement of sysadmins. I sympathise with my sysadmin friends who feel that devops is turning into a trend of developers thinking they can do without sysadmins. Reinventing package managers. Bundling dependencies. Building "apps" instead of components. I wish that people who deploy a system built on such premises, have it become so successful that they end up being paid to maintain them for their whole career. That is certainly what I wish and strive for, for me and my own projects. In my experience, a sustainable and maintainable system won't come out of the startup mindset of building something quick&dirty, then sell it and move on to something else. In my experience, the basis for having sustainable and maintainable systems have been well known and tested in Debian, and several other distributions, for over two decades. At FOSDEM, we thought that we need a name for such a mindset. Between beers, that name came to be "debops". (It's not just Debian, though: many other distributions get it right, too)

Mart&iacute;n Ferrari: Telegram

This weekend I attended FOSDEM, as I did for the past 4 years. As always, it was a great experience, even if most of the talks I attended were not so interesting. One of the great things about these events, is to get together with other Free Software enthusiasts. One of them introduced me to the new kid on the block: Telegram. It is advertised as a free and secure replacement for WhatsApp, a mobile application I have been refusing to use for months, much to the anger of friends and family. People use WhatsApp because it saves them money to send SMS-like messages to other people. Which in my mind does not make much sense, as I can use email or XMPP for that same purpose, without having to enter just another walled garden. Sadly, people nowadays are using email less and less, and think that it is easier to send a Facebook message (it is not), and XMPP has became a de-facto walled garden since Google betrayed its users by dropping federation. WhatsApp has the advantage of having millions of users already inside their walled garden, like it happened with Facebook, MSN, or ICQ back in the day. Their success can possibly be attributed to the foolproof system it uses to discover contacts: it just sends your entire address book to their servers for matching against already registered users, which is in itself enough reason not to use it. So, when I was told of a secure, free and open alternative, I was eager to try it out. I started by opening their website to see what it was about. There, I found the first signs that something was wrong: no mention of licenses, almost no technical detail of how the protocol works, or how security is achieved. Still, my friend wanted to talk to me, so I rushed to install it and accept a laundry list of permissions in Android. That was a big mistake. The first thing the application did was to check my address book for contacts, without my permission or knowledge. I got greeted by being told that some of my contacts already have Telegram installed, and since then I keep getting notification that some more of my geek friends are installing it. So it is obvious that this company got all my records, breaking my privacy and security. This is enough for me to remove this piece of software from my phone, but it is not the end of the story. When checking it in more detail I found several other problems. The supposed "secret chat" cannot be possibly secure, as there is no verification of the remote party. It "just works", who cares if there is a man in the middle or not. Supposedly it employs a peer-to-peer connection, but I haven't verified that. On the other hand, the non-"secret" conversations are all routed to the main server. The client-to-server communication is supposedly encrypted, but it uses a home-made protocol (which everybody knows is a recipe for disaster), and the server has access to the cleartext of all your communications. Then, browsing the website, I've found that this "open" and "free" offer does not even have all the source code released. In particular, the server code is not public, nor you can set up your own server. Of course, it does not have federation, so even with the server code you wouldn't be able to talk with your friends. It all depends on two men funding and maintaining the project, so when the funds run out, one can only expect that all the users will be left in the dark. I think these arguments are enough to realise that Telegram is only marginally better than WhatsApp. It offers encryption at the transport layer, but you still are contributing to another walled garden, you are at the mercy of a company which does not have a funding plan, and the security practises range from weak to disturbing. In closing, if you are going to compromise your privacy, give away all your contacts' information, and rely on a single company to keep in touch with people, you might as well go and use what everybody else is using. Update: Even before submitting this post, I've found that some more qualified people has already dissected Telegram and concluded that it is basically snake oil. Please see this article. and proceed to uninstall Telegram.

Russell Coker: Clothing and Phone Cameras

In 2012 I wrote about my jeans from Rivers that fit the largest available phones (and the smaller tablets) in their pockets [1]. Those jeans are still working well for me, I can add the fact that they don t wear out quickly to the list of positive attributes. Recently my sister asked for advice on getting a new phone, she was considering the Samsung Galaxy Note 2 (the phone I m using now) because it apparently takes better pictures than the Nexus 4 she s using. I ve used both those phones and I hadn t noticed a difference in picture quality, but there is some variation in manufacturing and it could be that I ve got a below average Note 2 and a better than average Nexus 4 so I ll assume for the sake of discussion that my sister would actually get an improvement in picture quality by using a Note 2. If you have a phone that doesn t have the picture quality you desire then one option is to buy a phone with a better camera, but you will be limited by issues of physics. A thin phone has a short focal length which means that the lens has to be small and therefore the amount of light that gets to the sensor is small. The Nokia Lumia 1020 has some of the best camera hardware that you ll find in a phone, but it s still only 14.5mm thick where the camera is and that will limit the quality a lot. Any compact camera should be able to beat all phone cameras in terms of picture quality in most areas. The Samsung Galaxy Camera [2] is also worth considering, it has more features than a typical compact camera and good GUI that allows novice photographers to take advantage of it. Also being able to blog your photos directly from the camera could be a useful feature. But the big down-side of a compact camera is that it s not that compact. Most people won t find it convenient to carry a compact camera with them at all times and therefore they might miss a good opportunity to take a photo. The Galaxy Note series of phones also suffer in this regard because they are larger than most phones. If your phone won t fit in your pocket and you have it in your backpack when on the move or on a bench at home then you will probably miss some good photos. As I was at a Rivers store recently I tested my Note 2 in the pockets of women s jeans. Rivers scored very poorly in this regard, one pair of women s jeans had fake pockets (this is just wrong for working clothes) and of the rest only one pair could fit a Note 2. The pair that fit a Note 2 didn t completely enclose the phone, one corner was sticking out, this would probably give a risk of having the phone fall out of the pocket and cause some discomfort to the wearer. I have a pair of shorts with similar size pockets and find it very annoying with the Note 2 in the pocket (for about 10 months of the year I wear jeans so this isn t a big deal). Rivers jeans only count as geeky jeans for male geeks. It s disappointing that with about a dozen different styles of women s jeans there didn t seem to be a single one with pockets of comparable size to the men s jeans. I had to recommend that my sister not get a phone from the Galaxy Note series if taking pictures is a priority due to the apparent difficulty in getting it to fit in a pocket and the probability that she would miss good photos due to this. In past discussions of phone size there have been mentions of the possibility of getting clothing altered. Does anyone have a good experience in getting clothes altered to have bigger pockets or in the case of women s clothing to have fake pockets replaced with real ones?

Andrew Pollock: [life] Day 8, another Kindergarten day

Yesterday was pretty crazy busy. I woke up a little bit late because I didn't have Zoe, and decided to head down to Jaycar to grab some components and other bits and pieces for my little spontaneous electronics project. I got home from Jaycar and fiddled around for a bit, and then biked down to Bulimba to get a ferry across to a bus so I could get into the city for lunch with my accountant. I ate my fill of sashimi while discussing the best corporate structure for my endeavours this year. Lunch ran a bit long, and it was going to be tight trying to bus it back to the ferry to retrieve my bike, so I decided to cab it back to Bulimba. I retrieved my bike and raced home and jumped in the car. It was just going to be too tight to bike over there. It probably worked out for the best, because I got to the Kindergarten and Zoe was fast asleep still. She took quite a lot of effort to wake. I think they'd only got her down for a nap not long before. I eventually roused her, but she was very groggy and a little bit sad about the whole thing. I think she would have been a sad panda if she'd had to then get on the bike. I asked her if she wanted to make some play dough or go swimming when we got home, and she chose swimming. I asked her if she wanted to bike or drive, and she wanted to drive. We took the new pool noodle that I picked up the other week and headed down to Colmslie Pool The pool was pretty busy with a lot of after school swim squads, but there was still enough room for Zoe to play around. Her sinkies were very popular and were "borrowed" extensively, and she really enjoyed riding the pool noodle like a horse. We got home and Sarah was waiting to pick up Zoe and I headed off for a massage, and then my girlfriend came over for dinner.

Diego Escalante Urrelo: Booting Fedora 20 from USB on a black MacBook3,1 (2007)

Here s a trick that is so obvious, I m still hitting my head against the desk. Let s say you want to install an EFI-friendly distribution on your MacBook. However, your MacBook does not detect bootable USB drives on startup (known bug on old Apple hardware). I found a blog post that had success rebuilding the ISO without EFI support and installing in BIOS mode, but I had a clear memory of getting this to work a few months ago without doing that. I just couldn t remember how. Well, turns out that OSX can boot from USB drives as long as you tell it to do so in advance. You can do this in the Boot disk/Startup disk panel in System Settings:
Startup disks panel in OSX
You don t see me complaining that everything on the web is in English, do you?
You only need to select the drive and close the panel, or reboot directly using that handy Reboot button. So considerate of Apple. Important: After you install, or try, your EFI friendly live USB you have to go back to the panel and select your OSX drive again, otherwise your MacBook will keep waiting for the (now gone) USB drive for about 30 seconds on startup. For Debian, the last few times I have just booted with a CD in BIOS mode without problems. After the installation you can configure Debian for EFI boot following this instructions. I haven t tried any other distribution on this machine.

Next.

Previous.