We re now in the middle of the talk submission period. Our new web interface doesn t allow to show all the proposals and we decided to start accepting some talks in order to inspire you to propose your own talks.

• Outsourcing your webapp maintenance to Debian
• bugs.debian.org Database Ho!
• use Perl; # Annual meeting of the Debian Perl Group
• Status of the Debian OpenPGP keyring
• seeing Debian through a Functional lens
• Debsources: powering sources.debian.net
• A glimpse into a systemd future
• New Network Interface Manager for Debian: ifupdown2

If your talk is not on the list doesn t mean is not accepted, don t panic! And now, we re calling you all to bring up your best Debian-related ideas, proposals, stories. To think about what you want to organize a discussion on. Which tracks would you like to coordinate or see populated with interesting talks. Talks are the main ingredient for a successful, interesting, discussion-sparking DebConf. Don t be shy, and read how to submit your talk

Only a very short summary in English: I am Mexican. I am Jewish. I am almost completely disconnected from the local Jewish communities. And understanding the local Jewish communities is hard. There is a very interesting and brave campaign, recently started, called Neither do I The Mexican Jewish gay activist group Guimel, started off with this video (with English subtitles, if you are interested in following along). But how did I learn about this very bold initiative? By getting a hateful spam, inviting people to join a hate campaign. Right, the hate mail is not calling to violence, but it is based on premises as stupid as everybody's right not to include (to begin with). So, the least I can do about this is to share both said hate mail and publicly denounce my shock on reading this nonsense nowadays. And, also in Spanish (I know many people following me don't understand it Sorry, it would just take too long, and after all, it's mainly for local "consumption"), this is the reply I sent to them (and to the other recipients). Sorry in advance to the Spanish speakers for my exabrupts :) This was written "as is", without much prior thought, and quite angry about what I had just read.

Buf... Expresiones como esta, que hacen evidente la cerraz n de tanta gente en las comunidades jud as, justifican claramente por qu tantos nos hemos ido abriendo, integr ndonos a la sociedad circundante. Me da verg enza ser asociado como jud o a comunidades donde se defienden estos puntos de vista; si bien yo no soy de la comunidad Monte Sinai (como resultar obvio por mi nombre), para la sociedad en su conjunto s soy un jud o (as , a secas: Jud o). Mucho nos hemos quejado colectivamente a lo largo de los siglos acerca de la discriminaci n, de que seamos considerado la "basura" del mundo, los "apestados". Y es precisamente esa actitud, ante todo y en todo momento, lo que me ha llevado a alejarme del juda smo. Soy un ser humano m s, con una historia personal nica, con una historia cultural compartida pero tambi n nica, con algunas elecciones y algunas caracter sticas que me son inherentes nicas. Algo de eso no le gusta a alguien? Por motivos racionales o irracionales? No lo puedo ni pienso evitar. Pero el que una comunidad completa sea llamada a ignorar, humillar, alienar a sus hijos, por una estupidez as de anacr nica (en el caso que lo presenta el video al que hacen referencia, y a la gente que valientemente ha conformado Guimel) me parece que simplemente va m s all de toda estupidez. Piensen bien antes de adherirse a esta campa a de odio. Substituyan la sexualidad por cualquier otra raz n en la que somos minor a. No les da asco vivir con un vendedor de telas? Con un jud o apestoso? Y s , aqu ya estoy yo tambi n dejando ir a esos demonios... que hay que mantener bajo control. Porque somos hombres y mujeres de nuestro siglo, y porque el mundo y las nuevas generaciones merecen nuestro mejor esfuerzo para ir colectivamente destruyendo la estupidez de nuestros ancestros. Seamos m s racionales. Dejemos el odio, dejemos los prejuicios. Aceptemos a los diferentes, porque todos queremos que nos acepten. Porque todos somos diferentes.

Attachment	Size
tambien.txt	8.55 KB

