Search Results: "reg"

10 December 2014

Gregor Herrmann: GDAC 2014/10

debian has a bigger role than "just" providing a free operating system to our users (& derivatives), it's also an important player in the free software world at large. a recent indication of this is the composition of the FSF's High Priority Projects Committee: if I'm counting correctly, there are two active & one former DDs listed as members; oh, & the contact person is yet another DD :) great to see many debianistas active all around!
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

Clint Adams: In Uganda, a popular marbles game is called dool.

Sophie stood before me. I'm leaving with that guy, she gestured. Yes, I thought that would happen, I chuckled. She hugged me. The guy, whose name we managed to never utter, did not hug me, though he usually does. They went home together. That was the last time I saw Sophie. The rest of us sat down, finished our drinks, and split up. I went with Sophie's ex-girlfriend and the guy who sometimes serves as her ironic beard. They smoked their disgusting light cigarettes, the kind with very little tobacco but lots of horrible chemicals that make me cough and hopefully fail to give me lung cancer, because watching someone else die of that was excruciating enough. So we get to our next destination and there is a Peruvian girl sitting on a stool and shopping for shoes on her phone. I am fascinated. Phone app developers had told me that people actually did this but I thought it was just wishful thinking on their part. The Peruvian girl, who is named something that sounds like it was uttered accidentally by Tommy Gnosis, complains to Sophie's ex-girlfriend that some guy keeps harassing her. We instinctively form a human barrier to shield her from this alleged transgressor, who, it turns out, is the pompous drug dealer with whom Sophie's ex-girlfriend is just about to conduct business. I'll be right back, she says. Hit on her. What Why I shout after her. There is no response. Sophie's ex-girlfriend and the drug dealer return from the darkness, having swapped possessions. The drug dealer is a blowhard and proceeds to regale us with stories so little interest to me that I can't even remember what they were about, but as drug dealers are wont to do, he abuses the power of his possession to maintain the delusion that people would tolerate his presence even if he didn't have illegal commodities to sell them. When the beard and Sophie's ex-girlfriend go out for a smoke break, I went home.

Chris Lamb: Starting IPython automatically from zsh

Instead of a calculator, I tend to use IPython for those quotidian bits of "mental" arithmetic:
In  [1]: 17 * 22.2
Out [1]: 377.4
However, I often forget to actually start IPython, resulting in me running the following in my shell:
$ 17 * 22.2
zsh: command not found: 17
Whilst I could learn do this maths within Zsh itself, I would prefer to dump myself into IPython instead being able to use "_" and Python modules generally is just too useful. After following this pattern too many times, I put together the following snippet that will detect whether I have prematurely attempted a calculation inside zsh and pretend that I ran it in IPython all along:
zmodload zsh/pcre
math_regex='^[\d\-][\d\.\s\+\*\/\-]*$'
function math_precmd()  
    if [ "$ ? " = 0 ]
    then
        return
    fi
    if [ -z "$ math_command " ]
    then
        return
    fi
    if whence -- "$math_command" 2>&1 >/dev/null
    then
        return
    fi
    if [ "$ math_command " -pcre-match "$ math_regex " ]
    then
        echo
        ipython -i -c "_=$ math_command ; print _"
    fi
 
function math_preexec()  
    typeset -g math_command="$ 1 "
 
typeset -ga precmd_functions
typeset -ga preexec_functions
precmd_functions+=math_precmd
preexec_functions+=math_preexec
For example:
lamby@seriouscat:~% 17 * 22.2
zsh: command not found: 17
377.4
In  [1]: _ + 1
Out [1]: 378.4
(Canonical version from my zshrc.d)

Dirk Eddelbuettel: Wilco!!

Wilco at The Riviera With a bit of luck due to a collegue having a spare ticket, I managed to make it to an awesome Wilco show at The Riviera in Uptown. This concert was part of a set a six shows. Tweedy and the band were fast, and loose, and wonderful, and totally beloved by the home crowd. An truly outstanding show, and a great evening. Also: I should get out more often. Last blog entry about Wilco was from 2005. Ouch.

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

