php -d xdebug.profiler_enable=1

So to enable profiling on the command line run your script in PHP like this:

php -d xdebug.profiler_enable=1 /path/to/script.php

You need to have configured xdebug in php.ini, I do it with a file in /etc/php/7.2/cli/conf.d/xdebug.ini that looks like this:

;xdebug.profiler_enable = 0
xdebug.profiler_output_dir = "/tmp/xdebug"
xdebug.profiler_output_name = "cachegrind.out.%p"

Note: you can enable profiling for all scripts with xdebug.profiler_enable = 1

Omitting date completed from MySQL dump file

By default when you run a dump with ‘mysqldump’ the date of the dump is appended to the file, e.g.:

jj5@love:~/desktop/experiment$ udiff *
--- dbt__jj_dev_1__svn_jdrepo.1.sql     2019-06-11 18:11:13.267758230 +1000
+++ dbt__jj_dev_1__svn_jdrepo.2.sql     2019-06-11 18:12:03.856075974 +1000
@@ -32,4 +32,4 @@
 /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
 /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

--- Dump completed on 2019-06-10 21:59:44
+-- Dump completed on 2019-06-10 12:06:49

This causes dumps for a single database that has not changed to have two dumps which differ. It’s better to have dumps from the same unchanged database to be the same. To facilitate that add the –skip-dump-date option when running ‘mysqldump’.

See here for the back-story.

Fixing character encoding issue in ViewVC

So I was having an issue with ViewVC wherein UTF-8 content (a copyright symbol) was being garbled in the web browser.

I chased a number of red herrings (Content-Type headers, http-equiv, XHTML vs HTML5) but eventually found the culprit in the viewvc.conf settings.

I needed to change the ‘detect_encoding’ setting from ‘1’ to ‘0’. Once that was done my content was presented correctly:

## detect_encoding: Should we attempt to detect versioned file
## character encodings?  [Requires 'chardet' module, and is currently
## used only by the syntax coloration logic -- if enabled -- for the
## 'markup' and 'annotate' views; see 'enable_syntax_coloration'.]
##
# 2019-06-02 jj5 - OLD: this was bollocksing things up...
#detect_encoding = 1
# 2019-06-02 jj5 - NEW: so I changed it...
detect_encoding = 0
# 2019-06-02 jj5 - END

Salt file.recurse source file not found (file encoding issue)

So I was running this:

/var/www/jj-web-1-www.jj5.net-sixsigma:
  file.recurse:
    - clean: True
    - user: root
    - group: root
    - dir_mode: 755
    - file_mode: 644
    - source: salt://inst/mediawiki-1.29
    - require:
      - pkg: apache2

And getting an error like this:

----------
          ID: /var/www/jj-web-1-www.jj5.net-sixsigma
    Function: file.recurse
      Result: False
     Comment: #### /var/www/jj-web-1-www.jj5.net-sixsigma/vendor/james-heinrich/getid3/getid3/module.audio.ac3.php ####
              Source file 'salt://inst/mediawiki-1.29/vendor/james-heinrich/getid3/getid3/module.audio.ac3.php?saltenv=base' not found

              #### /var/www/jj-web-1-www.jj5.net-sixsigma/vendor/james-heinrich/getid3/getid3/module.audio-video.mpeg.php ####
              Source file 'salt://inst/mediawiki-1.29/vendor/james-heinrich/getid3/getid3/module.audio-video.mpeg.php?saltenv=base' not found
     Started: 14:27:18.352264
    Duration: 134735.945 ms
     Changes:
----------

The issue was that the source files mentioned weren’t in UTF-8 format. To convert the files I ran, e.g.:

$ iconv -f WINDOWS-1252 -t UTF-8//TRANSLIT < module.audio-video.mpeg.php.bak > module.audio-video.mpeg.php

(Actually I couldn’t get the ‘iconv’ command to work so I edited manually in Vim)

Installing .NET on Debian 9

After installing Visual Studio Code I followed the instructions from .NET Tutorial – Hello World in 10 minutes, basically:

wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget -q https://packages.microsoft.com/config/debian/9/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list

Then:

sudo apt-get update
sudo apt-get install dotnet-sdk-2.1

Then for example to create a new console project:

dotnet new console -o myApp
cd myApp

I ended up reading MICROSOFT SOFTWARE LICENSE TERMS for the MICROSOFT .NET LIBRARY which included this doozy:

The software may collect information about you and your use of the software, and send that to Microsoft.

Ah, Microsoft. You haven’t changed.

I found some notes about how to disable telemetry:

Telemetry
———
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn’t include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to ‘1’ or ‘true’ using your favorite shell.

Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

I have added the opt-out environment variable via jj5-bin.

Debugging JINJA in Salt Stack

So I was trying to figure out how to report the template source file within the template itself and I found myself wanting to know what was available in the JINJA globals for a Salt Stack JINJA template.

Turns out you use the show_full_context() function, like this:

Context is: {{ show_full_context() }}

You can parse the output to see what top-level items are available. In my case I found the ‘source’ setting for the JINJA template in use.

Hot tip: if you’re using Vim to inspect the show_full_context() output, try using ‘%’ or ‘]}’ to move between matching braces.

Bonus: while I was learning about reporting the JINJA context I discovered that you can call Salt functions from JINJA templates, like this:

# The following two function calls are equivalent.
{{ salt['cmd.run']('whoami') }}
{{ salt.cmd.run('whoami') }}