Some Place for Mehttps://bblank.thinkmo.de/2023-10-03T19:00:00+02:00Myself, the World and EverythingIntroducing uploads to Debian by git tag2023-10-03T19:00:00+02:002023-10-03T19:00:00+02:00Bastian Blanktag:bblank.thinkmo.de,2023-10-03:/introducing-uploads-debian-git.html<p>We like to revisit the discussion about simple git tags used for Debian uploads.</p><p>Several years ago, several people proposed a mechanism to upload packages to Debian just by <a href="https://people.debian.org/~iwj/tag2upload/draft/">doing "git tag" and "git push"</a>.
Two not too long discussions on <code>debian-devel</code> (<a href="https://people.debian.org/~iwj/tag2upload/draft/">first</a> and <a href="https://people.debian.org/~iwj/tag2upload/draft/">second</a>) did not end with an agreement how this mechanism could work.<sup id="fnref:1"><a class="footnote-ref" href="#fn:1">1</a></sup>
The central problem was the ability to properly trace uploads back to the ones who authorised it.</p>
<p>Now, several years later and after re-reading those e-mail threads, I again was stopped at the question: can we do this?
Yes, it would not be just "git tag", but could we do with close enough?
I have some rudimentary code ready to actually do <a href="https://salsa.debian.org/lvm-team/lvm2/-/merge_requests/10">uploads from the CI</a>.
However the list of caveats are currently pretty long.</p>
<p>Yes, it works in principle.
It is still disabled here, because in practice it does not yet work.</p>
<h2>Problems with this setup</h2>
<p>So what are the problems?</p>
<p>It requires the git tags to include the both signed files for a successful source upload.
This is solved by a new tool that could be a git sub-command.
It just creates the source package, signs it and adds the signed file describing the upload (the <code>.dsc</code> and <code>.changes</code> file) to the tag to be pushed.
The CI then extracts the signed files from the tag message and does it's work as normal.</p>
<p>It requires a sufficiently reproducible build for source packages.
Right now it is only known to work with the special <a href="https://bblank.thinkmo.de/introducing-dpkg-format-gitarchive.html"><code>3.0 (gitarchive)</code> source format</a>, but even that requires the latest version of this format.
No idea if it is possible to use others, like <code>3.0 (quilt)</code> for this purpose.</p>
<p>The shared GitLab runner provides by <a href="https://salsa.debian.org/">Salsa</a> do not allow ftp access to the outside.
But Debian still uses ftp to do uploads.
At least if you don't want to share your ssh key, which can't be restricted to uploads only, but ssh would not work either.
And as the current host for those builds, the Google Cloud Platform, does not provide connection tracking support for ftp, there is no easy way to allow that without just allowing everything.
So we have no way to currently actually perform uploads from this platform.</p>
<h2>Further work</h2>
<p>As this is code running in a CI under the control of the developer, we can easily do other workflows.
Some teams do workflows that do tags after acceptance into the Debian archive.
Or they don't use tags at all.
With some other markers, like variables or branch names, this support can be expanded easily.</p>
<p>Unrelated to this task here, we might want to think about tying the <code>.changes</code> files for uploads to the target archive.
As this code makes all of them readily available in form of tag message, replaying them into possible other archives might be more of a concern now.</p>
<h2>Conclusion</h2>
<p>So to come back to the question, yes we can.
We can prepare uploads using our CI in a way that they would be accepted into the Debian archive.
It just needs some more work on infrastructure.</p>
<div class="footnote">
<hr>
<ol>
<li id="fn:1">
<p>Here I have to admit that, after reading it again, I'm not really proud of my own behaviour and have to apologise. <a class="footnote-backref" href="#fnref:1" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
</ol>
</div>Salsa updated to GitLab 13.72020-12-28T12:00:00+01:002020-12-28T12:00:00+01:00Bastian Blanktag:bblank.thinkmo.de,2020-12-28:/salsa-updated-to-gitlab-137.html<p>Debian Salsa updated to GitLab 13.7 with several new features.</p><p>Yesterday, Debian Salsa was updated to the new GitLab 13.7 upstream release.
As always, this new release comes with a bunch of new features.</p>
<h2>GitLab 13.7</h2>
<p>GitLab 13.7 includes a bunch of new features.
See the <a href="https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/">upstream release posting</a>
for a full list.</p>Salsa updated to GitLab 13.52020-10-22T20:00:00+02:002020-10-22T20:00:00+02:00Bastian Blanktag:bblank.thinkmo.de,2020-10-22:/salsa-updated-to-gitlab-135.html<p>Debian Salsa updated to the recent GitLab 13.5 release with several new features.</p><p>Today, GitLab released the version 13.5 with several new features.
Also Salsa got some changes applied to it.</p>
<h2>GitLab 13.5</h2>
<p>GitLab 13.5 includes several new features.
See the <a href="https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/">upstream release postfix</a>
for a full list.</p>
<h2>Shared runner builds on larger instances</h2>
<p>It's been way over two years since we started to use <a href="https://cloud.google.com/compute">Google Compute Engine (GCE)</a> for Salsa.
Since then, all the jobs running on the shared runners run within a <a href="https://cloud.google.com/compute/docs/machine-types#n1_machine_types"><code>n1-standard-1</code></a> instance,
providing a fresh set of one vCPU and 3.75GB of RAM for each and every build.</p>
<p>GCE supports several new instance types, featuring better and faster CPUs, including current AMD EPICs.
However, as it turns out, GCE does not support any single vCPU instances for any of those types.
So jobs in the future will use <a href="https://cloud.google.com/compute/docs/machine-types#n2d_machine_types"><code>n2d-standard-2</code></a> for the time being,
provinding <strong>two</strong> vCPUs and <strong>8GB</strong> of RAM..</p>
<h2>Builds run with IPv6 enabled</h2>
<p>All builds run with IPv6 enabled in the Docker environment.
This means the <code>lo</code> network device got the IPv6 loopback address <code>::1</code> assigned.
So tests that need minimal IPv6 support can succeed.
It however does <strong>not</strong> include any external IPv6 connectivity.</p>Booting Debian on ThinkPad X13 AMD2020-09-30T19:00:00+02:002020-09-30T19:00:00+02:00Bastian Blanktag:bblank.thinkmo.de,2020-09-30:/booting-debian-on-thinkpad-x13-amd.html<p>Got a bleeding ThinkPad X13 with Windows. Need Debian.</p><p>Running new hardware is always fun.
The problems are endless.
The solutions not so much.</p>
<p>So I've got a brand new ThinkPad X13 AMD.
It features an AMD Ryzen 5 PRO 4650U, 16GB of RAM and a 256GB NVME SSD.
The internal type identifier is <a href="https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x13-type-20uf-20ug" rel="nofollow">20UF</a>.
It runs the latest firmware as of today with version 1.09.</p>
<p>So far I found two problems with it:</p>
<ul>
<li>It refuses to boot my Debian image with Secure Boot enabled.</li>
<li>It produces ACPI errors on every key press on the internal keyboard.</li>
</ul>
<h2>Disable Secure Boot</h2>
<p>The system silently fails to boot a signed shim and grub from an USB thumb drive.
I used on of the Debian Cloud images, which should properly work in this setup and do on my other systems.</p>
<p>The only fix I found was to disable Secure Boot alltogether.</p>
<h2>Select Linux in firmware</h2>
<p>Running a Linux 5.8 with default firmware setting produces ACPI errors on each key press.</p>
<div class="highlight"><pre><span></span><code>ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GPP3], AE_NOT_FOUND (20200528/psargs-330)
ACPI Error: Aborting method \_SB.GPIO._EVT due to previous error (AE_NOT_FOUND) (20200528/psparse-529)
</code></pre></div>
<p>This can be "fixed" by setting a strategic setting inside the firmware:<br>
<code>Config</code> > <code>Power</code> > <code>Sleep State</code> to <code>Linux</code></p>Salsa hosted 1e6 CI jobs2020-09-16T21:00:00+02:002020-09-16T21:00:00+02:00Bastian Blanktag:bblank.thinkmo.de,2020-09-16:/salsa-hosted-1e6-ci-jobs.html<p>Today, Salsa hosted it's 1,000,000th CI job.
The price for hitting the target goes to the <a href="https://wiki.debian.org/Teams/Cloud">Cloud team</a>.
The <a href="https://salsa.debian.org/cloud-admin-team/debian-cloud-images-daily/-/jobs/1000000">job</a> itself was not that interesting, but it was successful.</p>Introducing dpkg source format for git repositories2019-12-19T23:00:00+01:002019-12-19T23:00:00+01:00Bastian Blanktag:bblank.thinkmo.de,2019-12-19:/introducing-dpkg-format-gitarchive.html<p>There is a large disagreement inside Debian on how a git repository used for Debian packages should look like.
You just have to read debian-devel to get too much of it.</p>
<p>Some people prefer that the content of the repository looks like a "modern" (3.0) source package the Debian …</p><p>There is a large disagreement inside Debian on how a git repository used for Debian packages should look like.
You just have to read debian-devel to get too much of it.</p>
<p>Some people prefer that the content of the repository looks like a "modern" (3.0) source package the Debian archive accepts.
This means it includes upstream source and stuff in <code>debian/patches</code> that need to get applied first to have something usable.
But by definition this concept is incompatible with a normal git workflow;
e.g. you can't use cherry-pick of upstream patches, but need to convert it into a patch file either by hand or with another tool.
It also can't use upstream test definitions using a CI without adopting it and patching source first.</p>
<p>Other people prefer to have a complete patched source available always.
This allows for use of cherry-pick and all the other git concepts available.
But due to the way our "modern" (3.0) source formats are definied,
it is impossible to use those together.
So everyone wanting to use this can only use ancient 1.0 source packages,
which lack a lot of features like modern compression formats.</p>
<p>Some do stuff that is much more weird.
Weird things like <code>git-dpm</code>, which is also incompatible with merges.
But we can't save everyone.</p>
<p>I started working on bridging the gap between a proper git repository and modern Debian source package by building a source package from some special target in <code>debian/rules</code>.
But people maybe rightfully complained that not be able to use <code>dpkg-source</code> got a big downside and needs a lot of documentation.
To get this into proper shape,
I'd like to introduce a new dpkg source format.</p>
<h2>New source format</h2>
<p>The package <a href="https://salsa.debian.org/waldi/dpkg-source-gitarchive"><code>dpkg-source-gitarchive</code></a> defines a new source format <code>3.0 (gitarchive)</code>.
This format doesn't represent a real source package format,
but uses a plain git repository as input to create a <code>3.0 (quilt)</code> source package that the Debian archive accepts.</p>
<p>This software got some currently hardcoded expectations on how things look like:</p>
<ul>
<li>The git tree must not contain <code>debian/patches</code>, instead all Debian patches are applied as git commits.</li>
<li>The file <code>debian/source/format</code> exists in the latest commit, not only in an uncommited file.</li>
<li>Original tarballs needs to be managed with <code>pristine-lfs</code> and must be compress using xz.</li>
<li>Tags for upstream sources called <code>upstream/$version</code> need to exist.</li>
</ul>
<p>Implementing this as a dpkg source format allows for a better user experience.
You can build a new source package both from the git repository and an existing source package by using <code>dpkg-source</code>/<code>dpkg-buildpackage</code> and don't need to use special tools.
No special tools or special targets in <code>debian/rules</code> are needed to manage sources to be uploaded.</p>
<h2>Open questions</h2>
<ul>
<li>Is it a good idea to implement a pretty specific set of requirements as dpkg source format and make it an interface?</li>
<li>Is enforcing a repository based handling of upstream tarballs, for now only with <code>pristine-lfs</code> a good idea?</li>
<li>Should it also handle debian version tags?</li>
</ul>
<p>*edit: package name was changed from <code>dpkg-format-gitarchive</code> to <code>dpkg-source-gitarchive</code>.</p>Google Cloud backed Debian mirror2017-12-21T09:45:00+01:002017-12-21T09:45:00+01:00Bastian Blanktag:bblank.thinkmo.de,2017-12-21:/google-cloud-backed-debian-mirror.html<p>It's been some time that someone at Google told us that they had problems providing a stable mirror of Debian for use by their cloud platform.
I wanted to give it a try and see what the platform can give us.
At this time I was already responsible for the …</p><p>It's been some time that someone at Google told us that they had problems providing a stable mirror of Debian for use by their cloud platform.
I wanted to give it a try and see what the platform can give us.
At this time I was already responsible for the Debian mirror network inside Microsoft Azure.</p>
<p>So I started to generalize a setup of Debian mirrors in cloud environments.
I applied the setup to both Google Cloud Engine and Amazon EC2.
The setup on the Google Cloud works pretty fine.
I scraped the EC2 setup for now, as it can neither provide the throughput, nor the inter-region connectivity to at a level that can compete with Google.</p>
<p>So I'd like to proudly present a test setup of a Google Cloud backed Debian mirror.
It provides access to the <a href="http://debian.gce-test.mirrors.debian.org/debian/">main</a> and <a href="http://security.gce-test.mirrors.debian.org/debian-security/">security</a> archive.
I would be glad to see a bit more traffic on it.
I'd like to asses if there are problems, both with synchronicity and reacheability.</p>
<p>They can be used by adding one of the following to your <code>sources.list</code>:</p>
<div class="highlight"><pre><span></span><code><span class="k">deb</span><span class="w"> </span><span class="s">http://debian.gce-test.mirrors.debian.org/debian</span><span class="w"> </span><span class="kp">stretch</span><span class="w"> </span><span class="kp">main</span><span class="w"> </span><span class="kp">contrib</span><span class="w"> </span><span class="kp">non-free</span>
<span class="k">deb</span><span class="w"> </span><span class="s">http://debian.gce-test.mirrors.debian.org/debian</span><span class="w"> </span><span class="kp">buster</span><span class="w"> </span><span class="kp">main</span><span class="w"> </span><span class="kp">contrib</span><span class="w"> </span><span class="kp">non-free</span>
<span class="k">deb</span><span class="w"> </span><span class="s">http://debian.gce-test.mirrors.debian.org/debian</span><span class="w"> </span><span class="kp">sid</span><span class="w"> </span><span class="kp">main</span><span class="w"> </span><span class="kp">contrib</span><span class="w"> </span><span class="kp">non-free</span>
<span class="k">deb</span><span class="w"> </span><span class="s">http://debian.gce-test.mirrors.debian.org/debian</span><span class="w"> </span><span class="kp">experimental</span><span class="w"> </span><span class="kp">main</span><span class="w"> </span><span class="kp">contrib</span><span class="w"> </span><span class="kp">non-free</span>
</code></pre></div>
<p>If you do and see problems, please report them back to me at <a href="mailto:waldi@debian.org">waldi@debian.org</a>.
Also please note that Google stores load balancer logs for seven days, including the client IP.</p>Network caps in cloud environments2017-08-12T23:00:00+02:002017-08-12T23:00:00+02:00Bastian Blanktag:bblank.thinkmo.de,2017-08-12:/network-caps-in-cloud-environments.html<p>Providing working network is not easy. Providing enough troughput is not easy either.</p><p>Providing working network is not easy.
All the cloud providers seem to know how to do that most of the time.
Providing enough troughput is not easy either.
Here it get's interresting as the cloud providers tackle that problem with completely different results.</p>
<p>There are essentially three large cloud providers.
The oldest and mostly known cloud provider is
<a href="https://aws.amazon.com/" rel="nofollow">Amazon Web Services</a> (AWS).
Behind that follow Microsoft with
<a href="https://azure.microsoft.com/" rel="nofollow">Azure</a> and the
<a href="https://cloud.google.com/" rel="nofollow">Google Cloud Platform</a> (GCP).
Some public instances of OpenStack exist, but they simply
<a href="https://www.slideshare.net/isotopp/openstack-im-reality-check-47018040" rel="nofollow">don't count anyway</a>.
So we remain with three and they tackle this problem with widely different results.</p>
<p>Now, what network troughput is necessary for real world systems anyway?
An old friend gives the advice: 1Gbps per Core of uncongested troughput within the complete infrastructure is the minimum.
A generalization of this rule estimates around 1bps per clock cycle and core, so a 2GHz core would need 2Gbps.
Do you even get a high enough network cap at your selected cloud provider to fill any of these estimates?</p>
<p>Our first provider, AWS, publishes a nice list of
<a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-ec2-config.html" rel="nofollow">network caps</a>
for some of there instance types.
The common theme in this list is:
for two cores (all the <code>*.large</code> types) you get 500Mbps,
for four cores (<code>*.xlarge</code>) you get 750Mbps and
for eight cores (<code>*.2xlarge</code>) you get 1000Mbps.
This is way below our estimate shown above and does not even raise linear with the number of cores.
But all of this does not really matter anyway, as the performance of AWS is the worst of the three providers.</p>
<p>Our second provider, Azure, seems to not publish any real information about network caps at all.
From my own knowledge it is 50MBps (500Mbps) per core for at least the smaller instances.
At least is scales linear with instance size, but is still way below our estimates.</p>
<p>Our third provider, GCP, documents a
<a href="https://cloud.google.com/compute/docs/networks-and-firewalls#egress_throughput_caps" rel="nofollow">simple rule for network caps</a>:
2Gbps per core.
This matches what we estimated.</p>
<p>Now the most important question: does this estimate really work and can we actually fill it.
The answer is not easy.
A slightly synthetic test of a HTTP server with cached static content showed that it can easily reach 7Gbps on a 2GHz Intel Skylake core.
So yes, it gives a good estimate on what network troughput is needed for real world applications.
However we still could easily file pipe that is larger by a factor of three.</p>New blog featuring Pelican2017-06-11T20:00:00+02:002017-06-11T20:00:00+02:00Bastian Blanktag:bblank.thinkmo.de,2017-06-11:/new-blog-featuring-pelican.html<p>For years I used a working blog setup using <a href="http://www.zope.org/en/latest/">Zope</a>, <a href="https://plone.org/">Plone</a> and <a href="http://www.contentmanagementsoftware.info/plone/quills">Quills</a>.
Quills was neglected for a long time and made me stuck at the aging Plone 4.2.
There seems to be some work done in the last year, but I did not really care.
Also this whole …</p><p>For years I used a working blog setup using <a href="http://www.zope.org/en/latest/">Zope</a>, <a href="https://plone.org/">Plone</a> and <a href="http://www.contentmanagementsoftware.info/plone/quills">Quills</a>.
Quills was neglected for a long time and made me stuck at the aging Plone 4.2.
There seems to be some work done in the last year, but I did not really care.
Also this whole setup was just a bit too heavy for what I actually use it for.
Well, static page generators are the new shit, so there we are.</p>
<p>So here is it, some new blog, nice and shiny, which I hope to stop neglecting.
The blog is managed in a <a href="https://git.thinkmo.de/bblank/bblank.thinkmo.de">Git repository</a>.
This repository is hosted on a private <a href="https://about.gitlab.com/">GitLab</a> instance.
It uses <a href="https://blog.getpelican.com/">Pelican</a> to generate shiny pages and is run via the GitLab CI.
The finished pages are served by a, currently not highly available, instance of GitLab Pages (yes, this is one of the parts they copied from Github first).</p>
<p>So let's see if this setup makes me more comfortable.</p>