:: [devuan-dev] Meeting notes 2021-07-…
Página Principal
Delete this message
Reply to this message
Autor: B Stack
Data:  
Para: devuan developers internal list
Assunto: [devuan-dev] Meeting notes 2021-07-22
# Devuan meet 2021-07-22 @20:30 UTC

Present: fsmithred, LeePen, rrq, plasma41, golinux, mason, Rick Moen,
Xenguy (later), brocashelm (later)

## Old Business

### Forking Policy for Maintainer's Guide (LeePen) I have tried to
incorporate the things we discussed last week. > Devuan was
established to be Debian without the need to have systemd as PID1.
Packages are forked when necessary to facilitate this. ~~Current
policy is
*not* to fork a package solely to remove systemd unit files or
libsystemd0 dependency.~~ Forked packages that require logind
functionality should be built using libelogind-dev. > > Packages are
sometimes forked for reasons other than functionality without systemd.
Most commonly this is to maintain or increase user choice. > > Devuan
welcomes contributions from those who are willing to fork and maintain
a package and keep it up to date with the Debian versions on an
on-going basis.

## Old Actions

## New Business

### LeePen

#### Bug #496 and speech accessible configuration A consequence of
  task-\*-desktop (3.68+devuan2) recommending
  devuan-speech-dispatcher-config-override alongside orca was to switch
  the default sound system for all new installs to ALSA. pavucontrol
  therefore hung. Reworked another approach in src:tasksel 3.68+devuan3:
  * new package task-speech-accessibility which depends on
    devuan-speech-dispatcher-config-override and also lightdm
  * tasksel only shows this package (default selected for installation)
    for new installations when the speakup kernel module is loaded, as
    it is in speech installs. Non-speech installs do not even see the
    option.


#### Beowulf Promoted eudev, rsyslog and
clearlooks-phenix-cinnabar-theme from beowulf-proposed-updates to
beowulf.

### rrq
* chimaera installer-iso docs -- cleanup and changes

### adam

#### Mailman3
* test install now finally working with hyperkitty (the archiver)!!
please take a test browse at http://mail.devuan.dev:8080/mailman3
(yes, it took a while)
* TODO0 there is example.com in the web interface, i think it is in the
sqlite db ... needs to be found and updated ...
* TODO1 evaluate prod db instead of sqlite3 install & configure, ok,
postgres it can
* TODO2 look at all mailing list archives to migrate?
* TODO3 add web TLS cert (LE with certbot?), move to port 443

#### Beowulf & Chimaera RaspberryPi ARM images
* nightly alpha build images here
https://ci.free2air.net/job/Images/job/rpi-img-builder/
* once stable, look at building triggered from gitea changes in
devuan(?)
* when jenkins config is stable, get someone to look at incorporating
into devuan jenkins (i'm not going to touch that without someone
looking over my shoulder!)
* where to put in arm-files? (discussion?)

### mason

#### mediawiki
* I installed the Debian packaging of MediaWiki on wiki.devuan.org but
  noted that there is still TWiki spoor to clean out, so I'll do that on
  my next run.
  * Some relevant docs:
    *
      https://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Debian_or_Ubuntu
    * https://wiki.debian.org/MediaWiki
  * This is going to want MySQL as a back-end, but we can set up regular
    dumps of the SQL.
  * Once the basic install is there we'll want to look at access rules.
    To reiterate my understanding of the goals: 1. We want most things
    but not all to be world-readable 1. We want a selected group to be
    able to edit public-facing, official pages 1. We want folks to be
    able to have their own user pages/hierarchies that they can use to
    demonstrate good work and earn trust. 1. We want to start off with
    some notion of how to use a standard block to note page freshness -
    a "last vetted" datestamp.
      * Ideally this lets us automate a search for pages old enough to
        need checking
      * We probably want to shift out of date content somehow - mark it
        as archival/out of date, but presumably keep it for its
        historical context.
  * Just a quick note - I don't feel I have an exclusive claim to the
    project and I don't want to block anyone else from expending energy
    towards its completion.


#### UsrMerge
* Some historical context:
  * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
  * https://lists.debian.org/debian-devel-announce/2019/03/msg00001.html
* (plasma41) Some even older historical context i.e. how the whole
  /{s,}bin versus /usr/{s,}bin split is a holdover from a specific quirk
  of Ken & Dennis's original PDP11:
  * http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
  * http://landley.net/writing/hackermonthly-issue022-pg33.pdf
* (plasma41) I'm just spitballing here, but to those favoring the
  elimination of the /usr/bin v /bin split I'd suggest taking the time
  to rework other historical quirks of the filesystem hierarchy. _If_ I
  wanted to eliminate the historical split, then while I was at it, I'd
  also suggest these moves: /bin, /usr/bin   -> /static/bin /sbin,
  /usr/sbin -> /static/sbin /etc             -> /conf /home
  -> /usr (after all that's what it was originally for) /lib, /usr/lib
  -> /static/lib /usr/libexec     -> /static/libexec /usr/include     ->
  /static/include /usr/games       -> /static/games /usr/share       ->
  /static/share /usr/src         -> /static/src /usr/local       ->
  /local Admittedly, such a rearrangement would require a full repo
  rebuilt, so I'm not floating this as a serious proposal, but if I were
  to ever get the Gentoo itch, I'd probably use a hierarchy similiar to
  this.
* The Debian dpkg maintainer's concerns:
  * https://wiki.debian.org/Teams/Dpkg/MergedUsr
* My personal opinion, this isn't one we can dodge, as Debian will be
  opening bugs against packages that don't work with UsrMerge, and it
  seems like there will be an ever-widening gap if we don't UsrMerge.
  I'd love for someone to point out to me how we can maintain a
  traditional root distinction without forking half the world.
  * (plasma41) FWIW, to get a list of binary packages that have a file
    in /bin, one can run: `apt-file search -x ^/bin/ | awk '{ FS = ":";
    print $1}' | uniq` This works on a per-architecture basis and gets
    its information from the repos listed in sources.list. It can easily
    be modified to show files in /sbin instead. This should at least
    help in getting an idea of how many packages would be most directly
    affected by usrmerge. Currently I see ~80 binary packages (haven't
    yet converted that to number of source packages) from the repos I
    have in my sources.list.


### fsmithred
* desktop-live and minimal-live chimaera alpha isos are up.
* possible live iso with speech synth is in development.

### Xenguy
**Item brought forward: Still to do: (Xenguy and golinux)**
* [ ] Modify [Buster to Beowulf
  documentation](https://www.devuan.org/os/documentation/dev1fanboy/en/buster-to-beowulf.html)
  to include:
  * A general disclaimer about these instructions?
    * Current migration guide appears to target desktop systems; on
      headless and remote systems, a reboot breaks the system (e.g. ssh
      doesn't start).
    * Jaromil also mentioned an "infamous bug": `error: symbol
      'grub_register_command_lockdown' not found`.
      * (mason) I found that some of my issues were resolved by
        directing GRUB to install to the mounted EFI directory
        explicitly:
        * grub-install --efi-directory=/boot/efi
  * Links to [tito's](https://git.devuan.org/farmatito/migration) and
    [rrq's](https://git.devuan.org/rrq/buster-to-devuan) migration
    scripts?


## New Actions
* golinux worked on the iso docs - updated css to chimaera colors,
removed 2 files and s/r beowulf references with chimaera. Sent to
Xenguy for git upload and further text updates.