DebConf16

Panel discussion, aimed at the general public and more technical participants alike. The panel will discuss the open hardware movement, and how it fits in with Smart Homes. It will highlight and discuss the futurology, trends, and challenges. Challenges include security, the role of big vendors, the requirement for a more powerful platform, competing interests and the role of industrial providers. The panel will be hosted by Bernelle Verster, and panelists include Andy Simpkins and others. (Please get in touch if you want to be on the panel too)

Code For South Africa use technology to promote informed decision making for social change. This talk points out some of the tech and principles we use to maximise our positive impact on society. From building a data gathering platform for citizen journalists, to releasing government financial data, FLOSS and a lean process helps deliver the best bang for the buck in these important partnerships. Often avoiding writing new software delivers more value, and frees us so that when we do need to write something, it counts.

The talk would cover my first brush with computing itself, the need and move to GNU/Linux, distro hopping and the need for that. the change to Debian and how it became my home. It would also be about the various choices and mistakes I made when I started and things to look out for. The audience would be people who are still unaware about the benefits of FOSS, community engagement and fence-sitters.

Again on Debian Day if the local LUG doesn't want to take or needs help. Willing to help out. The workshop would be to go through a basic install using regular installer and the GUI installer. Share thoughts about paritioning, things to do after installation, tips for security, updating and upgrading packages using both CLI (command-line) methods as well as GUI. Finish with some simple GNU/Linux commands which make life easier on the terminal.

A bof especially targeted at DebConf first timers, from DebConf old timers. What to expect, how to communicate effectively, how to get the most from this experience. This is a repeat of talk by Enrico Zini (enrico), and Francesca Ciceri (MadameZou) at DebConf15, which was my first DebConf. When I learnt they will not be coming, I asked to repeat the talk on their behalf as I found it very useful. You can see their talk here: https://summit.debconf.org/debconf15/meeting/170/new-to-debconf-bof/

Free software is a unique social movement in that for-profit companies have a deep interest in the outcome of the movement. Where the interest of companies and free software ideology overlap there is a powerful amplification of effort. Many ideological individuals have become employed writing free software and companies have become an important source of funding for the movement. While for-profit involvement is important and in fact inevitable where free software is successful, we as a community must evaluate the relationships we have with companies. In this talk, Karen will examine these relationships and discuss how they impact the future of free software.

A look, as an insider, on how a multi billion dollar industry is changing the game in the world's largest democracy from an insider's point of view. I would like to talk about my journey as a female coder from a developing nation which gives me a different perspective to the world. From parents who taught me to use Linux at an early age to living in the land at the verge of an IT boom which assures a job to anyone with basic computer knowledge. Anyone at any stage of their professional life can be the audience. The goal is to entertain the audience while shedding light on how technology is changing India and helping us solve our problems and how you can leverage some of that to find a solution you maybe looking for. Special emphasis on women empowerment and future prospects.

Last year, I committed myself to contribute to Open Source projects, daily, for 365 days in a row. The talk will tell a story of this experience, the difficulties encountered, lessons learned and why (or not) you should consider doing this as well. No technical background is required.

A friendly introduction to free software, open source, and Debian, with an opportunity for the audience to ask questions.