Hi All, Team Elektra recently released version 0.8.6 to download, more information on that here: http://sourceforge.net/p/registry/mailman/message/32418614/ However, since I am working with Debian, and the Debian package isn t ready yet I have spent a large chunk of the week working on that. Namely I fixed a few minor lintian errors and worked on packaging the lua and python bindings for Elektra. These two packages, libelektra-python4 and libelektra-lua4 uses a tool called SWIG. SWIG allows C and C++ programs to connect to programs written in higher-level languages such as Python. So these two packages use the power of SWIG to bring the features of the Elektra API (which is written in C) to Python and Lua developers. I personally think it is a really neat feature and allows Elektra to be used more widely than ever before. As our project develops Elektra will support more languages and we are even moving to allowing Developers to write Elektra plugins using other languages. Additionally, I worked on improving the MergeTools library for Elektra. This library just contains the necessary functions to allow developers to complete a three-way merge of KeySets. This library also serves as the backbone of the kdb merge command. First, the KeySetMerge command now returns an empty KeySet if its unsuccessful. I added operator overloads for == and != to the KeySet.hpp class so developers can tell if the returned keyset is empty. I created a new function that takes in 3 KeySets, their parent keys (for the purposes of merging), and a merge_root key which will be where the merged keys are stored under. The prototype for this function is KeySet(KeySet base, Key base_root, KeySet ours, Key our_root, KeySet theirs, Key their_root, Key merge_root). A function still exists that just takes in 3 KeySets and a key, merge_root. That function attempts to find each root key and then calls the previously mentioned function. Why? This week I finalized the kdb merge command (not including options). This command takes in 4 root keys, one for base, one for ours, one for theirs, and one for where the merged keys should be stored. The merge command now uses the new function to be able to handle more complex KeySets and so far it works great! In this case we don t need to make any assumptions about the KeySet since the user needs to pass in the root keys (this is how the kdb commands typically work) so we make good use of this information. Now the kdb merge command only appends the merge KeySet to the database upon successful merge, otherwise it tells you what went wrong. Also, looking into the main feature of my GSoC project, automatic conffile merging, it seems that it will require patching dpkg. Originally I though package maintainers would have to edit their packages to not define their conffiles as such in order to use the automatic merge. However this is obviously a messy workaround. Patching dpkg however would allow very clean integration of this feature. If this project is successful and the patch makes its way upstream, all Debian packages that utilize conffiles (most of them) will basically allow automatic merging practically overnight. dpkg would attempt a merge on the conffiles during an upgrade and if unsuccessful would just prompt the user like it does now. In most situations however, because of the features of Elektra, conffiles should merge fine. This would make Debian much more user-friendly and could save users a lot of time manually merging conffiles. Oh, and look for a little tutorial and explanation of the kdb mount command in the next few days. I will post it here. Until Then,
Ian S. Donnelly

Recently two companies have suffed problems due to compromised AWS credentials:

• Code Spaces
  • The company has effectively folded. Thier AWS account was compromised, and all their data and backups were deleted.
• Bonsai
  • Within two minutes all their instances were terminated.
  • This is still live - watch updates of the recovery process.

I'm just about to commit to using Amazon for hosting DNS for paying customers, so this is the kind of thing that makes me paranoid. I'll be storing DNS-data in Git, and if the zones were nuked on the Amazon-side I could re-upload them, but users would be dead regardless - because they'd need to update the nameservers in whois before the re-uploaded data would be useful. I suspect I need to upload to two DNS providers, to get more redundency. Currently I have a working system which allows me to push DNS records to a Git repository, and that seamlessly triggers a DNS update (i.e. A webhook trigged by github/bitbucket/whatever). Before I publish anything I need to write more code, more documentation, and agree on pricing details. Then I'll setup a landing-page at http://dns-api.com/. I've been challenged to find paying customers before launching, and thus far have two, which is positive. The DHCP.io site has now been freed. I'm no longer going to try to commercialize it, instead I will only offer the Git-based product as a commercial service. On that basis I upped the service so users could manage up to five names per account, more if you mail me privately and beg ;) (ObRandom: Google does hosted DNS with an API. They're expensive. I'm surprised I'd not heard of them doing this.)

