# Devuan meet 2021-05-06 @20:30 UTC

Present: Adam, plasma41, fsmithred, golinux, Erich, Xenguy, rrq, tuxd3v

## Old Business

### golinux
* As of this posting, no response from jaromil about this issue
  * Presentation of Dyne mail lists are not synced.  Thanks to tito for
    noticing.  devuan-discuss and devuan-bugs no longer exist.  Unsure
    about the rest: https://mailinglists.dyne.org/cgi-bin/mailman/admin
    https://lists.dyne.org/lurker/splash/index.en.html

### fsmithred
* Have we discussed the wireless password problem in the chimaera
installer isos? Last one I tried a couple weeks ago did not like
special characters in the password. I haven't tried newer isos.

## Old Actions

## New Business

#### tuxd3v
  * We need a new **RaspberryPi 2 Image ASAP**, the one present in the
    repos:
    http://arm-files.devuan.org/devuan_beowulf_3.1.0_armhf_rpi2.img
    doesn't even have users created, its bad.. "its dead Jimmy" Tenkawa,
    tested the Image it doesn't even boot :/ I suggest testing the Other
    RaspberryPi Images there ( Rpi1 I tested it, rpi3/4 in the forums
    there are people reporting success installing and using it, I don't
    know about rpi0.. ). (yeti) RPi1 stuff ™should™ run on RPi0.  WiFi
    and Bluetooth need an extra look.  I've a RPi4 image mentioned in
    the forum running here.  Apart from too much finetuning (I don't
    want preset fancy themes for e.g. midnight-commander and all the
    other blingbling) it runs fine.  Finding the default user and the
    password was an odyssee... maybe meanwhile there is a readme near to
    it? (user: pi, passwd: board  ...iirc...  while the only readme in
    the DL dir mentioned the old devuan std user/password).
  * Each time we release an Image we should verify its
    contents/functionality, at least in a macro escale.. EX:
    * Boot Log Messages( dmesg )
    * NetWorking,
      * If Ethernet
        * At least test installing packages from repository..
        * check if rx/tx buffers have the maximum size possible with
          ethtool..
        * Ideally do a bandwith test, with iperf3, to a server( that you
          know in advance its not bandwith constrained.. ).
      * If WIFI
        * Test if its working properly
          * Install **correct firmware** and **NVRAM.txt** file..
          * Verify Regional Domain Database( crda and Wireless-regb
            packages.. ), for Country CODE WIFI frequencies ranges..
          * Verify if reg database are loaded by the kernel,
          * Device txpower output confirmation(yes/no - if No limit
            TxPower for example in '/etc/rc.local')
          * Scan for devices, and connect to some network,
            * Test it, for example,  installing packages from the repo..
      * If Bluetooth
        * Install **correct firmware**( take in attention Datasheet
          WIFI/BLuetooth Module default Oscilator, RPi uses 37.4Mhz,
          others use 26Mhz, others use 24Mhz, others could use another
          main oscilator.. ), etc..
        * Test if its working properly
          * Detecting the BlueZ stack
          * Scanning
          * Listing devices
          * Power on/off
          * Connect/Disconnect to a Bluetooth device..
    * users/passwords/permissions..
    * kernel/headers/libc-dev
    * Soc correctly identified, frequency scalling ranges correct,
      temperatures and voltages applied to the Soc are correct Only then
      we should release a Image, and even then, its a trial Image,
      because is completly impossible to one person to check, and
      correct everything..but we should do our best, at least to support
      what is possible by the kernel/userpace..
  * It was sugested by someone in the forums( by peylight user.. I
    really don't know, **YET**, his trully intentions.. ), that we
    should do something like this:
    https://raspi.debian.net/tested-images/
    * But this would require extra Infraestructure, and seems overkill,
      altough the above steps are a good start.. and can be improved.
      * One Way would be in README.txt, with some information of what's
        working or what is not working..
      * Another Way would be to have a new File only to describe what
        was tested or untested..
  * (gl) - I hear what you are saying but it is my understanding that
    ARM images are maintained and tested by the ARM community. That's
    why they are not presented with the official Devuan isos at
    http://files.devuan.org/devuan_beowulf/ It's up to all of you ARMers
    to develop, test and and fix bugs in the ARM images. IOW, Devuan
    supports that work but is not involved hands-on with developing,
    maintaining or debugging ARM images. Might be a good idea to post
    testing protocols on the ARM builds forum and #devuan-arm to
    encourage participation. My hardware experience is limited to
    spinning disks so there is nothing I can help with there.
  * (adam) Thank you for the feedback. Especially on RPi2 image. It's
    ARM community driven. Most of the detailed comments are not relevant
    to the builds but the upstream project. Once set up, like c0rnelius
    the upstream maintainer, I can offer just sanity checking of
    successful booting each hardware variant image. Perhaps in the
    future, further feature checking and reporting can be automated, but
    this also will reply on community effort. Personally, I also commit
    to monitoring the forum (now in my RSS feeds) & IRC channel more
    closely.
* Actions: define a feedback channel These exist. IRC & forum.

### Xenguy

#### [Bug #576](https://bugs.devuan.org/cgi/bugreport.cgi?bug=576):
  chimaera branding 1. "bug reassigned from package `installer-iso` to
  `devuan-installer`."
  * **Question**:
    [installer-iso](https://git.devuan.org/devuan/installer-iso) has a
    repo, but `devuan-installer` does not. So for example, if I were to
    create a new `release notes` file for Chimaera, would I work in the
    `installer-iso` repo, or some other location?
* Release notes for Chimaera not yet written.
  * **Question**: Start here as other documentation refers to these?
* Cleanup of docs/docs/ in
  [installer-iso](https://git.devuan.org/devuan/installer-iso/src/branch/master/docs/docs):
  * docs/docs/migrate-to-beowulf.html
  * docs/docs/upgrade-to-beowulf.html
    * **Question**: Where should these 2 above files be archived to?
* Installation and migration documentation are only available for
  Beowulf, at https://www.devuan.org/os/documentation
  *(gl) I dug deep into memory and remembered what the install-guides
    directory was for.  I created the install-guides directory
    specifically for the VISUAL INSTALL GUIDES web pages. On
    https://www.devuan.org/os/install those guides are under the
    headers:
    * Install Beowulf (with screenshots)
    * Install ASCII (with screenshots)
    * The TEXT INSTALL guides are in the dev1fanboy directory.
    * The Chimaera visual presentations with images should go into
      install-guides directory.  That being said, I suppose that the
      install-guides directory could also be used to include the new
      TEXT presentations but they will have to be differentiated in some
      way.

## New Actions
* Where to put the working copy of release notes? Xenguy and fsr will
  discuss. ...and chimaera install and migrate guides.
  * www.devuan.org/source/os/documentation > $ ls > >design-guide/
    dev1fanboy/  index.html  install-guides/     update-dev1fanboy.sh.xz
  *
    https://www.devuan.org/os/documentation/install-guides/beowulf/Release_notes_beowulf_3.0.0.txt