Search Results: "ag"

5 June 2015

Guido G nther: Debian work in May

May was the first month I started to contribute to Debian LTS under the Freexian umbrella. In total I spent six hours working on: My current work flow looks like Now I have an already patched source tree to add the backported patches to. Especially in cases where the Jessie version is already fixed this makes it rather quick to get an idea what the affected versions are and to see how the code evolved over time. In order for this to work properly I made (on non LTS time) some improvements to gbp:

Mike Gabriel: My FLOSS activities in May 2015

May 2015 has been mainly dedicated to these three fields of endeavour: Received Sponsorship I am happy to report that I received a personal sponsoring over 3.000,- EUR from a sponsor not to be named in May 2015. The sponsoring has been dedicated to supporting my work on The Arctica Project. Last month's contributions of mine (8h) to the Debian LTS project had been contracted by Freexian [1] again. Thanks to Raphael Hertzog for having me on the team. Thanks to all the people and companies sponsoring the Debian LTS Team's work. Development and License of nx-libs 3.6.x What has been achieved in May 2015 concerning the nx-libs development? read more

4 June 2015

Norbert Preining: Debian/TeX Live 2015 is coming

texlive2015-is-coming a few more test

Daniel Kahn Gillmor: Challenge: one reproducible package a week

I encourage anyone interested in debian development to get involved with the Reproducible Builds project. My own project is to try to diagnose (and hopefully provide patches for) two unreproducible packages a week. Maybe you can do one package a week? Reproducible Builds is another example of the kind of audacious project that I celebrated in my last blog post. It's a fun way to learn a little bit about different parts of the archive, and to help on an incrementally-improving process. My workflow below is meant to encourage folks to join in. The documentation on the wiki is certainly more authoritative (and will be more up-to-date in the future). My usual workflow is this: The information at the R-B wiki page is quite detailed if you want more info. Finally, many many thanks to all of the people involved in the project, and particularly to h01ger and Lunar^, who have both contributed a ton of work, and have also made it easy to plug in and help as a less-involved contributor. The nice automatically-updated statistics provided by the team's continuous integration work makes it a fun game to help out. Tags: challenge, reproducible builds

3 June 2015

DebConf team: Final Call for DebConf15 Proposals (Posted by Michael Banck)

Call for Proposals Deadline The deadline for submitting proposals is approaching, with only 12 days left to submit your event by June 15th. Events submitted after that date might not be part of the official DebConf schedule. We are very excited about the upcoming conference, and we would like to encourage you to send your proposals. It s an important part of the conference to hear and discuss new ideas. If you have something that you d like to present but you have not submitted your event yet, please don t wait until the last minute! Check out the proposal submission guide and submit your event. If you have already submitted your event, do take this opportunity to login to summit and review it, expanding the event description to be more descriptive and appealing to the attendees if necessary. Second Batch of Approved talks We are happy to announce the following talks that are already approved: Please hurry up and share your ideas with us. Propose your event before the deadline is reached. Looking forward to see you on Heidelberg, The DebConf content Team

