# 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
https://dev1galaxy.org/viewtopic.php?pid=30389#p30389:
* "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
http://devuanzuwu3xoqwp.onion"
* 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
[dd85da97fb5b757339d89959e8b2fa875a438d46](https://git.devuan.org/devuan/www.devuan.org/commit/dd85da97fb5b757339d89959e8b2fa875a438d46)
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
regard?
* 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
rationale](https://bits.debian.org/2016/08/debian-and-tor-services-available-as-onion-services.html)
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
padding:
* { 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:
https://paste.debian.net/1202279/
* And my proposed patch for czmq:
https://paste.debian.net/1202282/
* (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)