One major change in GNOME 3.6 is Pango s shaper engines replacement with HarfBuzz. Only language engines (for word break analysis, for example) are retained. So, I m checking how this affects Thai/Lao rendering and what to do next. Over all, Behdad has put a good effort to make it right. Most Uniscribe behaviors have been achieved for compatibility. He even cares enough to cover some widespread Thai fonts in which the language tag 'latn' is used instead of 'thai', as seen in Mozilla #719366. Unfortunately, this font set has been declared as standard fonts in official documents. The workaround seems inevitable. Supported Fonts In my experiments with some existing Thai OpenType fonts, the new Pango still renders well without regression. Loma font from fonts-tlwg (glyph positioning with GPOS, rearrangement with GSUB): Arundina Sans font from Fonts-SIPA-Arundina (positioning by substitution, only GSUB, no GPOS): But for legacy fonts without OpenType features, it renders badly: In addition, according to Behdad, PUA glyphs in legacy fonts are not supported yet. This means there will be regression on fonts designed for Windows XP or below. But modern fonts designed for Windows 7 should be fine. Changes on Bugs The engine replacement from scratch certainly affects existing bugs. Some become obsolete, some still remain. Here are the summary for Thai/Lao engine, as resolved upstream: Closed bugs:

• GNOME #616495 (Debian #620001) regarding Lao MAI KONG rendering, which was caused by a flaw in my code. I have proposed a patch for a while, but no action is taken yet. And patched debs have been locally distributed as a workaround. However, with HarfBuzz replacement, the bug has now gone.
• GNOME #378001 regarding minority languages supports. I hadn t worked on this because I was waiting for WTT 3.0, a local standard, to be drafted. Anyway, with HarfBuzz replacement, the old WTT 2.0 clustering has been dumped and replaced with Unicode guidelines. Therefore, I assume it should be now possible to render minority languages with Thai script, provided that the font has the required OpenType features.
• GNOME #393307, #677090 regarding wrong rendering of zero-width marks like ZWJ, ZWSP. This bug has also been dumped with the HarfBuzz replacement.

Questionable bugs:

• GNOME #583718 (Debian #620002) regarding the rendition of Thai SARA AM (U+0E33) on VTE with excessive dotted circle. So far, I have disagreed with Behdad whether this bug should be treated along with Indic scripts. IMO, there is an easy path for Thai by rendering monospace fonts differently, which is also in accordance with widespread practice everywhere else, albeit XTerm, Emacs, or framebuffer TTYs. But Behdad doesn t like the idea and insists that it should be treated along with Indic scripts, which would complicate things a lot. So, the bug has been there for many years. Meanwhile, I have also provided a workaround in the aforementioned patched debs. BTW, the situation has been changed a little bit after the HarfBuzz replacement. Firstly, let s see the problem with current Pango: One can easily spot the dotted circle glitches. And here is how I workaround it, which is like how it's rendered on other terminals: With the HarfBuzz replacement, here is how it renders: That is, although it s still wrong, it s more tolerable. So, the question for users is: Could they tolerate this until VTE is redesigned for Indic scripts supports?

Remaining bugs:

• GNOME #576156 (Debian #620004) regarding weird cursor movements caused by Unicode UAX #29. Many amendment efforts have been pushed to Unicode from different sources, until it was finally accepted in Unicode 6.1.0. However, no action has been taken in Pango yet. We still have to push it further. Again, a fix has also been provided in the patched debs.

The unstoppable PostgreSQL team just announced the first release candidate of 9.2, with several bug fixes since the Beta 4. If you haven t tested 9.2 yet, now is the time! Remember that you can run a copy of your 8.4 or 9.2 cluster in parallel for testing with pg_upgradecluster. If you use Debian, 9.2rc1 will be available in experimental in a few hours. For Ubuntu, you can get packages for all supported releases from my PostgreSQL backports PPA as usual. Enjoy!

FreedomBox 0.1 Ian Sullivan posted a release announcement today regarding the first FreedomBox public release, which we're calling 0.1. This release is, frankly, long overdue. Getting here has been harder and taken much longer than any of us intended. Fortunately, now that we've reached this milestone, I believe that making regular progress towards the vision we have for a "1.0" release will get easier. FreedomBox is far from the only thing that I'll be working on after my upcoming early retirement from HP, but hopefully I will succeed in putting far more time towards the project soon than I have been able to in the past.

