Cover photo
Anthon Open Source Community (AOSC)
10 followers|2,498 views


On AOSC OS Ports...
by +Mingcong Bai

Just figured that some may be curious of how AOSC OS ports are done, so this particular transmission will be dedicated to this matter.

In case you haven't noticed yet (due to our puzzling download page), AOSC OS currently has 7 architectural ports under active development:

- AMD64/x86_64, your usual Intel/AMD PCs and servers (amd64).
- ARM, for your boards, tablets, phones, servers alike.
- ARMv7, 32-bit, hard-float, NEON (armel).
- ARMv8, 64-bit, AArch64 (arm64).
- MIPS, mainly for Imagination Technologies and Loongson devices.
- MIPS-II, 32-bit, o32 ABI (mipsel).
- MIPS64, 64-bit, n64 ABI (mips64el).
- PowerPC, mainly for consumer-oriented Apple and AmigaONE desktops and laptops.
- PowerPC, 32-bit, big-endian (powerpc).
- PowerPC, 64-bit, big-endian, AltiVec (ppc64).
And by AOSC OS design, these ports are all capable of running on mainline kernels (well not yet for MIPS64el) and various desktop environments (while some simply can't be built on some architecture yet, for example, Enlightenment on PowerPC64 due to lack of LuaJIT support). But in most cases, all ports of AOSC OS can be used with the same level of functionality, but with varying performance outcomes. There are several reasons to this:

- Plain performance deviations, you can't just expect a 15 year old Apple G4 to perform as well as your modern Skylake desktop, can you?
- Optimization compromises, there are certain sacrifices we had to make for a port to be (generally) universal for some particular architectures, for example, we have given up AltiVec optimizations on our PowerPC 32-bit port, so that our port can be run on older PowerPC processors like the 603e, 604e, and the G3 (G4 is the first to come with AltiVec support).
- JIT, this is a painful one, and mostly reflecting on some lesser-known architectures - JIT generally requires assembly support, which are lacking for some architectures in some software projects, say, OpenJDK, which does not yet have (or simply won't have in the forseeable future) JIT/Hotspot support for MIPS32 and PowerPC 32-bit processors.

Onto the workflow then. There is a rule among AOSC OS developers that, "there shall be no port before devices exists" - some Linux distributions (go figure) has lots of architectural ports, but sometimes no device is available for some architectures. While it's all fine and good as a technical references on these ports (in fact, we have learned a lot from Fedora and Gentoo, thank you both), we as a tiny development effort simply can't afford to start a virtual port - or "theoretical" port, let's say - this is precisely the reason why we haven't jumped on to porting AOSC OS to RISC-V yet, but when the first boards of that architecture debut, we will crack on with it. But anyways, if there exists a device availabled for us to purchase by one of our developers, a port will be started. Junde Yhi, long time AOSC contributor started his first venture of porting AOSC OS with his purchase of a Loongson 3A R2 (3A2000C) desktop of MIPS64el (MIPS 64-bit, little-endian) architecture, and it's truly an interesting (and perhaps unfortunately, quirky) machine.

The porting starts without actually doing the build, but with making "specs" for the particular port. As AOSC OS, there isn't much room for varied system designs, the work mostly comes to the optimization parameters and configuration for the toolchain (we use GNU's tools, of course). In the case of MIPS64el, Yhi spent roughly two weeks reading Loongson's compiler and optimizations specifications - not that we are making a Loongson port, but SGI's workstations are just... too much. At the end of the reading, a series of optimization parameters, or flags are collected and put in as a part of some Autobuild3 updates.

The next step would be to start reading and build along with the guides at Linux From Scratch. The only difference we make here is to change the triple to ours (in the case of MIPS64el, mips64el-aosc-linux-gnu), and incorporating package management (dpkg in our case) as soon as we could. With package management in place, it's time to start building the Core (from master of course), and debug through issues, committing changes and incorporating them into the next release. Then it just flows down the stream to our main tree, where terrible stuff like "stage-two-ing" (stripping out features for bootstrapping, and re-incorporating new features when dependencies are available) and you guess it, more bugs, will be found. But with enough packages available and tested, a new port of AOSC OS will be available from the downloads page. This process can take anywhere from weeks to months (our fastest growing ports yet are the PowerPC 32/64-bit ports, thanks to a powerful PowerMac G5 Quad, taking only 5 weeks to have the Base, MATE, and XFCE variants available), depending on the difficulty and fluidity of the porters.

What's next then? Generally, maintaining and hoping for more. Maintaining ports is a long enduring and often times tedious task. Given that our main port is still the AMD64/x86_64 port, all new package updates will be built and tested first on the AMD64 machines, pushed to the staging branch, and merged to the master branch before pushing the new updates to the community repository. Then, the updates will be organized into a task list and passed onto... usually me - owning machines from most of the architectuers available, and having horribly strong patience (just a boring personality, not praising myself by any means). Every week, ~500 new package updates/fixes commits are committed to the staging branch, and ~200 of them will be available to non-AMD64 ports (some simply can't be built, some being noarch data packages that do not need to be rebuilt). And yes, they take around ~3 times more in time expense to build despite the smaller number of tasks. And yes, these machines working together at the same time makes it a great cure to the Wisconsin winter, and a great tool for my roommate Tianhao Chai to heat his milk and such (package building for the ports generally happens in the weekends, a "good" period of time in a week by our definition).

