In this post I m reviewing what I ve done the last 6 days of Outreachy-funded reproducible builds work, outline what I plan to do the next two weeks, and speculate on long term goals. For those of you involved in the Debian reproducible builds project, please provide feedback about future plans and work! Week One review One week of Outreachy completed! What have I done?

• Reproduced the reproducible builds tests website locally
• Added information to the INSTALL file about reproducing the tests website (viewable here)
• Checked in changes that broke nearly every link to the tests website
• Fixed mosts of the broken links by adding redirects. (Please let me know if you find any!)

The change that broke everything was the addition of a directory: tests.reproducible-builds.org/debian The directory was added to contain all Debian-specific pages, in line with the other project s reproducible builds status pages: arch linux, fedora, coreboot, etcs. Previously, all Debian pages we simply served directly out of the DocumentRoot. To fix all the broken things, I m pretty sure I had to find, inspect, and add /debian or change global variables within every file pointer in the entire tests website. Sometime tedious, but chasing down bugs and complaints was mostly fun I also learned (everything I now know) about Apache websites, redirects, the website/navigation/directory structure of tests.reproducible-builds.org, and the roles of many of the reproducible scripts in jenkins.debian.net/bin. Week Two plan What will or should I do next? In the short term, over the next two weeks, I hope to make useful improvements to the tests website and backend while continuing to get up to speed (as well as learn Python).

• Improve navigation on tests.reproducible-builds.org/debian
  • fix highlighting in the nav bar on package pages
  • address navigation bar re-organizing requests like this one
  • add documentation/hovertext for links
• Create a front page for the test reproducible builds site (update: probably not do this yet, low priority, already too many front pages for reproducible builds)
• Convert bin/reproducible_html_pkg_sets.sh to python

Have other thoughts about minor improvements to tests.reproducible-builds.org? Please let me know! The above list is not internally prioritized, feel free to ask for things to be bubbled up. Longer-term goals My long term summer goal is to make the Debian test code more easily extensible to show the reproducible results from other projects. This will lower the barrier for new projects to keep track of the reproducibility of their code, for great good. This starts with the reproducible.db database, which presently only tracks reproducible testing results for the Debian project. The reproducible builds project s needs have outgrown the original SQLight database, so this redesigning includes a migration to Postgre. Goals of the redesign include ease of querying/comparing packages across distributions, as well as generalization to include results from projects other than Debian. I ll start on this work in two weeks, when I get to DebCamp! Redesigning the database will also lead to updating the python script which use that data to produce the Debian tests website. Other project scripts (like Fedora, RedHat and Coreboot) can then be updated to track results in the database as well, instead simply directly producing their own test websites. update: as an intermediate step before redesigned the reproducible.db database to handle multiple projects h01ger recommended I help the FreeBSD project recorded tests to a FreeBSD specific database.

<iframe frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=dedasys-20&amp;o=1&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;ref=ss_til&amp;asins=B004IYISQW" style="width: 120px; height: 240px; float: left; margin-right: 20px; margin-bottom: 8px;"></iframe> Many small business owners start a business with the idea of greater freedom in mind, yet end up chaining themselves to something that takes even more dedication than a regular job. This book discusses the dos and don'ts that business owners need to be conscious of in order to create a business that is independent of its owner(s) in order to be able to sell it. It does so in an easy to read format that's a bit of a gimmick - a fictional story illustrating the authors points. Like most business books, the core idea isn't that hard to explain. the book even includes a handy summary of the main points, which I'll paraphrase here:

