And now for your kind attention, the devuan-dev meet notes from
Wednesday, November 7th, 2018.

plasma41

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

# Devuan meet Nov. 7, 2018 @20:30 UTC

Pad is here:
https://pad.dyne.org/code/#/1/edit/RrP28i6FmsvPIOUFrvSqUQ/HktZWHd5MO5XrnA9C0yYPre8/

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: golinux, rrq, amesser, fsr, RickMoen, duncan, Centurion Dan

## Old Business
- d1conf planning:
https://pad.dyne.org/code/#/1/edit/lSWG6jS9TqtJdk3iUoHzsA/Fmgq2gMR+OCUA8aEQ1TY59iG/
- d1conf announcement:
https://pad.dyne.org/code/#/1/edit/Cr447i-kZTo07uzPbg7UsQ/KsnnAcL5dCwnUkb8YoJD6LrS/

- DNG bounces. Fixed?
(gl) Hasn't been addressed at all afaik
- Ongoing Devuan/Debian init diversity collaboration

## Old Actions


## New Business

### rrq
- upgrade of Devuan gitlab to version 11.4.4.
No issues. Also fixed favicon.

### Centurion_Dan:
- I've been beating my head against the infrastructure due to a broken
repo's job, and as a result discovered something I didn't know...
Namely the way we have configured dak is causing many unintended
side-effects. The heart of the issue is what is a "suite".

Debian and dak's workflow is oriented around suites as a deterministic
set of states through which a packages become part of a release -
experimental (new packages) -> unstable (updated packages) ->
testing (staging for next release) => stable (the stable release).
The reason I mention this is because dak is built around the
consistent use of those **suite names** and not **release names** -
that we call apply to our suites. There are many places in dak that
are hard coded to use **suite names** - simply because it makes sense
for the work flow.

As a result I propose that we reconfigure our dak instance to follow
the debian understanding of **suites** and **codenames** for
**releases** because it means we could drop all the current hacks and
use a largely unnodified dak which debian maintains.
The reconfiguration requires a one time database hack to rename the
suites to use the debian suite names, and make sure we set correctly
the codenames - and patching our custom dak_add_package tool to map
the codename to the correct suite.

The repo dak builds will not be effected difference in the output
(except the release files will have corrected fields - currently dak
spits out the wrong Label and Suite anyway)

- Package building policy: When rebuilding packages from debian always
use the source selected by tag or branch. Usually this means a line
in debian/gbp.conf [Default] section `upstrean-tag = v%(version)s` or
`upstream-branch = upstream/%(version)s` Don't use or generate
pristine-tar unless there is no upstream/branch or upstream/tags that
can be synced from debian. Pristine-tar fills our git with
large blobs.


### amesser
- can not push to "master" elogin git?

remote: GitLab: You are not allowed to push code to protected branches
on this project.
To git.devuan.org:devuan-packages/elogind.git

- just uploaded elogind 239.1-0.1 from LeePen

### KatolaZ (notes from IRC)
- have been working on sysvinit and d-i components for unstable
- we are close to a d-i build for unstable which would allow to test
stuff in beowulf more extensively
- have been concretely playing with aptly and set up a test repo
for that
- but Dan is working on a newer dak, which seems more amenable than the
old version

### golinux

- The #devuan archive link on the website now points to our znc instance
on d1g.
- Also added a link to pkginfo on the bottom of the index page.
- Set up a Beowulf todo pad (see New Actions below)

## New Actions

- we need rDNS for git.devuan.org (5.196.38.17)

- (rrq) would REALLY like middle-button copy-paste work in these pads.
- (gl) Works for me on the pad but not coming to the pad from outside.

- setup a todo pad for beowulf:
  - develop and document a package maintenance workflow to ensure
    consistency in the packagging process - particularly with respect
    to obtaining the upstream source as noted above.
  - (golinux) DONE!
https://pad.dyne.org/code/#/1/edit/aEXydBHk28Tormi6Vhyazg/EexaicIbGCz5Hj5+HPl4ZjNb/