Search Results: "ag"

22 December 2015

Steve Kemp: Finding and reporting trivial security issues

This week I'll be mostly doing drive-by bug-reporting. As with last year we start by using the Debian Code Search, to look for obviously broken patterns such as "system.>./tmp/.*" Once we find a fun match we examine the code and then report the bugs we find. Today that was stalin which runs some fantastic things on startup:
(system "uname -m >/tmp/QobiScheme.tmp")
(system "rm -f /tmp/QobiScheme.tmp"))
We can exploit this like so:
$ ln -s /home/steve/HACK /tmp/QobiScheme.tmp
$ ls -l /home/steve/HACK
ls: cannot access /home/steve/HACK: No such file or directory
Now we run the script:
$ cd /tmp/stalin-0.11/benchmarks
$ ./make-hello
And we see this:
$ ls -l /home/steve/HACK
-rw-r--r-- 1 steve steve 6 Dec 22 08:30 /home/steve/HACK
For future reference the lsat looks horrifically bad - it writes multiple times to /tmp/lsat1.lsat and although it tries to detect races I'm not convinced. Something to look at in the future.

Michal Čihař: Weekly phpMyAdmin contributions

Again one week has passed and there has been some progress on phpMyAdmin. This week the focus was on code cleanup and issue fixing. I've identified several pieces of dead code and removed that from our code base (the biggest removal being no longer used PMA_String class). The codebase is quite old and sometimes it's not easy to identify code which is not really being used, as it still might be referenced from some locations, but without actually invoking it. On the issue fixing side, I'm really happy from improving user experience with fields marked as binary - so far phpMyAdmin has displayed them as hexadecimal dump in all cases. Now it will display them as text as long as the content is valid utf-8. Bugs fixed: PS: I will most likely skip report next week due to Christmas.

Filed under: English phpMyAdmin 0 comments

Dmitry Shachnev: ReText 5.3 released

On Sunday I have released ReText 5.3, and here finally comes the official announcement. Highlights in this release are: Also, a week before ReText 5.3 a new version of PyMarkups was released, bringing enhanced support for the Textile markup. You can now edit Textile files in ReText too, provided that python-textile module for Python 3 is installed. As usual, you can get the latest release from PyPI or from the Debian/Ubuntu repositories. Please report any bugs you find to our issue tracker.

21 December 2015

Matthew Garrett: GPL enforcement is a social good

The Software Freedom Conservancy is currently running a fundraising program in an attempt to raise enough money to continue funding GPL compliance work. If they don't gain enough supporters, the majority of their compliance work will cease. And, since SFC are one of the only groups currently actively involved in performing GPL compliance work, that basically means that there will be nobody working to ensure that users have the rights that copyright holders chose to give them.

Why does this matter? More people are using GPLed software than at any point in history. Hundreds of millions of Android devices were sold this year, all including GPLed code. An unknowably vast number of IoT devices run Linux. Cameras, Blu Ray players, TVs, light switches, coffee machines. Software running in places that we would never have previously imagined. And much of it abandoned immediately after shipping, gently rotting, exposing an increasingly large number of widely known security vulnerabilities to an increasingly hostile internet. Devices that become useless because of protocol updates. Toys that have a "Guaranteed to work until" date, and then suddenly Barbie goes dead and you're forced to have an unexpected conversation about API mortality with your 5-year old child.

We can't fix all of these things. Many of these devices have important functionality locked inside proprietary components, released under licenses that grant no permission for people to examine or improve them. But there are many that we can. Millions of devices are running modern and secure versions of Android despite being abandoned by their manufacturers, purely because the vendor released appropriate source code and a community grew up to maintain it. But this can only happen when the vendor plays by the rules.

Vendors who don't release their code remove that freedom from their users, and the weapons users have to fight against that are limited. Most users hold no copyright over the software in the device and are unable to take direct action themselves. A vendor's failure to comply dooms them to having to choose between buying a new device in 12 months or no longer receiving security updates. When yet more examples of vendor-supplied malware are discovered, it's more difficult to produce new builds without them. The utility of the devices that the user purchased is curtailed significantly.

The Software Freedom Conservancy is one of the only organisations actively fighting against this, and if they're forced to give up their enforcement work the pressure on vendors to comply with the GPL will be reduced even further. If we want users to control their devices, to be able to obtain security updates even after the vendor has given up, we need to keep that pressure up. Supporting the SFC's work has a real impact on the security of the internet and people's lives. Please consider giving them money.

comment count unavailable comments

Diego Escalante Urrelo: Stallman on happiness and perseverance

