Debian is a big system. At the time of writing, the unstable distribution has more than 20,000 source packages, building more then 40,000 binary packages on the amd64 architecture. The number of inter-dependencies between binary packages is mind-boggling: the entire dependency graph for the amd64 architecture contains a little more than 375,000 edges. If you want to expand the phrase "package A depends on package B", there are more than 375,000 pairs of packages A and B that can be used. Every one of these dependencies is a potential source of problems. A library changes the semantics of a function call, and then programs using that library that assumed the previous semantics can start to malfunction. A new version of your favorite programming language comes out, and a program written in it no longer works. The number of ways in which things can go wrong goes on and on. With an ecosystem as big as Debian, it is just impossible to stop these problems from happening. What we can do is trying to detect when they happen, and fix them as soon as possible. The Debian Continuous Integration project was created to address exactly this problem. It will continuously run test suites for source packages when any of their dependencies is updated, as well as when a new version of the package itself is uploaded to the unstable distribution. If any problems that can be detected by running an automated test suite arise, package maintainers can be notified in a matter of hours. Antonio Terceiro has posted on his blog an introduction to the project with a more detailed description of the project, its evolution since January 2014 when it was first introduced, an explanation of how the system works, and how maintainers can enable test suites for their packages. You might also want to check the documentation directly.

Debian is a big system. At the time of writing, looking at my local package list caches tells me that the unstable suite contains 21306 source packages, and 42867 binary packages on amd64. Between these 42867 binary packages, there is an unthinkable number of inter-package dependencies. For example the dependency graph of the ruby packages contains other 20-something packages. A new version of any of these packages can potentially break some functionality in the ruby package. And that dependency graph is very small. Looking at the dependency graph for, say, the rails package will make your eyes bleed. I tried it here, and GraphViz needed a PNG image with 7653 10003 pixels to draw it. It ain t pretty. Installing rails on a clean Debian system will pull in another 109 packages as part of the dependency chain. Again, as new versions of those packages are uploaded the archive, there is a probability that a backwards-incompatible change, or even a bug fix which was being worked around, might make some funcionality in rails stop working. Even if that probability is low for each package in the dependency chain, with enough packages the probability of any of them causing problems for rails is quite high. And still the rails dependency chain is not that big. libreoffice will pull in another 264 packages. gnome will pull in 1311 dependencies, and kde-full 1320 (!). With a system this big, problems will arrive, and that s a fact of life. As developers, what we can do is try to spot these problems as early as possible, and fixing them in time to make a solid release with the high quality Debian is known for. While automated testing is not the proverbial Silver Bullet of Software Engineering, it is an effective way of finding regressions. Back in 2006, Ian Jackson started the development of autopkgtest as a tool to test Debian packages in their installed form (as opposed to testing packages using their source tree). In 2011, the autopkgtest test suite format was proposed as a standard for the Debian project, in what we now know as the DEP-8 specification. Since then, some maintainers such as myself started experimenting with DEP-8 tests in their packages. There was an expectation in the air that someday, someone would run those tests for the entire archive, and that would be a precious source of QA information. Durign the holiday break last year, I decided to give it a shot. I initially called the codebase dep8. Later I renamed it to debci, since it could potentially also run other other types of test suites in the future. Since early January, ci.debian.net run an instance of debci for the Debian Project. The Debian continuous Integration will trigger tests at most 4 times a day, 3 hours after each dinstall run. It will update a local APT cache and look for packages that declare a DEP-8 test suite. Each package with a test suite will then have its test suite executed if there was any change in its dependency chain since the last test run. Existing test results are published at ci.debian.net every hour, and at the end of each batch a global status is updated. Maintainers can subscribe to a per package Atom feed to keep up with their package test results. People interested in the overall status can subscribe to a global Atom feed of events. Since the introduction of Debian CI in mid-January 2014, we have seen an amazing increase in the number of packages with test suites. We had little less than 200 packages with test suites back then, against around 350 now (early June 2014). The ratio of packages passing passing their test suite has also improved a lot, going from less than 50% to more than 75%. There is documentation available, including a FAQ for package maintainers with further information about how the system works, how to declare test suites in their packages and how to reproduce test runs locally. Also available is development information about debci itself, to those inclined to help improve the system. This is just the beginning. debci is under a good rate of development, and you can expect to see a constant flux of improvements. In special, I would like to mention a few people who are giving amazing contributions to the project:

