The IPv6 patch set for netcfg (part of debian-installer) has landed in Debian unstable. In follow-up uploads I diverged from the Ubuntu patch set a little bit:

• I dropped the use of DUID-LL as the client identifier used by the DHCPv6 client. While basically a good idea, because it's predictable, it's also against the RFC to do that. We simply don't know if the network interface is permanently attached to the device. If the NIC that's used for DUID-LL generation is reused for installation in another box, the same identifier would be generated and stored on the machine. That's what DUID-LLT (the default in other software) avoids. As much as I loathe the replacement of the current MAC address-based scheme of DHCPv4 with DUID-LLT, it seems to be more correct to use that instead of DUID-LL, because that identifier is designed to be decoupled from the presence of the NIC. If you want predictable addressing, just enable SLAAC in your broadcast domain and use the EUI-64 address, which already contains the current MAC address.
• If SLAAC is used, netcfg will activate IPv6 privacy extensions in the installed system by default. They can be turned off by editing /etc/network/interfaces post-installation. This will only affect outgoing traffic, incoming traffic can be addressed at the stable EUI-64 address. (We don't use a randomized interface identifier like Windows does.)

Thanks to Michael Tokarev's recent upload of busybox, we now also have a more featureful ping and ping6 in debian-installer's environment.

Known bugs:

• As far as I can see, the DUID generated in the debian-installer environment is not copied into the installed system. Given the low prevalence of stateful DHCPv6 for servers I don't consider this a blocker, though.
• If stateful DHCPv6 is requested by the router advertisement (other config flag being set), the DHCPv6 client will not time out and continuously retry to get an address.
• According to Debian bug #688273 preseeding of netcfg/use_autoconfig does not work correctly. netcfg/disable_dhcp needs to be re-added as a deprecated preseeding option and mapped onto the use_autoconfig value until somebody comes up with a better scheme.
• We should state in the installation guide that ftp.ipv6.debian.org and http.debian.net can both be used for IPv6-only installation. The installer does not show in the mirror list if a mirror is IPv6-capable.

If you could take another look at a current d-i daily, install a system with it and look if the installed system has a correct network configuration, that would still be appreciated. I also need somebody to test the GNU/kFreeBSD image. I fixed it up to build there but the result might be entirely wrong.

My sincere thanks go to Bernhard Schmidt and Karsten Merker, who successfully completed installations over IPv6 in various environments!

Wheezy is coming closer to the release, there though are still way too many release critical bugreports outstanding for it. Squeeze has already been released, but it has collected even more release critical bugreports than wheezy since. To be able to reduce these amounts I will be at the Linuxhotel in Essen at the weekend from 23rd to 25th of November, and it would be a great pleasure if I could convince you to join me in this effort. As readers of my blog might assume, my main aim will be those RC bugs affecting squeeze and I would be happy if some people interested to work on those could join me, I plan to give a quick quick explanation about the version tracking of the BTS and why we should care about stable too, but the event will definitely not be limited to squeeze RC bugs. Also, it will be a good chance to improve your key stats for the web of trust in case your GnuPG key hasn't got enough signatures yet or you want to transition to a stronger one. Please read the Community page of the Linuxhotel for what they offer for accommodation in case you want to use their lodging. Personally I'll go for the two-bed room with breakfast option, but you are of course free to bring your own sleeping bag and mat if you want to cut short on the expenses. In case of any questions, feel free to ask me right ahead. It would be great if we could help both our stable release and the next stable release during the weekend, and if you could join in! Please add yourself to the wiki page about the BSP.

/debian permanent link Comments: 0 Flattr this

* KDE Randa Meetings and make a donation! I know that my contributions to KDE is minimal at this stage, but hey I m doing my part this time for sure!

Remember when Linus Torvalds lambasted NVidia for not supporting their Optimus technology in their Linux drivers for half a decade and counting? Well, I went out and bought an AMD/ATi video card as mu upgrade. And you know what? Its Linux drivers are far, far worse than NVidia.
1. Most of the games I had working fine on NVidia, do not work on AMD. And those that do suffer far more visual corruption, synchronization bugs (like bottom 40% of the screen rendering half a second after the top 60%), strange visual artifacts (weird triangles popping out of everywhere) and crashes, lots of crashes.
2. There were crashes with NVidia too, but NVidia never managed to crash Compiz along with it or crash the whole X server or lock up the system so far that only SysRq works or even lock up the system so far that only powering it off manually works.
3. And then there is the configuration atrocity. Apparently AMD is too good to store its configuration in /etc/X11/xorg.conf. Or even to document the supported options there. Instead they have their own (also undocumented) configuration file in /etc/ati folder. And it is undocumented because it is a cryptic mess and the only supported way to change it is to use their tools aticonfig and amdccccle. The command line tool is almost reasonable, except it is also barely documented. For example, one of my screens somehow was always stared at 1920 1080@30Hz. There were 3 different ways to specify default resolution, but none of them used or saved the refresh rate. And when I changed it in the GUI tool the refresh rate did change, but it was never saved. Oh there nowhere is a save button. It just works , except when it doesn t. Like: both of my screens for some reason started with huge black borders around the screen, I finally narrowed it down to the GUI setting overscan which defaulted to 10%. Ok, so I change it, it works, but next time I reboot, the overscan is back! I had to find an undocumented invocation of the aticonfig that would change the default value to 0%. Why did this one setting not save? Oh and fun note the refresh rate of that second screen was correct on the login screen, but it then swiched back as I logged in. Fun, huh?
4. Even at basic desktop tasks fglrx if inferior to not only the free driver, but also to the nvidia driver even simple scrolling of a large folder in nautilus seems to tax the 200$ card to its limits the bottom row blinks into place almost half a second after I stop scrolling. Another example with NVidia when I switch my TV to the HDMI input from the card, the sound starts at the same moment as the picture, however with AMD the sound only decides to show up 10-15 seconds later. And sometime it does not show up at all, unless I start the AMD Control GUI tool and only then the sound shows up 15 seconds later (without doing anything in the GUI). It may be that one part of AMD is better than NVidia at talking to free driver developers, but another part is so much worse at actual technical work of writing a driver, it is not even funny. They are busy reinventing the bycicle of configuration and display management, while their core driver is just not good enough. TL/DR: Anyone wanna buy a HD 6850 cheaply off my hands? Crossposted to Google+ https://plus.google.com/u/0/107099528362923100900/posts/6PC7RFQpm8K P.S. I also noticed the color difference with NVidia there was no difference between colors on my LCD TV and my IPS monitor, but with AMD there is a huge difference, the TV color just got washed out. I guess there is no proper color calibration support in the AMD driver? Update: I have managed to return the HD 6850 to the shop where I got it from (thanks to a nice law requiring web shops to take stuff back within 14 days no questions asked) and got the new NVidia GeForce GTX 660 instead. I had to build an updated NVidia driver (304.48 from this post, just like here or here) but other than that it was smooth and painless and everything is working great again. Only even faster

I will be speaking at ELC-E in Barcelona this year, with a talk entitled regmap: The Power of Subsystems and Abstractions. I look forward to seeing some of you at the conference, perhaps even in the audience!

The Register covered a story on a UEFI-based attack on Windows 8. It's actually covering this technical writeup, which is a discussion of a proof of concept implementation of an attack on the Windows 8 kernel from the firmware environment. The first approach they describe is pretty straightforward, in that they simply patch the Windows bootloader directly. Since this is what's reading the kernel off disk and launching it, patching that code means you can modify the kernel in-place and run it with built-in privilege elevation exploits.

The second approach is a little more interesting, and is based on their observation that the UEFI ExitBootServices() function is called after the kernel is loaded but before it's executed. UEFI calls are simply function pointers, so if you can run code in the firmware environment it's trivial to simply replace the function pointer with one to code of your own which does whatever you want before calling the original code. This makes it pretty straightforward to add a hook that gets run when ExitBootServices() is called, finds the kernel, patches it and then continues on its way. Since the kernel is patched after it's been read, this gets around any kind of signature checking that the bootloader might carry out.

But both these cases have something in common: they rely on the ability to run arbitrary code in the firmware environment, and that's precisely the thing that UEFI Secure Boot prevents. A system with a correct implementation of Secure Boot isn't vulnerable to the described attacks, but it's fairly unsurprising that running UEFI without Secure Boot is vulnerable. UEFI on its own doesn't provide any additional security. You're as vulnerable to bootkits as you are with BIOS.

So this isn't really a story about a surprising vulnerability. It's a story about someone taking the logical step of implementing a bootkit on top of UEFI, which is what everyone should have been expecting all along. Computers that are configured to run arbitrary code will run arbitrary code, and if that arbitrary code happens to modify your kernel so your credit card details are automatically posted to pastebin, well, that's a plausible outcome.

comments

My current employer has some internal program that it allows employee to devote two days a year for volunteering work.
It doesn t matter what it is (work for hospice, planting trees, helping in some foundation) so I thought about devoting this time for the Debian project. Either fixing RC bugs or finally give my packages enough attention and take care of their updates. Anyway the employer needs the certificate that I took participation in such event.
So the question is if it is possible to get some official document/certificate that I devoted some time to work on Debian? Bureaucracy has to be fulfilled unfortunately.

http://code.google.com/p/android/issues/detail?id=5484

Such a basic/important app and such a stupid bug... 3 years and not fixed yet? Seriously? and people claim Android is ready for lambda users?

</rant>

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

---

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

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

Assets

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

Core teams

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

Legal and RC fun

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

Hardware

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

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

---

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

I just uploaded Debian Policy 3.9.4.0, which includes the implementation of the Technical Committee decision to make build-arch and build-indep mandatory targets and which significantly reworks the section on shared libraries. Nothing here is release-critical for wheezy, and uploads targeted for wheezy should not attempt to update packaging for a new version of Policy. I went into some more detail on debian-devel-announce. The version number probably should have been 3.10.0.0 given the build-arch and build-indep changes and the work on symbols files. Ah well. Here's the upgrading checklist:

2.4

New tasks archive section.

4.9

build-arch and build-indep are now mandatory targets in debian/rules.

5.6.26

New section documenting the Vcs-* fields, which are already in widespread use. Note the mechanism for specifying the Git branch used for packaging in the Vcs-Git field.

7.1

The deprecated relations < and > now must not be used.

7.8

New Built-Using field, which must be used to document the source packages for any binaries that are incorporated into this package at build time. This is used to ensure that the archive meets license requirements for providing source for all binaries.

8.6

Policy for dependencies between shared libraries and other packages has been largely rewritten to document the symbols system and more clearly document handling of shared library ABI changes. symbols files are now recommended over shlibs files in most situations. All maintainers of shared library packages should review the entirety of this section.

9.1.1

Packages must not assume the /run directory exists or is usable without a dependency on initscripts (>= 2.88dsf-13.3) until the stable release of Debian supports /run.

9.7

Packages including MIME configuration can now rely on triggers and do not need to call update-mime.

9.11

New section documenting general requirements for alternate init systems and specific requirements for integrating with upstart.

12.5

All copyright files must be encoded in UTF-8.

I ve spent the last few hours working on a tool to take snapshots of all the html files in a .deb using phantomjs. It works great, but renders text all funny on my machine. I ve got two builds going with slight tweaks to check for the issue, but some advice before I file a bug would be helpful. (or see the full size image) This will hopefully be integrated into debuild.me, or debexpo.

As announced in the Debian Project News of September more mirrors have recently joined Debian's mirrors network. Two more have been added since that issue of DPN was released, and about four more might be added any day now. Many thanks to those sponsoring them!

The mirrors redirector has also received some improvements, and around 2.5 million requests a week.
Among the improvements, users of teredo and 6to4 tunnels are now handled as IPv4 users. Not only it gives them access to a wider range of mirrors, but it also avoids the tunnel overhead.

Another improvement is the prompt detection of mirrors that drop architectures without prior notification. This is thanks to a new version of ftpsync, the standard and recommended tool to create Debian mirrors suitable for Debian's mirrors network.
As more mirror administrators upgrade to the newer version, or switch to it, http.debian.net and other tools become more reliable: they no longer need to perform some checks and hope the results mean the mirrors actually include the architectures they say they include.

In this regard, http.debian.net is an improvement over debian-installer's mirrors selection menu: not only it chooses a mirror that is close to the user and up to date, it also ensures the mirror provides the files for an architecture even after the installer image has been built. debian-installer's mirrors list is static and hard-coded into the installation media.

There's more to come, stay tuned.

Conrad released the bug-fix release 3.4.1 of Armadillo earlier today, and the corresponding RcppArmadillo package 0.3.4.1 is already on CRAN. No R level or interface changes were, the upstream changes are summarized below.

Changes in RcppArmadillo version 0.3.4.1 (2012-09-18)

• Upgraded to Armadillo release 3.4.1
  • workaround for a bug in the Mac OS X accelerate framework
  • fixes for handling empty sparse matrices
  • added documentation for saving & loading matrices in HDF5 format
  • faster dot() and cdot() for complex numbers

Courtesy of CRANberries, there is also a diffstat report for 0.3.4.1 relative to 0.3.4.0 As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

About two years ago, I wrote about moving to a Sandisk Sansa Fuze as my music player. I transitioned from a 40G, HDD-based iRiver to an 8G flash-based player, with an additional 32G supplied by a micro SD card, both running the rockbox open-source firmware. Of course, my music collection has grown over the last few years and so I needed to find another solution. That solution is another Sansa Fuze! This was actually my interim solution, this time with 4G internal capacity (didn't matter too much) with another 32G microsd and a rubber band. It turns out that managing four storage devices (two SDs and two embedded storages) is a complete nightmare. However, as luck would have it, I learned that the new, larger capacity SDXC cards can be made to work in some SD readers, including the Sansa Fuze. At around this time, my original player started to malfunction and so, another Sansa Fuze, again! It took three attempts to get a 64G microsd: the first was faulty or fake, the second never turned up. Third times a charm, and a third sansa fuze (to get 8G internal capacity) completes the story. For the sansa fuze, to get a 64G microsd to work, one needs to change the partition type to 0x0c (W95 FAT32 (LBA)) and reformat with FAT32. (Interestingly that's actually hard to do for Windows users, as Win 7 refuses to offer FAT32 for flash devices over 32G in capacity by default). I now have approximately 67.7G of storage on a single device and all my music in one place again (albeit two storage locations) which feels surprisingly good!

This especially goes to planet.debian.org: SORRY! My WordPress thought it is a great idea to deliver empty (no date, no link, no content) posts, randomly, and planet started to post everything as new as it took the feed. I still haven t reenabled all the plugins, but it runs stable for several hours now and I ll try not to break it again.

0 comment(s) this blog is flattr enabled

When Keith and I released a new version of AltOS, the open source firmware and software system associated with our Altus Metrum hobby rocket avionics systems last week, we forgot to mention one small but really neat new feature Keith spontaneously added a few months ago. When a rocket is on the rail waiting to launch, we now beep out the igniter continuity status over the radio link instead of just sending periodic audio beeps. This is particularly useful when flying TeleMini, which is just too small to include an on-board beeper. Previously, you had to check the ground station computer to see if the board powered up correctly and was ready to fly. Now all you need is an HT tuned to the right frequency, which is easy to have in your pocket or clipped on your belt while preparing a rocket for flight! Son Robert and I made heavy use of this last weekend flying at the Tripoli Colorado Fall Frenzy 2012 launch, where 4 of our 5 flights were in TeleMini-equipped rockets set up for apogee-only electronic recovery deployment with motor backup. I also found it really handy when setting up YikStik3 on the flight line at Airfest 18. It was hard to hear the altimeter beepers on the two TeleMetrum boards buried deep in the airframe, but they were loud and clear through the HT in my back pocket! Thanks, Keith! So much improvement in flight-line experience from so little code...

I just released PyGObject 3.3.92, for GNOME 3.5.92. There is nothing too exciting in this release; a couple of small bug fixes and a lot of new test cases. See the detailled list of changes below. Thanks to all contributors! Changes:

• release-news: Generate HTML changelog (Martin Pitt)
• [API add] Add ObjectInfo.get_abstract method (Simon Feltman) (#675581)
• Add deprecation warning when setting gpointers to anything other than int. (Simon Feltman) (#683599)
• test_properties: Test accessing a property from a superclass (Martin Pitt) (#684058)
• test_properties.py: Consistent test names (Martin Pitt)
• test_everything: Ensure TestSignals callback does get called (Martin Pitt)
• argument: Fix 64bit integer convertion from GValue (Nicolas Dufresne) (#683596)
• Add Simon Feltman as a project maintainer (Martin Pitt)
• test_signals.py: Drop global type variables (Martin Pitt)
• test_signals.py: Consistent test names (Martin Pitt)
• Add test cases for GValue signal arguments (Martin Pitt) (#683775)
• Add test for GValue signal return values (Martin Pitt) (#683596)
• Improve setting pointer fields/arguments to NULL using None (Simon Feltman) (#683150)
• Test gint64 C signal arguments and return values (Martin Pitt)
• Test in/out int64 GValue method arguments. (Martin Pitt) (#683596)
• Bump g-i dependency to 1.33.10 (Martin Pitt)
• Fix -uninstalled.pc.in file (Thibault Saunier) (#683379)

It's taken years to get here, but Mel finally got a series of patches into the kernel, including this one, which should prevent deadlocks of machines doing swap-over-NBD. This means that one of my longest-running wishlist items has finally been attended to. Mel, I owe you a beer. Update: Mel seems to think I don't owe him beer. Obviously he's wrong.

A few months ago, a collection of essays called Open Advice was released. It consists of the things that seasoned Free and Open Source developers wish they had known when they got started. The LWN book review is the best way to get a good feel for what it's about, but here are the notes I took while reading it:

• Write code first: a project doesn't exist before there is code for it.
• Listen to your initial users and prioritise their bugs / feature requests: they will tell you how to turn your pet project into something that others will want to use.
• Documentation is not a waste of time: at some point, someone will need to take over from you. You're not just coding for yourself.
• When you first come to a project, you can make valuable contributions to the project's on-ramping process and documentation (other developers can't see or have forgotten about this stuff).
• Many potential contributors think they're not good enough to contribute to your project: invite them to do a specific task personally.
• Validated backups give you the freedom to do what's needed.
• Writing a library is a good way to enable cross-project collaboration.
• For many newcomers, documentation is a gateway in the FOSS community.
• Real programmers virtues: laziness, patience and humility (politeness is critical).
• Documentation can occur in sprints.
• Professional writers should focus on teaching and mentoring, not writing documentation.
• Watching real users use your software is the best way to improve its usability.
• The best designs evolve slowly and get refactored over time using well-known patterns.
• Outsiders can inject different viewpoints into the discussion, particularly around prioritization.
• Community managers should be good listeners and learn from their peers.
• Have a willingness to accept that you can and will be wrong sometimes.
• Sometimes you need to walk away from a project or argument, allow a day for things to settle down and for you to get a chance to breathe.
• Do not ask people what they think, state that you will do something by a date pending any objections from others.
• Creating a community team should never assume that people will stay fully committed the whole time. They will be in for a while then disappear for longer periods and then come back.

If you want to add some rules to your Apache based on the clients country, mod_geoip is perfect for it. Installation On Squeeze following is enough: # apt-get install libapache2-mod-geoip geoip-database/squeeze-backports Note that you should use the geoip-database version from squeeze-backports to have got the most up to date database version, I am updating it every month. Configuration You can add the rules to your VirtualHost, Directory, Location directives and also to your apache2.conf ( serverwide ). So you are flexible with where to use it. Blocking countries On some servers I have got more than 90 percent of spam requests only from three countries, so I blocked them with: <DirectoryMatch ^/var/www/.*/html >
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE UA BlockCountry
Deny from env=BlockCountry
</DirectoryMatch> Allow only specific countries In the other way you also can allow specific countries to have got access to your website, this also may be a good idea for extranets, where you know from where your customers are: <Directory /var/www/my.site.com/html/login >
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry
SetEnvIf GEOIP_COUNTRY_CODE CH AllowCountry
Deny from all
Allow from env=AllowCountry
</Directory> Very easy! Rewrite Rules You can also use it for mod_rewrite. Within a project, customers from CN and TW should be redirected to the chinese page: RewriteCond % ENV:GEOIP_COUNTRY_CODE ^(CN TW)$
RewriteRule ^(.*)$ http://some.example.cn/site.php [L] mod_geoip with proxy frontends Normaly mod_geoip works behinds load balancers and proxy servers, since it also take care of the HTTP_X_FORWARDED_FOR header. But with haproxy it looks problematic, since it does not add the HTTP_X_FORWARDED_FOR header to KeepAlive d requests :( Disabling KeepAlive is a bad idea on this cluster, so we decided to also use php5-geoip in our application, so everything is working nice now.. What mod_geoip is NOT is mod_geoip helps you to block/allow specific countries, but it does not protect you from them.
Also keep in mind that the database is only ~ 99,8% accurate, so you may have got false positives/negatives. If you only allow german users, a german IP could be listed as russian.
This is much more problematic with mobile/satellite connections and surely you can also not access your page, if you are on vacation in another country. ;)