What does happiness signify to you, I asked him, if it isn t based on wealth and comfort? Happiness for me is a combination of feeling good about myself and having love, he said. And to feel good about myself, I have to do things that convince me I deserve it. ( ) The point is, even though it s sad to see people being foolish, there s no use giving up. Nothing good can come of giving up. That just means you lose completely, right away.
Richard Stallman on the 30th anniversary of the GNU Manifesto. It s amazing to think that a broken printer lead to the creation of the Free Software movement which, many years later, would give me a professional career, an education, and incredible friends around the world. Which reminds me I still keep the sticker Richard personally handed at the end of his first talk in Per , back in August 2003:
DSCF9847-web

GNU & Linux: the dynamic duo.

Bonus: Enjoy The Free Software Song by The GNU/Stallmans.

Jonas Smedegaard: SOME DESCRIPTIVE TITLE

# Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2015-12-21 15:00+0100\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Title # #, no-wrap msgid "I want your input" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text msgid "You want to share an opinion with me, or raise a question?" msgstr "" #. type: Plain text msgid "Great, please do: I love exchanging opinions and ideas." msgstr "" #. type: Plain text msgid "" "You can [contact me discretely][]. Please consider, however, to speak in " "public instead, allowing others to benefit from our exchange." msgstr "" #. type: Plain text msgid "" "Don't worry if it is interesting to others - the World is big and someone " "somewhere always cares!" msgstr "" #. type: Plain text msgid "[contact me discretely]:" msgstr "" #. type: Title ## #, no-wrap msgid "Email - encourages reflection" msgstr "" #. type: Plain text msgid "Post to a public mailinglist." msgstr "" #. type: Plain text msgid "" "If uncertain that I am subscribed to the list, or if you want my special " "attention (but think twice if that's really needed!), add my [private " "mail](mailto:dr@jones.dk) as cc." msgstr "" #. type: Title ## #, no-wrap msgid "Chat - more casual" msgstr "" #. type: Plain text msgid "" "I am also [reachable via chat][]. Chat is nice for shorter " "questions/comments, and when you need to discuss what you want to say at " "all." msgstr "" #. type: Plain text msgid "[reachable via chat]:" msgstr "" #. type: Title ## #, no-wrap msgid "Blog - best for reuse" msgstr ""

Jonas Smedegaard: SOME DESCRIPTIVE TITLE

# Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2015-12-21 15:00+0100\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Title # #, no-wrap msgid "issues handling issues" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text msgid "" "I get lots of emails, some of which are "issues": Friends, colleagues, " "clients and machines tell me about stuff that is broken. and ask for new " "features." msgstr "" #. type: Plain text msgid "I currently handle issues somewhat like this:" msgstr "" #. type: Plain text #, no-wrap msgid "[[!graph src="""\n" msgstr "" #. type: Plain text #, no-wrap msgid "" "rankdir=LR\n" "inbox [label="incoming mails"]\n" "todobox [label="mail threads about issues"]\n" "issueboxes [label="issue-mails grouped by project" style=dotted]\n" "solve [label="fix issue"]\n" "archivebox [label="archived mails"]\n" "inbox -> todobox\n" "todobox -> issueboxes [style=dotted]\n" "todobox -> solve\n" "todobox -> archivebox\n" msgstr "" #. type: Plain text msgid "FIXME: Describe graf in steps." msgstr "" #. type: Plain text msgid "" "The idea was to organize issues in queues per project, but organizing emails " "requires understanding them, and that takes time: Too often I end up " "skipping that task, leading to weak overview of pending issues." msgstr "" #. type: Plain text msgid "Here's" msgstr "" #. type: Plain text #, no-wrap msgid "" "rankdir=LR\n" "inbox [label="incoming mails"]\n" "todobox [label="mail threads about issues"]\n" "new [label="unprocessed issues"]\n" "open [label="open issues"]\n" "solve [label="fix issue"]\n" "inbox -> todobox -> archivebox\n" "todobox -> new -> open\n" "open -> solve\n" "open -> done\n" msgstr ""

David Bremner: Bootable Debian USB

Umm. Somehow I thought this would be easier than learning about live-build. Probably I was wrong. There are probably many better tutorials on the web. Two useful observations: zeroing the key can eliminate mysterious grub errors, and systemd-nspawn is pretty handy. One thing that should have been obvious, but wasn't to me is that it's easier to install grub onto a device outside of any container. Find device
 $ dmesg
Count sectors
 # fdisk -l /dev/sdx
Assume that every command after here is dangerous. Zero it out. This is overkill for a fresh key, but fixed a problem with reusing a stick that had a previous live distro installed on it.
 # dd if=/dev/zero of=/dev/sdx bs=1048576 count=$sectors