On many occasions I ve seen discussions about the background knowledge that people are expected to have to contribute to FOSS projects. Often the background knowledge is quite different from the core skills related to their contributions (EG documentation mark-up skills required for coding work or knowledge of code required for writing documentation). One argument in favor of requiring such skills is of the form anyone who s good at one aspect of the project can learn skills for the other areas . Another is of the form anyone who has time to contribute in one area has time to learn all the other areas, anyone who doesn t want to learn is being lazy . I think it s reasonable that someone who is considering donating their time to a project would want to start doing something productive immediately. If someone has to spend many hours learning how things work before contributing anything of value they may decide that it s not a good use of their time or just not fun. Also if the project is structured to require a lot of background knowledge then that will increase the amount of time that long-term contributors spend teaching newbies which is another way of sucking productive energy out of a project. I don t think it s lazy to want to avoid learning unusual tools before starting a project. Firstly there is the issue of wanting to make productive use of your time. If you have a day for FOSS contributions and you can choose between spending 6 hours learning an environment for one project or 1 hour for another project then there s a choice of 2 hours or 7 hours of productive work. Someone who has the luxury of being able to spend several days a month on FOSS projects might think it s lazy to want to make effective use of 1 day, but there are a lot of people out there who are really busy and can only spend a few days a YEAR contributing, spending half a day learning an obscure development environment or documentation system can take a significant amount of someone s yearly time for such work. To make things even worse some of the best programmers are the ones who have little free time. For documentation MediaWiki (the software behind Wikipedia and Wikia.com) has a lot going for it. While it s arguable that it s not the best Wiki software out there (many people have wanted to argue this with me even though I don t care) it s obvious that MediaWiki is the most widely used Wiki software. If you have documentation stored in MediaWiki then most people who have any exposure to the IT industry, the FOSS community, or the Internet in general will already have experience using it. Also Wikipedia serves as a large example of what can be done with MediaWiki, there have been more than a few occasions when I have looked at Wikipedia for examples of how to layout text. Some people might think I m lazy for never reading the MediaWiki documentation, but again I ve got lots of other things to do and don t want to spend a lot of time learning about MediaWiki instead of doing more useful things like creating content. Project source code should be as consistent as possible. While large projects may have lots of modules and dependencies it s best to try and keep them all in one place. If your project depends on libraries of code from other sources then it s helpful to distribute copies of those libraries from the same location as the project source particularly when the project depends on development versions of libraries. Then if there s any mismatch between versions of libraries it will be a clear unambiguous bug that can be reported or fixed instead of being an issue that requires checks of what versions everyone is using. One thing we should aim for in FOSS projects is to get the long tail of contributions. If someone spends a day fixing bugs in a dozen projects to get their own system working as desired then it would be good if they could submit patches without excessive effort at the same time. This doesn t just apply to FOSS development, it also applies to a large extent to any collaborative project on the Internet. For example if I was to start a Wiki for fans of a sci-fi series wikia would be the first option I d consider because most potential contributors know it. Proprietary Software Development I ve seen all the same problems when developing proprietary software. The difference is that money and morale is wasted instead of contributions. Often in commercial projects managers choose products that have a good feature list without considering whether all their staff need to be retrained. Programmers can usually train themselves so it s often a hidden cost, the training is paid for in lost development time (both directly in time spent learning and indirectly when people make mistakes). One significant advantage of using free software on Windows is that programmers can play with it on their own. For example I ve never done a fresh installation of SourceSafe or ClearCase, but if I was going to work on a project that involved Git or Subversion on Windows then I could play with it and learn without risking disruption to the rest of the team. If commercial software is to be used then being common and relatively cheap is a significant advantage. MS SourceSafe offers significant benefits over most version control software on Windows simply because the vast majority of Windows developers have already used it and because it s cheap and easy to setup a test instance if necessary. I don t care about the success or failure of proprietary software projects in general (I only care when I m paid to care). I also don t expect that people read my blog with the aim of getting advice on running successful proprietary software development projects. This section is merely to illustrate the general nature of such wasted effort on collaborative projects and I should put my observations of failing proprietary software development projects to use. Debian Some Debian Developers are having a discussion about such things at the moment. That discussion inspired me to write this post. But I m mostly writing about my experience over the course of 20+ years working in the IT industry and contributing to FOSS projects not in a direct response to the Debian discussion (most of which I haven t yet read).

The press picked up the recent press release about Debian LTS but mainly to mention the fact that it s up and running. The call for help is almost never mentioned. It s a pity because while it s up, it s not really running satisfactorily yet. As of today (2014-06-19), 36 packages in squeeze need a security update, yet squeeze-lts has only seen 7 updates. As usual what we lack is contributors doing the required work, but in this specific case, there s a simple solution: pay people to do the required work. This extended support is mainly for the benefit of corporate users and if they see value in Debian LTS, it should not be too difficult to convince companies to support the project. With some other Debian developers, we have gone out of our way to make it super easy for companies to support the Debian LTS project. We have created a service offer for Debian-using companies. Freexian (my company) collects money from all contributing companies (by way of invoices) and then uses the money collected to pay Debian contributors who will prepare security updates. On top of this we added some concrete benefits for contributing companies such as the possibility to indicate which packages should have priority, or even the possibility to provide functional tests to ensure that a security update doesn t introduce a regression in their production setup. To make a good job of maintaining Debian Squeeze, our goal is to fund the equivalent of a full-time position. We re currently far from there with only 13 hours per month funded by 4 companies. That makes a current average of 3.25 hours/month funded by each contributing company, for a price of 276 EUR/month or 3315 EUR/year. This is not much if you compare it with the price those companies would have to pay to upgrade all their Debian 6 machines now instead of keeping them for two supplementary years. Assuming the average contribution level will stay the same, we only need the support of 50 other companies in the world. That s really not much compared to the thousands of companies using Debian. Can you convince your own company? Grab the subscription form and have a chat with your company management. Help us reach that goal, share this article and the link to Freexian s Debian LTS offer. Long Term Support is important if we want Debian to be a good choice for servers and big deployments. We need to make Squeeze LTS a success! Thank you!

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

