For a few years I did not attempt any serious task on the Amazon cloud. It took me a bit of time to get back my automatisms and adapt myself to the changes. In particular, the cheapest instances, t2.nano, are only accessible via virtual private clouds (VPC), and it was a bit difficult for me to find how to create a simple one. Perhaps this is because all AWS accounts created after March 18, 2013, automatically have a default VPC, and everybody else who needed their own simple VPC have created it a long time ago already. In the end, this was not complicated at all. This is probably why I could not find a tutorial. In brief, one needs first to create a VPC. If it is just for spawning an instance from time to time, the IP range does not matter much. Default VPCs are using 172.31.0.0/16, so let's do the same.

CIDR_BLOCK=172.31.0.0/16
aws ec2 create-vpc --cidr-block $CIDR_BLOCK

In the command's output, there is the VPC's identifier, that I paste by hand in a variable called VPC. The same pattern will be repeated for each command creating something. One can also find the VPC's identifier with the command aws ec2 describe-vpcs.

VPC=vpc-XXXXXXXX

Then, create a subnet. Again, no need for complications, in our simple case one can give the full IP range. I cut and paste the returned identifier in the variable SUBNET. In order that the instances receive a public IP address like in default VPCs and like in the usual behaviour of the VPC-less Cloud, one needs to set the attribute MapPublicIpOnLaunch.

aws ec2 create-subnet --vpc-id $VPC --cidr-block $CIDR_BLOCK
SUBNET=subnet-XXXXXXXX
aws ec2 modify-subnet-attribute --subnet-id $SUBNET --map-public-ip-on-launch 

Then, create a gateway (paste the identifier in GATEWAY) and attach it to the VPC.

aws ec2 create-internet-gateway
GATEWAY=igw-XXXXXXXX
aws ec2 attach-internet-gateway --internet-gateway-id $GATEWAY --vpc-id $VPC

A routing table was created automatically, and one can find its identifier via the command describe-route-tables. Then, create a default route to the gateway.

aws ec2 describe-route-tables
ROUTETABLE=rtb-XXXXXXXX
aws ec2 create-route --route-table-id $ROUTETABLE --destination-cidr-block 0.0.0.0/0 --gateway-id $GATEWAY

Of course, if one does not open the traffic, no instance can be contacted from outside... Here I open port 22 for SSH.

aws ec2 describe-security-groups
SECURITY_GROUP=sg-XXXXXXXX
aws ec2 authorize-security-group-ingress --group-id $SECURITY_GROUP --protocol tcp --port 22 --cidr 0.0.0.0/0

Other novelty, now Amazon distributes some Free tools for the command line, that are more comprehensive than euca2ools. Next, I will try again the Debian Installer in the Cloud.

After finally being able to fix Debian bug #794266 I want to thank those who made this possible: Some time ago my colleague Bj rn offered an Arietta G25 to me. After Jochen, another colleague, helped me to solder pin headers on it, this machine served as host computer for my tests. As I didn't have a machine with the relevant RTC chip, I contacted Seiko Instruments and they provided me a few chips including oscillators. It was again Jochen who then created a break-out board from these components that I could wire to my Arietta board. Finally Wolfram Sang's i2ctransfer helped me a lot to access and so understand the chip. It's has not landed in i2c-tools.git, but I hope this will change soon given that this is a really useful tool. A big thank you to all who helped me. It was fun and would have been less so without your efforts!