On the "hoping for more" part, we do accept device donations, and we (generally) make guarantees on porting AOSC OS onto them. Icenowy Zheng, our ARM maintainer, receives quite a quantity of devices from hardware manufactures due to her exemplary work in "mainlining" (merging device supports and fixes into the mainline Linux kernel) support for Allwinner (sunxi) devices - as you may have seen multiple times on our news. I myself received a Nokia N900 phone from a good friend of mine - knowing its potential and well maintainership by the mainline kernel, I should be able to get AOSC OS running - and of course, releasing images for it in a timely manner.

And that sums up how the ports happens, and happens to be in the context of AOSC OS development. If you are interested in donating devices or maintaining a new port for AOSC OS (that will be really could you know...), please do find us over at the #aosc IRC channel.

— Mingcong Bai
Anthon Open Source Community
Add a comment...
Happy (Early) New Year!
by +Mingcong Bai

It's that time of a year again (to look back), and I am very glad to say that 2016 has been a great year for all of us.

Lots of news and happenings around our projects, and we have got couple of new faces to our community's development effort - most notably, +Everette Rong (Yi "Everette" Rong), who kickstarted the big endian PowerPC ports for AOSC OS, and to top things off, made an experimental go at AOSC OS on Windows 10 with his WSAOSC (Wa-Sao-sk) installer, check it out here.

Not to be out done, +Icenowy Zheng made an explosive progress on AOSC OS's ARM ports with her aosc-mkrawimg and aosc-os-arm-boot-flasher projects. Dozens of images are released for Allwinner devices and Raspberry Pi, and Kernel updates on these devices got more and more intuitive.

Progress on our localization effort were looking better than ever, we have continued our effort with Simplified Chinese localization for FOSS projects. GNOME, MATE, Audacious,, etc. have received our continued support in this particular area. Most notably, with joint effort from +Mingye Wang, +shuyu liu (Zixing Liu), and I personally (+Mingcong Bai), Wine's zh_CN translation had reached 100% completion for the first time since 1993 - and yes, that's when the project started.

Looking ahead, 2017 will be equally if not more interesting for AOSC. Development will be resumed on AST's Startup Toolkit with a brand new UI and more universal support for Linux distributions other than AOSC OS; RISC-V will (potentially) see its first commercial hardware debut, and thus a new port for AOSC OS is imminent; ACBS, a replacement for our ABBS will bring better reliability, multi-tree support (forest.conf), and security to our AOSC OS packaging work. And of course, AOSC OS will see more improvement on dependencies, installation support, and user experience.

Before we get carried away, this has been an awesome year coordinating this community and working with all of you guys. And here to my sincere gratitude, and I wish all of you a happy new year!
Anthon Open Source Community
Add a comment...
[FEATURES] New package additions: Dec. 31, 2016

Per users' requests, we have added the following packages to our community repository:

