Search Results: "ag"

9 November 2014

Antti-Juhani Kaijanaho: About to retire from Debian

I got involved with Debian development in, I think, 1998. In early 1999, I was accepted as a Debian developer. The next two or three years were a formative experience for me. I learned both software engineering and massively international collaboration; I also made two major contributions to Debian that are still around (of this, I am very proud). In consequence, being a Debian developer became a part of my identity. Even after my activity lessened more than a decade ago, after I no longer was a carefree student, it was very hard for me to let go. So I ve hung on. Until now. I created my 4096-bit GPG key (B00B474C) in 2010, but never got around to collecting signatures to it. I ve seen other people send me their key transition statements, but I have not signed any keys based on them. It just troubles me to endorse a better secured key based on the fact that I once verified a less secure key and I have a key signature chain to it. For this reason, I have not made any transition statements of my own. I ve been meaning to set up key signing meetings with Debian people in Finland. I never got around to that, either. That, my friends, was my wakeup call. If I can t be bothered to do that, what business do I have clinging on to my Debian identity? My conclusion is that there is none. Therefore, I will be retiring from Debian. This is not a formal notice; I will be doing the formal stuff (including disposing of my packages) separately in the appropriate forums in the near future. I agree with the sentiment that Joey Hess wrote elsewhere: It s become abundantly clear that this is no longer the project I originally joined . Unlike Joey, I think that is a good thing. Debian has grown, a lot. It s not perfect, but like my elementary-school teacher once said: A thing that is perfect was not made by people. Just remember to continue growing and getting better. And keep making the Universal Operating System. Thank you, all.

Enrico Zini: fun-and-sanity

Fun and Sanity in Debian A friend of mine recently asked: "is there anything happening in Debian besides systemd?" Of course there is. He asked it 2 days after the freeze, which happened in time, and with an amazingly low RC bug count. The most visible thing right now seems to be this endless init system argument, but there are fun and sane things in Debian. Many of them. I think someone should put the spotlight on them, and here's my attempt. Yesterday I set up a gobby document asking "What is now happening in Debian that is exciting, fun and sane?", and passed the link around the Cambridge Miniconf and some IRC channels. Here are a few quotations that I collected:
The armhf and arm64 ports have for me been wonderful and exciting, and were a great time for me to start getting involved. (Jon "Aardvark" Ward) We have a way of tracking random contributors, and as far as I know no other project has anything like it. (Enrico Zini) codesearch.debian.net is an incredibly important resource, not just for us but for the free software community at large. (Ben Hutchings) sources.debian.net is a very useful resource with lots of interested contributors, it received 10 OPW applicants (Stefano Zacchiroli) It has never been easier to work on new infrastructure project thanks to the awesome work of the DSA team. We have dozens of contribution opportunities outside of just plain packaging. (Rapha l Hertzog) The work on reproducible builds has achieved excellent results with 61.3% of packages being reproducible. (Paul Wise) Porting arm64 has been (peversely) great fun. It's remarkably morish and I like nothing more than a tedious argument with autoconf macros. Working with lots of enthusiastic people from other teams, helping getting the port set up and build has been great - thank you everybody. (Wookey)
And here are random exciting things that were listed:

Erich Schubert: GR vote on init coupling