1. Focus on one thing you can do really well; even a service business can be 'productized' by creating a standard service that is the focus of the business.
2. If your business revolves around one or two key clients, the risk inherent in that approach will lower the value or scare of potential buyers completely.
3. Put a process in place, from sales through production.
4. Don't "be" your company. If the company is all about you, what's a potential buyer really getting if you sell it and leave?
5. By focusing on products, you can charge up front rather than having poor cash flow. If you pay people to work on a project for 3 months, and don't get paid for another month, you are, by the end, out 4 months salary while waiting for the payment.
6. Say no to projects outside the scope of your business. Only by focusing narrowly can you really excel at what you do.
7. Spend time doing some research and calculations to estimate your potential market size; buyers will want to know this.
8. If you have a business that has sales people, hire at least two so that they'll compete with one another.
9. You want people who are good at selling products, not services; the latter will want to tweak your offering for each and every client, rather than selling it as-is and trying to find how it can meet the customer's needs that way, which is the best strategy for a product.
10. If you were previously running a more 'generic' services company, and you switch to a more productized approach, be prepared to take a hit the year when you switch.
11. Potential acquirers will want to see at least a couple of years of steady growth with the new model after making the switch.
12. If you grow, you'll need a management team that can work without you. Put an incentive system into place to reward their loyalty and results.
13. When looking for an adviser to sell your company, aim for one where you will not be the largest or smallest client.
14. If your adviser really only has one company in mind to sell yours to, they may be trying to sell you off cheap as a favor.
15. Consider how much you could grow with the resources of a buyer. Think big, and show them what kind of growth could happen with the right backing.
16. Think and speak like a product business with 'customers' rather than 'clients'.
17. Stock options are more complex than simpler options like bonuses that are paid out over a period of time, in terms of ways to give people an incentive to stay.

All in all, it was an enjoyable read, with solid points. Even if you have no intention of selling your business, thinking of the business itself as a sort of "product" that is not dependent on you to work correctly is a sensible way to go about creating and growing a business. He's certainly not, nor claims to be the first one to discuss this idea, and indeed references the well known E-Myth Revisited which focuses less on selling a business, and more on how to go about extricating you and your skills from the business.

I'm excited by version 7 of debhelper, in particular the opportunity for debian/rules minimization. I suspect this will lower the barrier for rapid, reasonable packaging of simple software tools in a way that should be easy to audit and maintain. The most-minimized debian/rules possible with it is just (from dh(1)):

#!/usr/bin/make -f
%:
	dh $@

And all of the project-specific interesting bits go into nice, clean, well-named files under debian/. However, lintian (at least as of 1.23.48) complains loudly about the minimized debian/rules:

E: xdotool source: debian-rules-missing-required-target binary
E: xdotool source: debian-rules-missing-required-target binary-arch
E: xdotool source: debian-rules-missing-required-target binary-indep
E: xdotool source: debian-rules-missing-required-target build
E: xdotool source: debian-rules-missing-required-target clean

I'm not sure the right way to proceed: should i try to manually add overrides for each package that uses a minimized debian/rules? Should lintian recognize debhelper-specific minimized rules files and accept them? Should debhelper assuage lintian somehow? Or is this rules file minimization actually not as good an idea as I think it is? I notice that mr, which is Joey Hess's first example package using the minimized rules also reports the same errors.Tags: debhelper, lintian, packaging

On Ross’s blog he talks about “a project [that] is even more interesting for the geeks out there”. I’m pleased to disclose that said project is OProfileUI a graphical user interface for the OProfile system profiler. Hopefully this should help the amazing performance wizards do their thing. I also hope that this will lower the barrier to entry, profiling and performance improvements are often seen as a bit of a black art but it can be a good way for new contributors to explore the stack. This was my first project at OpenedHand and so i’m really pleased to see it released and available for other people to try (and improve.) Oh and it has a cool icon (thanks Andreas.)
Go on, grab it!.

These are the current translation ratios for French and Czech in unstable, after 16 days of "blitz l10n NMU". The re-introduction of debconf templates for viewvc with incomplete translations will lower the stats as of today...:-( I already notified its maintainer who is very l10n-aware so I'm confident we will fix this soon. However, that's kind of a disappointment for me, of course, as this will delay the day we will reach 100%. Yesterday, I worked on the oldest bugs mentioned on Thomas Huriaux dynamic status page:

• courier has been uploaded, unfortunately without the Swedish translation as the maintainer wrongly assumes this shouldn't be a target for Etch
• efingerd has been NMU'ed
• squidguard has been NMU'ed
• ssl-cert has been NMU'ed
• apt-proxy has been NMU'ed (man pages translations)
• defoma has been NMU'ed (man pages translations)
• qmail is ignored because of an obnoxious maintainer who is in my kill file
• gdm is ignored because #261086 is marked wontfix for reasons I don't want to dig into now (I'm pretty sure that something better could be done for that package, oh well)
• icedove is likely to be examined at some moment
• glide maintainer has been notified
• arb is ignored on request of its maintainer
• others are my targets for today..:)

PS: the title of this blog entry comes from a bug report from Joey Hess for ssl-cert. I didn't fix that because it certainly requires too invasive changes at this moment but these debconf templates are definitely not the best worded ever and the underlyign debconf code is pretty weak.