:: [devuan-dev] Notes - Devuan meet Oc…
Startseite
Nachricht löschen
Nachricht beantworten
Autor: Plasma
Datum:  
To: devuan-dev
Betreff: [devuan-dev] Notes - Devuan meet Oct. 17, 2018
And now for your kind attention, the devuan-dev meet notes from
Wednesday, October 17th, 2018.

plasma41

------------------------------------------------------------------------

# Devuan meet Oct. 17, 2018 @20:30 UTC

Pad is here:
https://pad.dyne.org/code/#/1/edit/xPKNp93WQqptudr-RbMMVw/ztRddRIlvv8IdKcb8lFI8p3i/

Meet here: https://vdc.dyne.org/devuan
   * Please post notes prior to the meet.
   * Please add your name as 'Present' below when you get to the
     meet.
   * When adding a comment in someone else's notes, please
     pre-pend your name like this: (whoever) whatever . . .


Present: RickMoen, Evilham, KatolaZ, golinux, Centurion_Dan, blinkdog,
fsr, duncan, rrq

## Old Business
- d1conf pad:
https://pad.dyne.org/code/#/1/edit/lSWG6jS9TqtJdk3iUoHzsA/Fmgq2gMR+OCUA8aEQ1TY59iG/
- Still weird mirror stuff being reported

## Old Actions
- last week's notes:
https://lists.dyne.org/lurker/message/20181015.052130.b4f2718f.en.html


## New Business
- sysvinit - Discussion
- Notes for first announcement of the d1conf. Should be short with
basic announcement:
https://pad.dyne.org/code/#/1/edit/Cr447i-kZTo07uzPbg7UsQ/KsnnAcL5dCwnUkb8YoJD6LrS/

### golinux
- Worked on updating the refracta site
http://www.stopcta.info/ss/refracta.org/1400.html
Page is now very flexible and doesn't break.
- Started the d1conf announcement pad

### Evilham
// extremely tired, will flunk quickly today //
(golinux) makes evilham a double espresso)

#### Mirrors
* New mirror checker, no relevant comments have been made (I don't
consider lack of human readability an issue, there is jq and there are
browser extensions that format json)
https://lists.dyne.org/lurker/message/20181015.120157.7dc7f44d.en.html
* There is potential for a halfway solution for https mirrors, like that
of debian's mirror network.
- It also simplifies real IPv6 support on the mirrors.
- Nothing is lacking for IPv6 support, just the proper DNS entries.
https://lists.dyne.org/lurker/message/20181012.203625.e601da5c.en.html
TODO: Test CNAME --> SRV
* LMU fixed their IPv6 mirror, took a couple days though:
https://evilham.com/d1mc.example.json

#### TLS Certs and monitoring
* Monitoring is disabled as TLS certs have *still* not been updated on
pkgmaster and auto mirror.
(It was being too noisy for my taste)
Reissuing certificates shouldn't be a burden but happen automagically.
Someone please fix that, I would but don't have access ;).
auto.mirror's cert expires in 5 days.
pkgmaster's on the 30th.
(KatolaZ will take care)

#### Debian + sysvinit
I guess it'll be talked thorughly, but Imma leave earlier:
* I think the best bet for long-term maintanability is to keep sysvinit
  in Debian, that does not excludes efforts like that of Dan's.
* If (at least) one of us becomes a DM / DD, it will be easier. Not
  everyone in Debian is being nasty, just a couple, vocal, people.
  * (blinkdog) https://www.smbc-comics.com/comic/2013-04-07
* I contacted a DD that would gladly support efforts for maintaining
  sysvinit and systemd-shim besides those that have already said
  so openly.
* The main issues are, indeed, bugs against sysvinit scripts. Working
  sysvinit scripts on debian may mean less work here.
* There is no reason to just give it up because a couple people are
  nasty. It may happen that we only delay the unavoidable, and that the
  change of policy regarding init and unit files takes place; but that'd
  be an issue for *next next* Debian stable (after buster).
* Keeping sysvinit, at least for now, in Debian buys time, which is
  quite appreciated, I guess we can and should start looking for
  backup plans.
* Also maybe help close OpenRC bugs and the like.
  There is a feeling that supporting non-systemd inits is kinda
  pointless when these things are not addressed:
  https://bugs.debian.org/910444
  Another added feature is that having better support for stuff other
  than sysvinit, actually gets devuan out of the "sysvinit" box, a bunch
  of people have us in.
    - Many have no idea that it is possible to pick OpenRC as an init
      system on Devuan.