Overregulation is bad, and the project is suffering from the recent Anti-Systemd hate campaigning.
There is nothing balanced about the original GR proposal. It is bullshit from a policy point of view (it means we must remove software from Debian that would not work with other inits, such as gnome-journal, by policy).At the same time, it uses manipulative language like "freedom to select a different init system" (as if this would otherwise be impossible) and "accidentally locked in". It is exactly this type of language and behavior which has made Debian quite poisonous the last months.
In fact, the GR pretty much says "I don't trust my fellow maintainers to do the right thing, therefore I want a new hammer to force my opinion on them". This is unacceptable in my opinion, and the GR will only demotivate contributors. Every Debian developer (I'm not talking about systemd upstream, but about Debian developers!) I've met would accept a patch that adds support for sysvinit to a package that currently doesn't. The proposed GR will not improve sysvinit support. It is a hammer to kick out software where upstream doesn't want to support sysvinit, but it won't magically add sysvinit support anywhere.
What some supporters of the GR may not have realized - it may as well backfire on them. Some packages that don't yet work with systemd would violate policy then, too... - in my opinion, it is much better to make the support on a "as good as possible, given available upstream support and patches" basis, instead of a "must" basis. The lock-in may come even faster if we make init system support mandatory: it may be more viable to drop software to satisfy the GR than to add support for other inits - and since systemd is the current default, software that doesn't support systemd are good candidates to be dropped, aren't they? (Note that I do prefer to keep them, and have a policy that allows keeping them ...)
For these reasons I voted:
  1. Choice 4: GR not required
  2. Choice 3: Let maintainers do their work
  3. Choice 2: Recommended, but not mandatory
  4. Choice 5: No decision
  5. Choice 1: Ban packages that don't work with every init system
Fact is that Debian maintainers have always been trying hard to allow people to choose their favorite software. Until you give me an example where the Debian maintainer (not upstream) has refused to include sysvinit support, I will continue to trust my fellow DDs. I've been considering to place Choice 2 below "further discussion", but essentially this is a no-op GR anyway - in my opinion "should support other init systems" is present in default Debian policy already anyway...
Say no to the haters.
And no, I'm not being unfair. One of the most verbose haters going by various pseudonyms such as Gregory Smith (on Linux Kernel Mailing list), Brad Townshend (LKML) and John Garret (LKML) has come forward with his original alias - it is indeed MikeeUSA, a notorious anti-feminist troll (see his various youtube "songs", some of them include this pseudonym). It's easy to verify yourself.
He has not contributed anything to the open source community. His songs and "games" are not worth looking at, and I'm not aware of any project that has accepted any of his "contributions". Yet, he uses several sock puppets to spread his hate.
The anti-systemd "crowd" (if it acually is more than a few notorious trolls) has lost all its credibility in my opinion. They spread false information, use false names, and focus on hate instead of improving source code. And worse, they tolerate such trolling in their ranks.

Charles Plessy: Did we need a general resolution?

In 2009 I called for a general resolution regarding membership procedures in Debian, to block a change that, in my opinion, was going against our values. Results, even if they satisfied the majority came with a bitter feeling and it became questioned whether a better solution could have been reached without using a constraining procedure. I did not think so, but not to the point of not having doubts about it, and therefore, regrets. This year, we are again having a vote related to a change that some people think it goes against our values, and again the existence of this vote makes it hard to find compromises. Bitterness will win whatever the result is. For the avoidance of doubt, I have proposed the amendment number 3, stating that this general resolution should not have been started. I hope that this amendment will defeat the original proposition and will make people think twice before pressing Debian's alarm button next time. PS: amendment 3, that is amendment C, that is choice 4. If there was a need for an example that the procedure is complex, here it is...

Lucas Nussbaum: Jessie frozen, can we release before FOSDEM?

Jessie was frozen on November 5th, as planned. At the time of the freeze, 310 RC bugs remained to be fixed. This is quite an achievement from the project as a whole, and the Release Team specifically. First, we froze on the date announced more than a year ago, and the freeze seems to have been well respected by all maintainers. Second, with 310 RC bugs at the time of the freeze, we are probably breaking a record for all recent Debian releases (though I don t have hard numbers for that). It seems that auto-removals of RC-buggy non-key packages helped a lot to keep the bug number under control. Assuming that all RC-buggy non-key packages were removed (which would be quite sad of course), we would even be down to about 150 RC bugs! Could we have the shorter Debian freeze ever? (wheezy: 44 weeks; squeeze: 26 weeks; lenny: 28 weeks; etch: 17 weeks). Given that FOSDEM is 12 weeks away, could we even release before FOSDEM, and have a big party there to celebrate? That s not impossible, but we need everybody s help. Random tip and tricks:

Steve Kemp: How could you rationally fork Debian?

The topic of Debian forks has come up a lot recently, and as time goes on I've actually started considering the matter seriously: How would you fork Debian? The biggest stumbling block is that the Debian distribution contains thousands of packages, which are maintained by thousands of developers. A small team has virtually no hope of keeping up to date, importing changes, dealing with bug-reports, etc. Instead you have to pick your battle and decide what you care about. This is why Ubuntu split things into "main" and "universe". Because this way they didn't have to deal with bug reports - instead they could just say "Try again in six months. Stuff from that repository isn't supported. Sorry!" So if you were going to split the Debian project into "supported" and "unsupported" what would you use as the dividing line? I think the only sensible approach would be : On that basis you'd immediately drop the support burden of GNOME, KDE, Firefox, Xine, etc. All the big, complex, and user-friendly stuff would just get thrown away. What you'd end up with would be a Debian-Server fork, or derivative. Things you'd package and care about would include: Would that be a useful split? I suspect it would. It would also be manageable by a reasonably small team. That split would also mean if you were keen on dropping any particular init-system you'd not have an unduly difficult job - your server wouldn't be running GNOME, for example. Of course if you're thinking of integrating a kernel and server-only stuff then you might instead prefer a BSD-based distribution. But if you did that you'd miss out on Docker. Hrm.

Wouter Verhelst: Thanks, joeyh

Last friday saw a somewhat distressing email to the debian-devel mailinglist, wherein Joey Hess, one of Debian's most valuable contributors, announced his decision to quit the project. For all of Joey's contributions over the years, this is an unwelcome message; I'd much rather have seen him remain active in Debian, both on a personal and a technical level. As it is, I have a feeling of not just losing a colleague in Debian, but also a friend. For people not active in Debian, it's easy to miss Joey's contributions to the project, but let me tell you that without Joey Hess, Debian simply would not be where it is today. We would not have the debian-installer and we would not have debhelper (so we would have massively complicated debian/rules files). More than that, though, Joey has been one of those people who, on a technical level, seemed to instinctively sense the right thing to do; as in, whenever Joey Hess disagrees with you on a technical matter, you know you must be doing something wrong. As sudden and as unwelcome as last friday's announcement was, however, I can't say that it was totally unexpected. I've noticed Joey reducing his efforts in core areas of the project over the past few years, where on the one hand he has been mostly withdrawing from debian-installer development, and on the other hand his two most recent 'large' projects (ikiwiki and git-annex) haven't really been about Debian. Still, it's a painful loss; and while Debian has lost other high-profile contributors in the past over divisive issues, and recovered, that doesn't make it any less fun. Here's to you, Joey. May you find joy in whatever you decide to do next. May you not disappear from our collective radars. May we meet again, at some conference in the future, so I can buy you a beer. (hint: FOSDEM ;-) )

