It s been two years since my latest blog post about my Linux desktop and many things have changed since then. I completely moved all my machines to GNOME 3, switched my main editor from nano to vim and my terminal multiplexer from screen to tmux. What didn t change at all except for a tweaks on the theme is my Irssi setup. Switching from nano to vim has been a pain at first, nano is really a straightforward editor, it does what you actually need from a CLI editor but while it works just fine when modifying configuration or text files, it s a bit limiting when it comes to programming. Vim on the other hand is highly customizable in every single part also thanks to its huge amount of plugins. Honestly I admit I spent several hours watching videos, reading documentation, trying out key bindings and I m not completely used to vim to be as much productive I would like to be with it. What I found to be the common error of vim s newcomers is their willingness to look around the web for a complete vimrc configuration file, full of key bindings, custom settings and personalizations. That s definitely something you should avoid when learning to use vim, the perfect vimrc doesn t objectively exist, each of us should spend some time investigating what is the best configuration for your needs and build a vimrc accordingly time by time. It will probably take months to have a complex vimrc file matching your needs completely, until then you won t be able to define your vimrc to be ultimate . And that s actually why wgetting someone else s vimrc and copying it to your home folder won t make you an expert of vim, it ll probably make your life harder when trying a specific action with the stock settings will result in something you wouldn t have expected thanks to a particular key binding on the vimrc you downloaded. The other tool that definitely improved my productivity is Tmux given the huge amount of open terminals I had every day during my sysadmin s duties at GNOME. Each day usually started with one or two open terminals mainly meant for random maintenance issues, after a few hours the amount of open terminals jumped to around 30. Switching between tabs became a pain and the usual amount of time spent finding out which terminal had the the specific remote connection I needed was surprisingly sticking around 10 seconds. I looked around for a possible solution and found Tmux, it has been a joy finding out how easy it was to set it up and get used to it. I m now able to divide my 27 inches monitor into several panels and switch between them with a little keybinding, in addition you can set up as many windows (and consequently as many panels) as you wish, that way I can divide my programming windows from the ones specifically meant as remote consoles. From there I can detach / attach my previous Tmux session with one command and keep working on the same files and connections I had open the last time I used Tmux. In addition to the above tools I ve kept being an huge fan of Irssi and some of its plugins that have improved my overall productivity when daily chatting with Fedora, Debian and GNOME contributors. What actually changed on it since two years ago is the theme which is currently a mix between the Solarized and the XChat themes. Please don t hesitate to ask me any question if you are curious about learning something more about my current working setup! :-)

NSCA is a tool used to submit passive check results to nagios. Unfortunately, an incompatibility was recently introduced between wheezy clients and old servers. Since I don't want to upgrade my server, this caused some problems and I decided to just get rid of NSCA completely. The server side of NSCA is pretty trivial, it basically just adds a timestamp and a command name to the data sent by the client, then changes tabs into semicolons and stuffs all of that down Nagios' command pipe. The script I came up with was:

#! /usr/bin/python
# -* coding: utf-8 -*-
import time
import sys
# format is:
# [TIMESTAMP] COMMAND_NAME;argument1;argument2; ;argumentN
#
# For passive checks, we want PROCESS_SERVICE_CHECK_RESULT with the
# format:
#
# PROCESS_SERVICE_CHECK_RESULT;<host_name>;<service_description>;<return_code>;<plugin_output>
#
# return code is 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN
#
# Read lines from stdin with the format:
# $HOSTNAME\t$SERVICE_NAME\t$RETURN_CODE\t$TEXT_OUTPUT
if len(sys.argv) != 2:
    print "Usage:  0  HOSTNAME".format(sys.argv[0])
    sys.exit(1)
HOSTNAME = sys.argv[1]
timestamp = int(time.time())
nagios_cmd = file("/var/lib/nagios3/rw/nagios.cmd", "w")
for line in sys.stdin:
    (_, service, return_code, text) = line.split("\t", 3)
    nagios_cmd.write(u"[ timestamp ] PROCESS_SERVICE_CHECK_RESULT; hostname ; service ; return_code ; text \n".format
                     (timestamp = timestamp,
                      hostname = HOSTNAME,
                      service = service,
                      return_code = return_code,
                      text = text))

