Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!
Tutorials on microcontroller ATtiny will push you to use WDTCR definition. It has been switched long time ago to WDTCSR, according to ATtiny24/44/84 Datasheet. I hope this short post may save some of your precious hacking time.
As Adirondack (train line MTL-NYC) is not Internet-friendly for RSS feeds I can't profit of my ~11h travelling to check this huge schedule in the way I want to, (= having a timetable view including room, description and speakers). HOPE X has just released a pdf and a xls (wtf??), but these contain only titles and room.
So I've coded an ics generator to process their feed. The result file is available at http://acaia.ca/hopex.ics and should be up to date with the original RSS.
After three years living in Montréal we're still amazed by the fact that here we have er... seasons!!
I believe that things have a special beauty when they don't last the time we want them to last, and seasons are all about it! (some people will exclude winter here) Anyways, taking pictures may give them more lifetime without compromising too much their beauty. And sharing them here and there is somewhat sharing our happiness, which might be a good balance in the end :)
At the time we moved the garden was just a single white thing...
then we realized that it provided some chairs, a table and a compost container, yay!
But the grey ground was something to be fixed...
so we hacked it and got some land :)
Few months later and it's finally becoming chard, beets, carrots, spinach, berries, cheries, okra, tomatoes, basil, potatoes, sage, agastache and a saskatoon berry tree!
Debian is a big system. At the time of writing, looking at my local package list caches tells me that the unstable suite contains 21306 source packages, and 42867 binary packages on amd64. Between these 42867 binary packages, there is an unthinkable number of inter-package dependencies. For example the dependency graph of the ruby packages contains other 20-something packages.
A new version of any of these packages can potentially break some functionality in the
And that dependency graph is very small. Looking at the dependency graph for,
rails package will make your eyes bleed. I tried it here, and
GraphViz needed a PNG image with 7653×10003 pixels to draw it. It ain’t pretty.
Installing rails on a clean Debian system will pull in another 109 packages as
part of the dependency chain. Again, as new versions of those packages are
uploaded the archive, there is a probability that a backwards-incompatible
change, or even a bug fix which was being worked around, might make some
rails stop working. Even if that probability is low for each
package in the dependency chain, with enough packages the probability of any
of them causing problems for rails is quite high.
And still the
rails dependency chain is not that big.
libreoffice will pull
in another 264 packages.
gnome will pull in 1311 dependencies, and
With a system this big, problems will arrive, and that’s a fact of life. As developers, what we can do is try to spot these problems as early as possible, and fixing them in time to make a solid release with the high quality Debian is known for.
While automated testing is not the proverbial Silver Bullet of Software Engineering, it is an effective way of finding regressions.
Back in 2006, Ian Jackson started the development of autopkgtest as a tool to test Debian packages in their installed form (as opposed to testing packages using their source tree).
In 2011, the autopkgtest test suite format was proposed as a standard for the Debian project, in what we now know as the DEP-8 specification.
Since then, some maintainers such as myself started experimenting with DEP-8 tests in their packages. There was an expectation in the air that someday, someone would run those tests for the entire archive, and that would be a precious source of QA information.
Durign the holiday break last year, I decided to give it a shot. I initially
called the codebase
dep8. Later I renamed it to
debci, since it could
potentially also run other other types of test suites in the future. Since
early January, ci.debian.net run an instance of debci
for the Debian Project.
The Debian continuous Integration will trigger tests at most 4 times a day, 3 hours after each dinstall run. It will update a local APT cache and look for packages that declare a DEP-8 test suite. Each package with a test suite will then have its test suite executed if there was any change in its dependency chain since the last test run. Existing test results are published at ci.debian.net every hour, and at the end of each batch a “global status” is updated.
Maintainers can subscribe to a per package Atom feed to keep up with their package test results. People interested in the overall status can subscribe to a global Atom feed of events.
Since the introduction of Debian CI in mid-January 2014, we have seen an amazing increase in the number of packages with test suites. We had little less than 200 packages with test suites back then, against around 350 now (early June 2014). The ratio of packages passing passing their test suite has also improved a lot, going from less than 50% to more than 75%.
There is documentation available, including a FAQ for package maintainers with further information about how the system works, how to declare test suites in their packages and how to reproduce test runs locally. Also available is development information about debci itself, to those inclined to help improve the system.
This is just the beginning.
debci is under a good rate of development, and
you can expect to see a constant flux of improvements. In special, I would like
to mention a few people who are giving amazing contributions to the project:
- Martin Pitt has been working on improving debci to support parallel and distributed workers. Being the current autopkgtest maintainer, Martin also already got some bug fixes and fixes into autopkgtest motivated by debci use cases.
- Lucas Kanashiro is another GSOC student, who is working on investigating patterns among packages that fail their test suites, so that we can figure out how we can fix them, or if there are classes of failures that are actually caused by problems in the debci infrastructure.
In 2010 I decided to stop using my google account. In 2011 I decided to leave facebook, twitter and other $cool stuff. This was a hard decision. Not because email migration was annoying, nor because I liked to do social networking. It's hard because most of friends depend on either google or facebook to chat. Since I moved to another country, phone calls and presencial meetings have been substantially reduced.
So we keep in contact by using IRC and XMPP. I have good friends who use IRC, mostly Debian people, which is great. I also have lots of friends and contacts not using IRC. In the past they used ICQ, then moved to MSN and now they are using google talk and facebook. I used to explain them that we could talk by using their google account and my Jabber account due to an open standard called XMPP. I enjoy having short conversations in random times, which sometimes takes hours and helps us to keep affectionately connected.
It used to work so well. Now it seems to be gone. I've noticed that I can't connect anymore with contacts using google talk, probably because google has finally put into action their decision to abandon open standards for instant messaging.
I'm not going to list here all the good things that happened in my life when I stopped using all this crap services. But I have to admit that it really hurts to see my contacts disappearing day by day, feeling like my friends are being devoured by these companies, with zero critical sense. You'll say that good friends won't disappear like that if they are good friends. I agree, but the convenience of having people from one-click distance in random hours a day makes a difference, mainly when physical distance is a blocker.