### Centurion_Dan

- Proposal for missing init scripts:

This will potentially grow as a problem over time as debian developers
lose interest in maintaining them due to not being able to test them.
It will also serve as a backstop if we fail to keep sysvinit in
debian. It could even potentially provide a nice way for supporting
other init systems not using sysvinit scripts.

  - Proposed Solution: Devuan-Baptise - baptise service/deamon packages
    to run on the hosts chosen init system.


    The idea is to use the systemd unit files shipped in a given package
    as input for generating equivalent functioning init scripts, xinetd
    listeners, cron files etc as a post install triggered tool - we can
    even potentially use it to override and delete all the
    systemd cruft.


    My thoughts are to leverage the work Lydia_K has already done in
    this space with https://git.devuan.org/Lydia_K/startmeup/ because it
    already does the creation of LSB compliant init scripts - so we only
    need to glean the needed input from the systemd units.


    Devuan-baptise will use a global (so run for every package)
    post-install and update trigger for setting up or updating scripts
    and a removal trigger for cleaning up on package removal  It's also
    a complementary to parazyd's noop libsystemd effort.


- (blinkdog) I like this suggestion because the return on time invested
is high. It also shows us where systemd unit files reference
functionality that may not exist in sysvinit. It gives us a list of
small utilities to create, so when systemd proponents say "Well how do
I do X with sysvinit?" we can respond "Oh, Devuan does that with Y,
no systemd needed."

There is also an opportunity for embrace-extend-extinguish here. If
the Linux ecosystem embraces systemd unit files as a de-facto standard
(as good or bad as that might be), the first step is embrace (we
support it), then we extend (add a killer feature only present in
Devuan), then well ... bye bye systemd >:-)

My only concern is the quasi-religious nature of "baptise". From a
marketing angle, I'd suggest something that implies completion, like
the systemd unit file leaves some parts out of the box, and this
service supplies the missing pieces that gets it working. (That's the
concept to shoot for, I can't pick the right words to capture it
yet though.)

I don't think I would ever stop smiling if someone said,
"Devuan did systemd right"

- (CenturionDan) I chose to use baptise in the name because it implies a
conversion process for packages - and the religious inference is a
purposely tongue in cheek rejection of systemd's forced universalist
group think, proving we can "convert" packages designed exclusively
for systemd to function with any init system.

  - (gl) Let's keep religious references out of it please. What is one
    person's salvation is anothers' stupidity. There are many other ways
    to go: devuan-capture, devuan-pwnsd, devuan-ascendant (which at
    least has planetary implications), devuan-rises, devuan-phoenix,
    devuan-alchemy


- (blinkdog) Now that you write it that way; I LOL, "convert"ing a
package; you were born a systemd package, but now you're free.
That's fantastic. :-)
- (golinux groans)

- (plasma41) I love the idea I'm not wild about the name. (Also, isn't
  it spelled baptize?) We should share the idea with other distros
  rejecting systemd
(https://devuan.org/os/init-freedom/#gnulinux-distributions-without-systemd)
  and see If they would like to contribute.
  - Baptise :-D (evilham) Actually not big fan of the name, but I
    couldn't care less about that :-p whatever works. There are some
    things that may be trickier, remember: systemd does not just do init
    (or cron, or dns); it's still worth a shot for some things though.


- (blinkdog) KatolaZ provided this link during the meet:
https://github.com/akhilvij/systemd-to-sysvinit-converter

### blinkdog
- systemd Unit survey
Last night I looked at some Contents files
(example below is buster main)
http://ftp.debian.org/debian/dists/buster/main/Contents-amd64.gz

I was thinking to identify all of the unit files in Debian, to get a
sense of usage, to get a sense of the scope of Dan's unit
file processor.

There were more unit file types than I expected.
service.service, socket.socket, device.device, mount.mount,
automount.automount, swap.swap, target.target, path.path, timer.timer,
slice.slice, scope.scope
https://www.freedesktop.org/software/systemd/man/systemd.unit.html

I don't have any results yet; just scoping out the problem. I was
hoping to write some scripts tonight to at least
identify the files / identify the packages / download the packages.

### KatolaZ
- step-up to help for sysvinit maintenance in Debian -- updates to be
sent here
- have started working on Translations (finally)

## New Actions
- plan for sysvinit action
- (blinkdog) work on d1conf announcement
- (blinkdog) systemd Unit survey