Let yourself be embraced by the purple rubber toy octopus! We're happy to announce
the release of Debian 9.0, codenamed Stretch.
Want to install it?
Choose your favourite installation media among Blu-ray Discs, DVDs,
CDs and USB sticks. Then read the installation manual.
Already a happy Debian user and you only want to upgrade?
You can easily upgrade from your current Debian 8 Jessie installation,
please read the release notes.
Do you want to celebrate the release?
Share the banner from this blog in your blog or your website!
Back at DebConf 15 in Germany, I gave a talk on on AIMS Desktop (which was then based on Ubuntu), and our intentions and rationale for wanting to move it over to being Debian based.
Today, alongside the Debian 9 release, we release AIMS Desktop 2017.1, the first AIMS Desktop released based on Debian. For Debian 10, we d like to get the last remaining AIMS Desktop packages into Debian so that it could be a Debian pure blend.
Students trying out a release candidate at AIMS South Africa
Congratulations to everyone who has played a part in the creation of Debian GNU/Linux 9.0! It s a great release, I ve installed the pre-release versions for friends, family and colleagues and so far the feedback has been very positive.
This release is dedicated to Ian Murdock, who founded the Debian project in 1993, and sadly passed away on 28 December 2015. On the Debian ISO files a dedication statement is available on /doc/dedication/dedication-9.0.txt
Here s a copy of the dedication text:
Dedicated to Ian Murdock ------------------------ Ian Murdock, the founder of the Debian project, passed away on 28th December 2015 at his home in San Francisco. He was 42. It is difficult to exaggerate Ian's contribution to Free Software. He led the Debian Project from its inception in 1993 to 1996, wrote the Debian manifesto in January 1994 and nurtured the fledgling project throughout his studies at Purdue University. Ian went on to be founding director of Linux International, CTO of the Free Standards Group and later the Linux Foundation, and leader of Project Indiana at Sun Microsystems, which he described as "taking the lesson that Linux has brought to the operating system and providing that for Solaris". Debian's success is testament to Ian's vision. He inspired countless people around the world to contribute their own free time and skills. More than 350 distributions are known to be derived from Debian. We therefore dedicate Debian 9 "stretch" to Ian. -- The Debian DevelopersDuring this development cycle, the amount of source packages in Debian grew from around 21 000 to around 25 000 packages, which means that there s a whole bunch of new things Debian can make your computer do. If you find something new in this release that you like, post about it on your favourite social networks, using the hashtag #newinstretch or look it up to see what others have discovered!
To get some idea about the expectations and current usage of alioth I created
a survey. Please take part in
it if you are an alioth user. If you need some background about the coming
alioth replacement I recommend to read the great lwn article written by anarcat.
Back at DebConf 15 in Germany, I gave a talk on on AIMS Desktop (which was then based on Ubuntu), and our intentions and rationale for wanting to move it over to being Debian based.
Today, alongside the Debian 9 release, we release AIMS Desktop 2017.1, the first AIMS Desktop released based on Debian. For Debian 10, we d like to get the last remaining AIMS Desktop packages into Debian so that it could be a Debian pure blend.
Students trying out a release candidate at AIMS South Africa
Congratulations to everyone who has played a part in the creation of Debian GNU/Linux 9.0! It s a great release, I ve installed the pre-release versions for friends, family and colleagues and so far the feedback has been very positive.
This release is dedicated to Ian Murdock, who founded the Debian project in 1993, and sadly passed away on 28 December 2015. On the Debian ISO files a dedication statement is available on /doc/dedication/dedication-9.0.txt
Here s a copy of the dedication text:
Dedicated to Ian Murdock ------------------------ Ian Murdock, the founder of the Debian project, passed away on 28th December 2015 at his home in San Francisco. He was 42. It is difficult to exaggerate Ian's contribution to Free Software. He led the Debian Project from its inception in 1993 to 1996, wrote the Debian manifesto in January 1994 and nurtured the fledgling project throughout his studies at Purdue University. Ian went on to be founding director of Linux International, CTO of the Free Standards Group and later the Linux Foundation, and leader of Project Indiana at Sun Microsystems, which he described as "taking the lesson that Linux has brought to the operating system and providing that for Solaris". Debian's success is testament to Ian's vision. He inspired countless people around the world to contribute their own free time and skills. More than 350 distributions are known to be derived from Debian. We therefore dedicate Debian 9 "stretch" to Ian. -- The Debian DevelopersDuring this development cycle, the amount of source packages in Debian grew from around 21 000 to around 25 000 packages, which means that there s a whole bunch of new things Debian can make your computer do. If you find something new in this release that you like, post about it on your favourite social networks, using the hashtag #newinstretch or look it up to see what others have discovered!
The Debian Release Team in coordination with several other teams are preparing the last bits needed for releasing Debian 9 Stretch.
Please, be patient! Lots of steps are involved and some of them take some time, such as building the images, propagating the release through the mirror network, and rebuilding the Debian website so that "stable" points to Debian 9.
Follow the live coverage of the release on https://micronews.debian.org or the @debian profile in your favorite social network!
We'll spread the word about what's new in this version of Debian 9, how the release process is progressing during the weekend and facts about Debian and the wide community of volunteer contributors that make it possible.
https://social.gl-como.it/photos/valhalla/image/4d9414558d6fc8782d7c7e65092f1535
Hosted Weblate provides also free hosting for free software projects. The hosting requests queue was over one month long, so it's time to process it and include new project.
This time, the newly hosted projects include:
git cinnabar upgrade command to handle metadata upgrade separately from fsck.git cinnabar fsck also faster.
Debian 9 Stretch , the latest stable version of the venerable Linux distribution, will be released in a few days. I pushed a last-minute change to get the latest security and feature update of WebKitGTK+ (packaged as webkit2gtk 2.16.3) in before release.
Carlos Garcia Campos discusses what s new in 2.16, but there are many, many more improvements since the 2.6 version in Debian 8.
Like many things in Debian, this was a team effort from many people. Thank you to the WebKitGTK+ developers, WebKitGTK+ maintainers in Debian, Debian Release Managers, Debian Stable Release Managers, Debian Security Team, Ubuntu Security Team, and testers who all had some part in making this happen.
As with Debian 8, there is no guaranteed security support for webkit2gtk for Debian 9. This time though, there is a chance of periodic security updates without needing to get the updates through backports.
If you would like to help test the next proposed update, please contact me so that I can help coordinate this.
It's been a while. And currently I shouldn't even post but rather pack my stuff because I'll get the keys to my flat in 6 days. Yay!
But, for packing I need a good sound track. And today it is Apollo 440. I saw them live at the Sundance Festival here in Vienna 20 years ago. It's been a while, but their music still gives me power to pull through.
So, without further ado, here are their songs:
The Debian Project welcomes and encourages participation by everyone. No matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community. While much of the work for our project is technical in nature, we value and encourage contributions from those with expertise in other areas, and welcome them into our community.The Debian Diversity Statement has recently turned 5 years old, and I still find it the best diversity statement I know of, one of the most welcoming texts I've seen, and the result of one of the best project-wide mailing list discussions I can remember.
If you have a bunch of machines running OpenBSD for firewalling purposes, which is pretty standard, you might start to use source-control to maintain the rulesets. You might go further, and use some kind of integration testing to deploy changes from your revision control system into production.
Of course before you deploy any pf.conf file you need to test that the file contents are valid/correct. If your integration system doesn't run on OpenBSD though you have a couple of choices:
pfctl -n -f /path/to/rules/pf.conf. deagol ~/pf.ctl $ ./pfctl ./pf.conf
./pf.conf:298: macro 'undefined_variable' not defined
./pf.conf:298: syntax error
vlans=" vlan1,vlan2 "
..
pass out on $vlans proto udp from $undefined_variable
pass out on vlan12 inet proto tcp from <unknown> to $http_server port 80,443
unknown just silently fails. In slowly removing more and more code to make it compile I lost the ability to keep track of table definitions - both their names and their values - Thus the fetching of a table by name has become a NOP, and a bogus name will result in no error.
Now it is possible, with more care, that you could use a hashtable library, or similar, to simulate these things. But I kinda stalled, again.
(Similar things happen with fetching a proto by name, I just hardcoded inet, gre, icmp, icmp6, etc. Things that I'd actually use.)
Might be a fun project for somebody with some time anyway! Download the OpenBSD source, e.g. from a github mirror - yeah, yeah, but still. CVS? No thanks! - Then poke around beneath sbin/pfctl/. The main file you'll want to grab is parse.y, although you'll need to setup a bunch of headers too, and write yourself a Makefile. Here's a hint:
deagol ~/pf.ctl $ tree
.
inc
net
pfvar.h
queue.h
sys
_null.h
refcnt.h
tree.h
Makefile
parse.y
pf.conf
pfctl.h
pfctl_parser.h
y.tab.c
3 directories, 11 files
Debian needs feature X but it is already in the enterprise version. We make a patch and, for commercial reasons, it never gets merged (they already sell it in the enterprise version). Which means we will have to fork the software and keep those patches forever. Been there done that. For me, that isn't acceptable.This concern was further deepened when GitLab's Director of Strategic Partnerships, Eliran Mesika, explained the company's stewardship policy that explains how GitLab decides which features end up in the proprietary version. Praveen pointed out that:
[...] basically it boils down to features that they consider important for organizations with less than 100 developers may get accepted. I see that as a red flag for a big community like debian.Since there are over 600 Debian Developers, the community seems to fall within the needs of "enterprise" users. The features the Debian community may need are, by definition, appropriate only to the "Enterprise Edition" (GitLab EE), the non-free version, and are therefore unlikely to end up in the "Community Edition" (GitLab CE), the free-software version. Interestingly, Mesika asked for clarification on which features were missing, explaining that GitLab is actually open to adding features to GitLab CE. The response from Debian Developer Holger Levsen was categorical: "It's not about a specific patch. Free GitLab and we can talk again." But beyond the practical and ethical concerns, some specific features Debian needs are currently only in GitLab EE. For example, debian.org systems use LDAP for authentication, which would obviously be useful in a GitLab deployment; GitLab CE supports basic LDAP authentication, but advanced features, like group or SSH-key synchronization, are only available in GitLab EE. Wirt also expressed concern about the Contributor License Agreement that GitLab B.V. requires contributors to sign when they send patches, which forces users to allow the release of their code under a non-free license. The debate then went on going through a exhaustive inventory of different free-software alternatives:
On the mailinglist it seemed that some Debian maintainers do not agree with our open core business model and demand that there is no proprietary version. We respect that position but we don't think we can compete with the purely proprietary software like GitHub with this model.
Personally I'm leaning towards the feeling that all configuration, code and dependencies for Debian services should be packaged and subjected to the usual Debian QA activities but I acknowledge that the current archive setup (testing migration plus backporting etc) doesn't necessarily make this easy.Wise did say that "DSA doesn't have any hard rules/policy written down, just evaluation on a case-by-case basis" which probably means that pagure packaging will not be a blocker for deployment. The last pending issue is the question of the mailing lists hosted on Alioth, as pagure doesn't offer mailing list management (nor does GitLab). In fact, there are three different mailing list services for the Debian project:
Note: this article first appeared in the Linux Weekly News.
Apart from being somewhat slow, one of the downsides of the
original Raspberry Pi SoC was that it had an old ARM11 core which
implements the ARMv6 architecture. This was particularly
unfortunate as most common distributions (Debian, Ubuntu, Fedora,
etc) standardized on the ARMv7-A architecture as a minimum for
their ARM hardfloat ports. Which is one of the reasons for Raspbian
and the various other RPI specific distributions.
Happily, with the new Raspberry Pi
2 using Cortex-A7 Cores (which implement the ARMv7-A
architecture) this issue is out of the way, which means that a a
standard Debian hardfloat userland will run just fine. So the
obvious first thing to do when an RPI 2 appeared on my desk was to
put together a quick Debian Jessie image for it.
The result of which can be found at: https://images.collabora.co.uk/rpi2/
Login as root with password debian (Obviously do change the
password and create a normal user after booting). The image is 3G,
so should fit on any SD card marketed as 4G or bigger. Using
bmap-tools
for flashing is recommended, otherwise you'll be waiting for 2.5G
of zeros to be written to the card, which tends to be rather
boring. Note that the image is really basic and will just get you
to a login prompt on either serial or hdmi, batteries are very much
not included, but can be apt-getted :).
Technically, this image is simply a Debian Jessie debootstrap
with a extra packages for hardware support. Unlike Raspbian the
first partition (which contains the firmware & kernel files to
boot the system) is mounted on /boot/firmware rather then on /boot.
This is because the VideoCore expects the first partition to be a
FAT filesystem, but mounting FAT on /boot really doesn't work right
on Debian systems as it contains files managed by dpkg (e.g. the
kernel package) which requires a POSIX compatible filesystem.
Essentially the same reason why Debian is using /boot/efi for the
ESP partition on Intel systems rather the mounting it on /boot
directly.
For reference, the RPI2 specific packages in this image are from
https://repositories.collabora.co.uk/debian/
in the jessie distribution and rpi2 component (this repository is
enabled by default on the image). The relevant packages there
are:
At Collabora one of the
many things we do is build Debian
derivatives/overlays for customers on a variety of architectures
including 32 bit and 64 bit ARM systems. And just as Debian does,
our OBS system builds on
native systems rather than emulators.
Luckily with the advent of ARM server systems some years ago
building natively for those systems has been a lot less painful
than it used to be. For 32 bit ARM we've been relying on Calxeda blade servers,
however Calxeda unfortunately tanked ages ago and the hardware is
starting to show its age (though luckily Debian Stretch does
support it properly, so at least the software is still fresh).
On the 64 bit ARM side, we're running on Gigabyte MP30-AR1 based
servers which can run 32 bit arm code (As opposed to e.g. ThunderX
based servers which can only run 64 bit code). As such running
armhf VMs on them to act as build slaves seems a good choice, but
setting that up is a bit more involved than it might appear.
The first pitfall is that there is no standard bootloader or
boot firmware available in Debian to boot on the "virt" machine
emulated by qemu (I didn't want to use an emulation of a real
machine). That also means there is nothing to pick the kernel
inside the guest at boot nor something which can e.g. have the
guest network boot, which means direct kernel booting needs to be
used.
The second pitfall was that the current Debian Stretch armhf
kernel isn't built with support for the generic PCI host controller
which the qemu virtual machine exposes, which means no storage and
no network shows up in the guest. Hopefully that will get solved
soonish (Debian
bug 864726) and can be in a Stretch update, until then a custom
kernel package is required using the patch attach to the bug report
is required but I won't go into that any further in this post.
So on the happy assumption that we have a kernel that works, the
challenge left is to nicely manage direct kernel loading. Or more
specifically, how ensure the hosts boots the kernel the guest has
installed via the standard apt tools without having to copy kernels
around between guest/host, which essentially comes down to exposing
/boot from the guest to the host. The solution we picked is to use
qemu's 9pfs support to share a folder from the host and use that as
/boot of the guest. For the 9p folder the "mapped" security mode
seems needed as the "none" mode seems to get confused by dpkg
(Debian
bug 864718).
As we're using libvirt as our virtual machine manager the
remainder of how to glue it all together will be mostly specific to
that.
First step is to install the system, mostly as normal. One can
directly boot into the vmlinuz and initrd.gz provided by normal
Stretch armhf netboot installer (downloaded into e.g /tmp). The
setup overall is straight-forward with a few small tweaks:
virt-install --name armhf-vm --arch armv7l --memory 512 \
--disk /srv/armhf-vm.img,bus=virtio
--filesystem /srv/armhf-vm-boot,virtio-boot,mode=mapped \
--boot=kernel=/tmp/vmlinuz,initrd=/tmp/initrd.gz,kernel_args="console=ttyAMA0,root=/dev/vda1"
virtio-boot /boot 9p trans=virtio,version=9p2000.L,x-systemd.automount 0 0
vm=$1
action=$2
bootdir=/srv/$ vm -boot
if [ $ action != "prepare" ] ; then
exit 0
fi
if [ ! -d $ bootdir ] ; then
exit 0
fi
ln -sf $(basename $(cat $ bootdir /vmlinuz)) $ bootdir /virtio-vmlinuz
ln -sf $(basename $(cat $ bootdir /initrd.img)) $ bootdir /virtio-initrd.img
Next.