Was there anything you didn t like about our trip? Jacob s answer: That we had to leave so soon! That s always a good sign. When I first heard about the Vintage Computer Festival Midwest, I almost immediately got the notion that I wanted to go. Besides the TRS-80 CoCo II up in my attic, I also have fond memories of an old IBM PC with CGA monitor, a 25MHz 486, an Alpha also in my attic, and a lot of other computers along the way. I didn t really think my boys would be interested. But I mentioned it to them, and they just lit up. They remembered the Youtube videos I d shown them of old line printers and punch card readers, and thought it would be great fun. I thought it could be a great educational experience for them too and it was. It also turned into a trip that combined being a proud dad with so many of my other interests. Quite a fun time. (Jacob modeling his new t-shirt) Captain Jacob Chicago being not all that close to Kansas, I planned to fly us there. If you re flying yourself, solid flight planning is always important. I had already planned out my flight using electronic tools, but I always carry paper maps with me in the cockpit for backup. I got them out and the boys and I planned out the flight the old-fashioned way. Here s Oliver using a scale ruler (with markings for miles corresponding to the scale of the map) and Jacob doing calculating for us. We measured the entire route and came to within one mile of the computer s calculation for each segment those boys are precise! We figured out how much fuel we d use, where we d make fuel stops, etc. The day of our flight, we made it as far as Davenport, Iowa when a chance of bad weather en route to Chicago convinced me to land there and drive the rest of the way. The boys saw that as part of the exciting adventure! Jacob is always interested in maps, and had kept wanting to use my map whenever we flew. So I dug an old Android tablet out of the attic, put Avare on it (which has aviation maps), and let him use that. He was always checking it while flying, sometimes saying this over his headset: DING. Attention all passengers, this is Captain Jacob speaking. We are now 45 miles from St. Joseph. Our altitude is 6514 feet. Our speed is 115 knots. We will be on the ground shortly. Thank you. DING Here he is at the Davenport airport, still busy looking at his maps: Every little airport we stopped at featured adults smiling at the boys. People enjoyed watching a dad and his kids flying somewhere together. Oliver kept busy too. He loves to help me on my pre-flight inspections. He will report every little thing to me a scratch, a fleck of paint missing on a wheel cover, etc. He takes it seriously. Both boys love to help get the plane ready or put it away. The Computers Jacob quickly gravitated towards a few interesting things. He sat for about half an hour watching this old Commodore plotter do its thing (click for video): His other favorite thing was the phones. Several people had brought complete analog PBXs with them. They used them to demonstrate various old phone-related hardware; one had several BBSs running with actual modems, another had old answering machines and home-security devices. Jacob learned a lot about phones, including how to operate a rotary-dial phone, which he d never used before! Oliver was drawn more to the old computers. He was fascinated by the IBM PC XT, which I explained was just about like a model I used to get to use sometimes. They learned about floppy disks and how computers store information. He hadn t used joysticks much, and found Pong ( this is a soccer game! ) interesting. Somebody has also replaced the guts of a TRS-80 with a Raspberry Pi running a SNES emulator. This had thoroughly confused me for a little while, and excited Oliver. Jacob enjoyed an old TRS-80, which, through a modern Ethernet interface and a little computation help in AWS, provided an interface to Wikipedia. Jacob figured out the text-mode interface quickly. Here he is reading up on trains. I had no idea that Commodore made a lot of adding machines and calculators before they got into the home computer business. There was a vast table with that older Commodore hardware, too much to get on a single photo. But some of the adding machines had their covers off, so the boys got to see all the little gears and wheels and learn how an adding machine can do its printing. And then we get to my favorite: the big iron. Here is a VAX a working VAX. When you have a computer that huge, it s easier for the kids to understand just what something is. When we encountered the table from the Glenside Color Computer Club, featuring the good old CoCo IIs like what I used as a kid (and have up in my attic), I pointed out to the boys that we have a computer just like this that can do these things and they responded wow! I think they are eager to try out floppy disks and disk BASIC now. Some of my favorites were the old Unix systems, which are a direct ancestor to what I ve been working with for decades now. Here s AT&T System V release 3 running on its original hardware: And there were a couple of Sun workstations there, making me nostalgic for my college days. If memory serves, this one is actually running on m68k in the pre-Sparc days: Returning home After all the excitement of the weekend, both boys zonked out for awhile on the flight back home. Here s Jacob, sleeping with his maps still up. As we were nearly home, we hit a pocket of turbulence, the kind that feels as if the plane is dropping a bit (it s perfectly normal and safe; you ve probably felt that on commercial flights too). I was a bit concerned about Oliver; he is known to get motion sick in cars (and even planes sometimes). But what did I hear from Oliver? Whee! That was fun! It felt like a roller coaster! Do it again, dad!

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In August, 140 work hours have been dispatched among 10 paid contributors. Their reports are available:

• Balint Reczey did 9.5 hours (out of 14.75 hours allocated + 2 remaining, thus keeping 7.25 extra hours for September).
• Ben Hutchings did 14 hours (out of 14.75 hours allocated + 0.7 remaining, keeping 1.45 extra hours for September).
• Brian May did 14.75 hours.
• Chris Lamb did 15 hours (out of 14.75 hours, thus keeping 0.45 hours for next month).
• Emilio Pozuelo Monfort did 13.5 hours (out of 14.75 hours allocated + 0.5 remaining, thus keeping 2.95 hours extra hours for September).
• Guido G nther did 9 hours.
• Markus Koschany did 14.75 hours.
• Ola Lundqvist did 15.2 hours (out of 14.5 hours assigned + 0.7 remaining).
• Roberto C. Sanchez did 11 hours (out of 14.75h allocated, thus keeping 3.75 extra hours for September).
• Thorsten Alteholz did 14.75 hours.

Evolution of the situation The number of sponsored hours rised to 167 hours per month thanks to UR Communications BV joining as gold sponsor (funding 1 day of work per month)! In practice, we never distributed this amount of work per month because some sponsors did not renew in time and some of them might not even be able to renew at all. The security tracker currently lists 31 packages with a known CVE and the dla-needed.txt file 29. It s a small bump compared to last month but almost all issues are affected to someone. Thanks to our sponsors New sponsors are in bold.

• Platinum sponsors:
• TOSHIBA (for 11 months)
• GitHub
• Gold sponsors:
• The Positive Internet (for 27 months)
• Blablacar (for 26 months)
• Linode LLC (for 16 months)
• Babiel GmbH (for 5 months)
• Plat Home (for 4 months)
• UR Communications BV
• Silver sponsors:
• Domeneshop AS (for 26 months)
• Universit Lille 3 (for 26 months)
• Trollweb Solutions (for 24 months)
• Nantes M tropole (for 20 months)
• University of Luxembourg (for 18 months)
• Dalenys (for 16 months)
• Univention GmbH (for 12 months)
• Universit Jean Monnet de St Etienne (for 12 months)
• Sonus Networks (for 6 months)
• Bronze sponsors:
• David Ayers IntarS Austria (for 27 months)
• Evolix (for 27 months)
• Offensive Security (for 27 months)
• Seznam.cz, a.s. (for 27 months)
• Freeside Internet Service (for 26 months)
• MyTux (for 26 months)
• Linuxhotel GmbH (for 24 months)
• Intevation GmbH (for 23 months)
• Daevel SARL (for 22 months)
• Bitfolk LTD (for 21 months)
• Megaspace Internet Services GmbH (for 21 months)
• Greenbone Networks GmbH (for 20 months)
• NUMLOG (for 20 months)
• WinGo AG (for 19 months)
• Ecole Centrale de Nantes LHEEA (for 16 months)
• Sig-I/O (for 13 months)
• Entr ouvert (for 11 months)
• Adfinis SyGroup AG (for 8 months)
• Laboratoire LEGI UMR 5519 / CNRS (for 3 months)
• Quarantainenet BV (for 3 months)
• GNI MEDIA