The reason for the hostname in the line (even though it's overridden) is to be compatible with send_nsca's input format. Machines submit check results over SSH using its excellent ForceCommand capabilities, the Chef template for the authorized_keys file looks like:

<% for host in @nodes %>
command="/usr/local/lib/nagios/nagios-passive-check-result <%= host[:hostname] %>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa <%= host[:keys][:ssh][:host_rsa_public] %> <%= host[:hostname] %>
<% end %>

The actual chef recipe looks like:

nodes = []
search(:node, "*:*") do  n 
  # Ignore not-yet-configured nodes                                                                       
  next unless n[:hostname]
  next unless n[:nagios]
  next if n[:nagios].has_key?(:ignore)
  nodes << n
end
nodes.sort!    a,b  a[:hostname] <=> b[:hostname]  
print nodes
template "/etc/ssh/userkeys/nagios" do
  source "authorized_keys.erb"
  mode 0400
  variables( 
              :nodes => nodes
             )
end
cookbook_file "/usr/local/lib/nagios/nagios-passive-check-result" do
  mode 0555
end
user "nagios" do
  action :manage
  shell "/bin/sh"
end

To submit a check, hosts do:

printf "$HOSTNAME\t$SERVICE_NAME\t$RET\t$TEXT\n"   ssh -i /etc/ssh/ssh_host_rsa_key -o BatchMode=yes -o StrictHostKeyChecking=no -T nagios@$NAGIOS_SERVER

Review: The Odd Clauses, by Jay Wexler

Publisher:	Beacon
Copyright:	2011
ISBN:	0-8070-0089-2
Format:	Trade paperback
Pages:	193

The subtitle of this book summarizes it nicely: Understanding the Constitution through Ten of Its Most Curious Provisions. (The constitution in question is the United States Constitution.) It's a sort of popularization of US constitutional law, but rather than look at the most well-known and controversial parts, it takes a look at some of the odd side points, obscure clauses, or clauses that one rarely thinks about because they rarely appear in the news. This is partly a tour of curiosity aimed at those who like legal trivia, but it also provides, indirectly, a look at how constitutional law is made and debated, and at some of the burning concerns at the time of the writing that have since faded away. Sometimes why the concern has faded is as interesting as the original problem. This is the sort of book whose table of contents provides a lot of insight into what you're getting. It has ten chapters, each devoted to a particular clause or amendment: incompatibility, weights and measures, recess appointments (one of the rare ones that has made the news), original jurisdiction, natural-born citizen (odd, but sadly now not at all obscure), letters of marque and reprisal, titles of nobility, bills of attainder, and the 3rd and 21st amendments. (For those who haven't memorized all the amendments to the US Constitution, the 3rd is the prohibition on quartering soldiers in private homes and the 21st is Prohibition, which here is examined not for its core intent but for the implications for federalism.) As you can see, this is quite a selection, and while the clauses are often obscure, the issues raised by them are still generally quite active. There are some that were intensely controversial at the time of the original debate that are little more than amusing trivia at this point (the prohibition on officers of the United States taking titles of nobility), or have become so much a part of the structure of the government that people rarely given them a second thought (such as the incompatibility clause, which prohibits members of Congress from holding positions in the executive branch). But most of these clauses establish ground rules for the US government that are still quite current today, even if the legal terminology used at the time is no longer familiar. A good example is the clause prohibiting bills of attainder, something that the writers of the US Constitution saw no need to define. A bill of attainder is an act of a legislature declaring a person guilty of a crime and assigning some punishment without trial. Framed that way, it seems like an obvious extension of the separation of powers system that the US government is constructed around, but unlikely to provoke much modern controversy. However, as Wexler explains quite lucidly, there's a reason why this clause is right next to the prohibition on ex post facto laws. While no one would stand for the US Congress declaring guilt on a matter of criminal law, it has written some startlingly specific laws that seem aimed solely at specific individuals or organizations, which is exactly the sort of behavior that this prohibition, interpreted broadly, was intended to prevent. Similarly, one might think that Congress's power to issue letters of marque and reprisal is little more than ground for an interesting history lesson. But that clause is deeply entangled with the checkered history of US declarations of war and controversies over Congressional oversight, and Wexler uses it as a jumping-off point to take a look at the implications for the modern habit of undeclared wars fought by military contractors. This is a short book, so these treatments are necessarily brief. Some of them are also fairly minor; for example, the discussion of the weights and measures clause is mostly an extended rant on the US refusal to adopt the metric system. That's a sentiment with which I entirely agree, but I'm not sure it has much to do with constitutional law. But Wexler is an entertaining and concise writer; even when the discussion is relatively shallow, I enjoyed reading his analysis. (I will warn, though, that he takes a few potshots from a liberal perspective, so one's enjoyment of his humor may to some extent depend on your personal political allegiances.) I wouldn't rush out to find this book, but I found it mildly diverting and occasionally quite informative. The chapter on original jurisdiction, for instance, explained how the Supreme Court handles certain classes of cases that must be filed directly with it, despite not being a trial court. This was a question that I didn't even know I had, and a side system of judicial procedure that turned out to be surprisingly interesting. I suspect The Odd Clauses will be the most interesting to people who have only a news media understanding of the US Constitution. I went through a personal libertarian period, during which I read the constitution in detail and sought out some discussions of its specifics, so quite a bit of this book was familiar ground to me. Others without that study background may find more novelty. But even with that background, I was entertained, and don't regret buying it. One note, though: I bought this book on the recommendation of Kevin Underhill, author Lowering the Bar, which is a masterpiece of dry humor. If you're looking for legal humor, parts of The Odd Clauses are mildly funny, but Lowering the Bar is the sort of site that will have you staying up late reading just one more page of archives and reading bits aloud to anyone nearby. Rating: 7 out of 10

One of the goals of our work at Nebula is making it as easy as possible for someone to set up a private cloud. In an ideal world that would involve being able to just plug in the controller hardware, wire up a rack of servers and turn everything on, but right now there are cases where the default firmware configuration on the servers doesn't match our desired configuration. Plugging a console into individual servers just to set some BIOS options is (based on personal experience) about as much fun as writing a doctoral thesis on the experience of watching paint dry, so it seemed worth trying to find a way to avoid people having to deal with that. Thankfully, it turns out that the industry has come to a similar set of conclusions. Recent Dell hardware lets you use WS-MAN, which makes it easy to do things like enable security features as long as you have an authenticated connection to the iDRAC management system. This actually works out wonderfully - the first time a Dell node sends a PXE request to the Cloud Controller, it can push back some configuration changes, reboot the system and then boot it in a known good configuration. Thanks, Dell![1].

HP's slightly trickier. As far as I've been able to work out, the remotely-available programmatic interfaces only provide configuration interfaces to the iLO device itself, along with a range of chassis-level monitoring. Instead, HP provide a couple of utilities that allow the OS to change values. The first of these is called conrep. Conrep is able to modify BIOS settings, but needs an XML file which tells it which configuration values are at which addresses. That's a bit of a pain. Thankfully it's being replaced with a new tool called hprcu which is able to directly query the firmware in order to figure out which configuration options are available and which values have to be stored where in order to set them. You run hprcu once and it spits out a file containing your existing settings. You modify that, feed it back into hprcu, reboot and you're set.

Sounds pretty ideal. What's the problem? The first is that hprcu is currently only shipped as a 32-bit binary, and right now we don't deploy any 32-bit support code on our nodes. It'd be irritating to have to do so just to configure the firmware. The second is that it works by doing raw port IO, and that's not going to be possible from userspace once we've moved to a UEFI Secure Boot setup.

So, obviously, I've been working on reimplementing it. The first step was to figure out what it was actually doing. The first step was to strace it to see if it was using the kernel IPMI interface. strace showed no accesses to /dev/ipmi*. My next thought was that it could be using some sort of shared memory segment with the iLO hardware, so I used MMIOTrace to dump the memory accesses it made. Turned out there weren't many, and certainly not enough to do anything interesting. Then I went back to the strace logs and saw that it was calling iopl() a bunch, and then I got sad.

iopl() allows a userspace application to change its io privilege levels. The Linux manpage for the iopl() call is amazingly helpful, informing us with a straight face that "This call is necessary to allow 8514-compatible X servers to run under Linux." What it actually does is grant userspace access to the full range of io ports.

So, what's an io port? The x86 architecture (and some others) provide two ways to communicate with hardware. The one that's mostly used these days is to map the hardware into the same address space as memory (memory-mapped io), but x86 has an entirely separate address range that can be used. This is significantly more limited, as only 65,536 addresses are available for the entire system. Further, you can only read or write a maximum of 4 bytes in a single transaction. However, while slower and less generally useful than memory-mapped io, port io has the advantage that it's much simpler to implement. As a result, a lot of the original PC hardware was intended to be accessed via port io, and a bunch of that's still present. Want to reprogram your real-time clock? Port io. Want to read from the legacy keyboard controller? Port io. For low-bandwidth transactions, it's a completely reasonable way to implement hardware.

Applications[2] perform port io by executing in and out instructions. Since these instructions allow you to do things like, say, hit the keyboard controller directly[3], userspace is generally forbidden from calling them. Sufficiently privileged applications can call iopl() to raise their privileges and gain access to the full set of io ports. But, since in and out are CPU-level instructions, the actual port io accesses won't show up in strace. So I had to take another approach.

The correct way of doing this would be to LD_PRELOAD something that intercepted iopl(), didn't call it, let the application perform an in or out instruction, caught the fault, looked at the stack frame, called iopl(), performed the access, dumped debug details, dropped iopl() again and restored state. Because that seemed like a bunch of work, I took advantage of the fact that hprcu had separate in and out functions and used gdb. I told gdb to break on every call to in or out, dump the register state and then continue. Then I hacked up a script to parse the register dumps and tell me where the reads and writes were going. Astonishingly, it worked. And then I read the results and got really sad.

PCI setup is hard, if you're a BIOS. You've got PCI devices with large memory windows and you've got to arrange them all somehow and look you've only got 640K of RAM you can access while you're doing this and come on, seriously? So PC-type systems define a port IO interface to performing PCI configuration. Each PCI device has an address made up of a bus, a device and a function. You take a 32-bit integer, set the top bit to indicate that you want PCI access, put the bus in bits 16-23, the device in bits 11-15, the function in bits 8-10 and the configuration register on that device you want to access in bits 0-7. Then you write that to io port 0xcf8. Reads or writes to io port 0xcfc then read or write from that configuration register on that device. This lets the BIOS tell each PCI device where it's going to live in mmio address space without having to actually perform any mmio. Good work, BIOS developers.

This works fine in the BIOS, because nothing else is running while the BIOS is. It even works fine in the kernel, which uses this approach on older hardware that doesn't provide a memory-mapped mechanism to access PCI configuration registers. But it works really badly if you're doing it in userspace, because it shares a problem with all other indexed accesses. You write an address to 0xcf8. You write a value to 0xcfc. What happens if the kernel writes to 0xcf8 before you write to 0xcfc? Your access goes to some other register on some other device and suddenly you've just mapped a PCI device over the top of RAM and well I sure hope you saved all your work.

So, I wasn't thrilled to discover that hprcu was communicating with the iLO by using 0xcf8/0xcfc port io accesses. Not only was it going to stop working once we started deploying UEFI Secure Boot, it had the potential to cause really annoyingly hard to debug problems. Working out how to reimplement it became something of a priority.

By looking at the XML files it generated, and by following the port IO accesses it was performing, I could figure out pretty much how it worked. Some configuration values are stored in the real-time clock CMOS. These were just done in the standard way - write the address to port 0x70, read or write the value to port 0x71[4]. Other configuration values were stored in NVRAM, with accesses going via PCI. This was a little trickier to figure out, because sometimes different NVRAM addresses went to the same PCI address. I finally figured it out - there's a 48 byte window into NVRAM via the PCI configuration registers, and another register which chooses which set of NVRAM is visible. So, take the NVRAM address, divide by 48, write that value to register 0xa6, take the modulus, add it to 0x80 and write the desired value to that address.

So now I knew enough to be able to take an existing XML file and deploy it. Definitely progress, and I could even add support to the kernel. But I still wanted to know how hprcu generated that XML file in the first place. Running strings over the binary showed a bunch of debug output that it never actually printed, but immediately after the help text it also printed SsLlFf:HhAaTtOoDd. I've lost enough years of my life to this kind of thing to be able to identity that as a getopt format string, and there was that tantalising D option at the end that went entirely unmentioned in the help text. Re-running hprcu with the -D argument gave me huge piles of debug output, including references to a DMI entry and an $RBS table.

DMI is a standard for exposing system information, and one aspect of it is providing data from the firmware to the operating system. The OS can look for a defined signature in a fixed area of memory and then pull out a bunch of data about the hardware, including things like the vendor name, model, serial number, BIOS version and more. Some of these information tables are standardised and some are vendor-specific. hprcu was looking for a vendor-specific table and then scanning for it looking for a known signature. That table turned out to to contain a set of signatures and addresses. The address corresponding to the signature hprcu was contained a bunch of data starting with "$RBS". It also contained a huge quantity of ASCII that looked awfully like the strings in the XML file that hprcu had written. Success!

So, the rest of today was spent on working out the format of this table. This was only marginally less tedious than setting up BIOS settings on 20 servers by hand, but I've made enough progress to be able to figure out how to write a kernel-level driver for this. That's about half-done now - the parsing code is all implemented, I just need to add the sysfs glue and I am nowhere near drunk enough for that right now[5], so for now you're just getting a format description.

To start with, look for a DMI table with a type of 0xe5. This contains several entries of 4 bytes of signature, 8 bytes of address and 4 bytes of length. Find the entry with a signature of "$CRQ" and map the corresponding address. The first four bytes of the mapped region should be "$RBS". The first record is 21 bytes into the file. Each record starts with a single byte representing the type and two bytes representing the record length. Records of type 1 contain an ascii string that starts 8 bytes into the record, and have a further type number 6 bytes into the record that tells you what type of string it is. 0x05 indicates that it's a "Feature string", which defines the overall classification of the following features. 0x06 is an "Option string", which provides a human readable explanation of what this configuration value corresponds to. 0x60 is an "Optional warning string", which tells the user which further configuration may be required before the configuration change takes effect.

All other types appear to be configuration options. Bytes 3 to 6 provide the little-endian name of the configuration option. Bytes 7 and 8 provide a unique numberical identifier for the configuration option. Byte 13 indicates the type. 0x03 is stored in CMOS. 0x04 is stored in NVRAM. 0x05 appears to be some different kind of CMOS store. I haven't figured out the others. There then follows a set of choices. These vary in length depending on the type - 0x03 are 14 bytes long, 0x04 are 6 bytes long, 0x05 are 5 bytes long. Type 0x03 choices have the choice id at byte 0, the CMOS offset at byte 2, the mask at byte 3 and the value at byte 4. Type 0x04 choices have the choice id at byte 0, the nvram offset at bytes 1 and 2, the mask at byte 3 and the value at byte 4. Type 0x05 choices have the choice id at byte 0, the cmos offset at byte 1, the mask at byte 2 and the value at byte 3. There are optional flags following each choice - if the final byte of the choice isn't 0, there then follow 6 bytes of flags. The first four bytes provide the name of a configuration option (little-endian, again), the fifth byte refers to a choice on that option and the sixth byte indicates what kind of flag. 0x1 appears to indicate that the option is mutually exclusive with that other option. Examples include the embedded serial port and virtual serial port options, where it's impossible to map both to the same address at once. A choice can have multiple flags.

After a configuration option, there'll be a set of option string records. In turn, these correspond to the previous choices - if a configuration option had three choices, there'll be three option string records. I haven't figured out whether there's a stronger way of binding the option string records to the configuration choice yet. The other thing I haven't entirely figured out are the details of configuring the platform to perform a cold reboot on the next power cycle, but the io traces for that don't look too bad.

The aim is to provide a kernel driver that exposes all these configuration options via sysfs, including indicating the current value, the available values and letting the user set a new value. In an ideal world we'd have a wonderfully generic interface to this kind of functionality, but I'm (sadly) not sure that that's possible.

And that's how I spent the past two days.

[1] (Thell)
[2] Or, indeed, kernels
[3] And, hence, read your keystrokes
[4] Which has exactly the same problems as the PCI access, in that if you happen to ask the clock what the time is while hprcu is accessing CMOS, at least one of you is going to get very confused
[5] Obviously, I would never write kernel code while drunk. You're certainly not running any of it in your enterprise kernel.

comments

I ve moved to using newsblur, a hosted F/OSS RSS feed reader. I really like it a lot, and I highly recommend it to anyone looking for a new feed reader. I also strongly encourage you to donate / pay for an account, it s rare we get a hosted F/OSS solution like this, and I d like to see more of it. That s all, really.

Is Franz Sacher, the Inventor of the famous sachertorte, still alive and and working at the at the Electronic Frontier Foundation? Might this help explain why EFF Technology Project Director Peter Eckersley is so concerned about protecting privacy and pseudonymity?

For some reason I've always hated the layout of Office Suite tools such as LibreOffice, OpenOffice and Microsoft Office (I seem to find the Ribbon interface nicer than what has gone before, although I can't put my finger on why.) I always find the sheer quantity of UI in these programs have a real negative impact on creativity. I still haven't found anything as inspirational as a blank sheet of paper (or perhaps more accurately, less demotivating than a blank sheet of paper.) I've tried disabling and removing bits in the past, but I've never ended up with something I was happy with. Recently I tried attaching one of the two standard toolbars vertically, instead of horizontally. Surprisingly to me, the result feels a lot nicer. There's still some way to go, though. focuswriter is pretty good but I like to have some graphical features. By analogy when I write on paper it's not always straight lines of words, but sometimes bubbles, arrows, lines, strikethroughs, etc. At least I can get bullet points by remembering the write X compose key sequence (alt gr, dot, equals)

