Search Results: "ag"

28 May 2013

Andrew Pollock: [life] Running, a year later

So it's been about a year since I started running. In that time, I've gone from just being able to run 5K, to comfortably doing 10K in just under an hour. In that same time, my weight has gone from 77.5 kg to around 69 kg. The thing that started all of this off was the 5K Packard Summer Scamper, and next month I'm going to run in my first 14K fun run, the City2South. I thought I'd have a go at fund raising too, so if you'd like to make a donation, here's my page. I'm raising money for the Heart Foundation. I've constantly surprised myself with my progress. Just the last time I went for a run, I managed to set personal records on 1 km, 1 mile, 5 km and 10 km, which really blew me away. Once upon a time, I had this crazy idea to try and get into the Queensland Police Service, and one of the fitness requirements for applying was you had to be able to run 2.4 km in under 12 minutes, and I remember training away on the treadmill at the gym and only just scraping in under that time on a treadmill. Then I tried it on a running track, and I have these vague memories of it being a total slog. That was probably 10 years or more ago now. Now I could do that easily. I've got quite a nice 10 km running course in my local neighbourhood, so I'm thinking now that I'm comfortably running 10 km on this course, I should try and go for a half-marathon distance, so one of these weekends I'll just try running the same course twice plus a little bit more, just to see if I have it in me. Then maybe I'll consider entering a half-marathon, just for shits and giggles. I'll probably do it after I run 14 km, which will be the longest distance I've run to date. I only learned about the City2South run yesterday. The run that I've been planning on doing since returning to Brisbane is the Bridge to Brisbane. It looks like they've just opened up entries for it now, so I guess I should go sign up for it too.

Johannes Schauer: New bootstrap analysis results

I wrote a small wiki page for botch. It includes links to some hopefully useful resources like my FOSDEM 2013 talk or my master thesis about botch. The final goal of botch is to generate a build order with which Debian can be bootstrapped from zero to more than 18000 source packages. But such a build order can only be generated once enough source packages (by now the number is around 70) incorporate build profiles which allow to compile them with less build dependencies and thereby break all build dependency cycles. So an intermediary goal of botch is, to find a "good" (i.e. a close to minimal amount) selection of such build dependencies that should be dropped from their source packages. So far, the results of all heuristics we use for this task were just dumped to standard output. Since this textual format was hard to read for a human developer and even worse machine readable, that tool now outputs its results in JSON. This data is then converted by another tool to a more human readable format. One such format is HTML and with the help of javascript for sortable and pageable tables, the data can then be presented without producing too much visual clutter (at least compared to the initial textual format). Another advantage of HTML is, that the data can now easily be shared with other developers without them having to run botch or install any other program first. So without further ado, please find the result of running our heuristics on Debian Sid as of 2013-01-01 here: http://mister-muffin.de/bootstrap/stats/ Here is a screenshot of what you can expect (you can see part of the table of edges with most cycles through them): As a developer uses this information to add build profiles to source packages, this HTML page can be regenerated and will show which strongly connected components are now left in the graph and how to best make them acyclic as well. Besides other improvements I also updated the data I used to generate the graphs from this post. I found this update to be necessary since we found and fixed several implementation bugs since October 2012, so this new plot should be more accurate. Here a graph which shows the amount of vertices in the biggest strongly connected component of Debian Sid by date. Some datapoints are missing for dates for which important source packages in Sid were not compilable.

Russ Allbery: Review: Advanced Perl Programming