Make file system. There are lots of options. I eventually used parted
 # parted
 (parted) mklabel msdos
 (parted) mkpart primary ext2 1 -1
 (parted) set 1 boot on
 (parted) quit
Make a file system
 # mkfs.ext2 /dev/sdx1
 # mount /dev/sdx1 /mnt
Install the base system
 # debootstrap --variant=minbase jessie /mnt http://httpredir.debian.org/debian/
Install grub (no chroot needed)
 # grub-install --boot-directory /mnt/boot /dev/sdx1
Set a root password
 # chroot /mnt
 # passwd root
 # exit
create up fstab
# blkid -p /dev/sdc1   cut -f2 -d' ' > /mnt/etc/fstab
Now edit to fix syntax, tell ext2, etc... Now switch to system-nspawn, to avoid boring bind mounting, etc..
# systemd-nspawn -b -D /mnt
login to the container, install linux-base, linux-image-amd64, grub-pc EDIT: fixed block size of dd, based on suggestion of tg.

Keith Packard: TeleLaunchTwo

TeleLaunchTwo A Smaller Wireless Launch Controller I've built a wireless launch control system for NAR and OROC. Those are both complex systems with a single controller capable of running hundreds of pads. And, it's also complicated to build, with each board hand-made by elves in our Portland facility (aka, my office). A bunch of people have asked for something simpler, but using the same AES-secured two-way wireless communications link, so I decided to just build something and see if we couldn't eventually come up with something useful. I think if there's enough interest, I can get some boards built for reasonable money. Here's a picture of the system; you can see the LCO end in a box behind the pad end sitting on the bench. Radio Link Each end has a 35mW 70cm digital transceiver (so, they run in the 440MHz amateur band). These run at 19200 baud with fancy forward error correction and AES security to keep the link from accidentally (or maliciously) firing a rocket at the wrong time. Using a bi-directional link, we also get igniter continuity and remote arming information at the LCO end. The LCO Box In the LCO box, there's a lipo battery to run the device, so it can be completely stand-alone. It has three switches and a button -- an arming switch for each of two channels, a power switch and a firing button. The lipo can be charged by opening up the box and plugging it into a USB port. The Pad Box The pad box will have some cable glands for the battery and each firing circuit. On top, it will have two switches, a power switch and an arming switch. The board has two high-power FETs to drive the igniters. That should be more reliable than using a relay, while also allowing the board to tolerate a wider range of voltages -- the pad box can run on anything from 12V to 24V. The Box Unlike the OROC and NAR systems, these boards are both designed to fit inside a specific box, the Hammond 1554E, and use the mounting standoffs provided. This box is rated at NEMA 4X, which means it's fairly weather proof. Of course, I have to cut holes in the box, but I found some NEMA 4X switches, will use cable glands for the pad box wiring and can use silicone around the BNC connector. The result should be pretty robust. I also found a pretty solid-seeming BNC connector, which hooks around the edge of the board and also clips on to the board. Safety Features. There's an arming switch on both ends of the link, and you can't fire a rocket without having both ends armed. That provides an extra measure of safety while working near the pad. The pad switch is a physical interlock between the power supply and the igniters, so even if the software is hacked or broken, disarming the box means the igniters won't fire. The LCO box beeps constantly when either arming switch is selected, giving you feedback that the system is ready to fire. And you can see on any LED whether the pad box is also armed.

20 December 2015

Lunar: Reproducible builds: week 34 in Stretch cycle