• Martin Pitt has been working on improving debci to support parallel and distributed workers. Being the current autopkgtest maintainer, Martin also already got some bug fixes and fixes into autopkgtest motivated by debci use cases.
• Brandon Fairchild is a GSOC student working on improving the debci web interface to provide more useful information, display information for multiple suites and architectures, plus making the UI work even without Javascript enabled.
• Lucas Kanashiro is another GSOC student, who is working on investigating patterns among packages that fail their test suites, so that we can figure out how we can fix them, or if there are classes of failures that are actually caused by problems in the debci infrastructure.

Zoe slept pretty well last night. She only woke up briefly at 4am because Cowie had fallen out of bed and she couldn't find her. Today was the last Playgroup of the term. Megan, her little sister and her Dad came as well to check it out, which was nice, because Zoe then had someone to actively play with in addition to me. After Playgroup, we went to the adjacent Bulimba Memorial Park with Megan, and then had some lunch at Grill'd. Megan's Dad wanted to do some work on their house while Megan's little sister napped, so I offered to give Megan a play date at our place. The plan was to watch a movie and chill out. The girls picked Ratatouille and I made a batch of popcorn for them. Unfortunately Megan seemed to be less of a square eyes than Zoe, and she lost interest after a bit, so we stopped watching the movie and moved out to the balcony to do some craft. Zoe had been wanting to make a crown for Mummy's boss for a while, so we made a couple of crowns with the hot glue gun. I had bought this bag of mixed craft "jewels" and it's probably the best single craft thing I've bought. Zoe loves gluing them onto everything. After that, Zoe pulled out the bag of coloured foil confetti. If the gems were the best thing I've bought, this would have to be the worst. So far, all it's done is leak in the drawer it's been stored in, and I've been avoiding using it because it was going to be messy. Today, Zoe wanted to glue it onto the outside of her cardboard box, so I decided to give in and embrace the mess, and boy, did we make a mess. It probably ended up being the longest bit of cooperative play the girls did. They'd alternate between handing each other a fistful of confetti while I applied globs of glue where directed. Probably about 10 percent of each handful ended up stuck to the rocket, so the balcony looked like quite a mess by the end of it all, but at least it was a dry mess, so I could just vacuum it all up. I suspect I'll be encountering dregs for quite a while, because I doubt it's stuck to the cardboard particularly well. After that, the girls played indoors for a bit, and watched a bit more of the movie, but Megan seemed to be scared of Anton Ego, so I think that was why it wasn't holding her attention. The other activity that the girls seemed to thoroughly enjoy was tearing around the living room squealing while they took turns at throwing a grapefruit-sized beach ball at me, and I threw it back at them. Jason came back to pick up Megan, and I started dinner. Not that long after Megan left, Sarah arrived to watch Zoe for me so I could go visit my cousin in hospital. I had dinner on the table pretty much as soon as she walked in the door, and headed out.

The DebConf team is pleased to announce the release of the DebConf13 Final Report. It s a 32-page document which gives the reader an idea about the conference as a whole. It includes words from the Debian Project Leader, descriptions of talks, a section about the Debian Birthday Party, attendee impressions, budgeting and DebConf13 in numbers. If you attended Debconf13, the report may refresh some of your memories and bring you closer to the organization team work. If not, it will certainly encourage you to be part of future Debian events. We thank the Matanel foundation, Google, the Republic and Canton of Neuch tel, and all other DebConf13 sponsors for their support that made the event possible. The DebConf team

More and more packages are getting autopkgtest aka DEP-8 testsuites these days. Thanks to Antonio Terceiro, there is ci.debian.net" running the tests. Last weekend, I've added a "CI" column on DDPO that shows the current test results for your packages. Enjoy, and add tests to your packages!

AddThis:

Categories:

• Debian-Blog
• Tools

Keywords:

• laptop-mode-tools

