:: [devuan-dev] Meeting notes 2021-04-…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: B Stack
Date:  
À: devuan developers internal list
Sujet: [devuan-dev] Meeting notes 2021-04-01
# Devuan meet 2021-04-01 @20:30 UTC

Present: jaromil, golinux, LeePen, Adam, fsmithred, plasma41, rrq,
mason, Xenguy, tuxd3v

## Old Business

### mason
* Since LeePen has Amprolla in a reliable state, I'm setting lurc aside
(still want to do it) and am returning to the wiki. Explored xwiki,
but it has an inherent dependency on systemctl. Returning to twiki.
Might model it on Apache first since that's its natural element, and
then look at differences needed for nginx. Either way, the wiki seems
like the current critical need I could try to address, now that
Amprolla isn't falling over so much.

### golinux
* There are still issues when registering to the mail lists that need to
  be addressed.
  * (onefang) Is the bus factor for the mailing lists too low?  Maybe we
    should move them to our own infrastructure, where more admins can
    get their hands dirty.
    * (gl) rrq has some magic for you.
    * (gl) This has been suggested in an internal discussion.
    * (mason) The state of mailing list software is awkward. Mailman2 is
      Python2, and Mailman3 is complex and different.
* Bug found in the clearlooks-phenix theme rubberband widget and
  corrected thanks to ToZ on the Xfce forum.


### tuxd3v
* bluez patches in standby,( waiting new hardware to test adition of
  ampak chips as broadcom )
  * there are already some actions taken( to add cypress devices as
    broadcom.. ), but the idea is to add also ampak devices.For that I
    need new hardware to test, which is in the mail.. I am yet to
    receive any input from the mail actions taken from me via email, and
    suck, last week..
  * current patches: https://gitea.devuan.dev/tuxd3v/bluez


### Xenguy
* Things have gotten busy IRL. All my activity is on an 'as time
  permits' basis for the next wee while.
