I recently installed new hardware in my primary computer running Debian unstable. The disk used for the / and /home filesystem was replaced with an Intel SSD 750 series NVM Express card. The graphics card was replaced by an AMD FirePro W4100 card, and two Dell P2715Q monitors were installed. Intel SSD 750 series NVM Express card This is an 800 GB SSD on a PCI-Express x4 card (model number SSDPEDMW800G4X1) using the relatively new NVM Express interface, which appears as a /dev/nvme* device. The stretch alpha 4 Debian installer was able to detect and install onto this device, but grub-installer 1.127 on the installer media was unable to install the boot loader. This was due to a bug recently fixed in 1.128:

grub-installer (1.128) unstable; urgency=high
  * Fix buggy /dev/nvme matching in the case statement to determine
    disc_offered_devfs (Closes: #799119). Thanks, Mario Limonciello!
 -- Cyril Brulebois <kibi@debian.org>  Thu, 03 Dec 2015 00:26:42 +0100

I was able to download and install the updated .udeb by hand in the installer environment and complete the installation. This card was installed on a Supermicro X10SAE motherboard, and the UEFI BIOS was able to boot Debian directly from the NVMe card, although I updated to the latest available BIOS firmware prior to the installation. It appears in lspci like this:

02:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
(prog-if 02 [NVM Express])
    Subsystem: Intel Corporation SSD 750 Series [Add-in Card]
    Flags: bus master, fast devsel, latency 0
    Memory at f7d10000 (64-bit, non-prefetchable) [size=16K]
    Expansion ROM at f7d00000 [disabled] [size=64K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI-X: Enable+ Count=32 Masked-
    Capabilities: [60] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [150] Virtual Channel
    Capabilities: [180] Power Budgeting <?>
    Capabilities: [190] Alternative Routing-ID Interpretation (ARI)
    Capabilities: [270] Device Serial Number 55-cd-2e-41-4c-90-a8-97
    Capabilities: [2a0] #19
    Kernel driver in use: nvme

The card itself appears very large in marketing photos, but this is a visual trick: the photographs are taken with the low-profile PCI bracket installed, rather than the standard height PCI bracket which it ships installed with. smartmontools fails to read SMART data from the drive, although it is still able to retrieve basic device information, including the temperature:

root@chase 0 :~# smartctl -d scsi -a /dev/nvme0n1
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.3.0-trunk-amd64] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor:               NVMe
Product:              INTEL SSDPEDMW80
Revision:             0135
Compliance:           SPC-4
User Capacity:        800,166,076,416 bytes [800 GB]
Logical block size:   512 bytes
Rotation Rate:        Solid State Device
Logical Unit id:      8086INTEL SSDPEDMW800G4                     1000CVCQ531500K2800EGN  
Serial number:        CVCQ531500K2800EGN
Device type:          disk
Local Time is:        Sun Dec 13 01:48:37 2015 EST
SMART support is:     Unavailable - device lacks SMART capability.
=== START OF READ SMART DATA SECTION ===
Current Drive Temperature:     31 C
Drive Trip Temperature:        85 C
Error Counter logging not supported
[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
Device does not support Self Test logging
root@chase 4 :~# 

Simple tests with cat /dev/nvme0n1 >/dev/null and iotop show that the card can read data at about 1 GB/sec, about twice as fast as the SATA-based SSD that it replaced. apt/dpkg now run about as fast on the NVMe SSD as they do on a tmpfs. Hopefully this device doesn't at some point require updated firmware, like some infamous SSDs have. AMD FirePro W4100 graphics card This is a graphics card capable of driving multiple DisplayPort displays at "4K" resolution and at a 60 Hz refresh rate. It has four Mini DisplayPort connectors, although I only use two of them. It was difficult to find a sensible graphics card. Most discrete graphics cards appear to be marketed towards video gamers who apparently must seek out bulky cards that occupy multiple PCI slots and have excessive cooling devices. (To take a random example, the ASUS STRIX R9 390X has three fans and brags about its "Mega Heatpipes".) AMD markets a separate line of "FirePro" graphics cards intended for professionals rather than gamers, although they appear to be based on the same GPUs as their "Radeon" video cards. The AMD FirePro W4100 is a normal half-height PCI-E card that fits into a single PCI slot and has a relatively small cooler with a single fan. It doesn't even require an auxilliary power connection and is about the same dimensions as older video cards that I've successfully used with Debian. It was difficult to determine whether the W4100 card was actually supported by an open source driver before buying it. The word "FirePro" appears nowhere on the webpage for the X.org Radeon driver, but I was able to find a "CAPE VERDE" listed as an engineering name which appears to match the "Cape Verde" code name for the FirePro W4100 given on Wikipedia's List of AMD graphics processing units. This explains the "verde" string that appears in the firmware filenames requested by the kernel (available only in the non-free/firmware-amd-graphics package):

[drm] initializing kernel modesetting (VERDE 0x1002:0x682C 0x1002:0x2B1E).
[drm] Loading verde Microcode
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_pfp.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_me.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_ce.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_rlc.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_mc.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_smc.bin

The card appears in lspci like this:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde GL [FirePro W4100]
(prog-if 00 [VGA controller])
    Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 2b1e
    Flags: bus master, fast devsel, latency 0, IRQ 55
    Memory at e0000000 (64-bit, prefetchable) [size=256M]
    Memory at f7e00000 (64-bit, non-prefetchable) [size=256K]
    I/O ports at e000 [size=256]
    Expansion ROM at f7e40000 [disabled] [size=128K]
    Capabilities: [48] Vendor Specific Information: Len=08 <?>
    Capabilities: [50] Power Management version 3
    Capabilities: [58] Express Legacy Endpoint, MSI 00
    Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
    Capabilities: [150] Advanced Error Reporting
    Capabilities: [200] #15
    Capabilities: [270] #19
    Kernel driver in use: radeon

The W4100 appears to work just fine, except for a few bizarre error messages that are printed to the kernel log when the displays are woken from power saving mode:

[Sun Dec 13 00:24:41 2015] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[Sun Dec 13 00:24:41 2015] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[Sun Dec 13 00:24:41 2015] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

There don't appear to be any ill effects from these error messages, though. I have the following package versions installed:

 / Name                          Version             Description
+++-=============================-===================-================================================
ii  firmware-amd-graphics         20151207-1          Binary firmware for AMD/ATI graphics chips
ii  linux-image-4.3.0-trunk-amd64 4.3-1~exp2          Linux 4.3 for 64-bit PCs
ii  xserver-xorg-video-radeon     1:7.6.1-1           X.Org X server -- AMD/ATI Radeon display driver

The Supermicro X10SAE motherboard has two PCI-E 3.0 slots, but they're listed as functioning in either "16/NA" or "8/8" mode, which apparently means that putting anything in the second slot (like the Intel 750 SSD, which uses an x4 link) causes the video card to run at a smaller x8 link width. This can be verified by looking at the widths reported in the "LnkCap" and "LnkSta" lines in the lspci -vv output:

root@chase 0 :~# lspci -vv -s 01:00.0   egrep '(LnkCap LnkSta):'
        LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
        LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
root@chase 0 :~# 

I did not notice any visible artifacts or performance degradation because of the smaller link width. The sensors utility from the lm-sensors package is capable of reporting the temperature of the GPU:

root@chase 0 :~# sensors radeon-pci-0100
radeon-pci-0100
Adapter: PCI adapter
temp1:        +55.0 C  (crit = +120.0 C, hyst = +90.0 C)
root@chase 0 :~# 

Dell P2715Q monitors Two new 27" Dell monitors with a native resolution of 3840x2160 were attached to the new graphics card. They replaced two ten year old Dell 2001FP monitors with a native resolution of 1600x1200 that had experienced burn-in, providing 4.32 times as many pixels. (TV and monitor manufacturers now shamelessly refer to the 3840x2160 resolution as "4K" resolution even though neither dimension reaches 4000 pixels.) There was very little to setup beyond plugging the DisplayPort inputs on these monitors into the DisplayPort outputs on the graphics card. Most of the setup involved reconfiguring software to work with the very high resolution. X.org, for tl;dr CLOSED NOTABUG reasons doesn't set the DPI correctly. These monitors have ~163 DPI resolution, so I added -dpi 168 to /etc/X11/xdm/Xservers. (168 is an even 1.75x multiple of 96.) Software like Google Chrome and xfce4-terminal rendered fonts and graphical elements at the right size, but other software like notion, pidgin, and virt-manager did not fully understand the high DPI. E.g., pidgin renders fonts at the correct size, but icons are too small. The default X cursor was also too small. To fix this, I installed the dmz-cursor-theme package, ran update-alternatives --config x-cursor-theme and selected /usr/share/icons/DMZ-Black/cursor.theme as the cursor theme. Overall, these displays are much brighter and more readable than the ones they replaced.

It is time again for another Tanglu blogpost (to be honest, this article is pretty much overdue ). I want to shine a spotlight on the work that s done in Tanglu, be it ongoing or past work done for the new release. Why is the new release taking longer than usual? As you might have noticed, usually a new Tanglu release (Tanglu 4 Dasyatis ) should be released this month. We decided a while ago, however, to defer the release and are now aiming for an release in February / March 2016. Reason for this change in schedule is the GCC 5 transition (and more importantly the huge amount of follow-up transitions) as well as some other major infrastructure tasks, which we would like to complete and give them a good amount of testing before releasing. Also, some issues with our build system, and generally less build power than in previous releases is a problem (At least the Debile build-system issues could be worked around or solved). The hard disk crash in the forum and bugtracking server also delayed the start of the Tanglu 4 development process a lot. In all of these tasks, manpower is of course the main problem Software Tasks General infrastructure tasks Improvements on Synchrotron Synchrotron, the software which is synchronizing the Tanglu archive with the Debian archive, received a few tweaks to make it more robust and detect installability of packages more reliably. We also run it more often now. Rapidumo improvements Rapidumo is a software written to complement dak (the Debian Archive Kit) in managing the Tanglu archive. It performs automatic QA tasks on the archive and provides a collection of tools to perform various tasks (like triggering package rebuilds). For Tanglu 4, we sometimes drop broken packages from the archive now, to speed up transitions and to remove packages which got uninstallable more quickly. Packages removed from the release suite still have a chance to enter it again, but they need to go through Tanglu s staging area again first. The removal process is currently semiautomatic, to avoid unneccessary removals and breakage. Rapidumo could benefit from some improvements and an interactive web interface (as opposed to static HTML pages) would be nice. Some early work on this is done, but not completed (and has a very low priority at the moment). DEP-11 integration There will be a bigger announcement on AppStream and DEP-11 in the next days, so I keep this terse: Tanglu will go for full AppStream integration with the next release, which means no more packaged metadata, but data placed directly in the archive. Work on this has started in Tanglu, but I needed to get back to the drawing board with it, to incorporate some new ideas for using synergies with Debian on generating the DEP-11 metadata. Phabricator Phabricator has been integrated well into our infrastructure, but there are still some pending tasks. E.g. we need subprojects in Phabricator, and a more powerful Conduit interface. Those are upstream bugs on Phabricator, and are actively being worked on. As soon as the missing features are available in Phabricator, we will also pursue the integration of Tanglu bug information with the Debian DistroTracker, which was discussed at DebConf this summer. UEFI support UEFI support is a tricky beast. Full UEFI support is a release-goal for Tanglu 4 (so we won t release without it). At time, our Live-CDs start on pure EFI systems, but there are several reported issues with the Calamares live-installer as well as Debian-Installer, which fails to install GRUB correctly. Work on resolving these problems is ongoing. Major LiveCD rework Tanglu 4 will ship with improved live-cds, which e.g. allow selecting the preferred locale early in the bootloader. We switched from live-boot to manage our live sessions to casper, the same tool which is also used in Ubuntu. Casper fixed a few issues we had, and brought some new, but overall using it was a good choice and work on making top-notch live-cds is progressing well. KDE Plasma Integration of the latest Plasma release is progressing, but its speed has slowed down since fewer people are working on it. If you want to help Tanglu s KDE Workspace integration, please help! For the upcoming release, the Plasma 5 packages which we created based on a collaboration with Kubuntu for the previous Tanglu 3 release have been merged with their Debian counterparts. This action fortunately was possible without major problems. Now Tanglu is (mostly) using the same Plasma 5 packages as Debian again (lots of Kudos go the the Kubuntu and Debian Qt/KDE packagers!). GNOME The same re-merge with Debian has been done on Tanglu s GNOME flavor (Tanglu also shipped with a more recent GNOME release than Debian in Tanglu 3). So Tanglu 4 GNOME and Debian Testing GNOME are at (almost) the same level. Unfortunately, the GNOME team is heavily understaffed a GNOME team member left at the beginning of the year for personal reasons, and the team now only has one semi-active member and me. Other An fvwm-nightshade spin is being worked on . Apart from that, there are no teams maintaining other flavors in Tanglu. Security & Stable maintenance Thanks to several awesome people, the current Tanglu Stable release (Tanglu 3 Chromodoris ) receives regular updates, even for many packages which are not in the fully supported set. Tangluverse Tasks Tasks (not) done in the global Tanglu universe. HTTPS for community sites Thanks to our participation in the Let s Encrypt closed beta program, Tanglu websites like the user forums and bugtracker have been fully encrypted for a while, which should make submitting data to these sites much more secure. So far, we didn t encounter issues, which means that we will likely aim for getting HTTPS encryption enabled on every Tanglu website. Tanglu.org website The Tanglu main website didn t receive much love at all. It could use a facelift and more importantly updated content about Tanglu. So far, nobody volunteered to update the website, so this task is still open. It is, however, a high-priority task to increase our public visibility as a project, so updating the website is definitely something which will be done soon. Promotion It doesn t hurt to think about how to sell Tanglu as brand : What is Tanglu? Our motivation, our goals? What is our slogan? How can we communicate all of this to new users, without having them to read long explanations? (e.g. the Fedora Project has this nicely covered on their main website, and their slogan Freedom, Friends, Features, First immediately communicates the project s key values) Those are issues engineers don t think about often, still it is important to present Tanglu in a way that is easy to grasp for people hearing about it for the first time. So far, no people are working on this task specifically, although it regularly comes up on IRC. Sponsoring & Government Tanglu is by design not backed by any corporation. However, we still need to get our servers paid. Currently, Tanglu is supported by three sponsors, which basically provide the majority of our infrastructure. Also, developers provide additional machines to get Tanglu running and/or packages built. Still, this dependency on very few sponsors paying the majority of the costs is very bad, since it makes Tanglu vulnerable in case one sponsor decides to end sponsorship. We have no financial backing to be able to e.g. continue to pay an important server in case it s sponsor decides to drop sponsorship. Also, since Tanglu is no legal entity, accepting donations is hard for us at time, since a private person would need to accept the money on behalf of Tanglu. So we can t easily make donating to Tanglu possible (at least not in the way we want donations to be). These issues are currently being worked on, there are a couple of possible solutions on the table. I will write about details as soon as it makes sense to go public with them. In general, I am very happy with the Tanglu community: The developer community is a pleasure to work with, and interactions with our users on the forums or via the bugtracker are highly productive and friendly. Although the development speed has slowed down a bit, Tanglu is still an active and awesome project, and I am looking forward to the cool stuff we will do in future!

It s been almost 2 years since the Debian Continuous Integration project has been launched, and it has proven to be a useful resource for the development of Debian. I have previously made a an introductory post, and this this is an update on the latest developments. Infrastructure upgrade Back in early 2014 when Debian CI was launched, there were less than 200 source packages with declared test suite metadata, and using a single worker machine polling the archive for updates and running tests sequentially in an infinite loop ( the simplest thing that could possibly work ) was OK-ish. Then our community started an incredible, slow and persistent effort to prepare source packages for automated testing, and we now have almost 5,000 of them. The original, over-simplistic design had to be replaced. The effort of transforming debci in a distributed system was started by Martin Pitt, who did an huge amount of work. In the latest months I was able to complete that work, to a point where I am confident in letting it run (mostly) unatended. We also had lots of contributions to the web UI from Brandon Fairchild, who was a GSOC intern in 2014, and continues to contribute to this date. All this work culminated in the migration from a single-worker model to a master/workers setup, currently with 10 worker nodes. On busy periods all of those worker nodes will go on for days with full utilization, but even then the turnaround between package upload and a test run is now a lot faster than it used to. Debian members can inspect the resource usage on those systems, as well as the length of the processing queue, by browsing to the corresponding munin instance (requires authentication via a SSL client certificated issued by sso.debian.org). The system is currenly being hosted on a Amazon EC2 account sponsored by Amazon. The setup is fully automated and reproducible. It is not fully (or at all) documented yet, but those interested should feel free to get in touch on IRC (OFTC, #debci) Testing backend changed from schroot to lxc Together with the infrastructure updates, we also switched to using lxc instead of schroot as backend. Most test suites should not be affected by this, but the default lxc settings might cause some very specific issues in a few packages. See for example #806542 ( liblinux-prctl-perl: autopkgtest failures: seccomp, capbset ) Adding support for KVM is also in the plans, and we will get to that at some point. Learn more If you want to learn more on how you can add tests for your package, a good first start is the debci online documentation (which is also available locally if you install debci ). You might also be interested in watching the live tutorial (WebM, 469 MB!) that has been presented at Debconf 15 earlier this year, full of tips and real examples from the archive. It would be awesome if someone wanted to transcribe that into a text tutorial ;-) How to get involved There are a few ways you can contribute: autodep8. if you are knowledgeable on a subset of packages that are very similar and can have their tests executed in a similar way, such as $Language libraries , you might consider writing a test metadata generator so that each package does not need to declare a debian/tests/control file explicitly, requiring only The Testsuite: header in debian/control. Ruby and Perl are already covered, and there is initial support for NodeJS. Adding support for new types of packages is very easy. See the source repository. If you manage to add support for your favorite language, please get in touch so we can discuss whitelisting the relavant packages in ci.debian.net so that they will get their tests executed even before being uploaded with the proper Testsuite: control field. autopkgtest. autopkgtest is responsible for actually running your tests, and you can use it to reproduce test runs locally. debci. debci is the system running in ci.debian.net (version 1.0, currently in testing, is exactly what is running up there, minus a version number and a changelog entry). It can also be used to have private clones of ci.debian.net, e.g. for derivatives or internal Debian-related development. See for example the Ubuntu autopkgtest site. Getting in touch For maintainer queries and general discussion:

• mailing list: debian-qa@lists.debian.org
• IRC: #debian-qa on OFTC. Feel free to highlight terceiro

For the development of debci/autopkgtest/autodep8

• mailing list: autopkgtest-devel@lists.alioth.debian.org
• IRC: #debci on OFTC

The first reproducible world summit was held in Athens, Greece, from December 1st-3rd with the support of the Linux Foundation, the Open Tech Fund, and Google. Faidon Liambotis has been an amazing help to sort out all local details. People at ImpactHub Athens have been perfect hosts. Nearly 40 participants from 14 different free software project had very busy days sharing knowledge, building understanding, and producing actual patches. Anyone interested in cross project discussions should join the rb-general mailing-list. What follows focuses mostly on what happened for Debian this previous week. A more detailed report about the summit will follow soon. You can also read the ones from Joachim Breitner from Debian, Clemens Lang from MacPorts, Georg Koppen from Tor, Dhiru Kholia from Fedora, and Ludovic Court s wrote one for Guix and for the GNU project. Infrastructure Several discussions at the meeting helped refine a shared understanding of what kind of information should be recorded on a build, and how they could be used. Daniel Kahn Gillmor sent a detailed update on how .buildinfo files should become part of the Debian archive. Some key changes compared to what we had in mind at DebConf15:

• Two .buildinfo with different environment information can attest to the same exact binary artifact.
• Multiple .buildinfo files can coexist for the same .deb as long as the listed checksums match the source and binary package in the archive.
• .buildinfo can be signed in-line to certify where a build comes from.

Hopefully, ftpmasters will be able to comment on the updated proposal soon. Packages fixed The following packages have become reproducible due to changes in their build dependencies: fades, triplane, caml-crush, globus-authz. The following packages became reproducible after getting fixed:

• binutils/2.25.90.20151125-2 uploaded by Matthias Klose, original patch by Reiner Herrmann.
• chocolate-doom/2.2.1-2 by Fabian Greffrath.
• csound/1:6.05~dfsg1-7 by Felipe Sateler.
• dispcalgui/3.0.5.0-1 uploaded by Christian Marillat, original patch by Reiner Herrmann.
• drmips/2.0.1-1 by Bruno Nova.
• ghc/7.10.1-5 by Joachim Breitner.
• gitolite3/3.6.3-3 by David Bremner.
• libdigidoc/3.10.1.1208+ds1-1 uploaded by Andrew Shadura, original patch by Reiner Herrmann.
• liberasurecode/1.1.0-3 uploaded by Thomas Goirand, original patch by Chris Lamb.
• libjs-jcrop/0.9.13+dfsg-1 uploaded by David Pr vot, original patch by Chris Lamb.
• libnet-interface-perl/1.012-3 uploaded by gregor herrmann, original patch by Reiner Herrmann.
• libosmocore/0.9.0-1 uploaded by Ruben Undheim, original patch by Reiner Herrmann.
• libperl-apireference-perl/0.21-2 fixed by Niko Tyni (#807111).
• netrik/1.16.1-2 by Axel Beckert.
• openssl/1.0.2e-1 by Kurt Roeckx.
• snp-sites/2.0.2-2 uploaded by Sascha Steinbiss, original patch by Reiner Herrmann.
• xfonts-shinonome/1:0.9.11-1 by Hideki Yamane, original patch by Chris Lamb.

Some uploads fixed some reproducibility issues, but not all of them:

• raster3d/3.0-3-2 uploaded by Andreas Tille, original patch by Lunar.

Patches submitted which have not made their way to the archive yet:

• #806580 on metview by Reiner Herrmann: remove timestamps from metview script.
• #806974 on xpra by Reiner Herrmann: interpret the changelog date as UTC.
• #807051 on why by Valentin Lorentz: removes extra timestamps from the build system.

akira sent proposals on how to make bash reproducible. Alexander Couzens submitted a patch upstream to add support for SOURCE_DATE_EPOCH in grub image generator (#787795). reproducible.debian.net An issue with some armhf build nodes was tracked down to a bad interaction between uname26 personality and new glibc (Vagrant Cascadian). A Debian package was created for koji, the RPM building and tracking system used by Fedora amongst others. It is currently waiting for review in the NEW queue. (Ximin Luo, Marek Marczykowski-G recki) diffoscope development diffoscope now has a dedicated mailing list to better accommodate its growing user and developer base. Going through diffoscope's guts together enabled several new contributors. Baptiste Daroussin, Ed Maste, Clemens Lang, Mike McQuaid, Joachim Breitner all contributed their first patches to improve portability or add new features. Regular contributors Chris Lamb, Reiner Herrmann, and Levente Polyak also submitted improvements. The next release should support more operating systems, filesystem image comparison via libguestfs, HTML reports with on-demand loading, and parallel processing for the most noticeable improvements. Package reviews 27 reviews have been removed, 17 added and 14 updated in the previous week. Chris Lamb and Val Lorentz filed 4 new FTBFS reports. Misc. Baptiste Daroussin has started to implement support for SOURCE_DATE_EPOCH in FreeBSD in libpkg and the ports tree. Thanks Joachim Breitner and h01ger for the pictures.

"It" has arrived [1]. Finally... Summary first... In a nutshell: Support Jolla, support the Mer Project, support the development of Sailfish OS!!! If you are brave enough, even get a Jolla device yourself and find out what it's like. Impressions then... First impression... Go and get one yourself. Jolla smartphones are awesome. Second impression... Wow, there are some bugs here and there that require being fixed. Dropping the idea of giving away Jolla phones for X-mas to family members for now... Third impression... The Jolla Oy company currently goes through some sort of a death valley [2] that startups regularly face. Let's keep fingers crossed that the company survives. Well, then... Fourth impression... The hosting location of the source code of the free parts of the SailfishOS is not always evident. I am still investigating this... Especially software offered via http://openrepos.net does not always come with a reference to the source code of provided binary blobs. Overall impression... If you are a nerd or brave enough otherwise, go and get one!!! Especially if your N900 gradually starts falling apart. Personally, my impression is that the Jolla smartphone is the best of an "up-to-date" Free Software phone, we can get at the moment. read more

November 2015 was a month where I could not work on much FLOSS, unfortunately. Due to family members and myself being ill, things got stalled and delayed. Local customer projects always receive prioritized attention in such phases. Ayatana Indicators As already posted in a separate article [1], I spent quite some time on studying the architectural design of Ayatana/Ubuntu Application Indicators. For the pure purpose of studying I forked various code projects around Indicators and tested them on Debian unstable. Unfortunately, I did not come to a point where things really started working at runtime. Git projects of the various Ayatana Indicators compenents can be found on Github [2]. Debian and Debian LTS For Debian LTS, I had to dispatch several of the open hours to other team members, because things got delayed here. I spent 6.5h on backporting a patch for CVE-2015-1335 [3] to lxc 0.7.x (as found in Debian squeeze and Ubuntu 12.04) [4]. This is still work in progress and I hope for a solution before X-mas. Locally, I did a lot of work for our Debian Edu / Skolelinux customers, but there has not been much to contribute back to the FLOSS realm, so far. read more

I've now been working on Debian LTS for a full year, so I'm going to stop counting months. In November, I carried over 5 hours from October and was assigned another 15 hours of work by Freexian's Debian LTS initiative. However, I spent much of the month on sick leave, so I only worked 5 billable hours on Debian LTS plus some unbilled time while on leave. I had another week in the front desk role, and triaged about 20 new issues. Less than half actually affected packages supported in squeeze-lts, and only about 5 were important. CVE-2015-5309 in putty had a patch that was fairly easy to backport, so I did that, uploaded and sent DLA 347-1. I backported several security fixes to linux-2.6 and sent some of those we had already released to Willy Tarreau for inclusion in Linux 2.6.32-longterm. At the end of the month, I reviewed Linux 2.6.32.69-rc1 and found a couple of bugs, leading to an -rc2. I applied that to the linux-2.6 packaging branch for squeeze-lts and spent a little time testing it, thankfully not hitting any regressions.

The second update to the Rblpapi package (since the initial CRAN upload in August) is now available. Rblpapi connects R to the Bloomberg system, giving access to a truly vast array of time series data and custom calculations. This release brings a new subscribe() function for real-time data, written by Whit. Don't get too excited because R's single-threadedness places some limits of the usefulness of this--but it is still tremendously valuable for checking other data sources etc pp. Also included in this release are a ton of bug fixes, many contributed by Rademeyer -- see below for more details.

Changes in Rblpapi version 0.3.2 (2015-12-07)

• A new subscribe() function supports live data subscription for a set of tickers and fields (#88).
• In the beqs() example the correct date format is used (PR #85 by Rademeyer).
• Both getTicks() and getBars() now check the start and end times for proper Datetime class.
• The getBars() function now also return the value traded (request of #89).
• An error in the documentation for bdh was corrected (PR #93 by Rademeyer closing #85).
• The beqs() function is now more robust with respect to empty return columns (PR #100 by Rademeyer fixing ticket #99).
• The getBars() function now uses a single (named) vector options to pass optional values to the underlying function (PR #105 updating PR #48 and fixing #47).
• When R is built with libcurl support, it used to download the build-time library and headers; otherwise curl is used. This avoids an issue on OS X where curl is insufficient.

Courtesy of CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the Rblpapi page. Questions, comments etc should go to the issue tickets system at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Cookies are an important part of the Web since they are the primary mechanism that websites use to maintain user sessions. Unfortunately, they are also abused by surveillance marketing companies to follow you around the Web. Here are a few things you can do in Firefox to protect your privacy.

Cookie Expiry Cookies are sent from the website to your browser via a Set-Cookie HTTP header on the response. It looks like this:

HTTP/1.1 200 OK
Date: Mon, 07 Dec 2015 16:55:43 GMT
Server: Apache
Set-Cookie: SESSIONID=65576c6c64206e6f2c657920756f632061726b636465742065686320646f2165
Content-Length: 2036
Content-Type: text/html;charset=UTF-8

When your browser sees this, it saves that cookie for the given hostname and keeps it until you close the browser. Should a site want to persist their cookie for longer, they can add an Expires attribute:

Set-Cookie: SESSIONID=65576c...; expires=Tue, 06-Dec-2016 22:38:26 GMT

in which case the browser will retain the cookie until the server-provided expiry date (which could be in a few years). Of course, that's if you don't instruct your browser to do things differently.

Controlling Cookie Expiry In order to change your cookie settings, you must open the Firefox preferences, click on "Privacy" and then choose "Use custom settings for history" under the "History" heading. There, you will have the ability to turn off cookies entirely (network.cookie.cookieBehavior = 2), which I don't recommend you do in your browser since you won't be able to login anywhere. On the other hand, turning off cookies is what I do (and recommend) in Thunderbird since I can't think of a legitimate reason for an email to leave a cookie in my mail client. Another control you'll find there is "Keep until" which defaults to honoring the server-provided expiry ("they expire" aka network.cookie.lifetimePolicy = 0) or making them expire at the end of the browsing session ("I close Firefox" aka network.cookie.lifetimePolicy = 2). A third option is available if you type about:config into your URL bar and looking for the network.cookie.lifetimePolicy preference. Setting this to 3 will honor the server-provided expiry up to a maximum lifetime of 90 days. You can also make that 90 days be anything you want by changing the network.cookie.lifetime.days preference. Regardless of the settings you choose, you can always tell Firefox to clear cookies when you close it by selecting the "Clear history when Firefox closes" checkbox, clicking the "Settings" button and making sure that "Cookies" is selected (privacy.clearOnShutdown.cookies = true). This could be useful for example if you'd like to ensure that cookies never last longer than 5 days but are also cleared whenever you shut down Firefox.

Third-Party Cookies So far, we've only looked at first-party cookies: the ones set by the website you visit and which are typically used to synchronize your login state with the server. There is however another kind: third-party cookies. These ones are set by the third-party resources that a page loads. For example, if a page loads JavaScript from a third-party ad network, you can be pretty confident that they will set their own cookie in order to build a profile on you and serve you "better and more relevant ads".

Controlling Third-Party Cookies If you'd like to opt out of these, you have a couple of options. The first one is to turn off third-party cookies entirely by going back into the Privacy preferences and selecting "Never" next to the "Accept third-party cookies" setting (network.cookie.cookieBehavior = 1). Unfortunately, turning off third-party cookies entirely tends to break a number of sites which rely on this functionality (for example as part of their for login process). A more forgiving option is to accept third-party cookies only for sites which you have actually visited directly. For example, if you visit Facebook and login, you will get a cookie from them. Then when you visit other sites which include Facebook widgets they will not recognize you unless you allow cookies to be sent in a third-party context. To do that, choose the "From visited" option (network.cookie.cookieBehavior = 3). In addition to this setting, you can also choose to make all third-party cookies automatically expire when you close Firefox by setting the network.cookie.thirdparty.sessionOnly option to true in about:config.

Other Ways to Limit Third-Party Cookies Another way to limit undesirable third-party cookies is to tell the browser to avoid connecting to trackers in the first place. This functionality is now built into Private Browsing mode and enabled by default. To enable it outside of Private Browsing too, simply go into about:config and set privacy.trackingprotection.enabled to true. You could also install the EFF's Privacy Badger add-on which uses heuristics to detect and block trackers, unlike Firefox tracking protection which uses a blocklist of known trackers.

My Recommended Settings On my work computer I currently use the following:

network.cookie.cookieBehavior = 3
network.cookie.lifetimePolicy = 3
network.cookie.lifetime.days = 5
network.cookie.thirdparty.sessionOnly = true
privacy.trackingprotection.enabled = true

which allows me to stay logged into most sites for the whole week (no matter now often I restart Firefox Nightly) while limiting tracking and other undesirable cookies as much as possible.

I decided some time ago to take over the development of at daemon. Here is a new release of at v3.1.17 From the Changelog:

at 3.1.17 (2015-08-31):
  Jose M Calhariz:
        at.1.in: Document behaviour when using past time, thanks Kelly Price (Closes: #639900).
        Makefile.in: On distclean remove at.allow.5, auto generated file.

Blocked by indiegogo because of blocked javascript?

I usually browse the web with javascript blocked, for obvious security reasons and slightly less obvious free software reasons https://www.gnu.org/philosophy/javascript-trap.html, adding sites to a temporary whitelist when absolutely needed.

I know that this hurts the revenue model of many websites, in some cases I'm sorry, in other cases I pay a subscription so that I don't have to be sorry, and in other cases I just don't care, depending on the service they provide.

One thing that I hate are websites that require javascript even to show their basic contents: I understand why some of them are doing it, but less so when they aren't getting money from ads, but from actually providing a paid service, such as indiegogo.

This morning I was browsing a campaign on that crowdfunding site, grudgingly allowed javascript from their domain to be able to see the campaign description and suddenly found this:

http://social.gl-como.it/photo/dde1ddaa79d831ffbc2bee30110a2497.png

So ok, they want me to confirm I'm a human, ok, I'm fine with that, but asking for personal identification? just to be able to browse your site securely? No thanks. The support page linked in that says that this company also support just asking to fill a captcha, which is probably not as effective, but also much less intrusive.

I was browsing a campaign for an (apparently) open hardware encryption device, which is probably enough these days to get you somewhat under the radar (luckily, I am already, and I have a t-shirt to prove it :) ), so being asked to identify myself before I could even start considering whether the device was interesting enough to support (in a public-ish way) was expecially bad.

So, if you are working on something like that, maybe you could consider using a different crowdfunding website, one that respects more their users?

My flight from Athens where I had the pleasure to attend the first reproducible world summit landed at the scheduled time in Paris (CDG). While people were getting their bags and putting their coats on, one member of the cabin crew announced that a police control will take place outside the plane and that we should have ready identity documents. My seat was in the back of the plane, so I had time to wait in the cold of the jetway while all passengers were controlled one after the other. Three cops were set up right at the entrance of the terminal. One was taking cards or passports and looking at people's face. He then passed it to another cop in front of a suitcase that seemed to contain a scanner and a computer. The third one was just standing against the wall watching. When it was my turn, after scanning my passport, the cop had this nice gesture where she started to move her hand holding the passport toward me just like she had just did a hundred times before pulling it backward when the result appeared on the screen. I had the confirmation that I was registered as a dangerous political activist in 2012 when David Dufresne published Magasin G n ral. One report from the interior intelligence service from 2008 was leaked to promote the book. My name had not been properly redacted from the very first version that went online and was associated with a political self-organized space in Dijon. Some Debian Developers had the pleasure to visit that space in 2005, 2006, or 2007. The report was full of mistakes, like almost all police files, so I don't want to comment on it. The good news is that since then, I have stopped being paranoid. I knew, and thus could take appropriate precautions. Just like every time I have to approach an airport, all my (encrypted) electronic devices were turned off. I had shaved a couple hours before. I know a lawyer ready to represent me. I am fully aware that it's best to say as little as possible. Although it has been a while since I had such a blatant confirmation that I was still a registered anarchist. It should not be a surprise though. Once you are in, there's no way out. I was then asked to step aside while they proceeded with the rest of the queue. I put my backpack down and leaned against the wall. Once they were over, one of the cops asked me to follow him. We walked through the corridors to reach the office of the border police. While we were walking, they asked me a series of questions. I'm not mentioning the pauses in between, but here's what I can remember:

Do you have a connection?
No.
Are you going to Paris?
To my parents' in the suburbs.
How long have you been staying in Greece?
5 days.
flipping the pages of my passport And you come back from the U.S. in Feb. 2015?
No, that was the maximum stay. I was there in August 2014.
Why were you in Greece? Vacations?
Work. I was at a meeting.
What do you do?
Free software.
What is that?
I am a developper.
Oh, computers.
Yes.
Is that why you also were in the US?
Yes, it was another conference.
And so you travel because of that. That's nice.

Are you a freelancer?
I work with a coop, but yes.

The cop also commented that they had to do some simple checks and that they would then let me go as I was coming back. I did not trust this but said nothing. When then passed through a door where the cop had to use their badge to unlock it. I was asked to sit on a chair in the corridor between two offices (as far as I could see). I could hear one cop explaining the situation to the next: Il a une fiche. Ah, une fiche. They seemed quite puzzled that I was not controlled when I flew out on Monday. After some minutes, another cop came back asking me for my boarding pass. Some more minutes later, he came back asking me if the address on my passport was still valid. I replied no . They gave me a piece of paper asking me for my current address, a phone number and an email address. As these information are all easy to find, I thought it was easier to comply. I gave my @irq7.fr address that I use for all public administrations. When the cop saw it, he asked:

What is it?
I don't understand.
Is it your company?
It is a non-profit.

He gave me my passport back and showed me the way out. (I will spare you details on the discussion I had to listen while waiting between two cops about how one loved to build models of military weapons used in wars against communism because of his origins. And that he was pissed off because fucking Europe disallowed some (toxic) paints he was used to.) To the best of my understanding, what happened is that they made a phone call and were just asked to update my personal details by the intelligence service. I don't know, but I'm left to wonder if all these people might just have been controlled because I was on the flight. All-in-all this didn't take too long: one hour after leaving the plane I was on the platform for the regional trains. The cops stayed polite the whole time. I am privileged: French citizen, white, able to speak French with a teacher accent. I am pretty sure it would have not been that good if I had been displaying a long beard or a djellaba. I took the time to document this because I know too many people who think that what the French government is doing doesn't concern them. It does. It's been a couple of years now that antiterrorism is how governments keep people in check. But we are reaching a whole new level now. We are talking about cops keeping their guns while off duties, house searches at any hours without judge oversight, and the government wants to change the constitution to make the state of emergency permanent. We've seen so many abuses in just two weeks. It will not go well. Meanwhile, instead of asking themselves why young people are killing others and themselves, state officials prefer dropping bombs. Which will surely prevent people ready to die from using suicidal tactics, right? We are at the dawn of an environmental crisis that will end humanity. Every human on this planet is concerned. People get beaten up when they march to pressure governments to do something about it. We need to unite and resist. And yes, we are going to get hurt but freedom is not free.

This week, I was attending the first Reproducible Builds World Summit in Athens. A while ago, I have fixed some reproducibility bugs in the Haskell compiler GHC (parts of #4012), and that got me a ticket to this fully sponsored and nicely organised event. This was the first event I attended that had a dedicated and professional moderator, Gunner from Aspiration, who came up with a suitable on-the-fly-schedule, ensured the time was structured by shorter plenary rounds with all ~40 attendees as well as longer working sessions in groups of usually at most 10 people, motivated people to run ( facilitate ) these working groups as well as ensured that any results were noted and collected. This definitely makes a difference to the otherwise unstructured let s all sit in a big circle and endlessly discuss things or let s all just hack on what we want to hack on right now structure of less professionally organised meetings. But after 1 days of talking, a certain desire to hack and get work done could be felt throughout the group, so most of us were happy to be allowed to make use of the laptop on Wednesday afternoon. At least as far as possible the wireless was not expecting this crowd, it seems. Besides the few patches above, my involvement in the project is rather rudimentary, so I tried to contribute as far as possible during the event itself. This was not always easy, as many of the working sessions were either self-reflecting or forward-facing: What problems do we see? What should we get done next? How do we talk to users/upstream/press/doners? Where possible, I tried to at least be helpful in the discussion. During the hacking sessions, I found it most useful to contribute to diffoscope, a program to recursively and deeply show the difference between files of any format, so there are now patches to implement a multi-file HTML output, to more efficiently include large diffs, and more importantly I assisted Lunar in making diffoscope multi-threaded. In Python this is not a very great experience; I guess I am spoiled by Haskell (as it is often the case). I enjoyed the group; a bit like DebConf but with many new faced from similarly-minded, but different projects. It was, however, again a Free Software event with an embarrassing low number of female participants. I liked discussing a proof of G del s first incompleteness theorem during a skill exchange session. Unfortunately, I had to leave very timely after the event on Thursday evening, in order to attend the Haskell in Leipzig workshop.

Categories:

• Debian-Blog
• Technology

Keywords:

• KDE
• gnome
• Yoga 2 13
• Yoga
• Lenovo
• Touch
• UI
• Design
• Freedom
• Privacy

Like:

Like everybody else on the internet today was the day I started rolling out SSL certificates, via let's encrypt. The process wasn't too difficult, but I did have to make some changes. Pretty much every website I have runs under its own UID, and I use a proxy to pass content through to the right back-end. Running 15+ webservers feels like overkill, but it means that the code running start.steve.org.uk cannot read/modify/break the code that is running this blog - because they run as different UIDs. To start with I made sure that all requests to the top-level /.well-known directory were shunted to a local directory - via this in /etc/apache2/conf-enabled/well-known.conf:

Alias /.well-known/ /srv/well-known/
<Directory "/srv/well-known/">
    ForceType text/plain
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    AuthType None
    Require all granted
</Directory>

Then configured each proxy to avoid forwarding that path to the back-ends, by adding this to each of the individual virtual-hosts that run proxying:

<Proxy *>
  Order allow,deny
  Allow from all
</Proxy>
ProxyPass /.well-known !
ProxyPass        / http://localhost:$port/
..

Then it came to be time to actually generate the certificates. Rather than using the official client I used a simpler one that allowed me to generate requests easily:

CSR=/etc/apache2/ssl/csr/
KEYS=/etc/apache2/ssl/keys/
CERTS=/etc/apache2/ssl/certs/
# generate a key
openssl genrsa 4096 > $KEYS/lumail.key
# make a CSR
openssl req -new -sha256 -key $KEYS/lumail.key -subj "/" -reqexts SAN \
   -config <(cat /etc/ssl/openssl.cnf \
   <(printf "[SAN]\nsubjectAltName=DNS:www.lumail.org,DNS:lumail.org")) \
   > $CSR/lumail.csr
# Do the validation
acme_tiny.py --account-key ./account.key --csr $CSR/lumail.csr \
  --acme-dir /srv/well-known/acme-challenge/ > $CERTS/lumail.crt.new

And then I was done. Along the way I found some niggles:

• If you have a host that listens on IPv6 only you cannot validate your request - this seems like a clear failure.
• It is assumed that you generate all your certificates in their live-location. e.g. You cannot generate a certificate for foo.example.com on the host bar.example.com.
• If you forward HTTP -> HTTPS the validation fails. I had to setup rewrite rules to avoid this, for example lumail.org contains this:
  • RewriteEngine On
  • RewriteCond % REQUEST_URI !^/.well-known
  • RewriteRule ^/(.*) https://lumail.org/$1 [L]

The first issue is an annoyance. The second issue is a real pain. For example *.steve.org.uk listens on one machine except for webmail.steve.org.uk. Since there are no wildcards created a single certificate with Alt-names for a bunch of names such as:

• ..
• blog.steve.org.uk
• start.steve.org.uk
• ..

Then seperately create a certificate for the webmail host - which I've honestly not done yet. Still I wrote a nice little script to generate SSL for a number of domains, with different Alt-Names, wrapping around the acme_tiny.py script, and regenerating all my deployed certificates is now a two minute job. (People talk about renewing certificates. I don't see the gain. Just replace them utterly every two months and you'll be fine.)

A new minor release of RQuantLib was released onto CRAN and into Debian. It takes advantages of some changes from last week's QuantLib release 1.7. Particularly noteworthy is the addition of support for intra-daily times in QuantLib based on work by Klaus Spanderen. If QuantLib was configured with the -enable-intraday option, we use the higher granularity of the time representation in all option pricers and implied volatility calculations. The impact of this feature is illustrated in the graph below. The graph shows the valuation of a Call option, European expiry, struck at the money with sensible short rate, dividend yield and volatility. We vary the time to expiry from five days to zero in steps of a quarter day. In darker blue is the correct valuation declining in parabolic shape. In lighter blue is what we get with QuantLib up to release 1.6, or newer releases configured without intra-day time support: an ugly step function that is off, and increasingly so we approach the expiration. Which leads to an appeal: a volunteer is needed to update the QuantLib 1.7 build for Windows. Jeroen tried, but ran into a snag and out of time. If you can help, please get in touch to Jeroen and myself. We suspect that the largest part of RQuantLib users relies on the prebuilt binaries from CRAN, and it would nice to have these updated to the current version of QuantLib. The full changes are detailed below.

Changes in RQuantLib version 0.4.2 (2015-12-03)

• Changes in RQuantLib code:
  • Intra-day times are now available if QuantLib 1.7 or later is used, and has been configured with --enable-intraday
  • New helper functions getQuantLibVersion() and getQuantLibCapabilties()
  • New package startup code detects and warns about outdated QuantLib versions, or missing intra-day capability, unless not interactive.
  • The missing Monthly parameter has been added to matchFrequency (fixing issue ticket #19)

Courtesy of CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list off the R-Forge page. Issue tickets can be filed at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.