+ afflib - An open and extensible file format to store disk images and associated metadata.
+ afl - A security-oriented fuzzer.
+ averia-fonts - The Avería GWF font family.
+ construct - A powerful declarative parser/builder for binary data.
+ ctemplate - A library implementing a simple but powerful template language for C++.
+ dff - An Open Source computer forensics platform.
+ distorm - Powerful disassembler library for x86/AMD64.
+ et-xmlfile - A low memory library for creating large XML files.
+ fbset - Framebuffer setup utility.
+ jbig2dec - Decoder implementation of the JBIG2 image compression format.
+ jdcal - Julian dates, from proleptic Gregorian and Julian calendars.
+ jsmath-fonts - Font family for jsMath.
+ libbfio - A library to provide basic file input/output abstraction.
+ libewf - A library to access the Expert Witness Compression Format (EWF).
+ libfm-qt - Core library of PCManFM-Qt (Qt binding for libfm).
+ libforensic1394 - Library for performing live memory forensics over the IEEE 1394 (FireWire) interface.
+ libglademm - C++ *bindings for libglade.
+ libiodbc - Independent Open DataBase Connectivity driver library.
+ libpff - Library and tools to access the Personal Folder File (PFF) and the Offline Folder File (OFF) format.
+ libvshadow - A library to access the Volume Shadow Snapshot (VSS) format.
+ lxqt-build-tools - Various packaging tools and scripts for LXQt applications.
+ muparser - A fast math parser library.
+ mysql-workbench - A cross-platform, visual database design tool developed by MySQL.
+ openpyxl - A Python library to read/write Excel 2007 xlsx/xlsm files.
+ paprefs - A simple GTK-based configuration dialog for PulseAudio.
+ pefile - A Python module to read and work with PE (Portable Executable) files.
+ ptunnel - A tool for reliably tunneling TCP connections over ICMP echo request and reply packets.
+ pyodbc - Python bindings for UnixODBC.
+ pyorbit - Python bindings for ORBit2.
+ reglookup - Utilities for direct analysis of Windows NT-based registry files.
+ scantailor - Interactive post-processing tool for scanned pages.
+ seahorse-nautilus - PGP encryption and signing for Nautilus (GNOME Files).
+ stunnel - A program that allows you to encrypt arbitrary TCP connections inside SSL.
+ system-config-lvm - A utility for graphical configuration of Logical Volumes.
+ thermald - The Linux Thermal Daemon program from
+ tinyproxy - A light-weight HTTP proxy daemon for POSIX operating systems.
+ volatility - Advanced memory forensics framework.
+ xrdp - An open source remote desktop protocol (RDP) server.
+ yara-python - Python bindings for Yara.
+ yara - Tool aimed at helping malware researchers to identify and classify malware samples.
+ zathura-pdf-mupdf - PDF support for Zathura (MuPDF backend).
+ znc - An IRC bouncer with modules & scripts support.

To learn about how to request new packages for addition into our community repository, please check out our "pakreq" guide. Or simply shout out requests with #pakreq hashtag on our #aosc IRC channel, or on our Telegram group (joining information available on IRC).
Add a comment...
[SECURITY] AOSA-2016-0042: Update Apache HTTP Server

Please update your httpd package to version 2.4.25.

A new version of Apache HTTP Server was recently announced to address the following security vulnerability:

CVE-2016-0736, CVE-2016-2161, CVE-2016-5387, CVE-2016-8723, CVE-2016-8740.

(Please visit our news page for links)

Relevant documentation:

- Original Announcement
Add a comment...
[SECURITY] AOSA-2016-0039: Update Samba

Please update your samba package to version 4.5.3.

A new version of Samba was recently released to address the following security vulnerability:

* CVE-2016-2123
* CVE-2016-2125
* CVE-2016-2126

Relevant documentation:

- Original Announcement
Add a comment...
[FEATURE] New package additions: Dec 16th, 2016

Per users' requests, we have added the following packages to our community repository:

+ abbs - Configuration/manifest manager for Autobuild.
+ aosc-os-arm-boot-flasher - AOSC OS boot-related file update(flash)er for ARM architecture (and maybe more).
+ apm - Atom Package Manager.
+ arc-openbox - Arc theme for the Openbox window manager.
+ atool - A script for managing file archives of various types.
+ compton - A compositor for X11.
+ easy-rsa - Simple shell based CA utility.
+ electron - Build cross platform desktop apps with JavaScript, HTML, and CSS.
+ flat-remix-icon-theme - A pretty simple icon theme for Linux.
+ gost - GO Simple Tunnel.
+ gtk3-tqt-engine - GTK+ 3 engine for TQt.
+ gtk-qt-engine - GTK+ engine for TQt/Qt 3.
+ http-parser - Parser for HTTP Request/Response written in C.
+ lrzsz - xmodem, ymodem and zmodem file transfer protocols.
+ ncbi-vdb - The NCBI VDB.
+ neofetch - A fast, highly customizable system info script.
+ netperf - Network benchmark for multiple types of networks.
+ ngs - NGS Language Bindings.
+ nitrogen - Background browser and setter for X windows.
+ opencryptoki - Implementation of the PKCS#11 (Cryptoki) specification.
+ pysocks - SOCKS4, SOCKS5 or HTTP proxy for Python.
+ quodlibet - Music library manager and player.
+ racer - Rust Code Completion Utility.
+ ranger - A simple, vim-like file manager.
+ rustfmt - Rust Code Formatter.
+ rxvt-unicode - A customizable terminal emulator forked from rxvt.
+ sassc - Command line driver for libsass.
+ skanlite - Image scanning application for KDE.
+ sra-tools - The NCBI SRA (Sequence Read Archive).
+ tde-i18n - Translation and l10n data for Trinity Desktop.
+ tdenetworkmanager - NetworkManager frontend for Trinity Desktop.
+ tpm-tools - Management tools for TPM hardware.
+ virtualenv - A tool to create isolated Python environments.

To learn about how to request new packages for addition into our community repository, please check out our "pakreq" guide. Or simply shout out requests with #pakreq hashtag on our #aosc IRC channel, or on our Telegram group (joining information available on IRC).
Add a comment...
[FEATURE] ACBS is Ready to Roll

