Wookey

The wrap of 32-bit time_t in Jan 2038 is only 15 years away. The people designing 32-bit linux products/systems still likely to be in use then have long product cycles so fixing this has become quite urgent. The base work has been done, but how to manage this ABI transition in distro-world needs some research, planning and co-ordination amongst distros. This session intends to get feedback on the problem and help inform a plan.

The fundamental choice is whether to treat it is a new arch/ABI/triplet or to migrate within the existing 32-bit arches/triplets to the new ABI. If different distros take different paths here we could end up in very confusing place. Updating ABIs has happened before so it is possible, but time_t appears in a lot of places and such a migration is certainly tricky. It may not be practical for some binary distros. Rebuilding from scratch is simpler but definitely requires a new GNU triplet.

Various people have looked into this over the last 3 years, but no one person has a good overview. Exactly how difficult this transition is still needs some experimentation and research. FOSDEM is a good opportunity to see where we are at, and see if we are agreed on a way forward.

A look at what's new (and old) in arm world. Arm64 is maturing as an architecture with a list of new features, and instructions. Some of them are interesting, but ABI-incompatible with the existing arm64 port and at some point we will have to think about whether there is anything that might be important enough to justify a new port. Meanwhile 32-bit arm is increasingly being relegated to embedded-world and our ports get harder to support as upstreams lose interest in baselines faster than we do. And there is the looming 2036 deadline for 32-bit time_t. We need to deal with that more or less immediately if we are going to. I'll tell you what's gone on so far and what I reckon we should do next. So this talk will be a bit of a romp through stuff that is going on with the arm ports, and hopefully inform people enough to have an intelligent discussion about the future.

This BoF is a chance for anyone interested in rust on Debian and packaging rust software to talk about their interests and issues. In case you don't already know, Rust is an efficient new language with some very nice features for security and parallelism https://www.rust-lang.org/ As it grows in popularity more software is written in it, which means there is a demand for it in distributions. Do you have particular rust software you would like to package? One subject we hope to cover is the problem that the current mapping of rust crates to packages produces a lot of small binary packages that then get stuck in the NEW queue. This is unsatisfactory for everyone: FTPmasters, rust packagers and users. Getting the right people in a (virtual) room might help us work out what to do about it. https://wiki.debian.org/Teams/RustPackaging https://wiki.debian.org/Teams/RustPackaging/Policy

Arm64 (aka Aarch64) is now fully available in distros. Nearly everything is built, with a few annoying exceptions. However quite a lot of stuff may not actually work very well, or may run embarassingly slowly. We want to know what's broken so we can fix it! This talk is intended to kick off this process of finding all the breakage and room for optimisations.

The arm64 port is now in pretty good shape with most things ported and built. However we know that there is plenty of software that is not optimised and some may not actually work at all. Please come along and moan about anything you have found which doesn't work as well on arm64 as it does on x86. We (Linaro, ARM and Debian) want your feedback on where to direct effort next.

This talk will cover the current status of the port, and of hardware availability. Only a few things are completely missing, but we know that a lot of software is using the basic 'fallback support' where other architectures have specific optimisations. Some stuff is probably building, but not actually working right. We are keen to fix things that are actively getting in the way of using arm64 in real systems, but to do that we need feedback from users on what to look at next as we move from mostly enablement to mostly optimisation. GCC, OpenJDK, & LLVM are known to be in good shape, but there is a pile of other stuff that probably isn't. It's very hard to test 'all the software in the world', so please tell us about stuff you've noticed not working well, or incredibly slowly, or that you suspect might be a problem and need work.

Bootstrapping a new Debian port of 18,000 source packages is always a massive job, and on average happens every year.

This year it's arm64. This talk covers how such a port is done, and the work of the last two years (on multiarch, cross-tools, dependency-anaylsis tools and packaging infrastructure) to make this a repeatable and largely automated process, rather than an epic labour of hackery and bodging.

It covers specific issues of the arm64 port, such as no hardware existing yet, and the current state of play.

Multiarch is a properly generic solution to the installation and use of library packages from one than one architecture at a time, which changes the way running non-native binaries and crossbuilding are dealt with in a fundamental way. It is both powerful and intrusive and has taken a long time to make happen. This talk explains what it is, how it works, and what you can do with it. We will also discuss future adoption by other distros.