Today there was an announcement that Dropbox supports two-factor authentication. On their page with detailed instructions there is (at the bottom) a link to the man page of the OATH Toolkit command line utility oathtool. OATH Toolkit is available in Ubuntu 12.04 and Debian Wheezy. (Note that the 1.10.4 version in Ubuntu does not support the base32 features.) There is not a lot of details in the documentation on Dropbox s site on how to use oathtool, but I have experimented a bit with the setup and I d like to share my findings. I assume you are somewhat familiar with the OATH Toolkit; if not I suggest reading my earlier introduction to OATH Toolkit. To use OATH Toolkit s command line utility to generate OTPs that are accepted by Dropbox, here is how you proceed. When you enable two-factor authentication on Dropbox s site, you must select Use a mobile app and on the next screen with the QR code image, click the enter your secret key manually link. You will then be presented with a code that looks like this: gr6d 5br7 25s6 vnck v4vl hlao re Now this code is actually space-delimitted base32 encoded data, without any padding. Since version 1.12.0, oathtool can read base32 encoded keys. However, parsing the raw string fails, so to make it work, you need to remove the spaces and add padding characters. I have yet to see any documentation on the Dropbox implementation, but I assume they always generate 16 binary octets that are base32 encoded into 26 characters like the codes that I have seen. The code is the cryptographic key used for the HMAC-SHA1 computation described in the RFC 6238 that specify OATH TOTP. If you study the base32 encoding you discover that 26 characters needs six pad characters. So converted into proper base32, the string would be gr6d5br725s6vnckv4vlhlaore======. Now generating OTPs are easy, see below.

jas@latte:~$ oathtool --verbose --totp --base32 "gr6d5br725s6vnckv4vlhlaore======"
Hex secret: 347c3e863fd765eab44aaf2ab3ac0e89
Base32 secret: GR6D5BR725S6VNCKV4VLHLAORE======
Digits: 6
Window size: 0
Step size (seconds): 30
Start time: 1970-01-01 00:00:00 UTC (0)
Current time: 2012-08-27 21:22:54 UTC (1346102574)
Counter: 0x2ACA9C5 (44870085)
125860
jas@latte:~$

Dropbox s implementation is robust in that it requests a valid OTP from me, generated using the secret they just displayed, before proceeding. This verifies that the user was able to import the key correctly, and that the users OATH TOTP implementation appears to work. If I type in the OTP generated from oathtool this way, it allowed me to enable two-factor authentication and I agreed. From that point, signing into the Dropbox service will require an OTP. I invoke the tool, using the same arguments as above, and the tool will use the current time to compute a fresh OTP. Reflecting on how things could work smoother, I suppose oathtool could be more permissive when it performs the base32 decoding so that the user doesn t have to fix the base32 spacing/padding manually. I ll consider this for future releases.

From Ken Starks, of Helios Project / Reglue

From the desk of just-so-you-know.....

Thomas Knight and I have agreed that the fund drive to aid in paying for necessary surgery for me should be halted. I will do a full blog about this entire effort this Monday but suffice it to say, you have donated more than enough to take care of my immediate needs and those down the road. Asking for anything more would be taking advantage of a loving and generous community. While it is far from adequate, the only thing I can offer you is my eternal thanks. It just seems so....small of a thing to give in return.

They will not stop the Indiegogo campaign until it reaches its time limit unfortunately so that will remain in effect for the next 30-some hours. Please do not donate anything further as I have more than enough to cover my expenses. I will explain more about that on my blog Monday.

If you helped spread the word about this campaign, please pass this posting along with the same intensity. I would deeply appreciate it.

See also now: update from Ken:

http://linuxlock.blogspot.co.uk/2012/08/of-roller-coasters-cancer-and-linux.html
==

Donations for Ken himself may be over: the work of Helios/Reglue still remains good, important and useful - the world benefits for investment in education. I would urge that this is still a worthwhile charity to contribute to as you get Linux into the hands of young people and the disadvantaged who can then USE it.

And here is it, after just six weeks of waiting!
As you can see on the image it is as long as a cigarette lighter. Now I just have to find some free time to play with the Debian image and to install my little music station :)