John Goerzen: Being Different

This evening, after the boys were in bed, Laura and I sat down to an episode of MASH (a TV series from the 70s) and leftover homemade pumpkin bars. She commented, Sometimes I wonder what generation we re in. This doesn t seem to be something people our age are usually doing. Probably true. I suppose people my age aren t usually learning to play the penny whistle or put up antennas in trees either. We ve had a fun day today a different sort of day in a lot of ways. We took the boys for their first Wichita Symphony Orchestra experience they were doing their first-ever family concert (Beethoven Lived Upstairs, which combined Beethoven s music with a two-person play aimed at kids). And they had an instrument petting zoo beforehand. Both boys loved it.
From November 8, 2014
After that, we took them to a sushi place for the first time. We ordered different types of rolls for our table, encouraging them to start with the California roll. They loved it (though Oliver did complain it was a bit hard to eat). Jacob happily devoured everything he could that wasn t spicy. He would have probably devoured the plate of California roll slices by himself if I hadn t stopped him and encouraged him to slow down and try some other things too. It doesn t seem very common around here to take 5-year-olds to a sushi place and plan on them eating the same sort of food that the adults around them are. It is a lot of fun to be different. Jacob and Oliver both have their unique personalities and interests, and I hope that they continue to find strength and joy in all the ways they are unique.

8 November 2014

Martin-Éric Racine: On the Joey debacle

Looking back, I cannot think of a single moment when Joey wouldn't have shown the utmost patience and courtesy towards anyone involved in Debian, even towards mere users filing sometimes senseless bug reports against his packages. From this perspective, I cannot help but venture that whatever chain of events lead to Joey's decisions essentially means one thing: Debian must have seriously gotten off-course for someone who has been involved for so long to call it quits. As for the current situation at hands, while I admittedly haven't followed too closely who or what caused Joey's decision, I nonetheless cannot help but feel that whoever pushed Joey's buttons so hard as to make him decide to leave Debian ought to be the one(s) kicked out of Debian instead.

Gunnar Wolf: Collective pain