No comment Liked this article? Click here. My blog is Flattr-enabled.

There are many online sites that accept reading input from remote locations. For example a site might try to extract all the text from a webpage, or show you the HTTP-headers a given server sends back in response to a request. If you run such a site you must make sure you validate the schema you're given - also remembering to do that if you're sent any HTTP-redirects.

Really the issue here is a confusion between URL & URI.

The only time I ever communicated with Aaron Swartz was unfortunately after his death, because I didn't make the connection. I randomly stumbled upon the html2text software he put together, which had an online demo containing a form for entering a location. I tried the obvious input:

file:///etc/passwd

The software was vulnerable, read the file, and showed it to me. The site gives errors on all inputs now, so it cannot be used to demonstrate the problem, but on Friday I saw another site on Hacker News with the very same input-issue, and it reminded me that there's a very real class of security problems here. The site in question was http://fuckyeahmarkdown.com/ and allows you to enter a URL to convert to markdown - I found this via the hacker news submission. The following link shows the contents of /etc/hosts, and demonstrates the problem: http://fuckyeahmarkdown.example.com/go/?u=file:///etc/hosts&read=1&preview=1&showframe=0&submit=go The output looked like this:

..
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
127.0.0.1 stage
127.0.0.1 files
127.0.0.1 brettt..
..

In the actual output of '/etc/passwd' all newlines had been stripped. (Which I now recognize as being an artifact of the markdown processing.) UPDATE: The problem is fixed now.

What happened in the Reproducible Builds effort between Sunday September 4 and Saturday September 10 2016: Reproducible work in other projects Python 3.6's dictonary type now retains the insertion order. Thanks to themill for the report. In coreboot, Alexander Couzens committed a change to make their release archives reproducible. Patches submitted

• #836609 filed against nostalgy by Chris Lamb.
• #836605 filed against torque by Chris Lamb.
• #836968 filed against erlang-p1-oauth2 by Chris Lamb.
• #836970 filed against erlang-p1-sqlite3 by Chris Lamb.
• #836817 filed against tj3 by Chris Lamb.
• #836969 filed against erlang-p1-xmlrpc by Chris Lamb.

Reviews of unreproducible packages We've been adding to our knowledge about identified issues. 3 issue types have been added:

• random_id_in_pdf_generated_by_dblatex
• captures_execution_time
• captures_home_dir

1 issue type has been updated:

• Expand comment for random_id_in_pdf_generated_by_dblatex

16 have been have updated:

• Add patch for nostalgy
• Add patch for torque
• Expand comment for babl.
• Tag pbuilder with random_id_in_pdf_generated_by_dblatex
• Tag uclibc with users_and_groups_in_tarball
• Tag realmd with different_encoding_in_html_by_docbook_xsl
• Tag mrmpi with timestamps_in_documentation_generated_by_htmldoc
• Tag dynare with leaks_path_environment_variable
• Tag sdlgfx with timestamps_in_tarball
• Tag pantomime1.2 with plist_weirdness
• Tag blockattack with different_due_to_umask
• Tag expeyes with different_pot_creation_date_in_gettext_mo_files
• Tag android-platform-frameworks-data-binding with random_ordering_in_pom
• Tag krunner with users_and_groups_in_tarball
• Tag libevocosm with leaks_path_environment_variable
• Tag gdbm with random_order_in_md5sums

13 have been removed, not including removed packages:

• htp fixed in/since 1.19-2
• Remove openni-sensor-pointclouds and openni-sensor-primesense; fixed by __DATE__ & __TIME__
• hsqldb fixed in/since 2.3.3+dfsg2-1
• linux-tools RM
• ksnapshot RM
• cobalt-panel-utils RM
• strigi RM
• libkdeedu RM
• erc RM
• ttf-atarismall RM
• gnupg-doc RM
• remove RMed django-localflavor
• easymp3gain RM

100s of packages have been tagged with the more generic captures_build_path, and many with captures_kernel_version, user_hostname_manually_added_requiring_further_investigation, user_hostname_manually_added_requiring_further_investigation, captures_shell_variable_in_autofoo_script, etc. Particular thanks to Emanuel Bronshtein for his work here. Weekly QA work FTBFS bugs have been reported by:

• Aaron M. Ucko (1)
• Chris Lamb (7)

diffoscope development

• Mattia Rizzolo:
  • Force LC_ALL=C.UTF-8 in basic-command-list autopkgtest so that diffoscope can always output something
• Ximin Luo:
  • html-dir: use 4 * the given max-diff-block-lines
  • difference: Don't truncate diff output by default, and use a separate flag when doing so
  • html-dir: In html-dir output, split large diffs across several child pages
  • Rename no-max-limits to no-default-limits, a more accurate name
  • Increase default max_diff_input_lines, should be OK based on what we've seen
  • Fix behaviour for max-diff-block-limit=1 and don't report when 0 lines are removed
  • Set limits to inf when parsing args, instead of checking for "> 0" everywhere
  • Suppress decimal line numbers for xxd output

strip-nondeterminism development