What happened in the reproducible builds effort between December 13th to December 19th: Infrastructure Niels Thykier started implementing support for .buildinfo files in dak. A very preliminary commit was made by Ansgar Burchardt to prevent .buildinfo files from being removed from the upload queue. Toolchain fixes Mattia Rizzolo rebased our experimental debhelper with the changes from the latest upload. New fixes have been merged by OCaml upstream. Packages fixed The following 39 packages have become reproducible due to changes in their build dependencies: apache-mime4j, avahi-sharp, blam, bless, cecil-flowanalysis, cecil, coco-cs, cowbell, cppformat, dbus-sharp-glib, dbus-sharp, gdcm, gnome-keyring-sharp, gudev-sharp-1.0, jackson-annotations, jackson-core, jboss-classfilewriter, jboss-jdeparser2, jetty8, json-spirit, lat, leveldb-sharp, libdecentxml-java, libjavaewah-java, libkarma, mono.reflection, monobristol, nuget, pinta, snakeyaml, taglib-sharp, tangerine, themonospot, tomboy-latex, widemargin, wordpress, xsddiagram, xsp, zeitgeist-sharp. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues, but not all of them: Patches submitted which have not made their way to the archive yet: reproducible.debian.net Packages in experimental are now tested on armhf. (h01ger) Arch Linux packages in the multilib and community repositories (4,000 more source packages) are also being tested. All of these test results are better analyzed and nicely displayed together with each package. (h01ger) For Fedora, build jobs can now run in parallel. Two are currently running, now testing reproducibility of 785 source packages from Fedora 23. mock/1.2.3-1.1 has been uploaded to experimental to better build RPMs. (h01ger) Work has started on having automatic build node pools to maximize use of armhf build nodes. (Vagrant Cascadian) diffoscope development Version 43 has been released on December 15th. It has been dubbed as epic! as it contains many contributions that were written around the summit in Athens. Baptiste Daroussin found that running diffoscope on some Tar archives could overwrite arbitrary files. This has been fixed by using libarchive instead of Python internal Tar library and adding a sanity check for destination paths. In any cases, until proper sandboxing is implemented, don't run diffosope on unstrusted inputs outside an isolated, throw-away system. Mike Hommey identified that the CBFS comparator would needlessly waste time scanning big files. It will now not consider any files bigger than 24 MiB 8 MiB more than the largest ROM created by coreboot at this time. An encoding issue related to Zip files has also been fixed. (Lunar) New comparators have been added: Android dex files (Reiner Herrmann), filesystem images using libguestfs (Reiner Herrmann), icons and JPEG images using libcaca (Chris Lamb), and OS X binaries (Clemens Lang). The comparator for Free Pascal Compilation Unit will now only be used when the unit version matches the compiler one. (Levente Polyak) A new multi-file HTML output with on-demand loading of long diffs is available through the --html-dir option. On-demand loading requires jQuery which path can be specified through the --jquery option. The diffs can also be simply browsed for non-JavaScript users or when jQuery is not available. (Joachim Breitner) Example of on-demand loading in diffosope Portability toward other systems has been improved: old versions of GNU diff are now supported (Mike McQuaid), suggestion of the appropriate locale is now the more generic en_US.UTF-8 (Ed Maste), the --list-tools option can now support multiple systems (Mattia Rizzolo, Levente Polyak, Lunar). Many internal changes and code clean-ups have been made, paving the way for parallel processing. (Lunar) Version 44 was released on December 18th fixing an issue affecting .deb lacking a md5sums file introduced in a previous refactoring (Lunar). Support has been added for Mozilla optimized Zip files. (Mike Hommey). The HTML output has been optimized in size (Mike Hommey, Esa Peuha, Lunar), speed (Lunar), and will now properly number lines (Mike Hommey). A message will always be displayed when lines are ignored at the end of a diff (Lunar). For portability and consistency, Python os.walk() function is now used instead of find to perform directory listing. (Lunar) Documentation update Package reviews 143 reviews have been removed, 69 added and 22 updated in the previous week. Chris Lamb reported 12 new FTBFS issues. News issues identified this week: random_order_in_init_py_generated_by_python-genpy, timestamps_in_copyright_added_by_perl_dist_zilla, random_contents_in_dat_files_generated_by_chasen-dictutils_makemat, timestamps_in_documentation_generated_by_pandoc. Chris West did some improvements on the scripts used to manage notes in the misc repository. Misc. Accounts of the reproducible builds summit in Athens were written by Thomas Klausner from NetBSD and Hans-Christoph Steiner from The Guardian Project. Some openSUSE developers are working on a hackweek on reproducible builds which was discussed on the opensuse-packaging mailing-list.

Iain R. Learmonth: A Week of Debian

