This year, I was invited to attend BADCamp 2014. No, I know what you are thinking, but this is not a camp for bad web developers. In fact, its quite the opposite. Badcamp stands for Bay Area Drupal Camp. This is a four day, annual event held in the San Francisco Bay area. Basically, its a gathering of like-minded web developers discussing and learning about Drupal.
Having never been to a major Drupal event, I jumped on the opportunity to go. It was a fun trip full of learning, networking and maybe an after...Read More
I am very happy that we in the Norwegian Unix User group (NUUG), spearheaded by Marius Halden from NUUG and Matthew Somerville from MySociety, finally managed to upgrade the code base for the Norwegian version of FixMyStreet. This was the first major update since 2011. The refurbished FiksGataMi is already live, and seem to hold up the pressure. The press release and announcement went out this morning.
FixMyStreet is a web platform for allowing the citizens to easily report problems with public infrastructure to the responsible authorities. Think of it as a shared mail client with map support, allowing everyone to see what already was reported and comment on the reports in public.
All this excited talk of Drupal 8 has a lot of people dreaming of the day they get to start working with it. Some people get to build new sites from scratch all the time, but a lot of Drupal work out there is maintaining and upgrading existing sites. How will the Drupal 8 upgrade path work, and will it be as shiny as Drupal 8 itself? Well, upgrades will be radically different in Drupal 8, and I'd say it has all the shiny you could possibly want.
Here is a slightly overdue status on Jessie.
- We are not ready to set a date on a Jessie release yet. Even if we were, it would be unlikely that said date would be in January. Accordingly, it is safe to assume that the rapid automatic removals clause of the freeze policy will be applied before our release. If your package (or a package you use) depend on any package in this list, then they are at risk.
- It is unclear to me whether our CD1s are able to contain all the necessary packages. This was a major issue for Wheezy. So far I have only done some minor prodding here. However, I really want this item done soon as it can easily take a month or more to resolve this.
- While the release notes have been improved quite a bit, I am certain that there are more cases we can cover. As an example, I am looking for input on #773386.
- Despite the declining number of RC bugs, we still have some particular unhealthy ones left. E.g. #759530. There is also a view of some of the known unfixed Jessie blockers.
- We have had a number of issues with APT and dpkg (e.g. trigger cycles, APT breaking under puppet) that caused upgrade failures or were a severe regression. Most of these have been resolved now. There are some trigger issues left and I have pushed for a fixed dpkg at the cost of possibly removing some packages. See #772866 (among others).
The next timed change of the freeze policy will apply per January 5th. After that date, we will only accept RC bugs fixes. Which means it is final chance for translation updates.More on RC bugs
In absolute numbers, the RC bugs have declined quite well. We are below 150 now. We lost quite a bit of traction in December compared to November. However, November was an extremely efficient month. However, we still need the final push here.Debian installer release pending
Yesterday, we received a list of packages that needed to be unblocked for d-i with a remark that a release of d-i might follow. Based on what we have unblocked previously, it will likely contain some (improved?) UEFI support.Pending Debian 7.8 release
While not directly relevant to Jessie, we also got a pending Wheezy release planned for the 10th of January. The window for getting changes into the 7.8 release closes this weekend.Want to help?
- File bugs against release-notes (source at [RN source]) and installation-guide for missing or outdated documentation. Patches and drafts especially welcome.
- Fix RC bugs – especially the known Jessie blockers.
- Test upgrade paths and installation media. Although in both cases, you may want to wait a bit (for the new dpkg to migrate and for the new debian-installer release respectively).
- Consider offering your help to teams such as the CD team or debian-installer team.
For a recent customer setup of Debian/wheezy on a IBM x3630 M4 server we used my blog entry “State of the art Debian/wheezy deployments with GRUB and LVM/SW-RAID/Crypto” as a base. But this time we wanted to use (U)EFI instead of BIOS legacy boot.
As usual we went for installing via Grml and grml-debootstrap. We started by dd-ing the Grml ISO to a USB stick (‘dd grml64-full_2014.11.iso of=/dev/sdX bs=1M‘). The IBM server couldn’t boot from it though, as far as we could identify it seems to be related to a problem with the IBM server not being able to properly recognize USB sticks that are registering themselves as mass storage device instead of removable storage devices (you can check your device via the /sys/devices/…/removable setting). So we enabled Legacy Boot and USB Storage in the boot manager of the server to be able to boot Grml in BIOS/legacy mode from this specific USB stick.
To install the GRUB boot loader in (U)EFI mode you need to be able to execute ‘modprobe efivars’. But our system was booted via BIOS/legacy and in that mode the ‘modprobe efivars’ doesnt work. We could have used a different USB device for booting Grml in UEFI mode but because we are lazy sysadmins and wanted to save time we went for a different route instead:
First of all we write the Grml 64bit ISO (which is (U)EFI capable out-of-the-box, also when dd-ing it) to the local RAID disk (being /dev/sdb in this example):root@grml ~ # dd if=grml64-full_2014.11.iso of=/dev/sdb bs=1M
Now we should be able to boot in (U)EFI mode from the local RAID disk. To verify this before actually physically rebooting the system (and possibly getting into trouble) we can use qemu with OVMF:root@grml ~ # apt-get update root@grml ~ # apt-get install ovmf root@grml ~ # qemu-system-x86_64 -bios /usr/share/qemu/OVMF.fd -hda /dev/sdb
The Grml boot splash comes up as expected, perfect. Now we actually reboot the live system and boot the ISO from the local disks in (U)EFI mode. Then we put the running Grml live system into RAM to not use and block the local disks any longer since we want to install Debian there. This can be achieved not just by the toram boot option, but also by executing grml2ram on-demand as needed from user space:root@grml ~ # grml2ram
Now having the local disks available we verify that we’re running in (U)EFI mode by executing:root@grml ~ # modprobe efivars root@grml ~ # echo $? 0
Great, so we can install the system in (U)EFI mode now. Starting with the according partitioning (/dev/sda being the local RAID disk here):root@grml ~ # parted /dev/sda GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel gpt (parted) mkpart primary fat16 2048s 4095s (parted) name 1 "EFI System" (parted) mkpart primary 4096s 100% (parted) name 2 "Linux LVM" (parted) print Model: IBM ServeRAID M5110 (scsi) Disk /dev/sda: 9000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB fat16 EFI System 2 2097kB 9000GB 9000GB Linux LVM (parted) quit Information: You may need to update /etc/fstab.
Then setting up LVM with a logical volume for the root fs and installing Debian via grml-debootstrap on it:root@grml ~ # pvcreate /dev/sda2 Physical volume "/dev/sda2" successfully created root@grml ~ # vgcreate vg0 /dev/sda2 Volume group "vg0" successfully created root@grml ~ # lvcreate -n rootfs -L16G vg0 Logical volume "rootfs" created root@grml ~ # grml-debootstrap --target /dev/mapper/vg0-rootfs --password secret --hostname foobar --release wheezy [...]
Now finally set up the (U)EFI partition and properly install GRUB in (U)EFI mode:root@grml ~ # mkfs.fat -F 16 /dev/sda1 mkfs.fat 3.0.26 (2014-03-07) WARNING: Not enough clusters for a 16 bit FAT! The filesystem will be misinterpreted as having a 12 bit FAT without mount option "fat=16". root@grml ~ # mount /dev/mapper/vg0-rootfs /mnt root@grml ~ # grml-chroot /mnt /bin/bash Writing /etc/debian_chroot ... (foobar)root@grml:/# mkdir -p /boot/efi (foobar)root@grml:/# mount /dev/sda1 /boot/efi (foobar)root@grml:/# apt-get install grub-efi-amd64 [...] (foobar)root@grml:/# grub-install /dev/sda Timeout: 10 seconds BootOrder: 0003,0000,0001,0002,0004,0005 Boot0000* CD/DVD Rom Boot0001* Hard Disk 0 Boot0002* PXE Network Boot0004* USB Storage Boot0005* Legacy Only Boot0003* debian Installation finished. No error reported. (foobar)root@grml:/# ls /boot/efi/EFI/debian/ grubx64.efi (foobar)root@grml:/# update-grub [...] (foobar)root@grml:/# exit root@grml ~ # umount /mnt/boot/efi root@grml ~ # umount /mnt/ root@grml ~ # vgchange -an 0 logical volume(s) in volume group "vg0" now active
That’s it. Now rebooting the system should bring you to your Debian installation running in (U)EFI mode. You can verify this before actually rebooting into the system by using the qemu/OVMF trick from above once again.
Rather late but I guess that just confirms it’s really me, right? The signed text and IDs should be at http://mjr.towers.org.uk/transition-statement.txt
Thank you if you help me out here I’ll resign keys in a while.
Full list of changes:
- Add phone power ON/OFF function.
- Removed deprecated Python modules gammu.Data and gammu.Worker.
- Store network name and code in SMSD tables.
- Fixed build with recent clang compiler.
- Fixed several possible issues found by Coverity scan.
- Fixed possible crash on SMSD startup.
- Fixed decoding unicode SMS messages.
- Added identification for several Nokia phones.
- Fixed compilation issues on various platforms.
- SMSD now honors loglevel for all logging targets.
- SMSD can automatically hangup incoming calls.
- Correctly detect Network errors.
You can download it from http://wammu.eu/download/.
I will not make any promises for future releases (if there will be any) as the tool is not really in active development.
In wikis, redirects are special pages that silently take readers from the page they are visiting to another page. Although their presence is noted in tiny gray text (see the image below) most people use them all the time and never know they exist. Redirects exist to make linking between pages easier, they populate Wikipedia’s search autocomplete list, and are generally helpful in organizing information. In the English Wikipedia, redirects make up more than half of all article pages.
Over the years, I’ve spent some time contributing to to Redirects for Discussion (RfD). I think of RfD as like an ultra-low stakes version of Articles for Deletion where Wikipedians decide whether to delete or keep articles. If a redirect is deleted, viewers are taken to a search results page and almost nobody notices. That said, because redirects are almost never viewed directly, almost nobody notices if a redirect is kept either!
I’ve told people that if they want to understand the soul of a Wikipedian, they should spend time participating in RfD. When you understand why arguing about and working hard to come to consensus solutions for how Wikipedia should handle individual redirects is an enjoyable way to spend your spare time — where any outcome is invisible — you understand what it means to be a Wikipedian.
That said, wiki researchers rarely take redirects into account. For years, I’ve suspected that accounting for redirects was important for Wikipedia research and that several classes of findings were noisy or misleading because most people haven’t done so. As a result, I worked with my colleague Aaron Shaw at Northwestern earlier this year to build a longitudinal dataset of redirects that can capture the dynamic nature of redirects. Our work was published as a short paper at OpenSym several months ago.
It turns out, taking redirects into account correctly (especially if you are looking at activity over time) is tricky because redirects are stored as normal pages by MediaWiki except that they happen to start with special redirect text. Like other pages, redirects can be updated and changed over time are frequently are. As a result, taking redirects into account for any study that looks at activity over time requires looking at the text of every revision of every page.
Using our dataset, Aaron and I showed that the distribution of edits across pages in English Wikipedia (a relationships that is used in many research projects) looks pretty close to log normal when we remove redirects and very different when you don’t. After all, half of articles are really just redirects and, and because they are just redirects, these “articles” are almost never edited.
Another puzzling finding that’s been reported in a few places — and that I repeated myself several times — is that edits and views are surprisingly uncorrelated. I’ll write more about this later but the short version is that we found that a big chunk of this can, in fact, be explained by considering redirects.
Several times in the last few weeks, OSTraining students have asked us about maps in Drupal.
The students wanted to set up directories that would show Google maps for each location.
They also wanted to create larger maps that would display multiple locations at once.
We recommended that the students use the GMap module. However, although that module is powerful, it is poorly documented and can be confusing to use.
So, here's a beginners guide to the GMap module.
This is the time of year when there are lots of adverts shown on TV solicating donations for charities, which frequently end with the two words "thank you".
I've always felt there were too many charities in the world, and that it was hard to half-heartedly give money to one charity this month, one the next, and still another next year. On that basis I decided long ago to give my money solely to three charities. If I had money that was spare, or I felt generous that month, I would give it to one of "my" charities. Any other appeals I just ignored (with minor exceptions for one-off events like tsunamis, etc).
I won't claim credit for this idea, it came directly from my mom who does the same thing. I've given money to the same three charities for twenty years now. Maybe not thousands, but hopefully enough to be useful. Certainly more than I'd have given if my donation were split between more recipients.
Now I'm changing. As of next year only one charitable organization will get my pennies. The other two haven't done anything bad, wrong, or failed/succeeded (sadly), but it feels better for me to stick to a single recipient.
(Details shouldn't matter, but to answer the obvious question the charity I've kept is the RNLI.)
One way of working on reproducible builds is to look at packages which fail to build reproducibly on our continuous integration platform. Looking at the output of debbindiff often makes it possible to spot common problems.
When I started to work on reproducible builds for Debian a year and a half ago, I never thought it would be useful to find actual release critical bugs. Until I had a look at libical debbindiff output.
Can you understand the issue and how bad it is?
Answer is in bug #773916.
A bit of news on the development of OpenTAC – the Open Hardware Test Automation Controller. I’ve talked about this at the MiniDebConf 2014 in Cambridge. (Video available). The development is being tracked on the Vero-Apparatus wiki and as this is Open Hardware, the files are attached to the wiki (All files are CC BY-SA 4.0).
Andy completed the schematics at the start of November, allowing work to start on the routing. With routing completed, orders were placed for manufacture of the first PCBs on the 19th December 2014. Whilst waiting for the PCBs to arrive we’re working on the device tree database (my first real experience with creating a device tree) which will underpin the PDU and serial console services available to the user as well as the admin interface for control of the USB subsystems, fan control, power control and thermal monitoring. The first thing we need to do is create a data dictionary – a table to correlate software identifiers with the real hardware pins. We’ll then follow that through with a default device tree overlay that will leave all the associated I/O lines in a safe initial state.
Once we have some code, I’ll be pushing to a branch on GitHub. We’ve also got an internal git repo on vero-apparatus for OpenTAC files which we will add to in due course.
Image of the board as rendered prior to prototype production:
More to come once we have the hardware on the desk …
It seems that the 0.37 release was not that good as I hoped for, so here comes another bugfix release. So here comes Wammu 0.38.
The list of changes is not really huge:
- Compatibility with latest wxPython releases.
- Fixed corrupted appdata metadata.
- Fixed broken desktop file due to Chinese translation.
- Translation updates.
I will not make any promises for future releases (if there will be any) as the tool is not really in active development.
In this period, I have tackled several bugs and got them finally about to be merged in the codebase. Namely, they are:
#761121 allow symbolic links within same version, #761861 override detected language type. I also spent some time on making debsouces runnable on sor.debian.org.
But still there is some db related problem on it. I am not quite familiar with psql, and kinda at a loss as what to do. Zack said he would take it over and I shall focus on what really I likes. Cool.
For some non-code tasks, I have a detailed read on “machine-readable debian/copyright”. The other task is on “flask blueprint”. The idea of “flask blueprint”, as far as I am concerned, is sort of what apps are in django.
Zack has drafted a specification on debian/copyright which serves as the goal of copyright.debian.net. Combined with the above reading knowledge, and with the help of Flask expert matthieu, I will get my hands dirty in the comming weeks to create a fantastic new site, aka, copyright.d.n. Stay tuned.some thought
I did spend some time learning how to use git, and read quite a lot of materials. But, I shamely forgot most of them. So when I am frequently using git these days, I feel kinda incompetent and sometimes awkward. I am thinking now, maybe I shall stop overlearn some technology that I might never use. Only real usage and practice could help me get comfort with those tools. Overlearn something which I am not currently using and either won’t in the future might just be a waste of time.
and finally, I spent a great Christmas. Wish everyone happy, and merry Christmas!
A new version of rfoaas is now on CRAN. The rfoaas package provides an interface for R to the most excellent FOAAS service--which provides a modern, scalable and RESTful web service for the frequent need to tell someone to eff off.
This version aligns the rfoaas version number with the (at long last) updated upstream version number, and brings a change suggested by Richie Cotton to set the encoding of the returned object.
The Drupal 7 Draggable Captcha module is not like most captchas. A captcha is a way to catch or capture spam and prevent a bot from completing a form. This is one of the most widely used ways to prevent SPAM on a website. Drupal has many different types of captchas available and the Draggable Captcha is one of the more fun and easy ones.Tags: DrupalDrupal 7Drupal PlanetSpam Prevention
Conrad produced another minor release 4.600 of Armadillo. As before, I had created a GitHub-only pre-release(s) of his pre-release(s), and tested a pre-release as well as the actual release against the now over one hundred CRAN dependents of our RcppArmadillo package. The tests passed fine as usual with less than a handful of checks not passing, all for known cases -- and results are as always in the rcpp-logs repository.
Changes are summarized below based on the NEWS.Rd file.Changes in RcppArmadillo version 0.4.600.0 (2014-12-27)
Upgraded to Armadillo release Version 4.600 ("Off The Reservation")
added .head() and .tail() to submatrix views
faster matrix transposes within compound expressions
faster accu() and norm() when compiling with -O3 -ffast-math -march=native (gcc and clang)
workaround for a bug in GCC 4.4
Courtesy of CRANberries, there is also a diffstat report for the most recent release. 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.