# Devuan meet 2020-10-08 @20:30 UTC

Present: golinux, mason, LeePen, fsmithred, bgstack15, adam, plasma41,
rrq, RickMoen, Beer

## Old Business
* We finally have the 2019 financial report from Jaromil thanks in good
part to Adam. https://devuan.org/os/donate
https://devuan.org/os/announce/report/devuan_financial_report_2019.pdf

## Old Actions
* eudev update for beowulf

### adam
* to investigate with manuela separate dyne bank account for devuan

### mason
* wiki exploration
  * ikiwiki lacks real ACLs.
  * Foswiki seems to have hardcoded Apacheisms
  * Current focus: PMwiki
    * Was suggested in email poll, despite being PHP.
    * I've got this running internally, although I'm still working on
      setting it up.
      * It's got the cleanest, clearest configuration of all of them so
        far, and has presented the fewest hurdles out of the box.
      * It has an explicit separation of code and server-editable data,
        which we want.
      * I'm going to push forward with this one and commit to having
        usable content for next week's meeting, and accounts doled out
        to those interested before then so we can come into the meeting
        with some direct experience of the thing.
      * (from golinux) use pkginfo or bugs for style guidelines -
        simpler than web site
* Unbound PID issue
  * I'm not sure they're going to go the right direction. They'll
    address the CVE-worthy security issue, but I suspect they'll
    continue with the self-owned PID. I don't have a feel for whether
    Debian would want to make this change or not, but we could wrap it
    in an init script that tells it not to manage its own PIDfile, and
    we can let start-stop-daemon manage a PIDfile for the service. This
    would mean forking it.
    * (Beer) They definitely seem obtuse about [the reported
      problem](https://github.com/NLnetLabs/unbound/issues/303). However
      forking & maintaining requires human resources…

## New Business

### mason
* How do people feel about elogind?
  * (mason) It's a big part of systemd and it seems like we should
    reject it as we reject the rest of systemd. It's a slippery slope.
    There are other tools that do its work that are not central
    components of systemd. This is distinct from elogind0, but I like
    the notion of ditching that as well. Libraries are supposed to
    supply defined resources related to each other. libelogind0 breaks
    this. As noted above, I hope to put my money where my mouth is once
    I've gotten the wiki into usable form - I'm looking to volunteer my
    own time primarily, but knowing that the project agrees or disagrees
    with these assessments will help me to properly understand how to
    prioritize this stuff.
  * (bgstack15) I care about lightdm, which requires elogind. And don't
    tell me that consolekit is suitable instead of elogind; isn't it by
    the same people, and unpopular in their eyes just like gtk2/3 is
    anathema to the Gnome people?
    * (mason) consolekit is preferable, but is this strictly needed at
      all for lightdm? Some quick reading suggests that you lose the
      ability to shut down from the login screen. And there are other
      display managers. Even on laptops, I find XDM to be entirely
      suitable for launching sessions of various sorts. Regardless, if
      we're just going to use huge chunks of systemd, I don't see the
      point. Just use Debian, if it really doesn't matter. I'm
      interested in having a diverse ecosystem, and a search/replace to
      rename pieces of systemd isn't a move in that direction. Tell me
      this: What's the point of Devuan if it's just going to use
      systemd?
  * (noname) I would love to see a maintained alternative to make
    devices available to it users securely and only while that
    particular user needs those devices. The seat management is only
    there to support that. Can you provide that? If yes, kill elogind
    with fire! If no: please keep elogind.
  * (LeePen) I think consolekit is unmaintained upstream and can't be
    considered a viable and secure option. The last commit was December
    2017. It also delegates suspend/hibernate/resume to pm-utils which
    is also dead upstream. See
    [here](https://github.com/ConsoleKit2/ConsoleKit2/issues/114).
  * (LeePen) I think the stated objective of Devuan is to be able to
    avoid the use of systemd as PID1, not avoid any systemd derived code
    in all circumstances. We currently use eudev, elogind and
    libsystemd0 which are all derived from systemd codebase.
    * (plasma41) Technically eudev isn't so much derived from systemd as
      it is extracted after having been absorbed into systemd
  * (LeePen) If somebody wants to write and maintain a compatible logind
    implementation from scratch, great and let's try it.
  * (plasma41) Given that using elogind feels like just replacing
    systemd with the same systemd code, just sliced into smaller pieces,
    I am in favor of minimizing its use. Currently I'm running
    consolekit for the role that elogind serves, though I am running a
    single-user, single-seat setup, so I'd prefer to be able to do away
    with "seat-management/session-management" code on my system
    altogether.
  * (plasma41) If we want to minimize elogind dependence, I recommend we
    collaborate with the Hyperbola devs. See
    https://www.hyperbola.info/todo/consolekit-migration/
    * (gl) pekman already hangs around here and he's active with
      hyperbola
    * (plasma41) And while we're ridding ourselves of systemd bits, I
      also would like to aim to get rid of the proto-systemd: d-bus.
      More Hyperbola colab opportunity here:
      https://www.hyperbola.info/todo/dbus-mitigation/

### LeePen
* New [Jenkins job to update pbuilder
chroots](https://jenkins.devuan.dev/job/update-builder-chroots/)
completed and run. Unstable builders are now working again.

## New Actions
* Find alternate eudev maintainer
* greeter / display managers
  * language?
  * shutdown from login?
  * what else?
* explore pm-utils viability
* explore desktop environments that might not need consolekit/(*)logind
  * kde? mate? lumina?
    * https://lumina-desktop.org/ and
      https://github.com/lumina-desktop/lumina
  * wayland and rootless X11 both need logind nowadays (or insecure
    hacks)

-- 
  Mason Loring Bliss         mason@???        http://blisses.org/  
For more enjoyment and greater efficiency, consumption is being standardized.