The role of information technology in the struggle for freedom, including the IBM apartheid case -- (the dompas, my correspondence with Mondo2000, Wired Magazine and Khulumani), nascent online protests, modem activism (West Coast, Silicon Valley and Cape Town), the dawn of information rights in South Africa, (Article 14 Privacy, 32 Access to Information), NetDemocracy and Constitution Building during 1995-1996 (canvassing of Communication Minister's Jay Naidoo and Pallo Jordan, iCafe sessions), some important milestones along the way, Electronic Freedom Charter, recent activism around the Cybercrime Bill, Privacy and Information Access, and other bills eroding communications freedom.

Teach the internet the language of your plants. Learn how to communicate with and monitor your garden with internet of things (IoT) basics. In this workshop, you will learn how to build your own complete internet of things garden, which will enable you to monitor the health of your plants from the internet. You will program your own electronics (or hardware), build and connect sensors, and design a specialized dashboard to check on your plants and their progress from anywhere and any device. Included in the workshop is a brief introduction about internet of things, basic electronics and programming. Note: 15 participants maximum, please sign up. Please come 10 mins before workshop and bring your laptop if possible. Attending workshops are free for participants who sign up. If you would like to take one of the products with you after the workshop, donations are very welcome in order to cover the cost of materials.

The Square Kilometer Array radio astronomy telescope will be one of the world's largest scientific instruments, spanning half the globe, with components distributed across Africa and Australia. The MeerKAT telescope, one of its precursors, is currently under construction in South Africa and uses fully open-source software and hardware for primary signal processing operations. When completed next year, it will be the world's most sensitive L-band array. This talk will discuss the telescopes and their unique challenges which drive the development of open-source hardware and software to process the deluge of data. I will introduce four generations of open-source FPGA hardware along with the collaboratively-developed ecosystem of software and DSP libraries.

Orienteering ice-breaker: learn the campus, end with a well-earned beer. Meeting in lobby of Menzies, by the Hetzner banner.

Let's face it, GNU/Linux is no youngster! Many developers are aging and as with any large group of people, we must plan for the sad but inevitable loss of contributors. We have already lost a number of extremely important people in our community. In this talk, Karen will discuss the legal and social implications of this transition and possible mechanisms we can put in place to address them.

In the past few decades, software has become a critical part of every single bit of infrastructure running the world, from the tiniest devices we embed in our bodies to improve our health, to the biggest human creations. Software is the key to accessing all the digital information we're constantly creating, and therefore is an essential part of our cultural heritage. But software is just a bunch of bits. Unlike antique stone carvings, software gets lost, deleted, or corrupted. Software Heritage has set out to build the biggest archive of free software ever conceived. Our mission is to collect, preserve, organise and facilitate the sharing of all the available free software. We are laying down foundations on which a wealth of applications can be built, ranging from cultural heritage, to research and industry. We started working in May 2015, and (as of April 2016) we have archived 2.2 billion unique files, more than 480 million project revisions across more than 16 million data sources, among which Debian source packages from snapshot.debian.org, public GitHub repositories, and the GNU project's FTP archive. This presentation will cover in more detail the why and the how of Software Heritage, as well as opportunities for the community to help us fulfill our goals.

An opportunity to meet the members of the Debian Technical Committee who are in attendance at Debconf, hear the status of open issues, and discuss pending and future issues with the committee. URLs: https://www.debian.org/devel/tech-ctte

Beyond being used at the Debian CI (ci.debian.net) and the Ubuntu autopkgtest website (autopkgtest.ubuntu.com), debci can be customized to a multitude of use cases, such as: running only a small subset of packages, This session is intended at helping interested people to bootstrap a development environment and start contributing with debci to increase the bus factor.

This is a BoF session to discuss the ppc64el architecture in Debian. These are the topics that might take be interesting for the participants: * Current Status * Major bugs and pitfalls of the platform * Missing packages * Machine availability (DSA) * Debian 9 Archive qualification * Desktop and laptop running Debian/ppc64el * Future: Power9** ** Power9 ISA was already released

This talk covers how web app packaging works for the free software [Sandstorm.io](https://sandstorm.io/) project. This talk covers how Sandstorm achieves one-click installs of web apps for unprivileged users. To do this, Sandstorm's packaging tools do a few strange things: - Every app package is a tiny Debian derivative, often as small as 20MB. - Apps have no Internet connectivity to the outside world. - Sandstorm uses a FUSE filesystem to identify which files are needed to run the app. - An app bundles all its needed services, as well as files, resulting in one MySQL service per app. - Users click and run one _instance_ of an app like Etherpad per document, which is all handled transparently via a web app, a strategy that has neutralized 95% of 0-day web app vulnerabilities, based on our analysis. - Developers on Mac OS and Windows can create packages for Sandstorm, even though Sandstorm is Linux-only, due to an emphasis on Linux VMs in our development tools. Somehow we manage to make this scale reasonably well. Additionally, it is popular with upstream authors: of the >50 web apps packaged for Sandstorm, about 1/3 are maintained by their upstreams. This talk focuses on how the Sandstorm packaging tools work, with community insights as well as technical ones, with the hopes of showing Debian how to more effectively package web apps for end users.

Do you want to learn how you can help make Stretch a success? How the next Debian releases will be named? What changes to the release processes we have implemented and what we are considering? Why your packages are being auto-removed from testing? Join us to learn about all that and more!

This talk will cover Debian on ARM devices, including NAS devices, development boards and other devices. The talk will briefly explain how the installer works on ARM from the point of view of a user. It will then cover in detail how Debian on ARM is different to Debian on x86 devices and what infrastructure we created in Debian to support a wide range of ARM devices, such as flash-kernel. Some supported platforms and devices will be covered as well.

What you can do for DSA and what DSA can do for you - Status Update 2016

Sandstorm is the Google Docs alternative that Tor and Debconf use, and you can learn about it at this BoF. It's implemented as a a web app package manager built so that end-users can use whatever software they want, with aggressive sandboxing. I'm on the development team and one of the admins of storm.debian.net and would love to discuss it with fellow Debian people. https://storm.debian.net/ is something any Debian community member is invited to use for their own personal use (and you can self-host it, too). You can use it for: - Personal documents (fully private to you), with Etherpad or Ethercalc or other tools - File sync, using Davros + ownCloud clients - CardDAV/CalDAV sync with Radicale I'd love to show how you can use storm.debian.net or self-host a Sandstorm install yourself, or listen to your feedback! storm.debian.net has a few admins, and if you want to talk about becoming an admin, we can talk about that, too.

Since the keyring-maint team started aggressively pushing for the retirement of short, obsoleted PGP keys two years ago, I started trying to get the keyring to "spew" some interesting data for us. Besides just showing the evolution on the number of keys conforming to our current best-practices, I started looking at the ugly entanglement of our keyring's graphical representation, and started hypothetizing what caused certain patterns to appear in its evolution. I am currently starting to do some aging and vitality analysis on the signatures and the keys themselves. The work I will be presenting is not likely to be a gamechanger for Debian, but it can be an entertaining way to understand social relationships in our project, and can lead us to understand some important turning points — maybe even forsee and prevent issues from arising at all.

Describing the adventures building a build network of armhf machines to run reproducibility tests, using a variety of readily available consumer-grade boards to increase possible reproducibility problems due to hardware differences. I will endeavor to explain how it grew from a few cute machines into a (still a bit slow) monster. Rumours will be spread of other monsters lurking on the horizon. Comes complete with Colored Charts, Documented Side Effects, Power Consumption and Bandwidth figures, and 5-12 volt tentacle (mis)management, and perhaps most importantly, advice on avoiding (or falling prone to) the same fate yourself.

LSB in stretch

In 2001, I uploaded the very first nbd-client and nbd-server packages into Debian. A few years later, I took over upstream maintenance. Much has changed in that time, both in Debian and in the wider open source community. Some of it had an impact on NBD, some of it did not. This talk will reflect on 15 years of NBD history, contrast it against Debian's history over the same time period, and see what we can learn from it.

This talk will provide an overview of the current status of Ultimate Debian Database, and some discussion about future plans.

Introduction to good GnuPG and keysigning practices. Re-verify the continuous keysigning hash, plus a brief introduction to what a Key-Signing Party is and how (and why!) is it being held "continuously" at DebConf16.

A presentation about a design for a next generation config management tool, and the specific problems this design solves. Three of the main design features of the tool include: * Parallel execution * Event driven mechanism * Distributed architecture This talk will demo a prototype I've built that implements these ideas. It is written in golang, and is completely free software. I will also cover the new functionality we've added to the tool such as the automatic edge and automatic grouping features and other fun stuff that happened between now and the conference. Mgmt's design goes out of its way to ensure that it always has feature parity on both Fedora and Debian simultaneously. An introductory blog post on the subject is available. https://ttboj.wordpress.com/2016/01/18/next-generation-configuration-mgmt/ Attendees are encouraged to read it before the talk if they are interested!

In this talk, I would like to share our success story running skroutz.gr, one of Greece's most-visited websites, using Debian with over 400 installations covering every tier, from core routers, to servers, development workstations and support desktops. The prospective audience for this talk are primarily system administrators, but its scope is broad enough to include bits on packaging, contributing etc. The key points include: - Maintaining a relationship with Debian: how, when and what to contribute, how to get your sysadmins involved. - Sysadmin-friendly packaging in the age of Puppet: playing nice with both sysadmins and configuration management tools. - Internal repository organization and package versioning; how to make sure your own packages play well with Debian's. - Leveraging Debian's own automation mechanisms in a highly automated environment; taming d-i preseeding and putting dpkg-divert to good use. - Applying security updates semi-automatically on a fleet of 300 servers. - Using Debian on the network: highly available routing and firewalling, using multiple upstream providers. - What we could do in Debian to further ease adoption by SMEs.

Discussion of the state of the ARM ports, and planning for the future. Let's have a get-together for the people working on the ARM ports in Debian, and anybody else interested. We'll discuss (among other topics) the current state of the ports, where things are going well and not so well, what hardware people are using and how to better support it, and which ports we want to continue supporting in the future.

The pkg-perl team will again take the opportunity to meet in person for discussing current topics and planning future work. Items for discussion and work are collected at [http://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks](http://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks)

20:30pm in the Super Cow Hack Lab, in the Fuller Hall Residence https://wiki.debconf.org/wiki/DebConf16/CheeseWineBoF

State of the project, ongoing activities and planned changes

Going on with the Debian policy - maintainership status, incorporating changes and fixes etc

Debian GNU/kFreeBSD is still under active development. I'll show some projects that have been ongoing since the last DebConf, and some new features being planned for stretch. Then I'd like to show what GNU/kFreeBSD's users are doing with it. I'll describe some use cases in more detail: using free software in place of proprietary appliances, which could apply to Debian and ZFS more generally. And we even have a downstream distribution now, so we'll see how that's been a useful collaboration already.

Similar to [last year](https://summit.debconf.org/debconf15/meeting/190/using-dbconfig-common/), I would like to discuss what is the way forward for [dbconfig-common](https://packages.debian.org/sid/dbconfig-common). Package maintainers that use or want to use or can't use dbconfig-common are especially invited to join the discussion. Share your success stories, difficulties or problems with respect to dbconfig-common. What are the wish lists (please file them already in the [bts](https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=dbconfig-common) if they aren't there yet)? I will briefly review the [fixes and improvements](https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/plain/debian/changelog) that I implemented in the year between Debconfs. Some ideas that I have: * way more databases support * inclusion in the Debian Policy that certain packages should use dbconfig-common * update/review the database policy included in the dbconfig-common package

Working session to kick-off fundraising for DebConf17 and possibly early advise for DebConf18 proposals.

With the stretch development cycle being well underway, we look at what has been happening over the last year since the jessie release with systemd as our default init system and what the Debian systemd maintainers team is and has been working on. We give an update on our plans regarding the stretch release and what is going on upstream.

DebConf16 tried wafer, a different Conference management system. What mistakes did we make in trying to support DebConf on wafer. Do we want to re-architect things? What are the next steps? This is not intended to be a discussion about whether we want to keep using wafer or something else. That's a [separate BoF](/talks/31/) for a broader audience.

Front Desk members, Debian Account Managers, Application Managers, current or prospective New Member applicants, Debian Maintainers and Contribors are all invited to ask questions, tell stories and exchange tips about everything related to handing out Debian hats.

There is a big community developing Debian derivative distributions. This talk aims to discuss about what derivative distributions use for their day to day operation, such building packages, images, live media, managing distribution repositories, trying to seek better unification and standardisation of such tools and processes. In the same way, we shall explore and discuss the return path to the upstream distribution.

New MariaDB major release is out of the door. It has new unique features, performance enhancements, as well as better MySQL compatibility. This talk will go over everything new that MariaDB 10.2 has to offer. It will describe all new features, both MySQL compatible, and MariaDB-only ones and show usage examples and practical use cases.

In this structured session, task-seekers will describe what they like doing, meet currently-active contributors, and find fun, productive things to do as part of the Debian project. If you're excited about contributing to Debian, or if you already are contributing but need help with something, this is the session for you. ### Event structure In detail: - All participants will sit down in a round-table BoF setting. - Mentees will introduce themselves, including answering a brief questionnaire. - The moderator (Asheesh) will summarize the mentee remarks. - Mentors will then find mentees who they can offer tasks to. These tasks should be short enough that they can be productively reviewed/merged/uploaded by the end of Debconf. If you want newcomers to help your Debian subproject, then this is a great event for you! The event will be a success if mentors and mentees work together, outside the session, over the course of the conference. Terminology: - "Mentee" means someone who is looking for something new to do within the Project. - "Mentor" means someone who can offer help, or can offer a task as well as review of the mentee's success at the task, to help them learn. ### Questionnaire 1. What's one thing you know about the Debian Project? 2. What's one thing you like about Debian? 3. What's one thing you want to learn more about? Not necessarily an element of Debian, just something in your life that you want to learn more about.

Show off your project! NB: It will be mandatory to set up your laptop before the session, in order to assure a smooth transition between speakers.

Kali Linux is a Debian derivative since 2012, it is maintained by Offensive Security and dedicated to penetration testing. Initially it was based on Debian Stable (Wheezy then Jessie) but since late 2015, it now tracks Debian Testing with its daily changes. There are upsides and downsides to this and I'll try to present those as well as the infrastructure that we have setup to run Kali Linux (repositories, build daemons, jenkins checks, etc.). This talk is interesting for other Debian derivatives that want to learn from Kali's experience, but it's also interesting for the Debian community to learn of the problems that derivatives are facing when they try to track Debian Testing.

DebConf16 tried wafer, a different Conference management system. Did it work out OK for us? Do we keep going down this road? What big issues would we want to address in it? See also: The [wafer upstream development BoF](/talks/30/)

Another year has passed and HP's (now HPE) Debian derivative is another year older. In this presentation I will be talking about how HPE has been doubling down on Debian and the effects this has had on how open source software is being managed within the company. HPE Linux has consolidated many functions previously distributed (and duplicated!) within HPE, and is now acting as a middleman or proxy between many internal and external parties. The idea of the distro as a middleman will be explored and how this can be used to promote or propose using Debian in other organisations.

any Python related topics

In this talk I'll explain how socket authentication in MariaDB works and how it makes the life of system administrators easier when they can do all maintenance as root, without the need of additional passwords. Life without extra passwords is also more secure, as there is less to leak or loose. Socket authentication in MariaDB is by default enabled in Debian.

All things about Debian s390x port

In the current development version (will become 3.1) of FOSSology (www.fossology.org), we're now able to generate DEP5 directly for packages. This gives us a useful tool for validating the manually generated DEP5 files. Would like to discuss with others interested in release, packaging, and legal issues what would be needed to improve the accuracy of the licensing information carried with the packages currently in Debian. How updates should be reported, etc. Basically looking to figure out what actually makes sense to do, and how this new capability can be used to help.

Ubuntu 16.04 LTS has shipped with a new port - s390x, which has existed for a while on Debian. This talk will briefly cover how the port was bootstrapped and what changes were done in the infrastructure to accommodate unusual particularities of IBM z Systems. Ideally this talk will also be followed by an s390x port BoF.

The annual DebConf gathering of the Ruby team, to discuss open issues and plans for the future.

BoF session for people interested in MariaDB/MySQL in Debian. Discussion according to what the attendees want to talk about. Hosted by members from the pkg-mysql-maint team.

The role of the DPL is one which isn't understood fully by anyone who hasn't done the job. There's generally accepted knowledge that it a) takes a lot of time and b) you need to talk to people, but the extent of this is very variable. In this talk, I'll go through my year as the DPL, looking at which issues were dealt with and what was actually involved. It'll call in to question what role is expected of the DPL, and if one person can actually perform this task.

android-tools is a young packaging team which focuses on bringing a usable Android SDK/NDK to Debian. This talk describes the rationale, people involved and current status of our packages. We also would like to call for more people join us. Android one of the most popular mobile operating systems in the world, which also makes the SDK vital to us. However not every developer in the world can easily download Android's SDK. In some corner of the world, people prefer to rely on third party mirror or even developer-provided binaries on some web drives. XcodeGhost on iOS side was caused by similar reasons. Additionally, official released Android SDK binaries are proprietary software. By building the SDK from source and deploy it to all Debian mirrors spread over the world, all developers can easily get it and are safe to use it. The packaging force of Android SDK started as student projects of Google Summer of Code 2015 and 2016.

In this BOF, I'd like to bring together the people that use fpc and/or lazarus. Both the direct users as well as package maintainer that build their packages using Free Pascal. This BOF has at least the following objectives: * meet people interested in fpc and the packages build with it. * discuss general/global issues and improvement strategies (such as the static library situation). * discuss bootstrapping of fpc on new architectures (mips/mipsel/ppc64el)

The project used to have Release Goals which, to some extent, defined global goals for the project. Such goals were proposed at the beginning of a release cycle and decided by the Release Team. The RT later stated [1] that "whilst release goals have been useful in the past to introduce archive-wide changes, [RT] should review whether this remains the case and whether the release team is really the right place to determine them." [1] https://lists.debian.org/debian-devel-announce/2013/11/msg00007.html Still, Debian members need to produce a list of common goals and projects. Those goals should not necessarily bound to a release. The roadmap will greatly help us to promote our vision and priorities.

Containers and related technologies have emerged (or re-emerged depending on your point of view) as both a complement and substitute to virtualisation. The Debian Go Packaging Team has been hard at work packaging the latest releases of Docker, Kubernetes and Rocket to ensure that the Debian community can use DFSG-compliant versions of. This talk will discuss that challenges of packaging software in the Go language and show how containerisation actually plays to Debian's strengths as a stable, free and unencumbered operating system.

AppRecommender is a package recommender system for Debian systems (and derivatives). Currently, AppRecommender only uses content-based recommendation strategies. One idea is for the application to also support collaborative recommendations, which would recommend packages based on users with similar package profiles. However, in order to do that, Popularity-contest data would be required. Therefore, this talk will discuss how this data can be used and also raise some security and privacy concerns about using them. AppRecommender went through NEW during Debconf and is already available in unstable.

When it comes to voice and video over IP, most people nowadays are quick to use Skype, Whatsapp, or Viber. These systems come with a big community of people though this Software is only free as free as in beer. Protocols and proprietary, privacy is basically non existent. There are though several free alternatives like Jitsi, Linphone, Ekiga, Tox (qtox) and Mumble. However, the communities are often small and due to a lack of servers firewall traversal can be very cumbersome. Even if all these techniques are also available as open source software (ice turn server, siproxy, jitsi conference bridge, asterisk, freesip), bootstrapping any business relevant network based on these free alternatives is still hard. Automatic dependency resolution does actually help in debian, however integration and configuration could be greatly simplified. This project will evaluate options to achieve this simplification and integrate necessary changes and documentation into the respective debian packages.

Status of building Debian images for Microsoft's Azure cloud

Installing scientific software can be hard. The last two years i've been working on methods to simplify the installation procedure by creating and publicly publishing debian packages of the most used radio astronomy software. These packages are now used in various institutes around the world. Still there are many problems to be solved, for example how to distribute updates of software without breaking existing pipelines or how to publish various (conflicting) versions of the same software and/or library. Kern is attempt to address some of these issues by introducing a bi-annual release cycle independent of Debian/Ubuntu. Kern now consists of 25 packages, down from 35 since some of them are in in Debian. http://kernsuite.info The Square Kilometre Array (SKA) is a large multi radio telescope project aimed to be built in Australia and South Africa. If built, it would have a total collecting area of approximately one square kilometre. It would operate over a wide range of frequencies and its size would make it 50 times more sensitive than any other radio instrument. It would require very high performance central computing engines and long-haul links with a capacity greater than the current global Internet traffic. It should be able to survey the sky more than ten thousand times faster than ever before. My bio: Gijs Molenaar is a scientific software engineer living and working in both Amsterdam and Cape Town

From the package description: autopkgtest runs tests on binary packages. The tests are run on the package as installed on a testbed system (which may be found via a virtualisation or containment system). The tests are expected to be supplied in the corresponding Debian source package. See adt-run(1) and /usr/share/doc/autopkgtest. Depending on which virtualization server you want to use, you need to install additional packages (schroot, lxc, lxd, or qemu-system) autopkgtest is what Debian CI (ci.debian.net) runs, so adding autopkgtest tests to your package will _automatically_ make those tests run on Debian CI as soon as the package hits the archive. The idea for this session it to get together and write/review autopkgtest test suites as well as discuss any related aspects. If you have ideas on how to test your package but don't know exactly how to wire things up for running with autopkgtest, let's look at that together.

At my invited talk at DebConf15, I announced Software Freedom Conservancy's Debian Services agreement with the Debian project. Under the agreement, Conservancy provides some essential services to the Debian project. Most notably, Conservancy accepts copyright assignments and enforcement agreements from Debian contributors, and enforces those copyrights when copyleft licenses are violated. Additionally, Conservancy provides its expertise on licensing issues, project governance, and the like, in an advisory role to the Debian project. This talk will cover what Conservancy accomplished for Debian under this services agreement, how the agreement is working so far, and what how Conservancy and Debian can work together in the coming year to make even better use of the services provided under the agreement. Ideally, attendees will come to suggest ideas for what they'd like to see, and after a short presentation, the remaining time will be used for Q&A and discussion.

The Linux kernel is under rapid development. Stable releases are made around 5 times per year, each including many new features and support for new hardware. This talk will summarise the features that have been added and enabled in the last year. There have been many changes to Linux between 4.1 and 4.6. Some of these will require new or updated userland applications to take advantage of them. I will attempt to summarise the most interesting changes and the state of integration in Debian.

The goal of this BOF is to brainstorm about Debian: What are the big challenges for our future? What should we focus on? What should Debian be in 10 years? People allergic to SWOT analysis are welcomed, but should ensure they took proper medication as there's a high risk of being exposed. (see https://en.wikipedia.org/wiki/SWOT_analysis )

LTTng is an open source kernel and userspace tracing framework for Linux. This talk will introduce developers and system administrators alike to the toolkit and show how it can help them get visibility into development and production systems. The following themes will be covered: - A description of the different tools involved - LTTng compared to other tracing tools like *perf* and *strace* - The state of LTTng in Debian - Basic use cases and workflows - Analysis of kernel traces You should leave this talk with an uncontrollable desire to use LTTng. **URLs**: https://lttng.org

Come and give dracut a try. Dracut will become the replacement of initramfsptools in the future. But it needs more people that give it a try. If you are a maintainer of a package that includes a hook for initramfs-tools, I may also help you to convert the hook for dracut. Thomas is the package maintainer of dracut.

Discussion of the this year's bursaries allocation process, in particular what worked well, and what can be improved for next year. Both team members and "customers" are welcome.

They're talks. They go like lightning.

How to use LAVA to provide test support on real hardware which can be remote or local to the user. * [lava.debian.net](https://lava.debian.net) * publish local tests from your desk to support testing packages like u-boot. * install lava-dispatcher on a machine on your LAN and publish local tests for everyone to view and analyse * run CI on the Linux kernel packages on hardware - ramdisk, NFS and SATA media * test DI on real hardware (typically ARM). * publish local tests of VM images, including live images, and potentially run tests on VM images where appropriate hardware is available. * run server-client tests on relevant hardware which cannot be easily performed in sbuild or single VM instances. * support for VLAN testing is available although unlikely to be via lava.debian.net itself. * support for Debian SSO for account creation. * XMLRPC and REST API interfaces.

https://wiki.debian.org/GCC6

WebRTC, also known as RTCWeb, puts two-way media streaming capabilities into the web browser and provides an API to manage them (starting and stopping calls) from the JavaScript embedded in any web page. The technology has been pioneered in the two major browsers, Mozilla Firefox and Google Chrome. Other browsers have been following their lead. There was some instability in the early years of WebRTC but since mid-2014 the technology has stabilised significantly. There have been some pseudo-WebRTC solutions as well, specifically, browser plugins that offer behavior similar to WebRTC with an emphasis on a specific provider. These solutions are not true WebRTC and they are largely becoming irrelevant now that most users have upgraded to browsers with genuine WebRTC support built in. WebRTC provides a mechanism for peer-to-peer media streaming (audio or video) but it does not specify the use of any particular signalling system, the mechanism responsible for locating other users and routing calls to them. The talk is going to include how to develop FreeRTC plugins for third party applications. Code snippets will be shared. Now it is possible to talk to each other from different cms systems.

We've had a lot of discussion recently about plans for producing official Debian images supporting various cloud services. Let's have some face-to-face session to cover: * what images we should be producing * tools to make those images * testing those images * when/where/who/how ...?

deb.debian.org is the Debian archive, fronted by a CDN instead of using the traditional mirror network. In this talk I will go into some of the new challenges this presents, current status and future plans. It will also touch on our traditional mirror structure and some of the challenges surrounding this.

With the approaching Stretch freeze, this BOF will be an opportunity to discuss the state of our QA testing tools and infrastructure, and plans for large scale QA efforts before the next release.

Since last year, Debian supports the AppStream specification for providing machine readable metadata for any software component available in the Linux distribution. At time, the data is primarily used by GNOME Software and KDE Discover to display an user-friendly catalogue of installable applications. But this is not all we can do with the new metadata: It can be used to automatically detect and install missing firmware and drivers, match applications between distributions and allow upstream projects to track them across different distribution releases and other interesting tasks like automatically checking installed applications for vulnerabilities or installing missing libraries and Python modules automatically in a distro-agnostic way. The talk will explain what AppStream is today and how it is implemented in Debian, as well as giving some statistics on the availability and evolution of metadata. It will also go into detail on usecases for the metadata, challenges in writing it and future plans, like support for fonts and more automatization in data generation.

FOSS software is undoubtedly the best option for developing nations, where financial resources may limit access to proprietary software. At the same time, using Debian/Linux also has its share of challenges in these settings, as there may be infrastructure issues to contend with. This talk shares the joys I have personally experienced while using Debian in Swaziland, as well as the challenges that I have faced, and also seen others face too. Perhaps the audience may be able to suggest ways to overcome some of the issues involved, and thus get more exposure and adoption for Debian in developing countries.

How do you use git-buildpackage? What could be improved?

With free software, anyone can inspect the source code for malicious flaws. But Debian provide binary packages to its users. The idea of “deterministic” or “reproducible” builds is to empower anyone to verify that no flaws have been introduced during the build process by reproducing byte-for-byte identical binary packages from a given source. This talk will explain the current status of the Debian Reproducible Builds project, how this is relevant for the complete free software eco system and how you can contribute.

Come and discuss with other Debian users how you are, or would like to, use virtualisation and containerisation in Debian.

Apt is used by a lot of people every day to update their systems, install software, and remove software on Debian, Ubuntu, and other derivatives. Some people actually forked an old apt and run it on some kind of fruit phones. The APT library is also used by aptitude, a formidable ncurses frontend. This talk discusses three major topics of APT development in the past year: Firstly, security improvements such as acquire method sandboxing and the deprecation of SHA1 support. Secondly, performance improvements: Between 1.1 and 1.2 there were many commits improving performance, both for the update command and building the cache itself (hello, phones!). Thirdly, we will take a look at the new pinning engine introduced in 1.1 at last year's DebConf, how it is different from the older engine, and why it is much better and actually does what you mean instead of nonsense.

We will look at the packaging techniques that each of the participating teams use and try to find overlap and where those could possibly converge (i.e. maybe share scripts). This is explicitly not about making a grand unified plan that will never be implemented. People joining please have examples of your workflow ready to give a short demo/example. Everybody using git to manage packages is welcome :-)

The AppArmor team meets in the pub and plans world domination. When: from 7pm to 8pm. Where: UCT Pub

Existing tools for network interface configuration have several shortcomings when applied to network switches. These include the lack of ability to handle interface dependencies, incremental updates to interface configuration without disruption, and interface configuration validation. The lack of such functionality increases operational burden. We introduced ifupdown2, a new network interface manager for Linux. ifupdown2 solves these problems through an implementation based on dependency graphs. The purpose of this talk is to briefly describes network interface configuration on Linux, the problems that arise when configuring a network switch and how ifupdown2 solves these problems and increases operational efficiencies overall. This talk mostly targets networking people. We also want to encourage people to contribute to this project by writing their own addon module to support new protocols (e.g. B.A.T.M.A.N.) : https://github.com/CumulusNetworks/ifupdown2 https://packages.debian.org/sid/ifupdown2 Via this talk we also want to give a general up-date on the project. What we added over the year (e.g. VRF, etc.) and what is coming (e.g. better netlink support, better performance..etc.)

There is no Free Software project in the world with Debian's commitment to representative governance. Debian has a Constitution, recall and referendum ballot initiatives, and accountable, elected bodies. However, any representative system, no matter how well structured, has its gaps that can be exploited politically. In this talk, I will first confess how I once used such a gap in the licensing approval process as part of package uploads to successfully reach political aims outside of Debian. I will explain how and why I did it, and why it was possible. While at the time, I was glad the system could be slightly "gamed", in hindsight, I'd like to draw the Debian's community attention this gap open for political opportunists and discuss changes in the political structure to prevent similar political exploitation in future. Ultimately, Debian ftp-masters fully control, absent a specific General Resolution, interpretation of the DFSG. While, technically speaking, no specific package upload refusal nor approval sets any overarching Debian policy on a particular license, the ftp-masters' decisions do become a de-facto precedence-based system, much like a common-law Court system, since overturning such decisions would typically require a General Resolution in practice. This talk will explore the socio-political ramifications of the current system of licensing decision-making in Debian, pontificate on ways it can be improved (and why it should be), and seek audience participation on whether the analysis presented is accurate and/or if the outcome of that analysis warrants changes in the existing system.

It's based on my recent work to support GNU/screen for Debian Installer. For d-i on normal PC, we can simply press Alt-F2 to get a console almost anytime during install, but it's not easy for some device such as headless server or ARM based board, which usually accessed via serial console or network-console (SSH). So I spent some time to make GNU/screen ported to Debian Installer [0]. Now it's almost done, and only wait for 2 packages to be uploaded [1][2] I also made a few local build for a few devices, and asked users to test, the feedback is quite positive [3]. I'll introduce this work during the short talk and ask for feedback. And if possible, I can also do some demo after the talk. Thank you! [0] https://lists.debian.org/debian-boot/2016/04/msg00308.html [1] https://bugs.debian.org/819397 [2] https://bugs.debian.org/819988 [3] https://lists.debian.org/debian-boot/2016/05/msg00121.html

This talk describes a recently started research project named [http://colis.irif.univ-paris-diderot.fr/ Colis] with the goal of developing techniques and tools for the formal verification of maintainer scripts (preinst, postinst, prerm, postrm). *Program verification* aims at obtaining a formal assurance that a program is correct with respect to a given specification. This is achieved by constructing a formal proof of correctness of the program. In contrast to *program testing*, the existence of a proof assures that the program behaves correctly in *any* situation described by the specification. Failure of an attempt to verify a program, on the other hand, can often be used to generate useful test cases. A possible example of a program specification is absence of execution error under certain initial conditions. Automatic program verification even for this kind of specification is an extremely challenging task. In case of Debian maintainer scripts we are faced with even more challenging properties like idempotency of scripts (required by policy), or commutation of scripts. The project is still in the beginning, so there are no results yet to present. However, I will explain why I think that the case of Debian maintainer scripts is very interesting for program verification : some aspects of scripts (POSIX shell, manipulation of a complex data structure) make the problem very difficult, while other aspects of the Debian case are likely to make the problem easier. I am also very interested in the inputs from the audience about possible use cases of script verification in the context of Debian.

July 2014 was the first month where Freexian used the money collected from many sponsors to pay Debian contributors to provide security updates for Debian 6. The Debian LTS project is now 2 years old: this talk is a restrospective of how we got started, a presentation of how we work today and of our plans for the future. This talk will also serve as an introduction to a BoF discussing the usage of (Debian) money to fund Debian projects. The Debian LTS project, despite its public reliance on sponsorship, and the fact that it is paying Debian contributors, has been well accepted in the Debian community. The talk will thus cover extensively the precautions taken when it comes to the handling of the money.

Software in the Public Interest is the legal and financial umbrella organization providing services to Debian in the United States. This session will provide an opportunity to meet the members of the SPI board attending Debconf, hear a brief update on the organization's activities in the last year, and get your questions answered.

I will talk about software bundling solutions, mainly Flatpak (XdgApp) and Limba, which problems they actually solve and why solving these issues is important for the Linux ecosystem as a whole. I will explain how bundling is implemented in the shiny new solutions available on Linux, and what we as distributor could do to make software bundles suck less and keep the distribution relevant. Additionally, I'll explain which roles sandboxing (Flatpak, Bubblewrap) plays in the big picture.

This event is a self-driven packaging tutorial. Attendees of all backgrounds are welcome. You will work through Lucas Nussbaum's well-tested documentation and learn about: - How to compile a Debian source package into a Debian binary package - How to create new packages for Debian and more. We're hopeful that new contributors to Debian will attend, as well as experienced contributors willing to answer questions. Format: 2 hour Workshop

This talk will be an introduction to Ring and the technology behind it. We will explore how OpenDHT and ICE are used to initiate communications and transmit messages in an decentralized and secure manner. The talk also includes a presentation of the different Ring clients, notably the new `ring` package that has made it to Debian testing this week. Finally, we will have a look at an up and comming new Ring freature: username registration using ethereum and a block chain.

With Debian LTS, we are now offering something that users expected for a long time and we are keeping users that we lost to Ubuntu in the past. Debian LTS would not exist without the work of paid contributors and the financial support of its sponsors. Can we learn what we got right in Debian LTS and try to see how we could use money to improve other parts of Debian? In this BoF, we will make some propositions and expect the audience to react to them, highlighting what is good and what is problematic, making suggestions on how to fix/improve the propositions. The Debian Project Leader is a central role in the way Debian spends his money. He will thus take an active role in this discussion.

Three years after a "Plan of action" for Secure Boot support, we've had another release without it and there are still many changes required. What is left to do and how will we finish it in time for "stretch"?

Debian and the Free Software Foundation, along with its GNU Project, share many goals and ideals. They are two of the most mature and dedicated organizations working in the free software movement. This is a great opportunity to talk in person about how they can better work together and learn from each other. FSF members (and potential members) will meet to talk about the FSF's work, and relationship with Debian: * A very brief update by the FSF's executive director on highlights of the FSF's work since the last DebConf * Feedback (positive and negative) from members, and a little brainstorming about what the FSF should and shouldn't be doing * A review of the current relationship between the FSF and Debian * A discussion of areas for collaboration, focused on projects that could be completed or significantly advanced before the next DebConf Past sessions at DebConf have led to concrete positive results like collaboration on the hardware database at . Let's have another productive one!

... or how to stop worrying and have fun hacking on d-i without needing to be scared about breaking everything The objective here is to let people push to feature branches and find out later how much damage they would have done had they put that into d-i. The hope being that the answer will often be "None" This should encourage people to do more work on d-i. The talk will also serve to demonstrate the use of Cucumber and Jenkins that we have for running the tests.

Show off your project! NB: It will be mandatory to set up your laptop before the session, in order to assure a smooth transition between speakers.

*Secure Boot* is a UEFI feature that prevents unsigned boot code from being loaded. Assuming the bootloader checks the signature on the kernel, and the kernel checks the signature on code it itself loads, this chain of trust can be extended quite far into the running system. Unfortunately, the only signing key that is trusted by most implementations is held by Microsoft. There are 2 major reasons for supporting Secure Boot in Debian: - some computers now ship with Secure Boot enabled by default, making it harder to install Debian; - while not perfect, it is a technology that can be used to make Debian user safer. The plan the Ben (bwh) has been hatching is as follows: - a minimalistic shim bootloader is signed by Microsoft; - the shim load a bootloader that was properly signed by Debian (in the long run, ftpmaster@; right now, it's bwh's signing key); - the bootloader loads a kernel signed by Debian; - the kernel only accepts to load code signed by Debian (`securelevel = 1`). The signing process itself uses signature packages, so as not to keep signing keys on the buildds or break reproducibility. Advantages: - no dependency on Microsoft, once the shim is signed (and it should need fixes very seldom); - robust process that can take advantage of reproducible builds; - gives reasonable guarantees that the running kernel is a legitimate one; - trusting only Debian (as opposed to anything Microsoft signs) can easily be achieved by shipping a Debian-signed shim and having the user put the Debian key as the only trusted one. Caveats: - doesn't protect the userspace (yet!); - still vulnerable to somebody with a kernel exploit (but this doesn't grant persistence) or who can get a bootloader signed by Microsoft. Help us, fellow Debian hackers! You are our only hope.

I recently adopted pristine-tar, because it has been orphaned for a while and it is a critical piece of infrastructure for several teams and individuals. I am not completely familiar with its internals yet, and would love to get more people onboard, among other reasons, to not have me being a single point of failure.

The annual Long Term Support BoF. This would allow current members, newcomers and interested people work and talk about LTS matters.

Overview of DebConf17 in Montreal.

Interested in having DebConf18 in your city? Come and show us your early plans! See: https://wiki.debconf.org/wiki/DebConf18/

Let's collect ideas and implementation methods for the future development of the Wine packaging (src:wine and src:wine-development) in Debian. Ubuntu is planning to use our packages. Which feature requests do they have and are they in line with Debian's plans? How can we help to keep the delta minimal without screwing up the Debian packaging? We will have a special look at current existing issues. gobby.debian.org/debconf16/bof/wine

In this talk, we will review what happened in the OpenStack world over the last year: new projects that appeared in Debian (Congress, Aodh, Gnocchi, Magnum, Mistral, Senlin and Zaqar), and improvements in the existing projects (walk through important bits of the release notes), and how Debian became the base for the packaging of commercial products: Mirantis OpenStack is now fully based on the Debian packaging of OpenStack, and puppet-openstack is now fully compatible with Debian. Then, in a 2nd part of this talk, we'll cover a broader topic: we'll see how a CI/CD and automation for writing packages (and more specifically Python modules) could help Debian developers at large, using either Jenkins, or Gerrit, Nodepool and Zuul, running an OpenStack deployment to build packages. We'll see how Mirantis implemented its CI (and what it can do), and how this is currently done in upstream OpenStack CI/CD infrastructure, and how we could deploy it for Debian, inside our own infrastructure.

"Open source" split from "free software" to be more pragmatic, to gain entry to the business world, partly by being more accepting of proprietary software. This led to descriptions of free software as "vegan" and open source as "vegetarian." Let's question this analogy, and in the process explore how the Tofurky is made, looking at underlying motivations, ethics, communication, and collaboration. In Debian, we don't just want to write and package free software or open source code. We want others to understand *why* we do it. We want to get along with each other. We want other people to join us in envisioning a world where our kind of collaborative production is the norm. At the very least, we want them to think we're not crazy. The challenges for those committed to our cause can be similar to those choosing to be vegetarians or vegans -- having to explain why we won't eat what seems to others to be perfectly good software/food, why we can only frequent certain restaurants/websites, why we refuse to serve meat/proprietary software to others. We can be similarly accused of being judgmental, impractical, idealistic, or "in a phase." Because many more people are familiar with the concept of dietary restrictions motivated by concern for animal rights, environmental ethics, sustainability, and health, this can be fertile ground for analogies to explain our choices in software and technology. As we chew the fat, we'll learn more about the diverse motivations within our movement, leading to both better collaborative potential among current practitioners and improved recipes for communicating about what we do to brand new audiences.

Debian now has gcc and binutils packages for cross-building with a variety of build and host architectures. They still don't do everything that some cross-toolchain users want. Let's discuss how to fill the gaps.

- Quick review of DebConf16 organization. The goal is to be able to quickly identify what went good/bad, what was a good/bad idea... and how this could help DebConf17 team. - How to help DebConf17 team to get started? - What are the first steps? - Who's interested to help?

In this talk i will give a short overview about DUCK. I will introduce/present the website as well as the tool, talk about how/why i started working on it, show some graphs and ask for suggestions on how to make the topic "broken URLs" more public. Audience is: QA in Debian

Bdale and Keith have been working on the design of an inexpensive yet robust, completely open design, hardware random number generator. At Debconf in Portland two years ago, Tom Marble gave a talk about the earliest prototypes and then state of the project. Happily, we now have a design we consider worthy of taking to production. This talk will describe the hardware design, kernel device driver, and current production status of Chaoskey.

How do people trust a service that you run? They could blindly trust that you are both honest and competent, but they shouldn't have to and you might not want to be trusted [0]. This BoF is meant for people providing (or using?) services over the network, to third-parties, and want to do so as transparently as possible. - Step 0 is simply running free software: how could one trust the service without even knowing what it does? Yet, the software itself is not enough: whether it performs as intended (in the scope of the service) and securely depends on its configuration. - The next step should be to document the setup, and publish the documentation. Unfortunately, documentation will get out of sync with the configuration, as it is wont to do. - Then, it seems intuitive to publish the configuration (as in, the entire `/etc` directory), likely kept in version control. The solution I have used so far is simply keeping `/etc` versionned in `git`, using `etckeeper`, and automatically pushing the modifications to a public repository. This approach also brings some unexpected benefits: - It make it very easy to (re)build the same infrastructure, even if it involves several systems. This is a boon, both for automated testing and for users who decide they wish to self-host the same setup. - Users can actually contribute back configuration changes, as patches/pull requests. They are not passive consumers anymore. - It is extremely convenient to use this mechanism to manage the configuration of several servers running the same service (with the same config). Some challenges I have been facing: - How to handle secrets? (cryptographic keys, credentials, ...) - How to handle automatic upgrades? (In the multi-server case) - How to prove to the user that the configuration that is published is was is actually being run? [0] By some weird cultural quirk, “trusted” is usually seen as a positive adjective. Yet, “X is trusted” means “X can break your security if compromised”: the less trust there is in a system, the more resilient it is.

Debsources (http://sources.debian.net) is an application aimed at gathering all the source code included in Debian packages, and present it through a web interface. This talk will be about its new mobile interface, and related features.

Good-bye to Cape Town!