* **Unfinished business:** (general items I will roll forward from
  meeting to meeting until actioned)
  * Revise buster-to-beowulf documentation on web site?
    * [x] chillfan has been emailed a second time, using additional
      email addresses found in the 'documentation' repo.
      * [x] Edit: 5 of 7 email addresses bounced back as 'Recipient
        address rejected'.
        * [x] Edit: The other 2 email addresses eventually bounced back
          also.  Chillfan's tracks have vanished, so this appears to be
          a dead end.
    * buster-to-beowulf documentation also included on the ISOs?  Verify
      this.
      * (gl) I thought it was verified last week
        * (Xenguy) Probably was; I want to see it for myself : -)
      * An idea:  include a pointer/note on ISO doc to direct user to
        most recent documentation version on web site?
        * A better idea:  remove 'migration' documentation from the
          ISO's, as per fsmithred's rationale.
    * IRC user gnu_srs suggested the following documentation
      modification:
      * "Regarding eudev this should be sufficient: Upgrade to eudev is
        made by the transitional package udev. No special measures are
        needed."
      * "So all text surrounding apt-get install eudev and apt-get -f
        install can be removed. Replaced with the text above."
      *(fsr) eudev is supoosed to pull in sysvinit-core in those
        instructions. (see below for more)
  * IRC user xrogaan asked some questions regarding web site content
    related to the issue of 'How can I contribute to Devuan?'
    * Need to look closer into this issue generally.
    * Check the 'donate' and 'development' (and other?) pages for this
      kind of language.
    * Discovered that [one of our
      pages](https://www.devuan.org/os/community.html) already links to
      the Forum page on [How you can help
      Devuan](https://dev1galaxy.org/viewtopic.php?id=589).
      * (gl) The [Donation](http://devuan.org/os/donate.html) and
        [Explore](https://www.devuan.org/os/explore.html) pages also
        link to the forum post


## Old Actions

## New Business

### mason
* emdete on IRC noted gitea not using TLS for outbound email. We see, in
  the email config: >    `## LeePen 2020-06-02 Disabled TLS`
  * Is there reason to keep this disabled?
  * Related, we appear to have the snakeoil PEM in place. We might use a
    Let's Encrypt certificate for email - I do this for my personal
    email.
    * rrq notes that we have DNS-based validation available
      * and this makes me think I should switch the vapourware wiki to
        use that instead of maintaing its own
  * We could turn it on and explicitly set "may" to get opportunistic
    encryption but still allow unencrypted mail exchange, unless there's
    reason why we don't want that.
    * http://www.postfix.org/postconf.5.html#smtpd_use_tls
    * http://www.postfix.org/postconf.5.html#smtpd_tls_security_level
  * Outcome: will implement, with an eye on gitea to make sure email
    still flows


### LeePen
* Updated beowulf mini isos after Debian release of updated buster
(10.9) with new kernel ABI.
* Updated iwd in ceres and experimental (thanks Job Bautista)

### rrq
* alpha drop of chimaera installer isos at
https://charla.rrq.id.au/download/ I gave up on building them using
fakechroot+fakeroot on beowulf, and instead set up scripting to use
sudo+chroot, still on beowulf. It needs to be parameterized to rely on
multi-arch for cross-architecture installer iso building. Though if
this is automated it's better to use the different build hosts
instead.
* new external IP address via nardoo to be ordered. The main reason is
to pass pkgmaster out on the Internet more directly, esp since the
current networking via nash is slow. (Traffic on those IP addresses
enter OVH in Paris, go to nash in Amsterdam, then to nardoo in Paris,
to pkgmaster which is currently hosted by nardoo... and back) But
pkgmaster is now shifted to the IP addresses for napier, which enter
OVH in Amsterdam, go to napier in Amsterdam(?) then to nardoo etc.;
that path is (of course) faster. It seems in particular the hops
through OVH for the nash-bound IP addresses make them much slower
although it is also due to the forth-and-back between Paris and
Amsterdam.

### fsmithred
* netinstall with chimaera alpha works. (standard system utils only)
* LXDE seems to be working. (installed after reboot into new system)
  * (Xenguy) LXDE would be a welcome DE addition, just MHO.
* migration from buster to beowulf tests...
  * posted method isn't working for me. sysvinit-core fails to install.
    Can't rescue in chroot because apt won't work without libsystemd0.
  * Nixer's method no longer works for me. Install sysvinit-core and
    screen goes black. End of story. Not end! init 1, login as root,
    continue the upgade. Try to reboot and get /run/initctl error. Kill
    it and reboot to console login. Then autoremove the whole system.
    Reconnect network. Install slim. Install eudev. Reboot to desktop.
    Wow. Few hundred packages are missing.
    * (Xenguy) See new comments from gnu_srs above in 'Old Business'
      section. Not sure if this is relevant whatsoever : -)
      * (fsr) Those comments are what prompted me to try it. Without
        installing eudev you must explicitly install sysvinit-core. But
        right now, neither way works.


### tuxd3v
* newt package responsible for generating libnewt, libnewt-dev, and
  whiptail, in Chimaera  doesn't have all paches applied, at least is
  missing NEWT_KEY_ESCAPE, as hotkey in forms.c, line 482..
  * patch sent to debian maintainer, asking what are her thoughts about
    the subject..
  * patch availlable for NEWT_KEY_ESCAPE as HotKey in forms:
    https://gitea.devuan.dev/tuxd3v/newt


### Xenguy
* Web site magnet URL for downloading ISO's has been temporarily removed
  from the web site until I can do some more testing.
  * I will be looking at finding a more reliable method to generate a
    proper magnet link, and also testing said magnet link to actually
    download the ISO's.
  * Thus far, the new magnet link results in a very slow download speed
    for me, so the torrent file appears to be a better option at the
    moment, for reasons unknown.


## New Actions

### mason
* find OpenRC deviation
  * several months ago (?) opened bug against OpenRC, and they kicked it
    back noting (correctly) that Debian replaces certain bits. I'll find
    the bug and summarize.
  * Found it: https://github.com/OpenRC/openrc/issues/383


### Xenguy
* Need some note or disclaimer added to the current buster-to-beowulf
  documentation, as fsmithred reports the documented method is not
  working properly any longer.
  * Can we encourage interested parties to help find a method that
    works?