随着 openSUSE Leap 15.1 和 SLE-15-SP1 即将发布，SUSE 的 YaST 团队正在投入大量时间来完善细节并修复小的（以及不那么小的）错误。 但幸运的是，这仍然给我们留出了足够的时间来处理我们的中期目标。
所以欢迎阅读我们通常精选的错误修复（列出所有错误会很无聊）和令人兴奋的新功能。 本期内容包括
- 一份关于报告 Snapper 错误的实用指南
- 大量针对阿拉伯语等从右向左语言的修复
- 存储区域的一些调整和改进
- 对 yast2-network 代码未来发展方向的抢先预览
- 一些面向贡献者的内容：例如我们新的拉取请求模板和为测试重新设计的 Docker 镜像
Snapper 错误报告指南
在此冲刺期间，我们修复了一个导致 Snapper 在非常特殊情况下崩溃的错误。 该场景非常不寻常，因此我们不得不从报告错误的提交者那里请求大量信息来确认发生了什么。 作为一种很好的结果，除了现在拥有更健壮的 Snapper（消灭了一个错误）之外，您还可以享受 openSUSE wiki 中的新页面，其中列出了您在在使用 (open)SUSE 时发现 Snapper 中的错误时应附加的信息。
这也为提醒您关于等效的 "报告 YaST 错误" 页面提供了一个很好的借口。
YaST 环游世界……朝各个方向
许多 YaST 用户和我们的博客读者都不是以英语为母语的人，他们肯定会欣赏 YaST 和 (open)SUSE 可以使用多种语言的事实。 但您有没有想过开发多语言软件的含义？ 确定？在所有语言中？ 
人类语言与人类文化一样多样，需要考虑许多细节，从使用不同的字母到处理性别或数字的各种方式（在英语中，单词只有一个单数形式和另一个复数形式，但在其他语言中可能会复杂得多）。 在今天的文章中，我们将关注我们最喜欢的翻译问题之一——从右向左书写的语言，例如阿拉伯语。
处理混合了拉丁文和阿拉伯文脚本的文本很复杂，有时我们不得不处理有趣的错误。 幸运的是，我们有自己的武器来对抗这些错误。 如果在星球大战中他们有像 C3PO 这样的协议机器人，那么在 YaST 团队中，我们有 Martin Vidner，他是最接近的人类等价物。
他修复了所有报告的错误，甚至创建了一个工具来帮助调试未来类似的问题。 您可以在 Github 上找到 该工具的源代码。 甚至还有一个 托管实例，供翻译人员或任何好奇的人使用。
现在，即使像我们的分区程序这样的复杂界面在从右向左的语言中看起来也足够正确，因此我们不必向所有阿拉伯语用户发送镜像。
如果您想了解更多关于这个令人兴奋但非常复杂的问题——双向文本，您可以从以下文档开始。
- Martin 的精彩总结，关于在 YaST 中发现的问题类型及其各自的解决方案。
- 维基百科：双向文本，一个概念概述
- Unicode 标准附录 #9：Unicode 双向算法，详细内容，有 50 页。
在相关新闻中，我们也收到了一些关于在未来 SLE-15-SP1 的 beta 版本中，韩语显示项目符号存在问题的报告。 但正如我们所验证的，所有这些问题现在都已消失。
存储修复
在此冲刺中受到关注的另一个领域是存储管理。 三个相关功能在即将发布的 (open)SUSE 版本之前需要进行调整
- 修复了分区程序警告中启动磁盘的检测。
- 引导式设置现在在不同磁盘上进行多次尝试时效果更好。
- AutoYaST 现在可以通过 NFS 安装。
YaST 团队开发的最后一个存储功能是在专家分区程序中对 Bcache 设备的支持。 在我们的 QA 团队测试时，他们发现了一个错误。 分区程序抱怨启动磁盘不包含分区表，这是 Legacy (非 UEFI) x86 系统的强制条件。 但这是一个错误的警告，因为他们实际上在另一个磁盘上定义了一个 /boot 分区。
这就是我们发现我们的分区程序在 /boot 位于与根文件系统不同的磁盘上时会感到困惑的原因。 分区程序坚持认为包含 / 的磁盘将用于启动，而不是检查包含 /boot 的磁盘的结构。 现在已修复此问题，改进将在即将发布的 SLE 15 SP1、Leap 15.1 以及当然 openSUSE Tumbleweed 中提供。
但不仅仅是存储错误在即将发布的版本中得到修复。 在几轮冲刺之前，初始提案的存储提案算法被修改为尝试在每个单独的磁盘上安装。 如果即使在禁用所有可选配置（例如快照和单独的 /home）之后，在给定磁盘上无法安装，则会尝试在下一个磁盘上进行新的提案，依此类推。 问题是先前尝试中禁用的选项在切换到下一个磁盘时没有恢复。 这导致了一些难看的副作用，例如，如果交换分区在尝试第一个磁盘时被禁用，那么在对下一个磁盘进行提案时，该提案不会尝试创建交换分区。 但现在也已修复，并且将按预期工作。
最后但并非最不重要的一点是，AutoYaST 现在支持通过网络文件系统 (NFS) 安装。 此功能在 SLE 15 GA 的新 YaST 存储堆栈重新实现时遗漏了。 实际上，这是一个未记录的功能。 这就是为什么我们忽略了 SUSE 12 可以使用一些技巧和无效的 AutoYaST 配置文件来做到这一点。 但不用担心，该功能再次可用，并且这样的配置文件现在可以在任何更新的 SLE-15 或 Leap 15.0 中工作。 当然，它也将在安装 SLE-15-SP1 或 openSUSE Leap 15.1 和 Tumbleweed 时工作。
尽管如此，我们正在努力寻找一种更好且记录在案的方法来支持未来的场景，而无需扭曲 AutoYaST 配置文件的规范。 请关注更多信息。
重新思考特殊启动分区的放置位置
现在存储层看起来健康且为即将发布的版本做好准备，我们还花了一些时间思考未来的改进。 如您所知，存储引导式设置始终会根据需要将特殊启动分区提议到每个磁盘上。 可能是 BIOS BOOT（用于 Legacy x86 系统和 GPT）、ESP（用于 UEFI 系统）、PReP（用于 PPC 系统）或 zipl（用于 S/390 系统）。 严格来说，这些分区不必与根分区位于同一磁盘上，并且在某些情况下，将其放在单独的磁盘上可能具有一些优势（例如与另一个操作系统共享 ESP 分区）。
但我们一直在重新考虑所有情况、大多数用户的期望以及其他操作系统中共享启动分区中的已知错误。 我们决定在未来对这些分区的放置位置更加严格。 从今天开始，在 openSUSE Tumbleweed 中，并在 openSUSE Leap 和 SLE 的 15.2 版本中，引导式设置将始终将这些分区提议到系统磁盘中。 也就是说，包含 /boot 和根文件系统的磁盘。
YaST 网络未来的在这里
那些关注此博客的人都知道，我们在过去几年中投入了大量时间来重写 YaST 中最容易出错且最难修改的部分——存储堆栈。 而且您可能已经注意到，自从我们这样做之后，我们正在以非常快的速度引入新功能（例如 bcache、更强大的分区程序、Raspberry Pi 支持等）并修复报告的错误，只需几天甚至几个小时。
YaST 领域中下一个要改造的是网络支持。 我们很高兴地宣布，我们开始看到一些可见的结果。 还有很长的路要走，我们将在未来的报告中提供更多信息。 但至少我们已经预览了完全重写的网络路由管理。 它仍然不可用在 openSUSE Tumbleweed 中。 但对于那些等不及的人，您可以在这里看到第一个屏幕截图。 所有基于新的干净代码和自动化测试。
在 openSUSE Leap 15.1 中激活在线仓库
openSUSE Tumbleweed 安装程序在安装开始时会询问是否激活并使用可用的在线仓库。
原因是安装 DVD 不包含所有可用的软件包，因为介质大小有限。 另一个优点是安装程序可以直接安装较新的软件包，而不是先安装旧版本，然后再升级到最新版本。
但是，在某些情况下，您可能不想使用在线仓库，例如网络连接速度慢或需要付费。
我们收到一个错误报告，Leap 15.1 中缺少此问题。 事实证明 control.xml 文件驱动安装程序缺少此步骤。 在文件中添加几行后，您现在也可以在 Leap 15.1 中享受在线仓库了！
我们为什么会写这个？ Leap 15.1 中缺少此步骤的原因有点令人惊讶。 通常，所有 YaST 包都在 Git master 分支中为 Tumbleweed 和 Leap 开发。 但是，在这种情况下，Leap 15.1 已经分支并且是单独开发的，master 中的更改仅转到 Tumbleweed。 我们忽略了这种细微的差异，并在添加此步骤时忽略了它。
为了避免将来发生这种情况，我们添加了一个 拉取请求模板，其中包含一个提醒，该提醒在打开拉取请求时告知开发人员 Git 设置中的此差异。
如果您的项目也具有一些不寻常的设置，那么 拉取请求模板 可能会为您提供一个很好的提醒。
构建 OBS 中的 Docker 镜像
但是关于正确分支和程序的提醒并不是我们为 YaST 贡献者和主要开发人员提供的所有新闻。 如您所记得，几年前我们已经切换到 在 Travis 上使用 Docker。 这效果很好，但我们发现最初设置存在一些缺点。
- 您需要在 Docker Hub 上拥有额外的帐户才能管理镜像。
- OBS 和 Docker Hub 之间没有链接，我们无法轻松地在 OBS 中更新包时触发镜像重建。
- 我们只是盲目地每 2 小时触发一次重建（在某些情况下重建是不必要的，在某些情况下需要太长时间）。
- Docker Hub 只能在 OBS 发布包后使用新的 OBS 包。
- Docker Hub 上的构建速度很慢（在我们的例子中约为 20 分钟），如果当前正在构建镜像，则构建将添加到队列中，并在之前的构建完成后开始。
结果是，合并拉取请求后，新的包可能需要几个小时才能在 Travis 中可用。 即使手动触发构建，也可能需要一个多小时。
我们需要一个更快的周期，解决方案，像往常一样，是在 openSUSE 生态系统中。 如您所知，Open Build Service 能够做的不止是构建包。 因此，我们决定利用 OBS 构建 Docker 镜像的能力。
在 OBS 中构建我们的包和 Docker 镜像具有许多优势
- 镜像构建在构建新包时立即开始，它不会等待发布包，也不会等待完全重建（仅针对必要的包）。
- 无需额外的帐户/权限（只需使用您的 OBS 帐户）。
- OBS 中的构建速度更快（6-7 分钟）。
- 无需定期触发镜像重建的额外 Jenkins 作业。
这意味着合并拉取请求后，新的包应该在大约 10-15 分钟内可用在 Docker 镜像中（对于叶包，更改核心包并触发 YaST 完全重建当然需要更多时间）。
如果您想了解更多关于此主题的信息，请查看以下链接
- OBS 镜像模板 – Docker 镜像示例
- OBS Docker 注册表 – 构建的 Docker 镜像发布在这里
- YaST Ruby 的源代码 及其各自的 OBS ci-ruby-container 包
- YaST C++ 的源代码 及其各自的 OBS ci-cpp-container 包
这还不是全部！
与往常一样，本报告的内容只是 YaST 团队在两周内完成的工作的一小部分。 在此冲刺中，大部分工作都用于修复各种错误，为即将发布的版本做准备。 大错误、小错误、隐藏错误和令人尴尬的明显错误。 希望您修复了您报告的错误。 如果没有，您可以随时关注更多新闻，了解下一次冲刺后的更多信息。 别忘了玩得开心！