I m in the process of moving to a new OpenPGP key, and I want to include a small JPEG image of myself in it. The OpenPGP specification describes, in section 5.12.1 of RFC 4880, how an OpenPGP packet can contain an JPEG image. Unfortunately the document does not require or suggest any properties of images, nor does it warn about excessively large images. The GnuPG manual helpfully asserts that Note that a very large JPEG will make for a very large key. . Researching this further, it seems that proprietary PGP program suggests 120 144 as the maximum size, although I haven t found an authoritative source of that information. Looking at the GnuPG code, you can see that it suggests around 240 288 in a string saying Keeping the image close to 240 288 is a good size to use . Further, there is a warning displayed if the image is above 6144 bytes saying that This JPEG is really large . I think the 6kb warning point is on the low side today, however without any more researched recommendation of image size, I m inclined to go for a 6kb 240 288 image. Achieving this was not trivial, I ended up using GIMP to crop an image, resize it to 240 288, and then export it to JPEG. Chosing the relevant parameters during export is the tricky part. First, make sure to select Show preview in image window so that you get a file size estimate and a preview of how the photo will look. I found the following settings useful for reducing size:

• Disable Save EXIF data
• Disable Save thumbnail
• Disable Save XMP data
• Change Subsampling from the default 4:4:4 (best quality) to 4:2:0 (chroma quartered) .
• Try enabling only one of Optimize and Progressive . Sometimes I get best results disabling one and keeping the other enabled, and sometimes the other way around. I have not seen smaller size with both enabled, nor with both disabled.
• Smooth the picture a bit to reduce pixel effects and size.
• Change quality setting, I had to reduce it to around 25%.

See screenshot below of the settings windows. Eventually, I managed to get a photo that I was reasonable happy with. It is 240 288 and is 6048 bytes large. If anyone has further information, or opinions, on what image sizes makes sense for OpenPGP photos, let me know. Ideas on how to reduce size of JPEG images further without reducing quality as much would be welcome.

Running Wireshark for Android has been an dream for a long time. Now it became a reality! You only need a rooted Android device with ~2GB free space, Internet connectivity and some patience to follow the steps below.