So... Well, contrary to the popular sentiment in Planet Debian, this year I'm very sorry to inform that... This is the first DebConf I miss in ten years, so... Yes, it's a big bummer for me. I'm not attending because this year, DebC(amp onf) coincide with the two first weeks of classes at my university And as a new teacher, I cannot afford to miss it! Anyway, but that should not stand in the way to attend a nice Debian 20th anniversary party! Parties will be held around the world. (Didn't find your city? Plan something and add it *now!*). In Mexico City, the nice guys at the very interesting Rancho Electr nico hackerspace took the lead, and organized the following activities: Don't you yet know the hackerspace? You should go there! It's in a very centric location, just two blocks West from Metro San Antonio Abad (Juan Lucas Lassaga 114, col. Obrera). And the only two times I have been there, it has been good fun. Surely this Saturday we can have a nice party as well! The planned activities are from 13:30 to 20:30. See you there!

I have been occasionally working on some Debian-related tasks. Chrony One of those was to get chrony is a slightly better shape, by using, at least, a patch system (indeed, I "modernized" its packaging with the format "3.0 (quilt)"), put it in a git repository and would like to receive some comments on what I have so far. The bug Debian bug #694690 contains a very brief description of my intentions and of the problems that I see in the current package. IMVHO, it is a very nice NTP client and server and it could even be used as the default for Debian, once it gets in shape. There is at least another high-profile distribution, namely Fedora, that switched to chrony as its default NTP software. We can certainly take a look at what they are doing and join forces here. MongoDB Another package where I spent some time was with mongodb: MongoDB is a tricky package that is only built for 2 arches: amd64 and i386. The version in unstable for i386 was 2.0.x (roughly the same as for wheezy), which the version in unstable for amd64 was 2.4.1, which has many features that 2.0 lacks. The packaging of it is a bit tricky, since the source tree has bazillion embedded/convenience libraries (e.g., Google's v8, Mozilla's spidermonkey, BOOST, Google's Snappy, PCRE 3 etc.). Up to version 2.4.1-2, it used all these convenience copies, which is of course, a problem for a distribution like Debian. I changed part of the build process to use the libraries that we already have in Debian and, as Antonin Kral uploaded this newer version, unsurprisingly the binary packages are smaller (especially if you take into account that a handful of the libraries may already be installed on the system). A few hours later, Antonin uploaded a new upstream version, which means that we now have better MongoDB packages to play with. I am, in fact, really playing with MongoDB as my first NoSQL database, since 10gen is giving an introductory course on how it works and my motivation was to get what we have in Debian in shape for the course. You can say that I am a firm believer of the "eat your own dogfood" principle. Regarding MongoDB only being built for i386 and amd64, the BTS has a patch to enable building for kFreeBSD, but the patch is for the 2.0 series and the code has changed so drastically in relation to the 2.4 series that there is no hope of it applying. It would be super nice to have MongoDB working on kFreeBSD and on HURD also, though. nocache There is a very nice command line program called nocache that was packaged by Dmitry Smirnov (and just approved by the FTP masters!) whose packaging I briefly reviewed per Dmitry's request and this is an amazing utility whose purpose is to bypass/minimize file system caching for a program. This is especially useful when you are making backups (reading lots of files that would, otherwise, fill the filesystem cache, even if they are not used frequently) or if you are just streaming one file (possibly larger than the system's RAM) to another computer and you have no need to use the file immediately after that. It performs its job by using the LD_PRELOAD mechanism and using posix_fadvise's flag POSIX_FADV_DONTNEED for the files that will be touched. Post note Oh, just one aside: for the readers of Debian Planet and other aggregation services which are not Debian Developers/Maintainers, I contributed to these packages without being the maintainer of them, just scratching some itches and contributing back what I produced.

