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!

anytime just arrived on CRAN as a very first release 0.0.1. So why (yet another) package dealing with dates and times? R excels at computing with dates, and times. By using typed representation we not only get all that functionality but also of the added safety stemming from proper representation. But there is a small nuisance cost: How often have we each told as.POSIXct() that the origin is epoch '1970-01-01'? Do we have to say it a million more times? Similarly, when parsing dates that are in some recogniseable form of the YYYYMMDD format, do we really have to manually convert from integer or numeric or factor or ordered to character first? Having one of several common separators and/or date / time month forms (YYYY-MM-DD, YYYY/MM/DD, YYYYMMDD, YYYY-mon-DD and so on, with or without times, with or without textual months and so on), do we really need a format string? anytime() aims to help as a small general purpose converter returning a proper POSIXct (or Date) object nomatter the input (provided it was somewhat parseable), relying on Boost date_time for the (efficient, performant) conversion. See some examples on the anytime page or the GitHub README.md, or in the screenshot below. And then just give it try! For questions or comments use the issue tracker off 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.

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.

An interesting side problem in keysafe's design is that keysafe servers, which run as tor hidden services, allow anonymous data storage and retrieval. While each object is limited to 64 kb, what's to stop someone from making many requests and using it to store some big files? The last thing I want is a git-annex keysafe special remote. ;-) I've done a mash-up of three technologies to solve this, that I think is perhaps somewhat novel. Although it could be entirely old hat, or even entirely broken. (All I know so far is that the code compiles.) It uses proof of work, token buckets, and bloom filters.

---

Each request can have a proof of work attached to it, which is just a value that, when hashed with a salt, starts with a certain number of 0's. The salt includes the ID of the object being stored or retrieved. The server maintains a list of token buckets. The first can be accessed without any proof of work, and subsequent ones need progressively more proof of work to be accessed. Clients will start by making a request without a PoW, and that will often succeed, but when the first token bucket is being drained too fast by other load, the server will reject the request and demand enough proof of work to allow access to the second token bucket. And so on down the line if necessary. At the worst, a client may have to do 8-16 minutes of work to access a keysafe server that is under heavy load, which would not be ideal, but is acceptible for keysafe since it's not run very often. If the client provides a PoW good enough to allow accessing the last token bucket, the request will be accepted even when that bucket is drained. The client has done plenty of work at this point, so it would be annoying to reject it. To prevent an attacker that is willing to burn CPU from abusing this loophole to flood the server with object stores, the server delays until the last token bucket fills back up.

---

So far so simple really, but this has a big problem: What prevents a proof of work from being reused? An attacker could generate a single PoW good enough to access all the token buckets, and flood the server with requests using it, and so force everyone else to do excessive amounts of work to use the server. Guarding against that DOS is where the bloom filters come in. The server generates a random request ID, which has to be included in the PoW salt and sent back by the client along with the PoW. The request ID is added to a bloom filter, which the server can use to check if the client is providing a request ID that it knows about. And a second bloom filter is used to check if a request ID has been used by a client before, which prevents the DOS. Of course, when dealing with bloom filters, it's important to consider what happens when there's a rare false positive match. This is not a problem with the first bloom filter, because a false positive only lets some made-up request ID be used. A false positive in the second bloom filter will cause the server to reject the client's proof of work. But the server can just request more work, or send a new request ID, and the client will follow along. The other gotcha with bloom filters is that filling them up too far sets too many bits, and so false positive rates go up. To deal with this, keysafe just keeps count of how many request IDs it has generated, and once it gets to be too many to fit in a bloom filter, it makes a new, empty bloom filter and starts storing request IDs in it. The old bloom filter is still checked too, providing a grace period for old request IDs to be used. Using bloom filters that occupy around 32 mb of RAM, this rotation only has to be done every million requests of so. But, that rotation opens up another DOS! An attacker could cause lots of request IDs to be generated, and so force the server to rotate its bloom filters too quickly, which would prevent any requests from being accepted. To solve this DOS, just use one more token bucket, to limit the rate that request IDs can be generated, so that the time it would take an attacker to force a bloom filter rotation is long enough that any client will have plenty of time to complete its proof of work.

---