A week has gone by and another small sharing about Doha and one package that quite a few of us use everyday but don t think much of them. Let s start with Doha with these two pictures which tells/shares a bit about what the Doha of today is like While I have more than a dozen snapshots of Doha, all of them show same thing, all are huge skyscrapers and overall Doha seems to be aping Dubai and is in a frenzy as World Cup 2022 is around the corner. We did see a few of the older places but these seemed to be more done for tourists rather than the real thing. We saw stuff like This was a picture taken by Ritesh Raj Saraff, a friend and a DD whom I met while I was going to Debconf. The place where this picture has been taken is known as a Souk or what we know as market-place. This was a place where you could get spices. Quite a few of the spices that we get and use in India were bought from Middle-East in the olden times. In fact, it has been argued that the whole Mughlai food that is part of Indian culture was imported from Middle-East when we were trading them before India or Akhand Bharat was invaded. What was interesting to both of us is that we could perceive that most of the buildings had a sort of fakeness to it, they tried to show that it had a lot of detailed work on the buildings but we could see it was all done recently so not that old as being led to believe. One of the other interesting bits that we came to know throughout our stay in Qatar that almost 80-90% of the staff we met inside Qatar airport as well as in the Souk were people from Asian sub-continent and more specifically from South India. I had few interesting conversations with some of the people who were managing the shops were that almost of them were just employees while the owners were Qataris . I could understand this as the distance and flight between Qatar and India is hardly 3 hours. It seemed very similar to how Mexicans look for work in United States. The most expensive thing there was water as it s desert other than housing and most workers seemed to have shared accommodation from anywhere between 5-15 people in one room. It s only the relative strength of the Qatari Rial which probably compels them to be there. The temperature was around 45 degrees with a bit of humidity as it s next to the Ocean. For all the money in the world, I wouldn t work there. It is true that you know your city s worth only when you go outside I do have some more stories about Qatar but that would have to wait for another day now. Also, I really don t want to talk much about this part as it s part depressing but probably would explore it a bit in a further blog-post. One of the more interesting topics that I attended was the apt talk . There are 3-4 tools in the Debian world i.e. apt, aptitude, apt-get, dpkg and dselect. More often than not people know aptitude and apt-get whereas the rest of the packages are not thought so much about. What I somewhat suspected about the history of apt was revealed to be true today, courtesy David K. You can see the talk/video about apt at http://meetings-archive.debian.net/pub/debian-meetings/2016/debconf16/The_past_year_in_APT.webm. I had been curious about apt,libapt,dpkg and the entire tool-chain which goes into updating packages and like. I had a couple of conversations here in India before on mail, in person and IRC as well as couple of conversations in South Africa as well before the APT talk where it was told that packages are not signed or it s not easy to figure out the integrity. Being a Debian fan-boy I could not believe this to be true. Hence I asked and to my dismay found it to be true . I also then asked the same with a bit more background on the mailing list as well and got to know that this has been a concern since 2005. As I do not have the requisite skills and the person would require probably knowledge of dpkg internals as well as have probably good social skills to have at least 1-2 DD s help her/im to work on it and have probably some server space where even some partial archive is re-built using debian packages which use dpkg-sig . I also had some concerns that even if somebody did do the work, it might come in the way of the reproducible builds concept where Neils shared ways in which it could be overcome. Having said the above, it is totally doable if somebody has the will, skills and the patience to do it. Just look at the amazing work done by the team which re-built almost all the archive using clang. See clang.debian.net for the amazing work that they have done. Now, one of the issues in India which comes in popularizing Debian or in fact any free software distribution in India is the bandwidth issue or rather the lack of it or how expensive it is. The situation for better lack of term is pathetic . While nothing can be done till the time the Govt. gives limited term oligopoly licenses to telecom operators and they have a cabal (cabal closed team where decisions and policies are made without any knowledge of and to other stakeholders.) we need to find ways to make the best of the situation. Anyways, while there are some ideas to tackle that but that s a long-term goal and I will share some aspects of it in probably another blog post. In the interim somethings can definitely be made better. Now one of the issues that is there for most people is getting the package updates. Before updating the packages, the package index needs to be updated. Now, both in home and work environments most people are cautious to update the package index. But many times, either due to bandwidth issues or some other issue which is outside your control, your package index is corrupted. I have put both the possible reasons of why and how the package index corruption takes place and a probable work-around of in the deity mail post. I do hope to put in a more coherent state by probably making smaller bug issues so they could be tackled or answered one by one. Any improvements would be better for stability of debian infrastructure only. If anybody does do the required work and need a guinea pig for testing, count me in. Just holler and share you will be working on this aspect and at least one of my workstations would definitely take part in seeing if its better or not. Even if you are able to just provide a way to make a copy of /var/lib/apt/lists after every successful update and do the comparison with time-stamp on next run and only change the copy when a successful update occurs, that will be a huge help in itself. Look forward to hearing form one and all.
Filed under: Miscellenous Tagged: #Debconf16, #feature-request, #Julian Andreas Klose, #shell-script ?, apt, aptitude