So my partner and I spent last week in Helsinki, visiting for Midsummer. The place was lovely, albeit "too damn hot"^tm. (Despite my regularly shaved head I'm a pale-skinned redhead covered in freckles. In sustained sun I can be burned in the space of 10-20 minutes. Ouch.) I ate cake, went to a sauna, and all the usual things. I also had personal interviews with all the mosquitos. The only downside to the holiday was the timing:

• Friday Worked.
• Saturday woke up early and flew.
• Time passes, Thorin sits down and starts singing about gold.
• Sunday flew back.
• Monday .. worked.
• Tuesday worked ..

I'm a sysadmin and sometimes that involves out of hours work, so you can shuffle virtual machines around, upgrade processors, and do all the kind of "disruptive" work outside core business hours. Yesterday I was awake for 22 hours and I was working for 14 of them. Today I'm doing nothing that involves a computer other than a token check-in or three to make sure everything is fine. 99% of the time I don't mind working late, starting early, or scheduling an event outside working hours (e.g. last night I worked from 10PM-3AM ). But with the holiday I've definitely been feeling burned. My sleeping is screwed up, and I'm just getting grumpy and stupid. Still there were some highlights and I took some nice photos, met some good people, and learned some more Finnish. I actually tried to find some Finnish instructor(s) here in Edinburgh, upon my return, and was amused to discover that there is an Edinburgh-based Finnish Society. Amused? They cancelled their midsummer event due to poor weather. For the rest of the week I'm going to be very careful to count working hours and do nothing excessive. I've also got to get back into my gym-routine. Still there is good news on the horizon. I get a new computer next Monday. The new machine will run Wheezy, and Awesome. With 8GB RAM I'll stop hitting OOM conditions once I process many photographs, and I'm going to be very dedicated in using revision control for everything. (I've noticed I've gotten lazy and have started storing bookmarks locally again, instead of under revision control which is a bad sign.) Rambling. I woke up early (10:30AM) because "Microsoft Technical Support" called me and told me my computer had a virus ..

Review: River of Stars, by Guy Gavriel Kay

Publisher:	Roc
Copyright:	April 2013
ISBN:	0-451-46497-4
Format:	Hardcover
Pages:	639

In Under Heaven, Guy Gavriel Kay applied his style of slightly fantastic alternate history to Tang Dynasty China and wrote possibly the best book of his career. In River of Stars, he takes the unusual step of revisiting one of his historical worlds, something I don't think he's done explicitly apart from the Sarantime Mosaic duology. River of Stars is set in the same land of Kitai, Kay's alternate China, four centuries later. It's a stand-alone novel, not a sequel, but the effects of the events of the earlier book are deeply felt on the structure of society. Under Heaven was one of my favorite books of all time, so you can imagine how eagerly I've been awaiting this book ever since it was announced. It starts, once again, in the distant regions of Kitai, this time with a boy. Ren Daiyan is the second son of a minor clerk in a backwater town with a very atypical dream for someone of his social rank: to win back the lost provinces of Kitai from the Xiaolu and restore the glory of the empire as the center of the world. One sees little hope for this dream in a world where no one with any choice in the matter would let their sons join the discredited and suspected army. And, as River of Stars opens, it's become much less likely since the town's only teacher has closed his school and left. As with Under Heaven, the unfolding of Daiyan's life is full of surprises, all of which should be enjoyed in the flow of the story. Here, I think the cover flap even gives away too much information, despite only mentioning events at the start of the book, since the incident that it recounts has much more impact without being spoiled. I recommend avoiding any plot summary and just reading, and therefore will avoid giving any more details. River of Stars, in another echo of its predecessor novel, has a second, female protagonist. Lin Shan is the daughter of a scholar on the edges of imperial court life, a man who has quietly but persistently refused to educate her differently than he would have educated a son. This matters in the time of this novel. Kitai has turned more conservative, turned away from the roles of women in public life seen (in their limited ways) in Under Heaven, and has pressed women into new roles of formal modesty. Shan has been set up for a difficult life. But she's also brilliant, careful, and canny, making use of opportunties, and manages to make several extraordinary friends within the power structures of the court. It's impossible not to compare this novel to Under Heaven, but that's an unfair standard to which to hold any novel. So I will say up front that, at least for me, River of Stars does not capture quite the same magic. Shen Tai was a brilliant protagonist, and his unwanted journey into the circles of power was the perfect palette on which to mix personal integrity with sweeping politics. It used history as a backdrop for a novel that was always grounded in Shen Tai's modest ambitions and quiet integrity. Neither Daiyan nor Shen are that character, nor is River of Stars that book. This novel is far more political from the start, concerned directly with issues of governance, court intrigue, and military maneuvers. Even with Shen to ground the story, the personal is the political and the events of history have been moved to center stage. I've seen Kay approach a history both ways, and I prefer when he uses history as backdrop rather than focus. I find it easier to identify and celebrate with the protagonists when their journies are less caught up in grand events. When, as here, the personal becomes the political, it creates a darker tone. The stakes are higher, and there is little separable individual triumph to blunt the tragic moments. That said, Kay remains at the height of his form. Once again, this novel contains some of the best conversations I have ever read. I'm not sure what Kay is doing that other novelists aren't. It may be that he is discarding some realism in favor of presenting the purified essence of sharp and dangerous exchanges (more on that in a bit). But there are several conversations here that read like the distilled essence of a high-stakes, insightful exchange between fearsomely intelligent adversaries: steeped in strategy, carefully managed for effect, and full of thrilling rhetorical tightropes. There are also moments that literally sent shivers up my spine: moments when the story changes, and lives change, in ways that I was not expecting at all. The story is beautifully stage-managed, imbuing every moment with a feeling of a broader resonance. I do have to warn, as with all Kay but particularly recent writing, that this is done openly and explicitly via an omniscient and very obvious narrative voice. Kay writes in the style of high fantasy in which the narrator is nearly a character in the story, one who foreshadows events and shares observations directly with the reader. Some people dislike that style inherently, and if so, Kay may not be for you. I love it when it's done well, and I don't think anyone does it better than Kay. I feel like I'm in the hands of a master storyteller who is carefully crafting the story to preserve surprise and suspense and who knows exactly where he wants the story to go. That's fitting, since one of the major themes of this book is stories and legends, and how they are shaped by events but then come to shape events in turn. River of Stars is partly about the construction of stories in the way that Under Heaven was partly about poetry. Some of the characters try to control the setting and subject matter, some use stories as a way to focus their personal motivation, and some use them to define their lives. But stories also shape politics because they can define popular reaction and the limits of the possible. This theme is subtle through much of the book, but the more I thought about it the more I noticed it woven through the story. Unfortunately, and very unusually for one of Kay's novels, the journey was intense but the destination was mildly unsatisfying. I don't want to give away any detail of the plot, so this is necessarily vague, but while I intellectually appreciate the themes that I think Kay was exploring, I think River of Stars lacks the powerful catharsis that I normally get from his novels. This for me returns to the focus on the politics over the personal (which is in some ways another of the themes of the novel). The catharsis in a novel for me begins and ends with the characters, and these characters didn't have quite enough independence from the broader sweep of events. Another theme of the novel is the degree to which every character is operating within tight constraints. This also showed up in Under Heaven, but Under Heaven was full of characters who subverted and manipulated those constraints. In River of Stars, they are more often suffocating. Shen is my favorite character, and I think the strongest character in the novel, because she manages to work around the most constraints and has the most personal story. But the roles into which she's forced remain smothering and push her out of the center of the action. Her life is full of lovely details (I particularly liked her domestic situation, which shows a family model that I think was far more common in reality than it has been in fiction and one that I would like to see portrayed far more often), but she simply doesn't have realistic room, within the society portrayed here, to maneuver to the catharsis I was looking for. One other, minor note: as in Tigana, but more blatantly, unusual sexual desires make an appearance linked with the closest thing this story has to a villain. (In this case, femdom BDSM, although shown so glancingly that I suspect some readers will not pick up on what's being described.) It was neither unrealistic nor out of character, but there is a moment of nastiness that caught me by surprise and bothered me. I hope eventually to see alternative sexuality show up in a Kay novel without the negative linkages. It's not quite characterization by stereotype (I think Kay was going for a deeper point about the constrained roles available to women), but it's close enough to not work for me. I'm spending a lot of words on what didn't quite work for me, but that's because it's complex to explain, not because this is a bad story. Rather the opposite: it's an excellent novel that I didn't enjoy quite as much as its predecessor for reasons that are very individual to me. It's quite likely that those with different narrative preferences or different tolerances for certain emotional tones in novels will have a far different reaction. The quality of the writing is quite high, provided that you don't mind Kay's intrusive narrator, and several moments in this novel made me catch my breath in wonder. If you like Kay, read this; it's very much worth your time. If you're new to Kay, I would start with Under Heaven, which is near the top of my list of novels to recommend to anyone. Then read this, since seeing how the world develops and how the events of the previous novel change and shape subsequent politics is fascinating. It's not quite at the same level, but it's very much worth reading on its own terms. Rating: 9 out of 10

This is part 2 in a series on organizational design and growth. What it means Carefully communicating about what s going on, and making fewer assumptions about what others know or think. Why it s important As companies grow, many new people join who don t have as much shared context. Many employees will also interact less frequently with each other, as we may not be able to maintain the same level of relationship with everyone. When we make assumptions about what our co-workers know, think or feel, we will increasingly be making errors of judgment. By replacing these tacit assumptions with explicit communication, we can help avoid mistakes and support cooperation within and between teams. Explicit communication is a vital tool for coming to agreement: by putting an agreement into words, we stand a better chance of understanding what we re agreeing to, and can change it together. Old status quo We take a lot for granted. We know quality when we see it, but can t explain it. New team members are expected to learn through osmosis or trial and error. Expectations are often ambiguous. Procedures live in our heads, and evolve in ad hoc fashion. New status quo We exercise care and thoughtfulness in our internal communications, telling others clearly what we expect and what they can expect from us. Key information and procedures are written down, and can be instantly shared with as many people as needed. We change them whenever we need to, and everyone concerned stays in the loop. Behaviors that help

• Document the basics: a new team member should be able to learn the essentials of how to do their work by referring to documentation. We don t need to try to exhaustively document everything, but the essentials (e.g. for an engineer, how to deploy their changes) should be written and maintained, and where appropriate encapsulated in software tools
• Make work visible: something as simple as a Trello board can offer a lot of insight into what s going on in a team, both specifics (e.g. status) and meta information (this is how we get things done)
• Define and track projects: a project has a beginning and an end and a scope. There will always be unknowns and changes, but there should be an explicit goal such that we can agree on when it s done
• Clarify roles and responsibilities: job roles are a tool to communicate with other people about what you do. By having a shared understanding of what roles we occupy, we can more easily divide up responsibilities and anticipate each other s contributions.
• Listen actively: is this what you meant? who is taking responsibility for making that happen? do we have agreement on this point?

Obstacles that hold us back

• Fear of process: Tiny companies can get by with very little structure in their operations, and may become attached to this as part of the culture . As they grow, this is less and less true. Process doesn t mean bureaucracy! A process is just a description of the way things work. It doesn t have to be rigid or foolish. The worst kinds of process are those that only exist in people s heads, and are divergent from each other.

[I'm encouraging git-annex users to post their success stories, and this one is my own.] I set up git-annex on my mom's and sisters' computers a couple of months ago. I noticed this was the first software I've written that I didn't have to really explain how to use. All I told them was, put files in this folder, and the rest of us will be able to see them. Don't put anything too big in there, or anything you don't want others to see. I paired the computers using XMPP, and set up an encrypted transfer repository using a free account rsync.net gave me for beta testing. I also added a repository on my server, which made things more robust. (XMPP has since improved, but it's still a good idea to have a git repository to suppliment XMPP.) I also have two removable drives that are used to back up our files. This was all set up using the webapp. And adding a computer takes just a couple of minutes that way. I set it up at my sister's in a spare moment during a visit, and it all just worked. Our shared git annex contains a couple of hundred files, and is a couple of gigabytes in size. And growing pretty fast as we find things we want to share. Mostly photos and videos so far but I won't be surprised to find poems and books pop up in there from the family's poets and authors. And it'll grow further as I add people who've so far been left out. Coming home from a week at the beach with my grand nephew and niece, was the first time I really used git-annex without thinking about it. Collapsed on a hotel bed, I plugged in my camera and loaded in the trip's photos. Only to see the hotel wifi cost extra. Urk, no! Later, in the lobby, I found an open wifi network, and watched it automatically sync up. By the time I was home, the video of cute kids playing weathermen and reporting on our near miss by a tropical storm had been enjoyed by the folks who didn't make that family gathering.

Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  aptitude*
0 upgraded, 0 newly installed, 1 to remove and 41 not upgraded.
After this operation, 4650 kB disk space will be freed.
Do you want to continue [Y/n]? 

It just so happens that I've been blogging long enough that I can say with pretty good confidence that I've been using aptitude for about eight years now. Originally, the aptitude resolver was mostly good enough that in most cases, I could just tell aptitude to mark packages for upgrades, and it'd work; only in a few cases did I have to tell it to find a different solution. Unfortunately, this is no longer the case; when given a complex problem, aptitude is far too happy to just go ahead and remove packages these days. Sometimes, when I tell it to upgrade package "foo", it'll find that something is uninstallable, and then tell me that by removing package "foo" (but upgrading some of the libraries it depends on) we can get the situation resolved. The resolver has some more bugs, but this really is the worst of it. Recently, I've noticed that nowadays I often find myself fighting aptitude trying to remove packages, to the point that eventually it gives up and I have to retry with "apt-get update" or "apt-get dist-upgrade" or similar. Which then works flawlessly. I've decided that enough is enough, and I'll just stick with apt-get for now.

It annoys me when the computer fail to do automatically what it is perfectly capable of, and I have to do it manually to get things working. One such task is to find out what firmware packages are needed to get the hardware on my computer working. Most often this affect the wifi card, but some times it even affect the RAID controller or the ethernet card. Today I pushed version 0.4 of the Isenkram package including a new script isenkram-autoinstall-firmware handling the process of asking all the loaded kernel modules what firmware files they want, find debian packages providing these files and install the debian packages. Here is a test run on my laptop:

# isenkram-autoinstall-firmware 
info: kernel drivers requested extra firmware: ipw2200-bss.fw ipw2200-ibss.fw ipw2200-sniffer.fw
info: fetching http://http.debian.net/debian/dists/squeeze/Contents-i386.gz
info: locating packages with the requested firmware files
info: Updating APT sources after adding non-free APT source
info: trying to install firmware-ipw2x00
firmware-ipw2x00
firmware-ipw2x00
Preconfiguring packages ...
Selecting previously deselected package firmware-ipw2x00.
(Reading database ... 259727 files and directories currently installed.)
Unpacking firmware-ipw2x00 (from .../firmware-ipw2x00_0.28+squeeze1_all.deb) ...
Setting up firmware-ipw2x00 (0.28+squeeze1) ...
# 

When all the requested firmware is present, a simple message is printed instead:

# isenkram-autoinstall-firmware 
info: did not find any firmware files requested by loaded kernel modules.  exiting
# 

It could use some polish, but it is already working well and saving me some time when setting up new machines. :) So, how does it work? It look at the set of currently loaded kernel modules, and look up each one of them using modinfo, to find the firmware files listed in the module meta-information. Next, it download the Contents file from a nearby APT mirror, and search for the firmware files in this file to locate the package with the requested firmware file. If the package is in the non-free section, a non-free APT source is added and the package is installed using apt-get install. The end result is a slightly better working machine. I hope someone find time to implement a more polished version of this script as part of the hw-detect debian-installer module, to finally fix BTS report #655507. There really is no need to insert USB sticks with firmware during a PXE install when the packages already are available from the nearby Debian mirror.

A new version of Rcpp is now on the CRAN network for GNU R; binaries for Debian have been uploaded as well. This release brings a fairly large number of fixes and improvements across a number of Rcpp features, see below for the detailed list. We are also announcing with this release that we plan to phase out the RCPP_FUNCTION_* macros. Not only have they been superceded by Rcpp Modules and Rcpp Atributes (each of which has its own pdf vignette in the Rcpp package), but they also appear to be at best lightly used. We are for example not aware of any CRAN packages deploying them. To provide a smooth transition, we are aiming to keep them around for another twelve months, but plan to remove them with the first release after that time window has passed. As before, we tested the release rather rigorously by checking against all packages I could (relatively easily) built on my server: this time it covered 91 of the 124 CRAN packages depending on Rcpp. As all of these 91 packages passed their checks, we do not expect any issues with dependent packages. The complete NEWS entry for 0.10.4 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.4 (2013-06-23)

• Changes in R code: None beyond those detailed for Rcpp Attributes
• Changes in Rcpp attributes:
  • Fixed problem whereby the interaction between the gc and the RNGScope destructor could cause a crash.
  • Don't include package header file in generated C++ interface header files.
  • Lookup plugins in inline package if they aren't found within the Rcpp package.
  • Disallow compilation for files that don't have extensions supported by R CMD SHLIB
• Changes in Rcpp API:
  • The DataFrame::create set of functions has been reworked to just use List::create and feed to the DataFrame constructor
  • The operator-() semantics for Date and Datetime are now more inline with standard C++ behaviour; with thanks to Robin Girard for the report.
  • RNGScope counter now uses unsigned long rather than int.
  • Vector<*>::erase(iterator, iterator) was fixed. Now it does not remove the element pointed by last (similar to what is done on stl types and what was intended initially). Reported on Rcpp-devel by Toni Giorgino.
  • Added equality operator between elements of CharacterVectors.
• Changes in Rcpp sugar:
  • New function na_omit based on the StackOverflow thread http://stackoverflow.com/questions/15953768/
  • New function is_finite and is_infinite that reproduces the behavior of R's is.finite and is.infinite functions
• Changes in Rcpp build tools:
  • Fix by Martyn Plummer for Solaris in handling of SingleLogicalResult.
  • The src/Makevars file can now optionally override the path for /usr/bin/install_name_tool which is used on OS X.
  • Vignettes are trying harder not to be built in parallel.
• Changes in Rcpp documentation:
  • Updated the bibliography in Rcpp.bib (which is also sourced by packages using Rcpp).
  • Updated the THANKS file.
• Planned Deprecation of RCPP_FUNCTION_*:
  • The set of macros RCPP_FUNCTION_ etc ... from the preprocessor_generated.h file will be deprecated in the next version of Rcpp, i.e they will still be available but will generate some warning in addition to their expected behavior.
  • In the first release that is at least 12 months after this announcement, the macros will be removed from Rcpp.
  • Users of these macros (if there are any) should start replacing them with more up to date code, such as using Rcpp attributes or Rcpp modules.

Thanks to CRANberries, you can also look at a diff to the previous release 0.10.3. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

When Sir Tim made a band the first image on the web back in 1992, I do not imagine for a moment he understood the full scope of what was to follow. I also do not imagine Marc Andreessen understood the technical debt he was about to introduce and that fateful day in 1993 when he proposed the img tag allowing inline images.

Many will argue of course that the old adage of my title may not apply to the web, where if it were true, every page view would be like reading a novel! and many of those novels would involve cats or one pixel tall colour gradients.
Leaving aside the philosophical arguments for a moment it takes web browser author a great deal of effort to quickly and efficiently put those cat pictures in front of your eyeballs.
NavigatingImages are navigated by a user in a selection of ways, including:

• Direct navigation to an image like this cat picture is the original way images were viewed i.e not inline and as a separate document not involving any html. Often this is now handled by constructing a generated web page within the browser with the image inline avoiding the need for explicit image content handling.
• An inline img tag (ironically it really does take thousands of words to describe) which puts the image within the web page not requiring the user to navigate away from the document being displayed. These tags are processed as the Document Object Model (DOM) is constructed from the html source. When an img tag is encountered a fetch is scheduled for the object and when complete the DOM completion events happen and the rendered page is updated.
• Imported by a CSS stylesheet.
• inline element created by a script

Whatever the method, the resulting object is subject to the same caching operations as any content object within a browser. These caching and storage operations are not specific to images however images are one of the most resource intensive objects a browser must regularly deal with (though javascript and stylesheet sources are starting to rival it at times) because they are relatively large and numerous.
Pre render processingWhen the image object fetch is completed the browser must process the image for rendering which is where this gets even more complicated. I shall use how this works in NetSurf as I know that browsers internals best, but operation is pretty similar in many browsers.

The content fetch will have performed basic content sniffing to determine the received objects mime type. This is necessary because a great number of servers are misconfigured and a disturbingly large number of images served as png are really jpegs etc. Indeed sometimes you even get files served which are not images!

Upon receipt of enough data to decode the image header, for the detected mime type, the images metadata is extracted. This metadata usually includes things like size and colour depth.

If the img tag in the original source document omitted the width or height of the image the entire document render may have to be reflowed at this point to allow the correct spacing. The reflow process is often unsightly and should be avoided. Additionally at this stage if the image is too large to handle or an unhandled format the object will be replaced with the "broken" image icon.

Often that will be everything that is done with the image, when I added "lazy" image conversion to NetSurf we performed extensive profiling and discovered well over 40% of images on visited pages are simply never viewed by the user but that small (100 pixel on a side) images were almost always displayed.

This odd distribution comes down to how images are used in modern web pages, they broadly fall into two categories of "decoration" and "content" for example all the background gradients and sidebar images etc. are generally small images used as decoration whereas the cat picture above is part of the "content". A user may not scroll down a page to see content but almost always gets to "view" the decoration.
RenderingThe exact browser heuristics used differ as to when the render operation is performed but they all have a similar job to perform. When i say render here this may be possibly as an "off screen" view if they are actually on another tab etc. Regardless the image data must be converted from the source data (a PNG, JPEG etc.) into a format suitable for the browsers display plotting routines.

The browser will create a render bitmap in whatever format the plotting routines require (for example the GTK plotters use a Cairo image surface) , use an image library to unpack the source image data (PNG) into the render bitmap (possibly performing transforms such as scaling and rotation) and then use that bitmap to update the pixels on screen.

The most common transform at render time is that of scaling, this can be problematic as not all image libraries have output scaling capabilities which results in having to decode the entire source image and then scaling from that bitmap.

This is especially egregious if the source image is large (perhaps a multi megabyte jpeg) but the width and height are set to produce a thumbnail. The effect is amplified if the user has set the image cache size limit to a small value like 8 Megabytes (yes some users do this apparently their machines have 32MB of RAM and they browse the web)

In addition the image may well require tiling (for background gradients) and quite complex transforms (including rotation) thanks to CSS 3. Add in that javascript can alter the css style and hence the transform and you can imagine quite how complex the renderers can become.
CachingThe keen reader might spot that repeated renderings of the source image (e.g. because window is scrolled or clipped) result in this computationally expensive operation also being repeated. We solve this by interposing a render image cache between the source data and the render bitmaps.

By keeping the data in the preferred format, image rendering performance can be greatly increased. It should be noted that this cache is completely distinct from the source object cache and relates only to the rendered images.

Originally NetSurf used to perform the render conversion for every image as it was received without exception, rather than at render time, resulting in a great deal of unnecessary processing and memory usage. This was originally done for simplicity and optimising for "decoration" images.

The rules for determining what gets cached and for how long are somewhat involved and the majority of the code within the current implementation NetSurf uses is metrics and statistic generation to produce better decisions.

There comes a time at which this cache is no longer sufficient and rendering performance becomes unacceptable. The NetSurf renderer errs on the side of reducing resource usage (clearing the cache) at the expense of increased render times. Other browsers make different compromises based on the expected resources of the user base.
FinallyHopefully that gives a reasonable overview to the operations a browser performs just to put that cat picture in front of your eyeballs.

And maybe next time your browser is guzzling RAM to plot thousands of images you might have a bit more appreciation to exactly what it is up to.

thanks to lucas & his trainees, we're seeing archive rebuilds & tons of new RC bugs again. besides that, there are still some patches in the BTS. here goes my list of recently worked on bugs; most of them in the pkg-perl group

• #665549 src:gtk-nodoka-engine: "gtk-nodoka-engine: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2
• #665559 src:indicator-applet: "indicator-applet: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2
• #665596 src:photoprint: "photoprint: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2
• #665601 src:qstardict: "qstardict: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2
• #700229 src:gpm: "FTBFS with glibc 2.17, missing include"
  add patch from Adam Conrad / Ubuntu (missing include), upload to DELAYED/2
• #701447 src:zfs-fuse: "zfs-fuse: ftbfs with eglibc-2.17"
  add patch from Ben Collins / Ubuntu, upload to DELAYED/2, moved to 0-day after maintainer feedback
• #708809 src:substance: "substance: FTBFS: [javac] / PKGBUILDDIR /src/test/contrib/setskin/MainClass.java:150: cannot find symbol"
  upload package prepared by Emmanuel Bourg (pkg-java)
• #713121 src:libscalar-does-perl: "libscalar-does-perl: FTBFS: unsatisfiable build-dependency: perl (>= 5.16) but 5.14.2-21 is to be installed"
  fix build dependency in git (pkg-perl)
• #713223 src:libredis-perl: "libredis-perl: FTBFS: tests failed"
  add patch from upstream bugtracker (pkg-perl)
• #713227 src:libmail-deliverystatus-bounceparser-perl: "libmail-deliverystatus-bounceparser-perl: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #713228 src:libextutils-modulemaker-perl: "libextutils-modulemaker-perl: FTBFS: test failed"
  set HOME during build (pkg-perl)
• #713229 src:libxml-compile-cache-perl: "libxml-compile-cache-perl: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #713233 src:libplack-perl: "libplack-perl: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #713241 src:libfile-save-home-perl: "libfile-save-home-perl: FTBFS: tests failed"
  set HOME during build (pkg-perl)
• #713245 src:libtext-csv-encoded-perl: "libtext-csv-encoded-perl: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #713246 src:libmojomojo-perl: "libmojomojo-perl: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #713247 src:librt-client-rest-perl: "librt-client-rest-perl: FTBFS: tests hang"
  update build dependency (pkg-perl)
• #713251 src:libmojolicious-plugin-authentication-perl: "libmojolicious-plugin-authentication-perl: FTBFS: tests failed"
  add patch from upstream bugtracker (pkg-perl)
• #713253 src:libtemplate-plugin-latex-perl: "libtemplate-plugin-latex-perl: FTBFS: tests failed"
  apply patch from CPAN RT (pkg-perl)
• #713259 src:libdist-zilla-plugin-git-perl: "libdist-zilla-plugin-git-perl: FTBFS: # Unable to open source/.gitnxtver_cache: No such file or directory"
  upload new upstream release (pkg-perl)
• #713265 src:perlbrew: "perlbrew: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #713266 src:libsql-abstract-more-perl: "libsql-abstract-more-perl: FTBFS: tests failed"
  upload fixed package prepared by Oleg Gashev (pkg-perl)
• #713267 src:libmojolicious-plugin-basicauth-perl: "libmojolicious-plugin-basicauth-perl: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #713556 src:iodine: "iodine: FTBFS: (.text+0x19a): undefined reference to floor'"
  deactivate tests until the check library is fixed
• #713682 src:libnet-cups-perl: "libnet-cups-perl: FTBFS: CUPS.xs:10:24: fatal error: cups/image.h: No such file or directory"
  add patch from upstream bugtracker (pkg-perl)