If you've been following on IRC, you may have noticed that releasing
Cockpit 132 failed yesterday. Here's why, and how it's been solved.
In general we want the entire release process to be completely
automatic, with all failures detected before hand.
Earlier this week I made a pull request that passed integration tests,
but broke the continuous delivery:
The symptom was that certain files we installed in 'make install' when
they shouldn't have been installed there. But the root cause was that we
were building RPMs differently during integration tests, and later
To solve this problem I added patches to the release-132 branch to fix
this problem, and then ran the continuous delivery scripts manually from
... in the cockpit/infra-release container ...
$ git fetch origin
$ git checkout release-132
$ RELEASE_SINK= RELEASE_TAG=132 release-runner -v
What this does is use the 132 git tag to create a tarball, and then any
commits after that are included in the SRPM as patches.
So how do we prevent this from happening again?
1. Build RPMs during integration more like release:
2. Cleanup the code related to 'make install' and 'make install-tests'
3. Document how to solve this in the future (this email).
4. I noticed that the release-dsc file does not consider patches the
way that release-srpm does. This needs a fix, any takers?
This wasn't a problem this time around because the patches did
not affect debian builds.
5. Figure out how to test upgrading. Martin Pitt caught it this time,
but it should have failed before going in:
Hi Cockpit people,
A while ago the ABRT team presented  Cockpit module showing problems detected by ABRT and allowing users to report them. It was more less a proof of concept. But we are eager to finish this effort.
After speaking with some members of the Cockpit team on DevConf we were advised to start by writing user stories. We did so and today I presented them on the wikipage of cockpit's github .
We would love to have a feedback from you. What do you think of this? Is it suitable for Cockpit?
We are open-minded to yours ideas.
#cockpit: weekly meeting
Meeting started by mvollmer at 14:03:34 UTC. The full logs are available
* Agenda (mvollmer, 14:05:12)
* Outreachy (mvollmer, 14:08:26)
Meeting ended at 14:18:52 UTC.
Action Items, by person
People Present (lines said)
* mvollmer (9)
* dperpeet (9)
* zodbot (5)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
We currently have a planned feature to clean up/improve our config format for
known (remote) machines:
This is a bit thin and not easy to understand/rationalize. So I took this plus
what I remembered from last week's discussion plus some thoughts what would
make sense and wrote a draft for what we want to achieve and how it should look
I'd appreciate some feedback about whether this makes sense, and opinions about
the per-user → global SSH host key transfer .
 My personal opinion is that we should not second-guess what SSH does and
STOP doing it.