这两天翻出来了去年代收的 PolarFire SoC Icicle Kit。因为隔壁的 FPGA 大佬们看不上这块板子，我打算尝试物尽其用一下，目标只是用板子上的 RISC-V 核启动 Arch Linux RISC-V 的 rootfs 测试（把它当作一块 SD 卡槽没有问题、并且带 PCIE 的 HiFive Unleashed 来用。隔壁嵌入式群的大佬们：买椟还珠！）。如此便开始了年轻人的 FPGA 初体验（可能还是不能算）。
一开始尝试的当然是最新版的 Yocto 镜像，毕竟这是“官方”的 Linux 镜像。结果刷完后立刻遇到了启动失败：
一开始我还以为是 SD 卡坏了。在多次尝试未果后……
当时的猜测是（不一定对），可能因为板子上 FPGA 部分（抱歉，我不知道专业的称呼）不够新，所以我打算刷一下 HSS。结果这成为了噩梦的开始。
Continue reading 萌新的 PolarFire SoC Icicle Kit 初体验如果你想要运行一个发行版容器，而又不想被 docker 一类的重量级方案打扰，现在有一个新的简单方案了。
nspawn.org 目前提供了 Arch、CentOS、Debian、Fedora、Ubuntu 的各版本镜像，并可以直接用 systemd-nspawn 的验证机制进行签名验证。
推荐的用法是使用其提供的 “nspawn” 工具。下面以创建一个 Fedora 30 容器为例：
1、获取工具：
|
1 2 |
$ wget https://raw.githubusercontent.com/nspawn/nspawn/master/nspawn $ chmod +x nspawn |
2、获取 Fedora 30 镜像：
|
1 |
$ sudo ./nspawn init fedora/30/tar |
3、启动容器并获取 shell：
|
1 2 3 4 |
$ sudo machinectl start fedora-30-tar $ sudo machinectl shell fedora-30-tar Connected to machine fedora-30-tar. Press ^] three times within 1s to exit session. [root@fedora30 ~]# |
最近从公司淘了一块 GTX 1060，淘宝了一个显卡盒折腾 TB3 eGPU 方案。由于笔记本经常带出门，打算采用即插即用的 bumblebee 方案（回家插上盒子用独显，拔下盒子可以带出门，可以正常待机不用重启）。下面记录一下 Arch 上配置的步骤和遇到的坑。
|
1 |
# pacman -S bumblebee primus lib32-primus nvidia-dkms lib32-nvidia-utils bolt |
修改 /etc/bumblebee/xorg.conf.nvidia，在 Section “Device” 中加入：
|
1 |
Option "AllowExternalGpus" "true" |
修改 /etc/bumblebee/bumblebee.conf，在 [optirun] 中修改：
|
1 |
Bridge=primus |
作为一个年轻和小众的社区（咳咳），Arch Linux 社区中有着许多不成文的约定。本文希望通过稍稍讲解一二，来消除一些新人们常常感到的困惑。由于预感到日后可能还会有更多问题，暂且认为这是系列里的第一篇 😛
仓库里一般的包可能有一个或多个维护者，也可能没有维护者，成为“孤儿”。如果坏掉或者过期的包是一个孤儿，申请从仓库里删掉是更有效的方法，这样它可以在 AUR 找到新的主人。发邮件到 aur-general 解释一下情况，并表明自己或者别人想维护它，一般都会很快得到解决。
如果“坏”包有维护者，但他太忙了呢？这种情况下，这个包很可能已经在 Bug Tracker 里泥足深陷。这种时候可以通过帮维护者一个小忙的方式来促进问题的解决。如果有人找到了上游 Bug Report，并且上游已经修复提供了 patch 的话，可以考虑把 patch 贴到 Arch 的 Bug Tracker；如果这件事已经有人做了，可以修改 PKGBUILD 打上 patch，然后把改好的 PKGBUILD 贴上去；如果连 PKGBUILD 都有人准备好了，而且过去了一段时间的话，可以考虑把这份准备好的 srcpkg 或者 diff 直接发邮件给维护者，附上简短的感谢和一个笑脸 🙂
同样的道理，如果一个过期包已经被标记过期很久了，也可以准备一个新版的 PKGBUILD 发邮件给维护者。 Continue reading Arch Linux 社区中不成文的约定（一）
大概很多人还不知道，在老K同学偷偷默默开发了很久后，新一代的 fcitx5 已经“能用”了。不过因为还处在早期开发阶段，现在只有拼音输入法能用，而且输入界面极挫，没有配置界面和任何命令行帮助信息等。
先来一段 demo：
下面简单介绍一下 Arch 里的安装及配置方法：
首先从 AUR 中安装相关的软件包：
|
1 |
yaourt -S fcitx5-git fcitx5-qt-git fcitx5-gtk-git fcitx5-chinese-addons-git |
依赖中其他的相关包会被 yaourt 自动安装。如果你更喜欢手动安装，可以参考下面的顺序：
xcb-imdkit-git -> fcitx5-git -> libime-git -> fcitx5-chinese-addons-git -> fcitx5-gtk-git -> fcitx5-qt-git
注意原来的 fcitx 和这系列软件包冲突，可能会被提示卸载。 Continue reading 尝鲜可能比 sunpinyin 好一点的新拼音输入法
devtools 是 Arch Linux 开发者们用来往官方仓库里推进软件包使用的一系列工具。由于里面有许多工具可能不是我们常用的，这里主要介绍里面的一部分——用于在干净的环境中编译软件包的命令。
为什么要在干净的环境里编译软件包？这里有几个常见的理由：
如果你有这样的需求，可以考虑使用 devtools。安装过程很简单
|
1 |
pacman -S devtools |
这是一篇简化的教程，如果你有一个喜爱的 Python 模块不在 Arch 仓库里，AUR 里也没有，可以尝试读下去。
对 Python 模块来说，一般仅仅一个 PKGBUILD 文件就足以完成所有的事情。现在你可以打开你最喜欢的文本编辑器，把下面这一个简单的 PKGBUILD 模板复制进去：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
# $Id$ # Maintainer: Felix Yan <felixonmars@archlinux.org> pkgbase=python-whatever pkgname=('python-whatever' 'python2-whatever') pkgver=0.4.3 pkgrel=1 pkgdesc='Easy way to make anonymous functions by partial application of operators' arch=('any') license=('BSD') url='https://github.com/Suor/whatever' makedepends=('python-setuptools' 'python2-setuptools') checkdepends=('python-pytest-runner' 'python2-pytest-runner') source=("$pkgbase-$pkgver.tar.gz::https://github.com/Suor/whatever/archive/$pkgver.tar.gz") sha512sums=('162d66753ef4fb15279150b7fa953b4ecf086e2b36cc77531dac099ff4a25b3458af627bdf52e168b7b4b2163a1445f35c2c656b1c10c0c73502d2357ba42dd8') prepare() { cp -a whatever-$pkgver{,-py2} } build() { cd "$srcdir"/whatever-$pkgver python setup.py build cd "$srcdir"/whatever-$pkgver-py2 python2 setup.py build } check() { cd "$srcdir"/whatever-$pkgver python setup.py pytest cd "$srcdir"/whatever-$pkgver-py2 python2 setup.py pytest } package_python-whatever() { depends=('python') cd whatever-$pkgver python setup.py install --root="$pkgdir" --optimize=1 install -D -m644 LICENSE "$pkgdir"/usr/share/licenses/$pkgname/LICENSE } package_python2-whatever() { depends=('python2') cd whatever-$pkgver-py2 python2 setup.py install --root="$pkgdir" --optimize=1 install -D -m644 LICENSE "$pkgdir"/usr/share/licenses/$pkgname/LICENSE } # vim:set ts=2 sw=2 et: |
因为距离 Python 2 的废弃时间（2020年）还早，Arch 仓库中的 Python 模块包通常同时提供 Python 2/3 模块。上面例子里的 Python 软件包名叫 whatever，这也同样是它在 PyPI 中的名字。如果原来的包名中包含大写字母，在制作软件包时需要改成小写。 Continue reading 给 Arch 打一个包 – Python 模块篇
昨晚我大概没有把硬盘插紧，零点（一堆计划任务执行时）在 dmesg 里看到了大量 ext4/SATA 错误。今天开机时 BIOS 直接提示没有可引导的设备。下面记录了我所有的测试和恢复步骤：
至此，虚惊一场的数据丢失已经完全恢复，总共历时 1 个小时（前面大量的时间花在了让备份盘能启动起来，上一次备份出现了一点差错……）。
最后赞美一下坚强的 ext4！
Pacman 5.0 带来了 Hooks 支持，但在大规模应用前，我们留出了一个多月的时间来让用户先升级到 Pacman 5.0（因为同时升级 pacman 和有定义 hooks 的包会导致无法正常执行这些 hooks）。现在距离 Hooks 正式投入使用已经过去了一个月，我觉得是时候介绍一下 Hooks 和如何使用它了。
先来看一个简单的 Hook:
|
1 2 3 4 5 6 7 8 9 10 11 |
[Trigger] Type = File Operation = Install Operation = Upgrade Target = usr/lib/tmpfiles.d/*.conf [Action] Description = Creating temporary files... When = PostTransaction Exec = /bin/sh -c 'while read -r f; do /usr/bin/systemd-tmpfiles --create "/$f"; done' NeedsTargets |
这个 Hook 的作用是：当检测到安装或更新的包文件中存在 usr/lib/tmpfiles.d/*.conf 时，在更新后对每个文件调用 systemd-tmpfiles --create 方法。前面的检测部分定义在 [Trigger] 部分，后面执行的操作定义在 [Action] 部分。下面我们分别了解一下这两部分。
首先需要了解的是可以用于触发的条件类别（Type）。上面的例子里使用了文件（File），即当操作中的包中存在对应文件时触发。另一个可选的 Type 是软件包名（Package），即直接匹配操作中的包名。
接下来，操作（Operation）选项限制了对软件包的操作类别。可以选择的操作有安装（Install）、更新（Upgrade）和删除（Remove）。一个 Hook 需要在多种操作执行时，如例子中那样写成多行即可。常用的组合有三种全部写上（更新缓存、数据库等）、写 Install+Upgrade（执行安装时的一次性操作）及与之对应的 Upgrade+Remove（卸载时的一次性操作）。
最后，我们需要定义具体的目标（Target）。如果目标是文件，这里需要写其相对根目录的完整路径，但需要去掉开头的 / 字符。通配符（*、?）可以使用，具体匹配时会使用 fnmatch 方法。同样的，在一个 Hook 中可以定义多个目标，类似例子中的 Operation 那样写成多行即可。
Continue reading Pacman Hooks 简介
Arch Linux 中的 [testing]、[community-testing] 和 [multilib-testing] 三个仓库构成了 [testing] 系列仓库。由于网上许多地方对 [testing] 系列仓库存在一定的误解，我作为一只开发者，想藉此文介绍一下 [testing] 系列仓库。
一、[testing] 系列仓库里有哪些包？
主要有三类，按照数量排序应该是：由 soname 等 TODO 产生的大批完全未经测试的包；重要软件包、软件集合的更新、不靠谱上游推出的新版本、上游大版本更新等维护者虽然测试过但是不敢肯定没问题的包；因为维护者没有时间等情况而完全未经测试的包。注意，这里多数的情况都是完全未经测试的包，keep in mind。
二、什么情况下软件包会留在 [testing] 系列仓库里很长时间？
主要也有三类：没人测试给 signoff 的；已知有问题但还未修复或不知道怎么修复还在研究的；维护者明明拿到 signoff 了（针对目标仓库是 [core] 的情况）或明明不需要 signoff（针对所有除了 [core] 以外的仓库）但还是觉得没把握的。简单来说，一般情况下你想用的新版软件不会在 [testing] 系列仓库里停留超过一个星期，除非它已经被发现有问题了。
三、开 [testing] 系列仓库需要满足什么条件？
最后，如果读到这里还没被我吓跑，欢迎你像我一样启用 [testing] 系列仓库，并把发现的问题报告到 Arch Linux Bug Tracker。