It has been close to a year now that I've incorporated my new company, Mergify. I've been busy, and I barely wrote anything about it so far. Now is an excellent time to take a break and reflect a bit on what happened during those last 12 months.
What problem does Mergify solve?Mergify is a powerful automation engine for GitHub pull requests. It allows you to automate everything and especially merging. You write rules, and it handles the rest.Example of rule matching returned in GitHub checksFor example, let's say you want your pull request to be merged, e.g., once your CI passes and the pull request has been approved. You just write such a rule, and our engine merges the pull request as soon as it's ready.We also deal with more advanced use cases. For instance, we provide a merge queue so your pull requests are merged serially and tested by your CI one after another avoiding any regression in your code.Our goal is to make pull request management and automation easy. You can use your bot to trigger a rebase of your pull requests, or a backport to a different branch, just with a single comment.Some people like to make bots talk to each other.
A New AdventureMergify is the first company that I ever started. I did run some personal businesses before, created non-profit organizations, built FOSS projects but I never created a company from scratch, even less with an associate.Indeed, I've chosen to build the company with my old friend Mehdi. We've known each others for 7 years now, and have worked together all that time on different open-source projects. Having worked with each other for so long has probably been a critical factor in the success of our venture so far.I had little experience sharing the founding seats with someone, and tons of reading seemed to indicate that it would be a tough ride. Picking the right business partner(s) can be a hard task. Luckily, after working so much time together, Mehdi and I both know our strengths and weaknesses well enough to be able to circumvent them. On the other hand, we both have similar backgrounds as software engineers. That does not help to cover all the hats you need to wear when building a company. Over time, we found arrangements to cover most of those equally between us.We don't have any magical advice to give on this. As in every relationship, communication is the key, and the #1 factor of success.
Getting UsersI don't know if we got lucky, but we got users and customers pretty early. We used a few cooperative projects as guinea pigs first, and they were brave enough to try our service and give us feedback. No repository has been harmed during this first phase!Then, as soon as we managed to get our application on the GitHub Marketplace, we saw a steady number of users coming to us.This has been fantastic as it allowed us to get feedback rapidly. We set up a form asking users for feedback after they used Mergify for a couple of weeks. What we hear is that users were happy, that the documentation was confusing and that some features were buggy or missing. We planned all of those ideas as our future work in our roadmap, using the principles we described a few months ago.
If you're curious, you can read this article.We tried various strategies to get new users, but so far, organic growth has been our #1 way of onboarding new users. Like many small startups out there, we're not that good at marketing and executing strategies.We provide our service for free for open-source projects We are now powering many organizations, such as Mozilla, Amazon Web Services, Ceph and Fedora.
Working with GitHubWorking with GitHub has been complicated. When you build an application for a marketplace, your business is entirely dependent on the platform you develop for both in terms of features and quality of service.In our case, we hit quite many bugs with GitHub. Their support has mostly been fast to answer, but some significant issues are still opened months later. The truth is that the GitHub API could deserve more love and care from GitHub. For example, their GraphQL API is a work in progress for years and miss out many essential features.GitHub service status is not always green.We dealt and still deal with all those issues. It obviously impacts our operations and decreases our overall velocity. We regularly have to find new ways to sidestep GitHub limitations.You have no idea how we wished for GitHub to be open-source. The idea of not having access to their code and understand how it works is so frustrating that we publish our engine as an open-source project. That allows all of our users to see how it works and even propose enhancements.
Automate all the wayWe're a tiny startup, and we decided to bootstrap our company. We never took any funding. From the beginning, it has been clear to us that we had to think and act like we had no resources. We're built around a scarcity mindset. Every decision we make is based on the assumption that we basically are very limited in terms of money and time.We basically act like any wrong choice we do could (virtually) kill the company. We only do what is essential, we ship fast, and we automate everything.For example, we have built our whole operation about CI/CD systems, and pushing any new fix or feature in production is done in a matter of minutes. It's not uncommon for us to push a fix from our phone, just by reviewing some code or editing a file.
GrowthWe're extremely happy with our steady growth and more users using our service. We now manage close to 30k repositories and merge 15k pull requests per month for our users.That's a lot of mouse clicks saved!If you want to try Mergify yourself, it's a single click log-in using your GitHub account. Check it out!
Here is my monthly update covering what I have been doing in the free software world (previous month):
I was elected Debian Project Leader for 2017. I'd like to sincerely thank everyone who voted for me as well as everyone who took part in the election in general especially Mehdi Dogguy for being a worthy opponent. The result was covered on LWN, Phoronix, DistroWatch, iTWire, etc.
Added support for the Monzo banking API in social-core, a Python library to allow web applications to authenticate using third-parties. (#68)
Updated systemd's documentation to explain why we suggest explicitly calling make all despite the Makefile's "check" target calling it. (#5830)
Updated the documentation of a breadth-first version of find(1) called bfs to refer to the newly-uploaded Debian package. (#23)
Updated the configuration for the ticketbot IRC bot (zwiebelbot on OFTC) to identify #reproducible-builds as a Debian-related channel. This is so that bug Debian bug numbers are automatically expanded by the bot. (#7)
Reproducible builds
Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users.
The motivation behind the Reproducible Builds effort is to permit verification that no flaws have been introduced either maliciously or accidentally during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.
I have generously been awarded a grant from the Core Infrastructure Initiative to fund my work in this area.
This month I:
Presented at foss-north.se 2017 in Gothenburg, Sweden on Reproducible Builds.
Sent a patch for poti a library to generate paje traces to ensure the build is reproducible when Git is not available. (#7)
Submitted a pull request to patat (a tool to make terminal-based presentations using Pandoc) to make the build reproducible. (#36)
Fixed miniupnp's build system to make the build reproducible. (#237)
Updated sunpinyin, a "statistical model" based Chinese input method, to make the .pc file output reproducible. (#73)
taskflow (an OpenStack library) to ensure the generated documentation is reproducible. (#4)
Issued DLA 882-1 for the tryton-server general application platform to fix a path suffix injection attack.
Issued DLA 883-1 for curl preventing a buffer read overrun vulnerability.
Issued DLA 884-1 for collectd (a statistics collection daemon) to close a potential infinite loop vulnerability.
Issued DLA 885-1 for the python-django web development framework patching two open redirect & XSS attack issues.
Issued DLA 890-1 for ming, a library to create Flash files, closing multiple heap-based buffer overflows.
Issued DLA 892-1 and DLA 891-1 for the libnl3/libnl Netlink protocol libraries, fixing integer overflow issues which could have allowed arbitrary code execution.
The Debian Project Leader elections finished yesterday and the winner is Chris Lamb!
Of a total of 1062 developers, 322 developers voted using the Condorcet method.
More information about the result is available in the Debian Project Leader Elections 2017 page.
The current Debian Project Leader, Mehdi Dogguy, congratulated Chris Lamb in his
Final bits from the (outgoing) DPL message.
Thanks, Mehdi, for the service as DPL during this last twelve months!
The new term for the project leader starts on April 17th and expires on April 16th 2018.
I'd like to thank the entire Debian community for choosing me to represent them as the next Debian Project Leader.
I would also like to thank Mehdi for his tireless service and wish him all the best for the future. It is an honour to be elected as the DPL and I am humbled that you would place your faith and trust in me.
You can read my platform here.
It's that time of year again for the Debian Project: the elections of
its Project Leader!
The Project Leader position is described in
the Debian Constitution.
Two Debian Developers run this year to become Project Leader:
Mehdi Dogguy,
who has held the office for the last year,
and Chris Lamb.
We are in the middle of the campaigning period that will last until
the end of April 1st. The candidates and Debian contributors
are already engaging in debates and discussions on
the debian-vote mailing list.
The voting period starts on April 2nd, and during the following two
weeks, Debian Developers can vote to choose the person
that will fit that role for one year.
The results will be published on April 16th
with the term for new the project leader starting the following day.
Many of you are big fans of S.W.O.T analysis, I am sure of that! :-) Technical competence is our strongest suit, but we have reached a size and sphere of influence which requires an increase in organisation.
We all love our project and want to make sure Debian still shines in the next decades (and centuries!). One way to secure that goal is to identify elements/events/things which could put that goal at risk. To this end, we've organized a short S.W.O.T analysis session at DebConf16. Minutes of the meeting can be found here. I believe it is an interesting read and is useful for Debian old-timers as well as newcomers. It helps to convey a better understanding of the project's status. For each item, we've tried to identify an action.
Here are a few things we've worked on:
Identify new potential contributors by attending and speaking at conferences where Free and Open Sources software are still not very well-known, or where we have too few contributors.
Each Debian developer is encouraged to identify events where we can promote FOSS and Debian. As DPL, I'd be happy to cover expenses to attend such events.
Our average age is also growing over the years. It is true that we could attract more new contributors than we already do.
We can organize short internships. We should not wait for students to come to us. We can get in touch with universities and engineering schools and work together on a list of topics. It is easy and will give us the opportunity to reach out to more students.
It is true that we have tried in the past to do that. We may organize a sprint with interested people and share our experience on trying to do internships on Debian-related subjects. If you have successfully done that in the past and managed to attract new contributors that way, please share your experience with us!
If you see other ways to attract new contributors, please get in touch so that we can discuss!
Not easy to get started in the project.
It could be argued that all the information is available, but rather than being easily findable from on starting point, it is scattered over several places (documentation on our website, wiki, metadata on bug reports, etc ).
Fedora and Mozilla both worked on this subject and did build a nice web application to make this easier and nicer. The result of this is asknot-ng.
A whatcanidofor.debian.org would be wonderful! Any takers? We can help by providing a virtual machine to build this. Being a DD is not mandatory. Everyone is welcome!
Cloud images for Debian.
This is a very important point since cloud providers are now major distributions consumers. We have to ensure that Debian is correctly integrated in the cloud, without making compromises on our values and philosophy.
I believe this item has been worked on during the last Debian Cloud sprint. I am looking forward to seeing the positive effects of this sprint in the long term. I believe it does help us to build a stronger relationship with cloud providers and gives us a nice opportunity to work with them on a shared set of goals!
During next DebConf, we can review the progress that has been made on each item and discuss new ones. In addition to this session acting as a health check, I see it as a way for the DPL to discuss, openly and publicly, about the important changes that should be implemented in the project and imagine together a better future.
In the meantime, everyone should feel free to pick one item from the list and work on it. :-)
The process leading to acceptation of new Debian Maintainers is mainly administrative today and is handled by the Newmaint team. In order to simplify this process further, the team wants to integrate their workflow into nm.debian.org's interface so that prospective maintainers can send their application online and the Newmaint team review it from within the website.
We need your help to implement the missing pieces into nm.debian.org. It is written in Python and using Django. If you have some experience with that, you should definitely join the newmaint-site mailing list and ask for the details. Enrico or someone else in the list will do their best to share their vision and explain the needed work in order to get this properly implemented!
It doesn't matter if you're already a Debian Developer to be able to contribute to this project. Anyone can step up and help!
My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me.
Debian LTS
I handled a new LTS sponsor that wanted to see wheezy keep supporting armel and armhf. This was not part of our initial plans (set during last Debconf) and I thus mailed all teams that were impacted if we were to collectively decide that it was OK to support those architectures. While I was hoping to get a clear answer rather quickly, it turns out that we never managed to get an answer to the question from all parties. Instead the discussion drifted on the more general topic of how we handle sponsorship/funding in the LTS project.
Fortunately, the buildd maintainers said they were OK with this and the ftpmasters had no objections, and they both implicitly enacted the decision: Ansgar Burchardt kept the armel/armhf architectures in the wheezy/updates suite when he handled the switch to the LTS team, and Aur lien Jarno also configured wanna-build to keep building armel/armhf for the suite. The DSA team did not confirm that this change was not interfering with one of their plans to decommission some hardware. Build daemons are a shared resource anyway and a single server is likely to handle builds for multiple releases.
DebConf 16
This month I registered for DebConf 16 and submitted multiple talk/BoF proposals:
Kali Linux s Experience of a Debian Derivative Based on Testing (Talk)
2 Years of Work of Paid Contributors in the Debian LTS Project (Talk)
Using Debian Money to Fund Debian Projects (BoF)
I want to share the setup we use in Kali as it can be useful for other derivatives and also for Debian itself to help smooth the relationship with derivatives.
I also want to open again the debate on the usage of money within Debian. It s a hard topic but we should really strive to take some official position on what s possible and what s not possible. With Debian LTS and its sponsorship we have seen that we can use money to some extent without hurting the Debian project as a whole. Can this be transposed to other teams or projects? What are the limits? Can we define a framework and clear rules? I expect the discussion to be very interesting in the BoF. Mehdi Dogguy has agreed to handle this BoF with me.
Packaging
Django. I uploaded 1.8.12 to jessie-backports and 1.9.5 to unstable. I filed two upstream bugs (26473 and 26474) for two problems spotted by lintian.
Unfortunately, when I wanted to upload it to unstable, the test suite did not ran. I pinned this down to a sqlite regression. Chris Lamb filed #820225 and I contacted the SQLite and Django upstream developers by email to point them to this issue. I helped the SQLite upstream author (Richard Hipp) to reproduce the issue and he was quick to provide a patch which landed in 3.12.1.
Later in the month I made another upload to fix an upgrade bug (#821789).
GNOME 3.20. As for each new version, I updated gnome-shell-timer to ensure it works with the new GNOME. This time I spent a bit more time to fix a regression (805347) that dates back to a while and that would never be fixed otherwise since the upstream author orphaned this extension (as he no longer uses GNOME).
I have also been bitten by display problems where accented characters would be displayed below the character that follows. With the help of members of the GNOME team, we found out that this was a problem specific to the cantarell font and was only triggered with Harfbuzz 1.2. This is tracked in Debian with #822682 on harfbuzz and #822762 in fonts-cantarell. There s a new upstream release (with the fix) ready to be packaged but unfortunately it is blocked by the lack of a recent fontforge in Debian. I thus mailed debian-mentors in the hope to find volunteers to help the pkg-fonts team to package a newer version
Misc Debian/Kali work
Distro Tracker. I started to mentor Vladimir Likic who contacted me because he wants to contribute to Distro Tracker. I helped him to setup his development environment and we fixed a few issues in the process.
Bug reports. I filed many bug reports, most of them due to my work on Kali:
#820288: a request to keep the wordpress package installable in older releases (due to renaming of many php packages)
#820867: possibility to apply overrides on already installed packages in reprepro
#821070: jessie to stretch upgrade problem with samba-vfs-modules
#822157: python-future hides and breaks python-configparser
#822669: dh_installinit inserts useless autoscript for System V init script when package doesn t contain any
#822670: dh-systemd should be merged into debhelper, we have systemd by default and debhelper should have proper support for it by default
I also investigated #819958 that was affecting testing since it has been reported to Kali as well. And I made an NMU of dh-make-golang to fix #819472 that I reported earlier.
Thanks
See you next month for a new summary of my activities.
The Debian Project Leader elections finished yesterday and the winner is Mehdi Dogguy!
Of a total of 1023 developers, 282 developers voted using the Condorcet method.
More information about the result is available in the Debian Project Leader Elections 2016 page.
The new term for the project leader starts today April 17th and expire on April 17th 2017.
It is time of the year where Debian project members should elect a new project leader. This year, only one candidate has stepped up, yours truly. As a reminder, my platform is published here. The campaign has been quite calm, comparing to past editions, which is not surprising given the number of candidates. There have been some interesting questions though as detailed below:
There are not many questions. It will take little time to read, if you haven't already.
Last but not least, please do vote! You have until 2016-04-16 23:59:59 UTC to vote (as announced here). It is very important to share your opinion and take part in the reflection around the future of the project. That every project member takes part in the evolutions that should be implemented to stay relevant and innovative in what we do.
It's that time of year again for the Debian Project: the elections of
its Project Leader!
Neil McGovern who has held the office for the last year will not be
seeking reelection. Debian Developers will have to choose between voting
for the only candidate running Mehdi Dogguy
or None Of The Above. If None Of The Above wins the election then
the election procedure is repeated, many times if necessary.
Mehdi Dogguy was a candidate for the DPL position last year, finishing
second with a close amount of votes to the winner Neil McGovern.
We are in the middle of the campaigning period that will last until April
2nd. The candidate and Debian contributors are expected to engage in
debates and discussions on the debian-vote mailing list.
The voting period starts on April 3rd, and during the following two
weeks, Debian Developers will vote to choose the person who will guide
the project for one year. The results will be published on April 17th
with the term for new the project leader starting immediately that same
day.
A little more than 3 months after our latest minor release, here is the new
major version of Gnocchi, stamped
2.0.0. It contains a lot of new and
exciting features, and I'd like to talk about some of them to celebrate!
You may notice that this release happens in the middle of the OpenStack release
cycle. Indeed, Gnocchi does not follow that 6-months cycle, and we release
whenever our code is ready. That forces us to have a more iterative approach,
less disruptive for other projects and allow us to achieve a higher velocity.
Applying the good old mantra release early, release often.
Documentation
This version features a large documentation update. Gnocchi is still the only
OpenStack server project that implements a "no doc, no merge" policy, meaning
any code must come with the documentation addition or change included in the
patch. The full documentation is included in the source code and available
online at gnocchi.xyz.
Data split & compression
I've already covered this change extensively in
my last blog about timeseries compression.
Long story short, Gnocchi now splits timeseries archives in small chunks that
are compressed, increasing speed and decreasing data size.
Measures batching support
Gnocchi now supports batching, which allow submitting several measures for
different metric in a single request. This is especially useful in the context
where your application tends to cache metrics for a while and is able to send
them in a batch. Usage is
fully documented for the REST API.
Group by support in aggregation
One of the most demanded features was the ability to do measure aggregation no
resource, using a group by type query. This is now possible using the
new groupby parameter to aggregation queries.
Ceph backend optimization
We improved the Ceph back-end a lot. Mehdi Abaakouk wrote a new Python binding
for Ceph, called Cradox, that is going to
replace the current Python rados module in the subsequent Ceph releases.
Gnocchi makes usage of this new module to speed things up, making the Ceph
based driver really, really faster than before. We also implemented
asynchronous data deletion, which improves performance a bit.
The next step will be to run some new benchmarks
like I did a few months ago and compare with the
Gnocchi 1.3 series. Stay tuned!
What happened in the reproducible
builds effort between December
27th and January 2nd:
Infrastructure
dak now silently accepts and discards .buildinfo files (commit 1, 2), thanks to Niels Thykier and Ansgar Burchardt. This was later confirmed as working by Mattia Rizzolo.
Packages fixed
The following packages have become reproducible due to changes in their
build dependencies:
banshee-community-extensions,
javamail,
mono-debugger-libs,
python-avro.
The following packages became reproducible after getting fixed:
fltk1.1/1.1.10-20 by Aaron M. Ucko, currently FTBFS.
fltk1.3/1.3.3-5 by Aaron M. Ucko, currently FTBFS.
reproducible.debian.net
The testing distribution (the upcoming stretch) is now tested on armhf. (h01ger)
Four new armhf build nodes provided by Vagrant Cascandian were integrated in the infrastructer. This allowed for 9 new armhf builder jobs. (h01ger)
The RPM-based build system, koji, is now in unstable and testing. (Marek Marczykowski-G recki, Ximin Luo).
Package reviews
131 reviews have been removed, 71 added and 53 updated in the previous week.
58 new FTBFS reports were made by Chris Lamb and Chris West.
New issues identified this week:
nondeterminstic_ordering_in_gsettings_glib_enums_xml,
nondeterminstic_output_in_warnings_generated_by_breathe, qt_translate_noop_nondeterminstic_ordering.
Misc.
Steven Chamberlain explained in length why reproducible cross-building across architectures mattered, and posted results of his tests comparing a stage1 debootstrapped chroot of linux-i386 once done from official Debian packages, the others cross-built from kfreebsd-amd64.
It is with great sadness that I learned of the passing of Ian Murdock. I have never had the chance to meet him. Several persons testify for his kindness and talent. We will always remember him. His legacy influences our lives everyday!
Looking at his latest blog posts, he seemed a bitnostalgic about Debian and still very proud of it.
Later, he wrote about how he came to find Linux and the importance of telling the story of hackers of his generation. In his memory, I'll reread Stephen Levy s Hackers for the nth time too.
This weekend is organized the Aaron Swartz Day across the world. There are events organized in many cities and video streams available. It is important that we remember Aaron's projects and fights. If you want to know more about Aaron Swartz, you may start by watching the excellent documentary The Internet's Own Boy : The Story of Aaron Swartz. His work was very inspirational and should not be forgotten!
Thanks to Mehdi Dogguy, here's a nice hook to generate a source
change file at build time (with pbuilder), so one can upload
source-only packages to the archive and have buildds rebuild for
all the architectures. Put it in .pbuilder/hooks/B10_source-build
so it gets called once the builds succeeds
#! /bin/sh
generate_change_file()
local version=$(dpkg-parsechangelog -Sversion)
local package=$(dpkg-parsechangelog -Ssource)
echo "Generating source changes file"
dpkg-genchanges -S > ../$ package _$ version _source.changes
cd /tmp/buildd/*/debian/..
generate_change_file
Next time you build a package, you should find, alongside the
<package>_<version>_<arch>.changes file, a
<package>_<version>_source.changes which you can use
with usual tools (lintian, debsign, dput ) to upload it to the
Debian archive.
Note that if you do that, you have to make sure that your
debian/rules support building separately the arch-dependent and
arch-independant packages. To check that, you can call pdebuild
like this:
pdebuild --debbuildopts -A # binary-only build, limited to arch-independant packages
pdebuild --debbuildopts -B # binary-only build, limited to arch-dependant packages
Stefano Rivera uploaded python-cffi/1.3.0-1 which makes the generated code order deterministic for anonymous unions and anonymous structs. Reported by Tristan Seligmann, and fixed uptream.
reproducible.debian.net
pbuilder has been updated to version 0.219~bpo8+1 on all eight build nodes. (Mattia Rizzolo, h01ger)
Packages that FTBFS but for which no open bugs have been recorded are now tested again after 3 days. Likewise for depwait packages. (h01ger)
Out of disk situations will not cause IRC notifications anymore. (h01ger)
Documentation update
Lunar continued to work on writing documentation for the future reproducible-builds.org website.
Package reviews
44 reviews have been removed, 81 added and 48 updated this week.
Chris West and Chris Lamb identified 70 fail to build from source issues.
Misc.
h01ger presented the project in Mexico City at the 3er Congreso de Seguridad de la Informaci n where it became clear that we lack academic papers related to reproducible builds.
Bryan has been doing hard work to improve reproducibility for OpenWrt. He wrote a report linking to the patches and test results he published.
Niels Thykier uploaded debhelper/9.20151004 which exports SOURCE_DATE_EPOCH when running dh_auto_* (patch by Dhole). dh now also calls dh_strip_nondeterminism during build (patch by Andrew Ayer). The only remaining change regarding reproducibility in the custom debhelper is related to mtimes in data.tar which might be fixed directly in dpkg instead.
Niels Thykier made another upload of debhelper/9.20151005 the next day to sort Build IDs added by dh_strip in control files.
Scott Kitterman fixed an issue with non-deterministic Depends generated by dh-python identified by Santiago Vila and Chris Lamb.
Lunar updated the patch against dpkg which makes the order of files in control.tar.gz deterministic using the new --sort=name option available in GNU Tar 1.28.
josch released sbuild version 0.66.0-1 with several fixes and improvements. The most notable one for reproducible builds is the new --build-path option and $build_path configuration variable added by akira which allows to explicitly chose a given build path.
Reiner Herrmann wrote a new patch for dh-systemd to sort the list of unit files in the generated maintainer scripts.
Packages fixed
The following packages became reproducible due to changes in their
build dependencies:
aoeui,
apron,
camlmix,
cudf,
findlib,
glpk-java,
hawtjni,
haxe,
java-atk-wrapper,
llvm-py,
misery,
mtasc,
ocamldsort,
optcomp,
spamoracle.
The following packages became reproducible after getting fixed:
reproducible.debian.net
ProfitBricks once again increased their support for reproducible builds in Debian and in other free software projects by adding 58 new cores and 138 GiB of RAM to the already existing setup. Two new amd64 build nodes and 16 new amd64 build jobs have been added which doubles the build capacity per day and allows us to spot many kind of problems earlier. The size of the tmpfs where builds are performed has also been increased from 70 to 200 GiB on all amd64 build nodes. Huge thanks!
When examining a package, a link now points to a table listing all previous recorded tests for the same package. (Mattia) The menu on the package pages has also been improved. (h01ger)
Packages in the depwait state are now rescheduled automatically after five days. (h01ger)
Links to documentation and other projects being tested have been made more visible on the landing page. (h01ger)
To reduce noise on the team IRC channel five different types of notifications have been turned into mail notifications. The remaining ones have been shortened and the status changes have been limited to unstable and experimental. (h01ger)
Maintainer notifications about status changes in a package will only be sent out once per day, and not on each status change. (h01ger)
diffoscope development
Some more experiments of concurrent processing have been made. None were good and reliable enough to be shared, though.
Package reviews
48 reviews have been removed, 189 added and 23 updated this week.
9 FTBFS bugs were reported by Chris Lamb.
Misc.
h01ger met with Levente Polyak to discuss testing Arch Linux on Debian continuous test system with an easily extensible framework. The idea is to also allow testing of other distributions, and provide a nice package based view like the one for Debian.
We've been hard working with the Gnocchi team these last months to store your
metrics, and I guess it's time to show off a bit.
So far Gnocchi offers scalable metric storage and resource indexation,
especially for OpenStack cloud but not only, we're generic. It's cool to
store metrics, but it can be even better to have a way to visualize them!
Prototyping
We very soon started to build a little HTML interface. Being REST-friendly
guys, we enabled it on the same endpoints that were being used to retrieve
information and measures about metric, sending back text/html instead of
application/json if you were requesting those pages from a Web browser.
But let's face it: we are back-end developers, we suck at any kind front-end
development. CSS, HTML, JavaScript? Bwah! So what we built was a starting
point, hoping some magical Web developer would jump in and finish the job.
Obviously it never happened.
Ok, so what's out there?
It turns out there are back-end agnostic solutions out there, and we decided to
pick Grafana. Grafana is a complete graphing dashboard
solution that can be plugged on top of any back-end. It already supports
timeseries databases such as Graphite, InfluxDB and OpenTSDB.
That was largely enough for that my fellow developer
Mehdi Abaakouk to jump in and start writing a
Gnocchi plugin for Grafana! Consequently, there is now a basic but solid and
working back-end for Grafana that lies in the
grafana-plugins
repository.
With that plugin, you can graph anything that is stored in Gnocchi, from raw
metrics to metrics tied to resources. You can use templating, but no annotation
yet.
The back-end supports Gnocchi with or without Keystone involved, and any type
of authentication (basic auth or Keystone token). So yes, it even works if
you're not running Gnocchi with the rest of OpenStack.
It also supports advanced queries, so you can search for resources based on
some criterion and graphs their metrics.
I want to try it!
If you want to deploy it, all you need to do is to install Grafana and its
plugins, and create a new datasource pointing to Gnocchi. It is that simple.
There's some CORS middleware configuration involved if you're planning on using
Keystone authentication, but it's pretty straightforward just set the
cors.allowed_origin option to the URL of your Grafana dashboard.
We added support of Grafana directly in Gnocchi devstack plugin. If you're
running DevStack you can follow
the instructions
which are basically adding the line enable_service gnocchi-grafana.
Moving to Grafana core
Mehdi just opened a pull request
a few days ago to merge the plugin into Grafana core. It's actually one of the
most unit-tested plugin in Grafana so far, so it should be on a good path to be
merged in the future and have support of Gnocchi directly into Grafana without
any plugin involved.
St phane Glondu uploaded dh-ocaml/1.0.10 which now generates *.info with a deterministic order. Original patch by Chris Lamb. St phane also uploaded ocaml/4.02.3-1 to experimental which enables ocamldoc to build reproducible manpages using a patch by Valentin Lorentz.
Paul Gevers uploaded pasdoc/0.14.0-1 with upstream changes which should make the generated documentation reproducible by default.
Osamu Aoki uploaded debiandoc-sgml/1.2.31-1 adding spport for a DEBIANDOC_DATE environment variable to override the content of the <date> tag.
Dmitry Shachnev uploaded sphinx/1.3.1-4 which fixes many reproducibility issues and add support for SOURCE_DATE_EPOCH.
#795438 on wims-extra by Chris Lamb: ask grep to cope with non-UTF8 files.
#795441 on aprx by Chris Lamb: use SOURCE_DATE_EPOCH as source for the manpage date instead of the currentdate.
#795462 on ogre-1.9 by Chris Lamb: removes timestamps from the documentation system.
#795484 on ruby-rmagick by Chris Lamb: patch the bindings to allow the PRNG seed to be set, and set it to a fixed value when generating examples.
#795562 on htp by Chris Lamb: export TZ=UTC in debian/rules.
akira found another embedded code copy of texi2html in maxima.
reproducible.debian.net
Work on testing several architectures has continued. (Mattia/h01ger)
Package reviews
29 reviews have
been removed, 187 added and 34 updated this week.
172 new FTBFS reports were filled, 137 solely by Chris West (Faux).
josch spent time investigating the issue with fonts in PDF files.
Chris Lamb documented the issue affecting documentation generated by ocamldoc.
Misc.
Lunar presented a general Reproducible builds HOWTO talk at the Chaos Communication Camp 2015 in Germany on August 13th. Recordings are already available, as well as slides and script.
h01ger and Lunar also used CCCamp15 as an opportunity to have discussions with members of several different projects about reproducible builds. Good news should be coming soon.
It has been close to a year now that I've incorporated my new company, Mergify. I've been busy, and I barely wrote anything about it so far. Now is an excellent time to take a break and reflect a bit on what happened during those last 12 months.
Example of rule matching returned in GitHub checks
Some people like to make bots talk to each other.
Mergify
If you're curious, you can read this article.
GitHub service status is not always green.
Here is my monthly update covering what I have been doing in the free software world (
Many of you are big fans of 
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
What happened in the 
Thanks to Mehdi Dogguy, here's a nice hook to generate a source
change file at build time (with pbuilder), so one can upload
source-only packages to the archive and have buildds rebuild for
all the architectures. Put it in .pbuilder/hooks/B10_source-build
so it gets called once the builds succeeds