The following text is not mine. I'm copy-translating a text a dear friend of mine just wrote in Spanish, in Facebook. He writes far better than I do (much better than most people I have known). I am not also a great translator. If you can read Spanish, go read the original.
I hate my country. I want to get the hell out of here. This country stinks. Phrases that appear in talks between Mexicans since yesterday. On the network and outside of it. And to tell the truth, I would have put them between quotation marks if I had not thought them as well. At some point. Because that is the edtent of the pain. Enuogh to hate, to insult, to give up. But we talk and write without realizing that it might be the most terrible thing in all this mess. That the pain makes us give up and consent to play a role in the game that they, the executioners, would pleasedly look at from their tribunes, laughing at us while they hand each other the popcorn. That would be over the line. So lets not give them that joy. Because they surely don't realize we have the obligation to notice it from the very beginning and do something to avoid falling there: The root of the pain they caused us yesterday is because that's how the annihilation of hope feels like. The shout "Alive they were taken" they do not realize but we do is a shout of hope. A pronouncement for the possible goodness in the human being. A testimony of hope in the future. A bet for life. And with his cold address, the federal attorney yesterday wanted to finish the killing of our already aching hope. We cannot grant him that joy. They say it's the last thing that dies. I'd say it's the only thing that should not die. Ever. It finishes and everything finishes. There is no possible justice for the parents of the 43. Much less for the 43. Not even however much the official discourse wants to gets us dizzy with the propaganda saying "we will not rest until". Not even if the president quits that would bring back to their classrooms even one of those that by today are just ashes. And sadly, that's the excuse that man wields to not stop boarding his plane and travel wherever he pleases. The farthest from Mexico, the better. Lets not do the same. Lets remind the world this country is full of us, not of them. That the face of a persn is not the dirtyness on his forehead and cheeks, but the skin that's below, that feels and throbs. Lets show the world Mexico is more the verse than the blood, more the idea than the terror. And to them... Lets not give them the joy. To them, lets make them see that, however hard they try, there are things they will never take from us. Our love for this country, for example. The country, over all things.
- Antonio Malpica. After what appears to be the bitter and sadly expected end of a sad, terrible, unbelievable collective social rupture we have lived for ~50 days. And what comes next? How can it come? How can we expect it? I have no way to answer. We, the country's people, are broken.

Steve Kemp: Some brief notes on Docker

Docker is the well-known tool for building, distributing, and launching containers. I use it personally to run a chat-server, a graphite instance, and I distribute some of my applications with Dockerfiles too, to ease deployment. Here are some brief notes on things that might not be obvious. For a start when you create a container it is identified by a 64-byte ID. This ID is truncated and used as the hostname of the new guest - but if you ever care you can discover the full ID from within the guest: 
~# awk -F/ ' print $NF ' /proc/self/cgroup
9d16624a313bf5bb9eb36f4490b5c2b7dff4f442c055e99b8c302edd1bf26036
Compare that with the hostname: 
~# hostname
9d16624a313b
Assigning names to containers is useful, for example: 
$ docker run -d -p 2222:22 --name=sshd skxskx/sshd
However note that names must be removed before they can be reused: 
#!/bin/sh
# launch my ssh-container - removing the name first
docker rm  sshd   true
docker run --name=sshd -d -p 2222:22 skxskx/sshd
The obvious next step is to get the IP of the new container, and setup a hostname for it sshd.docker. Getting the IP is easy, via either the name of the ID: 
~$ docker inspect --format '  .NetworkSettings.IPAddress  ' sshd
172.17.0.2
The only missing step is the ability to do that magically. You'd hope there would be a hook that you could run when a container has started - unfortunately there is no such thing. Instead you have two choices: I wrote a simple watcher to fire when events are created, which lets me do the job. But running a deamon just to watch for events seems like the wrong way to go. Instead I've switched to running via a wrapper dock-run: 
$ dock-run --name=sshd -d -p 2222:22 skxskx/sshd
This invokes run-parts on the creation directory, if present, and that allows me to update DNS. So "sshd.docker.local" will point to the IP of the new image. The wrapper was two minutes work, but it does work, and if you like you can find it here. That concludes my notes on docker - although you can read articles I wrote on docker elsewhere.

Ingo Juergensmann: Bind9 vs. PowerDNS - part 2

