2 个给使用 Fedora 工作站的音乐爱好者的新应用
Linux 操作系统非常适合进行独特的自定义和调整，以使你的计算机更好地为你工作。例如，i3 窗口管理器 就让用户认识到了构成现代 Linux 桌面的各种组件和部分。Fedora 上有两个音乐爱好者会感兴趣的新软件包：mpris-scrobbler 和 playerctl。mpris-scrobbler 可以在 Last.fm 和/或 ListenBrainz 等音乐跟踪服务上跟踪你的音乐收听历史。 playerctl 是一个命令行的音乐播放器的控制器。mpris-scrobbler：记录你的音乐收听趋势mpris-scrobbler 是一个命令行应用程序，用于将音乐的播放历史记录提交给 Last.fm、Libre.fm 或 ListenBrainz 等服务。它监听 MPRIS D-Bus 接口 以检测正在播放的内容。它可以连接几个不同的音乐客户端，如 spotify 客户端、vlc、audacious、bmp、cmus 等。安装和配置 mpris-scrobblermpris-scrobbler 在 Fedora 28 或更高版本以及 EPEL 7 存储库中可用。在终端中运行以下命令进行安装：sudo dnf install mpris-scrobbler安装完成后，使用 systemctl 启动并启用该服务。以下命令启动 mpris-scrobbler 并始终在系统重启后启动它：systemctl --user enable --now mpris-scrobbler.service提交播放信息给 ListenBrainz这里将介绍如何将 mpris-scrobbler 与 ListenBrainz 帐户相关联。要使用 Last.fm 或 Libre.fm，请参阅其上游文档。要将播放信息提交到 ListenBrainz 服务器，你需要有一个 ListenBrainz API 令牌。如果你有帐户，请从个人资料设置页面中获取该令牌。如果有了令牌，请运行此命令以使用 ListenBrainz API 令牌进行身份验证：$ mpris-scrobbler-signon token listenbrainz Token for listenbrainz.org:最后，通过在 Fedora 上用你的音乐客户端播放一首歌来测试它。你播放的歌曲会出现在 ListenBrainz 个人资料页中。playerctl 可以控制音乐回放playerctl 是一个命令行工具，它可以控制任何实现了 MPRIS D-Bus 接口的音乐播放器。你可以轻松地将其绑定到键盘快捷键或媒体热键上。以下是如何在命令行中安装、使用它，以及为 i3 窗口管理器创建键绑定的方法。安装和使用 playerctlplayerctl 在 Fedora 28 或更高版本中可用。在终端运行如下命令以安装：sudo dnf install playerctl现在已安装好，你可以立即使用它。在 Fedora 上打开你的音乐播放器。接下来，尝试用以下命令来控制终端的播放。播放或暂停当前播放的曲目：playerctl play-pause如果你想跳过下一首曲目：playerctl next列出所有正在运行的播放器：playerctl -l仅使用 spotify 客户端播放或暂停当前播放的内容：playerctl -p spotify play-pause在 i3wm 中创建 playerctl 键绑定你是否使用窗口管理器，比如 i3 窗口管理器？尝试使用 playerctl 进行键绑定。你可以将不同的命令绑定到不同的快捷键，例如键盘上的播放/暂停按钮。参照下面的 i3wm 配置摘录 看看如何做：# Media player controls bindsym XF86AudioPlay exec "playerctl play-pause" bindsym XF86AudioNext exec "playerctl next" bindsym XF86AudioPrev exec "playerctl previous"体验一下音乐播放器想了解关于在 Fedora 上定制音乐聆听体验的更多信息吗？Fedora Magazine 为你提供服务。看看 Fedora 上这五个很酷的音乐播放器。也可以通过使用 MusicBrainz Picard 对音乐库进行排序和组织，为你的混乱的音乐库带来秩序。via: https://fedoramagazine.org/2-new-apps-for-music-tweakers-on-fedora-workstation/作者：Justin W. Flory 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Facebook 开发人员 Christine Abernathy 讨论了开源如何帮助公司分享见解并推动创新。开源逐年变得无处不在，从政府直辖市到大学都有。各种规模的公司也越来越多地转向开源软件。事实上，一些公司正在通过财务支持项目或与开发人员合作进一步推进开源。例如，Facebook 的开源计划鼓励其他人开源发布他们的代码，同时与社区合作支持开源项目。 Christine Abernathy，是一名 Facebook 开发者、开源支持者，也是该公司开源团队成员，去年 11 月访问了罗切斯特理工学院，在 11 月 的 FOSS 系列演讲中发表了演讲。在她的演讲中，Abernathy 解释了 Facebook 如何开源以及为什么它是公司所做工作的重要组成部分。Facebook 和开源Abernathy 说，开源在 Facebook 创建社区并使世界更加紧密的使命中扮演着重要的角色。这种意识形态的匹配是 Facebook 参与开源的一个激励因素。此外，Facebook 面临着独特的基础设施和开发挑战，而开源则为公司提供了一个平台，以共享可帮助他人的解决方案。开源还提供了一种加速创新和创建更好软件的方法，帮助工程团队生产更好的软件并更透明地工作。今天，Facebook 在 GitHub 的 443 个项目有 122,000 个分支、292,000 个提交和 732,000 个关注。一些以开源方式发布的 Facebook 项目包括 React、GraphQL、Caffe2 等等。（图片提供：Christine Abernathy 图片，经许可使用）得到的教训Abernathy 强调说 Facebook 已经从开源社区吸取了很多教训，并期待学到更多。她明确了三个最重要的：分享有用的东西突出你的英雄修复常见的痛点Christine Abernathy 作为 FOSS 演讲系列的嘉宾一员参观了 RIT。每个月，来自开源世界的演讲嘉宾都会与对自由和开源软件感兴趣的学生分享关于开源世界智慧、见解、建议。 FOSS @MAGIC社区感谢 Abernathy 作为演讲嘉宾出席。关于作者Justin 是罗切斯特理工学院主修网络与系统管理的学生。他目前是 Fedora Project 的贡献者。在 Fedora 中，Justin 是 Fedora Magazine 的主编，社区的领导...via: https://opensource.com/article/18/1/inside-facebooks-open-source-program作者：Justin W. Flory 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
过了这个夏天，我把我的桌面环境迁移到了 i3，这是一个瓦片式窗口管理器。当初，切换到 i3 是一个挑战，因为我必须去处理许多以前 GNOME 帮我处理的事情。其中一件事情就是改变屏幕亮度。 xbacklight 这个在笔记本电脑上改变背光亮度的标准方法，它在我的硬件上不工作了。最近，我发现一个改变背光亮度的工具 brightlight。我决定去试一下它，它工作在 root 权限下。但是，我发现 brightligh 在 Fedora 下没有 RPM 包。我决定，是在 Fedora 下尝试创建一个包的时候了，并且可以学习怎么去创建一个 RPM 包。在这篇文章中，我将分享以下的内容：创建 RPM SPEC 文件在 Koji 和 Copr 中构建包使用调试包处理一个问题提交这个包到 Fedora 包集合中前提条件在 Fedora 上，我安装了包构建过程中所有步骤涉及到的包。sudo dnf install fedora-packager fedpkg fedrepo_req copr-cli 创建 RPM SPEC 文件创建 RPM 包的第一步是去创建 SPEC 文件。这些规范，或者是指令，它告诉 RPM 怎么去构建包。这是告诉 RPM 从包的源代码中创建一个二进制文件。创建 SPEC 文件看上去是整个包处理过程中最难的一部分，并且它的难度取决于项目。对我而言，幸运的是，brightlight 是一个用 C 写的简单应用程序。维护人员用一个 Makefile 使创建二进制应用程序变得很容易。构建它只是在仓库中简单运行 make 的问题。因此，我现在可以用一个简单的项目去学习 RPM 打包。查找文档谷歌搜索 “how to create an RPM package” 有很多结果。我开始使用的是 IBM 的文档。然而，我发现它理解起来非常困难，不知所云（虽然十分详细，它可能适用于复杂的 app）。我也在 Fedora 维基上找到了 创建包 的介绍。这个文档在构建和处理上解释的非常好，但是，我一直困惑于 “怎么去开始呢？”最终，我找到了 RPM 打包指南，它是大神 Adam Miller 写的。这些介绍非常有帮助，并且包含了三个优秀的示例，它们分别是用 Bash、C 和 Python 编写的程序。这个指南帮我很容易地理解了怎么去构建一个 RPM SPEC，并且，更重要的是，解释了怎么把这些片断拼到一起。有了这些之后，我可以去写 brightlight 程序的我的 第一个 SPEC 文件 了。因为它是很简单的，SPEC 很短也很容易理解。我有了 SPEC 文件之后，我发现其中有一些错误。处理掉一些错误之后，我创建了源 RPM (SRPM) 和二进制 RPM，然后，我解决了出现的每个问题。rpmlint SPECS/brightlight.spec rpmbuild -bs SPECS/brightlight.spec rpmlint SRPMS/brightlight-5-1.fc26.src.rpm rpmbuild -bb SPECS/brightlight-5-1.fc26.x86_64.rpm rpmlint RPMS/x86_64/brightlight-5-1.fc26.x86_64.rpm 现在，我有了一个可用的 RPM，可以发送到 Fedora 仓库了。在 Copr 和 Koji 中构建接下来，我读了该 指南 中关于怎么成为一个 Fedora 打包者。在提交之前，他们鼓励打包者通过在在 Koji 中托管、并在 Copr 中构建项目来测试要提交的包。使用 Copr首先，我为 brightlight 创建了一个 Copr 仓库，Copr 是在 Fedora 的基础设施中的一个服务，它构建你的包，并且为你任意选择的 Fedora 或 EPEL 版本创建一个定制仓库。它对于快速托管你的 RPM 包，并与其它人去分享是非常方便的。你不需要特别操心如何去托管一个 Copr 仓库。我从 Web 界面创建了我的 Copr 项目，但是，你也可以使用 copr-cli 工具。在 Fedora 开发者网站上有一个 非常优秀的指南。在该网站上创建了我的仓库之后，我使用这个命令构建了我的包。copr-cli build brightlight SRPMS/brightlight.5-1.fc26.src.rpm 我的包在 Corp 上成功构建，并且，我可以很容易地在我的 Fedora 系统上成功安装它。使用 Koji任何人都可以使用 Koji 在多种架构和 Fedora 或 CentOS/RHEL 版本上测试他们的包。在 Koji 中测试，你必须有一个源 RPM。我希望 brightlight 包在 Fedora 所有的版本中都支持，因此，我运行如下的命令：koji build --scratch f25 SRPMS/brightlight-5-1.fc26.src.rpm koji build --scratch f26 SRPMS/brightlight-5-1.fc26.src.rpm koji build --scratch f27 SRPMS/brightlight-5-1.fc26.src.rpm 它花费了一些时间，但是，Koji 构建了所有的包。我的包可以很完美地运行在 Fedora 25 和 26 中，但是 Fedora 27 失败了。 Koji 模拟构建可以使我走在正确的路线上，并且确保我的包构建成功。问题：Fedora 27 构建失败！现在，我已经知道我的 Fedora 27 上的包在 Koji 上构建失败了。但是，为什么呢？我发现在 Fedora 27 上有两个相关的变化。Subpackage and Source DebuginfoRPM 4.14 (特别是，debuginfo 包重写了)这些变化意味着 RPM 包必须使用一个 debuginfo 包去构建。这有助于排错或调试一个应用程序。在我的案例中，这并不是关键的或者很必要的，但是，我需要去构建一个。感谢 Igor Gnatenko，他帮我理解了为什么我在 Fedora 27 上构建包时需要去将这些增加到我的包的 SPEC 中。在 %make_build 宏指令之前，我增加了这些行。export CFLAGS="%{optflags}" export LDFLAGS="%{__global_ldflags}" 我构建了一个新的 SRPM 并且提交它到 Koji 去在 Fedora 27 上构建。成功了，它构建成功了！提交这个包现在，我在 Fedora 25 到 27 上成功校验了我的包，是时候为 Fedora 打包了。第一步是提交这个包，为了请求一个包评估，要在 Red Hat Bugzilla 创建一个新 bug。我为 brightlight 创建了一个工单。因为这是我的第一个包，我明确标注它 “这是我的第一个包”，并且我寻找一个发起人。在工单中，我链接 SPEC 和 SRPM 文件到我的 Git 仓库中。进入 dist-gitIgor Gnatenko 发起我进入 Fedora 打包者群组，并且在我的包上留下反馈。我学习了一些其它的关于 C 应用程序打包的特定的知识。在他响应我之后，我可以在 dist-git 上申请一个仓库，Fedora 的 RPM 包集合仓库为所有的 Fedora 版本保存了 SPEC 文件。一个很方便的 Python 工具使得这一部分很容易。fedrepo-req 是一个用于创建一个新的 dist-git 仓库的请求的工具。我用这个命令提交我的请求。fedrepo-req brightlight \ --ticket 1505026 \ --description "CLI tool to change screen back light brightness" \ --upstreamurl https://github.com/multiplexd/brightlight 它为我在 fedora-scm-requests 仓库创建了一个新的工单。这是一个我是管理员的 创建的仓库。现在，我可以开始干了！My first RPM in Fedora dist-git – woohoo!与 dist-git 一起工作接下来，fedpkg 是用于和 dist-git 仓库进行交互的工具。我改变当前目录到我的 git 工作目录，然后运行这个命令。fedpkg clone brightlight fedpkg 从 dist-git 克隆了我的包的仓库。对于这个仅有的第一个分支，你需要去导入 SRPM。fedpkg import SRPMS/brightlight-5-1.fc26.src.rpm fedpkg 导入你的包的 SRPM 到这个仓库中，然后设置源为你的 Git 仓库。这一步对于使用 fedpkg 是很重要的，因为它用一个 Fedora 友好的方去帮助规范这个仓库（与手动添加文件相比）。一旦你导入了 SRPM，推送这个改变到 dist-git 仓库。git commit -m "Initial import (#1505026)." git push 构建包自从你推送第一个包导入到你的 dist-git 仓库中，你已经准备好了为你的项目做一次真实的 Koji 构建。要构建你的项目，运行这个命令。fedpkg build 它会在 Koji 中为 Rawhide 构建你的包，这是 Fedora 中的非版本控制的分支。在你为其它分支构建之前，你必须在 Rawhide 分支上构建成功。如果一切构建成功，你现在可以为你的项目的其它分支发送请求了。fedrepo-req brightlight f27 -t 1505026 fedrepo-req brightlight f26 -t 1505026 fedrepo-req brightlight f25 -t 1505026 关于构建其它分支的注意事项一旦你最初导入了 SRPM，如果你选择去创建其它分支，记得合并你的主分支到它们。例如，如果你后面为 Fedora 27 请求一个分支，你将需要去使用这些命令。fedpkg switch-branch f27 git merge master git push fedpkg build 提交更新到 Bodhi这个过程的最后一步是，把你的新包作为一个更新包提交到 Bodhi 中。当你初次提交你的更新包时，它将去测试这个仓库。任何人都可以测试你的包并且增加 karma 到该更新中。如果你的更新接收了 3 个以上的投票（或者像 Bodhi 称它为 karma），你的包将自动被推送到稳定仓库。否则，一周之后，推送到测试仓库中。要提交你的更新到 Bodhi，你仅需要一个命令。fedpkg update 它为你的包用一个不同的配置选项打开一个 Vim 窗口。一般情况下，你仅需要去指定一个 类型（比如，newpackage）和一个你的包评估的票据 ID。对于更深入的讲解，在 Fedora 维基上有一篇更新的指南。在保存和退出这个文件后，fedpkg 会把你的包以一个更新包提交到 Bodhi，最后，同步到 Fedora 测试仓库。我也可以用这个命令去安装我的包。sudo dnf install brightlight -y --enablerepo=updates-testing --refresh 稳定仓库最近提交了我的包到 Fedora 26 稳定仓库，并且不久将进入 Fedora 25 和 Fedora 27 稳定仓库。感谢帮助我完成我的第一个包的每个人。我期待有更多的机会为发行版添加包。via: https://blog.justinwflory.com/2017/11/first-rpm-package-fedora/作者：JUSTIN W. FLORY 译者：qhwdw 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出