Debian is a big system. At the time of writing, the unstable distribution has more than 20,000 source packages, building more then 40,000 binary packages on the amd64 architecture. The number of inter-dependencies between binary packages is mind-boggling: the entire dependency graph for the amd64 architecture contains a little more than 375,000 edges. If you want to expand the phrase "package A depends on package B", there are more than 375,000 pairs of packages A and B that can be used.
Every one of these dependencies is a potential source of problems. A library changes the semantics of a function call, and then programs using that library that assumed the previous semantics can start to malfunction. A new version of your favorite programming language comes out, and a program written in it no longer works. The number of ways in which things can go wrong goes on and on.
With an ecosystem as big as Debian, it is just impossible to stop these problems from happening. What we can do is trying to detect when they happen, and fix them as soon as possible.
The Debian Continuous Integration project was created to address exactly this problem. It will continuously run test suites for source packages when any of their dependencies is updated, as well as when a new version of the package itself is uploaded to the unstable distribution. If any problems that can be detected by running an automated test suite arise, package maintainers can be notified in a matter of hours.
Antonio Terceiro has posted on his blog an introduction to the project with a more detailed description of the project, its evolution since January 2014 when it was first introduced, an explanation of how the system works, and how maintainers can enable test suites for their packages. You might also want to check the documentation directly.
One of the things we’re keen to continue to push with Ubuntu is a spirit of openness and inclusivity. Over the last couple of years with the reduction in ‘in person’ Ubuntu Developer Summits it’s been said Canonical developers are harder to reach, and that we’re not communicating effectively our plans and designs for the future direction of Ubuntu. We’ve been trying to address this via increased blogging, regular email status updates and video updates from all areas of the community.
As always we’re also keen to hear feedback, we welcome email discussion on our lists, bug reports, design mock-ups and of course well tested patches. We also want to ensure people at every level are available for Q&A sessions on a regular basis. Jono Bacon had a series of Q&A sessions which the Community Team will continue, but with additional domain experts and leaders during those sessions.
One of the biggest visible areas of change for Ubuntu is the transition from Unity 7 on Compiz (used in 14.04 and below) and Unity 8 and Mir (to be used in future releases). So today this weeks Ubuntu Online Summit we’ve arranged a couple of sessions which we invited participation in.
At 14:00 UTC today Rick Spencer (VP of Engineering) and Oliver (Olli) Ries (Director of Unity & Display Server) will hold an Ask Rick & Olli session. Bring along your questions about Unity, Mir, convergence, future desktop direction and more.
Click the time links above to find out when these are happening in your timezone today, and the other links to join in the sessions at that time. If you miss it you can watch the sessions later using the same links.Tweet
In my previous blog-post I mentioned, briefly, that I'd posted a couple of adverts on Reddit looking for work.
To give more detail I did three things:
The advertising on Reddit was painless to setup, and the traffic stats were interesting, but even though this worked out well I'm a little loathe to repeat the process - since the "non-sterling transaction fee" from my bank effectively doubled my budget.
I received a few (private) emails and comments, along with the expected grammar corrections. The end result was that I received contact from an American company founder who seemed interested.
He allowed me to write some code to solve a fun problem, appeared to enjoy the code I sent (Ruby code for dealing with (exim) email spam, that's as specific as I will be). The end result was a three month contract, which we obviously hope will lead to more permanent work.
Anyway I thought this was an atypical route to find a work, and was about a million times nicer than working with recruiters, so .. consider this documentation!
In other news it is now 10pm and I need to go to the gym and pub, in that order.
Some coding updates:
I've converted most of my Dockerfiles to work with docker 1.0.0, which is nice.
I also hacked up a fun DNS-server for sharing JSON-encoded data, within a LAN or other environment:
Finally I updated the blogspam-detecting site a little, on the back-end. The code is now running inside Docker containers which means I can redeploy more easily in the future.
My blog post about looking for a job received some attention via a Reddit advert I posted to /r/edinburgh + /r/sysadmin, but thus far has mostly resulted in people wanting me to write code for them .. which is frustrating.
For the moment I'm working on a fun challenge involving (email) spam-detection. That takes me back.
The Debian project is excited to announce that we are now accepting presentations, discussion sessions and tutorials for our DebConf14 conference which will take place in Portland State University, Oregon, USA from 23 to 31 August.Submitting an event
To submit an event, first register as an attendee for DebConf14 in the conference management system. If you have any doubts or have problems with the registration process please check the Registration FAQ.
After registering, go to the event submission page, or click on the Create an event option from the management system. Describe your submission in the web form. The most common event types are Lecture or Open Discussion (BoF). Please include a short title (to make it easy to produce a compact schedule) and an engaging description of the event.Tracks
We will organize some talks into thematic tracks. If you have a proposal for a DebConf track, such as "Debian ARM", "Debian Infrastructure", or "Community Outreach" please contact firstname.lastname@example.org.
If you would like to be a track coordinator, please volunteer on the given mail address.Format of the events
A regular session will be 45 minutes long, including time for questions. There will be a 15 minute breaks between events.
Submissions are not limited to traditional talks: you could propose a performance, art installation, debate, or anything else. If you have any specific requirements for your event, please send an email to email@example.com with the details of your requirements and be sure to mention your event title in the subject.Deadline
While we ask speakers to submit their events before the deadline of 7 July 2014, 23:59:59 UTC, late submissions will continue to be accepted for scheduling until the end of DebConf. All attendees will have an opportunity to schedule ad-hoc events during DebConf itself if we have space for them. Very promising late submissions may be considered for inclusion in the main conference. Note that ad-hoc events have a much lower chance of video archiving, and streaming, so if you want these services it's better to get your submissions in early.
DebConf official events will be broadcast live on the Internet when possible, and videos of the talks will be published on the web along with the presentation slides and papers.
For private communication regarding your talk, or for more general ideas, or questions about the event and talks, please mail us
We hope to you see you and share some good times with you this year in Portland during DebConf14!
If anybody has access to a complete mirror of the Debian Wheezy release, and was willing to share a list of all setuid/setgid binaries that would be greatly appreciated.
It doesn't seem to be something you can find online, so you need to manually unpack each .deb file and look at the permissions.
I don't have access to a (complete) local mirror, and so I cannot easily build such a thing, unless I go to ebay and buy a random DVD-archive.
This list would be useful for folk wanting to direct their audits ..
Until recently I was very happy with my console mail client, Lumail, thinking I'd written it in a flexible manner, with lots of Lua-callable primitives.
Now I'm beginning to suspect that I might have gone down the wrong path at some point.
The user interface, at startup consists of a list of mailboxes. The intention being that you select a mailbox, and open it. That then takes you to a list of messages. (There is a cool and simple to use option to open the union of multiple mailboxes, which is something I use daily.)
Now the list of mailboxes is sorted alphabetically, so the user interface looks something like this:
Now the issue that triggered my rethink:
Sure you think. It's just a list of strings. You could pass an array to a lua on_sort_maildirs function, and then use the returned array/table as teh display order. Simple.
Simple until you realize the user might want to do more than operate solely on the list of strings. Perhaps they wish to put folders with unread messages at the top. At which point you need a "count_unread( maildir )" function. (Which does exist.)
Anyway the realisation I had is that the CMaildir object, on the C++ side, isn't exposed to the Lua-side. So the (useful) member functions which should be exported/visible are not.
Really what I'm trying to say is that I think I've implemented and exported useful Lua primitives, but actually many more parts of the implementation could be usefully exported - but are not, and that comes from the choice I made to expose "things" not "objects". If I'd exposed objects right from the start I'd have been in a better place.
I continued to toy with a basic GUI mail-client last week, but I've pretty much written that off as a useful way to spend my time. For the moment I'll leave email alone, I've done enough and despite niggles what I have is absolutely the best mail client for me.
(It is a shame that Mutt is so heavyweight and hard to deal with, and that notmuch never really took off.)