• Content count

  • Joined

  • Last visited

  • Days Won


BINREV SPYD3R last won the day on October 24 2019

BINREV SPYD3R had the most liked content!

Community Reputation

-39 Troll


  • Rank
    I could have written a book with all of these posts

Profile Information

  • Gender
  • Country
  1. New hosts Welcome to our new host: crvs. Last Month's Shows Id Day Date Title Host 3021 Mon 2020-03-02 HPR Community News for February 2020 HPR Volunteers 3022 Tue 2020-03-03 FOSDEM 2020 Stand Interviews Ken Fallon 3023 Wed 2020-03-04 Critique My Script, Episode 1 - Qots-Crew-Gen Carl 3024 Thu 2020-03-05 A funny thing happened the other day MrX 3025 Fri 2020-03-06 Keep unwanted messages off the Fediverse Ahuka 3026 Mon 2020-03-09 Hex Bug and Battle Bots operat0r 3027 Tue 2020-03-10 What is quantum computing and why should we care? mightbemike 3028 Wed 2020-03-11 Monads and Haskell crvs 3029 Thu 2020-03-12 At Union Station with a train delay Archer72 3030 Fri 2020-03-13 My new Samsung tablet MrX 3031 Mon 2020-03-16 Daniel Persson - Me? Me! Daniel Persson 3032 Tue 2020-03-17 piCore on a Raspberry Pi 1 Model B Claudio Miranda 3033 Wed 2020-03-18 32 Bit Time Travel monochromec 3034 Thu 2020-03-19 How to bridge Freenode IRC rooms to Thaj Sara 3035 Fri 2020-03-20 Decentralised Hashtag Search and Subscription in Federated Social Networks Ahuka 3036 Mon 2020-03-23 WiiU is dead long live WiiU! operat0r 3037 Tue 2020-03-24 Ambient recording at Union Station Archer72 3038 Wed 2020-03-25 Solo Magic klaatu 3039 Thu 2020-03-26 Making a Raspberry Pi status display Dave Morriss 3040 Fri 2020-03-27 Why use GNU Autotools klaatu 3041 Mon 2020-03-30 How to use GNU Autotools klaatu 3042 Tue 2020-03-31 The COVID-19 Work From Home Stream - Day 0 Thaj Sara Comments this month These are comments which have been made during the past month, either to shows released during the month or to past shows. There are 23 comments in total. Past shows There are 2 comments on 2 previous shows: hpr3009 (2020-02-13) "Linux Inlaws S01 E01" by monochromec. Comment 5: bittin on 2020-03-05: "yay" hpr3019 (2020-02-27) "Linux Inlaws S01E02 FOSDEM shenanigans" by monochromec. Comment 1: ClaudioM on 2020-03-05: "FLOSS Weekly #568" This month's shows There are 21 comments on 8 of this month's shows: hpr3023 (2020-03-04) "Critique My Script, Episode 1 - Qots-Crew-Gen" by Carl. Comment 1: Dave Morriss on 2020-03-04: "Bash arithmetic" Comment 2: Dave Morriss on 2020-03-04: "Another Bash-ism that might be useful" Comment 3: nobody on 2020-03-04: "There must be an easier way" Comment 4: nobody on 2020-03-04: "Little correction to my comment" Comment 5: Carl on 2020-03-05: "Thanks for the comments" Comment 6: Carl on 2020-03-05: "Thanks for the comments" Comment 7: nobody on 2020-03-05: "Re: Re:" Comment 8: nobody on 2020-03-05: "Standalone increment in ash" Comment 9: Carl on 2020-03-05: "Neat" Comment 10: nobody on 2020-03-05: "$(())" Comment 11: Carl on 2020-03-05: "Version 3" hpr3024 (2020-03-05) "A funny thing happened the other day" by MrX. Comment 1: tuturto on 2020-03-05: "great storytelling" Comment 2: MrX on 2020-03-07: "Re great storytelling" hpr3025 (2020-03-06) "Keep unwanted messages off the Fediverse" by Ahuka. Comment 1: Ken Fallon on 2020-03-09: "I disagree" Comment 2: Ahuka on 2020-03-09: "Further discussion" hpr3026 (2020-03-09) "Hex Bug and Battle Bots" by operat0r. Comment 1: Windigo on 2020-03-25: "Great episode" hpr3028 (2020-03-11) "Monads and Haskell" by crvs. Comment 1: tuturto on 2020-03-11: "welcome!" Comment 2: crvs on 2020-03-11: "Re: welcome!" hpr3031 (2020-03-16) "Daniel Persson - Me? Me!" by Daniel Persson. Comment 1: Klaatu on 2020-03-22: "History" hpr3032 (2020-03-17) "piCore on a Raspberry Pi 1 Model B" by Claudio Miranda. Comment 1: Windigo on 2020-03-26: "Minimal distros are the best" hpr3034 (2020-03-19) "How to bridge Freenode IRC rooms to" by Thaj Sara. Comment 1: Klaatu on 2020-03-22: "Did not know this" Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mail List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: Events Calendar With the kind permission of we are linking to The Community Calendar. Quoting the site: This is the community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page. Any other business Tags and Summaries Thanks to the following contributors for sending in updates in the past month: crvs, Windigo, Archer72, Dave Morriss Over the period tags and/or summaries have been added to 28 shows which were without them. If you would like to contribute to the tag/summary project visit the summary page at and follow the instructions there. View the full article
  2. The GDPR (General Data Protection Regulation) was enacted by the European Community in 2016, and began to be enforced in 2018. Since this covers a large segment of the Internet users, and other jurisdictions are looking at similar legislation this talk is a timely look at what is required and how Open Source Software can meet the legal requirements. Links: View the full article
  3. NEW 'Off The Hook' ONLINE Posted 02 Apr, 2020 1:23:35 UTC The new edition of Off The Hook from 04/01/2020 has been archived and is now available online. An update on Alex's health, increasing protective measures, disturbing projections, weird noises, getting through this together, artificial software locks preventing ventilator repairs, it's census day, listener phone calls, 2600 meetings cancelled, Manu Dibango has passed away. "Off The Hook" - 04/01/2020 Download the torrent here View the full article
  4. I use cordless headphones, I find this very handy when I want mocp to play for a set time then pause. Commands used Ctrl + r, to quickly find the command sleep 10m && mocp -G sleep 10m && mocp -M ~/.moc/audiobooks -G sleep 5h && iplayer-url View the full article
  5. Sentry BT250 Bluetooth Headphones w/ mic F-Droid - free open source apps for Android Audio Recorder from F-Droid Features: Mute incoming call audio while recording Variety of format encoding ogg (default) wav flac m4a mp3 opus X-plore Android file explorer Audacity Amplify tool Bass and Treble tool View the full article
  6. NEW 'Off The Wall' ONLINE Posted 31 Mar, 2020 23:34:44 UTC The new edition of Off The Wall from 03/31/2020 has been archived and is now available online. "Off The Wall" - 03/31/2020 Download the torrent here View the full article
  7. Tuesday 17.03.2020 Guests: honkeymagoo, crvs, and Thaj How likely we are to get COVID-19 Should we invest while the market is down How bad is the internet infrastructure in the US Learning Python Grasshopper Learn Python tne Hard Way Excercism Klaatu's Programming Book Growing plants That Audiobook Club though... Video games Single Board Computers OpenBSD on Raspberry Pi Why haven't you done a show about that Thaj? Emacs and org-mode Nano for the win View the full article
  8. Due to the COVID-19 crisis, we are canceling all 2600 meetings scheduled for this week. This applies even if you're in an area that's currently not afflicted by the virus. Every place that's currently in the midst of this was once unaffected. The last thing we want to do is create a situation that could potentially make matters worse. Please, no matter where you are, stay home and be safe. We will get through this and help others. If you have alternative methods of virtual gathering for your meetings, please tweet to @2600Meetings and we'll help spread them. We look forward to seeing everyone once this is over. Stay safe. View the full article
  9. I found a great article on this topic here:, so please refer to that as show notes. Page included by Ken, as permitted by cc-by-sa Introduction to GNU Autotools Have you ever downloaded the source code for a popular software project that required you to type the almost ritualistic ./configure; make && make install command sequence to build and install it? If so, you’ve used GNU Autotools. If you’ve ever looked into some of the files accompanying such a project, you’ve likely also been terrified at the apparent complexity of such a build system. Good news! GNU Autotools is a lot simpler to set up than you think, and it’s GNU Autotools itself that generates those 1,000-line configuration files for you. Yes, you can write 20 or 30 lines of installation code and get the other 4,000 for free. Autotools at work If you’re a user new to Linux looking for information on how to install applications, you do not have to read this article! You’re welcome to read it if you want to research how software is built, but if you’re just installing a new application, go read my article about installing apps on Linux. For developers, Autotools is a quick and easy way to manage and package source code so users can compile and install software. Autotools is also well-supported by major packaging formats, like DEB and RPM, so maintainers of software repositories can easily prepare a project built with Autotools. Autotools works in stages: First, during the ./configure step, Autotools scans the host system (the computer it’s being run on) to discover the default settings. Default settings include where support libraries are located, and where new software should be placed on the system. Next, during the make step, Autotools builds the application, usually by converting human-readable source code into machine language. Finally, during the make install step, Autotools copies the files it built to the appropriate locations (as detected during the configure stage) on your computer. This process seems simple, and it is, as long as you use Autotools. The Autotools advantage GNU Autotools is a big and important piece of software that most of us take for granted. Along with GCC (the GNU Compiler Collection), Autotools is the scaffolding that allows Free Software to be constructed and installed to a running system. If you’re running a POSIX system, it’s not an understatement to say that most of your operating system exists as runnable software on your computer because of these projects. In the likely event that your pet project isn’t an operating system, you might assume that Autotools is overkill for your needs. But, despite its reputation, Autotools has lots of little features that may benefit you, even if your project is a relatively simple application or series of scripts. Portability First of all, Autotools comes with portability in mind. While it can’t make your project work across all POSIX platforms (that’s up to you, as the coder), Autotools can ensure that the files you’ve marked for installation get installed to the most sensible locations on a known platform. And because of Autotools, it’s trivial for a power user to customize and override any non-optimal value, according to their own system. With Autotools, all you need to know is what files need to be installed to what general location. It takes care of everything else. No more custom install scripts that break on any untested OS. Packaging Autotools is also well-supported. Hand a project with Autotools over to a distro packager, whether they’re packaging an RPM, DEB, TGZ, or anything else, and their job is simple. Packaging tools know Autotools, so there’s likely to be no patching, hacking, or adjustments necessary. In many cases, incorporating an Autotools project into a pipeline can even be automated. How to use Autotools To use Autotools, you must first have Autotools installed. Your distribution may provide one package meant to help developers build projects, or it may provide separate packages for each component, so you may have to do some research on your platform to discover what packages you need to install. The primary components of Autotools are: automake autoconf make While you likely need to install the compiler (GCC, for instance) required by your project, Autotools works just fine with scripts or binary assets that don’t need to be compiled. In fact, Autotools can be useful for such projects because it provides a make uninstall script for easy removal. Once you have all of the components installed, it’s time to look at the structure of your project’s files. Autotools project structure GNU Autotools has very specific expectations, and most of them are probably familiar if you download and build source code often. First, the source code itself is expected to be in a subdirectory called src. Your project doesn’t have to follow all of these expectations, but if you put files in non-standard locations (from the perspective of Autotools), then you’ll have to make adjustments for that in your Makefile later. Additionally, these files are required: NEWS README AUTHORS ChangeLog You don’t have to actively use the files, and they can be symlinks to a monolithic document (like that encompasses all of that information, but they must be present. Autotools configuration Create a file called at your project’s root directory. This file is used by autoconf to create the configure shell script that users run before building. The file must contain, at the very least, the AC_INIT and AC_OUTPUT M4 macros. You don’t need to know anything about the M4 language to use these macros; they’re already written for you, and all of the ones relevant to Autotools are defined in the documentation. Open the file in your favorite text editor. The AC_INIT macro may consist of the package name, version, an email address for bug reports, the project URL, and optionally the name of the source TAR file. The AC_OUTPUT macro is much simpler and accepts no arguments. AC_INIT([penguin], [2019.3.6], []) AC_OUTPUT If you were to run autoconf at this point, a configure script would be generated from your file, and it would run successfully. That’s all it would do, though, because all you have done so far is define your project’s metadata and called for a configuration script to be created. The next macros you must invoke in your file are functions to create a Makefile. A Makefile tells the make command what to do (usually, how to compile and link a program). The macros to create a Makefile are AM_INIT_AUTOMAKE, which accepts no arguments, and AC_CONFIG_FILES, which accepts the name you want to call your output file. Finally, you must add a macro to account for the compiler your project needs. The macro you use obviously depends on your project. If your project is written in C++, the appropriate macro is AC_PROG_CXX, while a project written in C requires AC_PROG_CC, and so on, as detailed in the Building Programs and Libraries section in the Autoconf documentation. For example, I might add the following for my C++ program: AC_INIT([penguin], [2019.3.6], []) AC_OUTPUT AM_INIT_AUTOMAKE AC_CONFIG_FILES([Makefile]) AC_PROG_CXX Save the file. It’s time to move on to the Makefile. Autotools Makefile generation Makefiles aren’t difficult to write manually, but Autotools can write one for you, and the one it generates will use the configuration options detected during the ./configure step, and it will contain far more options than you would think to include or want to write yourself. However, Autotools can’t detect everything your project requires to build, so you have to add some details in the file, which in turn is used by automake when constructing a Makefile. uses the same syntax as a Makefile, so if you’ve ever written a Makefile from scratch, then this process will be familiar and simple. Often, a file needs only a few variable definitions to indicate what files are to be built, and where they are to be installed. Variables ending in _PROGRAMS identify code that is to be built (this is usually considered the primary target; it’s the main reason the Makefile exists). Automake recognizes other primaries, like _SCRIPTS, _DATA, _LIBRARIES, and other common parts that make up a software project. If your application is literally compiled during the build process, then you identify it as a binary program with the bin_PROGRAMS variable, and then reference any part of the source code required to build it (these parts may be one or more files to be compiled and linked together) using the program name as the variable prefix: bin_PROGRAMS = penguin penguin_SOURCES = penguin.cpp The target of bin_PROGRAMS is installed into the bindir, which is user-configurable during compilation. If your application isn’t actually compiled, then your project doesn’t need a bin_PROGRAMS variable at all. For instance, if your project is a script written in Bash, Perl, or a similar interpreted language, then define a _SCRIPTS variable instead: bin_SCRIPTS = bin/penguin Automake expects sources to be located in a directory called src, so if your project uses an alternative directory structure for its layout, you must tell Automake to accept code from outside sources: AUTOMAKE_OPTIONS = foreign subdir-objects Finally, you can create any custom Makefile rules in and they’ll be copied verbatim into the generated Makefile. For instance, if you know that a temporary value needs to be replaced in your source code before the installation proceeds, you could make a custom rule for that process: all-am: penguin touch bin/ penguin: bin/ @sed "s|__datadir__|@datadir@|" $< >bin/$@ A particularly useful trick is to extend the existing clean target, at least during development. The make clean command generally removes all generated build files with the exception of the Automake infrastructure. It’s designed this way because most users rarely want make clean to obliterate the files that make it easy to build their code. However, during development, you might want a method to reliably return your project to a state relatively unaffected by Autotools. In that case, you may want to add this: clean-local: @rm config.status configure config.log @rm Makefile @rm -r autom4te.cache/ @rm aclocal.m4 @rm compile install-sh missing There’s a lot of flexibility here, and if you’re not already familiar with Makefiles, it can be difficult to know what your needs. The barest necessity is a primary target, whether that’s a binary program or a script, and an indication of where the source code is located (whether that’s through a _SOURCES variable or by using AUTOMAKE_OPTIONS to tell Automake where to look for source code). Once you have those variables and settings defined, you can try generating your build scripts as you see in the next section, and adjust for anything that’s missing. Autotools build script generation You’ve built the infrastructure, now it’s time to let Autotools do what it does best: automate your project tooling. The way the developer (you) interfaces with Autotools is different from how users building your code do. Builders generally use this well-known sequence: $ ./configure $ make $ sudo make install For that incantation to work, though, you as the developer must bootstrap the build infrastructure. First, run autoreconf to generate the configure script that users invoke before running make. Use the –install option to bring in auxiliary files, such as a symlink to depcomp, a script to generate dependencies during the compiling process, and a copy of the compile script, a wrapper for compilers to account for syntax variance, and so on. $ autoreconf --install installing './compile' installing './install-sh' installing './missing' With this development build environment, you can then create a package for source code distribution: $ make dist The dist target is a rule you get for "free" from Autotools. It’s a feature that gets built into the Makefile generated from your humble configuration. This target produces a tar.gz archive containing all of your source code and all of the essential Autotools infrastructure so that people downloading the package can build the project. At this point, you should review the contents of the archive carefully to ensure that it contains everything you intend to ship to your users. You should also, of course, try building from it yourself: $ tar --extract --file penguin-0.0.1.tar.gz $ cd penguin-0.0.1 $ ./configure $ make $ DESTDIR=/tmp/penguin-test-build make install If your build is successful, you find a local copy of your compiled application specified by DESTDIR (in the case of this example, /tmp/penguin-test-build). $ /tmp/example-test-build/usr/local/bin/example hello world from GNU Autotools Time to use Autotools Autotools is a great collection of scripts for a predictable and automated release process. This toolset may be new to you if you’re used to Python or Bash builders, but it’s likely worth learning for the structure and adaptability it provides to your project. And Autotools is not just for code, either. Autotools can be used to build Docbook projects, to keep media organized (I use Autotools for my music releases), documentation projects, and anything else that could benefit from customizable install targets. View the full article
  10. GNU Autotools is a build system that helps you distribute your code in a predictable and reliable way. Build systems offer many benefits, including: Standard and automate-able build process hooks into packaging systems (RPM, DEB, Slackbuilds, Flatpak, Snap, and so on) version reporting build for various OSes you get lots of code to handle every possible corner case, for free with a single configuration, you can build your project as the developer, build it for packagers, and enable users to build it for themselves Next up: how to use GNU Autotools View the full article
  11. NEW 'Off The Hook' ONLINE Posted 26 Mar, 2020 1:56:49 UTC The new edition of Off The Hook from 03/25/2020 has been archived and is now available online. This week's show is coming from four different locations, an update on Alex's health, how others are dealing with social distancing, New York is the epicenter of the outbreak now, WBAI is running with a skeleton crew, panic over the signal, rating the presidential response, dangerous advice, listener feedback, technology solutions to the health crisis, technology failures. "Off The Hook" - 03/25/2020 Download the torrent here View the full article
  12. Introduction I have had a project on my To Do list for a while: to make a status display from a Raspberry Pi. My vision was to show the state of various things including some HPR stuff, and I had imagined setting up a Pi with a monitor and controlling it over SSH. I started on the project over the Christmas period 2019. I have a Raspberry Pi 3A+, which is a sort of souped-up Pi Zero, which I bought on a whim and hadn’t found a use for (Yannick reviewed this RPi model in show 2711). I also had an old square Dell monitor from about 15 years ago which still worked (at least to begin with). I had imagined I’d write some software of my own with a web front end which ran various tasks to monitor things. However, in my researches I came across MagicMirror2 which I thought I might be able to use instead of writing my own thing. Long notes I have provided detailed notes as usual for this episode, and these can be viewed here. Links JavaScript programming language: Wikipedia entry Node.js JavaScript runtime environment: Website Wikipedia entry Electron software framework: Website Wikipedia entry MagicMirror2: GitHub page Website List of third-party modules Resources: Example files: config.js custom.css View the full article
  13. This episode outlines my single-player mod for the Magic: The Gathering card game. View the full article
  14. NEW 'Off The Wall' ONLINE Posted 24 Mar, 2020 23:25:10 UTC The new edition of Off The Wall from 03/24/2020 has been archived and is now available online. "Off The Wall" - 03/24/2020 Download the torrent here View the full article
  15. This was recorded in the main hall at Union Station in Chicago, Illinois. There was a brief security announcement about watching for bags or package left unattended. View the full article