Client Challenge

#bundlewrap is almost ready to be released in version 5.0.0 👀

https://github.com/bundlewrap/bundlewrap/milestone/12

Thanks to everyone who put in their hard work this week to give this a push and make it happen.

My first tag2upload upload

Tag2upload?

The tag2upload service has finally gone live for Debian Developers in an open beta.

If you’ve never heard of tag2upload before, here is a great primer presented by Ian Jackson and prepared by Ian Jackson and Sean Whitton.

In short, the world has moved on to hosting and working with source code in Git repositories. In Debian, we work with source packages that are used to generated the binary artifacts that users know as .deb files. In Debian, there is so much tooling and culture built around this. For example, our workflow passes what we call the island test – you could take every source package in Debian along with you to an island with no Internet, and you’ll still be able to rebuild or modify every package. When changing the workflows, you risk losing benefits like this, and over the years there has been a number of different ideas on how to move to a purely or partially git flow for Debian, none that really managed to gain enough momentum or project-wide support.

Tag2upload makes a lot of sense. It doesn’t take away any of the benefits of the current way of working (whether technical or social), but it does make some aspects of Debian packages significantly simpler and faster. Even so, if you’re a Debian Developer and more familiar with how the sausage have made, you’ll have noticed that this has been a very long road for the tag2upload maintainers, they’ve hit multiple speed bumps since 2019, but with a lot of patience and communication and persistence from all involved (and almost even a GR), it is finally materializing.

Performing my first tag2upload

So, first, I needed to choose which package I want to upload. We’re currently in hard freeze for the trixie release, so I’ll look for something simple that I can upload to experimental.

I chose bundlewrap, it’s quote a straightforward python package, and updates are usually just as straightforward, so it’s probably a good package to work on without having to deal with extra complexities in learning how to use tag2upload.

So, I do the usual uscan and dch -i to update my package…

And then I realise that I still want to build a source package to test it in cowbuilder. Hmm, I remember that Helmut showed me that building a source package isn’t necessary in sbuild, but I have a habit of breaking my sbuild configs somehow, but I guess I should revisit that.

So, I do a dpkg-buildpackage -S -sa and test it out with cowbuilder, because that’s just how I roll (at least for now, fixing my local sbuild setup is yak shaving for another day, let’s focus!).

I end up with a binary that looks good, so I’m satisfied that I can upload this package to the Debian archives. So, time to configure tag2upload.

The first step is to set up the webhook in Salsa. I was surprised two find two webhooks already configured:

I know of KGB that posts to IRC, didn’t know that this was the mechanism it does that by before. Nice! Also don’t know what the tagpending one does, I’ll go look into that some other time.

Configuring a tag2upload webhook is quite simple, add a URL, call the name tag2upload, and select only tag push events:

I run the test webhook, and it returned a code 400 message about a missing ‘message’ header, which the documentation says is normal.

Next, I install git-debpush from experimental.

The wiki page simply states that you can use the git-debpush command to upload, but doesn’t give any examples on how to use it, and its manpage doesn’t either. And when I run just git-debpush I get:

jonathan@lapcloud:~/devel/debian/python-team/bundlewrap/bundlewrap-4.23.1$ git-debpush
git-debpush: check failed: upstream tag upstream/4.22.0 is not an ancestor of refs/heads/debian/master; probably a mistake ('upstream-nonancestor' check)
pristine-tar is /usr/bin/pristine-tar
git-debpush: some check(s) failed; you can pass --force to ignore them

I have no idea what that’s supposed to mean. I was also not sure whether I should tag anything to begin with, or if some part of the tag2upload machinery automatically does it. I think I might have tagged debian/4.23-1 before tagging upstream/4.23 and perhaps it didn’t like it, I reverted and did it the other way around and got a new error message. Progress!

jonathan@lapcloud:~/devel/debian/python-team/bundlewrap/bundlewrap-4.23.1$ git-debpush
git-debpush: could not determine the git branch layout
git-debpush: please supply a --quilt= argument

Looking at the manpage, it looks like –quilt=baredebian matches my package the best, so I try that:

jonathan@lapcloud:~/devel/debian/python-team/bundlewrap/bundlewrap-4.23.1$ git-debpush --quilt=baredebianEnumerating objects: 70, done.Counting objects: 100% (70/70), done.Delta compression using up to 12 threadsCompressing objects: 100% (37/37), done.Writing objects: 100% (37/37), 8.97 KiB | 2.99 MiB/s, done.Total 37 (delta 30), reused 0 (delta 0), pack-reused 0 (from 0)To salsa.debian.org:python-team/packages/bundlewrap.git6f55d99..3d5498f debian/master -> debian/master * [new tag] upstream/4.23.1 -> upstream/4.23.1 * [new tag] debian/4.23.1-1_exp1 -> debian/4.23.1-1_exp1

Ooh! That looked like it did something! And a minute later I received the notification of the upload in my inbox:

So, I’m not 100% sure that this makes things much easier for me than doing a dput, but, it’s not any more difficult or more work either (once you know how it works), so I’ll be using git-debpush from now on, and I’m sure as I get more used to the git workflow of doing things I’ll understand more of the benefits. And at last, my one last use case for using FTP is now properly dead. RIP FTP :)

#bundlewrap #Debian #IanJackson #SeanWhitton #tag2upload

Wait, neither #pyinfra nor #BundleWrap run actual Python code on the remote hosts, right? They're apparently both basically just fancy wrappers for running shell commands, mainly via SSH.

In contrast, #Ansible _does_ run Python on the remote side. Which means that Python is required to be installed, but also means that you can do more sophisticated stuff than parsing CLI tool output. 🤔

I found the #bundlewrap config management system this week and had an itch to try it out.

https://docs.bundlewrap.org/guide/quickstart/

To play around with it more easily (and check the package I made for @openSUSE) I created a #vagrant setup (using vagrant-libvirt as usual):

https://github.com/johanneskastl/bundlewrap_vagrant_libvirt_ansible

This sets up a #Tumbleweed VM and prepares everything the vagrant user needs inside the VM so you can just log in and start playing with bundlewrap. Have a lot of fun...

#configmanagement #bundlewrap #vagrant #libvirt #opensuse

Quickstart - BundleWrap

Not sure I am totally happy with the #bundlewrap documentation. It took me I don’t know how long to find out how a bundle depends on an installed package.
Task des Tages: Config für einen Juniper EX4200 mittels #bundlewrap und #netbox zusammenbauen und deployen.
Irgendwer hier hatte doch ein #bundlewrap Item, um automatisiert SSH-Keys zu generieren, wer war das nochmal? Habs vergessen :(
Sorry for the quick downtime, I finally switched this server's config management to #bundlewrap 🎉

Ah, finally we have also transferred the DNS/DHCP config to #bundlewrap.

Currently node networking is not modularized yet, so all network mapping is present in a huge dictionary - I want to fix this at some time to have each node add itself to some network configuration. And I'm still amazed at how much faster it is than Ansible 🎉