jenkins-debian-glue is an open source project of mine which recently celebrated its first birthday and it s time to finally write about it. jenkins-debian-glue allows you to build Debian and Ubuntu packages directly from the Jenkins continuous integration system. It retrieves package sources from a version control repository, adjusts debian/changelog (handle version number + mention changes that took place) and builds according source and binary packages out of it. Its lintitan integration provides Q/A reports about the resulting source and binary Debian packages. It started as a small pet project of mine to get integration of Debian packaging inside Jenkins. I mainly had the needs for the Grml project in mind and starting with Grml 2011.12 every release (including also all the daily builds) was built using Jenkins since then. It turned out that my project would also be a perfect match for one of my customers, Sipwise GmbH. In December 2011 the sip:provider 2.4 was the first stable release that was built 100% through Jenkins and featuring jenkins-debian-glue. Thanks to special needs and the open source friendliness of Sipwise I could invest further time into the project. Recently the project got even some further drive thanks to interest by some fellow Debian Developers, most notably are the icinga, nagios-plugins, packages and the PostgreSQL in Debian Hackathon. Now if you re also interested in it: there s an automated deployment procedure available for your service to get started with the whole jenkins-debian-glue and Jenkins stack in less than 10 minutes, working just fine on Debian as well as Ubuntu. For further details please head over to jenkins-debian-glue.org or check out this 6:36min screencast (safe for work, no audio ): <iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/9asp2ZvH90A?autohide=1&amp;showinfo=0" width="560"></iframe> This embedded video doesn t work for you? Try heading over to YouTube.

Almost a year has passed since my talk at pgconf.eu 2011 in Amsterdam on Connecting the Debian and PostgreSQL worlds, and unfortunately little has happened on that front, mostly due to my limited spare time between family and job. pgapt.debian.net is up and running, but got few updates and is lagging behind on PostgreSQL releases. Luckily, we got the project moving. Dimitri Fontaine and Magnus Hagander suggested to do a face-to-face meeting, so we got together at my house for two days last week and discussed ideas, repository layouts, build scripts, and whatnot to get all of us aligned for pushing the project ahead. My employer sponsored my time off work for that. We almost finished moving the repository to postgresql.org infrastructure, barring some questions of how to hook the repository into the existing mirror infrastructure; this should get resolved this week. The build server running Jenkins is still located on my laptop, but moving this to a proper host will also happen really soon now. We are using Mika Prokop's jenkins-debian-glue scripts for driving the package build from Jenkins. The big plus point about Jenkins is that it makes executing jobs on different distributions and architectures in parallel much easier than a bunch of homemade shell scripts could get us with reasonable effort. Here's a list of random points we discussed:

• We decided to go for "pgdg" in version numbers and distribution names, i.e. packages will have version numbers like 9.1.5-1.pgdg+1, with distributions wheezy-pgdg, squeeze-pgdg, and so on.
• There will be Debian-testing-style distributions called like wheezy-pgdg-testing that packages go into for some time before they get promoted to the "live" distributions.
• PostgreSQL versions out of support (8.2 and below) will not be removed from the repository, but will be moved to distributions called like wheezy-pgdg-deprecated. People will still be able to use them, but the naming should make it clear that they should really be upgrading.
• We have a slightly modified (compared to Debian unstable) postgresql-common package that sets the "supported-versions" to all versions supported by the PostgreSQL project. That will make the postgresql-server-dev-all package pull in build-dependencies for all server versions, and make extension module packages compile for all of them automatically. (Provided they are using pg_buildext.)
• There's no Ubuntu support in there yet, but that's mostly only a matter of adding more cowbuilder chroots to the build jobs. TBD soon.

We really aim at using unmodified packages from Debian as much as possible, and in fact this project doesn't mean to replace Debian's PostgreSQL packaging work, but to extend it beyond the number of server versions (and Debian and Ubuntu versions covered) supported. The people behind the Debian and Ubuntu packages, and this repository are mostly the same, so we will claim that "our" packages will be the same quality as the "original" ones. Big thanks go to Martin Pitt for maintaining the postgresql-common testsuite that really covers every aspect of running PostgreSQL servers on Debian/Ubuntu systems. Stay tuned for updates! :)

