|:: [devuan-dev] Meeting notes 2021-06-…|
|This message is part of the following thread:|
|the complete thread tree sorted by date|
### 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"
#### 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.
### 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.
|This message was posted to the following mailing lists:|
Mailing List Info | Nearby Messages
|[devuan-dev] bug#588: System freezes with the latest kernel update||[devuan-dev] Devuan meet 2021-07-01 20:30 UC|
|dyne.org open discussions |
administrated by dyne.org hackers
|Lurker (version 2.3)|