Dirk Eddelbuettel: RcppAnnoy 0.0.4

A few weeks ago, RcppAnnoy had its initial release 0.0.2 and subsequent update in release 0.0.3. The latter brought Windows support, thanks to a neat pull request by Qiang Kou. RcppAnnoy wraps the small, fast, and lightweight C++ template header library Annoy written by Erik Bernhardsson for use at Spotify. RcppAnnoy uses Rcpp Modules to offer the exact same functionality as the Python module wrapped around Annoy. In the 0.0.3 release, I overlooked one thing: that with builds on Windows, we would also get builds against what CRAN calls R-oldrel: the previous release, which cannot turn on C++11 via the simple CXX_STD = CXX11 declaration in src/Makevars (and which we need because use of Boost brings in long long which R can only cope with under C++11 ...). So this new release 0.0.4 does nothing more than add a constraint in a Depends: R (>= 3.1.0) to avoid builds not being able to turn on C++11. Courtesy of CRANberries, there is also a diffstat report for this release. More detailed information is on the RcppAnnoy page 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.

9 December 2014

Gregor Herrmann: GDAC 2014/9

today, I again had a pleasant experience around an RC bug, featuring a diligent patch submitter, & a maintainer showing his appreciation for the help. motivating!
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

Wouter Verhelst: Playing with ExtreMon