ACBS (Autobuild CI Build System), after several re-writes, is now available as a replacement to our old Autobuild manifest and configuration manager ABBS (AutoBuild Build Service). ACBS comes with enhanced functionality, improved reliability, and full compatibility with old ABBS trees:

* Multi-tree support (a "forest", so to speak).
* Checksum verification support.
* Cache cleaning and management support.
* Logging support.
* Proper dependency calculation (automatic build sequences, useful for bootstrapped bases).

Extra blings are also included:

+ Build timing utilities.
+ More detailed error messages.

The new set of tool is written in Python 3 (and you will need a version newer than 3.3), along with several essential dependencies - which are commonly found in any well built Linux distributions - ACBS is built for any Linux distribution eyeing on Autobuild for its packaging work.

New packages built for AOSC OS since today will be built with ACBS - just to give it more real-world and detailed testing - but as it stands today, it is already quite a bit more advanced than ABBS. Definitely a recommended upgrade.

Our AOSC OS packaging documentation "AOSC Cadet Training" ( is also updated for using ACBS - please note that ABBS is now marked deprecated, and you should not continue to use ABBS - we are not interested in fixing old and deprecated stuff, as we usually do.
Anthon Open Source Community
Add a comment...
[FEATURE] Update on Wine and x86 Support for ARM Devices

+Icenowy Zheng just made an update on the wine package for ARMv7 (armel), fixing some runtime issues introduced with an earlier commit. To prove its usability, she attempted to build a version of Notepad++ for her tablet running AOSC OS...

Along with the update, Zheng is currently marking all optenv32, our i686/32-bit x86 runtime environment as architectural neutral packages - in the future, all of our AOSC OS ports will be able to run i686 applications (Wine or Linux Native) with the help of Qemu User Mode Emulation. Keep posted for updates!
Add a comment...
[SECURITY] AOSA-2016-0043: Update OpenSSH

Please update your openssh package to version 7.4p1.

A new version of OpenSSH was recently announced to address the following security vulnerabilities:

CVE-2016-10009, CVE-2016-10010, CVE-2016-10011, CVE-2016-10012.

(Please visit our news page for links)

Relevant documentation:

- Original oss-security mailing list post.
Add a comment...
[SECURITY] AOSA-2016-0041: Update cURL

Please update your curl (and curl+32 if using the AMD64/x86_64 port with optenv32 installed) to version 7.52.1.

This security advisory discusses the security vulnerabilities addressed in 7.52.0 and followed by 7.52.1 as an emergency release - to fix a new security regression introduced with version 7.52.0.

Version 7.52.0 addressed the following security vulnerabilities:

* CVE-2016-9586
* CVE-2016-9952
* CVE-2016-9953

Version 7.52.1 address a security vulnerability described as follows, however, no CVE was assigned at the time of writing:

"libcurl's (new) internal function that returns a good 32bit random value was implemented poorly and overwrote the pointer instead of writing the value into the buffer the pointer pointed to.

"This random value is used to generate nonces for Digest and NTLM authentication, for generating boundary strings in HTTP formposts and more. Having a weak or virtually non-existent random there makes these operations vulnerable.

"This function is brand new in 7.52.0 and is the result of an overhaul to make sure libcurl uses strong random as much as possible - provided by the backend TLS crypto libraries when present. The faulty function was introduced in this commit."

Relevant documentation:

- Original 7.52.0 Announcement.
- Original 7.52.1 Announcement.
Add a comment...
[SECURITY] AOSA-2016-0040: Update FlightGear

Please update your flightgear package to version 2016.4.3-1.

A fix was recently introduced to the source code for the FlightGear Flight Simulator to address the following security vulnerability:

* CVE-2016-9956

"The FlightGear project fixed a security issue, allowing arbitrary file overwrites for files the user running FlightGear has write access to and could be taken advantage to for other impact as arbitrary code execution."

Relevant documentation:

- Debian Security Advisory DSA-3742. - Original oss-security mailing list post.
- Original patch.
Add a comment...
[SECURITY] AOSA-2016-0038: Update Exim
DECEMBER 31, 2016

Please update your exim package to version 4.88.

A security vulnerability was recently disclosed that:

"Exim leaks the private DKIM signing key to the log files. Additionally, if the build option EXPERIMENTAL_DSN_INFO=yes is used, the key material is included in the bounce message."

And was consequently assigned with CVE-2016-9963 (

Relevant documentation:

- Original Security Advisory
Add a comment...
Welcome to AOSC! We are a progressive and friendly open source community.
Basic Information
Decline to State
Anthon Open Source Community (AOSC)'s +1's are the things they like, agree with, or want to recommend.