For the last week I have been stuck in England. For the vast majority of that time, I've had nothing to do except work on Debian and this blog post documents some of the things I worked on. Obviously spending a whole week on Debian, there's going to be some packaging involved. The following packages got new versions in unstable this last week: Packaging updates were one of the simpler tasks tackled this week though. I spent a lot of time this week on Debian Live along with others in the #debian-live IRC channel. Over the last week we achieved a number of things, possibly the most important being that all the generic live support packages (i.e. live-boot, live-config and live-tools) have now been converted into native packages, have their VCS repositories hosted on Alioth and have seen a good number of patches merged from the BTS and from the old patch system. All future patches will be managed via the BTS for Debian Live, as with other Debian projects. We've also put effort into getting documentation online again now that the live.debian.net server has been turned off and we now have the live-build documentation and the live-wrapper documentation hosted on the project's Alioth webspace. The live-wrapper user documentation was mostly written this week so may not be amazing. On the smaller task list for Debian Live, the KGB bots are now present in the channel and reporting on git commits, a number of the more popular URLs from live.debian.net are now being redirected to their new locations (although we've had to recover these URLs from web.archive.org, the list of redirections is certainly not complete) and we've made updates to the wiki pages about how to contribute to the project. Unfortunately, no one has stepped forwards as a new lead for live-build and so this package has been orphaned. This does not necessarily mean that the package will be removed from Debian any time soon, just that it does not currently have a maintainer. If you're interested in taking over maintainence of live-build, see #808048. For testing the core live support packages, new live images for stretch have been built using live-wrapper and are available here. There are known issues with the syslinux configuration and these are not isohybrid images. My other major project this week has been my efforts to form a Debian Metadata team. The Debian Metadata team would produce the frameworks and run the services that make data about Debian available in a number of formats to make the data as accessible as possible and to encourage its use both within Debian and in external projects. Currently this includes two experimental services: rdf.debian.net and map.debian.net. We're don't plan to duplicate any of the work done by UDD, but make the data aggregated in UDD more accessible to users and developers. This means publishing that data in JSON/JSONP, KML, RDF, iCalendar and any other format that makes sense. There may be instances where it makes sense to augment the published data with live data, for example mirror availability should probably be live and not just a recent snapshot. If you're interested in participating in the Debian Metadata team, you can register your interested on bug #808049. This is not a complete summary of all my activities over the last week, but for those interested, it should give you an idea of what I've been up to. Finally, for those of you that have been waiting for my write-up on the airgapped GnuPG master key, I decided in the end that my blog was not the right place for this. You can find the guide in two parts: key generation and key export to the YubiKey. I've tried to keep these guides as generic as possible while still being as useful as possible. While writing these up on the wiki, I've also created pages for OpenPGP and GnuPG and I've almost entirely rewritten the DebianKeyring wiki page. I discovered this awesome guide to OpenPGP concepts which I would recommend to anyone that is new to OpenPGP.

Iustin Pop: Nikkor 200-500mm f5.6E ED VR tests

So, lately I've been on a telephoto lens learning curve; after the 300mm prime, I said to test a zoom lens. As I found the prime reasonably easy to adapt to (compared to shorter focal length lenses), I thought that a zoom (heavier, bigger) will be the same. Oh, I was wrong. My keeper rate for the first outdoors test was quite bad around 50% only, which (when talking only about focus/sharpness) is much below my standards. I started easy; some close or medium range shots, nothing special: Usual flower picture Lonely snag But then, moving to further distances, things became less straightforward. Shooting two pictures each time meant that usually one of them was sharp, but the other not. I got really confused at this step; the shutter speed was 1/2000s and I also had VR on; either VR was unneeded (i.e. contributing blur instead of helping) or something else was going on. After much head scratching, I think it's a combination of the following factors: So, for such style of shooting, I need to train more both photographic technique and arm strength at the gym In the meantime, it is possible to get such shots reasonably sharp, for example this picture of the (start of the) Alps taken from what is technically still Z rich city: The Alps  viewed from Z rich! I'm happy with the detail (at this distance), however I was not able to correct the colour due to the haze between me and the mountains; note that the trees on the bottom of the distance were not near me, but on the next or after-next hill. This picture confirms that with more practice things will get better. Coming back to shorter distances, and shorter focal lengths, things are looking better. We were passing somewhat near some people playing with RC-controlled planes not near enough to hear them, but near enough to see the plane quickly flying. Switched camera quickly to AF-C and Dynamic-21 focus, and - to my surprise - I was able to capture four good pictures, two so-so and four more clearly out of focus. But, for such a heavy length, hand-held and on the short notice, I was happy; the first picture is one of the so-so ones, but I kept it as I like the way the propeller is seen. All pictures at 290mm plus some cropping, 1/1250s, ISO between 900 and 1800, f/5.6 (i.e wide open): RC plane: continous focus tests RC plane #2 RC plane #3: good results! RC plane #4 RC plane #5: landing? From this exercise, the conclusion is that the lens is OK-ish for tracking, although the not-so good keeper rate tells me that I need to be careful; I'll have to see how a subject moving not left-right, but instead approaching or moving away from the camera would be tracked. But enough pictures of small planes. At 500mm, but still somewhat close, trees: Trees @ 500mm At this step I'm starting to wonder if stopping down a bit would help with the sharpness; I'll have to test that in the future. Walking some more, finally a bird in flight; one of the hopes when I took the camera/lens out was that I'll see some birds, but this was the first. 500mm, heavily cropped, but quite good result for myself (same autofocus settings as before): Bird in flight @ 500mm Bird in flight: difficult light The only problem here is, as always with crows (I think these are crows), is the black bird against the light-blue sky (not even strong blue), which means the picture has a high dynamic range; recovering the shadows on the bird is difficult. But in any case, it's clear the lens can deliver, if the photographer is good. Next, a helicopter was gracious enough to pass by (pretty close): Helicopter: close shot Two minutes later, it was quite far, but since it was going in the direction of the Alps, it gave the opportunity for a nice shot: Helicopter: flying towards the Alps This picture is less sharp, but still I like it due to composition; not successful on small screens though, only if you see it full screen. Light is very difficult though and about 10 seconds earlier would have been even better (more separation between the helicopter and the mountain). And since we're talking about planes, let's see a plane at 500m, directly overhead, and quite high: High-flying plane This picture (@500mm, cropped, 1/2000s) has the most detail of a plane flying high enough to have trails (not sure how to estimate, but at least 5km, maybe more around 7-8 I'd say) that I ever took. So yes, the lens can deliver, but it's not easy. This shot, being shot more or less straight up, had the least distance through low-altitude atmosphere, so it has less problems compared to the mountains pictures. It's still not really sharp (lens wide open), but the amount of detail I'm sold :) And to finish on a more close note: Hunting!! A long focal length lens allows one to get "close" without getting close, which means animals are not disturbed. The first picture with the cat (not shown) had the cat less alert; ears not fully up, although eyes were still seeking; this picture shows it fully alert and concentrated, like it was a wild cat hunting for its survival, and not a city cat, out just for fun. So, summary: All the best to everybody for the coming holidays, and thanks for reading.

