Category Archives: Uncategorized

OverDrive Account No Longer Able to Be Used for Library Sign In

OverDrive for Libraries recently changed their platform to no longer allow sign-in with an OverDrive account. The end result is that you must log in with your library card number and PIN code instead. This change took place with no public announcement that I could find on their website or social media channels. The “What’s the difference between an OverDrive account and a library card?” help article removed this language sometime between 13 AUGUST 2019 02:50 PM and 19 AUGUST 2019 02:06 PM:

An OverDrive account:

Lets you sign into your library’s digital collection

Can be used to sign into multiple libraries

Apple pwnz u

In order to delete an Apple ID, you first must have access to the device that is associated with it. Then you have to get an activation code through Apple’s website from that device through the network, and submit a form and wait up to 7 days, during which time they retain the right to refuse your deletion request based on no particularly detailed policy. Once you have verified that your account is deleted from the device, you may no longer log in with your Apple ID to wipe the device. Catch 22. Apple pwnz u.

Moral of the story: remove your device from the account before requesting account deletion, then log out of your Apple device and “trust” Apple to delete your account.

Vue.js and self-closing tags

Self-closing tags don’t (usually) work in DOM-based (in-browser) Vue template code, but they do work from single-file (.vue file) templates that are run through a preprocessor. Some documentation assumes the use of .vue files and provide self-closing tags in their example code. If you copy and paste self-closing tags from documentation examples into browser-based code they may not work as expected. The solution is to add a separate closing tag for each element.

I recently ran into this problem while trying out bootstrap-vue tables. Using the example code, the b-btn (clear button) in the b-input-group-append would not exist until I closed the preceding b-form-input tag.

Here’s the relevant section from the Vue style guide:
Self-closing components

Explicitly allowing a third-party deb repo to change its origin name

I went to pray to the dist-upgrade gods today and must have angered them:
...
Reading package lists... Done
E: Repository 'http://dl.google.com/linux/chrome/deb stable Release' changed its 'Origin' value from 'Google, Inc.' to 'Google LLC'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

I read the apt-secure manpage; it has many grammatical errors but absolutely no information about how to explicitly accept this change of origin name.

The solution is found in the apt-get manpage:

--allow-releaseinfo-change
           Allow the update command to continue downloading data from a repository which changed its information of the release contained in the repository indicating e.g a new major release. APT will fail at the update command for such repositories until the change is confirmed to ensure the user is prepared for the change. See also apt-secure(8) for details on the concept and configuration.

           Specialist options (--allow-releaseinfo-change-field) exist to allow changes only for certain fields like origin, label, codename, suite, version and defaultpin. See also apt_preferences(5). Configuration Item: Acquire::AllowReleaseInfoChange.

TL;DR: the solution is simple:
apt-get --allow-releaseinfo-change-origin update

MediaWiki error Fatal exception of type “Wikimedia\Rdbms\DBQueryError”

It’s been quite some time since I used my local MediaWiki installation. I went to log in today to my wiki and was greeted with a strange error:
Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

No details were provided even though I have set:
$wgShowSQLErrors = true;
$wgDebugDumpSql = true;

I then added this to my LocalSettings.php file:
$wgShowDebug = true;

That output finally gave me a clue – I needed to update my database schema! From there it was as easy as visiting /mw-config on my wiki and adding a one-time use key to my LocalSettings.php to upgrade the database.

References:
https://www.mediawiki.org/wiki/Manual:How_to_debug
https://www.mediawiki.org/wiki/Manual:Upgrading

UASP adapter seen by smartctl as unknown USB bridge

I recently bought a generic USB 3.0 to M.2 adapter. It has a JMicron JMS567 chipset that very recently had a quirk added to the Linux kernel that fixes UAS support. Even with this patch, smartctl returns:

/dev/sdb: Unknown USB bridge [0x152d:0x0578 (0x508)]
Please specify device type with the -d option.

This can be fixed by telling smartctl that it is a SCSI to ATA Translation (SAT) device:

smartctl -a /dev/sdb -d sat

Alpaca Forms (alpacajs) and adding another button that is only enabled when the form is valid

The submit button is disabled by default in Alpaca Forms until the form passes validation. You can add more buttons easily (see the documentation on forms) but having them share this behavior isn’t straightforward. The answer is to add the class ‘alpaca-form-button-submit’ to the button using the ‘styles’ property:

'form': {
        'attributes': {
            'id': 'alpaca_form'
        },
        'buttons': {
            'another_button': {
                'label': 'Clickable when valid',
                'click': function(e) {
                    do_something();
                },
                'styles': 'alpaca-form-button-submit'
                }
            }
        }
}

For a full explanation, search for the enableSubmitButton and adjustSubmitButtonState functions in the source code.