Raphaël Hertzog: My Free Software Activities in May 2015

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 10.25 hours on Debian LTS. In that time I did the following: Other Debian work Package Tracker. The Debian system administrators upgraded the machine hosting tracker.debian.org to jessie and I dealt with the fallout. Fixing the Apache configuration was easy but DACS also broke and I had to disable it (thus breaking login via sso.debian.org). Fortunately Enrico Zini and Martin Zobel-Helas debugged the problem and restored it. Sponsorship. I sponsored a dolibarr upload and many tryton-modules-* uploads to bring Tryton 3.6 to Debian (and granted DM rights on the newly introduced packages to Matthias Behrle who is maintaining those packages). Misc stuff. I discussed multiple feature requests with Dmitry Smirnov for dh-linktree. Packaging. I uploaded a new upstream version of cpputest. I did that twice actually because the first version had failing tests (see #784674). I also filed #784959 on blhc because I saw what looked like a false positive report for a missing hardening flag. I uploaded Django 1.8 to experimental. This is a major upstream release and shall ideally only be uploaded to sid after having reported problems on reverse dependencies. I doubt we will have the time to do this I started working on Publican 4.3.0 but the test suite fails and it s not even the fault of publican for once. It s a bug in libxml apparently. Thanks See you next month for a new summary of my activities.

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

Scott Kitterman: Debian LTS Work May 2015

This was my first month as a Freexian sponsored LTS contributor. I was assigned 4 hours which was enough for me to update clamav to the current upstream version, 0.98.7. This resolves a stack of CVEs and enables LTS users to take advantage of the latest anti-virus signatures and features clamav offers. This is consistent with the way clamav is updated for Debian supported releases through proposed-updates. This is covered under DLA 233-1.

2 June 2015

Jo Shields: mono-project.com Linux packages, June 2015 edition

The latest stable release of Mono has happened, the first bugfix update to our 4.0 branch. Here are the release highlights, and some other goodies. Stable Packages This release covers Mono 4.0.1, and MonoDevelop 5.9. As promised last time, this includes builds for RPM-based x64 systems (CentOS 7 minimum), Debian-based x64, i386, ARMv5 Soft Float, and ARMv7 Hard Float systems (Debian 7/Ubuntu 12.04 minimum). Version numbering From now on, we re going to be clearer with our version numbering scheme. Historically, we ve shipped, say, 4.0.0 to the public internally, there have been a lot of builds on this target branch, all of which get an internal revision number. 4.0.0 as-shipped was in fact 4.0.0.143 internally that was the first 4.0.0 branch release approved of for stable release. This release is the first service release on the 4.0.0 branch, numbered 4.0.1.44 it ll be officially referred to as 4.0.1 in some places, but isn t the same as 4.0.1.0, which already released on Linux/Windows a while back, to include an emergency bugfix for those platforms. That was sorta a screwup really. Using the 4-part version removes the ambiguity, rather than having 44 different 4.0.1 s in existence. And we ll aim to be clearer in future about what is alpha, what is beta, and what is final (and what is a random emergency snapshot). Alpha Linux packages Want to see things earlier? We ve now got the structure in place to provide Linux packages (and source releases) to mirror what we do on Mac. When we upload a prospective package to our Mac customers, we will automatically trigger builds for Linux too. See http://www.mono-project.com/download/alpha/ Beta Linux packages See above. s/alpha/beta/. Weekly git Master snapshots We already have packages in place for every git commit, which parallel-install Mono into /opt. This is different. Weekly (or, right now, when I manually run the requisite Jenkins job), the latest Mac build of Mono git master from our internal CI system will be copied to a public location just for you, a source tarball generated, and packages built. See here for info on making use of that.
directhex@marceline:~$ mono --version
Mono JIT compiler version 4.3.0 (Nightly 4.3.0.21/88d2b9d Thu May 28 10:54:32 UTC 2015)

Julien Danjou: Get back up and try again: retrying in Python

I don't often write about tools I use when for my daily software development tasks. I recently realized that I really should start to share more often my workflows and weapons of choice. One thing that I have a hard time enduring while doing Python code reviews, is people writing utility code that is not directly tied to the core of their business. This looks to me as wasted time maintaining code that should be reused from elsewhere. So today I'd like to start with retrying, a Python package that you can use to retry anything. It's OK to fail
Often in computing, you have to deal with external resources. That means accessing resources you don't control. Resources that can fail, become flapping, unreachable or unavailable. Most applications don't deal with that at all, and explode in flight, leaving a skeptical user in front of the computer. A lot of software engineers refuse to deal with failure, and don't bother handling this kind of scenario in their code. In the best case, applications usually handle simply the case where the external reached system is out of order. They log something, and inform the user that it should try again later. In this cloud computing area, we tend to design software components with service-oriented architecture in mind. That means having a lot of different services talking to each others over the network. And we all know that networks tend to fail, and distributed systems too. Writing software with failing being part of normal operation is a terrific idea. Retrying
In order to help applications with the handling of these potential failures, you need a plan. Leaving to the user the burden to "try again later" is rarely a good choice. Therefore, most of the time you want your application to retry. Retrying an action is a full strategy on its own, with a lot of options. You can retry only on certain condition, and with the number of tries based on time (e.g. every second), based on a number of tentative (e.g. retry 3 times and abort), based on the problem encountered, or even on all of those. For all of that, I use the retrying library that you can retrieve easily on PyPI. retrying provides a decorator called retry that you can use on top of any function or method in Python to make it retry in case of failure. By default, retry calls your function endlessly until it returns rather than raising an error.
import random
from retrying import retry

@retry
def pick_one():
if random.randint(0, 10) != 1:
raise Exception("1 was not picked")

This will execute the function pick_one until 1 is returned by random.randint. retry accepts a few arguments, such as the minimum and maximum delays to use, which also can be randomized. Randomizing delay is a good strategy to avoid detectable pattern or congestion. But more over, it supports exponential delay, which can be used to implement exponential backoff, a good solution for retrying tasks while really avoiding congestion. It's especially handy for background tasks.
@retry(wait_exponential_multiplier=1000, wait_exponential_max=10000)
def wait_exponential_1000():
print "Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards"
raise Exception("Retry!")

You can mix that with a maximum delay, which can give you a good strategy to retry for a while, and then fail anyway:
# Stop retrying after 30 seconds anyway
>>> @retry(wait_exponential_multiplier=1000, wait_exponential_max=10000, stop_max_delay=30000)
... def wait_exponential_1000():
... print "Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards"
... raise Exception("Retry!")
...
>>> wait_exponential_1000()
Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards
Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards
Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards
Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards
Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards
Wait 2^x * 1000 milliseconds between each retry, up to 10 seconds, then 10 seconds afterwards
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.7/site-packages/retrying.py", line 49, in wrapped_f
return Retrying(*dargs, **dkw).call(f, *args, **kw)
File "/usr/local/lib/python2.7/site-packages/retrying.py", line 212, in call
raise attempt.get()
File "/usr/local/lib/python2.7/site-packages/retrying.py", line 247, in get
six.reraise(self.value[0], self.value[1], self.value[2])
File "/usr/local/lib/python2.7/site-packages/retrying.py", line 200, in call
attempt = Attempt(fn(*args, **kwargs), attempt_number, False)
File "<stdin>", line 4, in wait_exponential_1000
Exception: Retry!

A pattern I use very often, is the ability to retry only based on some exception type. You can specify a function to filter out exception you want to ignore or the one you want to use to retry.
def retry_on_ioerror(exc):
return isinstance(exc, IOError)

@retry(retry_on_exception=retry_on_ioerror)
def read_file():
with open("myfile", "r") as f:
return f.read()

retry will call the function passed as retry_on_exception with the exception raised as first argument. It's up to the function to then return a boolean indicating if a retry should be performed or not. In the example above, this will only retry to read the file if an IOError occurs; if any other exception type is raised, no retry will be performed. The same pattern can be implemented using the keyword argument retry_on_result, where you can provide a function that analyses the result and retry based on it.
def retry_if_file_empty(result):
return len(result) <= 0

@retry(retry_on_result=retry_if_file_empty)
def read_file():
with open("myfile", "r") as f:
return f.read()

This example will read the file until it stops being empty. If the file does not exist, an IOError is raised, and the default behavior which triggers retry on all exceptions kicks-in the retry is therefore performed. That's it! retry is really a good and small library that you should leverage rather than implementing your own half-baked solution!

Ben Hutchings: Debian LTS work, May 2015

This was my sixth month working on Debian LTS. I was assigned 10.5 hours by Freexian's Debian LTS initiative. This was less than in previous months, but I was still able to work on several packages. dpkg This update was almost ready to release at the end of April. I had to rebuild from the upstream tarball as released by Guillem, then uploaded and issued DLA 220-1. tiff This update was also almost ready to release. I hoped to get some users to test it, but didn't get any response. I uploaded and issued DLA 221-1. ruby1.8 Ruby 1.8 had a single CVE to fix. It was already fixed in wheezy against a similar upstream version, so it took little time to apply that patch. Ruby has an extensive test suite that reassured me this wouldn't cause a regression. I uploaded and issued DLA 224-1. p7zip p7zip allows arbitrary file overwrite via symlinks (CVE-2015-1038) when extracting a carefully constructed archive, and this bug is not fixed upstream. This sort of bug has been identified and fixed previously in similar tools such as GNU tar, so I looked at how that handles links and tried to apply a similar change in p7zip. This was somewhat complicated by the code style (C++ with COM-style interfaces and NIH containers), but not too hard. I came up with a patch that seems to work for the versions in Debian, and have attached it to the upstream bug report for review. linux-2.6 I reviewed the patches for Linux 2.6.32.66 - many of which were my own backports - and then integrated this update into the SVN branch. I will probably upload a new version soon, whether or not there's a high severity issue, just to avoid piling up a large number of changes in one update.

1 June 2015

Thorsten Alteholz: My Debian Activities in May 2015

FTP assistant This month I marked 235 packages for accept and rejected 44 of them. I know, the NEW-queue is rather large, but the numbers are showing a downward trend again. In the light of recent events I would like to cite two things. The US Copyright Office Circular 14 says about derivative work:
A typical example of a derivative work received for registration in the Copyright Office is one that is primarily a new work but incorporates some previously published material. This previously published material makes the work a derivative work under the copyright law. To be copyrightable, a derivative work must be different enough from the original to be regarded as a new work or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes. The new material must be original and copyrightable in itself. Titles, short phrases, and format, for example, are not copyrightable.
Title 17 of the United States Code says in 103:
The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.
Squeeze LTS This was my eleventh month that I did some work for the Squeeze LTS initiative, started by Raphael Hertzog at Freexian. This month I got assigned a workload of only 10.25h and I spent most of it to prepare a new upload of ruby1.9.1. The other stuff I uploaded was [DLA 222-1 has been only a sponsored upload, where Markus Koschany prepared the patches. [DLA-226] needed two uploads as the first patch turned out to be incomplete. I also marked CVEs in the security tracker as for Squeeze or added notes for future processing.
The next big adventure in June will be another upload of PHP5. Other stuff This month I also uploaded feynmf to take care of the new TDS tree (#766287). Donations Again, thanks alot to all donors. I really appreciate this and hope that everybody is pleased with my commitment. Don t hesitate to make suggestions for improvements.

Sven Hoexter: Out of the comfort zone: CentOS 5 mock chroot and /etc/filesystems vs net-snmp

It turned out that my adventure in backporting net-snmp from CentOS 7 to CentOS 5 has a regression issue with disk stats. The logs provided us with the following error message
2015-05-29T10:27:14+02:00 foobar snmpd[2200]: Cannot statfs
but only on CentOS 5. CentOS 6, build on the same CentOS 7 VM also with mock, worked like a charm. When I attached strace to the snmpd process I could see that the calls to statfs() were executed with an empty string, so no path was supplied. A bit of source code grep'ing already pointed in the direction of #define ETC_MNTTAB but at that point I didn't believe that the chroot could be the culprit. So it took some discussions with the colleagues until I did a test build, the old way with a "./configure --prefix=$HOME/snmpd && make && make install", on a real system. To my surprise that worked. Since I did not fold in all the patches from the CentOS 7 rpm I expected that one of the patches broke something along the way for old Linux releases. So I went on, disabled nearly all patches in the spec file, build again in a chroot and the resulting binary still did not work. Somehow the chroot was at fault. Looking closer at the configure magic linked above you'll see it iterates through a list of various files that contain the list of mounted disks on various of *nix systems. For some unknown reason my CentOS 5 chroot is not populated with a proper /etc/mtab linked to the systems /proc/self/mounts while the one for CentOS 6 is. With /etc/mtab missing the configure script happily picks up /etc/filesystems which is, you might or might not know this, the /etc/fstab pendant on AIX. But on a CentOS system that just contains a list of filesystems. That indeed could not work out and explains why the build itself succeeded but parsing a filesystem path out of that file did not. Luckily we can override that stuff easily with the '--with-mnttab="/etc/mtab"' configure option of net-snmp, but the "/etc/filesystems" file on CentOS was something I did not expect and never noticed before. Hint: for the function of /etc/filesystems take a look at man 8 mount and the section about the "-t" parameter.

Enrico Zini: 05

Internet references saved for May 2015 Instead of keeping substantial tabs open until I have read all of them, or losing them in the jungle of browser bookmarks, I have written a script that collects them into a file per month, and turns them into markdown files for my blog. This way I sort of know where to find them, and if I do not, some internet search might. And if I wish, I can even choose to share it. download as mailbox

Joachim Breitner: ZuriHac 2015

Last weekend, I attended ZuriHac 2015, which was, as always, a pleasant event. I did not actually do a lot, besides some maintenance of Debian Haskell packages, but had some nice chats. It is always very motivating to hear that people read my blog, or that they found my talk (such as the Haskell Bytes talk at Galois) helpful. My plan was to work on gipeda and perf.haskell.org. I did not do much until an hour before I had to leave, when Lennard Kolmodin came around and I showed him the software. He liked it so far, so we quickly set up an instance of gipeda for the binary library. It is not finished yet, as more benchmarks need to be extracted from the build log. That was motivating, and I got further ideas to implement during the train ride back. If only that had happened earlier during the weekend...

Russ Allbery: Review: Hild

Review: Hild, by Nicola Griffith
Series: Hild #1
Publisher: Farrar, Straus and Giroux
Copyright: 2013
ISBN: 0-374-28087-8
Format: Hardcover
Pages: 539
Hild was born in seventh-century Britain, daughter of Hereric (would-be king of Daria) and Breguswith. Born, her mother said, to be a light to the land. This much is documented by the Venerable Bede, in The Ecclesiastical History of the English Nation, along with Hild's later rise to become one of the most powerful abbesses in British history. But nearly all of Hild's early life is a cipher. Hild fills in some of that gap with fiction. Specifically, it takes Hild from a child of three, learning her father has been killed, to a young woman, an advisor of Edwin king. It's a coming of age story in part, following her maturation both physically and mentally, her training in when to speak and how, and the dangers of being close to royalty in a fractious, political, and war-torn land. It's also the story of endless maneuvering and care, initially by her mother Breguswith and then by Hild herself sometimes in opposition to her mother, sometimes in alliance as her mother attempts to make a safe place for her daughter and herself in a treacherous court of shifting dangers. But Hild is also a story about Britain. It's a novel about how it felt and how it sounded. How it was organized, primarily among the high-born but with snippets of perspective from the lower classes. And it's a story about women: about weaving, about medicine, about friendships and partnerships and alliances among women, about the politics of marriage and childbirth, but also about the places women held and made in a time when surviving official history is all about the men. Hild is a painstakingly-researched, sprawling, lush, and sensual immersion in a part of history that gets little formal attention: after the Romans, before what we think of as medieval, before England as a country. I've been waiting for a new Nicola Griffith novel for quite a while, since Always in 2007. Hild doesn't disappoint, but it's also different than Griffith's previous writing. It has less of the strong narrative drive and clarity of either her SF or Aud Torvingen stories. Instead, the goal of Hild is to immerse and transport you, to help you feel the shape of Hild's world, to understand her days and tasks, her dreams and dangers. Like all of Griffith's work, it's beautifully written. Griffith puts description at the fore, in the sharp eyes of an observant girl who loves the outdoors, and who has been taught to watch for signs of weather and tools of healing. From early on, Hild's mother sets her up as a seer and prophetess as a way of establishing her value to war leaders and kings, and while some of it is drama and cryptic words, so much of it is careful observation, networks of information-gathering, and sharp deduction about the motives and politics of surrounding kings. Hild is very good at what she does because she has a sharp, quick mind that has been carefully trained, and because she has the aid of her mother's networks and then aid in building her own. Griffith does a wonderful job showing the reader what Hild sees, how she appreciates the world both for its own beauty and for the information she can gather from it, and how to build influence by navigating tense and dangerous moments: waiting for just the right moment and the right word, and taking sudden, impulsive risks and accepting their consequences. Unfortunately for me, this setting is also rich in complex politics and numerous actors, with older and unfamiliar names, and I got lost. Constantly. That's the drawback to immersion: Griffith doesn't hold the reader's hand. We get Hild's thoughts and analysis, and the reader has to keep up. Sometimes I did; sometimes I didn't. There's a dizzying flurry of names here, both personal and place, and while there is a map and a single family tree, neither helped me as much as I wanted them to. At several points, I found myself skimming through the latest shift in the balance between various petty kings because, while I knew I'd seen all the names before, they had come adrift from their context in the story. That was my major frustration with this book. It was all interesting enough that I would have kept thumbing back to a detailed dramatis personae, and indeed I kept checking the family tree, but there just wasn't enough detail there. Even better would have been a brief factual history of the political and military conflicts Hild was living through, keyed by chapter. Hild is startlingly intelligent, leaping from insight to insight, which is wonderful for building character, but which occasionally leaves the reader scrambling to catch up with the connections between her thoughts. I felt like, had I the broader context, I could have understood her insight more readily. All this information is likely available, since Griffith is playing off of documented history, but I'm not the sort of reader who likes doing Internet research while engrossed in a book. So, that's the downside, at least for me. But this book has many strengths, even if you're lost much of the time. Hild as written by Griffith is a fascinating character, full of sharp edges and difficult moods and a powerful belief in what she feels is right. Griffith is at the height of her writing ability when describing Hild making hard choices and taking on burdens that seem too large for her to bear. There are two sections of the book, where Hild is forced by circumstances to lead men in violence, that I think are two of the best bits of writing Griffith has ever published not just because of those scenes themselves, but because of the aftermath, the lingering echos, the way that they shape and inform everything Hild does afterwards. The mingling of reward and loss, maturation and trauma, the sense that the world has shifted both inside and out and it's nearly impossible to say whether the change is for the better or worse. Griffith also knows when not to say too much, and while I found that frustrating for the politics, it does wonders for the characters. Hild's complex and fraught relationship with Gwaldus is the best example. We never know exactly what Gwaldus is thinking; Hild can only guess, and at times one is fairly sure that she guesses wrong. But that doesn't lead to sudden revelations, where the characters finally understand each other. Instead, they both adjust, they maneuver around each other, they find space and understanding where they can, and sometimes they just close off. This book is full of relationships like this: loves that are too complicated for words, bonds that are too dangerous to acknowledge, and characters who can't relax even though they wish the best for each other. At times, it's exhausting reading, but it gives Hild a tension that one wouldn't expect from a sprawling novel full of description and scene-building. Hild is clearly the first book of a series, and leaves quite a lot unresolved. If you want closure in relationships and in politics, there's a lot here that you may find frustrating. And if, like me, you struggle to keep names and politics straight, you're probably going to get lost. But it's well worth the effort for the description, for Hild's thought processes, and for a few haunting scenes that I will be replaying in my head for a very long time. Expect to take your time with this, and wait until you're in the mood for immersion and puzzling out context as you go, but recommended. I suspect it would be even better on a second reading. Rating: 8 out of 10

Paul Tagliamonte: Soylent Sherry Negroni

paultagskitchen:
DELICIOUS COCKTAIL PHOTOIngredients
  • 1 tsp soylent
  • 1 tsp simple syrup
  • 1 oz Palo Cortado sherry
  • oz Rosso Vermouth
  • oz Campari
Assembly Combine Soylent and Simple Syrup. Create what I m going to start to call Soylent Syrup . Enjoy that one, folks. Add ice to a rocks glass, pour Soylent Syrup over ice. Add Sherry, Vermouth and Campari. Stir. Garnish with an orange twist. Big thanks to Matthew Garrett for sparking this one.

31 May 2015

Dirk Eddelbuettel: rfoaas 0.1.6

After a few quiet months, a new version of rfoaas is now on CRAN. As before, it shadows upstream release of FOAAS from which carried over the version number 0.1.6. 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 f$#@ off. Release 0.1.6 of FOAAS builds on the initial support for filters and now adds working internationalization. This is best shown by example:
R> library(rfoaas)
R> off("Tom", "Everyone")                                      # standard upstream example
[1] "Fuck off, Tom. - Everyone"
R> off("Tom", "Everyone", language="fr")                       # now in French
[1] "Va te faire foutre, Tom. - Everyone"
R> off("Tom", "Everyone", language="de", filter="shoutcloud")  # or in German and LOUD
[1] "VERPISS DICH, TOM. - EVERYONE"
R> 
We start with a standard call to off(), add the (now fully functional upstream) language support and finally illustrate the shoutcloud.io filter added in the preceding 0.1.3 release. As usual, CRANberries provides a diff to the previous CRAN release. Questions, comments etc should go to the GitHub issue tracker.

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

Dominique Dumont: Improving update of existing debian/copyright file

Hello One of my last blog introduced the new cme update dpkg-copyright command and explained how to use this command to create a debian/copyright file from scratch. We will see in this blog how cme update dpkg-copyright command can also be used if a debian/copyright file already exists. During the lifetime of a package, creating a new debian/copyright copyright file should only happen once. When updating a package to a new upstream version, the content of the copyright file should be modified to reflect upstream changes by: cme update dpkg-copyright can be run with an existing debian/copyright file: the information extracted by licensecheck are merged in debian/copyright. Unfortunately, this merge may bring back the errors coming from licensecheck that you ve cleaned up manually last time. This last part is not optimal as the manual clean up must be repeated after cme update dpkg-copyright is run. Here s a way to avoid the last problem: cme update dpkg-copyright supports a way to modify the content of debian/copyright after the merge: the optional file debian/fix.scanned.copyright contains instructions to tweak the content of debian/copyright. (See Config::Model::Dpkg::Copyright man page for more details) You may remember that Config::Model handles all configuration information as a tree. The information contained in the copyright file is also stored in a tree structure. debian/fix.scanned.copyright contains instructions to navigate this tree and modify the content of the tree. Imagine that there s a robot (or a monkey) in that configuration tree. Each instruction tells the robot either to move in the tree or to perform an operation. The most useful instructions for debian/fix.scanned.copyright are: Otherwise: Let s see a commented example:
# go to the root of the tree (with '!')
# and remove a bogus Files entry (with ":~")
! Files:~"foo/bogus.c"
// go to a Files entry and append (operator '.=') some info to   owner
! Files:"foo/bar.h"
  Copyright.=" Appended info."
# go back to tree root and assign   info
! Files:"foo/baz.c" Copyright="2014, FooBar"
# add a global license and a file entry missed by licensecheck
# global license must be set before using it in Files entry
# note: MIT text license is provided by cme
! License=MIT
! Files:"3rdparty/missed.c" Copyright="2005 FooBar" License short_name=MIT
Other possible instructions for this file are described in Config::Model::Loader doc. The number of instructions depends on the accuracy of licencecheck command. Hopefully, this number can be reduced by improving licensecheck. Last but not least, the following packages are required: You may want to install also libconfig-model-tkui-perl to update the copyright file with cme GUI. In summary, the command cme updated dpkg-copyright associated with instructions stored in debian/fix.scanned.copyright enable Debian packagers to update with less effort debian/copyright file when updating a package. All the best

29 May 2015

Norbert Preining: USB stick update: Debian is back, plus GRML

In the previous post on the multi-boot usb stick, Debian had to be dropped, due to missing support of iso-loading in the Debian installer iso images. Thanks to helpful comments from Jonathan McDowell and private emails, we found a way around this. In addition to having again an installable Debian image, I also added GRML support. multi-usb-disk There are a few tricks necessary to get this going, though. Let us start with the easy part, grml: Grml Quoting from the home page of Grml
Grml provides an excellent selection of software packages for installation, deployment and system rescue. You ll get sysadmin s favourite tools. Choose between a x86 and an amd64 version depending on your needs or just grab the multiboot ISO grml96, providing 64bit and 32bit ISOs in one single place.
I went for the 64bit version Version 2014.11 (named Gschistigschasti , a typical Austrian expression for fuss ), as most computers nowadays are anyway 64bit capable, downloaded the image file grml64-full_2014.11.iso, and saved it into my USB stick s boot/iso/ directory, where there are already the other iso images. Then, with the help of the Grml web page which provides guidance how to boot from ISO, I added the following entry to my grub.cfg:
submenu "GRML 2014.11 ---> "  
  menuentry "Grml Rescue System 64bit"  
        iso_path="/boot/iso/grml64-full_2014.11.iso"
        export iso_path
        loopback loop (hd0,1)$iso_path
        set root=(loop)
        kernelopts=" ssh=SOME_PASSWORD_HERE toram  "
        export kernelopts
        configfile /boot/grub/loopback.cfg
    
 
Note that if you add the ssh=SOME_PASSWORD_HERE part, an ssh server is started and the root login password will be set to SOME_PASSWORD_HERE, so choose it wisely (and different from your normal passwords!). If you don t want a running ssh server, simply remove the ssh parameter. That s it, booting into Grml takes quite some time, but worked out nicely. Debian Jessie installation As mentioned in the previous post, booting Debian/Jessie installation images via any method didn t work, since the iso images is never found. It turned out that the current installer iso images do not contain the iso-scan package, which is responsible for searching and loading of iso images. But with a small trick one can overcome this: One needs to replace the initrd that is on the ISO image with one that contains the iso-scan package. And we do not need to create these initrd by ourselves, but simply use the ones from hd-media type installer. I downloaded the following four gzipped initrds from one of the Debian mirrors: i386/initrd text mode, i386/initrd gui mode, amd64/initrd text mode, amd64/initrd gui mode, and put them into the USB stick s boot/debian/install.386, boot/debian/install.386/gtk, boot/debian/install.amd, boot/debian/install.amd/gtk, respectively. Finally, I added entries similar to this one (rest see the grub.cfg file):
submenu "Debian 8.0 Jessie NetInstall ---> "  
    set isofile="/boot/iso/firmware-8.0.0-amd64-i386-netinst.iso"
    menuentry '64 bit Install'  
        set background_color=black
        loopback loop (hd0,1)$isofile
        linux    (loop)/install.amd/vmlinuz iso-scan/ask_second_pass=true iso-scan/filename=$isofile vga=788 -- quiet 
        initrd   /boot/debian/install.amd/initrd.gz
     
    ...
 
Again an important point, don t forget the two kernel command line options: iso-scan/ask_second_pass=true iso-scan/filename=$isofile, otherwise you probably will have to make the installer scan all disks and drives completely, which might take ages. With that in place, the stick now is back to full working, plus an added Grml. Thanks everyone for the suggestions.

Roland Mas: FusionForge 6.0 final release available

Hi all, After 4 release candidates, the FusionForge community is proud to announce the new major Fusionforge 6.0 final release. The major changes in this version are: Here is a more detailed list of visible changes: Standard features: Tracker roadmap of the 6.0 release: roadmap. Some metrics about 6.0: FusionForge 6.0 can be downloaded in source form from our file release system. Packages will be available in some distributions soon. Enjoy! Your feedback to fusionforge-general@lists.fusionforge.org is welcome! For more information on FusionForge, refer to FusionForge.org. -- The FusionForge community

Next.

Previous.