• 首页
  • 加入
  • RSS
  • Monday, April 10, 2023

    目前 dde-nixos 已经分叉,mian 分支进行 v23 的维护,目前主要更新了 dtk 和部分 deepin 开头的应用, dde 开头的核心应用移植暂未实现,dbus 接口不兼容,因此目前不可日常使用。

    gomod 分支用于测试使用 buildGoModule 完成构建,仅验证可行性,实际使用还需要调整硬编码相关的 patch。

    日常使用 DDE 需要切换 v20 分支,会优先使用已经提交到上游的应用:

       dde-nixos = {
          url = "github:linuxdeepin/dde-nixos/v20";
          inputs.nixpkgs.follows = "nixpkgs";
        };
    

    在 v20 分支,dtk 使用 5.6.3 不再升级,deepin 应用会保持最新的 v20 版的最新版本(不会上 6.0.0),dde 应用冻结为 1 月份打包时测试可用的版本,一般不再升级:

    既除了 deepin 应用,其他应用只有在 v23 移植完成后再更新。

    目前 NixOS 23.05 — Feature Freeze & Release Blockers 已经开始,进度请关注: https://github.com/NixOS/nixpkgs/issues/224457#issuecomment-1501383113

    向上游贡献的主要调整:

    1. 调整 patch

    在 dde-nixos 中,编写了 getPatchFrom, replaceAll 等函数帮助 patch 硬编码路径,但打包时为上游添加函数是难以接受的,因此所有的 patch 都需要使用 substituteInPlace 重写:

    一个典型的例子是:https://github.com/NixOS/nixpkgs/pull/217806

    1. 改善对交叉编译

    所有 deepin 启用 strictDeps,调整了 nativeBuildInputs 和 buildInputs 不规范的地方,(使用 qmake 的除外,会造成 qtwebengine 找不到,且上游已经不太关心 qmake)

    strictDeps 下无法传播 qtimageformats 问题 ,由 NickCao 解决

    ps:可以使用 nix-build -A pkgsCross.riscv64.deepin.dtkcore 尝试交叉编译。目前 x86_64 和 aarch64 可正常编译。

    Friday, April 7, 2023

    obs 全称 Open Build Service,是一个开放的构建平台。相较于其他构建工具有以下优点:

    • 支持跨平台构建(x86、arm64 等)
    • 支持多种虚拟环境(kvm、lxc、chroot 等)
    • 支持软件包构建(deb、rpm、pkg 等)
    • 支持容器构建(flatpak、appimage、docker 等)
    • 支持发型版镜像构建(debian、windows 等)

    玲珑 是一种新型的独立包管理工具集,致力于治理 Linux 系统下传统软件包格式复杂、交叉的依赖关系导致的各种兼容性问题,以及过于松散的权限管控导致的安全风险。

    本文介绍怎么给 obs 添加玲珑构建支持,供以参考实现你自己的 obs 构建服务。

    Thursday, March 9, 2023

    deepin v23 beta 的发布在即,为了能够使相关的 bug 能够得以更快解决,并促进研发团队的协作变得更高效,我们(开源社区中心)决定在 deepin 员工内部举办小规模的 bug hunting 性质的比赛,并命名该比赛为“小浣熊杯修 bug 大赛”。而首届“小浣熊杯”也于昨天顺利落幕,那么就让我们一起了解一下这个比赛吧!

    比赛介绍

    如上所述,“小浣熊杯“的比赛大致内容即为在比赛时间内对已有缺陷进行修复。我们将所有参赛的员工划分为多个组,每个组除研发外也配备一个测试人员。在比赛时间周期内,研发从指定的缺陷看板中挑选自己”中意“的 BUG 进行修复,并在修复后将修复公布在相关群内,由 其他组 的测试人员进行测试。当修复被测试人员验证没有问题后,即可进行计分。最终,会以本组研发人员所修复的数量与测试人员所完成的测试数量相组合,并计算小组人均得分,最后以小组人均得分的高低决定最终排名。

    小组得分的计算公示为:

    小组得分 = (本组研发修复的缺陷数量 + 本组测试所验证的缺陷数量 / 3) / 小组总人数
    

    比赛会在 https://github.com/linuxdeepin/.bug-game/ 中进行,每次比赛会创建一个看板来跟进整个比赛的实时情况,并创建一个对应的 issue 记录相关进展与结果。

    另外,考虑到比赛过程中对缺陷的修复不需要经过其他研发人员的 code review ,因而可能存在实际的代码质量问题,故相关的 PR 均不要求在比赛结束前合入,相关提交仍需按照正常流程,经过有效 review 获得 approval 后合入。

    首届状况介绍

    比赛过程看板截图

    首届比赛共划分了四个小队参赛,比赛时间从 3 月 7 日开始,为期两天。比赛过程与结果在 这个 Issue 中汇总,最终的缺陷修复情况也可以参见 这个看板。比赛过程中“修 bug”队一度领先,随后被”进击的小浣熊“队反超,最终经过了两天的”激烈比拼“后,本次比赛总计处理了 42 个 Issue,由”进击的小浣熊“队以 18.333 分的总积分获得人均积分第一夺冠。“修 bug”队紧随其后,“呆呆鹅” 与 “bug 收割小分队” 获得随后的名次。

    比赛过程中,各个小组对已有 bug 的挑选与“占坑”以及测试人员对新提交修复的“抢单”是过程中最有趣的事情之一。快速挑选便于修复的 BUG 并进行有效的修复成为了获胜的关键之一,根据表象快速分析推测问题的能力,以及在陌生项目1中快速尝试定位和修复问题的能力也变得至关重要。作为花絮,有的小组也在选择 BUG 的过程中连续发现自己所选择的缺陷实际早已在版本迭代中被修复,耗费了较多时间而造成了相对的失利,但这个过程也对现存 BUG 的有效性验证有很大的帮助2

    赛后,我们进行了比赛的颁奖,获胜队伍获得了比赛限定奖杯与荣誉证书,以及一个 deepin 主题背包。获奖队伍也进行了合影:

    荣誉证书

    颁奖截图

    无论是否获奖,我们都感谢各个参赛队伍的积极参与,也希望各位能在后续的比赛中能够获得优异的成绩。


    1. 注:缺陷的修复不限于自己所维护的项目,研发人员也可以尝试修复由其他项目组所维护的缺陷。 ↩︎

    2. 或许在后续的比赛中应当为此类也算作计分项。 ↩︎

    Tuesday, February 14, 2023

    deepin 社区博客

    deepin 社区公共博客平台。

    用法说明

    此博客平台使用了 HUGO 作为文章平台工具,进行博客文章的静态生成,并最终利用 GitHub Pages 呈现网页。故整个过程你只需按照 HUGO 的正常使用方式进行使用即可。

    若未安装 HUGO,您可以从 HUGO 官方 GitHub 仓库的 Release 页面获取适用于您设备的 HUGO 版本,并放置其于 PATH 内以便调用。

    安装就绪后,大致常用命令如下(在此源码仓库的根目录下执行):

    $ hugo server # 启动一个本地服务器,预览目前状态下的网站内容
    $ hugo new posts/my-post.md # 创建一篇新文章,以便进行编辑
    $ hugo server -D # 启用本地服务器,并且能够预览状态为草稿(`draft: true`)的文章
    $ hugo -D # 生成静态页面(如果需要),生成的文件将位于 public 目录下
    

    创建文章时,创建格式为 <分类>/<文件名>.<格式>,上面给出的例子中,分类为 posts,文件名为 my-post,格式为 md (markdown)。创建文章后,默认会使用 YAML front-matter 标记文章的一些元信息,请留意 draft 草稿状态的文章最终不会显示。

    若要获取 HUGO,请参考官方文档给出的安装方式

    文章内容指导建议

    向此博客平台投递文章需要经过相关人员的 review,合入后即投递完成。需要注意的是,向此处投递的文章必须是与 deepin 社区发展所相关的文章。对于与 deepin 开源社区贡献相关的个人感想或随笔等博客,可以考虑发布到 planet.deepin.org 聚合平台,此博客平台的文章也会出现 planet.deepin.org 之中。

    在发布您的文章时,建议使用标签来标记您文章所相关的主题,以便读者更方便的查阅您的文章。例如 tags: ["持续集成"]tags: ["指南文档", "CMake"]。另外也建议在文章的元信息中附带作者信息,例如 authors: ["张三"](可为多人)。

    改善此项目的样式风格

    此项目使用了 geekblog 主题(基于 v0.5.3,有改动)。若你有任何建议,可以进行讨论并修改或提供更适合的主题。

    Friday, February 3, 2023

    【摘要】pbuilder + qemu 以下操作基于debian11环境,其他环境下需注意qemu版本是否在5.2版本以上 sudo apt install pbuilder qemu qemu-user-static pigz 配置 /etc/pbuilderrc MIRRORSITE=https://m 阅读全文

    Thursday, February 2, 2023

    编辑的话请把自己的名字加到作者名单里

    DDE v23 beta3 即将随 deepin v23 beta 3 发布(你阅读到这个文章的时候可能已经发布了)。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版,这里提供一篇简要的移植指南,用以描述常见的移植问题和解决方案。

    下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

    概览

    DDE 此次 beta2 -> beta3 的更新中,dde-application-manager 进行了大规模重构;dde-launchpad 取代 dde-launcher 成为了新的启动器/开始菜单应用;新的技术预览项目 dde-shell 和 treeland 也随此次发布提供了初步版本,以及为了服务 dde-launcher 和 dde-shell,dtk 也开始提供 Qt 6 版本。

    由于这些项目的版本间互相影响,我们建议移植人员参照 deepin v23 beta3 所使用的包版本进行打包(随后会把完整的版本参照列表贴到这里),下面会对主要的部分进行详细说明。

    主要组件

    DTK 与 DTK6

    作为 DDE 组件与应用的基础依赖,DTK 现开始提供 Qt 6 支持。适用于 beta 3 的版本参照如下:

    packageversion
    dtkcommon5.6.21
    dtkcore5.6.22
    dtkgui5.6.22
    dtkwidget5.6.22
    dtkdeclarative5.6.24
    qt5integration5.6.20
    qt5platform-plugins5.6.22
    dtk6core6.0.4
    dtk6gui6.0.5
    dtk6widget6.0.4
    dtk6declarative6.0.7
    qt6integration6.0.4
    qt6platform-plugins6.0.4

    由于 dtkdeclarative 和 dtkgui 存在一些发布前的紧急修复,所以这两个组件存在版本号未对齐的情况。请直接参照上述表格的版本进行打包,以便确保 dtk 自身互相依赖的版本无误。

    关于 qt5platform-plugins,现有的 dwayland 插件可能对非 DDE 环境(例如 KDE)的 wayland 用户存在影响,可参照 linuxdeepin/developer-center#7217 打对应的 patch 规避影响。

    dtk6 曾对 Qt 6.2, Qt 6.4 和 Qt 6.6 均进行过适配,但我们目前的研发与测试主要使用 Qt 6.6 版本,故我们建议使用尽可能新的 Qt 6 版本。

    目前,使用 dtk6 的正式组件有 dde-application-manager 以及 dde-launchpad,技术预览组件有 dde-shell, treeland。

    dde-application-manager

    dde-application-manager 自 1.1.0 版本起进行了完整重构(此次随 beta 3 发布的版本是 1.1.8),接口存在完全不兼容的变动。故原本依赖重构前 dde-application-manager 的应用程序和组件均需要进行更新。比较典型的组件为 dde-dock 与 dde-file-manager。

    dde-launchpad

    dde-launchpad 取代了 dde-launcher,原 dde-launcher 由于大量缺陷以及对旧 dde-application-manager 的强依赖,已不再可用。如果您的发行版在使用 dde-launcher,现在可以废弃 dde-launcher 并使用 dde-launchpad 替代了。

    尽管在 deepin 中,dde-launchpad 使用的是 Qt 6 构建的版本,dde-launchpad 本身仍然提供了选项来控制使用 Qt 5 或是 Qt 6。我们建议在允许的情况下尽可能使用 Qt 6 而不是 Qt 5,以及无论 Qt 5 或是 Qt 6 支持,请都不要忘记安装 qt5/6integration 插件以及 qt5/6platform-plugins,否则 dde-launchpad 可能会缺失圆角与模糊效果。同样,强烈建议配合最新 DTK 版本构建来获得最佳显示效果。

    另外,随 dde-launchpad 一并发布了 dde-application-wizard 项目。此项目是一个守护进程,提供对旧的 dde-application-manager 所提供的卸载服务接口的兼容支持,但可被移植到支持 packagekit 的发行版,故您可以考虑打包移植此组件。如果您的发行版不支持 packagekit,则可考虑暂时 patch dde-launchpad 来隐藏菜单中的卸载按钮,后续 dde-launchpad 会提供 DConfig 来便于发行版定制这些菜单项。

    技术预览组件

    技术预览阶段的组件均可酌情决定是否打包。

    dde-shell

    dde-shell 目前是技术预览阶段的项目。dde-shell 旨在将 DDE 桌面环境插件化与模块化,降低开发难度,使各个组件的替换变得更加容易,并且提供更好的桌面环境集成支持。

    dde-shell 目前包含 shell 本体,以及预制的新 dock 插件和通知中心插件。

    treeland / ddm

    treeland 目前是技术预览阶段的项目,兼顾 Wayland 窗口合成器和显示管理功能。treeland 除需要 dtk6declarative 外,还依赖新项目包括 waylibqwlroots。需要使用 Qt 版本 >= 6.6.0, wlroots 版本 >= 0.17.0 编译 qwlroots/waylib。

    同时我们放弃了对 deepin-kwin wayland 的支持(更新 dde-session 后会屏蔽入口),DDE 所有 wayland 相关的支持均由 Treeland 提供。

    deepin-im

    treeland 目前是技术预览阶段的项目,提供了输入法的抽象层。目前,deepin-im 仅期望在 treeland 环境下使用。它会设置 QT_IM_MODULE 等环境变量的值来影响实际使用的输入法模块。

    获取移植帮助

    如果您希望得到移植相关的帮助,请考虑加入我们 DDE 移植小组的在线交流群(下列房间有桥接,任选其一即可),一起展开相关的交流:

    Monday, January 30, 2023

    本月对 NixOS DDE 做了进一步完善,已经比较适合在实体机上使用了。

    现在 deepin v23 的版本即将发布,github 大部分 DDE 软件已经升级到了 23 版本,由于 20 和 23 版本不完全兼容,dde-nixos 将使用 v20 分支继续维护/测试 v20 版本的 DDE, main 分支尝试 v23 版本。

    目前的主要工作是将 v20 版本的移植工作转移到上游,方便更多用户使用。同时 review 机制也可以找到并处理现有写法的不规范之处。Nixpkgs 合并进程请关注:https://github.com/linuxdeepin/dde-nixos/issues/9

    目前已经有一部分应用可在官方仓库下载

    此外 @SamLukeYes 构建了 NixOS DDE 的 iso,可以直接使用: https://github.com/SamLukeYes/nixos-dde-iso/releases/tag/22.11.20230113

    • dtk

      • 统一升级到 5.6.3
      • qt5integration 使用 5.6.4 :修复通知中心图标缺失问题/修复 log 中大量 create icon [] engine failed.[theme:] 问题
    • dde-control-center:

      • 禁用系统版权协议模块(仅适配deepin/uos)
      • (dde-api) 修复无法识别本机语言的问题
      • 修改语言(locale)功能在 NixOS 中无法实现,属于正常现象
      • 适配系统版权信息(通过 /etc/deepin-installer.conf 配置实现)
      • 修复明暗主题,图标光标主题缺失(go-lib isDir 判断错误)
    • dde-daemon

      • 修复 nix 的 wrapped 应用后无法通过 verifyExe 校验问题
      • 清理无用的硬编码 patch
    • deepin-kwin 相关软件:

      • 已经切换至 linuxdeepin 仓库的 tag 版本
    • dde-account-faces

      • /var 路径文件改用 systemd.tmpfiles 模块管理
    • deepin-system-monitor

      • 修复 dock 插件显示问题
    • 配置 Garnix CI

      • 通过 Garnix 自动构建 dde-nixos 的软件,支持 x86 和 arm
      • 使用 Garnix 提供的 binary caches,可以无需编译即可使用 DDE, 用法见项目 readme
    • gio-qt

      • 修复文档编译失败
    • deepin-boot-maker

      • 修复多处硬编码路径,修复无法识别 u 盘的问题
    • dpa-ext-gnomekeyring

      • 修复硬编码
    • deepin-font-manager

      • 修复系统字体识别错误
    • dde-file-manager

      • 修复新版空格预览崩溃
      • 处理插件硬编码路径
    • dde-app-services

      • 修复 GUI 编辑器无法读取其他应用配置问题
    • dde-network-core

      • 修复控制中心插件翻译

    其他:

    • 新增 security.pam.services.dde-lock, 代替 dde-lock 所使用的 common-auth
    • 新增 deepin-orc 支持
    • 修复对 deepin-anything 的支持
    • 默认安装 onboard, dock 插件使用
    • 处理 updateDbusEnvironment 未生效的问题:https://github.com/NixOS/nixpkgs/issues/209847
    • 清理 dde 模块中非必要启用的 services
    • 优化 nix 函数结构,dtk 不再使用列表,改用 propagatedBuildInputs

    目前已知的问题:

    qt 应用启动器启动不是deepin主题,但通过 deepin-terminal 启动是:

    qt5integration 未全局安装,安装后虽然 qt 主题无问题,但是会导致启动器缺失图标等问题。建议 qt 继续使用 breeze 主题

    lightdm 不是 deepin 主题

    目前 deepin-greeter 无法正常使用,不过使用其他主题或者用 sddm 也是可以启动 DDE 的。

    窗口模糊特效缺失

    deepin-kwin 的问题,等待修复。通过控制中心关闭再打开特效,可以临时解决。

    Tuesday, December 27, 2022

    vscode snipets 用户代码片段使用指南

    snipets简介

    snipets 我愿意称为程序员的ctrl+c ctrl+v最大的竞争对手,sniptes适用于遇到很多重复代码却又没法去提取代码特点抽象成类的情况。比如写注释的时候。

    这是一个极好的工具用于高效率办公(摸鱼)

    vscode 打开snipets

    然后你就需要选择对应的语言,这里我以doxygen注释文件为例子: 打开之后会得到这样一个文件:

    {
     // Place your snippets for doxygen here. Each snippet is defined under a snippet name and has a prefix, body and
     // description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
     // $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the
     // same ids are connected.
     // Example:
     // "Print to console": {
     //  "prefix": "log",
     //  "body": [
     //   "console.log('$1');",
     //   "$2"
     //  ],
     //  "description": "Log output to console"
     // }
    }
    

    这个文件都是注释组成,自然也没有任何功能,我们要做的是对其进行修改,以支持我们自己的代码片段

    代码片段的解读

    先以一个比较简单的例子作为内容:

    {
     // Place your snippets for doxygen here. Each snippet is defined under a snippet name and has a prefix, body and
     // description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
     // $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the
     // same ids are connected.
     // Example:
     // "Print to console": {
     //  "prefix": "log",
     //  "body": [
     //   "console.log('$1');",
     //   "$2"
     //  ],
     //  "description": "Log output to console"
     // }
     "dox dtkwidget": {
      "prefix": "da",
      "body": [
       "@fn void Dtk::Widget::DAlertControl::${2:function}",
       "@brief ${3:info}"
      ]
     }
    }
    

    我们来逐行解释:dox dtkwidget指的是这个代码片段的命名,你可以使用任何你喜欢的命名来代替它

    然后就是一个键值对 “prefix” 的值一般是一个字符串,这个字符串也是可以自定义的,含义就是你在代码文件里面输入这个字符串(在某一行的开头)后会弹出选项询问你是否使用代码片段:比如这个就是da,你在某一行的开头打出da这俩字符,就会弹窗询问你是否替换

    同时会显示对于代码片段的命名

    body键值对就是最重要的一部分,这个里面就保存的你需要的代码片段,

    请注意,其中每一行都代表的是你之后生成的代码的一行,如上代码片段生成的代码就是

    @fn void Dtk::Widget::DAlertControl::function
    @brief info
    

    如果你现在已经复制了我的代码片段,不妨新建一个dox文件试试。打出da之后会弹出选项,按tab键确认之后就会出现这个代码,不过会让你填写function的值,填写完毕之后就按tab键切换到info需要你填写info的值

    不过这样还不是代码片段的全部实力,它还能更强大点:

     "dox about dtkwidget": {
      "prefix": "dd",
      "body": [
       "@property ${1|QColor,void,bool|} Dtk::Widget::DAlertControl::${2:function}",
       "@brief 返回${3:info}",
       "",
       "@fn void Dtk::Widget::DAlertControl::set${2/(.*)/${1:/capitalize}/i}",
       "@brief 设置${3:info}",
       "@sa DAboutDialog::${2:function}"
      ]
     }
    

    比如这样

    你可以自己试试这个会发生什么

    对的 它还支持正则表达式的替换

    现在看看我正在用的doxygen的代码片段

    {
    
     "dox about DtkGui": {
      "prefix": "dd",
      "body": [
       "@property Dtk::Gui::DDciIconPalette::${2:function}",
       "@brief ${2}属性",
       "@sa READ方法: void Dtk::Widget::DDciIconPalette::${2:function}",
       "@sa WRITE方法: void Dtk::Widget::DDciIconPalette::set${2/(.*)/${1:/capitalize}/i}",
       "",
       "@fn ${1|QColor,void,bool|} Dtk::Widget::DDciIconPalette::${2:function}",
       "@brief 返回${3:info}",
       "@sa DDciIconPalette::${2:function}",
       "",
       "@fn void Dtk::Widget::DDciIconPalette::set${2/(.*)/${1:/capitalize}/i}",
       "@brief 设置${3:info}",
       "@sa DDciIconPalette::${2:function}"
      ]
     },
     "dox dtkwidget": {
      "prefix": "da",
      "body": [
       "@fn void Dtk::Widget::DDciIconPalette::${2:function}",
       "@brief ${3:info}"
      ]
     }
    }
    

    我可以通过这个代码片段一键生成属性的get和set方法的doxygen注释

    Monday, December 12, 2022

    自小组成立以来,已经为 DDE 的移植做出了很多贡献,本文做出了一些总结。如有补充或批改,可向 sig-dde-porting 提出 pr。

    NixOS 的移植从今年 3 月开始,到现在已经有了实用的可能,今后会用一篇文章单独介绍。未来会每月更新进展,关注的同学可以订阅本站 rss。

    今年改善可移植性的一些努力

    • 修复依赖特定 kwayland 无法在其他发行版编译的问题(为项目增加禁用wayland的option):

    deepin-system-monitor,dde-clipboard,dde-session-shell…

    • 修复安装路径硬编码问题

    29 个相关 pr https://github.com/linuxdeepin/developer-center/issues/3167

    • 减少代码中的硬编码问题

    16 个相关 pr https://github.com/linuxdeepin/developer-center/issues/3374

    • 编译 flag 直接覆盖的问题

    大约 8 处

    • 修复 as-need 参数 break 了部分连接器:

    10 个相关 pr https://github.com/linuxdeepin/developer-center/issues/3345

    • 完善项目关于 pkg-config/Config.cmake 的问题(如写死路径,版本号错误,引入依赖检查不完善等等)

    至少 17 个相关 pr,事实上应该远多于 17,存在多个修改顺便提在一个 pr 的情况。

    • 使用 dpkg-architecture 判断架构其他发行版无法使用问题

    4 处以上

    • 避免绝对路径头文件:

    解决 2 处,但仍有 1 处难以处理(https://github.com/linuxdeepin/dde-session-shell/pull/120)

    • dde-kwin 问题

    justforlxz 已经多次修复 dde-kwin 对 kwin 的适配问题,但每次 kwin 每次更新都会重新带来很多问题。正在移植中的 deepin-kwin 将会解决这个麻烦,目前可以使用 Arch(aur)或者 dde-nixos 先行体验。

    • 处理 deepin-wallpapers 非自由协议问题(拆包)

    dde-nixos 近期进展

    • dtkcore:

      • 其他发行版调用 uosType 直接返回 UosTypeUnknown,避免无意义的报错刷屏
      • 完善 isDDE 函数判断
      • deepin-os-release 判断是其他发行版后不会输出 deepin/uos 特有参数
    • dde-control-center:

      • 提供禁用生物认证模块的 option
      • 修复无法设置头像问题
      • 修复密码校验无法通过的问题
      • 修复系统信息/关于本机的显示问题:
        • 启用不应隐藏的“计算机名”,“产品名称”
        • 隐藏“版本”(社区版/专业版)
        • 替换为 NixOS 的 logo
        • 隐藏修改 “计算机名” 的功能
      • 隐藏用户体验模块,禁用对应 dbus 调用,修复通用模块卡钝问题
      • 修复显示内存为 0 的问题
    • deepin-movie:

      • 修复格式支持不完整的问题(修复 libPath 硬编码)
      • 修复一个崩溃问题
    • dde-grand-search:

      • 修复调用 dde-grand-search-daemon 的权限验证
    • deepin-screen-recorder:

      • 修复2个导致崩溃的问题
      • 修复命令行启动无法录屏的问题(dock插件仍然有此问题)
    • 修复 GStreamer 音频播放:

      • 需要设置依赖以及 GST_PLUGIN_SYSTEM_PATH_1_0
      • 涉及 deepin-music deepin-voice-note deepin-movie 和 dde-introduction
    • deepin-editor:

      • 修复主题路径硬编码造成的界面异常
    • deepin-compressor:

      • 修复无法加载自身插件的问题
    • 修复个别图标丢失的问题(部分 dci 图标需要 qtimageformats 支持)

    Thursday, September 22, 2022

    这是第一篇 deepin-m1 sig 的博客,我非常的激动,因为 deepin 现在已经可以在 m1 设备上启动了。

    目前在 m1 上启动 Linux 的项目进展最快的是 Asahi Linux,他们是 Linux m1 的项目发起者,同时也是 Asahi Linux 的维护者,目前 Asahi Lina 正在努力开发 m1 GPU 驱动,已经实现了绝大部分底层的功能,正在做渲染队列的工作,相信很快就可以为 Linux 带来开源的 m1 GPU 驱动。

    debian 和 fedora 也基于 Asahi installer 制作了发行版本,我们的工作也是从这里开始的。

    经过分析,发现 Asahi installer 已经预留了更换 rootfs 的接口,这使得我们的工作异常顺利,很快便完成了第一版的安装文件。

    bootloader

    start

    目前 m1 启动 Linux 的流程是先启动 Asahi m1n1,由 m1n1 启动 u-boot,再由 u-boot 启动 grub。

    m1n1 是一个非常不错的项目,可以通过 usb 进行串口调试,方便进行驱动逆向和调试,也可以测试启动 elf。

    在 m1 上安装 Linux,需要先进入一次 macOS 的恢复模式,利用恢复模式将文件内容写入,目前这已经是最好的解决方案了,目前小组正在整理相关文档和脚本,预计下个月可以对外提供正式的安装脚本和视频教程。还有很多功能没有准备好,例如一些 x86 软件无法运行,m1 只支持 16k 页内存等,可能会带来很多软件的兼容性问题,我们也欢迎更多的人加入 deepin-m1 sig 组中,提供更多的帮助。

    enjoy live!