Lars Wirzenius: FUUG grant for Obnam development: what happened then

In September, The FUUG Foundation gave me a grant to buy some hardware for Obnam development. I used this money to buy a new desktop-ish machine, see below for details. It's sat in a corner, and I use it as a server: it's not normally connected to a monitor or keyboard. It runs Obnam benchmarks. Before this, I ran Obnam benchmarks and experiments on my laptop, or on BigV virtual servers donated by Bytemark. The hardware The parts: Not to brag, but it's a nice machine. Much more power than my 2012 era laptop. The SSD is the system drive, the HDDs are for running Obnam benchmarks on. The HDDs are not RAIDed. Each drive is a PV for LVM2. All the data on those drives is scratch data: it's not valuable, and I do not care if it is lost. In fact, most of the data gets created and deleted during a benchmark run, and usually the disks are empty. The SSD contains the host operating system, and the virtual disks for all the virtual machines. I assembled the machine myself, with the help of a friend, and installed Debian jessie on it. The Debian installation is pretty bare bones, just enough to run and manage a bunch of virtual machines using libvirt and ansible. All the actual work, including benchmarks, are run in virtual machines. The benchmarks The benchmarks are run by a kludge, called obbench, and the results are published at http://benchmark.obnam.org/. Here's a snapshot of the results so far:
date many files one big file
2015-09-28 2165.0 1381.9
2015-12-06 1461.6 384.0
In a bit over two months, I've made some significant progress, I think. The two benchmarks that I currently run are: These are two extreme cases of what a backup needs to deal with: either the file metadata, or its content. They incur different costs for a backup program. Thus, two benchmarks. In both cases, the benchmark consists of an initial backup, a restore, and a second backup, without changes to the live data. The second backup is an extreme case of what backups usually do: most data usually doesn't change, so keeping that in mind for optimisation is important. The above benchmarks are synthetic: they use data that's generated by a program (genbackupdata), so that they can be reproduced. Synthetic benchmarks are useful, especially for looking at particular aspects of a program's operation for optimisation. However, they do not necessarily reflect how a program behaves in actual use. I also run, by hand, experiments with real data. I have a snapshot of our home file server and my laptop on the benchmark machine. The snapshots are static, and do not get updated. I experiment by running Obnam backups manually, the initial full backup and a no-change incremental one. In early October, I couldn't finish the initial full backups. They took too long, more than a week. Now I can finish them in about a day. This remarkable change is not evident from the synthetic benchmarks. In numbers: 572986 files in the live data, containing 4.5 TiB. Initial backup, about 18.5 hours. Incremental backup, 4m13s. This is from a local disk to a local disk. In addition to these, I've run numerous experiments on the new machine. These would have been much less easy to run on my laptop, and so I probably wouldn't have. Running benchmarks was always painful on my laptop, since it does not have the necessary disk space, and I'd really rather like to use it for other things. The results Thanks to the benchmarks and experiments I've been able to take the in-development version of Obnam from being quite impractical for real use to being in experimental use for real data. I now use the new version as my primary backup of my laptop, with two secondary backups (with the old Obnam version, and rsync) in parallel. This would not have happened this year without the extra hardware. In addition to the Obnam work, I've used the new machine to develop a test suite for vmdebootstrap. My actual development still happens on my laptop, except for things that are heavy enough to be slow on the laptop. I've made sure I can do most development purely on my laptop, while offline, including running a CI system, and testing things on two architecture and three releases of Debian. I do not want my development to be dependent on incidental things such as network access, unless I'm doing things that by their nature depend on the network, such as publishing changes or releases.

