On a personal note, I do apologise for the lack of update for the past month - as my friend Junde Yhi and I went on a 2-week trip to parts of Russia - and now it’s the beginning of the school season so time management was a great struggle.
Anyways, lets go on with the update. I’m happy to report that Core 5.0 is now in the final testing phase (Release Candidate 4), and should hit the stable repository by the end of the month - yes, with the Joint-August-and-September Wave of updates (and for the same reason mentioned above, we were unable to release the August wave, need more packagers!).
We have now finished preparing a semi-final set (well, final if we didn’t find anything stupid) of Core 5 wallpapers with a completely new style, here’s a small banner to be used in the Core 5 announcement to give you some ideas…
If you want, the full set is already available at the aosc-os-artworks repository, and will be made available to users of the Testing repositories in ~6 hours.
Apart from the wallpaper change, we have made quite some changes to the Core, including…
But I’m not going to share them all just yet, as in the Release Candidate phase, things can still change… a little bit. We will post another update on the actual date-of-release.
Another thing worth looking forward to in September or October is the inclusion of the first wave of “Overlay” packages for AMD64 (x86_64). We are currently making some final touches to the Autobuild3 build toolkit and apt-gen-list - which when done, Overlay repositories should be enabled based on your processor’s capabilities.
More on that later (it’s still crazy busy here so I do apologise for repeated delays).
As for non-AMD64 (ARMv7, AArch64, PowerPC 32-bit, PowerPC 64-bit, MIPS 32-bit, MIPS 64-bit) ports of AOSC OS, we are currently working to synchronise all updates with the ABBS Tree - we can’t guarantee a date of completion just yet, but here are the two things we are sure about…
bugfixupdates (and that includes all security fixes).
bugfixupdates will be synchronised immediately, while “normal updates” from the
stagingbranch will settle in the forseable future.
New AOSC OS tarballs and images will roll out in October (probably by the end of the month) with the Core 5 updates - but again, for non-AMD64 ports, this will not necessarily include all the feature updates from the main tree - we do apologise for that.
— Mingcong Bai
Just a quick update that we have confirmed that our repository server is now up and running, all regular services have returned to stable status.
Again, we apologise for any inconvenience experienced.
At this point (well beyond 12 hours), we are sorry to announce we are yet to be able to have our repository server up for service. Our host over at Taiwan is still having issue from within OSSPlanet’s datacenter…
Here are two updates we received from our partner Matthew Lien…
At 5:23 UTC, August 19th.
All public networks working now. Two PSU[s] on SAN (Storage Area Network) Switch failed at once. The chance is lower than winning the lottery, but it really happened. Trying to fix it.
At 14:53 UTC, August 19th.
Our DC staffs are trying to recover VM [Virtual Machine] infra. Sorry for the unexpected inconvenience...
Therefore, please keep watching out for updates in the coming day. We do as well apologise for any inconvenience with this unfortunate repository downtime.
Due to damaged high voltage power lines and equipment at our host for community repository, we are expecting an one-day downtime for this server.
At the meantime, we would recommend that you:
We apologise for any inconvenience.
Here below is a copy of the original announcement from our server host OSSPlanet:
MAINTENANCE DOWNTIME: 2017/8/19 9am-4pm CST (1am-8am UTC) In short: Tomorrow. We are going to have a maintenance downtime for damaged High Voltage power lines and equipment (ATS) to prevent further unexpected issues in case of power outage. Please shutdown your VMs before 7am CST (8/18 23:00 UTC) to prevent any data lose. We're sorry for the inconveniences. If you need any assistance, please feel free to contact us.
With a somewhat successful completion of the monthly update cycle in the July Wave, we have just finished discussion on goals/objectives in the August Wave of updates. The focus or the theme, if you like, of this month will be refinement and clean up.
First of all, a majority of work to be done this week will be dictacted by ACID - a CI-like mechanism which builds every single packages on offer in the ABBS Tree. Packages to be fixed are mounting up to couple hundreds at present, and that will be what we are doing this month - fix them while the number climbs even higher. In addition to that, new commits introduced to our Autobuild3 toolkit - if you haven’t heard of it yet, it’s our only official packaging tool for AOSC OS - increased the level of strictness while running build scripts, loads of old scripts should end up failing. It’s better to rebuild these old and low-quality packages preemptively than ending up as bugs discovered by users, and this is exactly why we are doing this in August.
While handling this potentially significant task load, in August…
longtermlabel, should be re-investigated and (if time allows) fixed, or else closed (if justified).
How about package updates then? Those not specifically requested by community members will be handled according to time allowance in August - while of course, those requested will be dealt with with priority. As always, security and urgent bugfixes will be provided at instance of availability as usual, no worries there.
Hopefully, in September we developers and users will be working with a cleaner copy of AOSC OS.
— Mingcong Bai
Today marks the conclusion to our first AOSC OS monthly update cycle - yes, we are a day late, however, this was largely due to some difficulties trying to get Mozilla software (Firefox, Thunderbird, etc.) working on ARMv7 (
armel) and AArch64 (
arm64) - not much success this month despite a five-day effort, however, we’ve heard good news about version 55 of Mozilla software. Anyways, here’s a re-cap.
This NVIDIA Jetson TX1 development kit has handled most of the packaging work, computing resources on non-PC platform is still quite scarce in AOSC.
With a longer period for packaging and testing, we are more confident about our updates. Another thing which time could “buy” is better attention to usability of packages - and that would include higher availability of packages for a particular port, higher reliability, and more importantly, better coverage with usability investigation for existing packages.
The first part could be seen with updates made to our two ARM ports, which includes for the first time, a full KDE/Plasma suite. Though we are still having a blocker which prevented Plasma from running on ARMv7 devices, and a minor issue which will crash KInfoCenter when checking PCI information on a device (which is, well, most ARM devices) which does not have such bus on board. We will be looking into pushing a quick patch revision for ARMv7 later this week for the former issue, while the latter will have to wait for upstream’s response (it is quite dangerous for a software upstream to disregard their own portable software running on non-x86 platforms, eh?). Apart from that, we are looking at a ~+300 package delta for this port, and more will come later as we get around to it.
Krita running on an AArch64-capable board, Orange Pi PRIME - AOSC OS image is available in the download page.
For usability investigation then, we would have to talk about two sets development utilities, the Ciel (Lion Yang asked me to leave “the” in so…) and ACID (just a random name). The Ciel is a (development) environment deployment and manipulation kit which manages one or more systemd-nspawn containers running on a hierarchical OverlayFS architecture, which allows for quick rollback of development/packaging environment(s) - soon to be a requirement for AOSC OS packaging, starting as an experiment in August.
Working upon the Ciel will be ACID, which is a simple script running on our servers to thoroughly build all packages in our ABBS tree, acting somewhat like a CI (considering the amount of packages - 4000+ of them - to be built continuously over the course of a month) to discover any packaging error - missing dependencies, misspelled words, incorrect scripting, and more. This system will surely improve the general packaging quality for AOSC OS, benefiting developers and users alike.
Lion Yang’s laptop looking at a netdata page of our buildbot (compiling host).
With the introduction of monthly cycles, we have now introduced two new types of community requests available to community members: updreq (Update Request) and optreq (Optimisation Request). The former is quite easy to understand, a package is too old, then request it.
The latter though could be more variable in its content, for example, Profile Guided Optimisation is available for a package, say
git, then a community member could open a optreq specifying building the
git package with PGO enabled (which involves changes to the build script, or configurations). For another example, which will be a future feature to be introduced to AOSC OS, the Overlay system - in this case, a community member may request that the package Python to be built with AVX2 support flags enabled, further enhancing its performance on newer processors, to be found in its
While updreq could be a quick and simple request, optimisation could quite easily be more difficult to open, and for our developers to investigate request and decide on if such request is actually beneficial - and to be fair, this could require more technical awareness on the part of our community members, one may quite simply think that “GNOME is too damn slow on my computer” is a valid request for us to invest into, but let’s just say up front, “tell it to the upstream, we did not write the program, can’t really help here, sorry”.
We’ve mentioned that PowerPC (32/64-bit big endian) ports will be halted until September due to lack of device availability for building and testing.
Similarly, but with time, our MIPS maintainer Junde Yhi decided that it will be quite difficult for our MIPS ports to catch up with the cycles until some major architecture-specific issues (compilers, and more) could be properly resolved. He’s also estimating a September return to the cycled updates. Meanwhile, catching up will be his task.
You might have noticed a lack of AOSA news posts on this page in August, we are currently working on a new community website which contains AOSC OS related Errata and Knowledge Base articles. Future AOSA will be posted there with a set format and more technical details (vulnerability descriptions, and PoCs if available).
We will keep you updated on this issue.
My apologies for rambling on and on about July - there are actually quite a bit happening in our July development cycle, the changelog is over 700 lines long, it’s quite hard to generalise them all - will keep practicing, I promise (LOL). But do expect the same amount of work done to AOSC OS - as our part of our continuous development effort to improve and optimise AOSC OS as your daily productivity platform.
Anyways, please enjoy this month’s update. For more information on what’s changed in this month’s wave of updates, please take a read at our complete changelog.
Information on August wave of updates will be announced tomorrow, or the day after - we are currently in the process of determining what’s to be done this month. Stay tuned.
— Mingcong Bai (with kind regards)
Thanks to SB Blog (烧饼博客), our community website and some of our infrastructures are now migrated to a new server with greater bandwidth and application performance.
As you might have noticed before, our website struggled to load all of the elements or even to stay up - not an ideal experience considering all the time spent on the loading state. This was an issue mainly related to prior Internet connectivity constraints found in certain areas of the world (for the sake of politics-free creed of our community, we won’t get into details here - the removal of our ICP registration information from the footer should be a good hint), and thus we relied heavily on reverse proxy on servers scattered across multiple countries.
With that said, we are grateful of Qingcloud’s continued support for our community network infrastructure - even though our websites have moved away from their servers, some of our behind-the-scenes services - our community relay for BuildBots (our “nickname” for build hosts, if you will) for example.
Please do report any connectivity or rendering issues you have encountered to our community channel at
#aosc, and enjoy your stay!
In this special issue of Dev. Updates, we are presenting to you a new, monthly, and function defined update pattern for AOSC OS. With this change to update pattern, AOSC OS will be updated in a scheduled fashion, where:
With that said, with July, you will not be receiving updates to your AOSC OS installation on a irregular basis (usually we aimed for a batch per week, but updates could had happened on a daily basis as well… essentially it was never planned or guaranteed), instead, we are expecting to ship the July wave of updates by around 28th - for all architectures/ports. But as aforementioned, security and important bugfix updates will be pushed as soon as they become available.
What if I can wait though, you asked… Well, by our schedule, we are expected to finish all update packages by Day 20, and tests finished by Day 25 of each month (February could be a mess but we will see). That said, by Day 20 of each month, updates will be pushed to our testing repositories, details coming in the following weeks leading up to AOSCC. However, if you do mean serious business when using AOSC OS, you might want to steer clear of that - as packages could be overwritten without any version change, making it hard sometimes to manage your updates - not to mention all the potential bugs you may run into, as we haven’t tested them yet when pushing all these fresh updates to the testing repositories.
It should also be noted that general version or feature updates of all AOSC OS packages are collected and scheduled on the first day of each month, meaning that if a package has a new version to be released on July 2nd, it will be pushed with the August wave of updates - could be sad for some of you cutting-edge users, but we have our reasons not to go full Arch Linux, and here are our reasons…
Firstly, with the introduction of multiple ports and noarch/data packages, updates across different AOSC OS ports could be asynchronous, meaning that some data packages - which is shared among all ports - could be unsuitable for one or more of the ports, as newer data packages could be unsuitable for older application/binary packages, and vice-versa. This was heavily exhibited in the past 6 months with our developers struggling to find time.
Secondly, quality is king, while it’s “cool” as a distribution to be able to push a new GNOME release set the week it’s got released, the price could be steep as it might come with all manners of issue - introduced with upstream code or general oversight of our packagers - making it hard for work to be carried out on AOSC OS when a big batch of updates come untested.
And lastly, this gives our developers more time (which is not in abundance as most of us are college students) to “improve” our packages, and not just updating them when an update is available - that is a general waste of time for us, and not exactly productive when it comes to improve user experience of AOSC OS. With more time on hand for handling updates and packaging, this could lead to a quality improvement, in general, to AOSC OS.
So that’s all we have for now, a quick heads up for our fellow AOSC OS users. Please enjoy the summer.
Unless the security update come in a form of a major update, which could potentially break its dependees. In which case you will be notified while we figure out a way to handle this issue. ↩︎
This means that if with a month’s update, the package simply stopped working (which is unlikely given that we will be doing tests on them), or a date-sensitive application ceased to function - for example,
youtube-dl, which relies constantly on newest protocols/routines to grab videos off websites. In that case, upon request, we will update the package(s) and make it (them) available as soon as possible. ↩︎
Please update your
systemd package to version
A security vulnerability was recently discovered in
systemd-resolved (DNS resolve configuration daemon) that…
Certain sizes passed to dns_packet_new can cause it to allocate a buffer that’s too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this - so, on x86 this will be a page-aligned number - 80. Eg, calling dns_packet_new with a size of 4016 on x86 will result in an allocation of 4096 bytes, but 108 bytes of this are for the DnsPacket struct.
A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that’s too small, and subsequently write arbitrary data beyond the end of it.
This security vulnerability was assigned CVE-2017-9445.
Please update your
linux+kernel package so that your Linux Kernel version is
4.11.5 or higher; or update your
linux+kernel+lts package so that your Linux Kernel on Long-Term Support branch is version
4.9.32 or higher.
A security vulnerability was reported recently that…
Until recently, /dev/snd/timer driver was prone to a data race, which led to uninitialized memory from the kernel heap being copied to the userspace.
And this was assigned CVE-2017-10000380.