A while back mdz blogged about challenges facing Ubuntu and other Linux distributions. He raises the point that runtime libraries for Python / Ruby etc have a unique set of issues because they tend to have their own packaging systems. Merely a month later he attended Debconf 2010 where a presentation was given on the issues that Java packages have on Dpkg based systems. Since then the conversation seems to have dried up. I ve been reminded of it recently in discussions within Canonical looking at how we deploy web services. Matt suggested some ways forward, including:

• Decouple applications from the core
• Treat data as a service (rather than packages) get data live from the web rather than going web -> distro-package -> user machines.
• Simplify integration between packaging systems (including non-packaged things)

I think its time we revisit and expand on those points. Nothing much has changed in how Ubuntu or other distributions approach integration with other packaging systems but the world has kept evolving. Internet access is growing ever more ubiquitous, more platforms are building packaging systems clojure, scala, node.js, to name but three, and a substantial and ever growing number of products expect to operate in a hybrid fashion with an evolving web service plus a local client which is kept up to date via package updates. Twitter, Facebook and Google Plus are three such products. Android has demonstrated a large scale app store on top of Linux, with its own custom packaging format. In order to expand them, we need some background context on the use cases that these different packaging systems need to support. Platforms such as antivirus scanners, node.js, Python, Clojure and so forth care a great deal about getting their software out to their users. They care about making it extremely easy to get the latest and greatest versions of their libraries. I say this because the evidence is all around us: every successful development community / product has built a targeted package management system which layers on top of Windows, and Mac OSX, and *nux. The only rational explanation I can come up for this behaviour is that the lower level operating system package management tools don t deliver what they need. E.g. this isn t as shallow as wanting a packaging system written in their own language, which would be easy to write off as parochialism rather than a thoughtful solution to their problems. In general packaging systems provide a language for shipping source or binary form, from one or more repositories, to users machines. They may support replications, and they may support multiple operating systems. They generally end up as graph traversal engines, pulling in dependencies of various sorts you can see the DOAP specification for an attempt at generic modelling of this. One problem that turns up rapidly when dealing with Linux distribution package managers is that the versions upstream packages have, and the versions a package has in e.g. Debian, differ. They differ because at some stage, someone will need to do a new package for the distribution when no upstream change has been made. This might be to apply a local patch, or it might be to correct a defect caused by a broken build server. Whatever the cause, there is a many to one relationship between the package versions that end users see via dpkg / rpm etc, and those that upstream ship. It is a near certainty that once this happens to a library package, that comparing package versions across different distribution packages becomes hard. You cannot reliably infer whether a given package version is sufficient as a dependency or not, when comparing binary packages between Red Hat and Debian. Or Debian and Ubuntu. The result of this is that even when the software (e.g. rpm) is available on multiple distributions (say Ubuntu and RHEL), or even on multiple operating systems (say Ubuntu and Windows), that many packages will /have/ to be targeted specifically to build and execute properly. (Obviously, compilation has to proceed separately for different architectures, its more the depedency metadata that says and build with version X of dependency Y that has to be customised). The result of this is that there is to the best of my knowledge no distribution of binary packages that targets Debian/Ubuntu and RHEL and Suse and Windows and Mac OS X, although there are vibrant communities building distributions of and for each in isolation. Some of the ports systems come close, but they are still focused on delivering to a small number of platforms. There s nothing that gives 99% coverage of users. And that means that to reach all their users, they have to write or adopt a new system. For any platform X, there is a strong pressure to have the platform be maintainable by folk that primarily work with X itself, or with the language that X is written in. Consider Python there is strong pressure to use C, or Python, and nothing else, for any tools that is somewhat parochial, but also just good engineering reducing variables and making the system more likely to be well maintained. The closest system I know of Steam is just now porting to Ubuntu (and perhaps Linux in general), and has reached its massive popularity by focusing entirely on applications for Windows, with Mac OSX a recent addition. Systems like pypi which have multi platform eggs do target the wide range of platforms I listed above, but they do so both narrowly and haphazardly: whether a binary or source package is available for a given platform is up to the maintainer of the package, and the packages themselves are dealing with a very narrow subset of the platforms complexity: Python provides compilation logic, they don t create generic C libraries with stable ABI s for use by other programs, they don t have turing complete scripts for dealing with configuration file management and so forth. Anti virus updaters similarly narrow the problem they deal with, and add constraints on latency- updates of anti virus signatures are time sensitive when a new rapidly spreading threat is detected. A minor point, but it adds to the friction of considering a single packaging tool for all needs is the different use cases of low level package management tools like dpkg or rpm vs the use cases that e.g. pypi has. A primary use case for packages on pypi is for them to be used by people that are not machine administrators. They don t have root, and don t want it. Contrast that with dpkg or rpm where the primary use case (to date) is the installation of system wide libraries and tools. Things like man page installation don t make any sense for non-system-wide package systems, whereas they are a primary feature for e.g. dpkg. In short, the per-platform/language tools are (generally):