AttachmentSize
dnssec.sh.txt3.55 KB
Two weeks ago I wrote about implementing DNSSEC with Bind9 or PowerDNS and asked for opinions, because Bind9 appeared to me to be too complex to set it up with regular key signing and such and PowerDNS seemed to me to be nice and easy, but some kind of black box where I don't now what's happening. I think I've now found the best and most suitable way for me to deal with DNSSEC. Or in short words: Bind9 won! It won because of its inline-signing config option that you can use in bind9.9, which happens to be in backports. Another tip I can give due to my findings on the web: if you plan to implement DNSSEC with Bind9, do NOT! search for "bind dnssec" on the web. This will only bring up old HowTos and manuals which leaves you with the burden of manually update your keys. Just add the magic word "inline-signing" to your search phrase and you'll find proper results like the one from Michael McNally on a subpage of ISC.org: In-line Signing With NSEC3 in BIND 9.9+ -- A Walk-through. It's a fairly good starting point, but still left me with several manual steps to do to get a DNSSEC-signed zone. I'm quite a lazy guy when it comes down to manual steps that needs to get executed repeatedly, as many others in IT as well, I think. So I wrote some sort of small wrapper script to do the necessary steps of creating the keys, adding the necessary config options to your named.conf.local, enabling nsec3params, add the DS records to your zone file and displaying the DNSKEY to you, so that you just need to upload it to your registrar. One problem was still open: when doing auto-signing/inline-signing with bind9, you are left with your plain text zone file whereas your signed zone file will keep to increase the serial with each key rollover. When changing your plain text zone file by adding, changing or removing RRs of that domain, you'll be left with the manual task of finding out was your actual serial is that is currently used, because it's not your serial +1 from your plain text zone file anymore. This is of course an awkward part I wanted to get rid off. And therefor my script includes an option to edit zone files with your favorite editor, increase the serial automatically by determing the currently highest number, either on disk or in DNS and raising this serial by 1. Finally the zone is automatically reloaded by rndc. That way I now have the same comfort as in PowerDNS with Bind9, but also know what's going on, because it's not a black box anymore. Me happy. :-) P.S.: I don't know whether this script is of interest to other users, because it relies heavily on my own setting, e.g. paths and such. But if there's interest, just ask... P.P.S.: Well, I think it's better when you can decide yourself if my script is of interest to you... please find it attached...
Kategorie:
Debian
Tags:
Debian
Software
Internet
DNS

Russ Allbery: Another book haul

Someday there will be reviews. Also, software releases. But these posts are much easier to write in the evening when my brain is fried. Also, the anticipation of reading good books is delightful. The motivating reason for this order was that Powell's was giving away $10 gift cards with an order, so I bought books to buy more books later. Iain M. Banks Feersum Endjinn (sff)
Jacqueline Carey Autumn Bones (sff)
Robert Caro The Path to Power (non-fiction)
Keith Houston Shady Characters (non-fiction)
Jan Morris Hav (mainstream)
Arika Okrent In the Land of Invented Languages (non-fiction) I've been in a non-fiction mood lately, so lots of random non-fiction here. The Caro is the first volume of his huge biography of LBJ, which is apparently one of the best biographies ever written. The other non-fiction is less serious: one about intentionally-created languages, and the other about the history of punctuation characters. Hav is a travel book about a city that doesn't actually exist, so it fits somewhat with the non-fiction theme.

7 November 2014

Martin-Éric Racine: HEL has just frozen over. Wait. No. Debian did.

Noticing that Debian just entered its freeze, I went ahead and changed the APT sources on a spare host that is currently running stable. Then, it was time for this command to be executed:

sudo apt-get update && \
sudo apt-get install apt dpkg locales && \
sudo apt-get --purge dist-upgrade && \
sudo apt-get --fix-policy install && \
sudo apt-get --purge autoremove $(deborphan --guess-all)

I guess I'll be busy filing bug reports for the next few hours. Wish me (and each faulty package's maintainer) luck!

PS: Apparently, so many aspects of Debian have become dependent upon GPG features that merely upgrading APT, DPKG and libc6+locales is no longer enough. One must also upgrade gnupg and gnupg2. Thus, the second element of the above recipe has become:

sudo apt-get install apt dpkg gnupg gnupg2 locales && \

Hopefully, APT's dist-upgrade command already knows that these must be upgraded first...

PPS: Hosts running Network-Manager cannot be upgraded remotely, because Network-Manager insists upon killing the network connection and the SSH daemon with it, when its turn comes to get upgraded.

Richard Hartmann: Release Critical Bug report for Week 45