• Chris Lamb:
  • handlers/jar.pm: Reintroduce subroutine prototype on _jar_filename_cmp to fix ordering regression in .jar files.
  • bin/strip-nondeterminism: die if file does not exist (Closes: #800159)
  • t/fixtures/jar/*: Add a testcase for jar file ordering and normalisation.
  • t/fixtures.t:
    • Check that output matches expected before comparing attributes to make it less confusing on failure.
    • Don't test whether inode number has changed either.
    • Add a lookup table for descriptions of stat(1) indices.
    • Re-order @fixtures setup for global->specific ordering.
    • Re-add top-level "plan" call dropped in previous commit.
    • Align size check with atime, etc.
    • Make it clearer that we are checking for attributes
    • Add comment why we use a per-fixture temporary directory.
  • Drop all calls to unlink_on_destroy now that we copy the file. (Closes: #836670)
  • Extend testsuite to ensure no extra files are leftover again.

tests.reproducible-builds.org:

• F-Droid:
  • Hans-Christoph Steiner found after extensive debugging that for kvm-on-kvm, vagrant from stretch is needed (or a backport, but that seems harder than setting up a new VM).
• FreeBSD:
  • Holger updated the VM for testing FreeBSD to FreeBSD 10.3.

Misc. This week's edition was written by Chris Lamb and Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

We have been making a lot of minor changes to lintian.d.o and the underlying report framework. Most of them were hardly noticeable to the naked. In fact, I probably would not have spotted any of them, if I had not been involved in writing them. Nonetheless, I felt like sharing them, so here goes. User visible changes:

• The generated reports are now in HTML5 rather than XHTML. [commit:9652c2e]
• Add alt texts to graphs for [commit:83434ec]
• Wrap front page index in a <nav> and reword link text so they can stand alone [commit:13993c8]
• Fix index of maintainer names, so characters outside [A-Z] always go at the end plus add a link directly to that section. [commit:70a24ed, commit:94eb258]
• Put the banner links in a <nav> [commit:baa77fc]
• Always create an index of packages on the individual maintainer pages [commit:124f9a8]
• Wrap the above-mentioned indices in a <nav> tag [commit:2ecea9b]
• Make the links in these indices self-contained [commit:bfc5292, commit:1043d4d]
• Fix mojibake in maintainer names [commit:e907388]

In case you were wondering, the section title is partly a pun as half of these changes were intended to assist visually impaired users. They were triggered by me running into Sam Hartmann at DebConf16, where I asked him about how easy Debian s websites were for blind people. Allegedly, we are generally doing quite good in his opinion (with one exception, for which Sam filed Bug#830213), which was a positive surprise for me. On a related note: Thanks Luke Faraone and Asheesh Laroia for getting helping me started on these changes. Reporting framework / Internal changes:

• Harness supports a no generate reports to make report generation optional. [commit:21fab0b]
• Reduced memory requirements for reports generation by ~15% [commit:534d169]
• Refactored reporting frontends to share the same bootstrap code as lintian/lintian-info ( dplint ) [commit:7d9a7d1, commit:97cf104, plus a bunch of refactoring leading up to those commits]
• Add sub-resource integrity fields in <link> tags [commit:27a367d]
• Add a Content-Security-Policy (via a <meta http-equiv>-tag) [commit:b022a39, commit:30bdc90]
• Support mirrors using Packages.xz files and without SHA1 fields [commit:d9cf314, commit:cb05f1d]
• Shuffle the lintian backlog to randomize the workload [commit:9b8873f]
• Stop lintian when the dead-line/run-time limit is exceeded [commit:7032be5, commit:7b3190d, commit:62532f8]

With the last change + the no generate reports option, we were able to schedule lintian more frequently. Originally, lintian only ran once a day. With the no generate reports , we added a second run and with the last changes, we bumped it to 4 times a day. Unsurprisingly, it means that we are now reprocessing the archive a lot faster than previously. All of the above is basically the all the note-worthy changes on the Lintian reporting framework since the Partial rewrite of lintian s reporting setup (~1 years ago).
Filed under: Debian, Lintian

From "Stop stealing dreams":

Settling for the not-particularly uplifting dream of a boring, steady job isn t helpful. Dreaming of being picked picked to be on TV or picked to play on a team or picked to be lucky isn t helpful either. We waste our time and the time of our students when we set them up with pipe dreams that don t empower them to adapt (or better yet, lead) when the world doesn t work out as they hope. The dreams we need are self-reliant dreams. We need dreams based not on what is but on what might be. We need students who can learn how to learn, who can discover how to push themselves and are generous enough and honest enough to engage with the outside world to make those dreams happen.

This made me think that I know many hero stories based on "the chosen", like Matrix, like most superheros getting powers either from some entity chosing them for it, or from chance. I have a hard time thinking of a superhero who becomes one just by working hard at acquiring and honing their skills: I can only think of Batman and Ironman, and they start off as super rich. If I think of people who start from scratch as commoners and work hard to become exceptional, in the standard superhero narrative, I can only think of supervillains. Scary. It makes me feel culturally biased into thinking that a common person cannot be trusted to act responsibly, and that only the rich, the chosen and the aristocrats can. As a bias it may serve the rich and the aristocrats, but I don't think it serves society as a whole.

Every year since 2010 the Whitley Bay Film Festival has put on a programme of movies in my home town, often with some quirk or gimmick. A few years back we watched "Dawn Of The Dead" in a shopping centre the last act was interrupted by a fake film-reel break, then a load of zombies emerged from the shops. Sometime after that, we saw "The Graduate" within a Church as part of their annual "Secret Cinema" showing. Other famous stunts (which I personally did not witness) include a screening of Jaws on the beach and John Carpenter's "The Fog" in Whitley Bay Lighthouse.

Massive thanks to Hunter North Recruitment for sponsoring Metropolis https://t.co/mphzHPCQ6O @snattaz pic.twitter.com/S9MNQmeLWZ Whitley Film Fest (@wbayfilmfest) August 14, 2016

This year I only went to one showing, Fritz Lang's Metropolis. Two twists this time: it was being shown in The Rendezvous Cafe, an Art-Deco themed building on the sea front; the whole film was accompanied by a live, improvised synthesizer jam by a group of friends and synth/sound enthusiasts who branded themselves "The Mediators" for the evening.

Metropolis live soundtrack preparations at the Rendezvous Cafe. Doors open 19.30 #metropolis pic.twitter.com/AdAqNVdEdx Whitley Film Fest (@wbayfilmfest) August 14, 2016

I've been meaning to watch Metropolis for a long time (I've got the Blu-Ray still sat in the shrink-wrap) and it was great to see the newly restored version, but the live synth accompaniment was what really made the night special for me. They used a bunch of equipment, most notably a set of Korg Volcas. The soundtrack varied in style and intensity to suit the scenes, with the various under-city scenes backed by a pumping, industrial-style improvisation which sounded quite excellent. I've had an interest in playing with synthesisers and making music for years, but haven't put the time in to do it properly. I left newly inspired and energised to finally try to make the time to explore it.

I bought a laptop with only SSD drives a while ago and based on a limited amount of reading, added the "discard" option to my /etc/fstab file for all partitions and happily went on my way expecting to avoid the performance degradation problems that happen on SSD cards without this setting). Yesterday, after a several month ordeal, I finally installed SSD drives in one of May First/People Link's servers and started doing more research to find the best way to set things up. I was quite surprised to learn that my change in /etc/fstab accomplished nothing. Well, not entirely true, my /boot partition was still getting empty sectors reported to the SSD card. Since my filesystem is on top of LVM and LVM is on top of an encrypted disk, those messages from the files system to the disk were not getting through. I learned that when I tried to run the fstrim command on one of the partitions and received the message that the disk didn't support it. Since my /boot partition is not in LVM or encrypted, it worked on /boot. I then made the necessary changes to /etc/lvm/lvm.conf and /etc/crypttab, restarted and... same result. Then I ran update-initramfs -u and rebooted and now fstrim works. I decided to remove the discard option from /etc/fstab and will set a cron job to run fstrim periodically. Also, I learned of some security implications of using trim on an encrypted disk which don't seem to outweigh the benefits.

debci 1.4 was released just a few days ago. Among general improvements, I would like to highlight:

• pretty much every place in the web UI that mentions a PASS or a FAIL also displays the tested package version. This was suggested to me on IRC by Holger
• I also tried to workaround an instability when setting up the LXC containers used for the tests, where the test bed process setup would finish without failure even though some steps in the middle of it failed. This caused the very final step for the debci-specific setup to fail, so there was no debci user inside the container, which caused tests to fail because that user was missing. Before that was fixed I was always keeping an eye on this issue, fixing the issue by hand, and re-triggering the affected packages by hand, so as far I can tell there is no package whose status has been permanently affected by this.
• Last, but not least, this release brings an interesting contribution by Gordon Ball, which is keeping track of different failure states. debci will now let you know whether a currently failing package has always failed, has passed in a previous version, or if the same version that is currently failing has previously passed.

ci.debian.net has been upgraded to debci 1.4 just after that. At the same time I have also upgraded autodep8 and autopkgtest to their latest versions, available in jessie-backports. This means that it is now safe for Debian packages to assume the changes in autopkgtest 4.0 are available, in special the $AUTOPKGTEST_* environment variables. In other news, for several weeks there were had issues with tests not being scheduled when they should have. I was just assuming that the issue was due to the existing test scheduler, debci-batch, being broken. Today I was working on a new implementation that is going to be a lot faster, I started to hit a similar issue on my local tests, and finally realized what was wrong. The fact is that debci-batch stores the timestamp of the last time a package has been scheduled to run, and it there are no test result after that timestamp, it assumes the package is still in the queue to be tested, and does not schedule it again. It turns out that a few weeks ago, during maintainance work, I had cleared the queue, discarding all jobs that were there, but forgot to reset those timestamps, so when debci-batch came around again, it checked the timestamp of the last request and did not make new requests because there was no test result after that timestamp! I cleared all those timestamps, and the system should now go back to normal. That is it for now. I you want to contribute to the Debian CI project and want to get in touch, you can pop up on the #debci channel on the OFTC IRC network, or mail the autopkgtest-devel mailing list.

sunweaver sighs... This short post is to inform all Debian MATE users that the recent GTK-3+ upload to Debian (GTK-3+ v3.21) broke most parts of the MATE 1.14 desktop environment as currently available in Debian testing (aka stretch). This raises some questions here on the MATE maintainers' side... Questions

1. Isn't GTK-3+ a shared library? This one was rhetorical... Yes, it is.
2. One that breaks other application with every point release? Well, unfortunately, as experience over the past years has shown: Yes, this has happened several times, so far and it happened again.
3. Why is it that GTK-3+ uploads appear in Debian without going through a proper transition? This question is not rhetorical. If someone has an answer, please enlighten me.

Potential Counter Measures For Debian MATE users running on Debian testing: This is untested, but it is quite likely that your MATE desktop environment will work again, once you have reverted your GTK-3+ library back to v3.20. For obtaining old Debian package versions, please visit the https://snapshots.debian.org site. Prospective The MATE 1.16 release is expected for Sep 20th, 2016. We will do our best to provide MATE 1.16 in Debian before this month is over. MATE 1.16 will again run smoothly (so I heard) on GTK-3+ 3.21.
light+love
sunweaver (who is already scared of the 3.22 GTK+ release, luckily the last development release of the GTK+ 3-series)

What happened in the Reproducible Builds effort between Sunday August 28 and Saturday September 3 2016: Media coverage Antonio Terceiro blogged about testing build reprodubility with debrepro . GSoC and Outreachy updates The next round is being planned now: see their page with a timeline and participating organizations listing. Maybe you want to participate this time? Then please reach out to us as soon as possible! Packages reviewed and fixed, and bugs filed The following packages have addressed reproducibility issues in other packages:

• ruby-ronn/0.7.3-5 by Antonio Terceiro, original patch by Chris Lamb.

The following updated packages have become reproducible in our current test setup after being fixed:

• check-all-the-things/2016.09.03 by Paul Wise, original patch by Chris Lamb.
• e2fsprogs/1.43.2-2 by Theodore Y. Ts'o.
• gnupg1/1.4.21-1 by Daniel Kahn Gillmor, #834755 by Chris Lamb.
• gnupg2/2.1.15-2 by Daniel Kahn Gillmor.
• inform6-compiler/6.33-2 by Ben Finney.
• libhat-trie/0.0~git25f9e946-2 by Sascha Steinbiss.
• mrd6/0.9.6-13 by Thomas Preud'homme, original patch by Reiner Herrmann.
• safecat/1.13-3 by Teemu Hukkanen, original patch by Reiner Herrmann.
• shibboleth-sp2/2.6.0+dfsg1-1 by Ferenc W gner.
• sweethome3d-furniture-editor/1.15-2 by Markus Koschany, original patch by Reiner Herrmann.
• traceroute/1:2.1.0-2 by Laszlo Boszormenyi, original patch by Reiner Herrmann.
• wise/2.4.1-19 by Sascha Steinbiss.
• xmltooling/1.6.0-2 by Ferenc W gner.

The following updated packages appear to be reproducible now, for reasons we were not able to figure out yet. (Relevant changelogs did not mention reproducible builds.)

• comitup/0.5-1 by David Steele.
• dita-ot/1.5.3-2 by Mathieu Malaterre.
• dput/0.10.2 by Ben Finney.
• gnome-settings-daemon/3.21.90-2 by Michael Biebl.
• libkf5kipi/4:16.08.0-1 by Pino Toscano.
• libmpc/2:0.1~r475-2 by James Cowgill.
• taurus/4.0.1+dfsg-1 by Picca Fr d ric-Emmanuel.
• tcpwatch-httpproxy/1.3.1-2 by Toni Mueller.

The following 4 packages were not changed, but have become reproducible due to changes in their build-dependencies:

• djangorestframework
• roarplaylistd
• zope-maildrophost
• zope-replacesupport

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

• amanda/1:3.3.9-1 by Jose M Calhariz.
• dispcalgui/3.1.6.0-2 by Christian Marillat, original patch by Chris Lamb.
• fastqtl/2.184+dfsg-4 by Dylan A ssi.
• grass/7.0.5~rc1-1~exp1 by Bas Couwenberg.
• kdevplatform/5.0-1 by Pino Toscano, original patch by Scarlett Clark.
• leveldb/1.19-1 by Alessio Treglia.
• libdevel-cover-perl/1.23-2 by gregor herrmann, original patch by Chris Lamb.
• linux/4.7.2-1 by Ben Hutchings, #830268 by Reiner Herrmann.
• lmms/1.1.3-4 by Javier Serrano.
• mayavi2/4.4.3-2.2 by Anton Gladky.
• opensaml2/2.6.0-2 by Ferenc W gner.
• perl/5.22.2-4 by Dominic Hargreaves, original patch and original patch by Chris Lamb.
• radare2/0.10.5+dfsg-1 by Sebastian Reichel, original patch by Chris Lamb.
• splint/3.1.2.dfsg1-3 by Rapha l Hertzog, original patch by Chris Lamb.

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

• #835673 filed against dacs by Chris Lamb.
• #835805 filed against dh-python by Chris Lamb.
• #835985 filed against nmh by Chris Lamb.
• #836609 filed against nostalgy by Chris Lamb.
• #835807 filed against pygtksourceview by Chris Lamb.
• #836004 filed against python-gflags by Chris Lamb.
• #835816 filed against rt-extension-customfieldsonupdate by Chris Lamb.
• #835834 filed against ruby-compass by Chris Lamb.
• #836605 filed against torque by Chris Lamb.
• #833176 filed against trafficserver by Reiner Herrmann.

Reviews of unreproducible packages 706 package reviews have been added, 22 have been updated and 16 have been removed in this week, adding to our knowledge about identified issues. 5 issue types have been added:

• timestamps_in_documentation_generated_by_ocamldoc
• timestamp_in_enc_files_added_by_texlive_fontinst
• cython_captures_build_path
• timestamps_in_perllocal_pod_manpages_generated_by_perl_extutils_mm_unix
• uname_output_in_python_debugging_symbols_caused_by_sysconfig_getplatform

1 issue type has been updated:

• timestamp_in_enc_files_added_by_texlive_fontinst

Weekly QA work FTBFS bugs have been reported by:

• Chris Lamb (8)
• Lucas Nussbaum (3)

diffoscope development diffoscope development on the next version (60) continued in git, taking in contributions from:

• Mattia Rizzolo:
  • Better and more thorough testing
  • Improvements to packaging
  • Improvements to the ppu comparator

strip-nondeterminism development Mattia Rizzolo uploaded strip-nondeterminism 0.023-2~bpo8+1 to jessie-backports. A new version of strip-nondeterminism 0.024-1 was uploaded to unstable by Chris Lamb. It included contributions from:

• Chris Lamb:
  • Improve code quality of zip, jar, ar, png processors
• AYANOKOUZI, Ryuunosuke:
  • Preserve file attribute information of target file (#836075)

Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches. disorderfs development Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches. tests.reproducible-builds.org Debian: We now vary the GECOS records of the two build users. Thanks to Paul Wise for providing the patch. Misc. This week's edition was written by Ximin Luo, Holger Levsen & Chris Lamb and reviewed by a bunch of Reproducible Builds folks on IRC.

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Android, Java, Games and LTS topics, this might be interesting for you. Debian Android

• This was the final month of the Google Summer of Code and the students achieved the main goal of packaging the Android SDK. It is now possible to build Android apps on Debian with packages only from the main distribution (apt install android-sdk). Chirayu Desai fixed the last remaining issue in android-platform-system-core (#827216). That also means apktool is now ready to rebuild Android applications. You can find more information about the students work at wiki.debian.org and on their individual pages Chirayu Desai, Kai-Chung Yan and Mouaad Aallam.
• I sponsored a new upstream release (2.2.0) of apktool for Chirayu Desai.
• I also reviewed and sponsored the following packages for Kai-Chung and Chirayu Desai (RC bug fixes and new upstream releases): android-platform-dalvik, android-platform-frameworks-base, android-sdk-meta.

Debian Games

• I started the month with package updates for foobillardplus, tuxpuck, etw, cube2, cube2-data and neverball.
• I released a new revision of triplane to fix a reproducible build issue.
• I packaged a new upstream release of springlobby.
• I fixed GCC-6 FTBFS bugs in stormbaancoureur and love and updated both packages to use modern Debian helpers (stormbaancoureur needed it badly).
• I invested some time to package Liquidwar 6 (#680023) and attached my preliminary work to the bug report. Liquidwar 6 has been in the works for a long time now and is a complete rewrite of the original Liquidwar game. The graphics are much more polished and dozens of new levels are available. I didn t complete my work on Liquidwar 6 because, at least on my system, the game constantly consumes 100% CPU time. Network modus isn t finished yet and it still depends on SDL 1. Nowadays I m only interested in SDL 2 (or similar) games though because I think the library is more future-proof and SDL 1 will probably become a burden for future maintainers.
• In the second half of the month I fixed a couple of RC bugs again caused by the Boost 1.61 transition and yes still more GCC-6 bugs : libclaw (GCC-6 and Boost 1.61 issues, new upstream release), freeorion (Boost 1.61 FTBFS, #833773. This one was arguably a regression in Boost 1.61 and I filed #833794 because of it), pokerth (GCC-6 RC bugs. I also took the opportunity to implement systemd support for pokerth-server and I modified the package to run the server as the _pokerth system user out-of-the-box.), 0ad (missing build-dependency on python).
• Even music packages can pile up bug reports, so I went ahead and updated fretsonfire-songs-muldjord and fretsonfire-songs-sectoid.
• In the last days of August 2016 I packaged a new upstream release of redeclipse and redeclipse-data, a first-person shooter. The older version was network-incompatible and long unsupported.

Debian Java

• I packaged new upstream releases of libjide-oss-java, undertow, jboss-xnio, hawtjni.
• I fixed RC bugs in libfreemaker-java, airlift-slice, japi-compliance-checker (was already fixed by Emmanuel Bourg but never uploaded), lucene2, libbtm-java, javassist, commons-math, libslf4j-java, surefire, maven-invoker, maven-scm and sweethome3d-furniture-editor.
• I triaged RC bug #834744 in xmlgraphics-commons and lowered the severity because the build failure was not reproducible in a clean cowbuilder environment. Another RC bug was reported against mina2 but I also couldn t reproduce the test failure hence I lowered the severity and marked #834682 as unreproducible.
• Another RC bug was reported against bookkeeper, #835277, allegedly the issue was caused by a missing artifact. After some investigation it turned out that the recent update of libprotobuf-java, one of bookkeeper s build-dependencies, used the wrong pom.xml and thus different Maven coordinates for the artifact. I filed #835358 and later #835514 against libprotobuf-java and both issues got resolved quickly.
• I reported #835354 against libitext-java because the package was uninstallable.
• I sponsored a new upstream release of freeplane for Felix Natter.

Debian LTS This was my seventh month as a paid contributor and I have been paid to work 14,75 hours on Debian LTS, a project started by Rapha l Hertzog. In that time I did the following:

• From 01. August to 07. August I was in charge of our LTS frontdesk. I triaged CVEs in wordpress, mysql-5.5, libsys-syslog-perl, libspring-java, curl and squid and answered questions on the debian-lts mailing list.
• DLA-586-1. Issued a security update for curl fixing 2 CVE.
• DLA-585-1. Announced the security update for firefox-esr which was prepared by Mike Hommey.
• I was involved in an embargoed security issue that currently affects two source packages in Wheezy. The update will be released on 15. September 2016 and will be coordinated with Debian s Security Team and other distributions. I will add more information next month.
• DLA-610-1. I spent most of the time this month on triaging and fixing security issues in tiff3, a library providing support for the Tagged Image File Format (TIFF). 99 source packages currently build-depend on this library in Wheezy. In total I triaged 35 CVEs and fixed 23 of them. I could confirm that CVE-2015-1547, CVE-2016-5322, CVE-2016-5314, CVE-2016-5315, CVE-2016-5316, CVE-2016-5317 and CVE-2016-5320 were duplicates of other CVEs fixed in this update. The update hardened the library and fixed possible denial-of-service (application crash) and arbitrary code execution issues. I tested whenever possible against the provided reproducers (malicious tiff images). The tiff3 package now includes all currently available patches. Most of the current open vulnerabilities do not directly affect end-users since no binary package has been provided for the tiff tools in Wheezy. However they can still pose a threat to people who build these tools from source manually. Though the majority of users should not be affected. It is also unlikely that the remaining issues will be fixed by tiff s upstream developers since they decided to remove the affected applications from newer releases but again most of them can t be exploited since the tools are not built by default in this version.

Non-maintainer uploads

• I did a NMU for pacman fixing one GCC-6 RC bug.

QA

• I packaged a new upstream release of pygccxml and worked around a RC bug that threatened to remove spring. For similar reasons I filed #835121 against castxml that got quickly fixed by Gert Wollny.

Debian LTS August marked the sixteenth month I contributed to Debian LTS under the Freexian umbrella. I spent 9 hours (of allocated 8) mostly on Rails related CVEs which resulted in DLA-603-1 and DLA-604-1 fixing 6 CVEs and marking others as not affecting the packages. The hardest part was proper testing since the split packages in Wheezy don't allow to run the upstream test suite as is. There's still CVE-2016-0753 which I need to check if it affects activerecord or activesupport. Additionally I had one relatively quiet week of LTS frontdesk work triaging 10 CVEs. Other Debian stuff

• I uploaded git-buildpackage 0.8.2 to experimental and 0.8.3 to unstable. The later bringing all the enhanements and bugfixes since Debconf 16 to sid and testing.
• The usual bunch of libvirt related uploads

A masterpiece by Yukio Mishima Patriotism the story of love and dead. A short story about the double suicide of a Lieutenant and his wife following the Ni Ni Roku Incident where some parts of the military tried to overthrow government and military leaders. Although Lieutenant Takeyama wasn t involved into the coup, because his friends wanted to safeguard him and his new wife, he found himself facing a fight and execution of his friends. Not being able to cope with this situation he commits suicide, followed by his wife.
Written in 1960 by one of the most interesting writers of Japanese modern history, Yukio Mishima, this book and the movie made by Mishima himself, are very disturbing images of the relation between human and state. Although the English title says Patriotism, the Japanese one is (Yukoku) which is closer to Concern for one s own country. This concern, and the feeling of devotion to the Imperial system and the country that leads the two into their deed. We are guided through the whole book and movie by a large scroll with (shisei, devotion) written on it. But indeed, Patriotism is a good title I think one of the most dangerous concepts mankind has brought forth. If Patriotism would be only the love for one s own country, all would be fine. But reality shows that patriotism unfailingly brings along xenophobia and the feeling of superiority. For someone coming from a small and unimportant country, I never had even the slightest allure to be patriotic in the bad sense. And looking at the world and people around me, I often have the feeling that mainly big countries produce the biggest and worst style of patriotism. This is obvious in countries like China, but having recently learned that all US pupils have to recite (obviously without understanding) the Pledge of Allegiance, the shock of how bad patriotism can start washing the brains of even the smallest kids in a seemingly free country is still present. But back to the book: Here the patriotism is exhibited by the presence of the Imperial images and shrine in the entrance, in front of which the two pray the last time before executing themselves. Not only the book is a masterpiece by itself, also the movie is a special piece of art: Filmed in silent movie style with text inserts, the whole story takes place on a Noh stage. This is in particular interesting as Mishima was one of the few, if not the only, modern Noh play writer. He has written several Noh plays. Another very impressive scene for me was when, after her husbands suicide, Reiko returns from putting up her final make-up into the central room. Her kimono is already blood soaked and the trailing kimono leaves traces on the Noh stage resembling the strokes of a calligraphy, as if her movement is guided, too, by . The final scene of the movie shows the two of them in a Zen stone garden, forming the stone, the unreachable island of happiness. Very impressive, both the book as well as the movie.

Debian LTS August marked the sixteenth month I contributed to Debian LTS under the Freexian umbrella. I spent 9 hours (of allocated 8) mostly on Rails related CVEs which resulted in DLA-603-1 and DLA-604-1 fixing 6 CVEs and marking others as not affecting the packages. The hardest part was proper testing since the split packages in Wheezy don't allow to run the upstream test suite as is. There's still CVE-2016-0753 which I need to check if it affects activerecord or activesupport. Additionally I had one relatively quiet week of LTS frontdesk work triaging 10 CVEs. Other Debian stuff

• I uploaded git-buildpackage 0.8.2 to experimental and 0.8.3 to unstable. The later bringing all the enhanements and bugfixes since Debconf 16 to sid and testing.
• The usual bunch of libvirt related uploads

The Haskell minicourse at the University of Pennsylvania, also known as CIS-194, has always had a reach beyond the students of Penn. At least since Brent Yorgey gave the course in 2013, who wrote extensive lecture notes and eventually put the material on Github. This year, it is my turn to give the course. I could not resist making some changes, at least to the first few weeks: Instead of starting with a locally installed compiler, doing execises that revolve mostly around arithmetic and lists, I send my students to CodeWorld, which is a web programming environment created by Chris Smith¹. This greatly lowers the initial hurlde of having to set up the local toolchain, and is inclusive towards those who have had little expose to the command line before. Not that I do not expect my students to handle that, but it does not hurt to move that towards later in the course. But more importantly: CodeWorld comes with a nicely designed simple API to create vector graphics, to animate these graphics and even create interactive programs. This means that instead of having to come up with yet another set of exercieses revolving around lists and numbers, I can have the students create Haskell programs that are visual. I believe that this is more motivating and stimulating, and will nudge the students to spend more time programming and thus practicing. In fact, the goal is that in their third homework assignemnt, the students will implement a fully functional, interactive Sokoban game. And all that before talking about the built-in lists or tuples, just with higher order functions and custom datatypes. (Click on the picture above, which is part of the second weeks s homework. You can use the arrow keys to move the figure around and press the escape key to reset the game. Boxes cannot be moved yet -- that will be part of homework 3.) If this sounds interesting to you, and you always wanted to learn Haskell from scratch, feel free to tag along. The lecture notes should be elaborate enough to learn from that, and with the homework problems, you should be able to tell whether you have solved it yourself. Just do not publish your solutions before the due date. Let me know if you have any comments about the course so far. Eventually, I will move to local compilation, use of the interpreter and text-based IO and then start using more of the material of previous iterations of the course, which were held by Richard Eisenberg in 2014 and by Noam Zilberstein in 2015.

The seventh update in the 0.12.* series of Rcpp just arrived on the CRAN network for GNU R as well as in Debian. This 0.12.7 release follows the 0.12.0 release from late July, the 0.12.1 release in September, the 0.12.2 release in November, the 0.12.3 release in January, the 0.12.4 release in March, the 0.12.5 release in May, and the 0.12.6 release in July --- making it the eleventh release at the steady bi-montly release frequency. Keeping with the established pattern, this is again more of a maintenance release which addresses small bugs, nuisances or documentation issues without adding any major new features. One issue that got to a few people was our casual use of NORET in the definition of Rcpp::stop(). We had (ahem) overlooked that NORET is only defined by R 3.2.0 or later, and several folks trying to build on older releases of R (why?) got bitten. Well, at least we have a new record for most frequently reported bug ... Kidding aside, this is now fixed. Rcpp has become the most popular way of enhancing GNU R with C or C++ code. As of today, 759 packages on CRAN depend on Rcpp for making analytical code go faster and further. That is up by well over fifty packages since the last release in mid-July! We are once again fortunate to have a number of pull request, from first-timers to regulars. James "coatless" Balamuta in particular relentlessly pushed for better documentation and cleanup of numerous dangling issue tickets. Artem Klevtsov also contributed again. Qiang, Kevin and I also got some changes in for the Rcpp Core team. More details are again below.

Changes in Rcpp version 0.12.7 (2016-09-04)

• Changes in Rcpp API:
  • The NORET macro is now defined if it was not already defined by R itself (Kevin fixing issue #512).
  • Environment functions get() & find() now accept a Symbol (James Balamuta in #513 addressing issue #326).
  • Several uses of Rf_eval were replaced by the preferred Rcpp::Rcpp_eval (Qiang in PR #523 closing #498).
  • Improved Autogeneration Warning for RcppExports (James Balamuta in #528 addressing issue #526).
  • Fixed invalid C++ prefix identifiers in auto-generated code (James Balamuta in #528 and #531 addressing issue #387; Simon Dirmeier in #548).
  • String constructors now set default UTF-8 encoding (Qiang Kou in #529 fixing #263).
  • Add variadic variants of the RCPP_RETURN_VECTOR and RCPP_RETURN_MATRIX macro when C++11 compiler used (Artem Klevtsov in #537 fixing #38).
• Changes in Rcpp build system
  • Travis CI is now driven via run.sh from our fork, and deploys all packages as .deb binaries using our PPA where needed (Dirk in #540 addressing issue #517).
• Changes in Rcpp unit tests
  • New unit tests for random number generators the R namespace which call the standalone Rmath library. (James Balamuta in #514 addressing issue #28).
• Changes in Rcpp Examples:
  • Examples that used cxxfunction() from the inline package have been rewritten to use either sourceCpp() or cppFunction() (James Balamuta in #541, #535, #534, and #532 addressing issue #56).

Thanks to CRANberries, you can also look at a diff to the previous release. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads page, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

Wow, a mouthful of a title, for a much simpler post. Up until earlier this year, I had only one sport GPS device, and that was a watch. Made sense, as my "main" sport was running (not that I did it very consistently). Upgraded over a few generations of Garmins, I mainly used it to record my track and statistics (pace, heart rate, etc.) The newest generation of watch and heart rate monitor even give more statistics (left-right leg balance, ground contact time, so on). Most of this data can be looked at while running, but only as an exception; after all, it's very hard to run with one hand up in front of your face. The other useful features guided workouts and alerts during normal runs I've used, but not consistently. So when I started biking a bit more seriously, I wondered whether it would make sense to buy a bike computer. The feature intersection between watch and bike GPS is quite large, so clearly this is a "want" not a "need" by far. Reading forum posts showed the same question repeated multiple times What convinced me to nevertheless buy such a bike GPS were the mapping/routing features. A bike GPS with good routing features, or even just maps on which tracks can be overlayed, can certainly ease the discovery of new routes. After a few months of use, my most useful feature is one that I didn't expect. While the mapping is useful and I do use it, the one that actually is significantly better than my watch is the large display with data fields that I can trivially check almost continuously on road biking, and during technically easy climbing sections for mountain biking. My setup looks like this: It's a 9-field setup; the Edge 1000 can go to 10, but I like "headline" field. The watch can only go to four, and is basically not usable during rides, unless one would use a quick-release kit for mounting on the handle bar. This setup allowed me to learn much better my physical capabilities, why I sometimes run out of energy, and how the terrain affects me. Random things that I learned:

• Gradient: on a road bike, +2% grade is just fun, -2% grade is excellent; on a mountain bike, -2% is somewhat felt but not so much. Going above 6-8% on a mountain bike is tiring, and above 15% means I can bike but I will dip too much into my reserves. Not sure yet what the numbers are on a road bike
• Cadence: on flatter routes, my most efficient cadence is 102-108 RPM; between 98-102 I feel I need to extra push, and below 98 I know (now) my muscles will get tired too early; on significant ascents, I don't have enough gearing to sustain such an RPM, and that tires me faster. On medium distance flat rides (~70Km), I usually do ~100 averaged over the whole distance.
• Heart rate: below ~140 is recovery, ~140-150 is sustained effort, ~150-160 is short-duration pushes, and anything above ~160 will eat through my anaerobic budget, which means I'd better stop soon or my performance for the rest of the ride will suffer; this, surprisingly, matches quite well with my latest run lactate threshold (as computed by my watch), which was 161bpm.
• Condition: when cruising without pedalling or when stopping, I can ballpark my current condition very easily by seeing how fast my heart rate goes down.
• Total ascent: useful for two things: to make me proud how much I've already climbed, and if I know the total ascent for the route either make me despair how much I have left, or make me happy that the climbs are done

Seeing all this data only after the ride is less useful since you don't remember exactly how you felt during specific points in the ride. But as real-time data, one can easily see/feel the correlation between how the body feels and what data says. One thing that would be also useful would be real-time power data (3 sec average, not instantaneous) to correlate even better with the body state. I now use heart rate and cadence as a proxy for that, but being able to see actual power numbers would increase the usefulness of the data even more. Unfortunately, none of these makes the climbs easier. But at least it allows me to understand why one climb feels hard and another easy (relatively speaking). I wonder if, and how this could be applied to running; maybe with smart glasses? Conclusion: yes, I do recommend a bike computer with a large display (to be able to see many fields at once). Just in case one has disposable income at hand and doesn't know which hobby to spend it on

FTP assistant This month I marked 257 packages for accept and rejected only 26. Seems to be that I mostly choosed the high quality packages this month. I also sent 12 emails to maintainers asking questions. Debian LTS This was my twenty-sixth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload has been 14.75h. Again, most of the time I choosed packages, where at the end the vulnerable code of the corresponding CVE was not present in the Wheezy version. So I could mark several CVEs for lshell and wget as not-affected, without doing an upload. Unfortunately I had to give up working on chicken. My scheme abilities appear to be rather rusty. Further, I uploaded a test version for php5 that takes care of 17 CVEs and as requested by the LTS users, two additional bugs. After all tests are passed, I will do a real upload with DLA. This month I also had another term of frontdesk work. Other stuff For the Alljoyn framework I fixed a compile issue with gcc 6 and could close RC-bugs
#831127, #831091, and #831198.
My patch was also accepted by upstream. Unfortunately a bug in gtest resulted in #833636. As gcc 6 is the default compiler now in testing, I could also close RC bug #831106.

Nationalpark Bike Marathon 2016 report: gravity rules! "Marathon" is a bit of a misnomer, since I did the short route, not the medium nor the long one. But hey, it's the official name! Setup This race has four possible lengths: "Valader" which is full round-trip Scuol-Scuol (137km/4'026m), "Jauer" (Fuldera-Scuol, 103km/2'934m), "Livignasco" (Livigno-Scuol, 66km/1'871m) and "Put r" (S-chanf to Scuol, 47Km/1'051m). After many debates, I settled on the Livignasco route, as that was what I was reasonably confident to be able to do. The only problem was that this route (and all the longer ones, of course) were going over Pass Chaschauna, which is a quite hard climb. My bike shop person, who did the full length a number of times, just said when hearing the route I was planning: "Chaschauna is a bitch " Bad language, proper characterisation. The route choice also impacts the logistics: except for the full route, the question is where to sleep the night before? One can sleep either at the start place, or sleep in Scuol itself and take the official shuttle to the start place, but this means waking up much earlier. I decided to sleep in Livigno, as with a 7:45 start this would allow me to sleep until ~6:30, have a quick breakfast and be in time for the race. Problem #1 So on Friday (26th) I drove to Scuol, picked up my start number, and then drove over to Livigno and checked in to the hotel. Speaking of picking up the start number, I saw this at the start area: An STI needed as pacer? How fast are these people, I wondered? Day of the race My plan to have a relaxing sleep until relatively late failed. I went to sleep with difficulties: late dinner due to my late arrival in Livigno, and then I was stressed enough about not missing the race that at 05:05 I already woke up, and was checking the clock every five minutes. Finally at 05:30 I gave up and got out of bed, with only about 6 hours of sleep. Problem #2. The other problem was that I na vely thought the hotel will have breakfast from 07:00 or even 07:30. Hah, as if this was Switzerland. The hotel had breakfast from 08:00, no reason to hurry, right? So I had a poor man's breakfast in the room, some energy bars and an ice tea. Problem #3. At least I had time to grab this picture from the hotel room: Not bad. On to the race! But before that, remember to fill my hydration pack with 3L of water, and put it in my not-so-light backpack. Of course I had tools and some spare parts with me, what if something happens? Problem #4, over-planning. The race The setup at the start was pretty easy. Wait near the start until 07:45, then go. For me, not too in front, of course: Pass Chaschauna About 3 kilometres of easy/flat road, and then it starts. Pass Chaschauna, killing your legs softly But at least the pictures were nice! The climb is difficult. It was around 22% for most of the time, and very few people were able to bike up. Not only the absolute meters were the problem, but also the fact that the ground was quite loose, and pushing the bike, or rather climbing up while pushing the bike, was difficult to do in bike shoes with cleats. Proper hiking shoes would have been much more adequate. Maybe this is why despite the effort, some people biked as much as possible? I was careful not to over-exert myself and walked almost all the way up. Hence the pictures But at last, reached the top of the pass, and was very happy to be done with it. The GPX file from my Garmin says it took only 4 minutes (1.2km) after the race start to actually start climbing (it was not obvious we were climbing so early), and then 1h:20m/8Km to get from 1'817m altitude to the highest point at 2'658m. 8Km in 1h:20m, faster than walking pace but quite slower than running pace (on flat terrain, of course). At the top of the pass I was quite happy: And then the descent started: All the way leading to the race I kept thinking only about climbing Chaschauna, and not about going down on it. It was quite an experience, which I won't forget soon. The trail was already well travelled, which means that besides the loose ground in form of large clumps of dried earth, there was a layer of fine, somewhat moist earth, about 3-5 centimetres deep, which made the downhill "interesting". Coupled with what was a much steeper trail than going up I saw most of the time ~33% it's no surprise that many, or even most, of the people were walking their bikes down. The GPX track says that the trail goes 319m down in 1Km (so a 31.9% over one entire kilometre), then another 130m over the next 1.4Km (9.28%), and then (not sure if this is the pass per se or after) another longer segment of ~260m over 3Km (8.56%). The first steep segment needs lots of skill and concentration, the others are normal gradients. But at least things go fast. What took uphill took ~40 minutes for the last 450m up, downhill it took only 15 minutes! Falling I was able, thanks to recent training, to bike down the trail, or at least I thought so. So on the steep segment I was struggling to bike down and keep control of my bike, putting one leg down on some sections but in general being "on the bike", being hit by the dirt I was throwing in the air despite the mud-guards, being careful but at the same time enjoying this difficult section. That is, right up to the point where I got, I think, too comfortable. After the second-to-last curve, the rear wheel slides, I lose balance and fall in the (thankfully soft) dirt a bit more forcefully than I should have, the bike also sliding along in the dirt. No damage to myself, just some trivial scratches; the bike seems a bit shaken (fork was turned 180 , full of dirt, etc.). I get again on the bike and I continue down; however, something seems off: the rear brake level doesn't have a return anymore, I have to push it to go back. Still usable, but strange. So I continue the other two segment of this descent, and over these ~4-5Km I feel the brake issue going worse and worse: it's actually hard to push the brake lever back, and even pressing it doesn't seem to have much effect. And then the realisation dawns on my: I have hydraulic brakes, and the worsening thing leads me to think my brake hose has been punctured (by what? I fell in loose dirt) and I'm losing the brake fluid with every press. Now, on flat road, biking with only the front brake is tricky but doable. On an MTB course, having only one brake is not a smart thing . Not easy, not smart, and definitely dangerous. It also felt very strange to not have both brakes, and then I realised how much I work with the brakes in unison. I knew that there are repair posts in the race, but I didn't know if they can fix such things (and doing a brake fluid refill how complicated is it, how much time does it take?). Anyway, I resolved to try and continue if the terrain allows until I reach the first repair post, and stop if it gets too steep. It would be pretty sad to have to abort the race after only 10Km, right? The terrain did cooperate: up and down, so I was able to bleed speed easily, and even though through forest, the visibility was good enough that I could plan ahead. It was strangely lonely at this time: I was going slowly and thus not reaching from behind anyone, but also not being reached by riders from behind. I did enjoy it a bit, the quietness of the forest, just interrupted by the squeaking of my front brake And then I finally see the sign for "Repair: 1Km". Yaaay! maybe I don't have to quit the race. And then, about 100m further on, another sign: "Danger! Steep descent". Uh-oh tantalisingly close Let's go slow. And yes, here I was overtaken by 3-4 other cyclists. This was the single moment in the race where I did have a moment of real fear: at one point, I was going down with the remaining brake as pressed as I could without compromising stability, and I was still gaining speed. Not smart, and as I was debating how to fall to stop my descent, the terrain started to get less steep, and I finally reached the repair station, at kilometre 21. Difficult repairs There was another person being serviced for a flat rear tire, so I wait in line and discuss with him my problem. Upon hearing I only had the front brake, he said: "Wow, how did you manage to descend this last segment?" "Well, slowly ". My turn came up, I explain my problem and my theory, and the repair guy gives me one look, the bike one look, but doesn't look at the brake hose. Instead, he looks once at the brake lever, sees that another cable guide on my handle bar was bent during the fall and actually was mechanically interfering with the brake lever, unbends that thing, and says "here you go". I was stunned. 15 seconds of looking at the problem without stress, and the problem was solved. I could have done this myself if I took the time to look and think, and not hurry. And I could have enjoyed all the downhill on the pass, with two functioning brakes. Some lessons have to be learned the hard way, and this was one. I got off easy though, as I didn't have a real accident while biking with only one brake. And they say you get wiser as you get older Anyway, brake repaired, I stopped at the Sanit r tent to have my scratches disinfected, and onwards. The following few kilometres until S-chanf I enjoyed very much. S-chanf And then, 2 hours 10 minutes into the race, I exit the forest trail, reach S-chanf, and start climbing and descending and climbing and descending. In the sun, which now (after 10 AM) is not that light anymore. The initial climb at S-chanf, while not much, took away my remaining short-term reserves. The route is 50m ascent, then down and then another 50m ascent, and after a bit of flat another 75m ascent I was getting tired, despite eating energy bars and drinking water (and juice at stops). This goes one for an entire hour, during which I cover about 23Km, so not a bad speed everything considered. But getting more and more tired. There were also some very nice segments, along the river, in the shade of the forest. Some fast downhill, some fast flat. I got overtaken by quite a few real racers, that were going so fast I couldn't keep up with them as in I didn't dare ride that fast even when I had the energy. Clearly they were from the longer segments, and boy were they fast! A number of couples (or pairs?) one woman one man, a number of bigger groups, all going as if they had E-bikes or super-powers, not just biking along tired like me Last climb And then, the last big climb: half an hour of going about 300m up (absolute values, so cumulative number would probably be higher), in the sun, over about 6Km, so only 5% average gradient. But I was tired and even resorted to walking on some portions At least I could take some pictures again: Or have pictures taken: Nice views: At one point, in a bit of a shade, I stop to catch my breath. Somebody else stopped as well and, seeing as I was checking my GPS, asks:

• "How much do we have left, about 10K?"
• I say yes (or was it 15K? the numbers don't match well)
• "And how about altitude?"
• "About 350m left "
• "Sigh "

I got overtaken by a lot of cyclists here, although many of them were from S-chanf route (based on the number colour). Sad The thing is, besides the climbing and the sun, this and the previous part was a very nice route: through small towns, high above the valley, beautiful landscapes, etc. Just enjoying it was hard, since I wasn't a) trained well enough and b) prepared well enough. Last segment, last downhill In any case, after that hard half hour, it's flat (or rather said, average gradient zero): Good road, good views, but I'm on the last virtual bar of my battery, so the remaining 15Km I do in 40 minutes, also "eating" the last ascent meters still about 300 left, I think, but up/down/up/down, so you could reuse kinetic energy to gain potential one. The only question I had now was, the route was at this moment about 400m higher (in absolute altitude) than the finish point, so when do we lose that altitude? The answer was a very very nice answer: in the last 5Km, for an average gradient of 8%, just perfect. I was tired however, so I couldn't really enjoy or go fast here, but it was a good feeling. Finish! And then, entering Scuol, not really believing I'm near the finish, that I will be able to actually stop and relax. My finish picture doesn't do justice to how happy I was at that moment: However, after passing the finish line, it was a bit weird. I just stop now? What next? So weird to just walk, not push pedals, and not go up. Or down. The funny thing here was that I thought I didn't use much of my water (hydration pack) during the race. But soon after finishing, I drank the equivalent of about two glasses (let's say 0.5L) and it was over. So I did manage to drink 2.5L during the race, plus the sport drinks at the stops. Time for stats: my Garmin says 67.07Km, 4h:29m, average speed 15.0kph (hah), 1'615m elevation gain. Official numbers say 66Km, 1'871m elevation, and thus 14.22kph. Ranking-wise:

• 147/192 in the overall men Livignasco route
• 44/60 in my age category

Sigh, could have done better. I was aiming for somewhere around last 33%, not last 25% First classed was ~66% faster than me Going to the train station was hard as in difficult to move my legs. Took one nice picture of Scuol though, so was able to think a bit: And then the long way back to Livigno. Took me 4 h to bike to Scuol, and about 3 hours to go back via public transport. At least I ate a sandwich in the meantime. Then reached Livigno, which was also looking nice: Then got on my bike, which at this point was magically light and easy to ride (it seems I was at least partially recovered), rode to the hotel, packed my stuff, and drove home. On the highway I had my first real meal for that day, but I was quite tired so didn't feel like the achievement it should have been Lessons The biggest takeaway from this race was the huge learning experience I got. The race was itself awesome, but the learning even more so. First, for this particular race, it's much better to sleep in Scuol and (if not doing the whole route) take the shuttle to the actual start. Yes, one has to wake up earlier, but you have assured breakfast via the organisers (++++!), and after the race you don't have to get even more tired by taking the train and the bus and Second, I need better logistics: I don't need to carry that heavy load (spare tube, pump, tools, jacket in case it's cold) when the race is well organised. The water in the hydration pack was useful, but carrying it up Chaschauna was a pain. Not sure what I'll do next; it's possible to survive only on water/drinks from the food posts (basically 2.5-2.8L is equivalent to only 4 750ml bottles, and there were I think about 6 stops?), but the hydration pack is so easy to use Keeping one's head cool and not stress about things also would help: had I looked at my brake lever in peace, I could have solved it myself, and not ride ~10Km with only one brake. Also, losing some weight (as in losing fat, not having a lighter bike) would definitely help. I could stand to lose 5Kg easily, probably 10Kg, and that would bring me more in line with other people in the race (at least looking at the pictures). And hey, my Watts/Kg would improve magically! And last but most important, I need better training. Training on how to use my energy, training longer rides so that my body gets used to it and doesn't bonk after 3 hours, training training training. Which I like, but the problem is time to do it Also, in case anybody wonders: yes, I do recommend this race! It was definitely fun, and the route itself is very nice, nicer than the pictures here show. Closing words: gravity rules. Up or down, it's hard and punishing. Still: Ride on!