Antonia came into the room. Where's Alieta? she asked. We don't know, replied Luda. It was true; we hadn't seen Alieta in quite some time, and we had no idea where she was. Antonia left. Varvara eyed me mischievously and said, You could call her. How? I asked. Touch the grandmother clock and you will figure it out. I touched the clock trepidly. Nothing happened. I opened my mouth to speak, but the word I had been about to say resonated in my mind as if spoken through a comb filter. I concentrated. Alieta, dozens of human-like voices sang over and over in different harmonies. I let go. What was that? I demanded. Clock, Varvara said dismissively. Come on, let's do laundry, Luda grunted. We carried our laundry out to the garage, which is where the washer and dryer lived. Alieta slipped in through one of the open garage doors, and surreptitiously pulled Varvara over for a whispered conversation. Antonia wandered in and squinted in Alieta's general direction. Luda quickly pulled Varvara in front of her. It's just Varvara, she announced. Antonia's eyes glazed over and she went back into the house. Alieta pursed her lips and studied the wall as if there might be some reflective object that had alerted her mother to her presence. Then she grabbed Varvara by the hand, pulled her over to push the buttons that closed the garage doors, and dragged her into the house. I watched the garage doors close. Then I watched the one on the left reverse direction. I opened my mouth to notify someone of this, but the doors reversed direction again, and proceeded to partially open and close as if possessed. I tried to hide behind Luda, without success. Now she was watching as well, as reality seemed to to shimmer and bend. The roof became arched, and there were loud mechanical noises as our environs transformed. When it finished, the place where the garage doors had been was now a wall of screens displaying video as you might encounter in a television store. More disconcertingly, we were in front of a railing which overlooked what appeared to be a car dealership showroom. Luda sucked in her breath. Benjamin Snow, you were into some serious shit, she muttered.

Ruby 2.0 was released today. This new version of the language brings some very interesting features, and according to the core team, an effort has been made to keep source level compartibility with Ruby 1.9. Debian packaging is under way and should hit NEW soon. During the last few days I gave more attention to getting the new multiarch support fixed upstream than to the packaging bits, but the remaining packaging work should be pretty much about housekeeping. Next steps from a Debian point of view (after Wheezy is out) include:

• add Ruby 2.0 support in gem2deb (should be trivial).
• check what packages need fixing to support Ruby 2.0, and which are broken beyond repair.
• figure out how to better exploit a multiarch-enabled Ruby.

Now let s get back to fixing RC bugs and getting Wheezy released. :-)

I've just pushed out the release files for Obnam version 1.3, my backup application, as well as Larch, my B-tree library, and cliapp, my Python framework for command line applications. They are available via my home page (http://liw.fi/). Since Debian is frozen, I am not uploading packages to Debian, but .deb files are available from my personal apt repository for the intrepid. (I will be uploading to Debian again after the freeze. I am afraid I'm too lazy to upload to experimental, or do backports. Help is welcome!) From the Obnam NEWS file:

• When creating files in the backup repository, Obnam tries to avoid NFS synchronisation problems by first writing a temporary file and then creating a hardlink to the actual filename. This works badly on filesystems that do not allow hard links, such as VFAT. If creating the hardlink fails, Obnam now further tries to use the open(2) system call with the O_EXCL flag to create the target file. This should allow things to work with both NFS and VFAT.
• More detailed progress reporting during the backup.
• Manual page now covers the diff subcommand. Patch by Peter Valdemar M rch.
• Speed optimisation patch for backing up files in inode numbering order, from Christophe Vu-Brugier.
• A setuid or setgid bit is now not restored if Obnam is not used by root or the same user as the owner of the restored file.
• Many new settings to control "obnam fsck", mainly to reduce the amount of checking being done in order to make it faster. However, fsck is has lost some features (checks), which will be added back in a future release.
• More frequent fsck progress reporting. Some speed optimisations to fsck.

Bug fixes for Obnam:

• Empty values for extended attributes are now backed up correctly. Previously they would cause an infinite loop.
• Extended attributes without values are now ignored. This is different from attributes with empty values. Reported by Vladimir Elisseev.
• An empty port number in sftp URLs is now handled correctly. Found based on report by Anton Shevtsov.
• A bad performance bug when backing up full systems (starting from the filesystem root directory) has been fixed. At the beginning of each generation, Obnam removes any directories that are not part of the current backup roots. This is necessary so that if you change the backup roots, the old stuff doesn't hang around forever. However, when the backup root is the filesystem root, due to the now-fixed bug Obnam would first remove everything, and then back it up all over again. This "worked", but was quite slow. Thanks to Nix for reporting the problem.
• Obnam now runs GnuPG explicitly with the "no text mode" setting, to override a "text mode" setting in the user's configuration. The files Obnam encrypts need to be treated as binary, not text files. Reported by Robin Sheat.
• A shared B-tree concurrency bug has been fixed: If another instance of Obnam was modifying a shared B-tree, Obnam would crash and abort a backup, possibly leaving lock files lying around. Now a failure to look up a chunk via its checksum is ignored, and the backup continues.
• Bugs in how Python OSError exceptions were being raises have been fixed. Error messages should now be somewhat clearer.
• Unset or wrongly set variable "full" fixed in "obnam diff". Reported by ROGERIO DE CARVALHO BASTOS and patched by Peter Valdemar M rch.
• Setuid and setgid bits are now restored correctly, when restore happens as root. Reported by Pavel Kokolemin.
• Obnam now complains if no backup roots have been specfied.