WE ARE FROZEN! Please note that Lucas hacked a "key packages" count into this list. If you have spare cycles, look at those first. I hope to have a (somewhat) random bug of the week thingie by next week which picks stalled bugs for increased exposure. As you can see, we are a bit worse than in the Squeeze cycle, but way ahead of Wheezy. Stats with proper diffs will also start next week. The UDD bugs interface currently knows about the following release critical bugs: How do we compare to the Squeeze release cycle?
Week Squeeze Wheezy Diff
43 284 (213+71) 468 (332+136) +184 (+119/+65)
44 261 (201+60) 408 (265+143) +147 (+64/+83)
45 261 (205+56) 425 (291+134) +164 (+86/+78)
46 271 (200+71) 401 (258+143) +130 (+58/+72)
47 283 (209+74) 366 (221+145) +83 (+12/+71)
48 256 (177+79) 378 (230+148) +122 (+53/+69)
49 256 (180+76) 360 (216+155) +104 (+36/+79)
50 204 (148+56) 339 (195+144) +135 (+47/+90)
51 178 (124+54) 323 (190+133) +145 (+66/+79)
52 115 (78+37) 289 (190+99) +174 (+112/+62)
1 93 (60+33) 287 (171+116) +194 (+111/+83)
2 82 (46+36) 271 (162+109) +189 (+116/+73)
3 25 (15+10) 249 (165+84) +224 (+150/+74)
4 14 (8+6) 244 (176+68) +230 (+168/+62)
5 2 (0+2) 224 (132+92) +222 (+132/+90)
6 release! 212 (129+83) +212 (+129/+83)
7 release+1 194 (128+66) +194 (+128/+66)
8 release+2 206 (144+62) +206 (+144/+62)
9 release+3 174 (105+69) +174 (+105/+69)
10 release+4 120 (72+48) +120 (+72/+48)
11 release+5 115 (74+41) +115 (+74/+41)
12 release+6 93 (47+46) +93 (+47/+46)
13 release+7 50 (24+26) +50 (+24/+26)
14 release+8 51 (32+19) +51 (+32/+19)
15 release+9 39 (32+7) +39 (+32/+7)
16 release+10 20 (12+8) +20 (+12/+8)
17 release+11 24 (19+5) +24 (+19/+5)
18 release+12 2 (2+0) +2 (+2/+0)
Graphical overview of bug stats thanks to azhag:

Niels Thykier: Release sprint Preparing for Jessie

The release team are doing a sprint right now up the mini-DebConf in Cambridge, kindly hosted by ARM. We have a fairly large agenda of around 10 items, ranging from simple things like determine the name for the next release to reviewing the list of RC bugs affecting Jessie. Personally, I am very pleased with our progress. We managed to finish 8 of items on the first day. Furthermore, we spent several hours on the RC bug list and keeping up with the unblock requests. There is also live status of the release team, courtesy of Jonathan Wiltshire. Mind you it is manually updated. We will announce the results of our sprint Sunday morning in our Release update talk. The announcement will also be posted to debian-devel-announce like our freeze announcement. Update: fix link to the live status

Andrew Cater

Here at the Debian mini-conf in Cambridge at ARM.

16 developers sat in near-total silence, the only noise keyboards and a server sitting next to me.

Some of them I've seen only on video presentations: one I first knew 20 years ago, one wrote all the HOWTO's I knew a couple of years before that - and was the second Linux user ever.

The release team is in another room behind me: Jessie froze the night before last - whatever else will be said/done, we're on the path to release.

It feels very strange and comforting to see Debian in the round: to be able to talk to someone you might argue with in email and see a real person.

And HUGE thanks to all at ARM for time, effort, chasing around and to Sledge and Jo Jo most of all for being stuck on a front desk waiting for people :)


Riku Voipio: Adventures in setting up local lava service

Linaro uses LAVA as a tool to test variety of devices. So far I had not installed it myself, mostly due to assuming it to be enermously complex to set up. But thanks to Neil Williams work on packaging, installation has got a lot easier. Follow the Official Install Doc and Official install to debian Doc, roughly looking like: 1. Install Jessie into kvm 

kvm -m 2048 -drive file=lava2.img,if=virtio -cdrom debian-testing-amd64-netinst.iso
2. Install lava-server 

apt-get update; apt-get install -y postgresql nfs-kernel-server apache2
apt-get install lava-server
# answer debconf questions
a2dissite 000-default && a2ensite lava-server.conf 
service apache2 reload
lava-server manage createsuperuser --username default --email=foo.bar@example.com
$EDITOR /etc/lava-dispatcher/lava-dispatcher.conf # make sure LAVA_SERVER_IP is right
That's the generic setup. Now you can point your browser to the IP address of the kvm machine, and log in with the default user and the password you made. 3 ... 1000 Each LAVA instance is site customized for the boards, network, serial ports, etc. In this example, I now add a single arndale board. 

cp /usr/lib/python2.7/dist-packages/lava_dispatcher/default-config/lava-dispatcher/device-types/arndale.conf /etc/lava-dispatcher/device-types/
sudo /usr/share/lava-server/add_device.py -s arndale arndale-01 -t 7001
This generates us a almost usable config for the arndale. For site specifics I have usb-to-serial. Outside kvm, I provide access to serial ports using the following ser2net config: 

