Notes about open source software, computers, other stuff.

Tag: Debian (Page 1 of 3)

Pinning the Wine package version so I can keep using the reMarkable Windows app

Back in January 2021 I ordered the reMarkable 2 e-paper note-taking “tablet”. I use it for two things: making notes and reading and annotating PDFs. Especially the note taking has changed significantly my working environment: no more stacks of paper notes lying all over my desk. No more trying to find a certain note in a notebook or on a piece of paper.

I do miss using my fountain pen, but the advantages, including having all your notes with you on your phone outweighs this. And, although the remarkable itself runs Linux, there is no Linux version of the desktop app. Unfortunately.

For some time I used community-developed tools, mainly to up- and download PDFs to and from the device. However, as the reMarkable software and file format evolved, more and more things stopped working, so I had to shift to another solution. I managed to install the Windows application in Wine. This works well and also allows me to e.g. share my reMarkable screen in video calls.

A few weeks ago, however, the app failed to start. I wasn’t sure if this was due to an update of the remarkable app itself or because the Wine version in Ubuntu 24.04 was upgraded from version 9.22 to 10.0rc2. It turned out to be the latter because my laptop definitely had an older (previously known good) version of the app that hadn’t been updated. Updating the Wine winehq-devel package, however, broke the app (a bug has been reported, see the list of links below).

Now, as you may have noted above, I was using the winehq-devel package, so I thought it was as simple as switching to the winehq-stable package. Unfortunately, that package is not available in Ubuntu 24.04. While looking for deb packages I found that the Wine HQ repo contained older package versions. So I decided to use the package pinning functionality of the Apt packaging system. I created the file /etc/apt/preferences.d/wine with the following contents:

Package: winehq-devel
Pin: version 9.*
Pin-Priority: 1000

Package: wine-devel
Pin: version 9.*
Pin-Priority: 1000

Package: wine-devel-amd64
Pin: version 9.*
Pin-Priority: 1000

Package: wine-devel-i386:i386
Pin: version 9.*
Pin-Priority: 1000

I determined the required package names by starting with the first one and then kept trying to install the winehq-devel package until it actually finished successfully. I set the pin priority to 1000, which means “causes a version to be installed even if this constitutes a downgrade of the package”, according to the apt_preferences man page. And, indeed, that is what Apt proposes:

The following additional packages will be installed:
  wine-devel wine-devel-amd64 wine-devel-i386:i386
The following NEW packages will be installed:
  winehq-devel
The following packages will be DOWNGRADED:
  wine-devel wine-devel-amd64 wine-devel-i386:i386
0 upgraded, 1 newly installed, 3 downgraded, 0 to remove and 15 not upgraded.
Need to get 229 MB of archives.
After this operation, 8.414 kB disk space will be freed.
Do you want to continue? [Y/n]

For completeness, these are the Wine packages that are currently installed on my system:

ii  wine-devel                                       9.22~noble-1                                amd64        WINE Is Not An Emulator - runs MS Windows programs
ii  wine-devel-amd64                                 9.22~noble-1                                amd64        WINE Is Not An Emulator - runs MS Windows programs
ii  wine-devel-i386:i386                             9.22~noble-1                                i386         WINE Is Not An Emulator - runs MS Windows programs
ii  winehq-devel                                     9.22~noble-1                                amd64        WINE Is Not An Emulator - runs MS Windows programs

As a side note, in order to make sure no other Wine settings were influencing my tests, I installed the reMarkable application in a fresh, dedicated WINEPREFIX:

WINEPREFIX=~/reMarkable/ wine ~/tmp/Downloads/reMarkable-3.16.1.901-win64.exe

After which I could start the application like this:

WINEPREFIX=~/reMarkable/ wine ~/reMarkable/drive_c/Program\ Files\ \(x86\)/reMarkable/reMarkable.exe

After this fresh install, the Gnome shell menu entry for the app didn’t work any more, so I had a look at the corresponding .desktop file in ~/.local/share/applications/wine/Programs/reMarkable/reMarkable.desktop. After some playing around I guess the problem was in missing double quotes around the path to the .exe file. The following works:

[Desktop Entry]
Name=reMarkable
Exec=env WINEPREFIX="/home/lennart/reMarkable" wine "/home/lennart/reMarkable/drive_c/Program Files (x86)/reMarkable/reMarkable.exe"
Type=Application
StartupNotify=true
Path=/home/lennart/reMarkable/dosdevices/c:/Program Files (x86)/reMarkable
Icon=94BF_reMarkable.0
StartupWMClass=remarkable.exe

Related Images:

Installing parted during Ubuntu installation

When installing Ubuntu (I guess a regular Debian installation won’t be any different), I sometimes would like to manually create or change partitions (by jumping to another terminal, e.g. using Alt-F2) before doing the actual install. My preferred tool for that is parted, however, on regular Ubuntu installation images (at least the server variety), parted isn’t available from the console by default.

Today I noticed that (at least on today’s daily image of Ubuntu 16.04 Xenial), a udeb file for parted is available. This is how you install it:

udpkg -i /cdrom/pool/main/p/parted/parted-udeb_3.2-15_amd64.udeb

after which you can use parted to your heart’s content.

For more information on udebs see the Debian Installer Internals documentation.

Related Images:

Setting the console font when using an nVidia card

Even though I do most of the work I do on my workstation in a graphical desktop environment, I sometimes want or need to switch to one of the virtual terminals (consoles), for example when trying to fix a connection problem or hanging desktop environment.

Whenever I had to do this I was always bothered by the fact that the font was so large (or, the other way around, the resolution so low). What made my annoyance worse was that I knew from my early Linux days So, instead of being annoyed I decided to fix this. Thanks to the help of mchid on unix.stackexchange.com I solved in a matter of minutes. The tricky part for me was to realise I am using an nVidia graphics card, which means things are just a little bit different than normally.

Just in case StackExchange ever goes down or this answer gets lost I will reproduce it below.

For newer Debian & Ubuntu distros using nvidia, I had to do the following: First, edit /etc/default/grub. Change the following line:

#GRUB_GFXMODE=640x480

to this:

GRUB_GFXMODE=1920x1200
GRUB_GFXPAYLOAD_LINUX=keep

replacing 1280×800 with the desired resolution.

Then:

echo "echo FRAMEBUFFER=y" | sudo tee /etc/initramfs-tools/conf.d/splash
sudo update-initramfs -u
sudo update-grub

To simply change the font size, you can do so using the following command:

sudo dpkg-reconfigure console-setup

Related Images:

Fixing font errors when running qmon on a remote server

Sun Grid Engine (SGE) is a bath queue system that can be used to distribute computation intensive tasks across one or more servers/CPUs. SGE has a graphical configuration utility called qmon, but when you start it on a remote machine (using SSH), you may end up with errors like this:

Warning: Cannot convert string "-adobe-courier-medium-r-*--14-*-*-*-m-*-*-*" to type FontStruct
Warning: Cannot convert string "-adobe-courier-bold-r-*--14-*-*-*-m-*-*-*" to type FontStruct
Warning: Cannot convert string "-adobe-courier-medium-r-*--12-*-*-*-m-*-*-*" to type FontStruct
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  45 (X_OpenFont)
  Serial number of failed request:  329
  Current serial number in output stream:  340

The warnings are not really a problem, but the error is. It can be solved by running the following on the client (i.e. your local) machine (assuming it runs Debian or Ubuntu):

sudo apt-get install xfonts-75dpi
xset +fp /usr/share/fonts/X11/75dpi
xset fp rehash

Related Images:

Using SSH for WordPress updates via the web interface

Note to self: if you want to be able to upgrade WordPress via the web interface using SSH, you need to have the libssh2-php package installed on Debian/Ubuntu Linux.

Don’t forget to restart Apache after installing the package. Reload the WordPress admin pages and you’ll see the SSH option added.

Related Images:

ProbABEL v0.4.2 released

During the Christmas holidays I released a new version of ProbABEL (v0.4.2). The official release announcement can be found here. ProbABEL is a toolset that allows running GWAS (Genome-Wide Association Studies) in a fast and efficient manner. It implements regression using the linear, logistic or Cox proportional hazards models.

This version is mostly a bug fix release. The most important user-visible change is the fact that the ‘official’ name for the wrapper script that runs a GWAS over a range of chromosomes is now called probabel instead of probabel.pl. This change was induced by my attempts to get ProbABEL packaged in the Debian Linux repositories. One of the warnings that occurred during the package creation process was a Lintian warning that said that scripts with ‘language extensions’ are not allowed. There are several reasons for that, but the one I found most compelling was the fact that the user shouldn’t be concerned with the programming/scripting language we used to write it in. Moreover, being ‘agnostic’ in this matter also allows us to write such a script in a different language.
Of course, we have left the original name in place (via a symlink) in order not to disrupt any current pipelines. If the user runs the script with the old name a warning appears, urging him/her to start using the new name and that the old name will be deprecated in the future.

In the mean time, ProbABEL v0.4.1 has been accepted in Debian (unstable) and as of today it is also available in Debian ‘testing’. Lots of thanks to the Debian Med team that helped me a lot in preparing the .deb package. Note that the package has been split up in probabel (architecture-dependent files) and probabel-examples (with architecture independent files: the examples). See the Debian Package Tracking System page for ProbABEL for more details of the package.

From Debian the package has trickled down to Ubuntu as well (Launchpad page here), so it will be available by default in the next Ubuntu release (14.04, a.k.a. Trusty Tahr).

Related Images:

Puppet commands change when upgrading to v3.0.0

After upgrading Puppet from versions < v3 to version 3.0.0 or higher, the main commands have changed, keep this in mind when reading my earlier post. From the ChangeLog:

Pre-2.6 Post-2.6
puppetmasterd puppet master
puppetd puppet agent
puppet puppet apply
puppetca puppet cert
ralsh puppet resource
puppetrun puppet kick
puppetqd puppet queue
filebucket puppet filebucket
puppetdoc puppet doc
pi puppet describe

Some examples

To run puppet on a client puppetd --test is changed to:

puppet agent --test

To show a list of clients waiting for signing of their certificates run the following on the master:

puppet cert list

instead of puppet ca -l. To list all certificates, run (on the master):

puppet cert list --all

To completely remove a client’s certificate on the master run:

puppet cert clean client.localdomain

and to sign a client certificate on the master run:

puppet cert sign client.localdomain

Related Images:

ProbABEL v0.4.1 released

Last week I released v0.4.1 of ProbABEL, just a few days after releasing v0.4.0, which contained a small, but irritating bug.

This release took quite some time to create, but features quite a few bug fixes, including a major one: for the first time since the filevector format was introduced somewhere in 2009/2010, the Cox proportional hazards regression module works with filevector/DatABEL files. This is a major step forward, because up till now we had to maintain two branches of code: trunk, with all the regular updates and improvements, and the old branch that contained the Cox PH module that was only capable of reading text files.

Another notable change is the incorporation of \chi^2 values in the output files. At the moment these are based on the LRT (likelihood ratio test), except where that doesn’t make sense (e.g. when using the --mmscore option. The implementation was relatively easy, because part of the code was still there from previous versions; it was disabled however, because it didn’t deal with missing genotype data. Now it does. Using the LRT is also easier in the case of the 2df (or genotypic) genetic model, where using the Wald test is not straightforward.

The third user-visible change was a change in the [code]probabel.pl[/code] script that hides some of the details (e.g. the location of the files with genotype data) of running a regression for the user. Previously, using the -o option meant that the output file name was constructed from the name of the phenotype file, the argument of the -o option and a fixed extension that depends on the model(s) being run. Starting with v.0.4.0 this behaviour has changed. If the -o option is specified its argument is used as the start of the output file name, with only the fixed extension appended to it. This allows users to specify output in a different directory than the one where the phenotype file was created.

Packages for Ubuntu Linux (or one of its derivatives and probably also Debian) can be found in the GenABEL PPA (personal package archive). Previously we also released pre-compiled Windows binaries, but I’ve stopped doing that. They were never tested anyway, and I think there isn’t much demand for them anyway. Most people who do genome-wide association studies use Linux servers anyway.

Development of ProbABEL (and other members of the GenABEL suite) takes place on this R-forge page. If you are in search of an open source project to contribute to, feel free to contact us!

User support for the GenABEL suite can be found at our forum.

Related Images:

Using BibTeX from org-mode

I use Emacsorg-mode a lot for writing notes, todo lists, presentations and writing short reports. Recently I started writing a larger report which I normally would have done in LaTeX. This time, since the notes related to the project were already in org format, I decided to write the whole report in org-mode. The one thing I needed for that was using BibTeX bibliographies (and RefTeX) from org-mode. A quick web search revealed that that can easily be done by adding the following to your .emacs file:

;; Configure RefTeX for use with org-mode. At the end of your
;; org-mode file you need to insert your style and bib file:
;; \bibliographystyle{plain}
;; \bibliography{ProbePosition}
;; See http://www.mfasold.net/blog/2009/02/using-emacs-org-mode-to-draft-papers/
(defun org-mode-reftex-setup ()
  (load-library "reftex")
  (and (buffer-file-name)
       (file-exists-p (buffer-file-name))
       (reftex-parse-all))
  (define-key org-mode-map (kbd "C-c )") 'reftex-citation)
  )
(add-hook 'org-mode-hook 'org-mode-reftex-setup)

After that, RefTeX works, but exporting the org document to PDF (via LaTeX) didn’t include the bibliography entries. A quick look at the error log showed that bibtex hadn’t been run, so the question was: how to tell org-mode to do that too when exporting. The answer is to tell org-mode to use the latexmk Perl script (on Debian/Ubuntu it is easily installed from the package repositories) when exporting to PDF. I added the following lines to my .emacs file:

;; Use latexmk for PDF export
(setq org-latex-to-pdf-process (list "latexmk -pdf -bibtex %f"))

Related Images:

Setting up (or fixing) an encrypted swap partition

Today I tried to clone my laptop’s harddrive to a new drive (thanks to Lenovo for sending me a replacement since the old drive was showing signs of breaking down). At first I tried dd, but that failed at around 90%, either because the old disk is indeed failing or because something fishy with the USB connection or enclosure in which I put the new disk. So I started gparted to check which partitions were copied OK and which weren’t. It turns out that all partitions were fine, except for my (encrypted) swap partition. gparted didn’t even recognise the partition type (on the original drive!). So after I replaced the harddrive I wanted to recreate the encrypted swap partition. It turn’s out to be easy if you follow the steps outlined in this blog post from Puny Geek. Thanks Puny Geek!

Related Images:

« Older posts

© 2025 Lennart's weblog

Theme by Anders NorĂ©nUp ↑