Jose M. Calhariz: Preview of amanda 3.3.7p1-1

Currently, as of today, amanda on sid is not installable because of a dependency on perl5 instead of perl. While I sort out a sponsor, my sponsor is very busy, here is a preview of the new packages. So anyone can install and test them and work around bug #808209. The source of the packages is in collab-maint. The debs files are here:

Iain R. Learmonth: YubiKey + udev follow-ups

In my previous post, I talked about the udev hack I had used with the YubiKey and how it was not the correct way to do things. I recieved a lot of feedback on this post, and here I'm hoping to summarise what the correct way to do it is. The rule I was originally using was:
SUBSYSTEMS=="usb", ATTRS idVendor =="1050",ATTRS idProduct =="0111", OWNER="irl"  
The problem with this rule was that it always made my own username the owner of the YubiKey. For my use on my laptop, this was fine, as I'm the only user ever logged into my laptop, but this is not the right way to do this. On a multi-user system you would want the user logged into the console, and so the one that has plugged in the USB device by implication, to be the owner of the device. Sam Morris followed up to my last post by e-mail to suggest the following rule:
SUBSYSTEMS=="usb", ATTRS idVendor =="1050", ATTRS idProduct =="0111", TAG+="uaccess"  
The difference here is that instead of explicitly setting an owner, the uaccess tag is added to the device. This tag has meaning to systemd-logind and will add the necessary ACLs to the device to allow the console user to access it. The ACL should also be removed by systemd-logind when you log out. He also suggested using getfacl (from the acl package) to check the ACLs that have been assigned to devices.
irl@orbiter$ getfacl /dev/hidraw0  
# file: hidraw0
# owner: irl
# group: root
user::rw-  
user:irl:rw-  
group::---  
mask::rw-  
other::---  
Here we can see that the device has been set to being owned by my username. (Note that on your system, the YubiKey may have a different path, check your dmesg output to see what device name it is assigned.) If you don't have systemd-logind available, fear not as there is an alternative approach you can take that was suggested by Simon Josefsson, who actually wrote a blog post in 2014 about using an offline GnuPG master key with subkeys on a YubiKey. If you install the pcscd package this will provide you with a daemon that runs as root and provides access to the smartcard for ordinary users. I haven't looked at how pcscd handles limiting access to the device for other users as this isn't an approach I've taken. Thanks to everyone who gave feedback, I feel like I've learnt something and taken another step closer to doing things The Right Way .

Petter Reinholdtsen: Using appstream with isenkram to install hardware related packages in Debian

Around three years ago, I created the isenkram system to get a more practical solution in Debian for handing hardware related packages. A GUI system in the isenkram package will present a pop-up dialog when some hardware dongle supported by relevant packages in Debian is inserted into the machine. The same lookup mechanism to detect packages is available as command line tools in the isenkram-cli package. In addition to mapping hardware, it will also map kernel firmware files to packages and make it easy to install needed firmware packages automatically. The key for this system to work is a good way to map hardware to packages, in other words, allow packages to announce what hardware they will work with. I started by providing data files in the isenkram source, and adding code to download the latest version of these data files at run time, to ensure every user had the most up to date mapping available. I also added support for storing the mapping in the Packages file in the apt repositories, but did not push this approach because while I was trying to figure out how to best store hardware/package mappings, the appstream system was announced. I got in touch and suggested to add the hardware mapping into that data set to be able to use appstream as a data source, and this was accepted at least for the Debian version of appstream. A few days ago using appstream in Debian for this became possible, and today I uploaded a new version 0.20 of isenkram adding support for appstream as a data source for mapping hardware to packages. The only package so far using appstream to announce its hardware support is my pymissile package. I got help from Matthias Klumpp with figuring out how do add the required metadata in pymissile. I added a file debian/pymissile.metainfo.xml with this content:
<?xml version="1.0" encoding="UTF-8"?>
<component>
  <id>pymissile</id>
  <metadata_license>MIT</metadata_license>
  <name>pymissile</name>
  <summary>Control original Striker USB Missile Launcher</summary>
  <description>
    <p>
      Pymissile provides a curses interface to control an original
      Marks and Spencer / Striker USB Missile Launcher, as well as a
      motion control script to allow a webcamera to control the
      launcher.
    </p>
  </description>
  <provides>
    <modalias>usb:v1130p0202d*</modalias>
  </provides>
