The most recent version of Wine is named wine-development in Ubuntu 22.04 repository, while in WineHQ repository it is named wine-devel ¹. This causes problem when installing packages depending on Wine and want the most recent version, e.g. carla-bridge-wine32.

One workaround is to use a dummy package using “equivs”:

1. install equivs
2. run equivs-control wine-devel-fixes
3. edit control file, related lines:

   Package: wine-devel-fixes
   Depends: wine-devel
   Provides: wine-development
   Description: Fixes the Wine package rename on Ubuntu 22.04
   

4. run equivs-build wine-devel-fixes
5. install the generated wine-devel-fixes_1.0_all.deb

Reference: workaround ROCm installation on Ubuntu 22.04 (when it didn’t support): https://github.com/ROCm/ROCm/issues/1730#issuecomment-1205109513

It is known that there’s make rpm-pkg -j${nproc} / make deb-pkg -j${nproc} that helps build and package Linux kernel, but on RHEL-like distros the default package name is still kernel and kernel-devel, causing conflict with existing kernels from repository.

So renaming the output package seems required, and here is one kind of patch:

• • • >>

To build KDE 6 on Ubuntu 22.04, other than steps on https://community.kde.org/Get_Involved/development/Build_software_with_kdesrc-build, there are other things need to be noticed:

• Qt6 in apt repo is not new enough, should let kdesrc-build build Qt6; follow instruction at https://community.kde.org/Get_Involved/development/More#Build_Qt6_using_kdesrc-build, and notice some packages are required to build some parts (see below)
• gpgme fail to build, check https://community.kde.org/Get_Involved/development/More#kdesrc-build_issues, or use environment variable to help pkg-config find Qt 6. Notice this should point to installed location, like

export PKG_CONFIG_PATH=/opt/kde/usr/lib/pkgconfig:$PKG_CONFIG_PATH

• • • >>

情况: Git 远程服务器 (例如 GitLab 实例) 位于内网, 需要能从外部访问.

Situation: Git remote server (e.g. GitLab instance) is in private network but need to access from outside.

一种解决方案: 用 ssh 打开隧道, 例如

One solution: open tunnel using ssh, like

Host jumper-machine
  # ...
  LocalForward 3002 10.1.2.233:80
  LocalForward 3003 10.1.2.233:33322

在用 ssh jumper-machine 开启隧道后, 即可使用 http://localhost:3002 访问 Git 远程服务器的网页, ssh://git@127.0.0.1:3003/<user>/<repo> 可作为 Git 仓库的远程地址.

After opening tunnel using ssh jumper-machine, use http://localhost:3002 to visit webpage of Git remote server, use ssh://git@127.0.0.1:3003/<user>/<repo> as Git remote url.

When processing continuous observation of more than 1 day, an error occurred from DSPSR:

Error::message
        epoch 60230.28412758417979894210 not spanned by ChebyModelSet

The error is related to TEMPO2 wrapper T2Predictor, where TEMPO2 complains ChebyModelSet_OutOfRange. This points to the command line of DSPSR calling TEMPO2, which does have a span of one day:

tempo2 -npsr 1 -f pulsar.par -pred "fast 60229.283869345 60230.283869345 200.006942749023438 350.006942749023438 12 2 3599.9999999999998" > stdout.txt 2> stderr.txt

Further searching shows the time span comes from dspsr/Signal/Pulsar/Fold.C, line 243. Changed this magic number

diff --git a/Signal/Pulsar/Fold.C b/Signal/Pulsar/Fold.C
index 009c1615..0c5c42f9 100644
--- a/Signal/Pulsar/Fold.C
+++ b/Signal/Pulsar/Fold.C
@@ -262,7 +262,7 @@ dsp::Fold::get_folding_predictor (const Pulsar::Parameters* params,
  /*
   * Tempo2 predictor code:
   *
   * Here we make a predictor valid for the next 24 hours
   * I consider this to be a bit of a hack, since theoreticaly
   * observations could be longer, and it's a bit silly to make
   * such a polyco for a 10 min obs.
   *
   */
-  MJD endtime = time + 86400;
+  MJD endtime = time + 10*86400;
 
   generator->set_site( observation->get_telescope() );
   generator->set_parameters( params );
   generator->set_time_span( time, endtime );

so folding can be done further.

• • • >>