Search Results: "intrigeri"

10 September 2017

Thanks to a Mozilla Open Source Software award, we have been working
on making the Tails ISO images
build reproducibly.
We have made huge progress: since a few months, ISO images built by
Tails core developers and our CI system have always been identical.
But we're not done yet and we need your help!
Our first call for testing build reproducibility in August uncovered
a number of remaining issues. We think that we have fixed them all
since, and we now want to find out what other problems may prevent you
from building our ISO image reproducibly.
Please try to build an ISO image today, and tell us whether it
matches ours!
Build an ISO
These instructions have been tested on Debian Stretch and testing/sid.
If you're using another distribution, you may need to adjust them.
If you get stuck at some point in the process, see our more detailed
build documentation
and don't hesitate to contact us:

Send us feedback!
No matter how your build attempt turned out we are interested in your
feedback.
Gather system information
To gather the information we need about your system, run the following
commands in the terminal where you've run rake build:

If the checksums match: success, congrats for reproducing Tails
3.2~alpha2! Please send an email to tails-dev@boum.org (public) or
tails@boum.org (private) with the subject "Reproduction of Tails
3.2~alpha2 successful" and system-info.txt.bz2 attached. Thanks in
advance! Then you can stop reading here.
Else, if the checksums differ: too bad, but really it's good news as
the whole point of the exercise is precisely to identify such
problems :) Now you are in a great position to help improve the
reproducibility of Tails ISO images by following these instructions:

Install diffoscope version 83 or higher and all the packages it
recommends. For example, if you're using Debian Stretch:

the smallest file among diffoscope.txt.bz2 and
diffoscope.html.bz2, except if they are larger than 100 KiB, in
which case better upload the file somewhere (e.g.
share.riseup.net and share the link
in your email.

Thanks a lot!
Credits
Thanks to Ulrike & anonym who authored a draft on which this blog post
is based.

15 May 2017

During the Contribute your skills to Debian
event that took place in Paris last week-end, we conducted a usability
testing session. Six people were tasked with testing a few aspects of
the GNOME 3.22 desktop environment and of
the Debian 9 (Stretch) operating system.
A number of other people observed them and took notes. Then, two
observers and three testers analyzed the results, that we are hereby
presenting: we created a heat map visualization, summed up the
challenges met during the tests, and wrote this blog post together.
We will point the relevant upstream projects to our results.
A couple of other people also did some usability testing but went in much more depth: their feedback is much more detailed and comes with a number of improvement ideas. I will process and publish their results as soon as possible.
Missions
Testers were provided a laptop running GNOME on a a Debian 9 (Stretch)
Live system. A quick introduction (mostly copied from the one we found
in some GNOME usability testing reports) was read. Then they were
asked to complete the following tasks.
A. Nautilus
Mission A.1 Download and rename file in Nautilus

Download a file from the web, a PDF document for example.

Open the folder in which the file has been downloaded.

Rename the dowloaded file to SUCCESS.pdf.

Toggle the browser window to full screen.

Open the file SUCCESS.pdf.

Go back to the File manager.

Close the file SUCCESS.pdf.

Mission A.2 Manipulate folders in Nautilus

Create a new folder named cats in your user directory.

Create a new folder named to do in your user directory.

Move the cats folder to the to do folder.

Delete the cats folder.

Mission A.3 Create a bookmark in Nautilus

Create a folder named unicorns in your personal directory.

This folder is important. Add a bookmark for unicorns in order to
find it again in a few weeks.

Mission A.4 Nautilus display settings
Folders and files are usually listed as icons, but they can also be
displayed differently.

Configure the File manager to make it show items as a list, with
one file per line.

You forgot your glasses and the font size is too small for you to
see the text: increase the size of the text.

B. Package management
Introduction
On Debian, each application is available as a "package" which contains
every file needed for the software to work.
Unlike in other operating systems, it is rarely necessary and almost
never a good idea, to download and install software from the authors
website. We can rather install it from an online library managed by
Debian (like an appstore). This alternative offers several advantages,
such as being able to update all the software installed in one
single action.
Specific tools are available to install and update Debian packages.
Mission B.1 Install and remove packages

Install the vlc package.

Start VLC.

Remove the vlc package.

Mission B.2 Search and install a package

Find a piece of software which can download files with BitTorrent
in a graphical interface.

Install the corresponding package.

Launch that BitTorrent software.

Mission B.3 Upgrade the system
Make sure the whole system (meaning all installed packages) is up to date.
C. Settings
Mission C.1 Change the desktop background

Download an image you like from the web.

Set the downloaded image as the desktop wallpaper.

Mission C.2 Tweak temporary files management
Configure the system so that temporary files older than three days are
deleted automatically.
Mission C.3 Change the default video player

Install VLC (ask for help if you could not do it during the previous mission).

Make VLC the default video player.

Download a video file from the web.

Open the downloaded video, then check if it opens with VLC.

Mission C.4 Add and remove world clocks
When you click the time and date in the top bar, a menu pops-up.
There, you can display clocks in several time-zones.

Add a clock with Rio de Janeiro timezone, then another
showing the current time in Boston.

Check that the time and date menu now displays these two
additional clocks.

Remove the Boston clock.

Results and analysis
Heat map
We used Jim Hall's
heat map
technique to summarize our usability test results. As Renata
puts it,
it is "a great way to see how the users performed on each task.
The heat map clarifies how easy or difficult it was for the
participant to accomplish a certain task.

Scenario tasks (from the usability test) are arranged in rows.

Test participants (for each tester) are arranged in columns.

The colored blocks represent each tester s difficulty with each scenario task.

Green blocks represent the ability of the participant to accomplish the tasks with little or no difficulty.
Yellow blocks indicate the tasks that the tester had significant difficulties accomplishing.
Red blocks indicate that testers experienced extreme difficulty or where testers completed the tasks incorrectly.
Black blocks indicate tasks the tester was unable to complete."
Alternatively, here is the spreadsheet that was
used to create this picture, with added text to avoid relying on
colors only.
Most tasks were accomplished with little or no difficulty so we will
now focus on the problematic parts.
What were the challenges?
The heat map shows several "hot" rows, that we will now be looking at
in more details.
Mission A.3 Create a bookmark in Nautilus
Most testers right-clicked the folder first, and eventually found they
could simply drag'n'drop to the bookmarks location in the sidebar.
One tester thought that he could select a folder, click the hamburger
icon, and from there use the "Bookmark this folder" menu item.
However, this menu action only works on the folder one has entered,
not on the selected one.
Mission B.1 Install and remove a package
Here we faced a number of issues caused by the fact that Debian Live
images don't include package indices (with good reason), so no package
manager can list available software.
Everyone managed to start a graphical package manager via the Overview
(or via the CLI or Alt-F2 for a couple power users).
Some testers tried to use GNOME Software, which listed only already
installed packages (Debian bug #862560) and provided no way we could
find to refresh the package indices. That's arguably a bug in Debian
Live, but still: GNOME Software might display some useful information
when it detects this unusual situation.
We won't list here all the obstacles that were met in Synaptic:
it's no news its usability is rather sub-optimal and better
alternatives (such as GNOME Software) are in the works.
Mission C.2 Tweak temporary files management
The mission was poorly phrased: some observers had to clarify that it
was specifically about GNOME, and not generic Linux system
administration: some power-users were already searching the web for
command-line tools to address the task at hand.
Even with this clarification, no tester would have succeeded without
being told they were allowed to use the web with a search query
including the word "GNOME", or use the GNOME help or the Overview.
Yet eventually all testers succeeded.
It's interesting to note that regular GNOME users had the same problem
as others: they did not try searching "temporary" in the Overview and did
not look-up the GNOME Help until they were suggested to do so.
Mission C.3 Change the default video player
One tester configured one single video file format to be opened by
default with VLC, via right-click in Nautilus Open with etc.
He believed this would be enough to make VLC the default video
player, missing the subtle difference between "default video player"
and "default player for one single video format".
One tester tried to complete this task inside VLC itself and then
needed some help to succeed. It might be that the way web browsers ask
"Do you want ThisBrowser to become the default web browser?" gave a hint
an application GUI is the right place to do it.
Two testers searched "default" in the Overview (perhaps the previous
mission dealing with temporary files was enough to put them in this
direction). At least one tester was confused since the only search
result (Details View information about your system), which is the
correct one to get there, includes the word View, which suggests
that one cannot modify settings there, but only view them.
One long-term GNOME user looked in Tweak Tool first, and then used
the Overview.
Here again, GNOME users experienced essentially the same issues
as others.
Mission C.4 Add and remove world clocks
One tester tried to look for the clock on the top right corner of the
screen, then realized it was in the middle. Other than this, all
testers easily found a way to add world clocks.
However, removing a world clock was rather difficult; although most
testers managed to do it, it took them a number of attempts to
succeed:

Several testers left-clicked or right-clicked the clock they wanted
to remove, expecting this would provide them with a way to remove
it (which is not the case).

After a while, all testers noticed the Select button (that has no
text label nor tooltip info), which allowed them to select the
clock they wanted to remove; then, most testers clicked the 1
selected button, hoping it would provide a contextual menu or some
other way to act on the selected clocks (it doesn't).

Eventually, everyone managed to locate the Delete button on the
bottom right corner of the window; some testers mentioned that it is less
visible and flashy than the blue bar that appears on the top of the
screen once they had entered "Selection" mode.

General notes and observations

None of the participants sollicited the GNOME Help, which is unfortunate knowing its:

great quality;

translations in several languages;

availability and adaptability to regional specifications;

adequacy to the currently running version of GNOME.

Some users found the relevant help page online via web searches;
others initially ignored it among search results, then looked for it
later after being told that the mission was more about GNOME.

Whether testers were already GNOME users or not seldom impacted
their chances of success.

Unfortunately, we haven't compiled enough information about the
testers to provide useful data about who they are and what their
background is. Still, we had an interesting mix in terms of genders,
age (between 17 and 52 years old), skin color and
computer experience.

4 March 2017

(There is
a French translation
of this announcement.)
Join us in Paris, on May 13-14 2017, and we will find a way in
which you can help Debian with your current set of skills! You might
even learn one or two things in passing (but you don't have to).
Debian is
a free operating system for your
computer. An operating system is the set of basic programs and
utilities that make your computer run. Debian comes with dozens of
thousands of packages, precompiled software bundled up for easy
installation on your machine. A number of other operating systems,
such as Ubuntu and
Tails, are based on Debian.
The upcoming version of Debian, called Stretch, will be released
later this year. We need you to help us make it awesome :)
Whether you're a computer user, a graphics designer, or a bug triager,
there are many ways you can contribute to this effort. We also
welcome experience in consensus decision-making, anti-harassment
teams, and package maintenance. No effort is too small and whatever
you bring to this community will be appreciated.
Here's what we will be doing:

We will test the upcoming version of Debian and gather all
kinds of feedback.

We will identify problems about graphics and design in Debian,
and solve some of them.

We will triage bug reports that are blocking the release of the
upcoming version of Debian.

Debian package maintainers will fix some of these bugs.

Goals and principles
Before diving into the exact content of this event, a few words from
the
organization team.
This is a work in progress, and a statement of intent.
Not everything is organized and confirmed yet.
We want to bring together a heterogeneous group of people.
This goal will guide our handling of sponsorship requests, and will
help us make decisions if more people want to attend than we can
welcome properly. In other words: if you're part of a group that is
currently under-represented in computer communities, we would like you
to be able to attend.
We are committed to providing a friendly, safe and welcoming
environment for all, regardless of level of experience, gender,
gender identity and expression, sexual orientation, disability,
personal appearance, body size, race, ethnicity, age, religion,
nationality, or other similar personal characteristic. Attending this
event requires reading and respecting our
Code of Conduct,
that sets the standards in terms of behaviour for the whole event,
including communication (public and private) before, while and after.
There will be a team ready to act if you feel you have been or are
being harassed or made uncomfortable by an attendee.
We believe that money should not be a blocker for contributing to
Debian. We will sponsor travel and find a place to sleep for as many
enthusiastic attendees as possible. The space where this event will
take place is accessible to wheelchairs. We are trying to organize
a translation into (probably French) sign language. Vegan food
should be provided for lunch. If you have any specific needs regarding
food, please let us know when registering, and we will do our best.
What we will be doing
There will be a number of stations, i.e. physical space dedicated to
people with a given set of skills, hosted by someone who is ready to
make this space welcoming and productive.
A few stations are already organized, and are described below. If you
want to host a station yourself, or would like us to organize another
one, please
let us know.
For example, you may want to assess the state of Debian Stretch for
a specific field of interest, be it audio editing, office work,
network auditing or whatever you are doing with Debian :)
Test the upcoming version of Debian
We will test Debian Stretch and gather feedback. We are particularly
interested in:

feedback about support for universal access technologies, such as
screen readers;

feedback about the state of translations into your language;

the top 3 things you like or dislike most in the current version of
Debian; the top 3 things you like or dislike most in the upcoming
version of Debian;

general feelings about your experience with Debian!

Experienced Debian contributors will be ready to relay this feedback
to the relevant teams so it is put to good use.
Hypra collaborators will be there to bring a focus
on universal access technologies.
Design and graphics
Truth be told, Debian lacks people who are good at design and
graphics. There are definitely a good number of low-hanging fruits
that can be tackled in a week-end, either in Debian per-se, or in
upstream)
projects, or in Debian
derivatives.
This station will be hosted by Juliette Belin.
She designed the themes for the last two versions of Debian.
Triage Release Critical bugs
Bugs flagged as Release Critical are blocking the release of the
upcoming version of Debian. To fix them, it helps to make sure the bug
report documents the up-to-date status of the bug, and of its
resolution. One does not need to be a programmer to do this work!
For example, you can try and reproduce bugs in software you use... or
in software you will discover. This helps package maintainers better
focus their work.
This station will be hosted by Solveig. She has experience in bug
triaging, in Debian and elsewhere. Cyril Brulebois, a long-time Debian
developer, will provide support and advice upon request.
Fix Release Critical bugs
There will be a Bug Squashing Party.
Where? When? How to register?
See https://wiki.debian.org/BSP/2017/05/fr/Paris for the exact
address and time.
Please
register
by the end of March if you want to attend this event!
If you have any questions, please
get in touch with us.

2 February 2017

Today, I have released
the first beta for Tails 3.0, that will be the first version of Tails
based on Debian 9 (Stretch).
Our automated test suite pretends it works pretty well and matches our
safety expectations. I'm inclined to trust it. But as we learned after
porting Tails to Squeeze, Wheezy and Jessie: quick, exploratory
testing of pre-releases will not identify all the
remaining regressions.
So this time I'm trying to change this narrative a bit. I have
committed to provide security updates for the 3.0~ series, just like
we do for stable versions of Tails. This was the only missing bit to
make me feel comfortable
asking my fellow Tails contributors
to upgrade to Tails 3.0~beta1 for their daily usage.
I hope this helps us release a great Tails 3.0 on June 13 and
a better Debian Stretch too: the more early users of Tails based on
Stretch, the more chances they identify a few annoying regressions in
Stretch before it's called stable :)
For details, see the
official announcement.
Next step: FOSDEM. And then, back to organizing an event that aims at
improving both social and technical aspects of Debian (to be
announced in about a week, stay tuned); because the way we get
organized and how power is distributed matter.

22 January 2017

28 July 2016

At DebConf 16 I was working on a systemd backport for Debian/jessie. Results are officially available via the Debian archive now.
In Debian jessie we have systemd v215 (which originally dates back to 2014-07-03 upstream-wise, plus changes + fixes from pkg-systemd folks of course). Now via Debian backports you have the option to update systemd to a very recent version: v230. If you have jessie-backports enabled it s just an apt install systemd -t jessie-backports away. For the upstream changes between v215 and v230 see upstream s NEWS file for list of changes.
(Actually the systemd backport is available since 2016-07-19 for amd64, arm64 + armhf, though for mips, mipsel, powerpc, ppc64el + s390x we had to fight against GCC ICEs when compiling on/for Debian/jessie and for i386 architecture the systemd test-suite identified broken O_TMPFILE permission handling.)
Thanks to the Alexander Wirt from the backports team for accepting my backport, thanks to intrigeri for the related apparmor backport, Guus Sliepen for the related ifupdown backport and Didier Raboud for the related usb-modeswitch/usb-modeswitch-data backports. Thanks to everyone testing my systemd backport and reporting feedback. Thanks a lot to Felipe Sateler and Martin Pitt for reviews, feedback and cooperation. And special thanks to Michael Biebl for all his feedback, reviews and help with the systemd backport from its very beginnings until the latest upload.
PS: I cannot stress this enough how fantastic Debian s pkg-systemd team is. Responsive, friendly, helpful, dedicated and skilled folks, thanks folks!

15 June 2016

What happened in the Reproducible
Builds effort between June 5th and June 11th 2016:
Media coverage
Ed Maste gave a talk at BSDCan 2016 on
reproducible builds
(slides,
video).
GSoC and Outreachy updates
Weekly reports by our participants:

Scarlett Clark
worked on making some packages reproducible, focusing on KDE backend and
utility programs.

Ceridwen
published an initial design for the interface for reprotest, including a
discussion on different types of build variations and the difficulties of
specifying certain types of variations.

Valerie Young improved documentation for
building our tests website, began migrating Debian-specific pages into a new
namespace, and planned future work around its navigation.

Documentation update
- Ximin Luo proposed a modification
to our SOURCE_DATE_EPOCH spec explaining FORCE_SOURCE_DATE.
Some upstream build tools (e.g. TeX, see below) have expressed a desire to
control which cases of embedded timestamps should obey SOURCE_DATE_EPOCH.
They were not convinced by our arguments on why this is a bad idea, so we
agreed on an environment variable FORCE_SOURCE_DATE for them to implement
their desired behaviour - named generically, so that at least we can set it
centrally. For more details, see the text just linked. However, we strongly
urge most build tools not to use this, and instead obey SOURCE_DATE_EPOCHunconditionally in all cases.
Toolchain fixes

TeX Live 2016 released
with SOURCE_DATE_EPOCH support for all engines except LuaTeX and original TeX.

Valerie Young namespaced the Debian-specific pages to /debian/
namespace, with redirects to
for the previous URLs.

Holger Levsen improved the reliability of build jobs: the availability of
both build nodes (for a given build) is now being tested when a build job is
started, to better cope when one of the 25 build nodes go down for some reason.

Ximin Luo improved the index of identified
issues to
include the total popcon scores of each issue, which is now also used for
sorting that page.

Misc.
Last week we also learned about progress of reproducible builds in FreeBSD. Ed Maste announced a change to record the build timestamp during ports building, which is required for later reproduction.
This week's edition was written by Reiner Herrman, Holger Levsen and Chris Lamb and reviewed by a bunch of Reproducible builds folks on IRC.

Martin Michlmayr had a talk in which he presented an overview about innovations and changes in Debian in the last years. Martin expressed his disappointment that there was no talk from us in Vienna (we'll fix this at DebConf16 in Cape Town) and described the reproducible builds work as "a real innovation". His talk is very much worth seeing, whatever your current perspective, it might change your view on Debian.

Ben Hutchings explains how Secure Boot will use signed kernels via separate signature packages and how this was designed with reproducible builds in mind.

Misc.
Amongst the 29 interns who will work on Debian through GSoC and Outreachy there are four who will be contributing to Reproducible Builds for Debian and Free Software. We are very glad to welcome ceridwen, Satyam Zode, Scarlett Clark and Valerie Young and look forward to working together with them the coming months (and maybe beyond)!
This week's edition was written by Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

21 September 2015

What happened in the reproducible
builds effort this week:
Media coverage
Nathan Willis covered our DebConf15 status
update in Linux Weekly News. Access to
non-LWN subscribers will be given on Thursday 24th.
Linux Journal published a more general
piece
last Tuesday.
Unexpected praise for reproducible builds appeared this week in the form of
several iOS applications identified as including spyware. The malware was
undetected by Apple screening. This actually happened because
application developers had simply downloaded a trojaned version of XCode
through an unofficial
source. While reproducible builds can't really help users of non-free software, this is exactly the kind of attacks that we are trying to prevent in our systems.
Toolchain fixes

#799410 on segment by Chris Lamb: use date of the latest debian/changelog entry as build date.

reproducible.debian.net
Tests for Coreboot, OpenWrt, NetBSD, and FreeBSD now runs weekly (instead of monthly).
diffoscope development
Python 3 offers new features (namely yield from and concurrent.futures) that could help implement parallel processing. The clear separation of bytes and unicode strings is also likely to reduce encoding related issues.
Mattia Rizolo thus kicked the effort of porting diffoscope to Python 3. tlsh was the only dependency missing a Python 3 module. This got quickly fixed by a new upload.
The rest of the code has been moved to the point where only incompatibilities between Python 2.7 and Pyhon 3.4 had to be changed. The commit stream still require some cleanups but all tests are now passing under Python 3.
Documentation update
The documentation on how to assemble the weekly reports has been updated. (Lunar)
The example on how to use SOURCE_DATE_EPOCH with CMake has been improved. (Ben Beockel, Daniel Kahn Gillmor)
The solution for timestamps in man pages generated by Sphinx now uses SOURCE_DATE_EPOCH. (Mattia Rizzolo)
Package reviews
45 reviews have
been removed, 141 added and 62 updated this week.
67 new FTBFS reports have been filled by Chris Lamb, Niko Tyni, and Lisandro Dami n Nicanor P rez Meyer.
New issues added this week: randomness_in_r_rdb_rds_databases, python-ply_compiled_parse_tables.
Misc.
The prebuilder script is now properly testing umask variations again.
Santiago Villa started a discussion on debian-devel on how binNMUs would work for reproducible builds.

4 September 2015

Debian LTS
August was the fourth month I contributed to Debian LTS under the
Freexian umbrella. In total I spent four hours working on:

pykerberors: Fixed a regression in DLA-265-1 affecting the
default parameters of checkPassword(). This resulted in
DLA-265-2.

wordpress: Craig Small updated wordpress to fix CVE-2015-2213
CVE-2015-5622 CVE-2015-5731 CVE-2015-5732 and CVE-2015-5734. I
did some testing and released DLA-294-1.

Besides that I did CVE triaging of 9 CVEs to check if and how they
affect oldoldstable security as part of my LTS front desk work.
Debconf 15 was a great opportunity to meet some of the other LTS
contributors in person and to work on some of my packages:
Git-buildpackage
git-buildpackage gained buildpackage-rpm based on the work by
Markus Lehtonnen and merging of mock support is hopefully around the
corner.
Debconf had two gbp skillshares hosted by dkg and a
BoF by myself. A summary is here. Integration with dgit as (discussed
with Ian) looks doable and I have parts of that on my todo list as
well.
Among other things gbp import-orig gained a --merge-mode
option so you can replace the upstream branches verbatim on your
packaging branch but keep the contents of the debian/ directory.
Libvirt
I prepared an update for libvirt in Jessie fixing a crasher bug,
QEMU error reporting. apparmor support now works out of the box
in Jessie (thanks to intrigeri and Felix Geyer for that).
Speaking of apparmor I learned enough at Debconf to use this now by
default so we hopefully see less breackage in this area when new libvirt
versions hit the archive. The bug count wen't down quiet a bit and
we have a new version of virt-manager in unstable now as well.
As usual I prepared the RC candidates of libvirt 1.2.19 in experimental
and 1.2.19 final is now in unstable.

20 June 2015

Guillem Jover uploaded dpkg/1.18.0 which now uses an approximation to compute Installed-Size, making it indpendent from the underlying filesystem. It now always sort the Dpkg::Dist::Files files list on output to make the output stable with parallel builds.

Christian Hofstaedtler uploaded yard/0.8.7.4-2 which will not write timestamps in the generated documentation. Original patch by Chris Lamb, does not write timestamps in the generated documentation anymore.

Emmanuel Bourg uploaded maven-plugin-tools/3.3-2 which removes the date from the plugin descriptor. Patch by Reiner Herrmann.

Emmanuel Bourg uploaded maven-archiver/2.6-1 which now uses the date set in the DEB_CHANGELOG_DATETIME environment variable for the timestamp in the pom.properties file embedded in the jar files. Original patch by Chris West.

Nicolas Boulenguez uploaded dh-ada-library/6.4 which will warn against non deterministic ALI for sources newer than changelog.

reproducible.debian.net
Alioth now hosts a script that can be used to redo builds and test for a package. This
was preliminary done manually through requests over the IRC channel. This should reduce
the number of interruptions for jenkins' maintainers
The graph of the oldest build per day has been fixed. Maintainance scripts will not
error out when they are no files to remove.
Holger Levsen started work on being able to test variations of CPU features and
build date (as in build in another month of 1984) by using virtual machines.
debbindiff development
Version 18 has been released. It will uses proper comparators for pk3 and info
files. Tar member names are now assumed to be UTF-8 encoded.
The limit for the maximum number of different lines has been removed. Let's see
on reproducible.debian.net how it goes for pathological cases.
It's now possible to specify both --html and --text output. When neither of
them is specified, the default will be to print a text report on the standard
output (thanks to Paul Wise for the suggestion).
Documentation update
Nicolas Boulenguez investigated Ada
libraries.
Package reviews
451 obsolete
reviews have
been removed and 156 added this week.
New identified issues: running kernel version getting captured, random filenames in GHC debug symbols, and timestamps in headers generated by qdbusxml2cpp.
Misc.
Holger Levsen went to re:publica and talked about
reproducible builds to developers and users there.
Holger also had a chance to meet FreeBSD developers and discuss the status of
FreeBSD. Investigations have
started on how it could be made part of our current test
system.
Laurent Guerby gave Lunar access to systems in the GCC Compile
Farm. Hopefully access to these powerful
machines will help to fix packages for GCC, Iceweasel, and similar packages
requiring long build times.

4 May 2015

Debian Jessie has been released on April 25th, 2015. This has opened the
Stretch development cycle. Reactions to the idea of making Debian
build reproducibly have
been pretty enthusiastic. As the pace is now likely to be even faster,
let's see if we can keep everyone up-to-date on the developments.
Before the release of Jessie
The story goes back a long
way
but a formal announcement to the
project
has only been sent in February 2015.
Since then, too much work has happened to make a complete report, but
to give some highlights:

New variations are now tested: umask, kernel version, domain name,
and timezone. We might only be missing CPU type and current date now.

Improvements to reproducible.debian.net
Mattia Rizzolo has been working on compressing logs using gzip to save
disk space. The web server would uncompress them on-the-fly for clients
which does not accept gzip content.
Mattia Rizzolo worked on a new page listing various
breakage: missing
or bad debbindiff output, missing build logs, unavailable build
dependencies.
Holger Levsen added a new execution environment to run debbindiff using
dependencies from testing. This is required for packages built with
GHC as the compiler only understands interfaces built by the same
version.
debbindiff development
Version 17 has been uploaded to unstable. It now supports comparing
ISO9660 images, dictzip files and should compare identical files much
faster.
Documentation update
Various small updates and fixes to the pages about
PDF produced by LaTeX,
DVI produced by
LaTeX,
static
libraries,
Javadoc,
PE
binaries,
and Epydoc.
Package reviews
Known issues have been tagged when known to be deterministic as some
might unfortunately not show up on every single build.
For example, two new issues have been identified by building with one
timezone in April and one in May. RD
and help2man add current month and
year to the documentation they are producing.
1162 packages have been removed and 774 have been added in
the past week. Most of them are the work of proper automated
investigation done by Chris West.
Summer of code
Finally, we learned that both akira and Dhole were accepted for
this Google Summer of
Code.
Let's welcome them!
They have until May 25th before coding officialy begins. Now is the good time
to help them feel more comfortable by sharing all these little bits of
knowledge on how Debian works.

9 March 2015

Between december 9th 2014 and march 9th 2015 I ve been working as an intern for Debian on Improving AppArmor support in Debian.
Progress
Before the internship started, I had no clue about AppArmor at all. Reading the Wikipedia page and the AppArmor wiki did barely enlighten me. At least, until I got my hands dirty and installed and activated it. I was able to do this only because there was already some basic documentation on the Debian wiki on how to get AppArmor running on a Debian system.
When the internship started I felt a little bit lost. I started to read the documentation and to play around with some AppArmor profiles. But the error messages I saw and the profiles I opened for reading overwhelmed me. What did all these lines mean?
Then one mentor briefed me about the current status of AppArmor in Debian. I took many notes and tried to bring some order into the information I was being given. These notes became the first page of the documentation and my first blog post.
Surprise: suddenly I was in the middle of knowing what we were talking about and how the next few weeks would look like.
To start with, I have set up a test environment and continued to test some of the profiles which came with the packages I had installed, namely apparmor-profiles-extra which provided me with a profile for Pidgin. I was very much interested in securing this several thousand lines long C-code application on my machine! As a Pidgin user, I noticed immediately that one of my favourite features pidgin blinklight threw an error in the logs. I tried to fix it on my test VM and eventually made it work.
Now knowing that such fixes should first be done upstream, i cloned the corresponding upstream repository and sent my first patch. It was not easy at first to switch to another VCS than Git, although I had been using Bazaar and Subversion years ago.
Shortly afterwards, I saw my patch showing up on the upstream mailing list, and some days later it got merged. That was a huge encouragement.
I was now able to write more documentation on how to contribute upstream.
In order to organize the documentation, we ve set up some User Stories. I did not know about this tool before and had quite a hard time to grasp all the details but it proved to be very useful as some pages started to become long and confusing.
Writing the documentation took up a lot of time, but before being able to write anything down, I needed to work everything out! This way I incidentally learned how to interact with many parts of Debian s infrastructure:

Git repositories for packaging I imported my upstream patches into the AppArmor team s repositories. My previous experience in Debian packaging was not only helpful but indispensable for this task.

Debian bug tracker I learned more about reporting and usertagging bugs and filed some whishlist bugs which would make life easier.

Debian wiki I wrote documentation but I also read a lot of documentation, namely about using the Bug Tracking System and making things work on Alioth.

Ultimate Debian Database I wrote a Python script which queries the UDD and sends email notifications for new usertags. Writing the Python script was a lot of fun. I had some prior coding experience, but thanks to the mentors and upstream authors feedback I realized how important it is to write consistent code that can be easily understood and maintained by several people.

Setting up Git repositories, post commit hooks and cronjobs on Alioth for group maintaining scripts.

While playing around with the tools provided to inspect AppArmor status on the system, I even accidentally found a little bug in one of the upstream tools. It got fixed very quickly after I mentioned it on the AppArmor team s mailing list.
Organization
Although I was uncomfortable with this in the beginning, we organized public meetings every two weeks on IRC. These meetings were also attended by MeetBot who took care of taking notes and leaving a trace of our discussions.
Based on the meetings, I maintained a progress page and todo list on the Debian wiki, which helped us to know which tasks were planned for the next two weeks. Before each meeting I sent a status update to the mailing list, so the mentors could catch up with my work.
During the meetings I was not only asked to provide feedback on progress but also on mentoring itself. It proved to be very useful to be able to say where I was stuck and if the mentoring process worked out well enough (it did!).
Furthermore, I got regular, detailed and pedantic (thanks for trying to push me to perfection!) feedback on the team s mailing list.
The mentors had introduced me on the upstream IRC channel in the beginning, so most of the people who are active there knew about my existence, something which also proved to be handy!
Future
The internship time is over, but some work remains to be done. As a new member of the AppArmor Packaging team, I am committed to make it happen:

Think about a cross distro meeting there was a proposal to do that during DebConf

Write the migrate profile documentation after migrating a profile in a real world scenario together with intrigeri.

Fix Debian bug #702030 intrigeri should review my technical proposal before I work on it.

Thanks
I feel much more confident after these three months, technically but also personally.
Thank you: Holger Levsen and intrigeri for mentoring and encouraging me on this journey and to upstream contributors Christian Boltz, Steve Beattie (and everybody else I might forget here) for providing help and feedback.
The Debian community (OPW organizers, sponsors, Alioth maintainers, planet.debian.org maintainers although my posts don t show up anymore -and others) has been very friendly and welcoming and I am very happy to be part of it.

17 August 2011

Drive from England to Bosnia, and back.
Plus two days of air travel, for a week of travel all told.
The trip with the UK convoy back from Bosnia was enjoyable,
Steve found a great route thru the Alps, and I much enjoyed finally
seeing them. Then we stopped at a golf course in Luxemburg,
where my hotel room was a suite ... swanky. We bogged down in Belgium,
missed our ferry, which provided a chance to play some Eurogames
in Europe. Then I visited family in London.
I hope to eventually have some pictures from that trip. If those
who had cameras make them available.

In between the European tour, there was
DebConf. As always, it was
excellent. I did not come out with the large todo list of exciting
things like happened last year. I did continue nibbling through that
list. Had some good conversations about haskell, met Intrigeri, who
wrote the ikiwiki po plugin. Had some meetings on things I feel I've
sorta moved on from to some extent but still have to be available for.
Didn't manage significant technical work, but this was not unexpected.
The day trip was fun, enjoyed seeing the waterfalls and little mills,
and swimming the cold, cold river. The last few days I was out of energy.
I did not give any presentations, and only realized during the lightning
talks that I should have given one about git-annex.

I had expected to have most of a week at home after getting back from
Europe, and technically did. But it was too annoying and unusual to
count. Wildlife ate two trees of pears while I was away. My cat was
stressed. I was stressed. It was insanely humid, and the house had
been closed up for two weeks, and I had to fight mold and damp.

So the added trip to the beach that put this month over the top
to beyond insane amounts of travel, turned out to be sorta a good thing.
Camping in the dunes, kids, good books, sea turtle eggs fenced off a
hundred feet away on the beach waiting to hatch. Lots of kite flying,
and somehow no sunburn. And no rain until a dawn rainbow followed by
lots of wet just as we were breaking camp.
Full details in this Ocracode. Nobody but me understands or cares, but
that's just fine. :)
OBX1.1 P6 L6 SC5d+++b--c- U0
T3 f++-b2 R1dw Bn-b++m++ F+u+ SC++s++g0 H+++f2i4Vs---m0 E+++r+++
T6f++-b0 R1w Bn-b++m++ F++u++ SC++s++g1 H+++f2i5 V+++ E+++r++

For the past three days I've been coding, which feels good after all that
time away.