NEWS for Larch:

• Make fsck progress reporting be a bit more fine grained.

NEWS for cliapp:

• Options in option groups are now included in manual page SYNOPSIS and OPTIONS sections.
• --log=syslog message format improvement by Daniel Silverstone. No longer includes a timestamp, since syslog adds it anyway. Also, the process name is now set on Linux.
• Make the default subcommand argument synopsis be an empty string, instead of None. Reported by Sam Thursfield.
• Meliae memory dumping support has been fixed. Reported by Joey Hess.
• Memory profiling reports can now be done at minimum intervals in seconds, rather than every time the code asks for them. This can reduce the overhead of memory profiling quite a lot.
• If there are any subcommands, cliapp now adds a subcommand called help, unless one already exists.
• For every boolean setting foo, there will no be a --no-foo option to be used on the command line.

in hexadecimal. I have been waiting for a long time to be able to make this joke, and I will still be able to do it for the next 9 years! :-)

DPL August report, posted on d-d-a a while ago (yep, I forgot to blog it up to now!, sorry for the oldies).

---

Dear project members, August has been a month with a good deal of vacations for many of us, including yours truly. Therefore the monthly report of DPL activities will be briefer than usual. Which is good, as it'll leave all my readers more time to do NMUs and fix RC bugs! Ongoing discussions

• Discussion about the new trademark policy has continued on -project. I've collected quite some feedback and summarized it in a request for change that I've passed on to SFLC. I'm waiting for a second draft from them, before reviving the thread.
• on the long-running issue of de-duplicating DebConf infrastructure wrt Debian's, I've been happy to support the proposal of moving DebConf's list to Debian's software and infrastructure. There seems to be interest and consensus, but the DebConf team could probably use a couple more helping hands to make it real
• starting from the practical need of dealing with minified JavaScript files, an interesting discussion sparkled on -devel. It quickly turned in both musing on the notion of archive-wide DFSG-freeness and some new devscript tooling by Andreas Tille. AFAIU some extra testing would be welcome

Assets

• The DFGS-free logo relicensing I've mentioned last month is now on its way. Following advice from SFLC, I've slightly patched the current trademark policy (mainly to clarify scope), just enough to decouple logo relicensing under LGPLv3/CC-BY-SA 3.0 from the finalization of a new trademark policy (see above). I've also verified that the license choice is fine with teams that regularly deal with the logos. Ball is now in SPI camp (as copyright holder). They should finalize the relicensing during the forthcoming board meeting, on September 13th.
• We heard back from the trademark office in Japan, who accepted our request to transfer it from local Debian contributors to SPI. That being mainly a bureaucratic acknowledgement, we'll now need to way for a while until they confirm the transfer has been finalized. My eternal thanks for help with this matter goes to Kenshi Muto.

Core teams

• Manoj Srivastava has stepped down as tech-ctte member. I hereby thank him for his long and valuable service in that capacity. The tech-ctte has now one vacant seat, and I've encouraged present tech-ctte members to propose to me a suitable candidate. In an attempt to promote diversity of views within the tech-ctte, they are now considering various ways to solicit candidatures. You'll hear from them about this soon, I suspect.
• In the meantime, monthly IRC meetings of the tech-ctte are continuing, as you might have noticed from tech-ctte decision reports posted on this list. As it seemed to be lingering, at the last meeting I've solicited progress on the Python maintenance issue.
• The auditors have noticed the unclear situation of the Policy Editor delegation, which seems to rely on a "base" delegation dating back to Antony Towns' office and various subsequent delegation "patches". After discussion with Russ Allbery I've then proceeded to a public "ping" to assess the interest of current editors in continuing their work in such capacity, and encourage new volunteers to apply as editors. Based on the feedback I've got, I'm now preparing a new Policy Editor delegation.

