January 27, 2012

Petter Reinholdtsen

Handling non-free firmware in Debian Edu/Squeeze

With some computer hardware, one need non-free firmware blobs. This is the sad fact of todays computers. In the next version of Debian Edu / Skolelinux based on Squeeze, we provide several scripts and modifications to make firmware blobs easier to handle. The common use case I run into is a laptop with a wireless network card requiring non-free firmware to work, but there are other use cases as well.

First and foremost, Debian Edu provide ISO images for DVD and CD with all firmware packages in the Debian sections main and non-free included, to ensure debian-installer find and can install all of them during installation. This take care firmware for network devices used by the installer when installing from from local media. But for example multimedia devices are not activated in the installer and are not taken care of by this.

For non-network devices, we provide the script /usr/share/debian-edu-config/tools/auto-addfirmware which search through the dmesg output for drivers requesting extra firmware. The firmware file name is looked up in the Contents-ARCH.gz file available in the package repository, and the packages providing the requested firmware file(s) is installed. I have proposed to do something similar in debian-installer (BTS report #655507), to allow PXE installs of Debian to handle firmware installation better. Run the script as root from the command line to fetch and install the needed firmware packages.

Debian Edu provide PXE installation of Debian out of the box, and because some machines need firmware to get their network cards working, the installation initrd some times need extra firmware included to be able to install at all. To fill the PXE installation initrd with extra firmware, the /usr/share/debian-edu-config/tools/pxe-addfirmware script is provided. Again, just run it as root on the command line to fill the PXE initrd with firmware packages.

Last, some LTSP clients might also need firmware to get their network cards working. For this, /usr/share/debian-edu-config/tools/ltsp-addfirmware is provided to update the LTSP initrd with firmware blobs. It is used the same way as the other firmware related tools.

At the moment, we do not run any of these during installation. We do not know if this is acceptable for the local administrator to use non-free software, and it is their choice.

We plan to release beta3 this weekend. You might want to give it a try.

27 January, 2012 10:30PM

hackergotchi for jmtd

Jon Dowland

hackergotchi for

Alexander Reichle-Schmehl

Release Critical Bug report for Week 04

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:1491
Affecting Wheezy:893
Wheezy only:179
Remaining to be fixed in Wheezy:714

Of these 714 bugs, the following tags are set:

Pending in Wheezy:48
Patched in Wheezy:102
Duplicates in Wheezy:45
Can be fixed in a security Update:19
Contrib or non-free in Wheezy:14
Claimed in Wheezy:0
Delayed in Wheezy:5
Otherwise fixed in Wheezy:48

Ignoring all the above (multiple tags possible) 491 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released.

However, with the view of the Release Managers, 788 need to be dealt with for the release to happen.

Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

27 January, 2012 12:01PM by Alexander Reichle-Schmehl (alexander@schmehl.info)

hackergotchi for

Raphaël Hertzog

People Behind Debian: Josselin Mouette, founder of the Debian GNOME team

Josselin Mouette is one the leaders of the pkg-gnome team, he takes sound technical decisions and doesn’t fear writing code to work-around upstream issues. He deserves kudos for the work he has put into packaging GNOME over the years. He can also be very sarcastic (sometimes he even enjoys participating to flamewars on debian lists), and there are quite a few topics where we have long agreed to disagree. But this kind of diversity is also what makes Debian a so interesting place…

Read on to learn more about the pkg-gnome team, its plans for Wheezy, Josselin’s opinion on the GNOME 3 switch, and much more.

Raphael: Who are you?

Josselin: I am a 31 years old Linux systems engineer. I started in life with physics, which I studied at the ENS Lyon. I started a thesis on experimental and numerical models for optoelectronics, but when it became clear that research was not for me, I abandoned it and accepted a job at the CEA, which holds the largest computing center in Europe. Working on these machines has been the most awesome job ever (except for it being near Paris). After that I worked a bit on system monitoring technologies.

I am married, currently living in Lyon, and working for EDF (the French historical electricity company) on scientific workstations using Debian. EDF is using Debian on more than a thousand workstations and holds the fastest Debian supercomputer in the world (200 Tflops), which makes it another obvious place for Debian developers.

Raphael: How did you start contributing to Debian?

Josselin: I discovered Debian in 1999 while studying at the ENS, which is one of the biggest nests of Debian developers – while being a small place, it is producing almost one Debian developer per year on average. After wondering for a while what it could be useful for, hacking on a slink snapshot made me think that it was for, well, everything except for gaming. Later, in 2002, when I was working on optoelectronics computing codes, I started to package them for Debian in order to make them easier to install, for us as well as other labs over the world. I started the NM process, and it was going smoothly but also going to take time. However, at that moment, the frozen-bubble game went out and made quite some buzz. Since I knew a guy who knew the game’s developer, he asked me to package it. The package found 3 sponsors in a very short time and was fast-tracked into the archive at a speed that was unseen before. After which the NM process was completed very quickly.

At that time, I was a heavy WindowMaker user, but I didn’t like the direction the project was taking (actually, I wonder if there was one). GNOME was starting to become attractive, but its packaging in Debian was very ineffective, with many inconsistent packages maintained by people who didn’t ever talk to each other – some of them didn’t speak English, and some of them didn’t talk at all. Together with awesome people, among which Jordi Mallach, Gustavo Noronha Silva, JHM Dassen, Ross Burton and Sébastien Bacher, we started the GNOME team in 2003, introducing consistent packaging practices, and initiating synchronized uploads. Releasing a completely integrated GNOME 2.8 in sarge was a considerable achievement; proving (together with the Perl team) that a team was the best way to maintain large package sets changed the way people work on Debian.

“Proving […] that a team was the best way to maintain large package sets changed the way people work on Debian.”

Raphael: You’re one of the most active contributors of the team which is packaging GNOME for Debian. What would you suggest to a new contributor who would like to help the team?

Josselin: There are several ways to contact the team, but the recommended one has always been IRC. We hang on #debian-gnome on the OFTC network, so just come around and ask for us.¹ The real question is what you want to do in the team. Of course, most new volunteers want to help packaging the latest and greatest version of GNOME into unstable as soon as possible, but unless they already have Debian background, this is not the easiest task. Since there are already people working on this, the “big” packages are usually waiting on dependencies.

I used to direct newcomers towards bug triage, but it is a tedious task and I’m now convinced that our huge bug backlog will never be dealt with. The most useful thing to do for newcomers now is probably to find a GNOME or GNOME-related package that needs improvement or is lagging behind, and simply try to work on it. You can also come and fix the bugs you find annoying. Find a patch on the GNOME bugzilla, or cook it yourself, propose it, and if it’s worthy enough you’ll soon get commit access.

“Our huge bug backlog will never be dealt with.”

¹ At this point I feel worth mentioning that if no one answers in 10 minutes, it doesn’t mean that no one will answer in 2 hours, so please stay on the channel after asking.

Raphael: There’s been some controversy about GNOME 3 and the direction that the project is taking. What’s your personal stance on GNOME 3? And what’s the position of the pkg-gnome team?

Josselin: The controversy is not new to GNOME 3, but the large-scale changes made with it have put it more prominently. The criticism usually boils down to a few categories:

  1. General lack of configurability
  2. Strange design decisions
  3. Red Hat centric development
  4. Hardware requirements
  5. Change resistance

The lack of configuration options has been an ongoing criticism since GNOME 2.0 has decided to rip off most of them. Of course, when the control center was redesigned again for 3.0, there was a surge of horrified exclamations from people who missed their favorite buttons. On this topic, I fully concur with GNOME developers. The configuration option that is useful for you is not necessarily useful for someone else. Of course, sometimes developers go a bit too far, but the general direction is right. At work, we found that only a minority of users actually configure anything on their desktops: they just want something that works to launch their applications. Apple and Google have sold millions of devices by making them the simplest possible and without any configuration.

Design decisions are, on the contrary, individual decisions, and each of them, while having reasons behind it, can be questioned. I remember seeing a lot of complaints when the OK and Cancel buttons were reversed in dialog boxes, something that nobody questions anymore. GNOME Shell is full of such changes; some are easy to get accustomed with, some others just make eyebrows raise. The most obvious example is the user menu in GNOME 3.2, which contains an entry to configure your Google account, but no entry to shutdown the computer. Both decisions were taken independently, each of them with (good or bad) reasons, but the result is simply ridiculous. The default configuration in Debian will contain an extension to make it a bit better, but on the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.

“On the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done.”

Point 3 is more complex. Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution. An example is the recurring discussions about relying on system services that are currently only implemented by systemd. Since there is a lot of (mostly unjustified) resistance against systemd in Debian, and since it won’t work on kFreeBSD anyway, someone needs to develop an alternative implementation of these services for upstart and sysvinit. Everything is in place for someone else to do the job but it has to be done, and this can be frustrating. Especially since it can also be hard to integrate changes needed for other distributions¹.

Hardware requirements are mostly a consequence of the previous criticism: there’s hardware that most distributions just don’t want to bother supporting. We’ve seen it in squeeze with the introduction of a hard dependency on PulseAudio. The Debian GNOME team (together with the Gentoo maintainers) made this dependency optional, carrying heavy patches, in order to cover the cases where it does not work. Now that it has gained more maturity, making this effort obsolete, the new tendency is to require 3D acceleration. For various reasons, it is not available to everyone². On this matter, the position of the Debian GNOME team has always been to support as much different configurations as possible with reasonable effort. Thanks to efforts from the incredible Vincent Untz, upstream supports a so-called “fallback mode”, which is the GNOME panel from 2.x with a lot of its bugs fixed. We intend to support this mode for as long as reasonably possible in Debian, possibly even after upstream ends up dropping it. However, other applications are going to require 3D because GStreamer is moving to clutter too, affecting video playback performance on non-accelerated systems³. For epiphany this is not a problem; only embedded video will be affected. But for totem, this is a major issue; because of that we will probably keep totem 3.0 in wheezy.

Finally, there is a natural human tendency to dislike change (I have it too), and it applies a lot to desktop users’ habits. Needless to say a change of such a scale as introducing GNOME Shell can trigger reactions. However, I don’t think it is reasonable, because of this resistance, to keep gnome-panel 2.x in Debian. This would be a lot of work on obsolete technology, and would prevent the upcoming removal of a lot of deprecated libraries. This time is much better spent improving gnome-panel 3.x in Debian and keeping the “fallback mode” great. One of the change that was made in Debian was to make it easier to find, being available as “GNOME Classic” directly from the login manager, instead of having to find it in an obscure configuration panel. In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it. I had never been accustomed to a new environment as quickly ever before.

“In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.”

¹ Having seen several of my GDM patches reverted without a warning, I know we are not finished with carrying patches in Debian packages.
² Scientific workstations are a non-trivial example, since there is a measurable effect of using 3D in the window manager on heavy 3D applications.
³ On the other hand, on accelerated systems, this feature should end up improving performance a lot.

Raphael: What are your plans for Debian Wheezy?

Josselin: The first goal of the GNOME team is, of course, to provide again a great desktop environment to work on. For wheezy it will probably be based on GNOME 3.4. There also needs to be some work on package management interfaces. Upstream bases everything on PackageKit, but it is not as featureful as the aptdaemon Ubuntu technology. If I have time, I would also like to improve HTTP proxy support, since currently it is based on a stack of terrible hacks.

Raphael: If you could spend all your time on Debian, what would you work on?

Josselin: Obviously I would like to make GNOME in Debian even better. That would imply working on underneath dependencies (what we now like to call plumbing) to make sure everything is working great. This would also imply working more as GNOME upstream to make it more suitable for our needs.

I would also work on large-scale improvements on the distribution, like conditional recommends which I’d love to see implemented¹, or automatic build-dependency generation. I would also work on the installer to make it better for desktops machines.

¹ The idea is to automatically install language packs, or glues between two packages when both packages are installed.

Raphael: What’s the biggest problem of Debian?

Josselin: The obvious answer is the same as the one most people you interviewed before gave: not enough members in core teams. A lot of developers join Debian to work on a small number of pet packages, and don’t necessarily want to be involved with existing teams. It is probably still not obvious enough that the primary way to start contributing to Debian is to join an existing team.

But if there is one thing that is preventing Debian from gaining more momentum now, it is a completely different one: the too short support timeframe. 3 years is really not enough for corporate users. One year to migrate from one version to another is too short, and it is not possible to skip a release. It is definitely possible to change that with reasonable effort: the long-term support after 3 years doesn’t have to cover the same perimeter as the short-term one. For example, we could upgrade the kernel to the version in the current stable release, and stop fixing all non-remote security holes. The important thing is to cover the most basic needs: companies are ready to take the risk of having less support if it allows skipping a version, but not the risk of having no support at all. And even more important is to say that you do something. Red Hat says they support a release for 10 years, but of course after 5 years the supported perimeter is extremely small.

“3 years [of support] is really not enough for corporate users.”

Long-term support will not magically fix all problems in Debian, but it will bring more corporate users into the picture. And with corporate users come paid Debian developers, who can work on critical pieces of the system. Debian was built on the synergy between individuals and companies, and in recent years – perhaps as a reaction against what happened with Ubuntu – we’ve kind of forgot the latter. A lot of individuals have joined the project, and they are actively working, for example, on shortening the release cycle, which goes against the interest of professionals. We should embrace again such users and developers, and that means adapting to the current needs of larger entities.

Raphael: You’re the maintainer of python-support, a packaging helper that was competing with python-central. Both helpers are now deprecated in favor of dh_python2. Does this mean that the situation of Python in Debian is now sane? Or are there remaining problems?

Josselin: dh_python2 (and the Python3 version, dh_python3) has a sane enough design. It fixes a lot of issues in python-central and also python-support, at the expense of somehow reduced functionality for developers. However, just like the previous tools, it merely works around design mistakes in the Python interpreter. For example it is not possible to split binary modules, pure-Python modules and byte-compiled modules in different directory trees, like Perl does – although PEP 3147 introduces a way to do so. There is still no sane and standardized way to deal with module versions. There is no difference made between the module (which is a part of language semantics) and the file containing it (an information which depends on the implementation). Developers heavily rely on introspection features and make assumptions based on the implementation, that make it impossible to work around problems with module files.

Such problems are not restricted to Python. Those who fought against Ruby gems could tell even worse stories. While introducing GObject introspection packages in Debian (they can be used in JavaScript and Python to provide modules based on GObject libraries), I was pleased to see a clear distinction between file and module, but I was again struck by the fact you are not forced to declare API versions in your Python/JS code. In all cases, there is no reliable way to detect runtime dependencies in a given Python or JavaScript file, which leaves the maintainer to declare them by hand, and of course, often be wrong about them. Add to that the fact that most errors cannot be detected before runtime. For all these reasons, and while still being fond of Python for scripts and prototyping, I’ve become really skeptical of using purely interpreted languages to write real applications. Some GNOME developers are moving away from Python and JavaScript, mostly towards Vala; I can only approve of that move and hope the same happens to other projects.

Raphael: Is there someone in Debian that you admire for their contributions?

Of course there is the never-sleeping, never-stopping, Michael Biebl who can upload a whole GNOME release in a single week-end. But there are a lot of awesome people who make Debian something that simply works. I could talk about Cyril Brulebois from the X strike force, Julien Cristau from the release team, Sjoerd Simons for his sound advice and work on plumbing, Luca Falavigna who is so fast at processing NEW, to quote only a few of those I work with frequently. And of course, Jordi and Sam for their humor.


Thank you to Josselin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook

.

One comment | Liked this article? Click here. | My blog is Flattr-enabled.

27 January, 2012 09:00AM by Raphaël Hertzog

Nikita Youshchenko

Cryptkeeper

Situation: a home Debian-based desktop, used by non-technical family members, without any lock-screen passwords or so to maximize convenience.

Need: without making much noise, hide private files from too curious relatives.

Solution: aptitude install cryptkeeper.

27 January, 2012 06:52AM by nikita

Craig Small

Unlucky sometimes

Sometimes life throws little curves at you to see if you are still awake, today has been one of those days.

fglrx is (apparently) fixed

I’ve had a long-running problem with fglrx on my laptop.  The problem stems from ATI closed-source drivers with one of those laptops that has an ATI and Intel driver. It means I am basically using the slow Intel chip only.  This morning I had enough and backed up my home and started to rebuild the laptop with debian 6.0.3.

So I kicked off the very very slow process of reformatting the crypto drive (it has taken 5 hours and still going) let it gurgle on its merry way and started to read my email.  One of the  emails was that my bug about fglrx not working is closed, apparently it is fixed.  If I had read that 10 minutes earlier, a simple ‘apt-get install fglrx-driver‘ would of perhaps fixed it; oh well.

My problem is now is do I move to the latest driver and hope their fix is my fix or leave it with some ancient version?  My preference is the former; I only hope it works!

psmisc 22.15 and buffer overflows

psmisc has a program called pstree which prints the set of processes in a tree fashion.  It hasn’t changed much for quite a while.  I released version 22.15 and the Debian package 22.15-1.  22.15-1 I also adopted the harden CFLAGS as suggested for procps.

I was a little surprised that I received an important bug.  The report was saying I had a buffer overflow introduced in 22.15-1, but no relevant code had changed.  The compiler options had done their job and stopped a buffer being overflowed.

But where exactly was the overflow?  Running gdb on pstree quickly showed that it was line 267 of pstree.c which uses strcpy().  That function set off warning bells. The relevant code is:

    PROC *new;
 
    if (!(new = malloc(sizeof(PROC)))) {
        perror("malloc");
        exit(1);
    }
    strcpy(new->comm, comm);

 

Now comm is the short command name you find in /proc//stat.  It is fixed in the kernel at 16 characters.  The PROC structure has this field as 17 characters long, one extra for the NUL.  I went and checked the Linux source and yes, it is still 16 characters long.  The clue was in the name of the program that it died on.

#6  new_proc (comm=0x6111b0 "{console-kit-dae}", pid=1571, uid=0)
    at pstree.c:267
 

That string is 17 characters long. The problem is that 16 characters is for the name only. If the name is in brackets or braces, then that 16 character limit doesn’t apply.  The buffer overflow bug has been there for a long time, but only with the compiler flags did it become visible.

Given you need to read names out of the /proc filesystem and if someone can fiddle with that you have bigger problems it doesn’t seem to be too much of an issue.  It should be (and is in Debian 22.15-2) fixed but is a nice example of the compiler catching bad things.

 

27 January, 2012 05:12AM by Craig

Lior Kaplan

PHP 5.4 @ Zend

As a Linux integration guy at Zend, most of my time is spent in compiling PHP related code or dealing with the variety of Linux distributions we support. With the coming release for PHP 5.4, we (at Zend) had some interesting stuff going on.

As part of the RC phase, I got to check the status of the 50-60 PHP extensions we provide, especially the PECL extensions which have different release cycles than the main PHP. With minor versions, this usually doesn’t really matter, but for major versions this means that some extensions need a little bit of love and fixes to work well with the new PHP version. This of course with the help of our developers.

The changes are usually one-liners due to a variable type change, or finding commits in the extension’s SCM and applying/back-porting it to the current versions (e.g. pecl memcache). Our policy regarding the patches we have, is that they should at least be sent to upstream (a core member or a bug report, e.g. #55703). I think I’m in the best position to enforce that patch policy, so in a few recent cases, I found myself asking one of our developers if the patch he sent me was already accepted upstream before willing to take it into the build process (in this case they are used temporarily, till we’ll work with the next RC or final release).

While most people build PHP as a final and standalone product, we also test it against ZendServer (or the other way around, depends on your POV). This helps to discover problems related to and implications of the changes done in the major version. During the PHP 5.4 RC cycle (which is still not finished), we had, more than a few times, that an internal problem discovered led to debugging, code reviewing and sending feedback (and patches when relevant) to the PHP project. Providing fixes for the issues found, helps having PHP in a better shape for release. At least for me, that’s one of the fun parts of work – getting the chance to contribute back to the community (or at least making sure others do, as I don’t write the patches myself).

Filed under: PHP

27 January, 2012 01:21AM by Lior Kaplan

January 26, 2012

hackergotchi for Guido Günther

Guido Günther

git-buildpackage in experimental

I've started uploading snapshots of git-buildpackage to experimental recently. Here's a short list of what changed over the version in wheezy and sid:

  • git-buildpackage now has a --git-pristine-tar-commit option that commits a tarball right back to the pristine-tar branch if it's not already there. This makes tracking upstream git and dfsg-clean source handling easier.
  • git-buildpackage's --git-upstream-tree now accepts a tree directly without the need to use --git-upstream-branch.
  • git-buildpackage's --git-export now parses the exported changelog instead of the working copy. This way we automatically pick up the correct tarballs, branches, etc. reducing the number of options needed.
  • Jan Čapek added a --git-postexport hook to allow to mangle the source after exporting it.
  • gbp-pull and gbp-fetch now support shallow clones thanks to Markus Lehtonen.
  • gbp-pull got a speed up by skipping the checkout for fast-forward. This makes updating large source trees less time consuming.
  • git-import-orig and git-import-dsc can now import into bare repositories.
  • Russ Allbery updated git-pbuilder to 1.27.
  • gbp-pq should be easier to use thanks to the --force and --switch options. It also handles patches without descriptions more robustly.
  • The test coverage of the internal test suite increased quiet a bit. We're now generating coverage information during the build in build/cover.
  • We're now generating apidocs which also serves as usage examples.

This blog is flattr enabled.

26 January, 2012 08:37PM

Ondřej Čertík

When double precision is not enough

I was doing some finite element (FE) calculation and I needed the sum of the lowest 7 eigenvalues of a symmetric matrix (that comes from the FE assembly) to converge to at least 1e-8 accuracy (so that I can check calculation done by some other solver of mine, that calculates the same but doesn't use FE). In reality I wanted the rounded value to 8 decimal digits to be correct, so I really needed 1e-9 accuracy (but it's ok if it is let's say 2e-9, but not ok if it is 9e-9). With my FE solver, I couldn't get it to converge more than to roughly 5e-7 no matter how hard I tried. Now what?

When doing the convergence, I take a good mesh and keep increasing "p" (the polynomial order) until it converges. For my particular problem, it is fully converged for about p=25 (the solver supports the order up to 64). Increasing "p" further will not increase the accuracy anymore, and the accuracy stays at the level 5e-7 for the sum of the lowest 7 eigenvalues. For optimal meshes, it converges at p=25, for not optimal meshes, it converges for higher "p", but in all cases, it doesn't get below 5e-7.

I know from experience, that for simpler problems, the FE solver can easily converge to 1e-10 or more using double precision. So I know it is doable, now the question is what the problem is: there
are a few possible reasons:

  • The FE quadrature is not accurate enough
  • The condition number of the matrix is high, thus LAPACK doesn't return very accurate eigenvalues
  • Bug in the assembly/solver (like single/double corruption in Fortran, or some other subtle bug)
When using the same solver for simpler potential, it converged nicely to 1e-10. So this suggests there is no bug in the assembly or solver itself. It is possible that the quadrature is not accurate enough, but again, if it converges for simple problem, it's probably not it. So it seems it is the ill conditioned matrix, that causes this. So I printed the residuals (that I simply calculated in Fortran using the matrix and the eigenvectors returned by LAPACK), and it only showed 1e-9. For simpler problems, it can go to 1e-14 easily. So that must be it. How do we fix it?

Obviously by making the matrix less ill conditioned, which is caused by the mesh for the problem (the ratio of the longest/shortest elements is 1e9) but for my problem I really needed such a mesh. So the other option is to increase the real number accuracy.

In Fortran all real variables are defined as real(dp), where dp is an integer defined at a single place in the project. There are several ways to define it, but it's value is 8 for gfortran and it means double precision.So I increased it to 16 (quadruple precision), recompiled. Now the whole program calculates in quadruple precision (more than 30 significant digits). I had to recompile LAPACK using the "-fdefault-real-8" gfortran option, that promotes all double precision numbers to quadruple precision, and I used the "d" versions (double precision, now promoted to quadruple) of LAPACK routines.

I rerun the calculation ---- and suddenly LAPACK residuals are around 1e-13, and the solver converges to 1e-10 easily (for the sum of the lowest 7 eigenvalues). Problem solved.

Turning my Fortran program to quadruple precision is as easy as changing one variable and recompiling. Turning LAPACK to quadruple precision is easy with a single gfortran flag (LAPACK uses the old f77 syntax for double precision, if it used real(dp), then I would simply change it as for my program). The whole calculation got at least 10x slower with quadruple. The reason is that gfortran runtime uses the libquadmath library, that simulates quadruple precision (as current CPUs only support double precision natively).

I actually discovered a few bugs in my program (typically some constants in older code didn't use the "dp" syntax, but had the double precision hardwired). Fortran warns about all such cases, when the real variables have incompatible precision.

It is amazing how easy it is to work with different precision in Fortran (literally just one change and recompile). How could this be done with C++? This wikipedia page suggests, that "long double" is only 80bit in most cases (quadruple is 128bit), but gcc offers __float128, so it seems I would have to manually change all "double" to "__float128" in the whole C++ program (this could be done with a single "sed" command).

26 January, 2012 06:51PM by Ondřej Čertík (noreply@blogger.com)

hackergotchi for Ben Hutchings (ben@decadent.org.uk)

Ben Hutchings

Testing backport of the isci driver for Intel C600 SAS/SATA controllers

Phil Kern made a general call for testing of Debian 6.0.4. I would like to more specifically point out that I backported the isci driver for Intel C600 SAS/SATA controllers. Unfortunately I have not yet had any testing results for this. If you have any machines with this hardware not yet in production, please do consider testing the new Linux kernel package, version 2.6.32-41.

Updated: I now have a positive test result from the user who requested this driver in the installer.

26 January, 2012 03:51PM

hackergotchi for

Aigars Mahinovs

Zombies. Wait, don’t run away, yet …

I never got the craze for the zombie this and zombie that. I saw the premise as thinner than vampire storyline which in my book only had a good day with Buffy franchise. But then I got Kindle and run out of stuff to read and decided to pick up something less lively and more shambling. And you know what I found – there are a few great books hiding behind the ‘zombie’ label.

I read them in the worng order, so to help you guys out, here is the way I would recommend to check out if the zombie genre is interesting to you:

Start with World War Z: An Oral History of the Zombie War. It is written as a historical book documenting the memories of people that have survived the world wide zombie apocalipse is a series of escalating short stories. This is a perfect bathroom or bus reading. Each story focuses on how people react (or fail to react) to a radical change in their environment. Zombies are a tool to expose the human condition for this book.

The next you could read (or you could even skip this if it get a bit boring for you) is The Zombie Survival Guide: Complete Protection from the Living Dead – this is a problem solving book, it basically takes a problem (“ZOMBIES!”) a goal (“I want to survive!”) and describes the logical steps needed to reach the goal in the context of the problem. It is very educational on the issue of problem solving, especially with unusual problems. But it can get boring for people – if so, don’t give up, but just skip this book for now and move on the the best of them all …

The third is a trilogy, two books are already published, the third is coming soon – first books is Feed (Newsflesh, Book 1) and the second is Deadline (Newsflesh, Book 2). This is a rare gem of modern literature. Basically this is a book set in the world long time after a zombie outbreak (with a good reason why and how it happened) where people have already lived a few decades with the problema and the kids are very used to it. So the book is written from a perspective of a young woman and her brother, who were born after Rising and are now into one of the most dangerous profession – journalism. :) Early on they become the first bloggers to be picked to follow a presidential election campagn (book was written before Obama campaign really took off) and it only get wilder from there.

I really liked these books. So much so, that I will now explore the other zombie fiction books to see if there possibly is something good there as well. Any recommendations?

26 January, 2012 12:55PM by aigarius

Ian Wienand

pylint and hiding of attributes

I recently came across the pylint error:

E:  3,4:Foo.foo: An attribute affected in foo line 12 hide this method

in code that boiled down to essentially:

class Foo:

    def foo(self):
        return True

    def foo_override(self):
        return False

    def __init__(self, override=False):
        if override:
            self.foo = self.foo_override

Unfortunately that message isn't particularly helpful in figuring out what's going on. I still can't claim to be 100% sure what the message is intended to convey, but I can construct something that maybe it's talking about.

Consider the following using the above class

foo = Foo()
moo = Foo(override=True)

print "expect True  : %s" % foo.foo()
print "expect False : %s" % moo.foo()
print "expect True  : %s" % Foo.foo(foo)
print "expect False : %s" % Foo.foo(moo)

which gives output of:

$ python ./foo.py 
expect True  : True
expect False : False
expect True  : True
expect False : True

Now, if you read just about any Python tutorial, it will say something along the lines of:

... the special thing about methods is that the object is passed as the first argument of the function. In our example, the call x.f() is exactly equivalent to MyClass.f(x). In general, calling a method with a list of n arguments is equivalent to calling the corresponding function with an argument list that is created by inserting the method’s object before the first argument. [Official Python Tutorial]

The official tutorial above is careful to say in general; others often don't.

The important point to remember is how python internally resolves attribute references as described by the data model. The moo.foo() call is really moo.__dict__["foo"](moo); examining the __dict__ for the moo object we can see that foo has been re-assigned:

>>> print moo.__dict__
{'foo': <bound method Foo.foo_override of <__main__.Foo instance at 0xb72838ac>>}

Our Foo.foo(moo) call is really Foo.__dict__["foo"](moo) -- the fact that we reassigned foo in moo is never noticed. If we were to do something like Foo.foo = Foo.foo_override we would modify the class __dict__, but that doesn't give us the original semantics.

So I postulate that the main point of this warning is to suggest to you that you're creating an instance that now behaves differently to its class. Because the symmetry of calling an instance and calling a class is well understood you might end up getting some strange behaviour, especially if you start with heavy-duty introspection of classes.

Thinking about various hacks and ways to re-write this construct is kind of interesting. I think I might have found a hook for a decent interview question :)

26 January, 2012 11:09AM

hackergotchi for

Bastian Venthur

Helping awstats to correctly interpret lighttpd’s log format

Note to self:

when configuring awstats using lighttpd logfiles, you have to use the following log format:

LogFormat="%host %virtualname %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

neighter 1 nor 4 will work correctly.

26 January, 2012 10:53AM by Bastian

Russ Allbery

Do symbols files make sense for C++?

I also posted this to debian-devel, which is where the discussion will be, but I wanted to post it on my journal as well so that others who may be interested will see it on Planet Debian. For those not familiar with Debian, this concerns the implications of a new feature for how Debian tracks shared library dependencies.

I'm currently working on the Policy modification to document (and recommend) use of symbols instead of shlibs, but I'd only personally used symbols with C libraries. Today I decided that I should try adding a symbols file to a C++ library, particularly if I'm going to recommend everyone do it. I tried this exercise with xml-security-c, which is, I think, a reasonably typical C++ library. Not the sort of core C++ library that would sit at the center of the distribution, but a random software package that's in Debian because other things use it.

The experience was rather interesting, and I ended up uploading the new version without a symbols file and continuing to just use shlibs. That's for the following reasons:

  1. The generated symbols file was HUGE. Hundreds of lines. This is a marked difference from the typical C symbols file, which is of quite manageable size. Some of that is that the library provides a lot of different classes, but some of it is that C++ just generates a lot of exported symbols. There's no way that I could do what I would do with a C library and understand those symbols, why they're there, and whether they are likely to have changed between revisions.

  2. Generating a reasonable symbols file was a pain. Generating an unreasonable symbols file that just contains all of the mangled symbols is largely mechanical and uninteresting, but that symbols file doesn't seem to me to convey useful information. So I did some scripting to translate the symbols back with c++filt, and add (c++) tags, and then try to understand what I was looking at and figure out whether I should sort the symbols list because the default sort is by mangled name, which is meaningless. This is a rather unappealing process. It's not particularly difficult, but it's very awkward and feels like it's missing vital tools.

  3. The resulting symbols file is incomprehensible to someone without strong knowledge of C++. It's full of opaque entries that don't make sense to the non-C++ programmer, wihch I suspect is a substantial number of people who package C++ libraries for Debian. I know enough C++ from school that I can evaluate security fixes, make simple patches, and review upstream changes, and I think that's all that should be needed to package things for Debian. But I'm deeply uncomfortable producing a symbols file on my own that contains entries for things that I know nothing about and cannot evaluate when they've last changed, like "non-virtual thunk to FooClass::~FooClass@Base".

  4. Once I had a symbols file that resulted in a successful build and that I could have uploaded, I started thinking about how I was going to maintain it. With a C program, I would change the symbols file versions when the underlying function implementation changes in a way that may not offer eqiuvalence, similar to bumping shlibs. I realized that I was going to have no idea when that happened, and the only way that I would maintain the symbols file would be to either trust upstream to maintain ABI equivalence and therefore only change the symbols file when upstream changes the SONAME, or not trust upstream to maintain ABI equivalence and therefore change all the versions with each new upstream release. That gives me exactly the same semantics as a shlibs file, so what's the point in having a symbols file?

  5. The exported symbols of the library contained many symbols that obviously weren't really from that library, but instead were artifacts of the C++ compilation process, things like instantiations of std::vector. Do those go into the symbols file? Do they change from architecture to architecture? If they disappear again, is that actually an ABI break? How do I know? It's all very mysterious, and while shlibs provides the same semantics as just ignoring this, at least I'm not then including in the package data, generated by me, things that I'm just blindly ignoring.

I came away from this experience thinking that I should revise the Policy amendment to say that symbols files are really for C libraries and for C++ libraries with either a tightly maintained symbol export list or maintained by a C++ expert, and that most C++ library maintainers should just not bother with this and use shlibs, bumping the shlibs version or not based on their impression of how good upstream is at maintaining ABI equivalence.

But that feels like a result contrary to what I had previously thought was the intended direction, so I wanted to ask the Debian development community as a whole: am I missing something? Are these symbols files actually useful? Am I missing some trick to make them useful?

26 January, 2012 07:04AM

hackergotchi for

MJ Ray

Phones, Privacy and Co-ops

And now a slightly longer than usual rant: The problem with the o2 network disclosing mobile browsers’ phone numbers that I repeated 2 days ago (and it appeared on our co-op website) snowballed yesterday to the point that it was on the short bulletins from ITN, BBC, IRN… and probably many more. And then o2 fixed it. Good!

The reply claims that it’s only since 10th January which is rather at odds with other claims that it has been happening since at least March 2010 in some situations.

I started buying from o2 in December. I was using Three, but their network where I stay in Norfolk isn’t reliable and you can’t just buy a device in a shop for The Phone Co-op. The dongle from o2 is a recent Huawei USB device that just worked in debian and was fairly easy for me to get working in Ubuntu. There’s space in it for a memory card, so maybe I could boot from it… but that’s an idea for later.

The o2 deal is OK but not great, and the included wifi is nowhere near as good as it looked: when it says it includes “BT Openzone” that doesn’t include any of the “BT Openzone-H” hotspots that are much more common. You’re only allowed to register one device for wifi, so no using your phone, tablet and laptop at different times!

I can’t believe it’s legal to advertise that as “unlimited wifi”, but o2 is still a better offer than access to “BT Openzone-H” hotspots at £39/month (yes, that’s the price for wifi-only…).

Ultimately, I think the problem is that there’s a rubbish choice of mobile (wifi or 3G) internet access providers in the UK. It’s a completely and utterly failed market, so you need to use Virtual Private Networks and similar tricks to protect yourself from the dysfunctional networks. My VPN meant my mobile number was safe: how about yours?

As luck would have it, I had already proposed a resolution about protecting customer privacy to The Phone Co-op (affiliate link) for our AGM on Saturday 4 February (if you’re a member, let me know). We were trying to find a compromise wording and I don’t think this little o2 scandal has hurt my proposal at all!

At least the phone co-op’s mobile service is based on Orange’s network, which wasn’t affected. How does your network perform? There’s an Internet Service Provider evilness test which might tell you.

26 January, 2012 05:26AM by mjr

hackergotchi for Joey Hess

Joey Hess

announcing github-backup

Partly as a followup to a Github survey, and partly because I had a free evening and the need to write more haskell code, any haskell code, I present to you, github-backup.

github-backup is a simple tool you run in a git repository you cloned from Github. It backs up everything Github knows about the repository, including other forks, issues, comments, milestones, pull requests, and watchers.

This is all stored in the repository, as regular files, on a "github" branch.

Available in Cabal now, in Debian maybe if someone packages haskell-github.

26 January, 2012 04:44AM

Russell Coker

January 25, 2012

hackergotchi for Phil Hands

Phil Hands

The future arrived

... a week ago, in the shape of Alexandra Daphne Scholz, my enchanting daughter.

A proud father shows the world his adorable 6 day old daughter

She seems to have inherited my hairstyle.

Gundemarie Scholz (my wife) and she are both doing remarkably well, to the extent that they both keep surprising medical staff with their rapid progress.

For those of you that care about such things: She was 2.9kg (6lb 6oz) at birth, and 49cm (1'7") tall ... or should that be "long", given that she's not doing so much standing up as yet? What she is doing is sleeping, breast feeding, and excreting ... rather a lot.

Between times, it's mostly gurgling cheerfully, looking around at the world, and attempting to study her own hands -- I find her completely fascinating.

That being the case, don't expect anything very sensible out of me for the foreseeable future (so no change there, eh? ;-) )

and because I cannot resist the urge, here are a few more snaps of her:

Alexandra in the Neonatal unit, having a well earned nap when a day old Alexandra in the Neonatal unit, looking around at the world Alexandra snuggled up in bed this morning

As you can see, at only one day old, it seems that she'd already managed to get hold of the Amulet of Yendor, and was having a well earned nap ;-)

25 January, 2012 11:26PM

hackergotchi for

Bartosz Feński

Sentelic touchpad

With the latest changes in driver for Sentelic touchpad I’m eventually able to use two-finger scrolling, and disable touchpad while typing.

Middle-button emulation and on pad click & drag doesn’t work yet, though. Edge scrolling either.

Anyway it starts to be really usable and there is some progress to merge this driver with mainline kernel.

I believe last time I was compiling kernel was around 2.4.18 and only because at that time I was maintaining router for some network and needed some special iptables extensions. Happily it hasn’t changed too much since then and I can compile 3.2.1 without problem ;)

25 January, 2012 09:19PM by fEnIo

hackergotchi for Christian Perrier

Christian Perrier

Petter Reinholdtsen

Setting up a new school with Debian Edu/Squeeze

The next version of Debian Edu / Skolelinux will include a new tool sitesummary2ldapdhcp, which can be used to quickly set up all the computers in a school without much manual labour. Here is a short summary on how to use it to set up a new school.

First, install a combined Main Server and Thin Client Server as the central server in the network. Next, PXE boot all the client machines as thin clients and wait 5 minutes after the last client booted to allow the clients to report their existence to the central server. When this is done, log on to the central server and run sitesummary2ldapdhcp in the konsole to use the collected information to generate system objects in LDAP. The output will look similar to this:

% sitesummary2ldapdhcp 
info: Updating machine tjener.intern [10.0.2.2] id ether-00:01:02:03:04:05.
info: Create GOsa machine for auto-mac-00-01-02-03-04-06 [10.0.16.20] id ether-00:01:02:03:04:06.

Enter password if you want to activate these changes, and ^c to abort.

Connecting to LDAP as cn=admin,ou=ldap-access,dc=skole,dc=skolelinux,dc=no
enter password: *******
% 

After providing the LDAP administrative password (the same as the root password set during installation), the LDAP database will be populated with system objects for each PXE booted machine with automatically generated names. The final step to set up the school is then to log into GOsa, the web based user, group and system administration system to change system names, add systems to the correct host groups and finally enable DHCP and DNS for the systems. All clients that should be used as diskless workstations should be added to the workstation-hosts group. After this is done, all computers can be booted again via PXE and get their assigned names and group based configuration automatically.

We plan to release beta3 with the updated version of this feature enabled this weekend. You might want to give it a try.

25 January, 2012 08:00PM

hackergotchi for

Bartosz Feński

Cracow against ACTA

Wow… that’s really big demonstration.
I’ve just uploaded video with people walking near Wawel castle… plenty of people during almost 20 minutes.
I suppose there was more than 50k people and wonder what’s going to be shown in TV ;)

I really like it.

25 January, 2012 07:50PM by fEnIo

Pietro Abate

new thinkpad x220

This summer my beloved thinkpad x301 died in a cloud of smoke. It was exactly 3 years and 20 days old while my warranty was valid only for 3 years. Now, don't tell me this is a coincidence. Anyway. After about 5 months, I finally managed to convince my employer to get me a new thinkpad, the x220. My specs includes a 128G SSD , 4G of RAM, 2.4Gz processor, camera and fingerprint reader.

It's a pity that the x300 series is not in production anymore. They were light, with a solid battery and a large screen. The X1 just don't cut it. Even though it can be consider the successor of the x300, its battery life is just not enough for my needs. On the other hand, the x220 is a very nice machine : the screen is a bit smaller then the X300, but it is light, with a very powerful processor, good battery and it feels very solid. In my opinion lenovo should have packed the new hw of the x220 in the chassis of the x300, maybe with small compromise on the battery life (I got the big battery and I can squeeze almost 7 hs with a single charge) but clearly this was not a good business choice...

Installing debian on this laptop is not immediate because none of the official debian installers are shipped with a recent kernel (as in 3.x series). Since with the official debian installer I cannot have neither the driver for the Ethernet card or the driver for the wirelles card, I opted to use a custom installer built by kmuto (http://kmuto.jp/debian/d-i/ ) . Using this installer the ethernet card is recognized immediately and it's easy to proceed with the installation as usual. Another option would have been to add the binary blog for the wireless chip, but apparently the deb installer supports only WEP auth, while all my access point are WPA. I didn't spend too much time on the wireless setup, so it might well be that is indeed possible to install using a WPA access point.

Last time I installed a laptop, I used the automatic partition option to have lvm on top of a lucks encrypted partition, only to discover later that the default dimensions of the partitions were a bit too small for me. For example, by default the boot partition is only 256Mb. This is plenty if you want to have only one kernel image installed at each given time, but if you want more then one kernel, memtest and for example a grml rescue iso, it's easy to run out of space.

So I proceed to manually partition the disc creating a boot partition of 512M, and using the rest as a luks encrypted device with lvm on top and 3 logical volumes : sys (15G), swap (4G) and home (the rest). For my daily use having 15G on my laptop for /usr, /var, etc should more the enough...

Next step was to install the system. Since in recent times I got extremely pissed off with gnome 3, I've decided to dump it completely and go back to awesome. But since awesome all by itself is a bit sad, I paired it up with xfce. Everything works, except the automount, and I'm still trying to figure out how to make it work. Apparently is a consolkit problem... I'll write another post about the xfce4 + awsome setup soon...

Today I've also started playing with the finger print reader. It seems working, but I haven't managed yet to use it in conjunction with pam for authentication ... more to come.

And... On last closing remark : during the last 5 months I've used a dell latitude e6410 ... Gosh. I feel I'm on anther planet. The keyboard of a thinkpad give you pleasure, not pain, from 2 to 4G of RAM is a big jump and from a conventional HD to a SSD ... well... it seems I'm flyinggggg :) I've the impression my productivity just went up 50% !!!

If you work with your laptop everyday get a good laptop. It is well worth the investment ...

25 January, 2012 03:53PM by abate

Russell Coker

SE Linux Status in Debian 2012-01

Since my last SE Linux in Debian status report [1] there have been some significant changes.

Policy

Last year I reported that the policy wasn’t very usable, on the 18th of January I uploaded version 2:2.20110726-2 of the policy packages that fixes many bugs. The policy should now be usable by most people for desktop operations and as a server. Part of the delay was that I wanted to include support for systemd, but as my work on systemd proceeded slowly and others didn’t contribute policy I could use I gave up and just released it. Systemd is still a priority for me and I plan to use it on all my systems when Wheezy is released.

Kernel

Some time between Debian kernel 3.0.0-2 and 3.1.0-1 support for an upstream change to the security module configuration was incorporated. Instead of using selinux=1 on the kernel command line to enable SE Linux support the kernel option is security=selinux. This change allows people to boot with security=tomoyo or security=apparmor if they wish. No support for Smack though.

As the kernel silently ignores command line parameters that it doesn’t understand so there is no harm in having both selinux=1 and security=selinux on both older and newer kernels. So version 0.5.0 of selinux-basics now adds both kernel command-line options to GRUB configuration when selinux-activate is run. Also when the package is upgraded it will search for selinux=1 in the GRUB configuration and if it’s there it will add security=selinux. This will give users the functionality that they expect, systems which have SE Linux activated will keep running SE Linux after a kernel upgrade or downgrade! Prior to updating selinux-basics systems running Debian/Unstable won’t work with SE Linux.

As an aside the postinst file for selinux-basics was last changed in 2006 (thanks Erich Schubert). This package is part of the new design of SE Linux in Debian and some bits of it haven’t needed to be changed for 6 years! SE Linux isn’t a new thing, it’s been in production for a long time.

Audit

While the audit daemon isn’t strictly a part of SE Linux (each can be used without the other) it seems that most of the time they are used together (in Debian at least). I have prepared a NMU of the new upstream version of audit and uploaded it to delayed/7. I want to get everything related to SE Linux up to date or at least with comparable versions to Fedora. Also I sent some of the Debian patches for the auditd upstream which should reduce the maintenance effort in future.

Libraries

There have been some NMUs of libraries that are part of SE Linux. Due to a combination of having confidence in the people doing the NMUs and not having much spare time I have let them go through without review. I’m sure that I will notice soon enough if they don’t work, my test systems exercise enough SE Linux functionality that it would be difficult to break things without me noticing.

Play Machine

I am now preparing a new SE Linux “Play Machine” running Debian/Unstable. I wore my Play Machine shirt at LCA so I’ve got to get one going again soon. This is a good exercise of the strict features of SE Linux policy, I’ve found some bugs which need to be fixed. Running Play Machines really helps improve the overall quality of SE Linux.

Related posts:

  1. Status of SE Linux in Debian LCA 2009 This morning I gave a talk at the Security mini-conf...
  2. SE Linux in Debian I have now got a Debian Xen domU running the...
  3. Debian SE Linux Status At the moment I’ve got more time to work on...

25 January, 2012 11:36AM by etbe

hackergotchi for jmtd

Jon Dowland

Music for Our Future

cover

In 2010, a collaboration between the SyFy channel, Create Digital Music, XLR8R and Pitchfork created "Music for our Future": a compilation album of free music inspired by the TV show "Caprica".

XLR8R hosted it but their page for the release has subsequently disappeared. A few people here and there on the 'net have been asking for a copy, so here it is on archive.org: http://www.archive.org/details/MusicForOurFuture.

Some background info, photos etc. via CDM.

25 January, 2012 10:35AM

January 24, 2012

James Morrison

Appengine

I've been working with appengine for a few months now. I've managed to find out the hard way that appcfg.py rollback is useless. I've learned to create a git branch for each refactoring I start on. The git branch also includes a new app version for the branch. When push all my changes to my live site, I upload one last time to the new app. Merge my branch into the master then change the live version from the old one to the new one.

I haven't learned how this work flow translates to having multiple developers. Hopefully, it is simple enough that other people can follow.

I also use make since it's an easy way to automate tasks. I hear redo is good, but for python, I'm not really compiling anything, I'm simply writing shell scripts and make is a great shell script dispatcher.

24 January, 2012 11:02PM by James A. Morrison (noreply@blogger.com)

Appengine backends and task queues

To get appengine to send queued tasks to a backend, you need to set the host header when queuing the task. E.g.
    deferred.defer(
batch.DoStuff, arg1, arg2, arg3,
_headers={'Host': backends.get_hostname(backend='backend_name')})

24 January, 2012 11:02PM by James A. Morrison (noreply@blogger.com)

Make is still my friend


The following is a makefile fragment I seem to start each of my appengine projects with.

GAEPATH = $(HOME)/bin/google_appengine
PORT=8081

PYLINTS = $(wildcard *.py */*.py */*/*.py)
PYLINTFILES = $(patsubst %.py,.%.lint,$(notdir $(PYLINTS)))
PYLINT = $(join $(dir $(PYLINTS)),$(PYLINTFILES))

PYTHONPATH=$(GAEPATH):$(GAEPATH)/lib/yaml/lib:$(GAEPATH)/lib/webob:$(GAEPATH)/lib/django_0_96:.

APP=new-app

run:
        $(GAEPATH)/dev_appserver.py ./ --port=$(PORT) --datastore_path=/tmp/$(APP).dev_appserver.datastore


.%.lint: %.py
        @PYTHONPATH=$(PYTHONPATH) pychecker --only --no-miximport $?
        @touch $@


lint: $(PYLINT)


clean:
        -rm ${PYLINT}


.PHONY: run lint clean


24 January, 2012 11:01PM by James A. Morrison (noreply@blogger.com)

CMYK images in PDFs

For the few of you out there that are parsing PDFs manually in python, JPEG images (including CMYK images) can be extracted with the following code fragment.
  # reader is a PDFReader object from pyPdf, value is the operand to a Do operator. 
from PIL import Image, ImageChops

xobject = reader.getObject(value)
if xobject['/Filter'] == '/DCTDecode':
raw_data = xobject.getRawData()
if xobject['/ColorSpace'] == '/DeviceRGB':
_CreateFile('image/jpeg', filename, raw_data))
else:
f = cStringIO.StringIO(raw_data)
of = cStringIO.StringIO()
i = Image.open(f)
if xobject['/ColorSpace'] == '/DeviceCMYK':
i = ImageChops.invert(i)
i.convert('RGB').save(of, 'JPEG')
_CreateFile('image/jpeg', filename, of.getvalue())

The CMYK images I found in the PDFs needed to inverted. PIL versions before 1.1.7 would do that for you, but version 1.1.7 removed in the ImageChops.invert() call.

24 January, 2012 11:01PM by James A. Morrison (noreply@blogger.com)

Tim Retout

Lenovo X121e 3G with ModemManager

Recently, I tried to get 3G working on my Lenovo ThinkPad X121e - it has an Ericsson F5521gw mobile broadband card. This is supported by ModemManager, but all I got were unknown errors (276 and 272).

Searching online, there were very few results (hence this short note) - just previous unrelated Linux kernel issues. I found someone with the same problem on Fedora, but no solution, so I started off by filing a bug report with Debian.

Of course, then I found the Arch user who had filed the same bug on Launchpad, and had discovered that resetting the BIOS to its default settings fixes the issue. If only that page mentioned the keywords "Ericsson", or "Lenovo"...

So after all that, it was just some weird BIOS issue. I hate hardware.

24 January, 2012 10:07PM

Sylvain Beucler

OpenGL ES 2.0 using Android NDK

Teapot on Android I got myself a second-hand Samsung Galaxy S at last, and started hacking on it!

The very first thing I wanted to try was porting the OpenGL wikibook C++ samples, that we wrote with OpenGL ES 2 in mind.

I started writing a minimal GLUT-compatible wrapper to run the samples as-is, using the Android NDK, and I'm making progress :) The Android NDK is getting nicer with Android 2.3, though it still feels less supported than Java apps (e.g. the resize events seem buggy and the keycodes header is incomplete...). Nonetheless, it's nice to be able to write C++ portable apps.

You can see how to use the wrapper, and how it works internally, at:

http://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Android

One of the limitations is that GLES2 is not a true subset of OpenGL 2.1, in particular:

  • the shader version is declared differently (#version 100 vs. #version 120)
  • GLES2 shaders require float precision hints, but OpenGL 2.1 doesn't support them at all

I needed to pre-process these differences away, checking on GL_ES_VERSION_2_0 in the C++ source code to define a GLES2 macro in the shaders:

#ifdef GLES2
varying lowp vec4 f_color;
# else
varying vec4 f_color;
#endif

Is there a better way?

24 January, 2012 09:48PM

Stefano Zacchiroli

hardware sponsorship for Debian Developers

A few days ago Yves-Alexis Perez asked me how many hardware sponsorship request I usually get from Debian Developers, that is how many people ask me to use Debian money to buy material that can improve their work on Debian — and indirectly Debian itself.

The answer is "too few".
Making it easier for our developers to improve Debian is a worthwhile investment of money donated to Debian.

Of course such a use of money should be motivated (i.e. you should be able to justify how the material you're asking for would improve Debian and why it should be Debian paying for it) and transparent (i.e. you should periodically report about what you're doing with material that Debian has bought for you to use).

The above two principles are what I've tried to convey in a new section of the sponsoring guidelines wiki page I've been maintaining for a while. Comments and improvements highly welcome!

Equally welcome are advocacy messages for hardware sponsoring to other fellow Developers, as suggested by Corsac.

24 January, 2012 05:07PM

hackergotchi for Charles Plessy

Charles Plessy

Strange Megumi

It is since two days that all my emails, @debian.org included, are in parked somewhere between the sender and my MX, as my server broke at a moment where I strictly had no time (dealine for a grant application). It is an OpenRD Ultimate with a second hand SSD. I was quite happy to have an ARM system available to test some packages like T-COFFEE, but it looks like I will have to do without.

Apparently, the machine permanently reboots. I did not manage to access to the USB serial port; there are no 10 seconds where the USB port is not disconnected / reconnected. Both ethernet port LEDs blink together synchronously with the disconnections. Removing the drive did not solve the problem.

The SSD itself is fine, and I did not find in the logs hints for software problems. Strange coincidence, the last log file that was modified is daemon.log, which indicates the connection of so-called megumi-PC to our unprotected, but to my knowledge never visited, wireless network. After this, nothing.

24 January, 2012 03:23PM

hackergotchi for

Gunnar Wolf

BugCon friends, are you trying to scare away 50%+ of the target audience?

You are scaring away much more than that.

I just came across an invitation for BugCon 2012.

BugCon is a Mexican conference devoted to computer security — I cannot comment on its level or value because, although it's a topic that has long interested me, I must recognize each day I feel less of an expert, nowadays finding myself at the level of a "sysadmin who tries not to be too dumb for his own job security". Oh, and also because it would be completely off-topic for this post.

If you look at Vendetta's (the main organizer) blog post, it will probably give you the impression that the conference is just an excuse for the afterparty: Lets go see some b00bs! Do you think your fellow female hackers will have any interest in joining a bunch of sex-starved, hormone-infested teenagers who only want to pwn a website and grab more pr0n? Do you think females will feel welcome (or even mildly safe) between you? I would not think so. And I also think you are alienating any professional who might have any interest in joining your community, be it as a member, as a mentor, or whatnot.

I cannot right now do a coherent post on this topic, but I can reference you to what I have seen (and read) over the last almost 10 years, when the issue was first brought up to our attention. I am very glad to see that, at least in the Free Software area, there has been a real change of mindset. I hope you are in time to think about it and rectify.

  • Timeline of incidents in Geekfeminism. Note that while it seems we see more as time passes, I am almost sure it's because we are more aware of the problem, not because it occurs more often. I hope I'm not mistaken.
  • Debconf ftp-masters talk. Myself a Debian person, my first contact with this problematic was being at the DebConf3 ftp-masters talk — And the discussion and action that followed. This led to the creation of the Debian Women group, one of the most (socially, not technically) influent parts of Debian. Great thanks and admiration to their members, as well as to the (male and female alike) people who have worked to form it and make it heard.
    I think Debian Women sparked other similar projects such as GnomeWomen (and there is a list with further projects in there), but I cannot authoritatively say who was there first.
  • Planet Fedora up-skirting photo (the original post is still available) showed the communit does no longer tolerate this behaviour. Good!
  • The Open Source Boob Project. One of the most childlike attempts at humor that surely alienated many would-be female geeks.
  • Another conference season, another dumb sexist, a post by Piers Cawley addressing this issue after attending the CouchDB + Ruby: Perform like a Pr0n star talk. Quoting him, Apparently, the difference between 80s truck salesmen and Matt’s audience is that at least 80s salesmen had the grace to look embarrassed.
  • Liz Keogh: "I am not a pr0n star: Avoiding unavoidable associations", a hacker woman that clearly felt offense by the CouchDB Pr0n Star joke, and did a thorough and interesting analysis, extending the effects to your work environment.
  • Just Say You're Sorry Already (regarding the same incident on CouchDB+Ruby)
  • Richard Stallman's EMACS virgins joke incident. It's sad how it's impossible to get Stallman to acknowledge he can also make mistakes and make feel people insulted.
  • [update] And of course, MadameZou mentions the very important 2002 HOWTO: HOWTO encourage women in Linux?

Oh, and not the description of an incident, but a very interesting and thoughtful take on this: [pdf] Interesting analysis by Hannah Wallach on the numbers and motivations of women in Free Software groups. I don't know if Hannah has published this in article form, but many interesting points can be understood by looking at the presentation.

My good friend Vendetta: I don't mean this post (longer than what I originally intended) as a way to say you and the conference you are organizing for the third year (IIRC) already is unprofessional or targetted to pimply teenagers. I know the work you have put in it. I hope you see the points I'm trying to drive — You are of course free to have whatever afterparty you have. But, if as the main organizer, you are giving the images of nice chicks at Hooters more weight and relevance than to the conference itself... you are doing yourself a disservice. I hope you can rectify it, and make BugCon attractive to hacker women as well.

24 January, 2012 03:11PM by gwolf

Julian Andres Klode

Managing system package selections using custom meta packages

Over the last years, I have developed a variety of metapackages for managing the package selections of the systems I administrate. The meta packages are organized like this:

jak-standard
Standard packages for all systems
jak-desktop
Standard packages for all desktop systems (GNOME 3 if possible, otherwise GNOME 2)
jak-printing
Print support
jak-devel
Development packages
jak-machine-<X>
The meta package defining the computer X

Each computer has a jak-machine-X package installed. This package is marked as manually installed, all other packages are marked as automatically installed.

The machine packages have the attribute XB-Important: yes set in debian/control. This creates an Important: yes field. This field is not official, but APT recognizes it and does not remove those packages (the same field is set for the APT package by APT when building the cache, as APT should not be removed either by APT). It seems to work a bit like Essential, with the exception that non-installed packages are not installed automatically on dist-upgrade.

The meta packages are created using seed files similar to Ubuntu. In contrast to Ubuntu, I’m not using germinate to create the packages from the seeds, but a custom dh_germinate_lite that simply takes a seed file and creates the correct substvars. It’s faster than germinate and really simplistic. It also does not handle Recommends currently.

The whole result can be seen on http://anonscm.debian.org/gitweb/?p=users/jak/jak-meta.git. Maybe that’s useful for some people. And if you happen to find some packages in the seeds that are deprecated, please let me know. Oh, and yes, some packages (such as the letterman one) are internal software not publically available yet [letterman is a simple GUI for creating letters using LaTeX].

While I’m at it, I also built Ubuntu’s version of wine1.2 for i386 squeeze. It can be found in
deb http://people.debian.org/~jak/debian/ squeeze main (it still needs a few changes to be correct though, I’ll upload a jak2 build soon). I also built updated sun-java6 packages for my parents (mostly needed due to the plugin, some websites do not work with the IcedTea one), but can’t share the binaries due to licensing requirements. I may push out a source repository, though, so others can build those packages themselves. I’ll let you know once that’s done.


Filed under: Debian, General

24 January, 2012 09:43AM by Julian Andres Klode

hackergotchi for

Raphaël Hertzog

Answering questions of Debian users on various support channels

When you start your journey with Debian, you tend to have lots of questions. You’ll find some answers in various documentations but there always are remaining questions. Those can be asked on various support channels:

Those are the places where you can also start your journey as a Debian contributor… instead of asking questions, you just have to answer questions of other users! Let me share some advice if you want to do some user support.

User support is difficult…

It’s not always an easy task. Some users are more skilled than others and there might be difficulties related to the language, English is not always the native language of a user who asks a question in English.

Be respectful and courteous when you answer user questions, even if they made mistakes. You’re effectively representing Debian and you should give out a good image of the project. If you don’t have the patience or the time needed to do a good answer, don’t reply and let someone else take care of this user. I invite you to read (and follow!) the Debian Community Guidelines.

Avoid RTFM answers, instead you should show the users how they could have found (alone) the solution to their problem. We don’t want to scare people away, we want to grow our community.

But it’s also rewarding

In some cases, the problem reported by the user will be a real problem and you’ll have an opportunity to file a good bug report, thus helping to improve Debian for everybody.

Often, you don’t even have the answer to the user’s question. But you’re more skilled than him/her to do researches on the web, or you know of a good documentation that might contain the relevant bits of information, in any case you’re doing further research to help this user. In this process, you also grow your own skills since you’re learning stuff that you didn’t know yet.

At least that’s how I learned many things during my first year in the Debian community… there’s no reason why you couldn’t learn lots of stuff that way, in particular if you also read the answers of other skilled people on those channels (it takes a bit of training to learn who are the skilled people though).

I still believe that doing user support is one of the best ways to join the Debian community and to start contributing. It helps you to grow your skills, and to slowly progress from “average user” to “advanced user”.

If you want to start contributing to Debian, click here to subscribe to my newsletter and get future updates for new contributors. You can also follow me on Identi.ca, Google+, Twitter and Facebook.

5 comments | Liked this article? Click here. | My blog is Flattr-enabled.

24 January, 2012 09:00AM by Raphaël Hertzog

hackergotchi for

C.J. Adams-Collier

SOPA response from Representative Rick Larsen, WA 2nd District

Below is an email I received from Representative Rick Larsen‘s office. I don’t recall ever having identifying myself as PVT Adams-Collier in any communications with his office, though I could have done so at some point. Maybe. I also don’t recall contacting his office directly concerning SOPA. I blogged a few things and mentioned him on facebook a couple of times, though. It is good to know that I don’t always have to go directly to my representative to have my voice heard.

For those playing along at home, I think the best course of action would be for producers to perform searches for their work on peer-to-peer file sharing search engines such as http://thepiratebay.org/ and http://scrapetorrent.com/. If producers find that their work is being distributed in a way which is contrary to their wishes, I advise the producer or their agent to contact the individuals operating seeds with high share ratio in order to ensure that they perform AAA before accepting new peers into the swarm. Those seed operators who refuse to negotiate reasonable AAA terms should be issued C&D orders, and legal action should be taken, should they fail to comply with the request.

[edit 2012-01-24T05:27:44]

It would probably be wise to impose a minimum fee of $5 for seed operators per content package they distribute. This will encourage them to pass this fee on to their subscribers in a legal and responsible manner. I recommend that it be distributed in the same fair and concise way in which the tickets are distributed for toll violations on the Tacoma Narrows Bridge. Ask me how I know.

This will provide content producers a valuable distribution channel which is closely in touch with the consumers of the producers’ media. I believe that if the producer puts forth effort in good faith to develop and maintain relationships with key distribution points, we will see a situation where both content producers and consumers get what they want.

The authorization phase of the AAA system could charge a Payment Card Industry or bitcoin account a reasonable fee. My employer produces content delivery appliances which would serve quite well the role of AAA gateway.

For an example of this use case in action (sans account billing), I recommend contacting seeding participants of the Debian CD/DVD swarms. I will proxy such requests if there is interest.

An alternative might be a tool developed for the online gaming community with a strange name:

http://www.evenbalance.com/



Dear Pvt. Adams-Collier:

Thank you for contacting me about the Stop Online Piracy Act (SOPA) and the Protect IP Act (PIPA). I wanted to update you on my views on this important issue.

I am opposed to SOPA and PIPA in their current forms. I believe that these bills create unacceptable threats to free speech and free access to the internet. I have heard from many of you in Northwest Washington who are deeply concerned about the potential impacts of SOPA and PIPA.

Online piracy is a serious problem that costs U.S. businesses billions of dollars. Government agencies must be empowered to stop and prosecute intellectual property thieves. But in doing so we cannot undermine freedom of speech or jeopardize the free flow of information on the internet. I will work with my colleagues to see that any final anti-online piracy legislation protects the internet and does not encroach on free speech rights.

Please be assured that I will keep your thoughts in mind should I have the opportunity to vote on any legislation that would impact online piracy and internet freedom on the House floor.

Again, thank you for contacting me. I encourage you to contact me in the future about this or any other issue of importance to you.

Sincerely,

Rick Larsen
United States Representative
Washington State, 2nd District

[edit 2012-01-24T05:28:09]

Sincerely,

C.J. Adams-Collier
San Juan County Democratic Central Committee (*whew*) PCO
San Juan County, Washington State, Orcas 3 District

24 January, 2012 01:37AM by C.J. Adams-Collier

hackergotchi for Paul Tagliamonte

Paul Tagliamonte

Hey look! Openstates data!

Sweet!

npr’s site is using some OpenStates data, the project I’m currently working on at sunlight labs.

If you feel like affecting change in US politics, and know Python, we could use some help (it’s a F/OSS project!) over on github

Keep being awesome!

24 January, 2012 01:25AM

Lior Kaplan

RTL status for Libre Office 3.5.0

As LibreOffice is approaching its final 3.5.0 release, I’d like to sum up the RTL status for RC1.

So far, 6 RTL related bugs were resolved in the 3.5 cycle (#32530, #34222, #40950, #43790#43793, #44078), and a few minor issues reported directly to the developer’s mailing list got quick responses. Most importantly, the new features of page break and header/footer not only support RTL but actually looks good. During the LibreOffice conference I was suggested to help with these features, providing feedback, and I’m glade the needed attention was given to it.

Besides that, a few l10n and translation issues were solved in the process of doing the Hebrew translation (which also reflects on other RTL languages). At a few cases, these issue because a general l10n issues which affects all the languages.

In general, I found the core developers responsive to mails about RTL support. I’m sure the talk about RTL problems during the conference helped, as well as being more active in the project and having more personal acquaintance with the developers.

That’s being said, RTL support for LibreOffice still has problems, which I hope will be pushed during the 3.5.x cycles (full list at Bug 43808, the rtl meta bug). As to get some focus regarding was is to be done, I’m listing the top problems:

  1. #44657 – RTL UI: Horizontal scrollbar in calc main window is broken
  2. #33302 – brackets inverted in rtl text (mac only)
  3. #37692 – RTL list numbering reverses its direction
  4. #42070 - RTL support in broken in presenter Console extension
  5. #32531 - Incorrect cursor key movement between table cells of different directionality
  6. #104515 - RTL UI: moving active embedded object to the left moves it to the right (reported for OO.org, but verified in LibO)
  7. #37128 - Writer saves text alignment of RTL paragraph not according to the ODF specification

I hoped to have the first two done for 3.5.0, but didn’t succeed in getting them fixed. Will keep trying…


Filed under: i18n & l10n, Israeli Community, LibreOffice

24 January, 2012 01:16AM by Lior Kaplan

January 23, 2012

hackergotchi for

Neil Williams

Emdebian Grip automated dependency resolution

The script isn't fully automated yet, I'm running it manually and watching for errors, but I do now have a simple script (~100 lines of perl) which runs edos-debcheck against each of the supported Emdebian architectures for unstable-grip and picks out those packages which are missing from the subset of packages which Emdebian monitors for Grip.

I was hoping to make these scripts into a normal Debian package but there are some limitations in that the scripts need to assume various pieces of Debian infrastructure. e.g. I started off using rsync to pull in the Packages files (along with Release and Sources) because apt has annoying behaviours with multiple architectures. (Emdebian Grip processes 7 architectures simultaneously on blavet.debian.org). Peter Palfrader kindly arranged for a local mirror to be available and now the entire Packages processing can be done using symlinks. Much, much better.

Actual package movement data comes directly from dak via projectb - something else which makes packaging these scripts for use on non debian.org boxes a bit hard.

Once again, I am indebted to the EDOS team (please, please keep working on edos-debcheck - it hasn't had uploads recently) because I tried to get this working with germinate but failed. (Colin - I'll be looking to borrow some of your time to work out what was going wrong.)

The dependency resolution script now means that I can meet release team requirements that when foo is updated in sid to depend on libbar2 but Emdebian Grip only has libbar1, the scripts will automatically pick up libbar2 and add it to Emdebian Grip. The current sid version gets pulled in and (the theory goes) will migrate into testing-grip as an almost automatically valid candidate. Processing of the dependency can happen within hours of the updated version of foo arriving in Emdebian Grip but as long as it happens within a few days I think everyone will be fine with it.

I've got a sync script too which can periodically run across the entire suite and check for packages which have slipped the net. I'll have to see how often that needs to run but once a week doesn't sound too painful.

Processing for Emdebian Grip is very fast. Most of the time is taken uploading:

2012-01-23 22:24:42 add sid-grip deb main armhf libfltk-images1.3 1.3.0-5em1
2012-01-23 22:24:52 add sid-grip deb main i386 libfltk-images1.3 1.3.0-5em1
2012-01-23 22:25:07 add sid-grip deb main mips libfltk-images1.3 1.3.0-5em1
2012-01-23 22:25:25 add sid-grip deb main powerpc libfltk-images1.3 1.3.0-5em1
2012-01-23 22:26:00 add sid-grip deb main amd64 libstdc++6-4.5-dev 4.5.3-12em1
2012-01-23 22:26:34 add sid-grip deb main armel libstdc++6-4.5-dev 4.5.3-12em1


(It was a lot longer, comparatively, when I was having to rsync and then dget instead of just read from the local filesystem.)

I've also been working on an init script which will gradually work through the subset of packages by order of Priority - approximately what a new architecture (like armhf) would do. Note that Emdebian Grip supports armhf already. The only slight concern is whether the init script needs to be throttled back to not flood the queues with hundreds of uploads an hour (which it could end up doing, at least for the first 24 hours).

Logs of package movements are available: http://www.emdebian.org/grip/logs.php

Packages can be searched too: http://www.emdebian.org/grip/search.php

More on Emdebian Integration on the Debian wiki: http://wiki.debian.org/EmdebianIntegration

Now all I need is a fix for #655919 :-) FTP team?

23 January, 2012 10:38PM by Neil Williams (nospam@example.com)

hackergotchi for Christian Perrier

Christian Perrier

2012 update 6 for Debian Installer localization

When you shake the tree, things happen..:-). I sent targeted update requests for level 2 (mostly espeakup and grub2).
  • Gujarati, Serbian and Tamil complete level 1
  • Bulgarian, Esperanto, Japanese complete level 2 and are now full 100%
  • Progress for Indonesian in level 1
  • Icelandic completes level 2
  • Simplified Chinese completes level 3 and is now full 100%
  • Hebrew completes level 3
  • First update for Wolof since ages
Status for D-I level 1 (core D-I files):
  • 25 languages 100%: bg cs de eo es fr gu it ja kk km ko mr nb nl pl pt ru sk sr sv ta th uk zh_CN
  • 5 languages 99%: bs fa hi si te
  • 3 languages 97%: ar eu tr
  • 2 languages 96%: be he
  • 4 languages 95%: bn dz id zh_TW
  • 4 languages 94%: ast da ga ro
  • 4 languages 93%: el hu is lo
  • 1 language 92%: sl
  • 3 languages 91%: et pa vi
  • others are 90% or below

Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.):

  • 19 languages 100%: bg cs de eo es fa fr he is it ja kk nl pt ru si sk uk zh_CN
  • 6 languages 99%: be da id sl sv th
  • 4 languages 98%: ca eu pt_BR ro
  • 1 language 96%: nb
  • 2 langauges 95%: el fi
  • 6 languages 94%: ar ast gl hr vi zh_TW
  • 8 languages 92%: bn bs hu ko ne pl sr tr
  • 10 languages 91%: dz ga gu ka km lt mk mr ta te
  • others are 90% or below

Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader)

  • 28 languages 100%: be bg bs ca cs de el eo es fa fi fr ga gl he is it ja kk nb nl pt ru sk sv th tr zh_CN
  • 2 languages 98%: hu uk
  • others are 90% or below
Full 100% completeness (hall of fame) for 14 languages: Bulgarian, Czech, German, Esperanto, Spanish, French, Italian, Japanese, Kazakh, Dutch, Portuguese, Russian, Slovak, Simplified Chinese

23 January, 2012 06:00PM

hackergotchi for Matthew Garrett

Matthew Garrett

UEFI and bugs

I gave a presentation on UEFI at LCA 2012 - you can watch it here, with the bonus repeat (and different jokes) here. It's a gentle introduction to UEFI, followed by some discussion of the problems we've faced in dealing with implementation bugs.

The fundamental problem is that UEFI is a lot of code. And I really do mean a lot of code. Ignoring drivers, the x86 Linux kernel is around 30MB of code. A comparable subset of the UEFI tree is around 35MB. UEFI is of a comparable degree of complexity to the Linux kernel. There's no reason to assume that the people who've actually written this code are significantly more or less competent than an average Linux developer, so all else being equal we'd probably expect somewhere around the same number of bugs per line. Of course, not all else is equal.

Even today, basically all hardware is shipping with BIOS by default. The only people to enable UEFI are enthusiasts. Various machines will pop up all kinds of dire warnings if you try to turn it on. UEFI has had very little real world testing. And it really does show. In the few months I've been working on UEFI I've discovered machines where SetVirtualAddressMap() calls code that has already been (per spec) discarded. I've seen cases where it was possible to create variables, but not to delete them. I've seen a machine that would irreparably corrupt its firmware when you tried to set a variable. I've tripped over code that fails to parse invalid boot variables, bricking the hardware. Many vendors independently fail to report the correct framebuffer stride. And those are just the ones that have ended up on hardware which crosses my desk, which means I haven't even tested the majority of consumer-grade hardware with UEFI.

The problems with UEFI have very little to do with its design or the ability of the people implementing it. After a few years of iterative improvements it stands a good chance of being more reliable and useful than BIOS. Increased commonality of code between vendors is a blessing and a curse - in the long term it means that these bugs can be shaken out, but in the short term it means that at least one hardware-destroying bug has ended up carried by multiple vendors. Right now we're still in the short term and it's likely that we'll find yet more UEFI bugs that cause all sorts of problems. The next few years will probably be a bumpy ride.

comment count unavailable comments

23 January, 2012 03:52PM

hackergotchi for Ben Hutchings (ben@decadent.org.uk)

Ben Hutchings

Testing backport of the isci driver for Intel C600 SAS/SATA controllers

Phil Kern made a general call for testing of Debian 6.0.4. I would like to more specifically point out that I backported the isci driver for Intel C600 SAS/SATA controllers. Unfortunately I have not yet had any testing results for this. If you have any machines with this hardware not yet in production, please do consider testing the new Linux kernel package, version 2.6.32-41.

23 January, 2012 02:53PM

hackergotchi for Philipp Kern (noreply@blogger.com)

Philipp Kern

Call for testing: Upcoming Squeeze point release 6.0.4

Adam sent a new call for testing for the next point release of Debian Squeeze. Please test the packages in squeeze-proposed-updates on some machines running squeeze if possible, so that we don't screw up your production machines with bad updates in a week. The point release is scheduled for January 28th, i.e. next Saturday. Don't forget to copy the debian-release mailing list when you encounter regressions. Thanks for your efforts.

If you want to receive these notices by mail, please subscribe to the debian-stable-announce mailing list.

23 January, 2012 08:55AM by Philipp Kern (noreply@blogger.com)

January 22, 2012

hackergotchi for Jonathan McDowell

Jonathan McDowell

I want you to see my storage automagically

For my day job I build storage systems. A lot of what I do at present involves caring a lot about how different OSes deal with things like new LUNs being presented from a SCSI target, or errors along a subset of the available paths to a device.

It will come as no surprise to you to discover that they all suck (for values of all equal to Linux, Solaris, Windows and VMWare). New LUNs are particularly annoying. I'm in the situation that creation and removal of a LUN is exceptionally easy.

Hmmm. Maybe I need to back up here a bit first. SCSI has the concept of a target (think, device, eg hard drive). Each target can present multiple logical units. Each of these is assigned a number - a Logical Unit Number. Most devices (a hard drive, or a CDROM drive) will present a single LUN. A storage array will tend to present multiple LUNs; one for each volume that is exported to the host. At the host level each LUN really just looks like a separate device (for Linux /dev/sda and /dev/sdb may well be separate LUNs on the same array, rather than 2 separate arrays/hard drives, for example. At the block device level you don't care about the difference usually).

Anyway. For various reasons I end up adding and removing LUNs quite often. And there are ways for the array to indicate that this has happened to the host (the UNIT ATTENTION/REPORT LUNS DATA CHANGED check condition seems to be favoured these days, as a complete Fibre Channel LIP can be disruptive). What I'd like to happen in that case is the host to pick up the check condition and drop and/or add the devices that have changed. Instead everything wants a manual rescan. rescan-scsi-bus tends to be simplest for Linux. Windows wants a manual refresh in Disk Administrator. VMWare a "Rescan HBAs" from vSphere. Solaris a "devfsadm -C" and possibly a "cfgadm -al" first. And all of these can be temperamental about picking up the changes.

We've done a lot about hotplug for the desktop user experience, without doing the same level for the server experience. I appreciate that there are situations that you don't want your server to reconfigure things without being told to, but the current situation can be detrimental (for example Linux multipathing will hold a device open even after it's disappeared and is returning an "INVALID LUN" response; it would be much better if it could cleanly close that device and wait for it to return). Storage is capable of being much more than just a single block device these days, and it's a shame that nothing seems to deal fully with that fact.

(Yes, yes, I should write and submit patches, but I appreciate that there's not always a simple answer, nor necessarily an answer that works for all situations automatically. Plus, y'know, not enough hours in the day and I hope you all appreciate I've taken a break from watching BSG to write this.)

22 January, 2012 11:57PM

hackergotchi for

Kees Cook

fixing vulnerabilities with systemtap

Recently the upstream Linux kernel released a fix for a serious security vulnerability (CVE-2012-0056) without coordinating with Linux distributions, leaving a window of vulnerability open for end users. Luckily:

  • it is only a serious issue in 2.6.39 and later (e.g. Ubuntu 11.10 Oneiric)
  • it is “only” local
  • it requires execute access to a setuid program that generates output

Still, it’s a cross-architecture local root escalation on most common installations. Don’t stop reading just because you don’t have a local user base — attackers can use this to elevate privileges from your user, or from the web server’s user, etc.

Since there is now a nearly-complete walk-through, the urgency for fixing this is higher. While you’re waiting for your distribution’s kernel update, you can use systemtap to change your kernel’s running behavior. RedHat suggested this, and here’s how to do it in Debian and Ubuntu:

  • Download the “am I vulnerable?” tool, either from RedHat (above), or a more correct version from Brad Spengler.
  • Check if you’re vulnerable:
    $ make correct_proc_mem_reproducer
    ...
    $ ./correct_proc_mem_reproducer
    vulnerable
    
  • Install the kernel debugging symbols (this is big — over 2G installed on Ubuntu) and systemtap:
    • Debian:
      # apt-get install -y systemtap linux-image-$(uname -r)-dbg
      
    • Ubuntu:
      • Add the debug package repository and key for your Ubuntu release:
        $ sudo apt-get install -y lsb-release
        $ echo "deb http://ddebs.ubuntu.com/ $(lsb_release -cs) main restricted universe multiverse" | \
              sudo tee -a /etc/apt/sources.list.d/ddebs.list
        $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ECDCAD72428D7C01
        $ sudo apt-get update
        
      • (This step does not work since the repository metadata isn’t updating correctly at the moment — see the next step for how to do this manually.) Install the debug symbols for the kernel and install systemtap:
        sudo apt-get install -y systemtap linux-image-$(uname -r)-dbgsym
        
      • (Manual version of the above, skip if the above works for you. Note that this has no integrity checking, etc.)
        $ sudo apt-get install -y systemtap dpkg-dev
        $ wget http://ddebs.ubuntu.com/pool/main/l/linux/$(dpkg -l linux-image-$(uname -r) | grep ^ii | awk '{print $2 "-dbgsym_" $3}' | tail -n1)_$(dpkg-architecture -qDEB_HOST_ARCH).ddeb
        $ sudo dpkg -i linux-image-$(uname -r)-dbgsym.ddeb
        
  • Create a systemtap script to block the mem_write function, and install it:
    $ cat > proc-pid-mem.stp <<'EOM'
    probe kernel.function("mem_write@fs/proc/base.c").call {
            $count = 0
    }
    EOM
    $ sudo stap -Fg proc-pid-mem.stp
    
  • Check that you’re no longer vulnerable (until the next reboot):
    $ ./correct_proc_mem_reproducer
    not vulnerable
    

In this case, the systemtap script is changing the argument containing the size of the write to zero bytes ($count = 0), which effectively closes this vulnerability.

UPDATE: here’s a systemtap script from Soren that doesn’t require the full debug symbols. Sneaky, put can be rather slow since it hooks all writes in the system. :)

© 2012, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

22 January, 2012 11:22PM by kees

hackergotchi for Jonathan McDowell

Jonathan McDowell

Totally divorced

I got divorced earlier this month; the decree absolute arrived in the post last weekend. I'm hoping this isn't news to anyone who knows me well, and I only really mention it here as an endpoint given that I blogged about the wedding itself.

22 January, 2012 10:12PM

hackergotchi for gregoa

Gregor Herrmann

RC bugs 2012/03

here's the list of RC bugs I've worked on during the last week:
  • #590822 – python-jaxml: "python-jaxml: cannot be bytecompiled with Python 2.7: SyntaxError: cannot assign to __debug__"
    sponsor (modified) NMU by Miguel Landaeta, upload to DELAYED/2
  • #592382 – src:liblunar: "liblunar: hardcoded dependency on python-support"
    use ${python:Depends} in Depends [Jakub Wilk], upload to DELAYED/2
  • #615765 – pornview: "pornview: ftbfs with gold or ld --no-add-needed"
    add patch to pass -lm to linker, upload to DELAYED/2
  • #641971 – gsnmp: "Fix FTBFS with moved glib-2.0 headers."
    add patch from Ubuntu / Matthias Klose, upload to DELAYED/2
  • #643050 – src:autodir: "autodir: FTBFS: dpkg-buildpackage: error: dpkg-source -b autodir-0.99.9 gave error exit status 2"
    change config.{sub,guess} handling to a "3.0 (quilt)" compatible way, upload to DELAYED/2
  • #648384 – buildbot: "buildbot: FTBFS due to missing build-dependency on python-twisted-words"
    add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
  • #653953 – magicmaze: "magicmaze searches for Isabella.ttf in wrong place, crashes."
    add patch to search .ttf file in new location, upload to DELAYED/2
  • #654257 – src:newlib: "newlib: FTBFS: cannot find the library `sys/linux/liblinux.la' or unhandled argument `sys/linux/liblinux.la'"
    add patch from Ubuntu / Wookey & Steve Langasek, send to BTS
  • #654911 – python-lunar: "python-lunar: missing dependency on python-gtk2"
    add python-gtk2 to Depends [Jakub Wilk], upload to DELAYED/2

22 January, 2012 06:47PM by gregoa

hackergotchi for jmtd

Jon Dowland

The Crying Tree

Somebody bought The Crying Tree by Naseem Rakha for Sarah as a present and she asked me to read it so we could talk about it, so I did.

It's a novel about a family tragedy, Southern-state U.S.A. and the death penalty. A little boy is shot dead, a man is arrested for the crime and faces the death penalty. The book chronicles what happens to the family and to the killer during the 19 years or so that passes before the execution takes place.

The book could be accused of having an anti-capital punishment agenda, but I have no problem with that. At least until about half-way through the book, the plot and happenings follow the synopsis with little in the way of surprise, but then there's a twist.

I felt that the twist diminished the message of the book. Without trying to spoil what happens, I felt that you didn't need the core details of the story to be varied or expanded upon or U-turned to push that agenda. In my opinion, it's perfectly possible for someone to construct a story about a killer who faces death, who was unambiguously guilty of the crime they are charged with, and still leave the reader feeling remorse for the killer, and questioning the justice meted out. In fact I thought Rakha was doing a fine job of just that.

However, a twist (or twists) occur, and the facts are called into question, and so you ask even further questions about the practise of killing criminals, in my view redundantly.

It's a good book and worth a read, regardless of what your position is on the issue. It does a great job of describing the unbearable pain of losing a child, but also of the power of forgiveness for the victims.

22 January, 2012 03:57PM

Nikita Youshchenko

squeeze + iceweasel backport = no printing in gimp

Looks like installing iceweasel backport packages from

deb http://mozilla.debian.net squeeze-backports iceweasel-release

causes installation of backport of libcairo2 1.10 – which breaks printing from GIMP, as described in this ubuntu bug.

Does anybody know a fix/workaround?

Update: looks like running gimp with LD_LIBRARY_PATH set to directory containing library files from squeeze libcairo2 package (1.8.10-6) workarounds this.

But this story makes me think again that bundling libraries with applications is not that bad idea – at least for users who need to get things done.

22 January, 2012 12:25PM by nikita

hackergotchi for jmtd

Jon Dowland

bugs

[pic]

Bugs I've hit in GNOME 3, in the last 5 minutes:

  • gnome-shell's "run" pop-up lost focus and I couldn't get rid of it. Nor could I launch another "run" dialogue, which is my normal route for starting software.

  • I tried to coax my web browser into launching a terminal by browsing to file:///usr/bin/gnome-terminal. Instead, it downloaded a copy to ~/Downloads. Fine, no problem, because after another click it launches nautilus to handle the file. (This is not a bug).

  • nautilus doesn't know what to do with the file. Apparently I haven't installed a handler for viewing executable files. I'm guessing the copy of gnome-shell isn't +x. nautilus does sensible things when another file (such as a picture) is marked +x, so why doesn't it do so for the opposite case?

  • This is such a bizarre error message I try to take a screenshot of it. I take one, then take another (cropped). I try to save the second picture over the first one, but gnome-screenshot complains that it cannot find a file somewhere in /tmp.

  • The flash plugin crashed in the middle of streaming an album. I'm almost not allowed to complain about the flash plugin crashing.

  • After and around and inbetween all that, I downloaded an .amz file (an Amazon MP3 download file, in fact, of the album I'm failing to stream) which I hoped to run through clamz (a command-line, open source tool that can interpret AMZ files). nautilus offers clamz as a launch option in the right-click menu, but it's not the default handler. If I select "properties" to set the default handler, clamz is not in the list of available handlers.

  • After sending the HUP signal to gnome-shell, I've got rid of the "run" pop-up, but now something has happened to it's $PATH and future "run" pop-ups can't find anything in the standard locations, like /usr/bin.

  • since the flash plugin died, nothing else seems to be able to make any sound, so I can't play the album I downloaded anyway.

I didn't set out to bug-hunt this morning, I'm actually trying to get some work done.

Whilst this is a particularly bad case of stacked-bugs, it's unfortunately, pretty representative of what it's like to try and use a Linux desktop at the moment. Every day I go through a similar experience.

I've just had to give up and log out and back in again. The shell path bug above has re-surfaced in a new session. Great.

I'm waiting on a delayed laptop at work. I'm very tempted to cancel the order and just use a Mac Air instead (we have one spare). It seems I'm walking the inevitable path of F/OSS desktop frustration and the end for many people seems to be the Mac… perhaps I should spare myself the pain of the journey. In the mean time, It's bye-bye to GNOME and off to Xfce for me.

22 January, 2012 10:51AM

hackergotchi for

Tore S. Bekkedal

Six months later

Today, six months have passed since the massacre I survived at Utøya. It strangely feels simultaneously as if it happened ages ago, and as if it happened yesterday. I will write a longer post at some point, to try to sum up some thoughts, feelings and reflections I have made in the aftermath. But this post is actually intended to be somewhat, albeit weirdly, cheerful – because today, of all dates, I was given a link to a web album by the Police where they post photographs of items they have recovered and cleared for re-release.  And I got a kick out of this. Check it out!

 

I’m getting my OpenVMS shirt back! Yay for conference T-shirts!

22 January, 2012 09:14AM by toresbe

January 21, 2012

David Welton

Thinking at the Margin

Something I've picked up from reading about economics is the concept of "the margin".  It's a way of thinking about problems that more people ought to take into consideration.

What is "the margin"?  It's that space on a line, in the middle, between two extremes, where the transition from "yes" to "no" occurs.  If I offered you a million dollars for the computer you're reading this on (for broad definitions of 'computing device'), you'd probably take me up on the offer.  For 0 dollars, you would not.  Somewhere, in the middle, is a number where you'd change your mind from "nope, won't sell" to "well... sure, what the heck".  That is, loosly defined, a margin.

As an example, when people debate about "intellectual property", they often use terrible examples: companies like Microsoft, or performers such as Lady Gaga.  Those are bad examples because they are complete outliers, way off on one end of the curve.   It's hard to disagree with "so what if Lady Gaga earns a bit less revenue from her music, she's got plenty to live on" when you talk about copyright being a means for artists to support themselves with.  Thinking "at the margin" is about those bands that currently barely sell enough music to work professionally as musicians.  In scenario A, they are able to work creating music, thus creating more, and likely better music than if they merely pursued it as a hobby.  In scenario B, they fall on the other side of the margin and therefore have to get 'real jobs'.  This means that their music takes a back seat, and they produce less of it.

Now, copyright and company are a complex conundrum with many facets; my point is simply that when thinking about big changes, we should think what will happen at the margin, not what will happen to the outliers.

21 January, 2012 11:44PM

Lior Kaplan

PHP 5.4 @ Debian

PHP 5.4.0 is around the corner, with RC6 released this weekend. With the courtesy of Ondřej Surý it’s already available in experimental.

Earlier this week, Raphael Geissert, tested some PHP extensions with the new version and reported 16 bugs (severity: important) against those who failed to build with PHP 5.4. As they will become RC bugs when 5.4.0 will enter unstable (probably around mid February), I preferred to handle them sooner than later. The result is 3 patches sent (one already uploaded) and 5 NMUs done.

During the process I poked through a lot of upstream SCMs. In the way I found out a trivial change was done in PECL’s SVN two years ago for all the extensions located there, which got me suspicious regarding some extensions we have. For non PECL hosted extensions, I had to track if and when a fix was done and use it for building or do a trivial fix myself. Packages using the 3.0 (quilt) source format were extremely easy to fix, and I was quite happy it generally went fast.

In general I’m a passive subscriber to the Debian PHP Maintainers mailing list, and finally could help actually and not just reply emails. For me it’s also doing some Debian work after a few months of focusing on the coming LibreOffice 3.5 release.

update [26/1/2012]:

From the 16 issues, only 2 aren’t fixed already or will be on the next upstream release. As their upstreams are dead, this is in the hands or the debian people, at least till they’ll FTBFS on unstable (instead of experimental).


Filed under: Debian GNU/Linux, PHP

21 January, 2012 10:52PM by Lior Kaplan

hackergotchi for Joey Hess

Joey Hess

olduse.net 1982

Hard to believe I've consumed all of 1981's Usenet posts now on olduse.net, and it's been running for 7 months already.


Last night, there was a "very long" post, describing nearly every node on usenet in 1982. There had been a warning about this post the day before, since it would take many sites half an hour to download at 300 baud. It was handily formatted as a shell script, which created per-node files.

So, I ran this code nobody has run since 1982. It worked. I got files. I tossed them on the olduse.net wiki, and used some ikiwiki code TOVA contracted me to write just a few months ago, to make clickable links on my usenet map.

usenet map

The map data was contributed in another post a while back. By 1982, usenet is getting nearly impossible to map with 1982 technology of ascii art. I enjoyed throwing graphviz, git, wikis, and the web at it.

So, we have a collaboration across time, me and "Mark" and a lot of people who described their usenet nodes and piles of technology that make creating a mashup easy. Awesome!


I blog about stuff I find on the olduse.net blog. It's an open blog; Koldfront also blogs there, and we welcome other bloggers.

Some of the highlights for me have included:

As the space shuttle program is winding down, reading the excitement about the first shuttle flights, and the play-by-play coverage of a launch, posted to net.columbia by a high school student borrowing his dad's account. (A usegroup name that's hard to read without remembering its fate).

The announcements of the Motorola M68k, the IBM PC, and the CD-ROM.

world ipv6 launch Reading the TCP-IP digest, and Postel's plans for launching IPv4 soon, while the world IPv6 launch is being planned now. (The nay-sayers are especially fun to read. Including the guy who was concerned about the address space size, in 1981!)

Learning that nethack ascention tales have a history streching back 30 years, to rogue, and that the stories back then had much the same flavor as they do today.

Various celebrity sightings. Dennis Ritchie teaching C and Unix. Bill Joy talking vi. RMS talking .. nuclear politics?

The general development of usenet. B-news being rolled out, groups proliferating, many first inklings of what will be major problems and developments in 5 or 10 years. A shift in tone is already apparent, by now usenet is not only about announcements, there are already some flames.

oldusenet in a period terminal

Still 9 years to go!

21 January, 2012 08:58PM

hackergotchi for Andrew Pollock

Andrew Pollock

[debian] Bits from the ISC DHCP Maintainer

I really should write these a bit more often.

Wow, I can't believe it was over 4 years ago that I started having occasional face to face meetings with the ISC DHCP folks.

The entire ISC DHCP team (of 5) was in town for an all-hands meeting, and Larissa Shapiro, the Product Manager for DHCP (and BIND) suggested it would be a good opportunity for another catch up. Given the current (bad) state of DHCP 4.2 in unstable, I thought this was an excellent idea, and so we all had lunch on Tuesday.

I pretty much set the agenda, and it was

  • general state of 4.2.2 in Debian
  • situation with GNU/Hurd and their patch to fix an FTBFS (#616290)
  • the current FTBFS issues with kFreeBSD (#643569)
  • the embedded BIND sources in the DHCP source
  • removal of the RFCs from the embedded BIND source (#645760)

The general state of 4.2.2 in Debian

In a nutshell, it's a bit of a mess. We've got release critical bugs, build failures, the whole cat and kaboodle. It makes me very sad, because 4.2.2 was the first 4.2 series that I had a chance to upload, and I was very excited to do so, because it contains the hotly desired LDAP patches merged upstream. Unfortunately, it's also got the beginnings of the BIND/DHCP merger that's going to be BIND 10, and that is all a bit of a mess. It's directly responsible for the kFreeBSD FTBFS and the introduction of the RFCs, which are both keeping 4.2.2 out of testing.

I gave the ISC folks a high-level overview of how Debian development works, and the normal progression of packages from unstable to testing to stable, and the release process and whatnot, and impressed upon them the implications of the current release critical bugs. I also showed them how Ubuntu development fitted into the picture. Finally, I showed them the popcon statistics for DHCP. I think they found it useful.

FTBFS issues on kFreeBSD

This was a good segue to #643569. The issue is actually with the embedded BIND sources. I'd already forwarded this bug upstream when it first happened, but I don't know what had happened to it. They seemed to act as if this was the first they'd heard of it. I'm hoping that they can get this fixed in 4.2.3, which is due around the end of the quarter.

Embedded BIND sources

Since we were already talking about an issue caused by the embedded BIND sources, we moved on to talking about #645760 and the existence of the embedded BIND sources in general. It should be pretty straightforward for them to strip the RFCs out of the source. They've already done it in the past for the DHCP sources, so I'm also hopeful that this will get resolved in 4.2.3.

The issue of the embedded BIND sources is apparently a bit more complicated, although the day before our meeting, Michael Gilbert filed #643569 and #645760, so I hope that the ISC folks can take a look at these patches and see if it's feasible to adopt them.

Patches for GNU/Hurd

Finally we talked about #616290, which I know is near and dear to the GNU/Hurd porters' hearts.

We probably spent the most time talking about this. The DHCP developers have concerns about accepting a patch for an OS that they do absolutely no testing on, and also questioned the viability of the OS in general. They stressed that they're fairly thin in numbers relative to what they have on their plate to achieve this year, and so pushed back pretty firmly on accepting the current patch.

I relayed the frustration that the Hurd folks were having about a lack of dialogue around the patch (most of the interaction has been via an ISC support person). There was actually a bit of a split between the developers, with one of them appreciating that the Hurd was unlikely to go anywhere as a platform without a working DHCP client, so in some regards, they were condemning the platform by taking the position they were taking.

They're going to go away and take another look at the patch and try to come back with some actionable feedback on what needs to change to make it more acceptable to them, so we'll see what comes of this. I'm not particularly optimistic that anything acceptable to the GNU/Hurd folks is likely to happen any time soon, but maybe if the patch gets cleaned up a bit more, I'll just bite the bullet and start applying it to the Debian package.

BIND 10

One of the guys is more involved in BIND 10 than DHCP, and asked if I could help out with the packaging of a build dependency for BIND 10. It seemed like #578387 was languishing so I offered to pick it up. I've not packaged a library before, mainly because the library packaging guide has scared me off it (I feel I lack the deep C fu that seems necessary), but I figured that this would be a good learning opportunity, so I'm going to dive in.

21 January, 2012 02:38PM

hackergotchi for Steve Kemp

Steve Kemp

So mega-upload is gone

So the site http://megaupload.com/ has been taken offline, amidst allegations of knowingly conducting in piracy.

There are probably a lot of legitimate users who have lost access to their uploaded files, even if they were offsite backups you can imagine a user owning a website which now has a million dead-links.

This reminds me of a conversation I overheard on Jon Dowlands blog - the summary is that he'd written a (useful) tool to extract attachments from Maildir folders and was wondering how to store and access those attachments. The upshot seemed to be magical URLs of the form:

  • https://file.example.com/sha1/509c2fe2eba509e93987c3024a74d74583c274bd

The comments covered an alternative which was hash:///sha1/xxxxxxxxxxxxxxxx, which then becomes close to the magnet:// schema.

I've not yet thought things through, but I can't help thinking that with the redundency already present in the internet we should be looking at non-server-specific links. Yes there are times right now when you might want to address a specific file on a specific server - but otherwise? Wouldn't it be nice if you could just access a file from "anywhere" which happened to have the right contents?

Already my nonporn-but-definitely-adult-site makes its images available as /img/$md5sum.jpg - and similarly the storage at the back-end of my random image upload site uses SHA1 hashes to store the actual files.

To make this more complete what we need is something that crawls the internet to find files by hash; then add support in browsers. Obviously this must be async and could introduce timing issues, but fundamentally it seems like a reasonable approach to the problem of a single host going offline.

(Consider what happens if imgur.com disappears. All those links would die, yet 99% of the images would still be available somewhere.)

I'm tempted to suggest microformat format but I need to consider the matter. Right now I'm going to immediately update my current image hosts to use, at the very least:

 <a href="/foo" rel="sha1:xxxxx md5sum:xxxx">
  <img src="foo.jpg" alt="img name">
 </a>

The unfortunate thing is you cannot have a 'rel="xx"' attribute for an image. So you either have to encode it in the parent link, or add it to the alt attribute which is suboptimal.

ObQuote: "Now, they tell me I paid my debt to society." - Oceans Eleven (2001)

21 January, 2012 12:42PM

hackergotchi for

Bartosz Feński

Unlock your X without password

Yep… it’s pretty simple. Just press CTRL+ALT+* (from numerical keyboard).

Peter Hutterer, an X.org developer, posted an interesting article about this.

And the link to the original blog entry about it.

21 January, 2012 09:11AM by fEnIo

January 20, 2012

hackergotchi for Paul Tagliamonte

Paul Tagliamonte

Dual-screen setup with aligned bottom edges

For the sake of anyone else who’s fighting their screens, I’ve got a script that will do this (but very very slowly)

setup script

xrandr --output VGA1  --auto
xrandr --output LVDS1 --auto
xrandr --output VGA1  --rotate left
eval "`monconf`"

monoconf script

#!/usr/bin/env python
import subprocess
output = subprocess.check_output(["/home/tag/.bin/mon.ls"])
output = [ item.split() for item in output.split("\n") ]

mons = {}

for mon in output:
    if len(mon) > 0:
        if mon[1] == "connected":
            res=mon[2]
            res=res.split("x")
            for item in res[1].split("+"):
                res.append(item)
            res.pop(1)
            mons[mon[0]] = res

BOTTOM_LEFT = "LVDS1"
TOP_RIGHT="VGA1"

LEFT_WIDTH  = mons[BOTTOM_LEFT][0]
LEFT_HEIGHT = mons[BOTTOM_LEFT][1]

RIGHT_WIDTH  = mons[TOP_RIGHT][0]
RIGHT_HEIGHT = mons[TOP_RIGHT][1]

print "xrandr --output %s --pos 0x%s" % (
    BOTTOM_LEFT,
    (int(RIGHT_HEIGHT) - int(LEFT_HEIGHT)))
print "xrandr --output %s --pos %sx0" % (
    TOP_RIGHT,
    int(LEFT_WIDTH)
)

and the mon.ls command

xrandr -q | grep "^[^\ ].*" | grep -v Screen

All of this is super hacky, but it works.

20 January, 2012 09:35PM

hackergotchi for

C.J. Adams-Collier

Power blip in Tukwila – everything’s okay.

There’s been a lot of weather here in Seattle this week. It looks like the Tukwila DC’s power blipped this morning. It gave me an excuse to update some configs on a few of the OpenVPN endpoints, re-configure some of the shorewall6 stuff, and enter a bunch of hosts and IPs into the BIG-IP’s node list. It gives me a quick way to know what needs fixing first when things start breaking and is a lot easier to configure than NAGIOS. If I really wanted to get fancy, I could even write me some hot external monitoring scripts in perl. I am growing fond of this machine.

20 January, 2012 08:49PM by C.J. Adams-Collier