Review: Advanced Perl Programming, by Sriram Srinivasan
Publisher: O'Reilly
Copyright: August 1997
ISBN: 1-56592-220-4
Format: Trade paperback
Pages: 392
The problem with buying lots of books is that one frequently doesn't read them soon after purchase. And while nearly all fiction and most non-fiction doesn't have a time limit, technical books are more of a problem. As you might have guessed from the publication date and subject matter of this book, it's one I waited too long to read. I picked up Advanced Perl Programming not too long after it was first published in 1997. I bought it primarily for the chapters on XS programming, since I was just starting to develop and help maintain code that built Perl interfaces for C libraries. And then it sat on my bookshelf in the office, and then at home, until it was 16 years old. That's problematic for a general Perl programming guide; it's particularly troublesome for a book that dives deep into internals. That said, I still got some interesting information from it. Advanced Perl Programming is something of a grab bag of different and largely unrelated topics. It starts with a data structures overview (which is mostly about references), covers typeglobs and the Perl symbol table, briefly discusses closures, and then dives deeper into eval. That's followed by an overview of modules and object-oriented programming in Perl. The general Perl topics close with a solid (if outdated) discussion of tied objects and a somewhat rambling and remarkably general discussion of persistance. Srinivasan then covers some recommended module APIs for networking and graphics (Tk, specifically) while working through some complex examples, takes a deeper dive into eval and code generation, and concludes with three chapters on XS and embedded Perl interpreters. This is all solid material, but a lot of it is at least partly obsolete. The chapters on modules and object-oriented programming fare the worst; you'll find much better guides to those topics elsewhere. Data structures also fare poorly, partly because Srinivasan is still happy to use symbolic references, now considered bad style due to lack of compile-time checking. (That does mean, though, that this is one of the best introductions to symbolic references that you'll find, since few other Perl programmers discuss them.) But the rest of the book is fairly solid, if limited by age. If I'd read it when I first started with XS, it would have indeed helped. Advanced Perl Programming contains a succinct and clear overview of Perl internals and data representation (assuming, of course, it's not changed drastically, but I didn't notice any significant issues from what I know of internals from quite a lot of XS programming), particularly when combined with the earlier chapter on typeglobs and the symbol table. It is interesting, though, to see how much accepted Perl style has changed. Srinivasan is quite fond of eval with a scalar argument to construct code at runtime, something that most current authors recommend against when it can be avoided. The loss of static syntax checking means the technique is often hard to debug and can cause surprising runtime errors. Several of the more advanced tricks in this book are built on that framework, including a moderately interesting templating system that he constructs from scratch in this book. The examples here are also missing the focus on use strict, warnings, and avoiding special variables and unusual constructs that you see in more recent Perl books. This is a very thoughtful book, with several structural techniques that I appreciated and would like to see more technical writers use. One is the comparisons to the approaches of other languages at the end of most chapters. It puts Perl's approach in a broader context and encourages thought about alternative ways to view a particular feature and implementation tradeoffs in Perl's choices. Another is the careful discussion of design approaches and possibilities during the construction of larger examples. I think there's a tendency in technical books to spend a lot of time developing the best possible implementation of something and then show that completed example. Even with a detailed analysis of its construction, this can be less useful than a broader discussion of possible approaches, including dead ends. The problem, of course, is that 16 years is a long time, even for a relatively mature programming language, and Perl has changed. There are significant improvements not only to the standard library but to Perl core functionality that have happened since this book was written. The chapter on tying, which is otherwise excellent, is badly out of date on what functionality and methods are available and is no longer a reliable guide to using that feature except for simple cases. Similar problems plague the chapter on persistence, which develops the concept from basics that most programmers reading an advanced book no longer need, and which has been rendered mostly obsolete by further developments in the Perl module ecosystem. I think the best parts of this book, the ones that cover material that I think is still relatively accurate and that are not well-covered by other resources, are the chapters on typeglobs and on XS. The typeglob discussion is both clear and informative, covering material and techniques that are used in a few core Perl modules and that I've never seen adequately addressed elsewhere. I'd subsequently picked up XS and Perl embedding the hard way: lots of trial and error and reading difficult POD documentation. I wish I'd read this book earlier, since Srinivasan does a great job of basic orientation. He doesn't go far enough for me (the book I probably wanted was Extending and Embedding Perl by Jenness and Cozens, published five years later), but I would have been up and running with basic XS much faster by starting here. If this were 1997, or even 2000, I would probably recommend this book, albeit with a few caveats. Higher Order Perl is the place you should go for discussion of closures, rather than here (although of course it didn't exist then). I wasn't fond of string eval even in 1997, and I still think it produces code that, while efficient and quite powerful, is horribly difficult to understand. And the introduction to modules is adequate but not compelling; most other introductions to object-oriented programming and module construction in Perl are better. But even discarding those chapters (and the mostly unnecessary Tk reference), there's a lot of great material here that would have been quite helpful in 2000. Unfortunately, this is not the sort of technical book that ages well, and while I did pick up some useful background knowledge and a much better understanding of typeglobs, I mostly read this book because I wanted to salvage some knowledge from a book that sat for far too long on my shelves. There's really no reason to buy it today. If you run across it in a library, there are a few chapters that are still worth reading, but by and large if you know enough Perl to know where to be careful of landmines due to changes in Perl since the book was written, you also know enough Perl to not really need this book. Rating: 5 out of 10

Russ Allbery: Collected haul

I've been slow lately in writing these up (and, for that matter, in doing most other things related to reading; things have been rather busy lately). This is a bunch of here-and-there purchases over the last few months, including Powell's Indiespensible shipments. Sandra Barret Face of the Enemy (sff)
Anne Bishop Written in Red (sff)
Lois McMaster Bujold Captain Vorpatril's Alliance (sff)
Cary Caffrey The Girls from Alcyone (sff)
Jenni Fagan The Panopticon (mainstream)
Niels Ferguson, et al. Cryptography Engineering (non-fiction)
Jen Kirchner The Fourth Channel (sff)
Anothony Marra A Constellation of Vital Phenomena (mainstream)
Steve McConnell Code Complete (non-fiction)
Seanan McGuire Velveteen vs. The Junior Super-Patriots (sff)
Patrick Nielsen Hayden, et al. (ed.) Some of the Best from Tor.com: 2012 (sff anthology)
Lisa O'Donnell The Death of Bees (mainstream)
Susan Palwich Flying in Place (sff)
Kim Stanley Robinson 2312 (sff)
John Scalzi Redshirts (sff)
Ian Tregillis Bitter Seeds (sff)
Leon Trotsky The History of the Russian Revolution (non-fiction)
Simon Van Booy The Illusion of Separateness (mainstream)
Chris Anne Wolfe Shadows of Aggar (sff)
Barbara Ann Wright The Pyramid Waltz (sff) That's a lot of stuff. It includes a couple of non-fiction O'Reilly books from sales, a few months of Powell's Indiespensible subscriptions, a variety of books I picked up after a discussion of good lesbian fiction on Tor.com (romance without the obnoxious gender tropes, or at least as many of them), and the rest of the Hugo nominees for the year. I got a ton of reading done earlier this month. I wish I could say the same thing about reviews, but I only wrote a few. That's something that I want to try to catch up on soon, so there will probably be a flurry of those posted soon. I've already read Blackout and Redshirts of this year's nominees (a review of the latter is coming), so at least I'm not too far behind on the reading. Throne of the Crescent Moon is in progress now.

27 May 2013

Bits from Debian: Debian welcomes its 2013 crop of GSoC students!

We are proud to announce that 16 students have been accepted to work on improving Debian this summer through the Google Summer of Code! This is great news, following our 15 accepted students in 2012, and 9 accepted students in 2011. Here is the list of accepted students and projects: If you're interested in one of the projects, please follow the links and talk directly to the students or the mentors, or come hang out with us on IRC. Welcome everyone, and let's make sure we all have an amazing summer!

Michael Stapelberg: Results of the Debian systemd survey

A week ago, we started the Debian systemd survey. The goal was to figure out a few trends and answer the following two questions:
  1. Do our subjective impressions from the discussions on debian-devel reflect the general sentiment about systemd?
  2. What are the main concerns that most people have?
Thank you all for your participation! General I am happy to tell that 2113 people had a look at the survey and 573 people actually participated. Of those, 45.7% said they are a DD, DM or otherwise maintaining packages. 74.5% said they actually booted and used a computer running systemd. With regards to having systemd in Debian at all, not necessarily as the default init system, answers are as follows: 43.9% said they personally want systemd as the default init system in Debian, while 32.2% don t want that. The remaining 23.7% don t know yet. Top concerns About 50% of participants provided one or more concerns. Evaluating this part of the survey is obviously the hardest, since the answers were provided as free text. I tried categorizing the feedback into a few buckets. Each bucket comes with a number which is a weighted (!) count, i.e. the top concern counts 3 times, the second concern counts 2 times and the last concern just once. If you cannot find your personal concerns, that is because those which were just voiced by less then five people are not listed here. As I said, we cared about trends in this survey, not individual opinions.
  1. systemd is too complex, or bloated, or it does too many things, or has too many dependencies (weight: 217)
  2. systemd is not portable to non-linux systems, e.g. Debian/kFreeBSD or HURD (weight: 199)
  3. Debugging the boot process is harder than in sysvinit (weight: 106)
  4. I have a problem with systemd upstream and/or Lennart in particular (weight: 87)
  5. systemd violates the UNIX philosophy (weight: 35)
  6. I dislike binary logs and/or the journal in general (weight: 30)
  7. systemd is too new, still untested, unstable and experimental (weight: 24)
  8. I cannot find enough documentation in general or about the transition from sysvinit to systemd in particular (weight: 20)
  9. People need to learn new commands/how the new system works (weight: 20)
  10. I don t know what problems systemd solves and/or have no problems with sysvinit currently (weight: 19)
  11. I think the configuration is binary and/or the configuration format is weird (weight: 13)
  12. systemd s code is not good (memory leaks, performance problems) and/or upstream s development lacks best practices such as long-term stable branches (weight: 9)
  13. There are problems with systemd in Debian (e.g. Debian-specific extensions to /etc/fstab not supported, system doesn t boot) (weight: 9)
  14. Customizing the boot is harder than with sysvinit (weight: 8)
  15. systemd is not compatible with sysvinit (weight: 8)
I realize that the choice of buckets is somewhat broad and there are many different, finely nuanced opinions out there. Again, this is for seeing a trend, not accounting for every single individual opinion. In case you strongly believe that I did something wrong when evaluating the survey results, please contact me and we can work something out. Conclusions/Actions I know this is a controversial topic. Please don t start yet another systemd discussion on debian-devel. We, the systemd Debian maintainers, will try to come up with good answers to all listed concerns and communicate them in a friendly and concise way soon. Furthermore, we have recognized the need for more documentation/information about how things are supposed to work with regards to the transition (and systemd in general) and will address that, too. Raw questions/numbers
Total records in survey: 573
Are you a Debian Developer (DD) or Debian Maintainer (DM) or otherwise currently maintaining Debian packages?
262 Yes
311 No
Did you ever boot and use a computer running systemd? It does not matter whether that computer was running Debian or a different operating system.
427 Yes
146 No
What is your general sentiment towards having systemd in Debian (not necessarily as default)?
358 I welcome systemd in Debian, everything is fine.
 81 I am not sure yet.
 46 I don t care.
 88 I don t want systemd in Debian.
Would you personally want systemd as the default init system in Debian?
252 Yes
136 I don t know
185 No

Dirk Eddelbuettel: R / Finance 2013 Recap -- and Presentation Slides

The fifth internation R/Finance conference was held last weekend. As one of the founding co-organizers, I may well be accussed of a little bias, but we think we once again pulled off a very nice and successful weekend-long event. Participants had kind words to say during the conference, and a few first posts have appeared such as Joe Rickert's post over at the REvo blog. Some participants, myself included, had already posted on their personal websites (though had forgotten to mention it here). In any event, I just updated the website with links to the pdf (or ppt) slides of all presenters who shared their material with us. Supplemental material may be made available too at a later date. We hope you find these slides useful. Please do spread the word about the R/Finance conference as we expect to have a sixth edition in May 2014---and we do look forward to receiving even more outstanding submissions. Dates, details, call for papers, etc will be forthcoming over the next few months.

Mike Hommey: signal() doubly considered harmful

When you want to set signal handlers on UNIX systems, the typical choice is to use signal (specified in C89, C99 and POSIX.1-2001) or sigaction (specified in POSIX.1-2001 and System V r4). Quoting the signal manual page:
The only portable use of signal() is to set a signal s disposition to SIG_DFL or SIG_IGN. The semantics when using signal() to establish a signal handler vary across systems (and POSIX.1 explicitly permits this variation); do not use it for this purpose. POSIX.1 solved the portability mess by specifying sigaction(2), which provides explicit control of the semantics when a signal handler is invoked; use that interface instead of signal().
Then it goes on about the UNIX vs BSD semantics, and how they affect signal delivery, which essentially is the main reason why one would want to stop using signal and use sigaction instead, with specifically chosen flags. But this is not really what I wanted to talk about here. One of the uses of signal or sigaction is to temporarily set a signal handler and restore the old signal handler once the job is done. Notwithstanding the fact that it s a pretty horrible thing to do in a multi-threaded program, it s also a horrible thing to do at all with signal if sigaction is used. The core of the problem is the following: the information you get from signal() about the old signal handler is missing all the important pieces about it if it was originally set with sigaction(), namely, flags, masks and restorer. So if you do use signal() to temporarily set a signal handler and then restore the previous signal handler, you risk resetting flags, masks and restorer. The first awful thing this means is the previous signal handler might be expecting three arguments, only one of which will be valid when it s invoked. Unexpected things can also happen with the lack of expected flags or masks. This is why you ll see horrible workarounds like this or that. In short, if you do use signal() to temporarily set a signal handler and then restore the previous signal handler, you re doing it wrong. And if you do that in a system library or driver, thank you for screwing things up. I m looking at you libsc-a3xx.so.

Petter Reinholdtsen: How to install Linux on a Packard Bell Easynote LV preinstalled with Windows 8

Two days ago, I asked how I could install Linux on a Packard Bell EasyNote LV computer preinstalled with Windows 8. I found a solution, but am horrified with the obstacles put in the way of Linux users on a laptop with UEFI and Windows 8. I never found out if the cause of my problems were the use of UEFI secure booting or fast boot. I suspect fast boot was the problem, causing the firmware to boot directly from HD without considering any key presses and alternative devices, but do not know UEFI settings enough to tell. There is no way to install Linux on the machine in question without opening the box and disconnecting the hard drive! This is as far as I can tell, the only way to get access to the firmware setup menu without accepting the Windows 8 license agreement. I am told (and found description on how to) that it is possible to configure the firmware setup once booted into Windows 8. But as I believe the terms of that agreement are completely unacceptable, accepting the license was never an alternative. I do not enter agreements I do not intend to follow. I feared I had to return the laptops and ask for a refund, and waste many hours on this, but luckily there was a way to get it to work. But I would not recommend it to anyone planning to run Linux on it, and I have become sceptical to Windows 8 certified laptops. Is this the way Linux will be forced out of the market place, by making it close to impossible for "normal" users to install Linux without accepting the Microsoft Windows license terms? Or at least not without risking to loose the warranty? I've updated the Linux Laptop wiki page for Packard Bell EasyNote LV, to ensure the next person do not have to struggle as much as I did to get Linux into the machine. Thanks to Bob Rosbag, Florian Weimer, Philipp Kern, Ben Hutching, Michael Tokarev and others for feedback and ideas.

Daniel Pocock: Upstream packaging and Debian: Drupal third-party libraries API

Many large, successful, de-centralised software projects have a suite of their own packages maintained with their own platform-independent tools. Typical examples are Drupal's collection of module and theme packages, the R Project packages (CRAN) and the Central Repository for Maven packages (Java). In the case of Drupal:
  • Debian only really packages the core Drupal system and not the modules and themes
  • Gunnar's dh-make-drupal can easily Debianize many of the modules from Drupal's collection
  • Drupal has strict rules about the contents of packages distributed from their official collection. In particular, they must all be 100% compatible with the GPL v2 or later.
  • Another rule that is particularly exciting for Debian is that Drupal's hosted modules may not duplicate code (particularly JavaScript) from other projects/repositories: everyone installing a module must download and unpack the required JavaScript, often adding many steps to the module installation.
This is a particular opportunity for Debian to demonstrate it's strengths. Debian's pkg-javascript team has been busy packaging a huge collection of popular JavaScript libraries in a 100% free manner that guarantees adherence to the Debian Free Software Guidelines. This means that they have already done a lot of the groundwork to weed out minified (obfuscated) code that isn't accompanied by readable source code and ensure that there is a mechanism for conveniently and promptly distributing security fixes. The Drupal Libraries API module has now been packaged for Debian and is available in the unstable archive. The goal of this package is to facilitate the automated use of Debian's high-quality JavaScript packages to fulfill the dependency requirements of Drupal modules. Exact details of how these components fit together is currently explained in the README.Debian file distributed in the package. People packaging JavaScript for use by Drupal modules need to consider making a small glue' package to help Drupal's Libraries API discover the JavaScript. In many cases the glue package needs to do little more than creating a symlink from /usr/share/javascript to /usr/share/drupal7/libraries - this process can also potentially be automated by a future version of dh-make-drupal

26 May 2013

Craig Small: props-ng 3.3.8

Procps-ng 3.38 was released yesterday. Besides the bug fixes,there have been two main enhancements: NUMA and systemd support. top comes with NUMA support which is a soft dependency, meaning that if compilied with the support, top will try to link at runtime to libnuma. The new key presses are 2 and 3 which will show the Nodes or more detail about a specific node respectively. ps has two new output columns; unit and uunit. These permit ps to display the systemd unit and user unit fields. The systemd support is a
hard dependency which is enabled with with-systemd procps-ng is available from gitorious or sourceforge:

Gregor Herrmann: RC bugs 2013/21

like last week, I was working on the preparation of the Perl 5.18 transition. besides that I also uploaded some RC bug fixes, mostly by taking patches that came from Ubuntu (kudos!): as a side note (or better: question): why are the bugs for the upcoming Apache 2.4 and openjdk-7 transitions classified as 'serious', instead of as 'important', like the Perl 5.18 ones?

Richard Hartmann: Full House

Even though I only flew to and from Berlin for a single day due to time constraints at work, my first attendance at LinuxTag was a nice experience. Everything was organized rather well and people seemed to be having fun. The event itself has a decidedly commercial tone to it with lots of actual companies present both at booths and during talks. Also, there was a distinct lack of anything resembling a hackerspace, i.e. chairs, tables and power outlets. My talk has been received rather well, having both the highest attendance of all talks I went to during LinuxTag and the highest attendance of all of my own talks to date. When I began there were 105 people in the room excluding myself. During the talk there was a constant trickle of people entering which led to several people standing at the back and others sitting on the ground. With a grand total of two people leaving early, I guesstimate 130+ people have attended. As you can see on the photo below the percentage of attendees who are looking into their laptops/cell phones and not really paying attention was, once again, very low: Audience during my 'Gitify your life' talk at LinuxTag 2013 Now if only I could find a way to track how many of them did actually sat down afterwards and looked at the tools presented... Sadly, there was no video recording of the talk, but I may be able to get my hands at the video material recorded during OSD2013.

Andrew Pollock: [life] Maker Fair 2013 virtual trip report

The Maker Faire is one of the Bay Area things that I'll really miss. Zoe had a ball last year (for weeks afterwards every outing was "Maker Faire!" regardless of what or where it was) Last year I didn't really get to cover it very well, so I ended up doing a bit of a virtual tour via the exhibitor list on their website, and so this year I thought I'd be there in spirit by doing the same thing again. Here's my picks:

25 May 2013

Jonas Smedegaard: FreedomBox - Helps You Stay Free!

On saturday 25. of May I gave a talk about FreedomBox at the "Claim back your device" track of LinuxTag in Berlin. LinuxTag is a fairly big annual conference about (yes, you guessed right) Linux and related topics. The FreedomBox is a project to help non-geeks care about their personal privacy when online, same ways as geeks have practiced for a decade or more. Concrete goal is to design a small, cheap physical box similar to an internet gateway or wifi router but with three additions: "Privacy" is commonly mistaken as "secrecy": Privacy is to keep you in control of your information, so that sharing or keeping to yourself is truly your own choice. Thanks a lot especially to Matthias Kirschner for inviting me as a speaker! Slides (sources) for the event.

Michael Stapelberg: Cloning git-buildpackage repositories

Whenever I want to work on some package, I usually clone its git repository, make my changes, then push and upload the Debian package. I don t keep those repositories around in order to avoid cruft and also to have a 100% clean, up-to-date setup whenever I start working on something. Everytime I clone such a repository, I struggle with the setup. For example, I usually forget the --pristine-tar flag for gbp-clone. Also, I usually forget to push other branches (working on debian , forgetting upstream ) and, even more often, I forget pushing tags. I spent some time on this and figured out that one can use the following to make --pristine-tar the default:
cat >> ~/.gbp.conf <EOF
[DEFAULT]
pristine-tar = True
EOF
Avoiding my other pain points is not so easy apparently, so I wrote a little shell function (only tested with zsh!) which uses debcheckout to get the git URL, gbp-clone to actually clone it and a few git config calls to make me able to just git push when I am done and not worry about anything:
# Clones the git sources of a Debian package
# needs debcheckout from devscripts and gbp-clone from git-buildpackage
function d-clone()  
    local package=$1
    if debcheckout --print $package >/dev/null
    then
        set -- $(debcheckout --print $package)
        if [ "$1" != "git" ]
        then
            echo "$package does not use git, but $1 instead."
            return
        fi
        echo "cloning $2"
        gbp-clone $2   return
        # Change to the newest git repository
        cd $(dirname $(ls -1td */.git   head -1))   return
        # This tells git to push all branches at once,
        # i.e. if you changed upstream and debian (after git-import-orig),
        # both upstream and debian will be pushed when running  git push .
        git config push.default matching   return
        # This tells git to push tags automatically,
        # so you don t have to use  git push; git push --tags .
        git config --add remote.origin.push "+refs/heads/*:refs/remotes/origin/*"   return
        git config --add remote.origin.push "+refs/tags/*:refs/tags/*"   return
        echo "d-clone set up everything successfully."
    else
        echo "debcheckout $package failed. Is $package missing Vcs tags?"
    fi
 
With that function, starting work on a package becomes as easy as d-clone golang-doc .

Petter Reinholdtsen: How can I install Linux on a Packard Bell Easynote LV preinstalled with Windows 8?

I've run into quite a problem the last few days. I bought three new laptops for my parents and a few others. I bought Packard Bell Easynote LV to run Kubuntu on and use as their home computer. But I am completely unable to figure out how to install Linux on it. The computer is preinstalled with Windows 8, and I suspect it uses UEFI instead of a BIOS to boot. The problem is that I am unable to get it to PXE boot, and unable to get it to boot the Linux installer from my USB stick. I have yet to try the DVD install, and still hope it will work. when I turn on the computer, there is no information on what buttons to press to get the normal boot menu. I expect to get some boot menu to select PXE or USB stick booting. When booting, it first ask for the language to use, then for some regional settings, and finally if I will accept the Windows 8 terms of use. As these terms are completely unacceptable to me, I have no other choice but to turn off the computer and try again to get it to boot the Linux installer. I have gathered my findings so far on a Linlap page about the Packard Bell EasyNote LV model. If you have any idea how to get Linux installed on this machine, please get in touch or update that wiki page. If I can't find a way to install Linux, I will have to return the laptop to the seller and find another machine for my parents. I wonder, is this the way Linux will be forced out of the market using UEFI and "secure boot" by making it impossible to install Linux on new Laptops?

Joachim Breitner: My first CTAN package: Typesetting Continued Equalities

I recently had a TeX itch to scratch: I am working on a paper that has several multi-line continued equalities where, depending on the size of the expressions and the explanations of each step, I chose among a few layouts. But implementing the layout together with the actual code was inefficient, as switching the layout involved changing every line. So I came up with the package conteq which allows you to typeset continued equations in a simple declarative manner, e.g.
\begin conteq 
  e^ \pi\cdot i  \\
= -1               & Euler's formula \\
< 0                & this is an inequality \\ 
< \sqrt 3 \\
= \int e^ -x^2  dx & this is due to Gauss.
\end conteq 
and allows you to select the layout via an parameter to the environment, or globally, or either. Also, the styling of the explanations (italics? wrapped in ... ?) can be configured simply by redefining a macro. For more details and an overview of the various styles, check out the package documentation.
If this sounds useful to you, fetch the conteq package from CTAN. But beware: It uses quite current features of the expl3 package, so you need at least the version from 2012/07/02 (TeXLive 2013 is good). You can file bug reports at the GitHub mirror of my git repository.
I d like to thank Bruno Le Floch and Joseph Wright, who made me aware of expl3 on various TeX Exchange questions. I haven t heard of this term before, but supposedly it is the right translation for the German word Gleichungskette .

Gunnar Wolf: A little extra value in 3.0 (quilt) format

Wouter still does not like the 3.0 (quilt) packaging format. And as he writes on his blog, I shall answer on mine. And what if one of the blogs becomes unreachable with time? Aha! That's one of the weaknesses, Wouter, on yuor closing comment:
I have all my packages stored in git with a proper Vcs-Git: header; if people really want to look at individual patches, they can just use debcheckout, kthxbye.
I am aware this would not be so much of an argument, or so much of a change. But the way I view a shipped package is that it should, by itself, be as a snapshot with its whole, full description. Say that three years from now Apple has scrubbed your brain and you went to work with them. And you decided to pull all of your non-iOS repositories. They have convinced you working for Debian is bad for mankind. So you erase all of your Git repos, including those in Alioth or whatever. But Debian Wheezy has some of your packages. And three years from now, I decided to be the maintainer. So, having fully commented and individually marked patches is a sort-of-way to avoid a situation akin to the tentacles of evil. Now, it's not that I'm criticizing your workflow. I have sen many ways to manage patches in quite a natural way, and I undestand it might be way easier when dealing with complex packages (FWIW I usually deal with very little complexity). Still, it is an argument.

24 May 2013

Bits from Debian: Security updates for the X Window System client libraries

If you see a bunch of X.org packages upgrades pending in your Squeeze or brand new Wheezy system, don't panic! Ilja van Sprundel, a security researcher from IOActive, has discovered a large number of issues in the various X client libraries and he has worked with X.Org's security team to analyze, confirm, and fix these issues. You can find more information in the security avisory from X.org. The Debian Security and X.org teams have quickly updated all the affected packages in Squeeze and Wheezy. You can see the full list of updates in the debian-security-announce mailing list archives.

Next.

Previous.