We, the Debian project and the Tor project are enabling Tor onion services for several of our sites. These sites can now be reached without leaving the Tor network, providing a new option for securely connecting to resources provided by Debian and Tor. The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others. Consequently, we are pleased to announce that we have started making several of the various web services provided by both Debian and Tor available via onion services. While onion services can be used to conceal the network location of the machine providing the service, this is not the goal here. Instead, we employ onion services because they provide end-to-end integrity and confidentiality, and they authenticate the onion service end point. For instance, when users connect to the onion service running at http://sejnfjrq6szgca7v.onion/, using a Tor-enabled browser such as the TorBrowser, they can be certain that their connection to the Debian website cannot be read or modified by third parties, and that the website that they are visiting is indeed the Debian website. In a sense, this is similar to what using HTTPS provides. However, crucially, onion services do not rely on third-party certification authorities (CAs). Instead, the onion service name cryptographically authenticates its cryptographic key. In addition to the Tor and Debian websites, the Debian FTP and the Debian Security archives are available from .onion addresses, enabling Debian users to update their systems using only Tor connections. With the apt-transport-tor package installed, the following entries can replace the normal debian mirror entries in the apt configuration file (/etc/apt/sources.list): Likewise, Tor's Debian package repository is available from an onion service : Where appropriate, we provide services redundantly from several backend machines using OnionBalance. The Debian OnionBalance package is available from the Debian backports repository. Lists of several other new onion services offered by Debian and Tor are available from https://onion.debian.org and https://onion.torproject.org respectively. We expect to expand these lists in the near future to cover even more of Debian's and Tor's services.

Before I started contributing to the iptables package back in December 2015 it suffered from a numbers of problems so the package was clearly in very bad shape.

One of the first problems was the lack of VCS for the package, no git, not even svn. Of course this was easy to solve and I did it straight away importing iptables 1.4.21-2 into a git repository.

The 1.4.21-2 version was dated in May 2014. This is a lot of time for a package which is active upstream and which is installed in almost all the Debian systems out there.

The number of Debian bugs opened for the package was simply huge, and I cleaned the bugtracker as reported in the blogpost "Current status of iptables & nftables in Debian".

Netfilter project upstream released version 1.6.0 which includes the nftables-compat stuff (iptables on top of the nftables kernel engine, and also the translation tools). Adding this was not an easy task given the overall state of the package.