This sounds complicated, and probably it is, but the implementation only took 333 lines of code. About the same number of lines that it took to implement the entire keysafe HTTP client and server using the amazing servant library. There are a number of knobs that may need to be tuned to dial it in, including the size of the token buckets, their refill rate, the size of the bloom filters, and the number of argon2 iterations in the proof of work. Servers may eventually need to adjust those on the fly, so that if someone decides it's worth burning large quantities of CPU to abuse keysafe for general data storage, the server throttles down to a rate that will take a very long time to fill up its disk. This protects against DOS attacks that fill up the keysafe server storage. It does not prevent a determined attacker, who has lots of CPU to burn, from flooding so many requests that legitimate clients are forced to do an expensive proof of work and then time out waiting for the server. But that's an expensive attack to keep running, and the proof of work can be adjusted to make it increasingly expensive.

Today I had my invited talk at the Colloquium Logicum 2016, where I gave an introduction to and overview of the state of the art of G del Logics. Having contributed considerably to the state we are now, it was a pleasure to have the opportunity to give an invited talk on this topic. It was also somehow a strange talk (slides are available here), as it was my last as academic . After the rejection of extension of contract by the JAIST (foundational research, where are you going? Foreign faculty, where?) I have been unemployed not a funny state in Japan, but also not the first time I have been, my experiences span Austrian and Italian unemployment offices. This unemployment is going to end this weekend, and after 25 years in academics I say good-bye. Considering that I had two invited talks, one teaching assignment for the ESSLLI, submitted three articles (another two forthcoming) this year, JAIST is missing out on quite a share of achievements in their faculty database. Not my problem anymore. It was a good time in academics, and I will surely not stop doing research, but I am looking forward to new challenges and new ways of collaboration and development. I will surely miss academics, but for now I will dedicate my energy to different things in life. Thanks to all the colleagues who did care, and for the rest, I have already forgotten you.

Hopkins Trailer Brake Controller in Subaru Outback My minivan transmission gave up the ghost last year, so I bought a Subaru outback to pull my t@b travel trailer. There isn't a huge amount of space under the dash, so I didn't want to mount a trailer brake controller in the 'usual' spot, right above my right knee. Instead, I bought a Hopkins InSIGHT brake controller, 47297. That comes in three separate pieces which allows for very flexible mounting options. I stuck the 'main' box way up under the dash on the left side of the car. There was a nice flat spot with plenty of space that was facing the right direction: The next trick was to mount the display and control boxes around the storage compartment in the center console: Routing the cables from the controls over to the main unit took a piece of 14ga solid copper wire to use as a fishing line. The display wire was routed above the compartment lid, the control wire was routed below the lid. I'm not entirely happy with the wire routing; I may drill some small holes and then cut the wires to feed them through.

I have been sick for about 2 weeks now hence haven t written. I had joint pains and still am weak. There has been lot of reports of malaria, chikungunya and dengue fever around the city. The only thing I came to know is how lucky I am to be able to move around on 2 legs and how powerless and debilitating it feels when you can t move. In the interim I saw Me Before You and after going through my most miniscule experience, I could relate with Will Taylor s character. If I was in his place, I would probably make the same choices. But my issues are and were slightly different. Last month I was supposed to share my debconf experience in the local PLUG meet. For that purpose, I took some pictures from my phone on a pen-drive to share. But when reached the venue, found out that I had forgotten to take the pen-drive. What I had also done is used the mogrify command from the imagemagick stable to lossy compress the images on the pen-drive so it is easier on image viewers. But that was not to be and at the last moment had to use my phone plugged into the USB drive of the lappy and show some pictures. This was not good. I had known that it was mounted somewhere but hadn t looked at where. After coming back home, it took me hardly 10 minutes to find out where it was mounted. It is not mounted under /media/shirish but under /run/user/1000/gvfs . If I do list under it shows mtp:host=%5Busb%3A005%2C007%5D . I didn t need any packages under debian to make it work. Interestingly, the only image viewer which seems to be able to work with all the images is feh which is a command-line image viewer in Debian. [$] aptitude show feh
Package: feh
Version: 2.16.2-1
State: installed
Automatically installed: no
Priority: optional
Section: graphics
Maintainer: Debian PhotoTools Maintainers
Architecture: amd64
Uncompressed Size: 391 k
Depends: libc6 (>= 2.15), libcurl3 (>= 7.16.2), libexif12 (>= 0.6.21-1~), libimlib2 (>= 1.4.5), libpng16-16 (>= 1.6.2-1), libx11-6, libxinerama1
Recommends: libjpeg-progs
Description: imlib2 based image viewer
feh is a fast, lightweight image viewer which uses imlib2. It is commandline-driven and supports multiple images through slideshows, thumbnail
browsing or multiple windows, and montages or index prints (using TrueType fonts to display file info). Advanced features include fast dynamic
zooming, progressive loading, loading via HTTP (with reload support for watching webcams), recursive file opening (slideshow of a directory
hierarchy), and mouse wheel/keyboard control.
Homepage: http://feh.finalrewind.org/ I did try various things to get it to mount under /media/shirish/ but as of date have no luck. Am running Android 6.0 Marshmallow and have enabled USB debugging with help from my friend Akshat . I even changed the /etc/fuse.conf options but even that didn t work. #cat /etc/fuse.conf
[sudo] password for shirish:
# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE) # Set the maximum number of FUSE mounts allowed to non-root users.
# The default is 1000.
mount_max = 1 # Allow non-root users to specify the allow_other or allow_root mount options.
user_allow_other
One way which I haven t explored is adding/making an entry into /etc/fstab. If anybody knows of a solution which doesn t involve changing content of /etc/fstab. At the same time you are able to get the card and phone directories mounted under /media// , in my case /media/shirish would be interested to know. I would like the /etc/fstab to remain as it is. I am using Samsung J5 (unrooted) Btw I tried all the mtpfs packages in Debian testing but without any meaningful change Look forward to tips.
Filed under: Miscellenous Tagged: #Android, #Debconf16, #debian, #mptfs, feh, FUSE, PLUG

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.