7001:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT
7002:telnet:0:/dev/ttyUSB1:115200 8DATABITS NONE 1STOPBIT
TODO: make ser2net not run as root and ensure usb2serial devices always get same name.. For automatic power reset, I wanted something cheap, yet something that wouldn't require much soldering (I'm not a real embedded engineer.. I prefer software side ;) . Discussed with Hector, who hinted about prebuilt relay boxes. Chose one from Ebay, a kmtronic 8-port USB Relay. So now I have this cute boxed nonsense hack. The USB relay is driven with a short script, hard-reset-1 

stty -F /dev/ttyACM0 9600
echo -e '\xFF\x01\x00' > /dev/ttyACM0
sleep 1
echo -e '\xFF\x01\x01' > /dev/ttyACM0
Sidenote: If you don't have or want automated power relay for lava, you can always replace this this script with something along "mpg123 puny_human_press_the_power_button_now.mp3" Both the serial port and reset script are on server with dns name aimless. So we take the /etc/lava-dispatcher/devices/arndale-01.conf that add_device.py created and make it look like: 

device_type = arndale
hostname = arndale-01
connection_command = telnet aimless 7001
hard_reset_command = slogin lava@aimless -i /etc/lava-dispatcher/id_rsa /home/lava/hard-reset-1
Since in my case I'm only going to test with tftp/nfs boot, the arndale board needs only to be setup to have a u-boot bootloader ready on power-on. Now everything is ready for a test job. I have a locally built kernel and device tree, and I export the directory using the httpd available by default in debian.. Python! 

cd out/
python -m SimpleHTTPServer
Go to the lava web server, select api->tokens and create a new token. Next we add the token and use it to submit a job 

$ sudo apt-get install lava-tool
$ lava-tool auth-add http://default@lava-server/RPC2/
$ lava-tool submit-job http://default@lava-server/RPC2/ lava_test.json
submitted as job id: 1
$
The first job should now be visible in the lava web frontend, in the scheduler -> jobs part. If everything goes fine, the relay will click in a moment and the job will finish in a few minutes.

Johannes Schauer: automatically suspending cpu hungry applications

TLDR: Using the awesome window manager: how to automatically send SIGSTOP and SIGCONT to application windows when they get unfocused or focused, respectively, to let the application not waste CPU cycles when not in use. I don't require any fancy looking GUI, so my desktop runs no full-blown desktop environment like Gnome or KDE but instead only awesome as a light-weight window manager. Usually, the only application windows I have open are rxvt-unicode as my terminal emulator and firefox/iceweasel with the pentadactyl extension as my browser. Thus, I would expect that CPU usage of my idle system would be pretty much zero but instead firefox decides to constantly eat 10-15%. Probably to update some GIF animations or JavaScript (or nowadays even HTML5 video animations). But I don't need it to do that when I'm not currently looking at my browser window. Disabling all JavaScript is no option because some websites that I need for uni or work are just completely broken without JavaScript, so I have to enable it for those websites. Solution: send SIGSTOP when my firefox window looses focus and send SIGCONT once it gains focus again. The following addition to my /etc/xdg/awesome/rc.lua does the trick: 
local capi =   timer = timer  
client.add_signal("focus", function(c)
  if c.class == "Iceweasel" then
    awful.util.spawn("kill -CONT " .. c.pid)
  end
end)
client.add_signal("unfocus", function(c)
  if c.class == "Iceweasel" then
    local timer_stop = capi.timer   timeout = 10  
    local send_sigstop = function ()
      timer_stop:stop()
      if client.focus.pid ~= c.pid then
        awful.util.spawn("kill -STOP " .. c.pid)
      end
    end
    timer_stop:add_signal("timeout", send_sigstop)
    timer_stop:start()
  end
end)
Since I'm running Debian, the class is "Iceweasel" and not "Firefox". When the window gains focus, a SIGCONT is sent immediately. I'm executing kill because I don't know how to send UNIX signals from lua directly. When the window looses focus, then the SIGSTOP signal is only sent after a 10 second timeout. This is done for several reasons: With this change, when I now open htop, the process consuming most CPU resources is htop itself. Success! Another cool advantage is, that firefox can now be moved completely into swap space in case I run otherwise memory hungry applications without ever requiring any memory from swap until I really use it again. I haven't encountered any disadvantages of this setup yet. If 10 seconds prove to be too short to copy and paste I can easily extend this delay. Even clicking on links in my terminal works flawlessly - the new tab will just only load once firefox gets focused again. EDIT: thanks to Helmut Grohne for suggesting to compare the pid instead of the raw client instance to prevent misbehaviour when firefox opens additional windows like the preferences dialog.