1. Install Lil Debi from Google Play or F-Droid. Lil Debi will install a Debian root file system in a loop device separately from the Android file system allowing us running Debian side-by-side to the Android apps.
2. Start Lil Debi and create the Debian system with 2000 MB image size. We will need some space for Wireshark, the graphical interface Wireshark depends on and for the capture files.
3. Start the newly created Debian system and log in to it. You will see the error message bash: [: : integer expression expected , but you can continue.
4. Now run the following commands at the command line to install all the packages Wireshark will need:

   # some important directories are missing from the PATH by default
   export PATH=/sbin:/usr/sbin/:$PATH
   # we will start an X server later
   export DISPLAY=127.0.0.1:0
   # install wireshark an a few things to make it nicer
   apt-get install openbox gnome-themes-standard tshark wireshark
   # gnome-settings-daemon depends on plenty of packages we don't need now,
   # but we need gnome-settings-daemon for the GNOME theme to be applied
   apt-get install --no-install-recommends gnome-settings-daemon

5. To run graphical applications from the Debian chroot we need to set up an X server on Android because Android uses a different method for presenting the GUI. XServer XSDL is available from Google Play and from SourceForge. Install and start it. It will show the display it is serving which will most probably end with :0, so the DISPLAY environment variable we set before is correct. (If there is an other number after the : , fix your DISPLAY variable.)
6. Start the openbox window manager, gnome-settings-daemon and finally wireshark in capturing mode:

   openbox &
   # if you would like to have bigger menu fonts skip starting gnome-settings-daemon
   gnome-settings-daemon &
   wireshark -k -i wlan0
   

7. Switch to the X server to see wireshark starting up, close the warning dialogs start capturing traffic!

I tested the tests above using a Nexus 7 (Asus 2013 version) running CyanogenMod M7, thus root access was granted by default, Lil Debi 0.4.7, and XServer XSDL 1.11.14.

AddThis:

Categories:

• Debian-Blog
• Technology
• Tools

Keywords:

• laptop-mode-tools

Yesterday, the Belgian team played against Algeria, and won 2-1. Before the match, there was some criticism about coach Wilmots' decision not to field a number of top players in the team at the start of the match. Today, some journalists -- including, apparently, some Russian journalists -- seem to think that the team didn't play all that well, and that the Belgian team could be beaten by a better team. I don't think that's the case; I think the strategy of Wilmots was a stroke of genius. The Algerian coach fielded a wall of 5 defenders, and played a pretty good counter game. When the Belgian team had posession -- for about 65% of the time during the entire match -- the Algerians returned every man to their own half of the field. Whenever one of the Belgian strikers came close to the Algerian penalty area, at least two Algerian players would be near and block them off. How does one win from a team that doesn't want to give you a millimeter of room? One way is to wear them out, and that's exactly what the team did: by keeping the pressure on the Algerian defense, the Algerian defense had to run a lot. Running a lot makes you tired, and if you're tired you make mistakes, or you can't follow a fresh substitute player. During half-time, it was reported that Wilmots had relayed the message to his players that "the bench will make the difference". And indeed it did; some time into through the second half, Wilmots substituted three players -- two strikers and one offensive midfielder -- with the top players he'd kept on the bench. Two of these three players made the difference, scoring two goals to end up with 2-1. Reading some articles today, it seems like many analysts think that this was a spur of the moment thing by Wilmots; but I think it's more likely that this was a deliberate strategy. Making the opposing defense run a lot is certainly a good strategy; but the downside of that is that your own offensive players will need to run a lot, too. If you can swap those out for top players on the bench... It'll be interesting to see the next matches.

I used to work for Bytemark, being a sysadmin and sometimes handling support requests from end-users, along with their clients. One thing that never got old was marking DNS-related tickets as "resolved", or managing to slip that word into replies. Similarly being married to a Finnish woman you'd be amazed how often Finnish and Finished become interchangable. Anyway that's enough pun-discussion. Over the past few days I've, obviously, been playing with DNS. There are two public results:

DHCP.io

This is my simple Dynamic-DNS host, which has now picked up a few users. I posted a token on previous entry, and I've had fun seeing how people keep changing the IP address of the host skx.dhcp.io.. I should revoke the token and actually claim the name - but to be honest it is more fun seeing it update. What is most interesting is that I can see it being used for real - I see from the access logs some people have actually scheduled curl to run on an hourly basis. Neat.

DNS-API.org

This is a simple lookup utility, allowing queries to be made, such as:

• http://dns-api.org/a/skx.dhcp.io
• http://dns-api.org/aaaa/skx.dhcp.io

Of the two sites this is perhaps the most useful, but again I expect it isn't unique.

That about wraps things up for the moment. It may well be the case that in the future there is some Git + DNS + Amazon integration for DNS-hosting, but I'm going to leave it alone for the moment. Despite writing about DNS several times in the past the only reason this flurry of activity arose is that I'm hacking some Amazon & CPanel integration at the moment - and I wanted to experiment with Amazon's API some more. So, we'll mark this activity as resolved, and I shall go make some coffee now this entry is Finnish. ObRandomUpdate: At least there was a productive side-effect here - I created/uploaded to CPAN CGI::Application::Plugin::Throttle.

Maybe someone else is using iDataPlex HW, so this might come in helpful... TL, DR: Dear Hardware Vendors! Please don't force people to use specific Linux distributions when a simple unzip command would do the same. At work we run (amongst others) an HPC system consisting of 120 IBM System X iDataPlex dx360 M4 Nodes. Recently, after some MCE logs caused by DIMM errors, the IBM guy refused to send me replacement DIMMs if if didn't update IMM firware and tortue test the machine some days more. Well, ok... IBM uses the so called UpdateXpress tool to update IMM and UEFI firmware. The tool is available for rhel4 to rhel7 (both 32 and 64 bit), SLES10 & SLES11 and Microsoft Windows. I tried all of the available UpdateXpress System Pack Installers, with basically the same result everytime:

WARNING! This package doesn't appear to match your system.
         The following information was determined for your system:
           distribution = Unknown
           release = -1
           processor architecture = Unknown

I tried to set up a fake RHEL environment (customized /usr/local/uname, custom /et/RHel-release, etc...) but after some more tries, the installer (yes, it's still the installer I am trying to run) fails with some strange SEGFAULTS. After some closer inspection, (well, the RHEL4 uxspi binary is about 109MB big!) i tried to unzip it, and voila:

~/firmware$ unzip ibm_utl_uxspi_9.60_rhel4_32-64.bin
Archive:  ibm_utl_uxspi_9.60_rhel4_32-64.bin
   creating: rhel6_64/image/
  inflating: rhel6_64/image/libpegasus.nsp.so  
  inflating: rhel6_64/image/libUxliteImmUsbLan.so  
  inflating: rhel6_64/image/eccConnect.properties  
  inflating: rhel6_64/image/libpegslp_client.so  
   creating: rhel6_64/image/esxi_assoc_templates/
  inflating: rhel6_64/image/esxi_assoc_templates/elxFC.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/elxCNA.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/ibmc.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/FPGA-S.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/degraded.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/brocadeFC.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/qlgcFC.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/broadcom.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/LSI.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/brocadeCNA.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/uefi.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/diags.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/qlgcCNA.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/VMwareESXi.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/ibmc2.uxt  
  inflating: rhel6_64/image/esxi_assoc_templates/FPGA.uxt  
  inflating: rhel6_64/image/libipmi_client.so  
  inflating: rhel6_64/image/UXLite_UPDATEID.dat  
  inflating: rhel6_64/image/libacpi.so  
  inflating: rhel6_64/image/libibmsp6_openipmi.so  
  ...

I managed to find a iflash64 binary, and after so trial and error, came up with the following workflow:

• Unzip the .uxz firmware file (you get this from the IBM Download Central):

  unzip ibm_fw_imm2_1aoo56d-3.73_anyos_noarch.uxz
  Archive:  ibm_fw_imm2_1aoo56d-3.73_anyos_noarch.uxz
  replace imm2_1aoo56d-3.73.upd? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
   extracting: imm2_1aoo56d-3.73.upd
    inflating: immalert.mib
    inflating: immRegistries.zip
    inflating: imm.mib
    inflating: OpenSourceNotices.html
    inflating: payload.xml
  

• Run the iflash tool:

./iflash64 --host your_host_imm_IP --user your_username --password your_password --package imm2_1aoo56d-3.73.upd --reboot
IBM Command Line IMM Flash Update Utility v2.02.11
Licensed Materials - Property of IBM
(C) Copyright IBM Corp. 2009 - 2014  All Rights Reserved.
Connected to IMM at IP address x.x.x.x.
Update package firmware type: IMM2
Update package build level:   xxxxxx
Target's current build level: xxxxxx
Would you like to continue with the update? y/n: y
Node 0: The IMM is preparing to receive the update.
Node 0: Transferring image: 98%
Node 0: Transfer complete.
Node 0: Validating image.
Node 0: Updating firmware:  0%
Node 0: Updating firmware:  100%
Node 0: Update complete.
Performing activation of the firmware:
Connected to IMM at IP address 10.8.2.4 successfully.
..........
Waiting up to 360 seconds for the activation to complete:
..
..

And so on... Conclusio: Dear Hardware Vendors! Please don't force people to use specific Linux distributions when a simple unzip command would do the same.

Warning: some spoilers ahead. A few months ago I saw the trailer for Edge of Tomorrow (film). Normally I don't look for trailers, probably this was shared on G+ by someone; but the basic idea behind the trailer was interesting enough I tried to look for more information about the (then upcoming) movie. To my surprise, I learned that this Hollywood movie is based on a Japanese novel - All You Need Is Kill. Since (broadly speaking) Japanese style is quite different from Hollywood style, I became even more interested. So I bought the book, and went through it quite quickly - I liked it a lot, and for the most part is has kept me reading and reading. I would say the book is quite straightforward, with a bitter-sweet ending that is what I (dreaded and) expected from it. Fast forward a few months, and yesterday I saw the movie. I had somewhat lower expectations for it compared to the book, but I was surprised at how they managed to morph the Japanese setting in the book into an European one and give a good introduction into the plot. The downside is that they had to make it somewhat melodramatic here and there, and that they added quite a bit of extra plot to fill in the time; on the other hand, it skipped a lot of background detail that the book brought and which explains the setting of the war. The biggest change however was to the overall plot line: the book is only about a single battle, and makes it clear at the end that the war is far from over. The movie, in grand Hollywood style, solves the entire war in one neat swipe, and has a quite happy ending. Which is not bad per se, but doesn't have the same emotional impact as the book. Oh, and they made the aliens scarier but in a strange way prettier (or better said less alien). Interesting that they felt the need to do it: the aliens in the book were (definitely) scary by their behaviour/abilities, yet they had to make them "look scary" in a way that connects to our visceral feelings, rather to the logical fear that a non-earth-like life form would bring. Speaking about the cast: I would still have preferred the Japanese setting of the book compared to the more western one in the movie, but at least one of the two main characters in the movie had a well-chosen person playing it. Overall, I'd give the book a 4/5 rating, and the movie (still) a 3/5. I enjoyed both, and the main plot idea is, if not new in SF, still appealing.

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

So, it seems that for a lot of people using unstable, hardware-related permissions (shutdown/reboot, suspend/hibernate, devices mount/umount etc.) have been broken since some times. That's usually the case for people using GNOME with lightdm display manager, Xfce with either gdm or lightdm. It seems that recently, policykit (which is used by GNOME and Xfce) switched from consolekit backend to logind backend (yeah, systemd-logind). So applications using policykit needs to handle that correctly, and that means beeing sure a logind session is correctly setup, which is done by installing the package libpam-systemd. For now, it's still possible to not switch to systemd as init system, by installing the systemd-shim package before libpam-systemd. Be aware that (at least with the current state of affairs), this is only true with logind before 204. When systemd maintainers start transitionning to a later version, only systemd-sysv (so, systemd as init system) will work. For people reluctant to switch to systemd, they can use systemd-shim for now. Then when systemd 205+ enters the archive, either lose those hardware permissions, or try to improve systemd-shim to handle that situation. There's not much we (Xfce/LightDM maintainers) can do about that.

Everything is set! The Debconf committee approved my accommodation sponsorship, my leave is confirmed and my airline tickets are booked, I m going to Debconf 14! It s going to be a 30 hour trip from Cape Town to Portland (I could shave off around 6 hours if I pay 120% more, doesn t seem worth it) and I ll be there for the full 9 days from 23 August to 31 August. I last attended Debconf 12 in Managua, Nicaragua and it was fun, educational and productive. I m really excited to see the Debian folk in person again and it will also be my first time in Portland. See you there!

The Debian project is excited to announce that we are now accepting presentations, discussion sessions and tutorials for our DebConf14 conference which will take place in Portland State University, Oregon, USA from 23 to 31 August. Submitting an event To submit an event, first register as an attendee for DebConf14 in the conference management system. If you have any doubts or have problems with the registration process please check the Registration FAQ. After registering, go to the event submission page, or click on the Create an event option from the management system. Describe your submission in the web form. The most common event types are Lecture or Open Discussion (BoF). Please include a short title (to make it easy to produce a compact schedule) and an engaging description of the event. Tracks We will organize some talks into thematic tracks. If you have a proposal for a DebConf track, such as "Debian ARM", "Debian Infrastructure", or "Community Outreach" please contact talks@debconf.org. If you would like to be a track coordinator, please volunteer on the given mail address. Format of the events A regular session will be 45 minutes long, including time for questions. There will be a 15 minute breaks between events. Submissions are not limited to traditional talks: you could propose a performance, art installation, debate, or anything else. If you have any specific requirements for your event, please send an email to talks@debconf.org with the details of your requirements and be sure to mention your event title in the subject. Deadline While we ask speakers to submit their events before the deadline of 7 July 2014, 23:59:59 UTC, late submissions will continue to be accepted for scheduling until the end of DebConf. All attendees will have an opportunity to schedule ad-hoc events during DebConf itself if we have space for them. Very promising late submissions may be considered for inclusion in the main conference. Note that ad-hoc events have a much lower chance of video archiving, and streaming, so if you want these services it's better to get your submissions in early. DebConf official events will be broadcast live on the Internet when possible, and videos of the talks will be published on the web along with the presentation slides and papers. For private communication regarding your talk, or for more general ideas, or questions about the event and talks, please mail us We hope to you see you and share some good times with you this year in Portland during DebConf14!

I m writing this on the train back from the ZuriHac Haskell Hackathon in Z rich, generously sponsored by Better and Google. My goal for this event was to attract new people to work on GHC, the Haskell compiler, so I announced a GHC bugsquashing project . I collected a few seemingly simple ticket that have a good effort/reward ratio for beginners and encouraged those who showed up to pick one to work on. Roughly six people started, and four actually worked on GHC on all three days. The biggest hurdle for them was to get GHC built for the first time, especially those using a Mac or Windows. They also had to learn to avoid recompilation of the whole compiler, which takes an annoying amount of time (~30 minutes for most people). But once such hurdles weren taken all of them managed to find their way around the source code to the place they need to touch and were able to produce a patch, some of which are already merged into GHC master. When I wasn t giving tips and hints I was working on various small tickets myself, but nothing of great impact. I very much hope that this event will pay off and one or two of the newcomers end up being regular contributors to GHC.

We took breaks from our respective projects to listen to interesting talks by Edward Kmett and Simon Marlow, and on Saturday evening we all went to the shores of the Zurisee and had a nice Barbecue. It was a good opportunity to get into contact with more of the attendees (the hacking itself was separated in multiple smaller office rooms) and I was happy to hear about people having read my recent Call Arity paper, and even found it valuable.

Thanks to the organizers and sponsors for this nice opportunity!

I must echo John Sullivan's post: GPG keysigning and government identification. John states some very important reasons for people everywhere to verify the identities of those parties they sign GPG keys with in a meaningful way, and that means, not just trusting government-issued IDs. As he says, It's not the Web of Amateur ID Checking. And I'll take the opportunity to expand, based on what some of us saw in Debian, on what this means. I know most people (even most people involved in Free Software development not everybody needs to join a globally-distributed, thousand-people-strong project such as Debian) are not that much into GPG, trust keyrings, or understand the value of a strong set of cross-signatures. I know many people have never been part of a key-signing party. I have been to several. And it was a very interesting experience. Fun, at the beginning at least, but quite tiring at the end. I was part of what could very well constitute the largest KSP ever in DebConf5 (Finland, 2005). Quite awe-inspiring We were over 200 people, all lined up with a printed list on one hand, our passport (or ID card for EU citizens) in the other. Actwally, we stood face to face, in a ribbon-like ring. And, after the basic explanation was given, it was time to check ID documents. And so it began. The rationale of this ring is that every person who signed up for the KSP would verify each of the others' identities. Were anything fishy to happen, somebody would surely raise a voice of alert. Of course, the interaction between every two people had to be quick More like a game than like a real check. "Hi, I'm #142 on the list. I checked, my ID is OK and my fingerprint is OK." "OK, I'm #35, I also printed the document and checked both my ID and my fingerprint are OK." The passport changes hands, the person in front of me takes the unique opportunity to look at a Mexican passport while I look at a Somewhere-y one. And all is fine and dandy. The first interactions do include some chatter while we grab up speed, so maybe a minute is spent Later on, we all get a bit tired, and things speed up a bit. But anyway, we were close to 200 people That means we surely spent over 120 minutes (2 full hours) checking ID documents. Of course, not all of the time under ideal lighting conditions. After two hours, nobody was checking anything anymore. But yes, as a group where we trust each other more than most social groups I have ever met, we did trust on others raising the alarm were anything fishy to happen. And we all finished happy and got home with a bucketload of signatures on. Yay! One year later, DebConf happened in Mexico. My friend Martin Krafft tested the system, perhaps cheerful and playful in his intent but the flaw in key signing parties such as the one I described he unveiled was huge: People join the KSP just because it's a social ritual, without putting any thought or judgement in it. And, by doing so, we ended up dilluting instead of strengthening our web of trust. Martin identified himself using an official-looking ID. According to his recount of the facts, he did start presenting a German ID and later switched to this other document. We could say it was a real ID from a fake country, or that it was a fake ID. It is up to each person to judge. But anyway, Martin brought his Transnational Republic ID document, and many tens of people agreed to sign his key based on it Or rather, based on it plus his outgoing, friendly personality. I did, at least, know perfectly well who he was, after knowing him for three years already. Many among us also did. Until he reached a very dilligent person, Manoj, that got disgusted by this experiment and loudly denounced it. Right, Manoj is known to have strong views, and using fake IDs is (or, at least, was) outside his definition of fair play. Some time after DebConf, a huge thread erupted questioning Martin's actions, as well as questioning what do we trust when we sign an identity document (a GPG key). So... We continued having traditional key signing parties for a couple of years, although more carefully and with more buzz regarding these issues. Until we finally decided to switch the protocol to a better one: One that ensures we do get some more talk and inter-personal recognition. We don't need everybody to cross-sign with everyone else A better trust comes from people chatting with each other and being able to actually pin-point who a person is, what do they do. And yes, at KSPs most people still require ID documents in order to cross-sign. Now... What do I think about this? First of all, if we have not ever talked for at least enough time for me to recognize you, don't be surprised: I won't sign your key or request you to sign mine (and note, I have quite a bad memory when it comes to faces and names). If it's the first conference (or social ocassion) we come together, I will most likely not look for key exchanges either. My personal way of verifying identities is by knowing the other person. So, no, I won't trust a government-issued ID. I know I will be signing some people based on something other than their name, but hey I know many people already who live pseudonymously, and if they choose for whatever reason to forgo their original name, their original name should not mean anything to me either. I know them by their pseudonym, and based on that pseudonym I will sign their identities. But... *sigh*, this post turned out quite long, and I'm not yet getting anywhere ;-) But what this means in the end is: We must stop and think what do we mean when we exchange signatures. We are not validating a person's worth. We are not validating that a government believes who they claim to be. We are validating we trust them to be identified with the (name,mail,affiliation) they are presenting us. And yes, our signature is much more than just a social rite It is a binding document. I don't know if a GPG signature is legally binding anywhere (I'm tempted to believe it is, as most jurisdictions do accept digital signatures, and the procedure is mathematically sound and criptographically strong), but it does have a high value for our project, and for many other projects in the Free Software world. So, wrapping up, I will also invite (just like John did) you to read the E-mail self-defense guide, published by the FSF in honor of today's Reset The Net effort.

ISC has issued an operational notification advising the use of the -fno-delete-null-pointer-checks flag when compiling current versions of BIND with GCC 4.9:

Beginning with GCC 4.9.0, code optimization in GCC now includes (by default) an optimization which is intended to eliminate unnecessary null pointer comparisons in compiled code. Unfortunately this optimization removes checks which are necessary in BIND and the demonstrated effect is to cause unpredictable assertion failures during execution of named, resulting in termination of the server process. Future versions of BIND will be modified so that the optimizer does not incorrectly remove necessary checks when building from source, and until those versions are available multiple immediate workarounds are available.

According to the GCC documentation, -fdelete-null-pointer-checks performs the following optimization, and is enabled by default even when compiling with -O0:

Assume that programs cannot safely dereference null pointers, and that no code or data element resides there. This enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that if a pointer is checked after it has already been dereferenced, it cannot be null.

This optimization dates back to 1999 but it recently became more aggressive in the GCC 4.9 release:

GCC might now optimize away the null pointer check in code like:

int copy (int* dest, int* src, size_t nbytes)  
  memmove (dest, src, nbytes);
  if (src != NULL)
    return *src;
  return 0;
 

The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash. The example above needs to be fixed to avoid the invalid memmove call, for example:

if (nbytes != 0)
  memmove (dest, src, nbytes);

It's interesting that the ISC operational advisory labels this an "incorrect" optimization. I wonder if this is a similar case to the Glibc optimization which exposed incorrect usage of memcpy() in many applications, including BIND. Fortunately, few users should be affected by this bug, since GCC 4.9 is fairly new. (The upcoming Fedora 21 release will probably be the first mainstream distribution to ship with GCC 4.9 as the default compiler.) Update: Debian bug #750760 filed.