Categories:

• Debian-Pages
• Debian-Blog
• Tools

Keywords:

• apt
• apt-offline
• debian

Like:

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.

as before, my work on release-critical bugs was centered around perl issues. here's the list of bugs I worked on:

• #687904 interchange-ui: "interchange-ui: cannot install this package"
  (re?)apply patch from #625904, upload to DELAYED/5
• #754755 src:libinline-java-perl: "libinline-java-perl: FTBFS on mips: test suite issues"
  prepare a preliminary fix (pkg-perl)
• #821994 src:interchange: "interchange: Build arch:all+arch:any but is missing build- arch,indep targets"
  apply patch from sanvila to add targets, upload to DELAYED/5
• #834550 src:interchange: "interchange: FTBFS with '.' removed from perl's @INC"
  patch to "require ./", upload to DELAYED/5
• #834731 src:kdesrc-build: "kdesrc-build: FTBFS with '.' removed from perl's @INC"
  add patch from Dom to "require ./", upload to DELAYED/5
• #834738 src:libcatmandu-mab2-perl: "libcatmandu-mab2-perl: FTBFS with '.' removed from perl's @INC"
  add patch from Dom to "require ./" (pkg-perl)
• #835075 src:libmail-gnupg-perl: "libmail-gnupg-perl: FTBFS: Failed 1/10 test programs. 0/4 subtests failed."
  add some debugging info
• #835133 libnet-jabber-perl: "libnet-jabber-perl: FTBFS in testing"
  add patch from CPAN RT (pkg-perl)
• #835206 src:munin: "munin: FTBFS with '.' removed from perl's @INC"
  add patch from Dom to call perl with -I., upload to DELAYED/5, then cancelled on maintainer's request
• #835353 src:pari: "pari: FTBFS with '.' removed from perl's @INC"
  add patch to call perl with -I., upload to DELAYED/5
• #835711 src:libconfig-identity-perl: "libconfig-identity-perl: FTBFS: Tests failures"
  run tests under gnupg1 (pkg-perl)
• #837136 libgtk3-perl: "libgtk3-perl: FTBFS: t/overrides.t failure"
  add patch from CPAN RT (pkg-perl)
• #837237 src:libtest-file-perl: "libtest-file-perl: FTBFS: Tests failures"
  add patch so tests find their common files again (pkg-perl)
• #837249 src:libconfig-record-perl: "libconfig-record-perl: FTBFS: lib/Config/Record.pm: No such file or directory at Config-Record.spec.PL line 13."
  fix build in debian/rules (pkg-perl)

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

Today, debhelper 10 was uploaded to unstable and is coming to a mirror near you really soon now . The actual changes between version 9.20160814 and version 10 are rather modest. However, it does mark the completion of debhelper compat 10, which has been under way since early 2012. Some highlights from compat 10 include:

• The dh sequence in compat 10 automatically regenerate autotools files via dh_autoreconf
• The dh sequence in compat 10 includes the dh-systemd debhelper utilities
• dh sequencer based packages now defaults to building in parallel (i.e. parallel is default in compat 10)
• dh_installdeb now properly shell-escapes maintscript arguments.

For the full list of changes in compat 10, please review the contents of the debhelper(7) manpage. Beyond that, you may also want to upgrade your lintian to 2.5.47 as it is the first version that knows that compat 10 is stable.
Filed under: Debhelper, Debian

