We started producing shows as Today with a Techie on 2005-09-19, 14 years, 6 months, 23 days ago. Our shows are produced by listeners like you and can be on any topic that "are of interest to hobbyists". If you listen to HPR then please consider contributing one show a year. If you record your show now it could be released in 10 days.
Please help out tagging older shows !
Hosted by HPR Volunteers on 2020-04-06 is flagged as Explicit and released under a CC-BY-SA license.
Tags: Community News.
Listen in ogg, spx, or mp3 format.
Series: HPR Community News | Comments (0)
Welcome to our new host:
crvs.
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.
There are 2 comments on 2 previous shows:
There are 21 comments on 8 of this month's shows:
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:
http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/2020-March/thread.htmlWith the kind permission of LWN.net we are linking to The LWN.net Community Calendar.
Quoting the site:
This is the LWN.net 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.
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 https://hackerpublicradio.org/report_missing_tags.php and follow the instructions there.
Hosted by Ahuka on 2020-04-03 is flagged as Clean and released under a CC-BY-SA license.
Tags: social media, alternative, Fediverse, ActivityPub, Privacy.
Listen in ogg, spx, or mp3 format.
Series: Social Media | Comments (0)
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. https://www.zwilnik.com/?page_id=1096
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
Hosted by Archer72 on 2020-04-01 is flagged as Clean and released under a CC-BY-SA license.
Tags: recording, bluetooth, android.
Listen in ogg, spx, or mp3 format.
Comments (1)
Sentry BT250 Bluetooth Headphones w/ mic
https://www.amazon.com/Wireless-Rechargeable-Stereo-Earbuds-Bluetooth/dp/B015NFWDX8
F-Droid - free open source apps for Android
https://f-droid.org/en/
X-plore Android file explorer
https://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en_US
Hosted by Thaj Sara on 2020-03-31 is flagged as Explicit and released under a CC-BY-SA license.
Tags: COVID-19, Stock Markets, Emacs, Python, Programming, Audiobooks, Growing Food, Video Games, SBCs.
Listen in ogg, spx, or mp3 format.
Comments (0)
Tuesday 17.03.2020
Guests: honkeymagoo, crvs, and Thaj
I found a great article on this topic here: https://opensource.com/article/19/7/introduction-gnu-autotools, so please refer to that as show notes.
Page included by Ken, as permitted by cc-by-sa
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.
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:
This process seems simple, and it is, as long as you use Autotools.
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.
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.
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.
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:
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.
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:
You don’t have to actively use the files, and they can be symlinks to a monolithic document (like README.md) that encompasses all of that information, but they must be present.
Create a file called configure.ac 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], [seth@example.com])
AC_OUTPUT
If you were to run autoconf at this point, a configure script would be generated from your configure.ac 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 configure.ac 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], [seth@example.com])
AC_OUTPUT
AM_INIT_AUTOMAKE
AC_CONFIG_FILES([Makefile])
AC_PROG_CXX
Save the file. It’s time to move on to the Makefile.
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 Makefile.am, which in turn is used by automake when constructing a Makefile.
Makefile.am 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 Makefile.am 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 Makefile.am 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.sh
penguin: bin/penguin.sh
@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 Makefile.in
There’s a lot of flexibility here, and if you’re not already familiar with Makefiles, it can be difficult to know what your Makefile.am 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.
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
configure.ac:3: installing './compile'
configure.ac:2: installing './install-sh'
configure.ac:2: 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 Makefile.am 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
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.
GNU Autotools is a build system that helps you distribute your code in a predictable and reliable way. Build systems offer many benefits, including:
Next up: how to use GNU Autotools
Hosted by Dave Morriss on 2020-03-26 is flagged as Explicit and released under a CC-BY-SA license.
Tags: Raspberry Pi,VGA monitor,MagicMirror2,MQTT,Node.js,Electron.
Listen in ogg, spx, or mp3 format.
Comments (0)
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.
I have provided detailed notes as usual for this episode, and these can be viewed here.
This episode outlines my single-player mod for the Magic: The Gathering card game.
Hosted by Archer72 on 2020-03-24 is flagged as Clean and released under a CC-BY-SA license.
Tags: soundscape, train station.
Listen in ogg, spx, or mp3 format.
Series: Sound Scapes | Comments (0)
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.
Get a full list of all our shows.