Legal and RC fun

• Solicited by Jonathan Nieder and Helge Kreutzmann, I've looked into #555168 and sought legal advice to answer various questions related to the non-copyrightability of locale data. Aaron Williamson of SFLC has been blazing fast in answering them (thanks!), and Jonathan and Helge has now all the needed information to help addressing that (RC) issue. Keep an eye on the bug log for more details.

Hardware

• I've approved buying 6 console servers to improve DSA ability to act on remote machines, without having to bother^Wrely on local admins when not strictly needed. ~550 USD well spent.

See? It's been quick(er)! Talk to you here next month, with a much lower count of Wheezy RC Bugs on the horizon, hopefully.
Cheers.

---

PS the boring day-to-day activity log for August 2012 is available at master:/srv/leader/news/bits-from-the-DPL.txt.201208

Scratch has finally reached Debian repositories. Scratch is a programming learning environment created by the Lifelong Kindergarten Group at the MIT Media Lab designed to be accessible by young learners (over 8 years old). Scratch makes it easy to create your own interactive stories, animations, games, music, and art through a visual interface based on blocks. Thus, beginners can get results without having to learn to write syntactically correct code first. It is powerful enough to have even been adopted as an entry-level computer language in computer science programs at different universities. Scratch makes use of pieces of code embedded in different blocks that are shaped like puzzle pieces. That way, programming consists on putting different blocks together, which gives immediate visual feedback to the programmer about the correctness of the syntax: If the pieces fit together, then the expression is valid. Scratch programming system is so nice and easy that has been the inspiration of other systems such as MIT App Inventor or Google Blocky.

Scratch animations consist of sprites that are animated by dragging the corresponent blocks into the Scripts area of the Scratch interface. Multiple sprites can be created and interact with one another. Each of the sprites can have different looks (called costumes in Scratch). You can use built-in sprites, load them from files, or draw your own using a drawing tool integrated in the environment. Scratch itself is coded in Squeak, a Smalltalk implementation derived from Smalltalk-80. The Scratch 1.4 source went GPLv2 on March, but there were some incompatibilites with the Squeak Virtual Machine currently in Wheezy that had to be resolved first. Luckily we were able to solve them, with the help of the Scratch and the Squeak guys, so I m happy to say that Scrach is finally available from Debian repositories. Note: If any Scratch derivatives (such as BYOB or Panther) also need to be ported to the current version of Squeak, they should have a look at the comments in the Scratch ITP, and especially to the script uploaded by Bert Freudenberg, that replaces 90 indexed primitive declarations (removed in later versions of Squeak VM) with their named counterpart. Note 2: This wouldn t have been possible without all the great work and effort made by Amos Blanton and many others. Lots of thanks!

The original image (in wallpaper resolution) was made^Whacked by my friend Aur lio .

So that grad student has just submitted his thesis and you are invited to review it. With these quick tips, you can test the limits of the student s willpower, and make his degree a little more deserved by putting him up for some constructive mind games.

Some networks have no connection to the outside except that they allow surfing through an HTTP(S) proxy. Sometimes you are happy and the HTTPS port (443) is unrestricted. The following server-side tools allow you to exploit these weaknesses and get you a shell on your server. sslh sslh is an SSH/SSL multiplexor. If a client connects to sslh, it checks if the clients speaks the SSH or the SSL protocol and then passes the connection to the according real port of SSL or some SSL enabled service, e.g. an HTTPS, OpenVPN, Tinc or XMPP server. That way it s possible to connect to one of these services and SSH on the same port. The usual scenario where this daemon is useful are firewalls which block SSH, force HTTP to go through a proxy, but allow HTTPS connections without restriction. In that case you let sslh listen on the HTTPS port (443) and to move the real HTTPS server (e.g. Apache) to listen on either a different port number (e.g. 442, 444 or 8443) or on another IP address, e.g. on localhost, port 443. On an Debian or Ubuntu based Apache HTTPS server, you just have to do the following to run Apache on port 442 and sslh on port 443 instead:

1. apt-get install sslh as root.
2. Edit /etc/default/sslh, change RUN=no to RUN=yes and --ssl 127.0.0.1:443 to --ssl 127.0.0.1:442.
3. Edit /etc/apache2/ports.conf and all files in /etc/apache2/sites-available/ which contain a reference to port 443 (which is only /etc/apache2/sites-available/default-ssl.conf in the default configuration) and change all occurrences of 443 to 442.
4. service apache2 restart
5. service sslh start

Now you should be able to ssh to your server on port 443 (ssh -p 443 your.server.example.org) while still being able to surf to https://your.server.example.org/. sslh works as threaded or as preforking daemon, or via inetd. It also honors tcpwrapper configurations for sshd in /etc/hosts.allow and /etc/hosts.deny. sslh is available as port or package at least in Gentoo, in FreeBSD, in Debian and in Ubuntu. AjaxTerm A completely different approach takes AjaxTerm. It provides a terminal inside a web browser with login and ssh being its server-side backend. Properly safe-guarded by HTTPS plus maybe HTTP based authentication this can be an interesting emergency alternative to the more common but also more often blocked remote login mechanisms. AjaxTerm is available as package at least in Debian and in Ubuntu.

Happily I never were forced to use either of them myself. :-)

Last Friday, after 5 long years, I have finally submitted my PhD thesis. It was quite a relief, more or less as if an elephant was taken off my back. An English title for my thesis would be Structural Complexity Characterization in Software Systems. Here is an abstract:

This thesis proposes a theory to characterize structural complexity in software systems. This theory aims to identify (i) the contribution of several factors to the structural complexity variation and (ii) the effects of structural complexity in software projects. Possible factors in the structural complexity variation include: human factors, such as general experience of the developers and their familiarity with the different parts of the system; factors related to the changes performed on the system, such as size variation and change diffusion; and organizational factors, such as the maturity of the software development process and the communication structure of the project. Effects of structural complexity include higher effort, and consequently higher cost, in software comprehension and maintenance activities. To test the validity of the proposed theory, four empirical studies were performed, mining data from free software project repositories. We analyzed historical data from changes performed in 13 systems from different application domains and written in different programming languages. The results of these studies indicated that all the factors studied influenced the structural complexity variation significantly in at least one of the projects, but different projects were influenced by different sets of factors. The models obtained were capable of describing up to 93% of the structural complexity variation in the projects analyzed. Keywords: Structural Complexity, Software Maintainance, Human factors in Software Engineering, Mining Software Repositories, Theories in Software Engineering, Empirical Software Engineering, Free/Open Source Software Projects.

Those who read Portuguese can check out the actual thesis text as a PDF file. Most of the studies discussed in the thesis are presented in English in papers I have published during the last years. My defense is going to be on March 23rd. If you happen to be at Salvador at that day, please feel cordially invited.

Now and then I want to output some ANSI color escape codes from software I write, and I always end up doing some trial-and-error to figure out the exact codes I want. Sometimes it s overkill to add a dependency on an existing library that already deals with it, or the language I am using does not have one. There are a lot of listings of the ANSI color codes out there, but I couldn t find one that matches the actual codes with the resulting effect in a visual way. Even the Wikipedia article has a colored table with the actual colors, but I have to lookup manually which code combination produces which color. So I spent a few minutes to write a shell script that prints all useful combinations, formatted with themselves. This way I can quickly figure out which exact code I want to achieve the desired effect. The code for now is very simple:

#!/bin/sh -e
for attr in $(seq 0 1); do
  for fg in $(seq 30 37); do
    for bg in $(seq 40 47); do
      printf "\033[$attr;$ bg ;$ fg m$attr;$fg;$bg\033[m " 
    done
    echo
  done
done

Is there a package in Debian that already does that? Would people find it useful to have this packaged? update: it turns out you can find some similar stuff on google images. It was a quick and fun hack, though. update 2: Replacing echo -n with printf makes the script work independently if /bin/sh is bash or dash. Thanks to cocci for pointing that out.