Munin is a great tool. If you can script it, you can monitor it with munin. Unfortunately, however, munin is slow; that is, it will take snapshots once every five minutes, and not look at systems in between. If you have a short load spike that takes just a few seconds, chances are pretty high munin missed it. It also comes with a great webinterfacefrontendthing that allows you to dig deep in the history of what you've been monitoring. By the time munin tells you that your Kerberos KDCs are all down, you've probably had each of your users call you several times to tell you that they can't log in. You could use nagios or one of its brethren, but it takes about a minute before such tools will notice these things, too. Maybe use CollectD then? Rather than check once every several minutes, CollectD will collect information every few seconds. Unfortunately, however, due to the performance requirements to accomplish that (without causing undue server load), writing scripts for CollectD is not as easy as it is for Munin. In addition, webinterfacefrontendthings aren't really part of the CollectD code (there are several, but most that I've looked at are lacking in some respect), so usually if you're using CollectD, you're missing out some. And collectd doesn't do the nagios thing of actually telling you when things go down. So what if you could see it when things go bad? At one customer, I came in contact with Frank, who wrote ExtreMon, an amazing tool that allows you to visualize the CollectD output as things are happening, in a full-screen fully customizable visualization of the data. The problem is that ExtreMon is rather... complex to set up. When I tried to talk Frank into helping me getting things set up for myself so I could play with it, I got a reply along the lines of...
well, extremon requires a lot of work right now... I really want to fix foo and bar and quux before I start documenting things. Oh, and there's also that part which is a dead end, really. Ask me in a few months?
which is fair enough (I can't argue with some things being suboptimal), but the code exists, and (as I can see every day at $CUSTOMER) actually works. So I decided to just figure it out by myself. After all, it's free software, so if it doesn't work I can just read the censored code. As the manual explains, ExtreMon is a plugin-based system; plugins can add information to the "coven", read information from it, or both. A typical setup will run several of them; e.g., you'd have the from_collectd plugin (which parses the binary network protocol used by collectd) to get raw data into the coven; you'd run several aggregator plugins (which take that raw data and interpret it, allowing you do express things along the lines of "if the system's load gets above X, set load.status to warning"; and you'd run at least one output plugin so that you can actually see the damn data somewhere. While setting up ExtreMon as is isn't as easy as one would like, I did manage to get it to work. Here's what I had to do. You will need: First, we clone the ExtreMon git repository:
git clone https://github.com/m4rienf/ExtreMon.git extremon
cd extremon
There's a README there which explains the bare necessities on getting the coven to work. Read it. Do what it says. It's not wrong. It's not entirely complete, though; it fails to mention that you need to Make sure the dump.py script outputs something from collectd. You'll know when it shows something not containing "plugin" or "plugins" in the name. If it doesn't, fiddle with the #x3. lines at the top of the from_collectd file until it does. Note that ExtreMon uses inotify to detect whether a plugin has been added to or modified in its plugins directory; so you don't need to do anything special when updating things. Next, we build the java libraries (which we'll need for the display thing later on):
cd java/extremon
mvn install
cd ../client/
mvn install
This will download half the Internet, build some java sources, and drop the precompiled .jar files in your $HOME/.m2/repository. We'll now build the display frontend. This is maintained in a separate repository:
cd ../..
git clone https://github.com/m4rienf/ExtreMon-Display.git display
cd display
mvn install
This will download the other half of the Internet, and then fail, because Frank forgot to add a few repositories. Patch (and push request) on github With that patch, it will build, but things will still fail when trying to sign a .jar file. I know of four ways on how to fix that particular problem:
  1. Add your passphrase for your java keystore, in cleartext, to the pom.xml file. This is a terrible idea.
  2. Pass your passphrase to maven, in cleartext, by using some command line flags. This is not much better.
  3. Ensure you use the maven-jarsigner-plugin 1.3.something or above, and figure out how the maven encrypted passphrase store thing works. I failed at that.
  4. Give up on trying to have maven sign your jar file, and do it manually. It's not that hard, after all.
If you're going with 1 through 3, you're on your own. For the last option, however, here's what you do. First, you need a key:
keytool -genkeypair -alias extremontest
after you enter all the information that keytool will ask for, it will generate a self-signed code signing certificate, valid for six months, called extremontest. Producing a code signing certificate with longer validity and/or one which is signed by an actual CA is left as an exercise to the reader. Now, we will sign the .jar file:
jarsigner target/extremon-console-1.0-SNAPSHOT.jar extremontest
There. Who needs help from the internet to sign a .jar file? Well, apart from this blog post, of course. You will now want to copy your freshly-signed .jar file to a location served by HTTPS. Yes, HTTPS, not HTTP; ExtreMon-Display will fail on plain HTTP sites. Download this SVG file, and open it in an editor. Find all references to be.grep as well as those to barbershop and replace them with your own prefix and hostname. Store it along with the .jar file in a useful directory. Download this JNLP file, and store it on the same location (or you might want to actually open it with "javaws" to see the very basic animated idleness of my system). Open it in an editor, and replace any references to barbershop.grep.be by the location where you've stored your signed .jar file. Add the chalice_in_http plugin from the plugins directory. Make sure to configure it correctly (by way of its first few comment lines) so that its input and output filters are set up right. Add the configuration snippet in section 2.1.3 of the manual (or something functionally equivalent) to your webserver's configuration. Make sure to have authentication chalice_in_http is an input mechanism. Add the chalice_out_http plugin from the plugins directory. Make sure to configure it correctly (by way of its first few comment lines) so that its input and output filters are set up right. Add the configuration snippet in section 2.2.1 of the manual (or something functionally equivalent) to your webserver's configuration. Authentication isn't strictly required for the output plugin, but you might wish for it anyway if you care whether the whole internet can see your monitoring. Now run javaws https://url/x3console.jnlp to start Extremon-Display. At this point, I got stuck for several hours. Whenever I tried to run x3mon, this java webstart thing would tell me simply that things failed. When clicking on the "Details" button, I would find an error message along the lines of "Could not connect (name must not be null)". It would appear that the Java people believe this to be a proper error message for a fairly large number of constraints, all of which are slightly related to TLS connectivity. No, it's not the keystore. No, it's not an API issue, either. Or any of the loads of other rabbit holes that I dug myself in. Instead, you should simply make sure you have Server Name Indication enabled. If you don't, the defaults in Java will cause it to refuse to even try to talk to your webserver. The ExtreMon github repository comes with a bunch of extra plugins; some are special-case for the place where I first learned about it (and should therefore probably be considered "examples"), others are general-purpose plugins which implement things like "is the system load within reasonable limits". Be sure to check them out. Note also that while you'll probably be getting most of your data from CollectD, you don't actually need to do that; you can write your own plugins, completely bypassing collectd. Indeed, the from_collectd thing we talked about earlier is, simply, also a plugin. At $CUSTOMER, for instance, we have one plugin which simply downloads a file every so often and checks it against a checksum, to verify that a particular piece of nonlinear software hasn't gone astray yet again. That doesn't need collectd. The example above will get you a small white bar, the width of which is defined by the cpu "idle" statistic, as reported by CollectD. You probably want more. The manual (chapter 4, specifically) explains how to do that. Unfortunately, in order for things to work right, you need to pretty much manually create an SVG file with a fairly strict structure. This is the one thing which Frank tells me is a dead end and needs to be pretty much rewritten. If you don't feel like spending several days manually drawing a schematic representation of your network, you probably want to wait until Frank's finished. If you don't mind, or if you're like me and you're impatient, you'll be happy to know that you can use inkscape to make the SVG file. You'll just have to use dialog behind ctrl+shift+X. A lot. Once you've done that though, you can see when your server is down. Like, now. Before your customers call you.

Thorsten Glaser: The colon in the shell: corrigenda

Bernhard s article on Pl net Debian about the colon command in the shell could use a clarification and a security-relevant correcture. There is, indeed, no difference between the : and true built-in commands. St phane Chazelas points out that writing : $ VARNAME:=default is bad, : "$ VARNAME:=default " is correct. Reason: someone could preset $VARNAME with, for example, /*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/* which will exhaust during globbing. Besides that, the article is good. Thanks Bernhard for posting it! PS: I sometimes use the colon as comment leader in the last line of a script or function, because it, unlike the octothorpe, sets $? to 0, which can be useful. Update: As jilles pointed out in IRC, colon ( : ) is a POSIX special built-in (most importantly, it keeps assignments), whereas true is a regular built-in utility.

8 December 2014

Gregor Herrmann: GDAC 2014/8

today, a pkg-perl member who was not very active for the last 2 or so years "re-appeared", & together we prepared & uploaded a new package. always good to see people coming back!
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

7 December 2014

Gregor Herrmann: GDAC 2014/7

creating a free operating system in general & fixing bugs in particular is a collaborative effort. today's example is bug report #766773 (& friends) which involved communication in the BTS & on IRC between the bug submitter, the maintainer of a related package, the release team, & me as a bug triager. & 2.5 hours later, another block for the jessie release is gone. thanks everybody for yet another pleasant collaboration experience!
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

Hideki Yamane: security.debian.org for Asia region

Thanks to DSAs' deployment, now there is security.debian.org mirror in Japan. It means users who live in Asia/Pacific region are not annoyed with slow download speed for stable security update - anymore :)

New security.debian.org mirror is kindly hosted by Sakura Internet, Inc. ( ) as well as debian-mirror.sakura.ne.jp mirror server in Ishikari, Hokkaido ( ).


Kudos to Sakura Internet! (twitter: CEO Kunihiro Tanaka and PR)

note: it's not for Pacific region, only Asia region. Thanks to Paul Wise for pointed out. But still good for our users :)

6 December 2014

Gregor Herrmann: GDAC 2014/6

positive feedback is motivating (probably not only) for me. a recent example showing that our work on creating a great operating system is appreciated was sent to the debian-project list yesterday. thanks!
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

5 December 2014

Gregor Herrmann: GDAC 2014/5

today I had a short chat with a fellow DD living in a neighbouring country. nothing spectacular in itself; but it reminded me again that debian is more than creating an operating system together for me it's also about a couple of friendships that grow out of it & which are dear to me.
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

Iustin Pop: Jump!

Jump!!! What Why At the end of November, we had a team offsite planned, with lots of fun and exciting activities in a somewhat exotic location. I was quite looking forward to it, when - less than two weeks before the event - a colleague asked if anyone is interested in going skydiving as an extra activity. Without thinking too much, I said "yes" immediately, because: a) I've never done it before, and b) it sounded really cool! Other people said yes as well, so we were set up to have a really good time! Of course, as the time counted down and we were approaching the offsite, I was thinking: OK, this sounds cool, but: will I be fine? do I have altitude sickness? All kinds of such, rather logistical, questions. In order to not think too much, I did exactly zero research on the topic (all mentions of Wikipedia above are from post-fact reading). So, we went on the offsite - which was itself cool - and then, on the last day, right before going back, the skydive event! How it went The weather on the day of the jump was nice, the sky not perfectly clear, just a bit of small clouds and some haze. We waited for our turn, got the instruction for what to do (and not to do!), got hooked into the harness, prepared everything, and then boarded the plane; it needed only a very short run before taking off the ground. It took around ten minutes or so to get to the jump altitude, which I spent partially looking forward to it, partially trying to calm the various emotions I had - a very interesting mix. It was actually annoying just having to wait and wait the ten long minutes, I wished that we actually get to the jumping altitude faster. The altimeter on the instructor's hand was showing 4'000, then 4'100, 4'150, then he reminded me again what I need to do (or rather, not to do), and then - people were already jumping from the plane! I was third from our team to jump, and I had the opportunity to see how people were not simply "exiting" the plane, but rather - exiting and then immediately disappearing from view! Finally we were on the edge of the door, a push and then - I'm looking down, more than two and a half miles of nothing between me and the ground. Just air and the thought - "Why did I do this"? - as I start falling. For the first around ten seconds, it's actually a free fall, gaining speed almost at standard acceleration, and the result - Weightlessness - it's the weirdest feeling ever: all your organs floating in your body, no compression or torsion forces. Much more weird a roller-coaster that never ends; then most I had on roller-coasters was around one second of such acceleration, and you still are in contact with the chair or the restraints, whereas this long fall was very confusing for my brain - it felt somewhat like when you're tripping and you need to do something to regain balance, except in sky-diving you can't do anything, of course. There's nothing to grab, nothing to hold on, and you keep falling. After ten long seconds we reached terminal velocity, phase 1 ends, and phase 2 begins, in which - while still falling - the friction with the air compensates exactly the earth's pull and one is falling at a constant speed and it's the most wonderful state ever. Like floating on the air, except that you're actually falling at almost 200kph, and yes, the closest feeling to flying, I guess. It doesn't hurt that you're no longer weightless, which means back to some level of normality. The location of the skydive was very beautiful: the blue ocean beneath, the blue sky above, somewhere to the side the beach, and the air filling the mouth and lungs without any effort is the only sign that I'm moving really fast. The way this whole thing feels is very alien if you never jumped before, but one gets accustomed to it quite fast - and that means I got too comfortable and excited and forgot the correct position to keep my legs in, the instructor reminded me, and as I put my legs back in the correct position, which is (among others) with the soles of the feet pointing up, I felt again the air going strongly into my shoes, and a thought crossed my mind: what if I the air blows off one of my shoes (the right one, more precisely) and I lose it? How do I get to the airport for the trip back? Will I look suspicious at the security check? The banality of this thought, given that I was still up in the air somewhere and travelling quite fast, was so comical that I started laughing And then, an unexpected noise, the chute opens, and I feel like someone is pulling me strongly up. Of course nobody is pulling "up", I'm just slowing down very fast on this final phase (Wikipedia says: 3 to 4g). And then, once at the new terminal velocity, the lack of wind noise and the quietness of everything around gives a different kind of awesome - more majestic and serene this time, rather than the adrenaline-filled moments before. Because one is still up and the beach looks small, you actually feel that you're suspended in the air, almost frozen. Of course, that feeling goes away quickly when the instructor start telling me to pull the strings, and we enter a fast spin - so fast that my body is almost horizontal again - a reminder that we're still in the air, going somewhat fast, and not in "normal" conditions. I'm again reminded of the speed once we get closer to the earth, the people on the beach start to get bigger fast, and now we're gliding over the beach and finally land in the sand. The adventure is over, but I'm still pumped up and my body is still full of adrenaline, and I feel like you've just been in heaven - which is true, for some definitions of . The first thing I realise is that the earth is very solid. And not moving at all. Everything is very very slow which is both good and bad. My body is confused at the very fast sequence of events, and why did everything stop?? Conclusion I learned all about the terminal velocity, how fast you get there, and so on a day later, from Wikipedia and other sources. It helped explain and clarify the things I experienced during the dive, because there in the air I was quite confused (and my body even more so). Knowing this in advance would have spoiled the surprise, but on the other hand would have allowed me to enjoy the experience slightly better. Looking back, I can say a few of things. First, it was really awesome - not what I was expecting, much more awesome (in the real sense of awe) than I thought, but also not as easy or trivial as I believed from just seeing videos of people "floating" during their dive. Yep, worth doing, and hard to actually put in words (I tried to, but I think this rambling is more confusing than helping). Phase one was too long (and a bit scary), phase two was too short (and the best thing), phase three was relaxing (and just the right length). I also wonder how it is to jump alone - without the complicated and heavy harness, without an instructor, just you up there. Oh, and the parachute. And the reserve parachute , of course. Point is, this was awesome, but I was mostly a passive spectator, so I wonder what it feels like to be actually in control (as much as one can be, falling down) and responsible. And finally, as we left the offsite location just a couple of hours after the skydive, and we had a 4 hours flight back, I couldn't believe myself how slow everything was. I never experienced quite such a thing, I was sitting in this normal airplane flying high and fast, but for me everything was going in slow motion and I was bored out of my mind. Adrenaline aftershock or something like that? Also interesting!

Michal Čihař: Weblate 2.1

Weblate 2.1 has been released today. It comes with native Mercurial support, user interface cleanup and various other fixes. Full list of changes for 2.1: You can find more information about Weblate on http://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://hosted.weblate.org/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far!

Filed under: English phpMyAdmin SUSE Weblate 0 comments Flattr this!

Enrico Zini: the-smell-of-email

The smell of email This was written in response to a message with a list of demotivating behaviours in email interactions, like fingerpointing, aggressiveness, resistance when being called out for misbehaving, public humiliation for mistakes, and so on There are times when I stumble on an instance of the set of things that were mentioned, and I think "ok, today I feel like doing some paid work rather than working on Debian". If another day I wake up deciding to enjoy working on Debian, which I greatly do, I try and make sure that I can focus on bits of Debian where I don't stumble on any instances of the set of things that were mentioned. Then I stumble on Gregor's GDAC and I feel like I'd happily lose one day of pay right now, and have fun with Debian. I feel like Debian is this big open kitchen populated by a lot of people: I have fun cooking and tring out the food. I have fun being around people who cook and try out the food. The fun in the kitchen seems to be correlated to several things, one of which is that it seems to be inversely proportional to the stink. I find this metaphore interesting, and I will start thinking about the smell of a mailing list post. I expect it should put posts into perspective, I expect I will develop an instinct for it, so that I won't give a stinky post the same importance of a post that smells of food. I also expect that the more I learn to tell the smell of food from the smell of shit, the more I can help cleaning it, and the more I can help telling people who repeatedly contribute to the stink to please try cooking instead, or failing that, just try and stay out of the kitchen.

4 December 2014

Gregor Herrmann: GDAC 2014/4

I'm reading planet debian since many years, & I still enjoy it. I like the mixture of personal thoughts/stories & insightful technical tips. today's recommendation: Don't ask your questions in private. very much agreed.
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

3 December 2014

Michael Stapelberg: Announcing the new Debian Code Search Instant

For the last few months, I have been working on a new version of Debian Code Search, and today it s going live! I call it Debian Code Search Instant, for multiple reasons, see below. A lot faster The new Debian Code Search is still hosted by Rackspace (thank you!), but our new architecture finally allows us to use their Performance Cloud Servers hardware generation. The old code search architecture was split across 5 different servers, however the search itself was only performed on a single machine with a network attached block volume backed by SSD. The new Code Search spreads out both the trigram index and the source code onto 6 different servers, and thanks to the new hardware generation, we have a locally connected SSD drive in each of them. So, we now get more than 6 times the IOPS we ve had before, at much lower latency :). Grouping by Debian source package The first feature request we ever got for Code Search was to group results by Debian source package. I ve tried tackling that before, but it s a pretty hard problem. With the new architecture and capacity, this finally becomes feasible. After your query completes, there is a checkbox called Group search results by Debian source package . Enable it, and you ll get neatly grouped results. For each package, there is a link at the bottom to refine the search to only consider that package. In case you are more interested in the full list of packages, for example because you are doing large-scale changes across Debian, that s also possible: Click on the symbol right next to the Filter by package list, and a curl command will be revealed with which you can download the full list of packages. Expensive queries (with lots of results) now possible Previously, we had a 60 second timeout during which queries must complete. This timeout has been completely lifted, and long-running queries with tons and tons of results are now possible. We kindly ask you to not abuse this feature it s not very exciting to play with complexity explosion in regular expression engines by preventing others from doing their work. If you re interested in that sort of analysis, go grab the source code and play with it on your own machine :). Instant results While your query is running, you will almost immediately see the top 10 results, even though the search may still take a while. This is useful to figure out if your regular expression matches what you thought it would, before having to wait until your 5 minute query is finished. Also, the new progress bar tells you how far the system is with your search. Instant indexing Previously, Code Search was deployed to a new set of machines from scratch every week in order to update the index. This was necessary because the performance would severely degrade while building the index, so we were temporarily running with twice the amount of machines until the new version was up. In the new architecture, we store an index for each source package and then merge these into one big index shard. This currently takes about 4 minutes with the code I wrote, but I m sure this can be made even faster if necessary. So, whenever new packages are uploaded to the Debian archive, we can just index the new version and trigger a merge. We get notifications about new package uploads from FedMsg. Packages that are not seen on FedMsg for some reason are backfilled every hour. The time between uploading a package and being able to find it in Debian Code Search therefore now ranges from a couple of minutes to about an hour, instead of about a week! New, beautiful User Interface Since we needed to rewrite the User Interface anyway thanks to the new architecture, we also spent some effort on making it modern, polished and beautiful. Smooth CSS animations make you aware of what s going on, and the search results look cleaner than ever. Conclusion At least to me, the new Debian Code Search seems like a significant improvement over the old one. I hope you enjoy the new features into which I put a lot of work. In case you have any feedback, I m happy to hear it (see the contact link at the bottom of every Code Search site).

Gregor Herrmann: GDAC 2014/3

as russ wrote some weeks ago in an excellent mail to debian-vote, upstreams are the raison d' tre for linux distributions. my experience in collaborating with upstream authors is mostly very positive, the most recent example from today being #728345. thanks to all upstream authors for their passion in writing software & sharing it. & for caring about it later as well!
this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

2 December 2014

Sven Hoexter: Out of the comfort zone: Backporting net-snmp from CentOS 7 to CentOS 5 and 6

Lately I faced the requirement to create a backport of net-snmp 5.7.2, which is part of CentOS 7, to a largely CentOS 5 and 6 based infrastructure. Due to some prior adventures in the rpm world I already knew about Mock (the Fedora equivalent to pbuilder). The easy part was the backporting to CentOS 6. Here the major objectiv is ripping out the newly added systemd support. That boils down to just ripping out a patch, removing a configure flag, some %post, %preun, %postun script snippets and the corresponding %install magic from the spec file. Builds fine but leaves us with the issue that the init script ships in a package net-snmp-sysvinit but the whole chkconfig registration magic is gone. I put that aside for a moment and moved on to CentOS 5. It did not even start to build.
  1. There is no tcp_wrappers-devel in CentOS 5.
  2. The perl libraries are in the main perl package and not in perl-devel.
  3. lm_sensors-devel is not at version 3.
I lowered the versioned build-dep on lm_sensors, disabled via a spec file toggle the tcp-wrapper support and changed the perl build-dep. This time it failed in the configure script due to DTLS support issues with the ancient openssl in CentOS 5. Decided to drop that one as well from the list of configure flags since we do not use it. Tried to build it again, now it failed somewhere down the road post compilation when assembling the package. Not cool. At that time we pushed a few other ideas back and forth. We found an isolated patch for net-snmp 5.6 that could fix our most pressing issue and someone had a look if that could be backported to CentOS 5 easily. Nope, internal structure of net-snmp changed a lot in between. So back to backporting. After staring long enough at the build log I could understand that the variable % RPM_BUILD_ROOT is empty in the CentOS 5 world. And indeed the BuildRoot stanza is also gone from the spec file. So I reintroduced that one and later even found documentation in the Fedora Wiki about this issue. If you know it it's easy to work around it, so I just defined it by hand:
BuildRoot: % _tmppath /% name -% version -% release -root
%global RPM_BUILD_ROOT % buildroot 
About ten minutes later I had a set of rpm files for CentOS 5. Tried to install it, failed due to a depedency on libmysqlclient15 which is part of the mysql package in CentOS 5. Yes, eight years back RedHat did not split off the lib packages and that would mean for us to install a mysql database on every system. So no, we won't do it and we just removed the mysql support. Left with only the init script setup missing I tried to be clever and failed miserable. Be warned, this would've also been a bad idea in the Debian world. Since we have the init script in a seperate binary package I thought I could just use something like
Requires: net-snmp-sysvinit
in the main net-snmp package and re-add the old %post, %preun and %postun magic. Of course that failed at install time for a good reason. In the second (desperate) try to work around it I tried something similar to "PreDepends"
Requires(post): net-snmp-sysvinit 
That works at install time but still breaks on a removal/update. So I think I did the right thing in the end (after reading some more documentation) and just added the scripts to the net-snmp-sysvinit package. It's just about adding the package name to the %post macro invocation. My initial plan included the wish to have one spec file that is usable to build on CentOS 5 and 6 but now I'm left with a number of special cases for CentOS 5. I already knew about the %if %endif conditional macro you can use in rpm spec files, so what was missing was a proper variable to base my decisions on. Every CentOS release ships with a "/etc/rpm/" directory that includes several macro file. Within those one can find the % rhel variable that defines an int we can use.
%if % rhel  <= 5
BuildRequires: perl
%else
BuildRequires: perl-devel
%endif
And finally I could build from one spec file a backport for CentOS 5 and 6. My diff against the CentOS 7 spec is at https://sven.stormbind.net/centos/netsnmp-bp-el56/net-snmp-backport.from_el7.diff Drawbacks of the resulting packages:
  1. No tcp-wrapper support, we don't care but that should be just another package name issue for the conditional Requires, simililar to the perl isssue.
  2. No mysql support. We do not care, one could change that and/or make it conditional or build against newer mysql releases where the -lib package is split.
  3. No DTLS support on CentOS 5. We do not care and that is not easy to fix.
  4. You've to install the net-snmp-sysvinit script to get back the usual setup you'd expect.
  5. We ripped out the systemd support, I did not investigate yet if it's possible to keep that included and just not enable it.
By now CentOS 5 is old. It's painful to backport to it. But it's still possible. Another strategy someone tried was packaging the current net-snmp upstream release based on the CentOS 5 spec file. That would've meant throwing away all 106 patches RedHat includes in that package at the moment and to depend on new upstream releases for your own security support. In case we start using CentOS 7 we would also diverge on the version of snmpd we use. So we decided to stick with the RedHat sources and keep the version consistent on our infrastructure even if we can not keep feature parity. After all the issues one encounters while backporting packages in the rpm world are similar to those in the dpkg world. Still it feels different if you're not familar with the toolchain. For example
  1. If you build a src.rpm with mock you've to copy it out of the result directory before you rebuild it with mock to create the binary package. Mock deletes everything from the result directory when starting a new build. So I guess parallel builds for the same chroot will not work.
  2. Depedencies on files instead of packages are a strange thing.
  3. How on earth do you maintain a patchset of over a hundred patches without something like quilt? I guess you always have to apply them in a for loop on your source directory and then you create a copy of that to implement your modifications and create another patch. I'm pretty sure eight years ago Fedora was far away from using git so I would rule out patch branches in a VCS for the moment. Not sure what they invented inside RedHat to keep track of it.

Next.

Previous.