</component>
The key for isenkram is the component/provides/modalias value, which is a glob style match rule for hardware specific strings (modalias strings) provided by the Linux kernel. In this case, it will map to all USB devices with vendor code 1130 and product code 0202. Note, it is important that the license of all the metadata files are compatible to have permissions to aggregate them into archive wide appstream files. Matthias suggested to use MIT or BSD licenses for these files. A challenge is figuring out a good id for the data, as it is supposed to be globally unique and shared across distributions (in other words, best to coordinate with upstream what to use). But it can be changed later or, so we went with the package name as upstream for this project is dormant. To get the metadata file installed in the correct location for the mirror update scripts to pick it up and include its content the appstream data source, the file must be installed in the binary package under /usr/share/appdata/. I did this by adding the following line to debian/pymissile.install:
debian/pymissile.metainfo.xml usr/share/appdata
With that in place, the command line tool isenkram-lookup will list all packages useful on the current computer automatically, and the GUI pop-up handler will propose to install the package not already installed if a hardware dongle is inserted into the machine in question. Details of the modalias field in appstream is available from the DEP-11 proposal. To locate the modalias values of all hardware present in a machine, try running this command on the command line:
cat $(find /sys/devices/ grep modalias)
To learn more about the isenkram system, please check out my blog posts tagged isenkram.

19 December 2015

Dirk Eddelbuettel: RcppTOML 0.0.5

After a short hiatus, a new version of the (wonderfully useful, if I dare say so ;-) RcppTOML package is now on CRAN. RcppTOML lets R read the (absolutely awesome) TOML configuration file format--which is simply fabulous as it emphasizes strong readability for humans while at the same time supporting strong typing as well as immediate and clear error reports. At work, we're all fans now. The new version on CRAN mostly updates to an updated version of the underlying cpptoml library by Chase. Nothing much changed on the R side. Courtesy of CRANberries, there is a diffstat report for this release More information and examples are on the RcppTOML page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Chris Lamb: travis.debian.net

travis.debian.net is my new hosted utility to make it easier and cleaner to test your Debian packages on the Travis CI continuous integration platform, without duplicating configuration or scripts across mulitiple repositories. You can read more about how it works, as well as follow the quick setup instructions. As ever, patches welcome.

Zlatan Todori : What is wrong with Jolla?

Jolla management really seems to not understand a first thing about how to deal with consumers. They "sailed" on wings people believing it will be open source product. They got litterally hunderds of request and question for why it isn't? Answers, I found once something along in these lines "we plan in future". The reallity - they aren't a good company. They still didn't ship tablets, they don't even know how to deal with that, they don't answer on people question and they even don't issue refunds for people that gave money for tablets. Jolla, you suck! They got some new funding with it but their blog post about it also sucks big time. Unless they open source SailfishOS they will go nowhere nor do I have any further interest in such bad behavior of one company that plays on community feeling. If you want a better experience and more open source then you should go with Tizen, FirefoxOS (although Mozilla closed development), Cyanogen, Android, Replicant and so on...

James McCoy: EINVAL woes with SG_IO

Dear lazyweb, TL;DR version Why does ioctl(fd, SG_IO, &sg_io_hdr) return EINVAL, but an immediate retry after reopening the /dev/sdX fd succeeds? I'm not sure if reopening the fd is relevant, but the code only holds the fd open long enough to do perform the ioctl. The frequency of EINVAL seems to increase in correlation with the number of IO threads, where none are seen with a single IO thread. Background At work, I've been adding Linux support to an internal Windows tool we use to perform data integrity testing of block storage devices. It's a heavily multi-threaded program: The user has the ability to use either SCSI pass-thru or read/write file to perform reads/writes to the LUN, as well as various other purely SCSI pass-thru commands. The IO portion of the code can be boiled down to basically the following pseudo code:
start IO thread  
    If SCSI pass-thru or command which requires SCSI pass-thru
        build sg_io_hdr_t struct
        open /dev/disk/by-path/  (O_RDWR   O_NONBLOCK)
        issue ioctl(fd, SG_IO, &sg_io_hdr)
        close fd
        return massaged ioctl status and scsi_status
     else
        open /dev/disk/by-path/  (O_RDWR   O_NONBLOCK)
        seek to LBA
        issue write/read
        close fd
        return massaged write/read status 
wait for IO thread completion  
check status and potentially retry operation
Problem As the number of target LUNs or IO threads scale, we're seeing increasing amounts of EINVAL errors when we issue the SG_IO ioctl. According to the sg documentation, there are only a couple situations where EINVAL should be seen: I wouldn't have been surprised to get EDOM (exceeding SG_MAX_QUEUE), but I'm at a loss as to where/why EINVAL is coming from. Granted, I'm opening an sd device instead of an sg device, so the error may be coming from a different layer in the stack. If you have any ideas, please let me know.

Next.

Previous.