Parazyd's New Proposed ASCII roadmap

Due to the streamlining from experimental→unstable→testing→stable not yet being ready, to catch up with Debian we should probably release Ascii the same way we did with Jessie. With Jessie we haven't made a patch release (e.g. 1.0.1 or 1.1.0) since the initial 1.0.0 release. IMHO we can leave it like that, but with Ascii we can do these if necessary. What I find more important is the streamlining work so we can be on track with Debian and keep going on with testing and development on Ceres and Beowulf - rather than losing time and nerves with Jessie and Ascii.

The Ascii roadmap I wrote after the release of Jessie hasn't received much love and not much progress has been made on it, so with this email I will render it obsolete and try getting the points below finished. These should be about enough to make a 2.0.0 release, and later on, if really needed, we can make 2.1.0 and others.

  • outdated packages in Ascii:
    • These packages might and might not need updates, but we should figure out if there is some necessary releases to be done regarding security.
  • libsystemd packages in Ascii:
    • These packages shouldn't have to be forked at this point, since the library doesn't do anything if systemd is not there.
  • currently doesn't have enough space to host both jessie and ascii

init (DONE!)

sysvinit is still working fine in Ascii. I would propose keeping it this way, and looking at OpenRC for Ceres first, and then Beowulf.

We're keeping sysvinit.


We should try and push eudev as the default hotplugging daemon. It has been working perfectly stable for a while now. Currently it's still in the experimental repos.

syslog (IN PROGRESS)

rsyslog still isn't being built properly for Ascii. This breaks default
debootstrap and locks the Jessie version if a dist-upgrade is being
done. Should we try fixing the rsyslog package or forcing a different
daemon like syslog-ng?

rsyslog is being fixed by parazyd for ascii

setup new jenkins build slaves:

  • one dedicated armhf board
  • one dedicated armel board
  • one dedicated amd64 computer
  • one dedicated arm64 board (by end of the week)

we can't include them in the CI since nextime's VPN doesn't quite seem to work and/or we're failing to setup openvpn clients. who can help with this?


Xorg still seems to work if we use the “xserver-xorg-legacy” package. It requires a hack being put in Xwrapper.config that makes it mandatorily run as root if no login manager is present. If a login manager like slim or lightdm are present, it should work just fine.

Amprolla (DONE!)

We need to finish the new Amprolla setup and force it as the new main package mirror. Amprolla3 is merging ascii-updates and ascii-security, which should need no tweaking and should keep working as-is. It has been tested and proven working multiple times, even before deploying it on the Devuan infrastructure. This action point implies fixing and pushing an update to devuan-keyring as well.

Antofox's MATE repos

Can we include Antofox's MATE repos in Ascii? Parazyd is currently hosting them on his server. Antofox could benefit a lot from using our CI infra.

Unfortunately, due to the timespan, I feel like these are the only points we should address for this 2.0.0 Ascii release. Again, the reason for this (somewhat radical) approach is to catch up with Debian and not be two years behind. This allows us to keep being a competitor and gives newcomers expected behavior and not two-year-old packages.

Please, let me know your thoughts and criticisms and let's discuss this in a polite way.


Previous ASCII roadmap

Please add any topics you wish to discuss here, or append to the existing ones. When we feel we are ready, we can discuss each topic on individual threads at the devuan-dev mailing list.

What is needed still in our current infrastructure setup?

  • migrating the DigitalOcean machines
  • ARM(64) build hosts
  • MIPS build hosts
  • PPC build hosts
  • Amprolla/Dak

How do we proceed with the basic Devuan userspace?

  • Init system?
    • OpenRC seems to be the most viable choice. Debian OpenRC is installable with the latest version of sysvinit-core (2.88dsf-59.9) installed. The scripts should perhaps be made gentoo style instead of using LSB. A more long term goal though.
  • Hotplugging daemon?
    • If we proceed with OpenRC, we need eudev. eudev is actually a good choice in any case.
      eudev is in the works and can soon be made available in ascii.
  • syslog?
    • rsyslog has been giving us troubles, and there are better and/or lighter alternatives available
      • syslog-ng
      • busybox-syslog
  • Userspace hardening?
    • Debian Stretch already has –enable-default-pie in their GCC. It is still somewhat broken and breaks certain relocations when libraries are being loaded. We have to take the time to track and fix these if they are not fixed upstream. This breakage mostly occurs in i386 when a hardened kernel is present and in use.
  • Xorg
    • ​​​​​​​It is currently impossible to start Xorg in Ascii without a login manager such as LightDM. This behaviour is very unwanted and might call for the need to fork Xorg-server and some of its components.
    • to avoid using xserver-xorg-legacy maybe utmp/wtmp can be useful for keeping track of logged-in users, see w(1) and who(2). Even systemd use utmp, it writes data to it, but don't read from it.
  • elogind
    • Maybe we should package elogind to get a workable systemd-logind interface?

What is needed/wanted in the current Devuan distribution system?

  • de??an-installer

​​​​​​​ * Is it worth fixing/maintaining? Or do we write a better installer?

  • devuan-sdk
    • ​​​​​​​The Devuan-SDK requires a full system to build images and will not work in containers such as LXC due to /sys limitations. We can setup ephemeral KVMs on a machine dedicated to do builds (maybe and utilize the devuan-sdk. Devuan is not mandatory to use the SDK.

We currently have d1h for people that are not very experienced with debian-style packaging and/or git. The main issue arises with running package builds. The current process is very cumbersome and we should look into different ways of issuing the builds. It can be either KatolaZ's suggestion of making a signed/tagged commit message that Jenkins will recognize, or we can go the way Github/Travis does, which is to run a build on every git push.

  • Streamlining of packages
    • We need to start utilizing the process of experimental→unstable→testing→stable and see what to do with -proposed repos and how/when to put those packages in main.