gettz is now on CRAN in its initial release 0.0.1. It provides a possible fallback in situations where Sys.timezone() fails to determine the system timezone. That can happen when e.g. the file /etc/localtime somehow is not a link into the corresponding file with zoneinfo data in, say, /usr/share/zoneinfo. Duane McCully provided a nice StackOverflow answer with code that offers fallbacks via /etc/timezone (on Debian/Ubuntu) or /etc/sysconfig/clock (on RedHat/CentOS/Fedora, and rumour has it, BSD* systems) or /etc/TIMEZONE (on Solaris). The gettz micro-package essentially encodes that approach so that we have an optional fallback when Sys.timezone() comes up empty. In the previous paragraph, note the stark absense of OS X where there seems nothing to query, and of course Windows. Contributions for either would be welcome. For questions or comments use the issue tracker off 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.

I am happy to announce the release of OASIS v0.4.7. OASIS is a tool to help OCaml developers to integrate configure, build and install systems in their projects. It should help to create standard entry points in the source code build system, allowing external tools to analyse projects easily. This tool is freely inspired by Cabal which is the same kind of tool for Haskell. You can find the new release here and the changelog here. More information about OASIS in general on the OASIS website. Pull request for inclusion in OPAM is pending. Here is a quick summary of the important changes:

• Drop support for OASISFormat 0.2 and 0.1.
• New plugin "omake" to support build, doc and install actions.
• Improve automatic tests (Travis CI and AppVeyor)
• Trim down the dependencies (removed ocaml-gettext, camlp4, ocaml-data-notation)

Features:

• findlib_directory (beta): to install libraries in sub-directories of findlib.
• findlib_extra_files (beta): to install extra files with ocamlfind.
• source_patterns (alpha): to provide module to source file mapping.

This version contains a lot of changes and is the achievement of a huge amount of work. The addition of OMake as a plugin is a huge progress. The overall work has been targeted at making OASIS more library like. This is still a work in progress but we made some clear improvement by getting rid of various side effect (like the requirement of using "chdir" to handle the "-C", which leads to propage ~ctxt everywhere and design OASISFileSystem). I would like to thanks again the contributor for this release: Spiros Eliopoulos, Paul Snively, Jeremie Dimino, Christopher Zimmermann, Christophe Troestler, Max Mouratov, Jacques-Pascal Deplaix, Geoff Shannon, Simon Cruanes, Vladimir Brankov, Gabriel Radanne, Evgenii Lepikhin, Petter Urkedal, Gerd Stolpmann and Anton Bachin.

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.

Relatively quickly after version 0.4.5 of RProtoBuf was released, we have a new version 0.4.6 to announce which appeared on CRAN today. RProtoBuf provides R bindings for the Google Protocol Buffers ("Protobuf") data encoding and serialization library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects. This version contains a contributed bug-fix pull request covering conversion of zero-length vectors, and adding native support for S4 objects. At the request / suggestion of the CRAN maintainers, it also uncomments a LaTeX macro in the vignette (corresponding to our recent JSS paper paper) which older R versions do not (yet) have in their jss.cls file.

Changes in RProtoBuf version 0.4.6 (2016-09-08)

• Support for serializing zero-length objects was added (PR #18 addressing #13)
• S4 objects are natively encoded (also PR #18)
• The vignette based on the JSS paper no longer uses a macro available only with the R-devel version of jss.cls, and hence builds on all R versions

CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub issue tracker off 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.

A year ago I got tired of Jenkins and wrote a CI system for myself, Ick. It's served me well since, but it's a bit clunky and awkward and I have to hope nobody else wants to use it. I've been thinking about re-architecting Ick from scratch, and so I wrote down some of my thinking about this. It's very raw, but just in case someone else might be interested, I put it online at ick2. At this point I'm still thinking about very high level concepts. I've not written any code, and probably won't in the next couple of months. But I had to get this out of my brain.

Slightly belated... Another year, another OMGWTFBBQ. By my count, we had 49 people (and a dog) in my house and garden at the peak on Saturday evening. It was excellent to see people from all over coming together again, old friends and new. This year we had some weather issues, but due to the delights of gazebo technology most people stayed mostly dry. :-) Also: thanks to a number of companies near and far who sponsored the important refreshments for the weekend:

• Mythic Beasts
• Metail
• Collabora
• Codethink
• QvarnLabs

As far as I could tell, everybody enjoyed themselves; I know I definitely did!