1. Written in languages that are familiar to the consumers of the tools.
2. Targeted at use on top of existing platforms, by non-privileged users, and where temporary breakage is fine.
3. Intended to get the software packaged in them onto widely disparate operating systems.
4. Very narrow they make huge assumptions about how things can fit together, which their specific language/toolchain permits, and don t generalise beyond that.
5. Don t provide for security updates in any specific form: that is left up to folk that ship individual things within the manager.

operating system package managers:

1. Are written in languages which are very easy to bootstrap onto an architecture, and to deploy onto bare metal (as part of installation).
2. Designed for delivering system components, and to avoid be able to upgrade the toolchain itself safely.
3. Originally built to install onto one operating system, ports to other operating systems are usually fragile and only adopted in niche.
4. Are hugely broad they install data, scripts, binaries, and need to know about late binding, system caches etc for every binary and runtime format the operating system supports
5. Make special provision to allow security updates to be installed in a low latency fashion, without requiring anything consuming the package that is updated to change [but usually force-uninstalling anything that is super-tightly coupled to a library version].

Anti virus package managers:

1. Exist to update daemons that run with system wide escalated privileges, or even file system layer drivers.
2. Update datasets in realtime.
3. Without permitting updates that are produced by third parties.

Given that, lets look at the routes Matt suggested Decoupling applications from the core as a strategy makes an assumption that the core and applications are partitionable. If they are not, then applications and the core will share common elements that need to be updated together. Consider, for instance, a Python application. If you run with a system installed Python, and it is built without zlib for some reason, but the Python application requires zlib, you have a problem. A classic example of this problem is facing Ubuntu today, with all the system provided tools moving to Python 3, but vast swathes of Python applications still being unported to Python 3 at all. Currently, the Python packaging system virtualenv/buildout + distribute don t provide a way to install the Python runtime itself, but will happily install their own components for everything up the stack from the runtime. Ubuntu makes extensive use of Python for its own tools, so the system Python has a lot of packages installed which buildout etc cannot ignore this often leads to issues with e.g. buildout, when the bootstrap environment has (say) zope.interfaces, but its then not accessible from the built-out environment that disables the standard sys.path (to achieve more robust separation). If we want to pursue decoupling, whether we build a new package manager or use e.g. virtualenv (or gem or npm or ), we ll need to be aware of this issue and perhaps offer, for an extended time, a dedicated no-frills, no-distro-packages install, to avoid it, and to allow an extended supported period for application authors without committing to a massive, distro sponsored porting effort. While its tempting to say we should install pip/npm/lein/maven and other external package systems, this is actually risky: they often evolve sufficiently fast that Ubuntu will be delivering an old, incompatible version of the tool to users well before Ubuntu goes out of support, or even befor the next release of Ubuntu. Treating data as a service. All the cases I ve seen so far of applications grabbing datasets from the web have depended on web infrastructure for validating the dataset. E.g. SSL certificates, or SSL + content checksums. Basically, small self-rolled distribution systems. I m likely ignorant of details here, and I depend on you, dear reader, to edumacate me. There is potential value in having data repackaged, when our packaging system has behind-firewall support, and the adhoc system that (for instance) a virus scanner system has does not. In this case, I specifically mean the problem of updated a machine which has no internet access, not even via a proxy. The challenge I see it is again the cross platform issue: The vendor will be supporting Ubuntu + Debian + RHEL + Suse, and from their perspective its probably cheaper to roll their own solution than to directly support dpkg + rpm + whatever Apple offer + Windows the skills to roll an adhoc distribution tool are more common than the skills to integrate closely with dpkg or rpm What about creating a set of interfaces for talking to dpkg / rpm / the system packagers on Windows and Mac OSX ? Here I think there is some promise, but it needs as Matt said careful thought. PackageKit isn t sufficient, at least today. There are, I think, two specific cases to cater to:

1. The anti-virus / fresh data set case.
2. The egg/gem/npm/ specific case.

For the egg/gem/npm case, we would need to support a pretty large set of common functionality, on Windows/Mac OSX / *nux (because otherwise upstream won t adopt what we create: losing 90% of their users (windows) or 5% (mac) isn t going to be well accepted . We d need to support multiple installations (because of mutually incompatible dependencies between applications), and we d need to support multiple language bindings in some fashion some approachable fashion where the upstream will feel capable of fixing and tweaking what we offer. We re going to need to support offline updates, replication, local builds, local repositories, and various signing strategies to match the various tradeoffs made by the upstream tools. For the anti-virus / fresh data case, we d need to support a similar set of operating systems, though I strongly suspect that there would be more tolerance for limited support in that most things in that space either have very platform specific code, or they are just a large-scale form of the egg/gem/npm problem, which also wants easy updates. What next? We should validate this discussion with at least two or three upstreams. Find out whats missing I suspect a lot and whats wrong I hope not much . Then we ll be in a position to decide if there is a tractable, widespread solution *possible*. Separately, we should stop fighting with upstreams that have their own packaging systems. They are satisfying different use cases than our core distro packaging systems are designed to solve. We should stop mindlessly repackaging things from e.g. eggs to debs, unless we need that specific thing as part of the transitive runtime or buildtime dependencies for the distribution itself. In particular, if us folk that build system packaging tools adopt and use the upstream application packaging tools, we can learn in a deep way the (real) advantages they have, and become more able to reason about how to unify the various engineering efforts going into them and perhaps even eventually satisfy them using dpkg/rpm on our machines.

This is the result of an old meme, but it is still quite interesting:

What American accent do you have? Your Result: The Northeast Judging by how you talk you are probably from north Jersey, New York City, Connecticut or Rhode Island. Chances are, if you are from New York City (and not those other places) people would probably be able to tell if they actually heard you speak.
Philadelphia
Boston
The Inland North
North Central
The South
The West
The Midland
What American accent do you have? Quiz Created on GoToQuiz

For anybody that doesn't know - Ken Starks is the man behind the Helios Project - recycling computers, putting Linux on them, donating them to youngsters and the needy in Austin Texas.

He has a cancer diagnosis but his disability pension is enough to defeat his state provided insurance. Now he himself needs the help of the community.

More details here: http://linuxlock.blogspot.co.uk/2012/08/something-ive-been-putting-off-all-day.html and his partner's post above.

and here: Thomas A. Knight, who is setting up donations.

http://thomasaknight.com/blog.php?id=71

UPDATE:

There is now also a donate button at the Blog of Helios (linuxlock.blogspot.com).

Enough has been raised so far to buy Ken an appropriate monitor - because of the effects of radiotherapy, he's been unable to tolerate using a monitor with backlighting.

One donor has also stepped in to buy a month's drug treatment.

The initial target -US $5000 - has been met but The cost of an operating theatre session is at least US $50,000. All donations continue to be gratefully received.

Should efforts for raising funds for Ken himself be unsuccessful, all surplus funds raised will be ploughed back into the Helios Project (now known as Reglue following a recent merger with another local computer charity).

The Helios Project has been associated with Software in the Public Interest [SPI - also the umbrella organisation supporting Debian] for some years.

UPDATE2 - From Thomas A. Knight's blog referenced above:

By Thomas A. Knight on Sun 19 Aug 2012 07:33:49 am $11,000 so far, and still going strong. The outpouring of support for this is amazing. My most humble thanks to all contributors.

Even though we are still far from our goal, this has been far more successful than I ever thought possible. Thank you.

UPDATE3 - From Ken Starks, Sunday 26 August 2012

The amount of money needed has been raised. Donations to Helios Project/Reglue are welcome, as ever - but Ken's immediate needs are satisfactorily met and he himself doesn't wish to profit further from the community's goodwill. As he says, he can't thank us enough
More news at http://linuxlock.blogspot.com is due on 27/08/2012

good news: I'm seeing more & more people contributing to RC bugs in the BTS. here are my own contributions for the past week:

• #656552 zope2.12-sandbox: "zope2.12-sandbox: fails to install, remove and install again"
  add info to bug report
• #670405 ekiga: "ekiga: Ekiga crashes on startup"
  add info to bug report
• #673370 centerim: "centerim: Crash at startup (suspect login msn)"
  add info to bug report, then close on submitter's behalf
• #683061 ntp: "ntp: missing init script dependency on $named"
  sponsor NMU from Ivo De Decker (fix init script), upload to DELAYED/2, then cancelled by maintainer after severity change
• #684019 python-liblcms: "python-liblcms: static library in /usr/share"
  re-enable dropping of .a and .la files from python package, upload to DELAYED/2
• #684024 src:python-adodb: "python-adodb: broken binary-indep target"
  apply patches from Evgeni Golov (d/rules targets) and Jakub Wilk (python-support handling), upload to DELAYED/2
• #684078 wv2: "calligra: Buffer overflow"
  apply modified patch from KDE, upload to DELAYED/2
• #684150 python-wxgtk2.8: "python-wxgtk2.8 breaks upgrade from squeeze to wheezy"
  add info to bug report
• #684180 angband: "angband: removes files that were installed by another package: /usr/share/angband/*"
  don't remove directory belonging to other package in postrm, upload to DELAYED/2
• #684488 puppet-lint: "puppet-lint not working with ruby1.9.1"
  send a patch to the BTS

This vision of the future at Sam's No. 3 in Denver suggests that we will have ample blackboards after the apocalypse. And that the contrast will be greatly improved in direct sunlight.

There are plenty of times where it is nice to have Linux transmit things out a radio. One obvious example is the digital communication modes, where software acts as a sort of modem. A prominent example of this in Debian is fldigi. Sometimes, it is nice to transmit voice instead of a digital signal. This is called voice keying. When operating a contest, for instance, a person might call CQ over and over, with just some brief gaps. Most people that interface a radio with a computer use a sound card interface of some sort. The more modern of these have a simple USB cable that connects to the computer and acts as a USB sound card. So, at a certain level, all that you have to do is play sound out a specific device. But it s not quite so easy, because there is one other wrinkle: you have to engage the radio s transmitter. This is obviously not something that is part of typical sound card APIs. There are all sorts of ways to do it, ranging from dedicated serial or parallel port circuits involving asserting voltage on certain pins, to voice-activated (VOX) circuits. I have used two of these interfaces: the basic Signalink USB and the more powerful RigExpert TI-5. The Signalink USB integrates a VOX circuit and provides cabling to engage the transmitter when VOX is tripped. The TI-5, on the other hand, emulates three USB serial ports, and if you raise RTS on one of them, it will keep the transmitter engaged as long as RTS is high. This is a more accurate and precise approach. VOX-based voice keying with the Signalink USB But let s first look at the Signalink USB case. The problem here is that its VOX circuit is really tuned for digital transmissions, which tend to be either really loud or completely silent. Human speech rises and falls in volume, and it tends to rapidly assert and drop PTT (Push-To-Talk, the name for the control that engages the radio s transmitter) when used with VOX. The solution I hit on was to add a constant, loud tone to the transmitted audio, but one which is outside the range of frequencies that the radio will transmit (which is usually no higher than 3kHz). This can be done using sox and aplay, the ALSA player. Here s my script to call cq with Signalink USB:

#!/bin/bash
# NOTE: use alsamixer and set playback gain to 99
set -e
playcmd ()  
        sox -V0 -m "$1" \
           "  sox -V0 -r 44100 $1 -t wav -c 1 -   synth sine 20000 gain -1" \
            -t wav -   \
           aplay -q  -D default:CARD=CODEC
 
DELAY=$ 1:-1.5 
echo -n "Started at: "
date
STARTTIME= date +%s 
while true; do
        printf "\r"
        echo -n $(( ( date +%s -$STARTTIME) / 60))
        printf "m/$ DELAY s: TRANSMIT"
        playcmd ~/audio/cq/cq.wav
        printf "\r"
        echo -n $(( ( date +%s -$STARTTIME) / 60))
        printf "m/$ DELAY s: off         "
        sleep $DELAY
done

Run this, and it will continuously play your message, with a 1.5s gap in between during which the transmitter is not keyed. The screen will look like this:

Started at: Fri Aug 24 21:17:47 CDT 2012
2m/1.5s: off

The 2m is how long it s been going this time, and the 1.5s shows the configured gap. The sox commands are really two nested ones. The -m causes sox to merge the .wav file in $1 with the 20kHz sine wave being generated, and the entire thing is piped to the ALSA player. Tweaks for RigExpert TI-5 This is actually a much simpler case. We just replace playcmd as follows:

playcmd ()  
        ~/bin/raiserts /dev/ttyUSB1 'aplay -q -D default:CARD=CODEC' < "$1"
 

Where raiserts is a program that simply keeps RTS asserted on the serial port while the given command executes. Here's its source, which I modified a bit from a program I found online:

/* modified from
 * https://www.linuxquestions.org/questions/programming-9/manually-controlling-rts-cts-326590/
 * */
#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <unistd.h>
#include <sys>ioctl.h>
#include <sys< sys="">types.h>
#include <sys>stat.h>
#include <fcntl.h>
static struct termios oldterminfo;
void closeserial(int fd)
 
    tcsetattr(fd, TCSANOW, &oldterminfo);
    if (close(fd) < 0)
        perror("closeserial()");
 
int openserial(char *devicename)
 
    int fd;
    struct termios attr;
    if ((fd = open(devicename, O_RDWR)) == -1)  
        perror("openserial(): open()");
        return 0;
     
    if (tcgetattr(fd, &oldterminfo) == -1)  
        perror("openserial(): tcgetattr()");
        return 0;
     
    attr = oldterminfo;
    attr.c_cflag  = CRTSCTS   CLOCAL;
    attr.c_oflag = 0;
    if (tcflush(fd, TCIOFLUSH) == -1)  
        perror("openserial(): tcflush()");
        return 0;
     
    if (tcsetattr(fd, TCSANOW, &attr) == -1)  
        perror("initserial(): tcsetattr()");
        return 0;
     
    return fd;
 
int setRTS(int fd, int level)
 
    int status;
    if (ioctl(fd, TIOCMGET, &status) == -1)  
        perror("setRTS(): TIOCMGET");
        return 0;
     
    status &= ~TIOCM_DTR;   </sys>* ALWAYS clear DTR */
    if (level)
        status  = TIOCM_RTS;
    else
        status &= ~TIOCM_RTS;
    if (ioctl(fd, TIOCMSET, &status) == -1)  
        perror("setRTS(): TIOCMSET");
        return 0;
     
    return 1;
 
int main(int argc, char *argv[])
 
    int fd, retval;
    char *serialdev;
    if (argc < 3)  
        printf("Syntax: raiserts /dev/ttyname 'command to run while RTS held'\n");
        return 5;
     
    serialdev = argv[1];
    fd = openserial(serialdev);
    if (!fd)  
        fprintf(stderr, "Error while initializing %s.\n", serialdev);
        return 1;
     
    setRTS(fd, 1);
    retval = system(argv[2]);
    setRTS(fd, 0);
    closeserial(fd);
    return retval;
 

This compiles to an executable less than 10K in size. I love it when that happens. So these examples support voice keying both with VOX circuits and with serial-controlled PTT. raiserts.c could be trivially modified to control other serial pins as well, should you have an interface which uses different ones.

Here are a few things to remember about cowbuilder:

If you run cowbuilder through sudo, and you want to build a source package whose result should be available to the user who initiated the build, then

• you should have "BUILDRESULTUID=the_user's_id" in ~/.pbuilderrc, and
  
• you might want to invoke cowbuilder with

'sudo cowbuilder --build the_pack_to_build.dsc --buildresult destination_dir_for_build_results'

If you want to login into a chroot environment in which you'd like to see part of your directory alongside the unpacked source tree of your package, then invoke cowbuilder with

sudo cowbuilder --login --bindmounts /path/to/the/dir/you/want

Your base.cow directory can be updated/changed manually with

sudo cowbuilder --login --save-after-login

You can update the base.cow directory with

sudo cowbuilder --update

That's about it.

Also, noteworthy tip: ccache might not work correctly in the cowbuilder chroot.