Also, users were asking for normal things, like Multi-Arch support (see #776041). Adding Multi-Arch support to iptables has been my personal packaging nightmare for a couple of months.

Michael Biebl, who is systemd Debian maintainer, required some changes in the iptables package as well (see #787480). This change asked for a package split to libiptc, libip4tc, libip6tc and libxtables-dev (instead of iptables-dev).
This binary package split was also required for a proper Multi-Arch support.

The situation has been clearly a huge challenge for me,: I made a lot of mistakes, I discovered how little I know about complex packaging, and I had to learn a lot about several stuff.
Probably some experts and experienced DD's could have solved the situation with more solvency, but at the end I enjoyed all the work and the learning :-)

All this changes required me about 60 commits to complete, in several uploads. The last one is 1.6.0-3 which is now in the NEW queue.

I would like to note that both Ana Guerrero and Michael Biebl invested a lot of time in reviewing and sponsoring the packages. Thanks you!

There are still work to be done, of course.

This is a repost and update of my retirement letter sent privately to Debian last month, July 10, 2016. At that time I received many notes of appreciation and good wishes which I treasure. Now, I d like to say goodbye to the broader Debian community and, as well, indicate which of the cleanup items have since been addressed in strikethrough style and with annotations. Also, I d like to stay in touch with many of you, so I have added some comments oriented towards those of you who are interested in doing that after the letter.

When in 1995, on a tip from a friend, I installed Debian on my 386 at work and was enthralled with the results, I could not have foreseen that two years later, friends I had made on channel #debian would nudge me to become a Debian developer. Nor when that happened did I have any idea that twenty years later, I d consider Debian to be like family, the greatest free software community in the world, and would still be promoting it and helping people with it whenever I could. Debian quietly, unexpectedly became a part of what defines me. My priorities in life have changed over that time, though. I have shifted my attention to things that are more important to me in life, such as my family, my health and well-being physically and spiritually, and bringing all I can to bear on the task of preserving our local wilderness areas and trails. In the latter area, I m now bringing all of what Debian has helped shaped me to be to the table, launching some ambitious projects I hope will bear fruit in the coming years, and make a measurable contribution to help us hang onto our precious natural preserves where I live. Unfortunately, as I ve poured more time and energy into these things, I ve increasingly not been giving my packages the care they need. Nor do I have any roles or goals now for any of the Debian projects I was previously involved in. So, after much careful deliberation, and as much as it pains me to say it, it s time to retire as a Debian developer. It has been a great privilege to work with you, and to meet many of you in New York at Debconf 10. I plan to be around online, and will continue to take an interest in Debian, lending a hand when I can. Thanks for all of the fun times, for all that I ve learned, and for the privilege to make awesome things with you. I ll treasure this forever. So much for the soppy bits. Now, business. These things remain to clean up upon my departure, and I d appreciate help from QA, and anyone else who can lend a hand. My packages are effectively orphaned, but I haven t the time to do any of the cleanup myself, so please speak up if you can help.

1. Debian Jr.
   • O: junior-doc. The junior-doc package has been awaiting an overhaul by whoever revives the project since I gave it up years ago. I m still listed as maintainer and that should be changed to Debian Junior Maintainers <debianjr-maintainers@lists.alioth.debian.org> if they want it. Otherwise, it is orphaned.
   • I should also be dropped from Uploaders from debian-junior, the metapackages source. Fixed in git.
2. Tux Paint. This is a very special package that deserves to go to someone who will love it and care for it well. There are three source packages in all:
   • O: tuxpaint
   • O: tuxpaint-config
   • O: tuxpaint-stamps
3. O: xletters. This is a cute little typing practice game and needs a new maintainer.
4. XPilot is co-maintained by Phil Brooke <pjb@debian.org>, so he should replace me as Maintainer. Phil said he ll pick up xpilot-ng and will also look at xpilot-extra.
   • xpilot-ng
   • O: xpilot-extra (recently removed from testing due to my neglect, and not co-maintained by Phil; it s unclear if anyone really uses this anymore)
5. GTypist is co-maintained by Daniel Leidert <dleidert@debian.org> and should replace me as Maintainer.
6. My ruby packages. A group of packages that I brought into Debian as dependencies of taskwarrior-web, which I never completed. Maybe they ll be useful in and of themselves, and maybe not. In any case, they are maintained by pkg-ruby-extras-maintainers, but I m the sole developer in Uploaders and should be removed: Fixed in git.
   • ruby-blockenspiel
   • ruby-parseconfig
   • ruby-rack-flash3
   • ruby-simple-navigation
   • ruby-sinatra-simple-navigation
   • ruby-term-ansicolor
   • ruby-versionomy
7. Debian Live stuff: I am listed in Uploaders for live-manual (fixed in git) and debian-installer-launcher (fixed in git) and need to be removed.
8. O: eeepc-acpi-scripts. The defunct Debian EeePC project has just this one package. Recently, the mailing list was asked about its status, and it was recently NMU d. To my knowledge, nobody from the original team remains to take care of it, so it needs a new maintainer. I should be removed from Uploaders, and since the Debian Eee PC Team no longer exists, it should be removed as maintainer. It is effectively orphaned unless someone speaks up.

There are also some Alioth projects / lists that are defunct that I ll need to talk to the Alioth admins about cleaning up in the coming days. One of these is <debian-eeepc-devel@lists.alioth.debian.org> and since it is still listed as the maintainer of eeepc-acpi-scripts, that needs to be sorted out before the list can be closed. Thanks again, and see you around!
Ben

Stay in touch For those of you who would like to stay in touch, here are some ways to do that:

• Follow my blog: http://syn.theti.ca
  If you already do that, great! If not, welcome to my blog! For the past couple of years you may have noticed a decrease in technical content and increase in local trails and conservation oriented posts. You can expect more of the latter.
• Say hi to me on irc: SynrG (also SynrGy) on irc.oftc.net (irc.debian.org) or irc.freenode.net.
  I still intend to hang out and offer support when I can, just no longer as a developer. Channel #debian-offtopic on either network is a good place to catch up with me socially.
• Follow me on Facebook: https://www.facebook.com/SynrG
  For better or worse, a lot of the trails and conservation folks hang out here, and many of you in the Debian community are already my Facebook friends.
• Look for my Bluff Trail posts on their site: https://wrweo.ca
  Providing tech support to this organization is where much of my time and energy is going these days. I post here once in a while, but do most of my work behind the scenes as a volunteer and, newly this year, as a board member.

Did you know there is a TV channel broadcasting talks from DebConf 16 across an entire country? Or that there is a TV channel broadcasting talks by or about Linus Torvalds, Tor, OpenID, Common Lisp, Civic Tech, EFF founder John Barlow, how to make 3D printer electronics and many more fascinating topics? It works using only free software (all of it available from Github), and is administrated using a web browser and a web API. The TV channel is the Norwegian open channel Frikanalen, and I am involved via the NUUG member association in running and developing the software for the channel. The channel is organised as a member organisation where its members can upload and broadcast what they want (think of it as Youtube for national broadcasting television). Individuals can broadcast too. The time slots are handled on a first come, first serve basis. Because the channel have almost no viewers and very few active members, we can experiment with TV technology without too much flack when we make mistakes. And thanks to the few active members, most of the slots on the schedule are free. I see this as an opportunity to spread knowledge about technology and free software, and have a script I run regularly to fill up all the open slots the next few days with technology related video. The end result is a channel I like to describe as Techno TV - filled with interesting talks and presentations. It is available on channel 50 on the Norwegian national digital TV network (RiksTV). It is also available as a multicast stream on Uninett. And finally, it is available as a WebM unicast stream from Frikanalen and NUUG. Check it out. :)

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):

