And now for your kind attention, the devuan-dev meet notes for
Thursday, November 28th, 2019.

plasma41

------------------------------------------------------------------------

# Devuan meet Nov. 28, 2019 @20:30 UTC

Pad is here:
https://pad.dyne.org/code/#/2/code/edit/-P6CnsejXviL4GArbot-Bdhl/

Meet here: https://vdc.dyne.org/devuan
   * Please post notes prior to the meet.
   * Please add your name as 'Present' below when you get to the
     meet.
   * When adding a comment in someone else's notes, please
     pre-pend your name like this: (whoever) whatever . . .

Present: LeePen, golinux, kramer, rrq


## Old Business


## Old Actions
- 2.1 announcement sent

### rrq
- armel-builder still inching forward (due to old-man stubbornness); the
VM is "ready", and now the ganeti wrapping is wrought into shape. The
(new) pipeline is set up to build "armel" on armhf-builder meanwhile.

### New Build Pipeline (LeePen)

Thanks to lots of help from rrq the new pipeline and dak is available
for testing.

#### Structure

1. Releasebot run by cron on dak.localnet gets jobs assigned to
   releasebot from gitlab and sends them to jenkins on ci.localnet
   (https://jenkins.devuan.dev).
2. Jenkins builds as directed by existing templates or new ones provided
   by releasebot:
   - source on master (ci.localnet)
   - binaries on slave nodes
   - repos by rsyncing master to dak.localnet and running
     ~dak/bin/add_pkgs script (all as user dak)

{* This is as far as I have implemented *}
3. ~dak on dak.localnet rsyncs to pkgmaster
4. Amprolla runs on amprolla.localnet just for pkgmaster.d.o.

#### Switching

- The entire existing archive has been imported to the new dak.

The only outstanding packages that I am aware of are debian-installer
(until I resolve the required Built-Using sources).

(leepen) This is resolved as of 1800 UTC today and everything has now
been imported.

- To test new pipeline and dak you should:-
  1. Ensure source is a version is not already in the old dak.
     Practically this probably means a version bump of anything that has
     previously been built, even if only partially successfully.
  2. (Optionally) reconfigure build jobs. This requires extra perms.
     However, I have implemented an ugly hack so that existing jobs do
     not *absolutely* need to be reconfigured to work.
  3. Open an assign a new build issue to **releasebot**.

- To change to using the new dak for the public archive we will need to:
  1. cron rsync dak.localnet to pkgmaster.d.o. Disable cron rsync of dak
     onpackages.d.o to pkgmaster.d.o.

#### Notes and Related Issues

##### Cowbuilder is Ancient

- We have 0.74+devuan1 in all suites apart from ascii-backports.
- Debian has

```
   debian:
     cowbuilder | 0.62+nmu2   | squeeze           | amd64, armel,
i386, ia64, mips, mipsel, powerpc, s390, sparc
     cowbuilder | 0.70        | wheezy            | amd64, armel,
armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc
     cowbuilder | 0.73~bpo7+1 | wheezy-backports  | amd64, armel,
armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc
     cowbuilder | 0.73        | jessie            | amd64, armel, armhf, i386
     cowbuilder | 0.85        | stretch           | amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
     cowbuilder | 0.88~bpo9+1 | stretch-backports | amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
     cowbuilder | 0.88        | buster            | amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
     cowbuilder | 0.88        | bullseye          | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
     cowbuilder | 0.88        | sid               | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
```

- It causes buggy buildhosts which fail on binary-indep 'all' build
with missing _all.changes file.
- Do we still need to fork it?
- Debian version 0.88 installs in beowulf and fixes the binary-indep
build failures.
- I suggest we remove 0.74+devuan1 from all suites, apart from jessie,
and revert to upstream packaging.

### Jenkins -repos build trigger

- Currently -repos builds are always triggered after the -binaries build
is complete, even if it has failed. This can mean some architectures
do not have packages built.
- What was the rationale for this choice?

I suspect this is because currently -repos jobs only have the
artifacts from the triggering build.

It would be better if we could only build the repos if all the binary
builds were in place.

There is a build configuration option to copy the latest successful
artifacts. Will that achieve this?

### Multiple amprollas

Currently there are 3 amprolla instances:-
1. amprolla on packages.devuan.org: Non-functional. Historical.
2. 2 separate amprolla3 instances on amprolla ganeti host serving
- pkgmaster.d.o
- packages.d.o

However packages.d.o redirects all its public http requests to pkgmaster
so the second of these is redundant and can be disabled or removed.

### Does amprolla care about file checksums?

Are we going to run into issues with changed checksums when we migrate
to the new dak?

### Builds on armel/armhf are relatively slow


## New Business

- https://dev1galaxy.org/viewtopic.php?pid=18748#p18748
  (Misbehaving lsb-release after upgrade)
  - (rrq) debian's lsb-release stays put, apparently due to some
    dependecy resolution issue

- https://www.patreon.com/posts/31633933
(Converting systemd units to init style shell scripts)
- (rrq) possibly think about automating script usage


## New Actions

- the ascii 2.1 i386 DVD is too big. Need to drop some pool packages.

- Evilham set to apply the amprolla patch tomorrow.