Russ Allbery: On tolerating personal abuse

While I don't consider myself part of the science fiction community directly (my con-going days are probably over), I do follow it across a wide variety of blogs. There are a lot of hard conversations and considerable soul-searching going on right now concerning an on-line commentator in that community who had been nasty and vicious to people, but originally for reasons that many people thought were good causes. (I had been one of those people. It's always very, very tempting to appreciate a good vitriolic rant from someone who shares your world view. And very easy to lose track of the people those rants are aimed at, or the excesses to which those rants go.) I'm not going to go into the details of the SF community issues here, since I have no context other than what I've read, and it's something to work out within that community. But I've been taking it as a useful reminder that abusive behavior is not acceptable, even if it comes from people who are arguably on your side. Anger is important. Anger is often how the world changes. But anger and abuse are not the same thing. I wrote something a little bit ago in a different context. Given that reminder, and given some of the arguments that are going on in the free software community as well, it seemed like a good idea to post a somewhat edited version of it in a more public place: None of us should be willing to continue to participate in a project in which we're expected to tolerate being abused and attacked, and all consequences of that abuse are our problem to deal with. It is simply not fun, and not motivating, and not interesting, and does not lead to us doing good work. I say this from lots of hard-won personal experience. I was deeply involved in Usenet governance for many years. I have made all the same arguments that I see today in favor of "blunt" speech, vitriol, and attacks. I have been a passionate advocate for the "free speech" approach. I have told other people to just filter and use killfiles. I have said that words aren't worth getting worked up about, and it's easy to ignore people. I was wrong. It took a long time for me to figure out that I was wrong, not just for other people, but for myself as well. It took me much longer to walk away from Usenet governance for good because the environment was too toxic. It remains one of the best decisions I have ever made in my life. It was the best bit of self-care that I ever did. I learned from that experience, and earlier this year, I walked away from a job for related reasons. I enjoyed the work, the job was much easier than the job that I have now, and I had a lot of time to work on free software and on Debian, but the emotional environment was toxic. (It was not as openly abusive, but it was an environment of disrespect, hierarchical dominance games, fear, blame, and emotional blackmail.) As a result, I've had to shift priorities considerably, but I'm a much happier person. It's worth having less time for things that I was previously enjoying to not to have to deal with an emotionally negative and confrontational environment. Life is too short, and I have the luxury of having choices. Both of those incidents taught me that it's very easy for me to leave that sort of situation to fester for too long, and that I underestimate how much of an improvement it is for my quality of life to walk away from abusive and negative emotional situations. I am belatedly learning how to be more ready and willing to do this. I very much understand the people who are concerned with ensuring there is space for strongly-worded opinions and heartfelt anger. But we have to draw a line, and that line needs to rule out emotional abuse of people in our community even in the name of passionate polemics about something that's important. We have to enforce that line, and if that means ejecting people from our community, that's what we have to do. Because, if we don't, we're also ejecting people from our community: the quiet people, the people who are just trying to get work done, or the people who have had past experience with abusive environments and understand the need to bail when an environment starts going in that direction. I'm not going to put up with the sort of environment I put up with when doing Big Eight newsgroup creation. I'm not saying this as some sort of threat -- I'm saying this to try to be very clear that not standing up for the members of our community and not supporting each other against abuse and emotional attacks also has consequences, and will destroy that community for a lot of us. I'm saying that I am not interested in living in an environment of fear and blame. And one should never underestimate the human power of giving people space and community in which they can be comfortable, relaxed, and truly happy. Walking the line between this stance and the "tone argument," in which people who are being abused or disenfranchised are attacked for being angry, is very difficult. There are some helpful rules of thumb, such as distinguishing between punching up and punching down, but those rules of thumb can fail or be distorted, as the SF community is learning. It's important that people be able to express anger. It's also important that people be able to name names and identify specific behaviors that they believe are worthy of that anger. But when that anger escalates into attacks, there is a real danger that passionate righteousness turns into passionate abusiveness, a danger of losing the sense of community in our own sense of righteousness. And that's not something we can or should accept. It's going to take a lot of hard work, a lot of open conversation, and a lot of empathy and care to find that line. There are many things in the world right now that should provoke anger, and with that anger comes power for good. But with that anger can also come a destructive blindness. The anger I want is the anger that drives us to change the world together, the anger that leads to confronting others with a reflection of their own better natures and challenging them to become better, more compassionate people. The anger that leads a man to feed the homeless in the true meaning of civil disobedience. Not the anger that crushes our enemies.

Next.

Previous.