• Presented "Reproducible Builds status update" at DebConf16, the annual Debian GNU/Linux developer conference.
• Attended a Core Infrastricture Initiative summit meeting. The CII was set up in the wake of the Heartbleed SSL vulnerability to support software projects that are critical to the functioning of the internet.

• Ensured that the Webconverger web kiosk operating system builds reproducibly. I may rework some of the patches to libisoburn and libisofs before sending them upstream. This work was sponsored by Webconverger.
• Proposed a pull request for Regex Replace (a Chrome extension to automatically replace text on webpages) to ensure that the rules were correctly HTML encoded on the options page. (#3)
• Proposed a change to ronn, a documentation generator that "is the opposite of roff", to make the output reproducible. (#98)
• Fixed an issue in django-enumfield, a custom Django web development field for type-safe named constants, to make the Enum.get interface more consistent. (#36)
• Proposed a change to txt2tags to make the output use SOURCE_DATE_EPOCH and non-timezone timestamps. (#204).

---

What happened in the Reproducible Builds effort between Sunday July 17 and Saturday July 23 2016: GSoC and Outreachy updates Valerie Young wrote an update about her Outreachy progress on tests.reproducible.org. Packages reviewed and fixed, and bugs filed Patches have been submitted by:

• Chris Lamb:
  • gearmand: please make the build reproducible
  • gngb: please make the build reproducible
  • speech-tools: please make the build reproducible
  • libwebsockets: please make the build reproducible
  • feh: please make the build reproducible
  • sa-exim: please make the build reproducible
  • wordgrinder: please make the build reproducible
  • ifmail: please make the build reproducible
  • libmongoc: please make the build reproducible
  • pxlib: please make the build reproducible
  • vtwm: please make the build reproducible
  • tcpreen: please make the build reproducible
  • borgbackup: please make the build reproducible
  • nfstrace: please make the build reproducible
  • ironic: please make the build reproducible
  • xloadimage: please make the build reproducible
  • stressapptest: please make the build reproducible
  • tcpflow: please make the build reproducible
  • python-mkdocs: please make the build reproducible
  • vtun: please make the build reproducible
  • hocr: please make the build reproducible
  • ui-auto: please make the build reproducible
  • ftplib: please make the build reproducible
  • fvwm: please make the build reproducible
  • why3: please make the build reproducible
  • uisp: please make the build reproducible
  • idjc: please make the build reproducible
  • python-docutils: please make the output of rst2man reproducible
  • python-mkdocs: please make the build reproducible
• Dhole:
  • libterralib: please make the build reproducible
• Reiner Herrmann:
  • aboot: please make the build reproducible

Package reviews 17 package reviews have been added and 4 have been updated. adding to our knowledge about identified issues. Some issues have been updated:

• Add new timestamps_in_manpages_generated_by_rst2man issue
• More timestamp issues are deterministic failures
• remove issue ftbfs_with_dpkg_buildpackage_buildinfo_identifier_error
• Add a patch for timestamps_in_manpages_generated_by_rst2man toolchain issue.

Weekly QA work FTBFS bugs have been reported by:

• Chris Lamb (5)
• Mattia Rizzolo (7)
• Samuel Hym (1)

diffoscope development

• Mattia Rizzolo:
  • Drop ar from RequiredToolNotFound.PROVIDERS as we don't use ar(1) directly
• Ximin Luo:
  • Add support for AR archives (including Rust .rlib files)
  • Add some more documentation for ArFile/ArContainer
  • RequiredToolNotFound.PROVIDERS dict values are package names, not binary names
• Chris Lamb:
  • Add git index file comparator.
  • Drop unused imports in Ar comparator.

strip-nondeterminism development

• strip-nondeterminism 0.020-1 was uploaded to unstable by Chris Lamb.
• Chris Lamb:
  • Correct the max number of bytes we read when copying PNG chunk data
  • Rewrite PNG handler to support bailing out on invalid header lengths
  • Include CRC when reading potential PNG blocks
  • Don't trust the value of $len in PNG handler. (Closes: #831443)
  • Improve readability in PNG handler by not including IEND detection in "else"

reprotest development

• Ceridwen:
  • Suppress autopkgtest verbosity for release
  • Add sdist and wheel to tests, and test the installed code
  • Maybe get setuptools install working
  • Merge virtualization into master
  • Reenable the Debian self-build
  • Ensure disorderfs is mounted with multiuser access if the container has root privileges
  • Rename Testbed.caps to Testbed.capabilities
  • Add Python license to debian/copyright
  • Fix cleanup handling iin both the failing and non-failing cases
  • Add new recommends and update version information
  • Add instructions for running the tests
  • Shorten license boilerplate and add new copyright info
  • Bump version numbers in preparation for the next release
  • Make the file names depend on the current version in the tests
  • Factor out common code for constructing shell ASTs
  • Move contextlib monkey-patch to its own file

tests.reproducible-builds.org

• Added main navigation highlighting to python pages (Valerie Young)
• Use python and templates to generate pkg sets (Valerie Young, with lots of review from mattia) which sped up runtime a lot, so package sets are now updated 4 times an hour instead of every 4 hours.

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

AppRecommender is a package recommender system for Debian. This project is also one of the Debian projects that is being worked on by some Google Summer of Code students. As one of these students, I will now present what my Google Summer of Code project is and what I have achieved so far.

Hello, my name is Lucas Moura and this post will present AppRecommender. This project is a package recommender system for Debian systems. The intent of this application is to look for packages that users have already installed in their system and recommend new useful packages based on them. This approach is similar as the one seen on Netflix or Amazon, where the movies or goods that a user has already seen determine other items that will be recommended.

PocketCHIP is the pocket sized Linux terminal I always used to want. Which is to say, it runs (nearly) stock Debian, X, etc, it has a physical keyboard, and the hardware and software is (nearly) non-proprietary and very hackable. Best of all, it's fun and it encourages playful learning. It's also clunky and flawed and constructed out of cheap components. This keeps it from being something I'd actually carry around in my pocket and use regularly. The smart thing they've done though is embrace these limitations, targeting it at the hobbiest, and not trying to compete with smart phones. The PocketCHIP is its own little device in its own little niche. Unless you're into hardware hacking and want to hook wires up to the GPIO pins, the best hardware feature is the complete keyboard, with even Escape and Control and arrow keys. You can ssh around and run vi on it, run your favorite REPL (I use ghci) to do quick programming, etc. The keyboard is small and a little strange, but you get used to it quickly; your QWERTY muscle memory is transferrable to it. I had fun installing nethack on it and handing it to my sister who had never played nethack before, to watch her learn to play. The screen resolution is 480x272, which is pretty tiny. And, it's a cheap resistive touchscreen, with a bezil around it. This makes it very hard to use scroll bars and icons near the edge of the screen. The customized interface that ships with it avoids these problems, and so I've been using that for now. When I have time, I plan to put a fullscreen window manager on it, and write a pdmenu menu configuration for it, so everything can be driven using the keyboard. I also have not installed Debian from scratch on it yet. This would be tricky because it uses a somewhat patched kernel (to support the display and wifi). The shipped distribution is sadly not entirely free software. There are some nonfree drivers and firmwares. And, they included a non-free gaming environment on it (a very nice one for part of the audience, that allows editing the games, but non-free nevertheless). They did do a good job of packaging up all the custom software they include on it, although they don't seem to have published source packages for everything. (They might be infringing my GPL copyright of flash-kernel by distributing a modified version without source. I say "might" because flash-kernel is a pile of shell scripts, so you could probably extract the (probably trivial) modifications. Still.. Also, they seem to have patched network-manager in some way and I wasn't able to find the corresponding source.) The battery life is around 5 hours. Unfortunately the "sleep" mode only turns off the backlight and maybe wifi, and leaves the rest of the system running. This and the slightly awkward form factor too big to really comfortably fit in a pocket limit the use of PocketCHIP quite a bit. Perhaps the sleeping will get sorted out, and perhaps I'll delete the GPIO breakout board from the top of mine to make it more pocket sized.

First post with the new link collection feature of staticsite!

Heavy Metal and Natural Language Processing [archived]

Natural language processing and Metal lyrics, including the formula for the "metalness" of a word and a list of the most and least metal words.

Confirming all use of an SSH agent [archived]

For a long time I ve wanted an ssh-agent setup that would ask me before every use, so I could slightly more comfortably forward authentication over SSH without worrying that my session might get hijacked somewhere at the remote end (I often find myself wanting to pull authenticated git repos on remote hosts). I m at DebConf this week, which is an ideal time to dig further into these things, so I did so today. As is often the case it turns out this is already possible, if you know how.

Why We Don t Report It [archived]

Why don t you report it? It s up there on every list I ve seen of things you shouldn t say to sexual assault survivors, yet I keep hearing it

Voltron, an extensible debugger UI toolkit written in Python

Multi-panel display built from various gdb outputs.

Notmuch, offlineimap and Sieve setup [archived]

Nice description of a notmuch+offlineimap+sieve setup, for when I feel like rethinking my email setup.

Wikipedia:Unusual articles

An endless source of weird and wonderful.

ZERO: no linked HIV transmissions [archived]

The results provide a dataset to question whether transmission with an undetectable viral load is actually possible. They should help normalise HIV and challenge stigma and discrimination.

TV pickup

Someone once in the UK told me that it was a big enough problem that so many people turn on their electric kettles during the endtitles of Eastenders, that there's an employee in a hydro plant that needs to watch it to ramp up the power at the right time. I've finally found a wikipedia page about it.

Amazon isn't saying if Echo has been wiretapped [archived]

"We may never know if the feds have hijacked Amazon Echo. In case you didn't know, Echo is an always-on device, which, when activated, can return search queries, as well as read audiobooks and report sports, traffic, and weather. It can even control smart home devices."

Categories:

• Debian-Blog
• Computing
• Tools
• Virtualization

Keywords:

• UML
• User Mode Linux
• debian

Like:

About a year ago, I bought a Projector after I finally admitted that I could actually use a TV in my apartment. I settled on buying a ViewSonic PJD5132. It was a really great value, and has been nothing short of a delight to own. I was always a bit curious about the DB9 connector on the back of the unit, so I dug into the user manual, and found some hex code strings in there. So, last year, between my last gig at the Sunlight Foundtion and USDS, I spent some time wandering around the US, hitting up DebConf, and exploring Washington DC. Between trips, I set out to figure out exactly what was going on with my Projector, and see if I could make it do anything fun. So, I started off with basics, and tried to work out how these command codes were structured. I had a few working codes, but to write clean code, I'd be better off understanding why the codes looked like they do. Let's look at the "Power On" code. 0x06 0x14 0x00 0x04 0x00 0x34 0x11 0x00 0x00 0x5D Some were 10 bytes, other were 11, and most started with similar looking things. The first byte was usually a 0x06 or 0x07, followed by two bytes 0x14 0x00, and either a 0x04 or 0x05. Since the first few bytes were similarly structured, I assumed the first octet (either 0x06 or 0x07) was actually a length, since the first 4 octets seemed always present. So, my best guess is that we have a Length byte at index 0, followed by two bytes for the Protocol, a flag for if you're Reading or Writing (best guess on that one), and opaque data following that. Sometimes it's a const of sorts, and sometimes an octet (either little or big endian, confusingly). Right. OK. So, let's get to work. In the spirit of code is data, data is code, I hacked up some of the projector codes into a s-expression we can use later. The structure of this is boring, but it'll let us both store the command code to issue, as well as define the handler to read the data back. As well as defining some of the const responses that come back from the Projector itself. These are pretty boring, but it's helpful to put a name to the int that falls out. After defining a few simple functions to write the byte arrays to the serial port as well as reading and understanding responses from the projector, I could start elaborating on some higher order functions that can talk projector. So the first thing I wrote was to make a function that converts the command entry into a native Hy function. Fun. Fun! Now, we can invoke it to create a Hy & Python importable API wrapper in a few lines! Cool. So, now we can import things like power-on from *commands* which takes a single argument (serial) for the serial port, and it'll send a command, and return the response. The best part about all this is you only have to define the data once in a list, and the rest comes for free. Finally, I do want to be able to turn my projector on and off over the network so I went ahead and make a Flask "API" on top of this. First, let's define a macro to define Flask routes: Now, we can define how we want our API to look, so let's define the power route, which will expand out into the Flask route code above. And now, let's play with it! Or, the volume! Check out the full source over at github.com/paultag/PJD5132!

This doesn t appear to cover the other kind of comment-moderation problem: that where overmoderation and attachment to poster identity leads to an environment of stifling conventionalism. Photography communities in particular (e.g. flickr, instagram, 500px) are vulnerable to turning into circlejerks where no-one is willing to say what they mean for fear of appearing the negative nancy (no pun intended) and where high post-count contributors poorly-supported opinions become elevated above said views merits. In such communities the typical discussion is at the level of tepid platitude: good exposure! , nice depth of field! , or cool HDR! . On the other end of the scale there s the imageboard style of community where anonymity is the norm, feedback is uncompromisingly harsh, and uselessly opaque criticism appears such on its face; unsuited to the overly sensitive but hideously valuable to the advancing novice. Ordinary web forums, with tools oriented towards a punitive he said the n-word! delete his account and everything he s posted! persona non grata, in damnatio memoriae! school of moderation, strongly tend to the former.

ksandstr on LWN

I recently attended Snappy Sprint Heidelberg, the first Snappy sprint focused on upstream and cross-distribution collaboration.

Snappy is a technology with an interesting history: initially started to provide App Store-like semantics (atomicity, declarative security) for the Ubuntu Phone project, it has since expanded to be a platform for desktop application deployment (e.g. VLC), as well as server applications and the IoT space.

There were a number of productive discussions with people working on Snappy itself, as well as folks from Fedora, elementary OS, KDE, and elsewhere.

At the start of the week, Snappy was technically usable in several different distributions, but only shipped fully-featured (in the main distribution repositories, with confinement, etc) in Ubuntu. Some great progress was made on AppArmor confinement in Arch Linux, and there is currently beta support for confinement via SELinux.

Providing a full-featured Snappy experience in Debian has its challenges, mostly relating to the lack of a default LSM. While AppArmor in Debian is supported and there's desire to have it be the default in "buster", Ubuntu carries a number of patches that add additional functionality not yet present upstream. I'm not sure whether pursuing getting those patches merged is more viable than waiting for SELinux support in snapd, however.

I've agreed to co-maintain the snapd package in Debian, and am excited to see intentions to support building snaps on a variety of distribution bases. While I do not expect Snappy (or Flatpak, or AppImage) to replace distribution-maintained software in the foreseeable future, nor do I feel that's a desirable outcome, I do think offering users freedom to choose to use software via these systems in a safe manner is critical.

I bought a new laptop E200HA, because my previous was a MacBook and It broke after a fall into the ground. I let it boot first in Win10 to check if everything was OK and because I could not found the way to enter in the UEFI/BIOS. It is F2 and is edge triggered. It boots fast into Win10, but I got the feeling of being a little slow. No worries because I it bought for running Debian and because of the autonomy of the battery, 14hours playing music according to Asus. A little research if the new laptop could run Linux almost return no hits, but one very valuable link on how to setup the Wifi. So I got the feeling that I needed a Debian stretch CD for installation. So I download the first installation DVD from here. Run a trial of the DVD image using kvm

kvm -m 2047 -cdrom debian-stretch-DI-alpha7-amd64-DVD-1.iso

Found that the installer DVD now have the functionality of Live CD. This will be useful. Copy the image to a USB stick using dd command. I turned on the E200HA, entered into the UEFI/BIOS by pressing and releasing the F2 key. Turned off the secure boot and select USB storage for boot. The E200HA happily boot the Linux and I select the rescue mode. Using another USB stick of 32GB that was formatted in xfs, because of the lower slack for storing the inodes than ext3/4. In this USB stick I put a raw image of the internal storage of the E200HA, preserving this way the Win10. Another reboot, this time for installation of Debian stretch. It detected the lack of firmware files, for the WiFi adaptor. This link come very handy. The instructions are for an older Linux kernel. So I recommend doing something similar to the following commands:

git clone https://github.com/ajaybhatia/Qualcomm-Atheros-QCA9377-Wifi-Linux
cd Qualcomm-Atheros-QCA9377-Wifi-Linux/firmware-only
tar cvf QCA9377.tar QCA9377

Copy the tar file to a a second USB stick and connect it to the other USB port. This tar is not the files the Debian installer are expecting, so you need to change to the second console "Alt-F2", press enter to activate a shell, and do the following commands:

cd /lib/firmware
mkdir ath10k
mount /dev/sdb1 /mnt
cd ath10k
tar xf /mnt/QCA9377.tar

Return to the first console "Alt-F1" and continue with the installation. The list of missing firmware files is reduced and the WiFi can work. I had problems with the WiFI, but was because a neighbor router was on the same channel, since I changed the channel of my router the WiFi is working as a charm. The following links maybe useful in the future or as a reference: kvalo/ath10k-firmware kernel/git/firmware/linux-firmware.git

This release adds a new, experimental server implementation: remctl-shell. As its name implies, this is designed to be run as a shell of a dedicated user rather than as a server. It does not use the remctl protocol, instead relying on ssh to pass in the command and user information (via special authorized_keys configuration). But it supports the same configuration as the normal remctl server. It can be useful for allowing remctl-style simple RPC in environments that only use ssh public key authentication. Also in this release is a new configuration option, sudo, which is like the existing user option to run a command as another user but uses sudo instead of calling setuid() directly. This allows the server to switch users when running as a non-root user, which will be the normal case for remctl-shell. The remctl-shell implementation in this release should be considered a first draft and is likely to improve in the future. (I already have a list of things that probably should be improved.) You can get the latest release from the remctl distribution page.