:: [devuan-dev] Meeting notes 2021-06-…
Top Page
Delete this message
Reply to this message
Author: B Stack
To: devuan developers internal list
Subject: [devuan-dev] Meeting notes 2021-06-24
# Devuan meet 2021-06-24 @20:30 UTC

Present: Xenguy, Rick Moen, golinux, Adam Burns, rrq, plasma41, mason,
Hendrik, LeePen, fsr, beer

## Old Business

### golinux
* Some weeks ago there was discussion of the documentation included on
  the installation isos.  Well, according to
  * "Thank you for the well documented web pages that are included with
    the (unpacked) .iso"

### mason
* FreeBSD is moving to http://mlmmj.org/ for mailing list management.
Might be worth a look if MailMan3 doesn't work out. Haven't seen
anything about a new wiki target.

## Old Actions

## New Business

### LeePen
* Updated beowulf debian-installer/mini.isos for Debian Buster 10.10
point release.
* Updated main-menu for ceres/chimaera
* amprolla recursive banupdates to be deployed in the next few days. New
banned package list example: http://ix.io/3r1X/text

### Xenguy

#### Tor services
* [x] A new v3 Tor URL has been generated for pkgmaster and tested.  The
  [relevant web
  page](https://www.devuan.org/os/packages.html#access-via-tor) has been
  updated and pushed Live.  Thanks to parazyd and rrq! There is a second
  Tor URL that needs further discussion:
* Background:  On the [main Devuan web site
  page](https://devuan.org/index.html#about-this-site), I commented out
  some text near the bottom of the page which read as follows:
  * "To avoid censorship and blocks to the Internet, this website is
    also accessible using Tor at the address
  * So it appears that at some point, there was a Tor instance pointing
    to the Devuan web site, for the reasons stated above.
    * (plasma) The commit adding that Tor address notice was
      by Jaromil in the file sources/pages/index.en.html.md.erb
  * rrq mentioned that this instance probably has been inactive for
    roughly 4 years, as if there was such Tor instance operating, it was
    likely only on a previous web server, i.e. not the current one.
  * I'd be curious to know if others have any recollection of this
    service running?
* **Question:**  Does Devuan wish to update this v2 Tor URL to a v3 URL,
  and reactivate this particular Tor service?
  * The original statement provides a rationale relating to avoiding
    censorship and blocks to the Internet:  are we still concerned about
    these issues, and will an updated Tor instance provide value in this
  * For context, and FWIW, Debian seems to be rather heavily invested in
    running services of this kind, though it is not clear [from this
    page](https://onion.debian.org/) what the project's rationale is for
    doing so.
    * Edit: This page provides a better sense of the [Debian
      in 2016 for offering these Tor services.

##### Decision
**Devuan has adopted Tor services for pkgmaster, but will not do so for
the web site, at this time.**

### golinux
* Been down the css rabbit hole for a few days. Bugs and popcon share
the same css except for one line. white-space: pre-line; white-space:
pre-wrap; pkginfo does kinda sorta use that css so it took some
fiddling to get everything harmonized. Finally got it as close as
it's gonna get: https://dev1galaxy.org/files/browser comparison.png
Note to web designers . . . always start your stylesheet with this
snippet near the top which removes browser's default margins and
* { margin: 0; padding: 0; }
* @Xenguy . . . will send you the updated css file in a bit.

### plasma
* How come our _forked_ rsyslog binary package depends on libsystemd0?
  There's a --disable-libsystemd configure flag available, so why aren't
  we using it?
  * I think what's going on with rsyslog is that the upstream default
    compile configuration is to include libsystemd if it is available
    and while libsystemd-dev is removed from the Build-Depends field of
    the control file, the libczmq-dev build dependency depends on
    libsystemd-dev resulting in it being found and included by the
    rsyslog configure script.
    * I propose we fork src:czmq to remove the libsystemd build
      dependency (there's a simple --with-libsystemd=no configure flag
      we can use) and also explicitly disable libsystemd in the rules
      file for rsyslog.
      * Here's my proposed patch for rsyslog:
      * And my proposed patch for czmq:
    * (LeePen) Look reasonable. Thanks.
* Furthermore, why aren't libsystemd-dev or libsystemd0 banned packages?
  * (LeePen) Because the banned packages are binary packages not source.
    We wouldn't have a usable disto without packages with rdepends on
    libsystemd0 and libsystemd-dev
    * (plasma) What depends on them which prevents their removal? Isn't
      libelogind0 supposed to be a drop in replacement for libsystemd0?
      * (LeePen) https://pkgmaster.devuan.org/libsystemd.txt
      * (LeePen) libelogind0 is a *runtime* replacement. We don't have
        the person-power to recompile several hundred packages against
        libelogind-dev at the moment. And all the Debian direct packages
        are compiled against libsystemd-dev.
        * (plasma) In an ideal world (sounds like a nice place) all
          source packages in Devuan would be buildable without systemd.
          * (LeePen) That is a step beyond my understanding of the
            previously stated project aims (which I believe to be not to
            have to run systemd as PID1)?
            * (plasma) It is, I admit. I realize we don't have the
              manpower at the moment to create and maintain a full
              repository rebuild, but for packages where libsystemd can
              be disabled with a simple configure flag (as is the case
              in my proposed patches above) we should consider forking
              those packages at least. RFC.
      * (mason) libelogind0 remains troubling to me and has me
        reconsidering Debian as a viable base system, which has in part
        led to my diminished presence lately
        * (plasma) I view libelogind0 as a stopgap until we can port its
          dependants to something like libseatd. (Not a walk in the
          park, I realize.)
          * (mason) This is potentially valid but Debian is moving
            inexorably towards making that harder and more difficult.
            Look at the orphaned init scripts package as an example.
            Things like the systemctl shim seem like throwing in the
            towel. FWIW, seatd seems like it strikes a good balance and
            offers a path forward for the things it does.

### Rick Moen
* I've not had time this past week to do anything on the mailing list
replacement project. I suck. I'll try to do better this coming week.

### adam
* No updates, unfortunately been too busy to mailman.

## New Actions
* (rrq) make some write-up of Devuan's tor service(s)