diff --git a/01_安装升级指南/安装指南( For MacOS ).md b/01_安装升级指南/安装指南(MacOS).md
similarity index 94%
rename from 01_安装升级指南/安装指南( For MacOS ).md
rename to 01_安装升级指南/安装指南(MacOS).md
index 3908e33c..80be4ef5 100644
--- a/01_安装升级指南/安装指南( For MacOS ).md
+++ b/01_安装升级指南/安装指南(MacOS).md
@@ -1,11 +1,11 @@
---
-title: 安装指南
+title: 安装指南(MacOS)
description:
published: true
-date: 2022-07-18T09:21:33.933Z
+date: 2024-05-08T07:38:12.847Z
tags:
editor: markdown
-dateCreated: 2022-03-11T03:16:53.878Z
+dateCreated: 2024-05-08T07:24:21.392Z
---
# 安装指南(For MacOS)
diff --git a/02_基础操作/通过New Bing(chatGPT)调教openkylin.md b/02_基础操作/通过(New_Bing)chatGPT调教openkylin.md
similarity index 95%
rename from 02_基础操作/通过New Bing(chatGPT)调教openkylin.md
rename to 02_基础操作/通过(New_Bing)chatGPT调教openkylin.md
index ed5624b6..da208e5a 100644
--- a/02_基础操作/通过New Bing(chatGPT)调教openkylin.md
+++ b/02_基础操作/通过(New_Bing)chatGPT调教openkylin.md
@@ -1,30 +1,30 @@
-#
通过New Bing/chatGPT调教openKylin OS
-#### 作者:Gary
-#### 2023-03-10 13:36:00
-
-
-
-### What is openKylin OS?
-
-
-
-### Install openKylin OS
-
-
-### Creat USB drive for openKylin OS
-
-
-
-### Features of openKylin OS
-
-
-
-
-
-### Coding with openKylin OS
-
-
-
-### Install pip on openKylin OS
-
-
+# 通过New Bing/chatGPT调教openKylin OS
+#### 作者:Gary
+#### 2023-03-10 13:36:00
+
+
+
+### What is openKylin OS?
+
+
+
+### Install openKylin OS
+
+
+### Creat USB drive for openKylin OS
+
+
+
+### Features of openKylin OS
+
+
+
+
+
+### Coding with openKylin OS
+
+
+
+### Install pip on openKylin OS
+
+
diff --git a/03_常见问题/QA.md b/03_常见问题/QA.md
index e69de29b..a8f32596 100644
--- a/03_常见问题/QA.md
+++ b/03_常见问题/QA.md
@@ -0,0 +1,3 @@
+# FAQ
+- Q:可以安装自己下载的apk包么?
+- A:可以,将apk下载到本地后,右键点击,打开方式选择安装器。
\ No newline at end of file
diff --git a/05_社区贡献/PR任务合集.md b/04_社区贡献/PR任务合集.md
similarity index 100%
rename from 05_社区贡献/PR任务合集.md
rename to 04_社区贡献/PR任务合集.md
diff --git a/05_社区贡献/assets/个人开发者贡献指南/PR流程.png b/04_社区贡献/assets/个人开发者贡献指南/PR流程.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/PR流程.png
rename to 04_社区贡献/assets/个人开发者贡献指南/PR流程.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/fork示例.png b/04_社区贡献/assets/个人开发者贡献指南/fork示例.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/fork示例.png
rename to 04_社区贡献/assets/个人开发者贡献指南/fork示例.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/gitee提交PR.png b/04_社区贡献/assets/个人开发者贡献指南/gitee提交PR.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/gitee提交PR.png
rename to 04_社区贡献/assets/个人开发者贡献指南/gitee提交PR.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/git版本.png b/04_社区贡献/assets/个人开发者贡献指南/git版本.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/git版本.png
rename to 04_社区贡献/assets/个人开发者贡献指南/git版本.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/三种CLA签署形式区别.png b/04_社区贡献/assets/个人开发者贡献指南/三种CLA签署形式区别.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/三种CLA签署形式区别.png
rename to 04_社区贡献/assets/个人开发者贡献指南/三种CLA签署形式区别.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/个人签署CLA流程.png b/04_社区贡献/assets/个人开发者贡献指南/个人签署CLA流程.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/个人签署CLA流程.png
rename to 04_社区贡献/assets/个人开发者贡献指南/个人签署CLA流程.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/企业CLA签署流程.png b/04_社区贡献/assets/个人开发者贡献指南/企业CLA签署流程.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/企业CLA签署流程.png
rename to 04_社区贡献/assets/个人开发者贡献指南/企业CLA签署流程.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/加入sig流程.desktop b/04_社区贡献/assets/个人开发者贡献指南/加入sig流程.desktop
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/加入sig流程.desktop
rename to 04_社区贡献/assets/个人开发者贡献指南/加入sig流程.desktop
diff --git a/05_社区贡献/assets/个人开发者贡献指南/员工CLA签署流程.png b/04_社区贡献/assets/个人开发者贡献指南/员工CLA签署流程.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/员工CLA签署流程.png
rename to 04_社区贡献/assets/个人开发者贡献指南/员工CLA签署流程.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/成功推送修改到个人仓库.png b/04_社区贡献/assets/个人开发者贡献指南/成功推送修改到个人仓库.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/成功推送修改到个人仓库.png
rename to 04_社区贡献/assets/个人开发者贡献指南/成功推送修改到个人仓库.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/提交issue.png b/04_社区贡献/assets/个人开发者贡献指南/提交issue.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/提交issue.png
rename to 04_社区贡献/assets/个人开发者贡献指南/提交issue.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/查看PR状态.png b/04_社区贡献/assets/个人开发者贡献指南/查看PR状态.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/查看PR状态.png
rename to 04_社区贡献/assets/个人开发者贡献指南/查看PR状态.png
diff --git a/05_社区贡献/assets/个人开发者贡献指南/申请单包维护者流程.png b/04_社区贡献/assets/个人开发者贡献指南/申请单包维护者流程.png
similarity index 100%
rename from 05_社区贡献/assets/个人开发者贡献指南/申请单包维护者流程.png
rename to 04_社区贡献/assets/个人开发者贡献指南/申请单包维护者流程.png
diff --git a/05_社区贡献/openKylin个人开发者参与指南.md b/04_社区贡献/openKylin个人开发者参与指南.md
similarity index 99%
rename from 05_社区贡献/openKylin个人开发者参与指南.md
rename to 04_社区贡献/openKylin个人开发者参与指南.md
index b73d8cb5..eba30e91 100644
--- a/05_社区贡献/openKylin个人开发者参与指南.md
+++ b/04_社区贡献/openKylin个人开发者参与指南.md
@@ -17,7 +17,7 @@ CLA全称是`Contributor License Agreement`,翻译过来就是贡献者许可
企业签署CLA的流程如下图所示
-
+
1. 首先在[企业签署](https://cla.openkylin.top/cla/sign/corporation_cla/openKylin-f46f289e01bc11edb8990242ac110005)页面提交企业签署的基本信息,其中`企业`、`联系人`、`职位`、`邮箱`以及`验证码`为必填项,其他信息可以不填;
2. 点击签署按钮后,在上一步中所填写的邮箱中会接收到一份邮件,邮件里面包括了上一步所填写的基本信息以及三个附件文件,依照邮件内容中的提示去完成后续步骤;
diff --git a/05_社区贡献/openKylin社区的文档翻译指南.md b/04_社区贡献/openKylin社区的文档翻译指南.md
similarity index 97%
rename from 05_社区贡献/openKylin社区的文档翻译指南.md
rename to 04_社区贡献/openKylin社区的文档翻译指南.md
index c1559bb0..a146fbfa 100644
--- a/05_社区贡献/openKylin社区的文档翻译指南.md
+++ b/04_社区贡献/openKylin社区的文档翻译指南.md
@@ -1,66 +1,66 @@
-## 签署 CLA
-按照社区的要求,贡献者需要签署 CLA。
-## 目录结构
-主仓库文档的译文建议放到 [en](https://gitee.com/openkylin/docs/tree/master/en) 文件夹下对应的目录,英文的目录树应当与中文的目录树一致。SIG 成员会有专人去进行审核。
-## 文档的类别
-为了避免开发者对各类文档的混淆,这里简单介绍一下区别。
-
-规范(Specification)一般是技术类文档,比如,如何编译软件,如何翻译文档……
-
-政策(Policies)一般是管理类文档,偏向于章程或纲领,比如,社区的理念,社区的组织架构……
-
-规则(Rules)一般也是管理类文档,偏向于守则或规章制度,比如,代码的版权,讨论问题的礼仪……
-
-## 命名规范
-如果目录有空格则全部用短横线“-”隔开,文件名有空格用下划线“_”隔开。
-## 查重
-翻译前请先查阅文档库和搜索引擎,看看是否已有文档的译文。这里有2种情况。
-
-(1)中文版是初始版本,已有相应的英文译文。
-
-(2)英文版是初始版本,中文版是从英文翻译而来。
-
-如果是情况(1),目前文库里已经有了一篇译文。此时你如果提交 PR 可以有 2 个方案。
-
-(1)给原文打补丁,对原文进行修改。
-
-(2)提交新文档。
-
-## 插图的路径
-译文中的插图应当放置在译文同级目录的 assets 文件夹,不要与译文并列存放。引用图片时使用相对路径“./”。这样做的好处是:如果上级文件夹被修改,引用图片的路径不会失效。
-
-## 插图里文本的翻译
-如果条件允许,建议将插图中的中文界面换成英文界面,重新截取。
-
-## 机器翻译和人工校验
-第一,我不反对机器翻译,但是,选择的翻译工具具备可靠性。
-
-第二,人工校对不可缺少,而且,要认真仔细。
-
-## 译文里的常见问题
-
-1、注意英语中的语法、词性和时态。
-
-差:In order to better manage issues, we divide participants into the following roles:
-
-好:For better issues "management" , we "divided" the participants into the following roles:
-
-2、译文要准确表达原文的意思。
-对各项目进行测试。
-
-差:Test projects。
-
-好:Testing of various projects。
-
-3、注意用词的统一。
-中文原文里,分类标签应该翻译为“Kind Tags”。这不是对错的问题,是一种约定吧。
-
-标签,这里不翻译为“label”,应为“Tags”。
-
-参与者,出现了“participant”和“contributor”2种译文。
-
-提出,出现了“proposed”和“raised”2种译文。
-
-## 注意事项
-如无特殊说明主仓库指的是[docs仓库](https://gitee.com/openkylin/docs),副仓库指的是[sig-documentation](https://gitee.com/openkylin/sig-documentation)。
+## 签署 CLA
+按照社区的要求,贡献者需要签署 CLA。
+## 目录结构
+主仓库文档的译文建议放到 [en](https://gitee.com/openkylin/docs/tree/master/en) 文件夹下对应的目录,英文的目录树应当与中文的目录树一致。SIG 成员会有专人去进行审核。
+## 文档的类别
+为了避免开发者对各类文档的混淆,这里简单介绍一下区别。
+
+规范(Specification)一般是技术类文档,比如,如何编译软件,如何翻译文档……
+
+政策(Policies)一般是管理类文档,偏向于章程或纲领,比如,社区的理念,社区的组织架构……
+
+规则(Rules)一般也是管理类文档,偏向于守则或规章制度,比如,代码的版权,讨论问题的礼仪……
+
+## 命名规范
+如果目录有空格则全部用短横线“-”隔开,文件名有空格用下划线“_”隔开。
+## 查重
+翻译前请先查阅文档库和搜索引擎,看看是否已有文档的译文。这里有2种情况。
+
+(1)中文版是初始版本,已有相应的英文译文。
+
+(2)英文版是初始版本,中文版是从英文翻译而来。
+
+如果是情况(1),目前文库里已经有了一篇译文。此时你如果提交 PR 可以有 2 个方案。
+
+(1)给原文打补丁,对原文进行修改。
+
+(2)提交新文档。
+
+## 插图的路径
+译文中的插图应当放置在译文同级目录的 assets 文件夹,不要与译文并列存放。引用图片时使用相对路径“./”。这样做的好处是:如果上级文件夹被修改,引用图片的路径不会失效。
+
+## 插图里文本的翻译
+如果条件允许,建议将插图中的中文界面换成英文界面,重新截取。
+
+## 机器翻译和人工校验
+第一,我不反对机器翻译,但是,选择的翻译工具具备可靠性。
+
+第二,人工校对不可缺少,而且,要认真仔细。
+
+## 译文里的常见问题
+
+1、注意英语中的语法、词性和时态。
+
+差:In order to better manage issues, we divide participants into the following roles:
+
+好:For better issues "management" , we "divided" the participants into the following roles:
+
+2、译文要准确表达原文的意思。
+对各项目进行测试。
+
+差:Test projects。
+
+好:Testing of various projects。
+
+3、注意用词的统一。
+中文原文里,分类标签应该翻译为“Kind Tags”。这不是对错的问题,是一种约定吧。
+
+标签,这里不翻译为“label”,应为“Tags”。
+
+参与者,出现了“participant”和“contributor”2种译文。
+
+提出,出现了“proposed”和“raised”2种译文。
+
+## 注意事项
+如无特殊说明主仓库指的是[docs仓库](https://gitee.com/openkylin/docs),副仓库指的是[sig-documentation](https://gitee.com/openkylin/sig-documentation)。
一般情况下,爱好者写的教程都会放到副仓库,官方提供的文档则会放到主仓库。但此种情况并不绝对,sig组也会根据写的内容来做出对应的建议。
\ No newline at end of file
diff --git a/05_社区贡献/openKylin社区贡献角色.md b/04_社区贡献/openKylin社区贡献角色.md
similarity index 100%
rename from 05_社区贡献/openKylin社区贡献角色.md
rename to 04_社区贡献/openKylin社区贡献角色.md
diff --git a/05_社区贡献/openKylin贡献攻略.md b/04_社区贡献/openKylin贡献攻略.md
similarity index 100%
rename from 05_社区贡献/openKylin贡献攻略.md
rename to 04_社区贡献/openKylin贡献攻略.md
diff --git a/05_社区贡献/开发指南/Peony/README.md b/04_社区贡献/开发指南/Peony/README.md
similarity index 100%
rename from 05_社区贡献/开发指南/Peony/README.md
rename to 04_社区贡献/开发指南/Peony/README.md
diff --git a/04_社区贡献/开发指南/arm上安装openKylin.md b/04_社区贡献/开发指南/arm上安装openKylin.md
new file mode 100644
index 00000000..3fe4078c
--- /dev/null
+++ b/04_社区贡献/开发指南/arm上安装openKylin.md
@@ -0,0 +1,27 @@
+---
+title: 在ARM上安装openKylin
+description:
+published: true
+date: 2023-01-12T02:42:26.148Z
+tags:
+editor: markdown
+dateCreated: 2023-01-12T02:36:15.135Z
+---
+
+# 一、在 coolpi 上安装openKylin
+
+[在 coolpi 上安装openKylin](./在arm设备上安装/在coolpi上安装openKylin.md)
+
+
+
+# 二、在树莓派上安装openKylin
+
+[在树莓派上安装openKylin](./在arm设备上安装/在树莓派上安装openKylin.md)
+
+# 三、在 chilliepi(双椒派) 上 安装 openKylin
+
+[在 chilliepi(双椒派) 上 安装 openKylin](./在arm设备上安装/在chilliepi(双椒派)上安装openKylin.md)
+
+# 四、在 飞腾派 上 安装 openKylin
+
+[在 飞腾派 上 安装 openKylin](./在arm设备上安装/在飞腾派上安装openKylin.md)
diff --git a/05_社区贡献/开发指南/assets/.keep b/04_社区贡献/开发指南/assets/.keep
similarity index 100%
rename from 05_社区贡献/开发指南/assets/.keep
rename to 04_社区贡献/开发指南/assets/.keep
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/0.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/0.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/0.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/0.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/1.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/1.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/1.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/1.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/10.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/10.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/10.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/10.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/100.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/100.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/100.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/100.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/101.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/101.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/101.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/101.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/102.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/102.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/102.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/102.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/103.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/103.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/103.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/103.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/104.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/104.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/104.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/104.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/105.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/105.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/105.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/105.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/106.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/106.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/106.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/106.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/107.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/107.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/107.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/107.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/108.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/108.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/108.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/108.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/109.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/109.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/109.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/109.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/11.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/11.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/11.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/11.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/110.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/110.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/110.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/110.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/111.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/111.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/111.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/111.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/112.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/112.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/112.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/112.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/113.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/113.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/113.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/113.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/114.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/114.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/114.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/114.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/115.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/115.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/115.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/115.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/116.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/116.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/116.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/116.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/117.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/117.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/117.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/117.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/118.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/118.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/118.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/118.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/119.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/119.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/119.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/119.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/12.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/12.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/12.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/12.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/120.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/120.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/120.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/120.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/121.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/121.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/121.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/121.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/122.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/122.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/122.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/122.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/123.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/123.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/123.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/123.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/124.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/124.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/124.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/124.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/125.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/125.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/125.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/125.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/126.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/126.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/126.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/126.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/127.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/127.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/127.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/127.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/128.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/128.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/128.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/128.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/129.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/129.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/129.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/129.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/13.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/13.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/13.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/13.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/130.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/130.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/130.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/130.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/131.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/131.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/131.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/131.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/132.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/132.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/132.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/132.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/133.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/133.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/133.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/133.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/134.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/134.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/134.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/134.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/135.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/135.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/135.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/135.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/136.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/136.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/136.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/136.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/14.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/14.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/14.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/14.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/15.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/15.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/15.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/15.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/16.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/16.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/16.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/16.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/17.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/17.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/17.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/17.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/18.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/18.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/18.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/18.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/19.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/19.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/19.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/19.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/2.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/2.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/2.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/2.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/20.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/20.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/20.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/20.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/21.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/21.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/21.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/21.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/22.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/22.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/22.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/22.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/23.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/23.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/23.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/23.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/24.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/24.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/24.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/24.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/25.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/25.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/25.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/25.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/26.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/26.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/26.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/26.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/27.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/27.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/27.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/27.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/28.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/28.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/28.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/28.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/29.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/29.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/29.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/29.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/3.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/3.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/3.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/3.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/30.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/30.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/30.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/30.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/31.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/31.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/31.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/31.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/32.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/32.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/32.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/32.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/33.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/33.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/33.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/33.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/34.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/34.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/34.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/34.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/35.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/35.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/35.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/35.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/36.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/36.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/36.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/36.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/37.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/37.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/37.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/37.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/38.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/38.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/38.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/38.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/39.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/39.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/39.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/39.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/4.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/4.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/4.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/4.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/40.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/40.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/40.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/40.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/41.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/41.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/41.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/41.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/42.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/42.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/42.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/42.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/43.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/43.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/43.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/43.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/44.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/44.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/44.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/44.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/45.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/45.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/45.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/45.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/46.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/46.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/46.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/46.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/47.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/47.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/47.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/47.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/48.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/48.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/48.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/48.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/49.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/49.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/49.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/49.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/5.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/5.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/5.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/5.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/50.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/50.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/50.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/50.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/51.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/51.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/51.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/51.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/52.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/52.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/52.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/52.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/53.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/53.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/53.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/53.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/54.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/54.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/54.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/54.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/55.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/55.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/55.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/55.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/56.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/56.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/56.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/56.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/57.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/57.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/57.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/57.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/58.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/58.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/58.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/58.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/59.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/59.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/59.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/59.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/6.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/6.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/6.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/6.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/60.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/60.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/60.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/60.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/61.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/61.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/61.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/61.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/62.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/62.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/62.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/62.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/63.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/63.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/63.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/63.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/64.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/64.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/64.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/64.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/65.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/65.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/65.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/65.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/66.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/66.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/66.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/66.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/67.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/67.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/67.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/67.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/68.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/68.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/68.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/68.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/69.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/69.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/69.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/69.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/7.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/7.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/7.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/7.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/70.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/70.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/70.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/70.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/71.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/71.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/71.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/71.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/72.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/72.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/72.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/72.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/73.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/73.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/73.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/73.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/74.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/74.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/74.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/74.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/75.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/75.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/75.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/75.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/76.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/76.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/76.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/76.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/77.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/77.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/77.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/77.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/78.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/78.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/78.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/78.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/79.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/79.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/79.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/79.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/8.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/8.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/8.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/8.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/80.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/80.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/80.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/80.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/81.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/81.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/81.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/81.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/82.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/82.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/82.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/82.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/83.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/83.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/83.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/83.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/84.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/84.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/84.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/84.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/85.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/85.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/85.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/85.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/86.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/86.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/86.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/86.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/87.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/87.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/87.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/87.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/88.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/88.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/88.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/88.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/89.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/89.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/89.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/89.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/9.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/9.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/9.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/9.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/90.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/90.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/90.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/90.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/91.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/91.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/91.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/91.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/92.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/92.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/92.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/92.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/93.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/93.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/93.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/93.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/94.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/94.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/94.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/94.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/95.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/95.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/95.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/95.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/96.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/96.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/96.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/96.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/97.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/97.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/97.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/97.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/98.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/98.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/98.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/98.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/99.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/99.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/99.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/99.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image1.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image1.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image1.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image1.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image10.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image10.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image10.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image10.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image11.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image11.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image11.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image11.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image12.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image12.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image12.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image12.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image13.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image13.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image13.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image13.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image14.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image14.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image14.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image14.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image15.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image15.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image15.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image15.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image16.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image16.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image16.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image16.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image17.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image17.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image17.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image17.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image18.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image18.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image18.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image18.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image19.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image19.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image19.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image19.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image2.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image2.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image2.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image2.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image20.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image20.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image20.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image20.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image21.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image21.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image21.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image21.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image22.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image22.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image22.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image22.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image23.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image23.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image23.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image23.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image24.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image24.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image24.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image24.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image25.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image25.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image25.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image25.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image26.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image26.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image26.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image26.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image27.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image27.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image27.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image27.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image28.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image28.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image28.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image28.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image29.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image29.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image29.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image29.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image3.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image3.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image3.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image3.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image30.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image30.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image30.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image30.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image31.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image31.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image31.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image31.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image32.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image32.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image32.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image32.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image33.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image33.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image33.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image33.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image34.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image34.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image34.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image34.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image35.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image35.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image35.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image35.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image36.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image36.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image36.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image36.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image37.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image37.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image37.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image37.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image38.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image38.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image38.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image38.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image39.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image39.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image39.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image39.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image4.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image4.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image4.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image4.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image40.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image40.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image40.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image40.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image5.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image5.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image5.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image5.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image6.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image6.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image6.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image6.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image7.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image7.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image7.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image7.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image8.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image8.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image8.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image8.png
diff --git a/05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image9.png b/04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image9.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image9.png
rename to 04_社区贡献/开发指南/assets/openKylin SDK开发指南V2.0/image9.png
diff --git a/05_社区贡献/开发指南/assets/openKylin源码包git工作流/native格式源码包转化成quilt格式-流程图.png b/04_社区贡献/开发指南/assets/openKylin源码包git工作流/native格式源码包转化成quilt格式-流程图.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin源码包git工作流/native格式源码包转化成quilt格式-流程图.png
rename to 04_社区贡献/开发指南/assets/openKylin源码包git工作流/native格式源码包转化成quilt格式-流程图.png
diff --git a/05_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例1.png b/04_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例1.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例1.png
rename to 04_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例1.png
diff --git a/05_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例2.png b/04_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例2.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例2.png
rename to 04_社区贡献/开发指南/assets/openKylin源码包git工作流/创建新产线的分支示例2.png
diff --git a/05_社区贡献/开发指南/assets/openKylin源码包git工作流/源码包导入流程图.png b/04_社区贡献/开发指南/assets/openKylin源码包git工作流/源码包导入流程图.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin源码包git工作流/源码包导入流程图.png
rename to 04_社区贡献/开发指南/assets/openKylin源码包git工作流/源码包导入流程图.png
diff --git a/05_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/.keep b/04_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/.keep
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/.keep
rename to 04_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/.keep
diff --git a/05_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/debian社区的软件包追踪平台示例.png b/04_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/debian社区的软件包追踪平台示例.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/debian社区的软件包追踪平台示例.png
rename to 04_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/debian社区的软件包追踪平台示例.png
diff --git a/05_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/软件项目选型策略.png b/04_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/软件项目选型策略.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/软件项目选型策略.png
rename to 04_社区贡献/开发指南/assets/openKylin源码自主选型构建流程/软件项目选型策略.png
diff --git a/05_社区贡献/开发指南/assets/openKylin系统输入法适配指南/inputmethod.png b/04_社区贡献/开发指南/assets/openKylin系统输入法适配指南/inputmethod.png
old mode 100755
new mode 100644
similarity index 100%
rename from 05_社区贡献/开发指南/assets/openKylin系统输入法适配指南/inputmethod.png
rename to 04_社区贡献/开发指南/assets/openKylin系统输入法适配指南/inputmethod.png
diff --git a/05_社区贡献/开发指南/assets/riscv64系统安装/riscv64Lotus2开发板信息.png b/04_社区贡献/开发指南/assets/riscv64系统安装/riscv64Lotus2开发板信息.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/riscv64系统安装/riscv64Lotus2开发板信息.png
rename to 04_社区贡献/开发指南/assets/riscv64系统安装/riscv64Lotus2开发板信息.png
diff --git a/05_社区贡献/开发指南/assets/桌面环境移植/image-1.png b/04_社区贡献/开发指南/assets/桌面环境移植/image-1.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/桌面环境移植/image-1.png
rename to 04_社区贡献/开发指南/assets/桌面环境移植/image-1.png
diff --git a/05_社区贡献/开发指南/assets/桌面环境移植/image.png b/04_社区贡献/开发指南/assets/桌面环境移植/image.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/桌面环境移植/image.png
rename to 04_社区贡献/开发指南/assets/桌面环境移植/image.png
diff --git a/05_社区贡献/开发指南/assets/语音助手适配说明/1.png b/04_社区贡献/开发指南/assets/语音助手适配说明/1.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/语音助手适配说明/1.png
rename to 04_社区贡献/开发指南/assets/语音助手适配说明/1.png
diff --git a/05_社区贡献/开发指南/assets/语音助手适配说明/2.png b/04_社区贡献/开发指南/assets/语音助手适配说明/2.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/语音助手适配说明/2.png
rename to 04_社区贡献/开发指南/assets/语音助手适配说明/2.png
diff --git a/05_社区贡献/开发指南/freedesktop-translate/README.md b/04_社区贡献/开发指南/freedesktop-translate/README.md
similarity index 100%
rename from 05_社区贡献/开发指南/freedesktop-translate/README.md
rename to 04_社区贡献/开发指南/freedesktop-translate/README.md
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/README.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/README.md
similarity index 100%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/README.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/README.md
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML0.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML0.md
similarity index 97%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML0.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML0.md
index 67745fc0..91407dcf 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML0.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML0.md
@@ -1,15 +1,15 @@
-# XML书签交换语言(The XML Bookmark Exchange Language)
-
-> Fred L. Drake, Jr.
-
-> Corporation for National Research Initiatives (CNRI)
-> 1895 Preston White Drive, Reston, Va 20191, USA
->E-mail: fdrake@acm.org
-
-> 28 October, 1998
-> Release 1.0
-
-## 摘要
-
-XML书签交换语言(XBEL)是一种丰富的书签数据交换格式,大多数Internet浏览器都使用这种格式。本文档描述了设计的起源,程序设计过程的需求,以及由此产生的文档类型。
-
+# XML书签交换语言(The XML Bookmark Exchange Language)
+
+> Fred L. Drake, Jr.
+
+> Corporation for National Research Initiatives (CNRI)
+> 1895 Preston White Drive, Reston, Va 20191, USA
+>E-mail: fdrake@acm.org
+
+> 28 October, 1998
+> Release 1.0
+
+## 摘要
+
+XML书签交换语言(XBEL)是一种丰富的书签数据交换格式,大多数Internet浏览器都使用这种格式。本文档描述了设计的起源,程序设计过程的需求,以及由此产生的文档类型。
+
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML1.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML1.md
similarity index 100%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML1.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML1.md
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML2.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML2.md
similarity index 100%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML2.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML2.md
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML3.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML3.md
similarity index 98%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML3.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML3.md
index 130edd69..2b9c3e12 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML3.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML3.md
@@ -1,186 +1,186 @@
-## 3. XBEL文档结构
-
-本节介绍XBEL文档的结构。其中包括DTD中定义的每个元素和属性的信息。一些描述包括对用于构造DTD的参数实体的引用;这些在4.1节“参数实体的使用”中有描述。
-
-### 3.1 日期/时间属性值
-
-在这个文档类型中定义的几个属性要求将日期/时间值存储为CDATA。对于这些属性,值必须格式化为ISO 8601:1988包含日期[fS88,Hou93,Kuh98]的值。只要设置时间值的应用程序可以使用该信息,就应该提供时间值。值的格式被限制为配置文件中指定的格式,定义为日期和时间格式[WW98]。需要这种形式的值的属性将在下面描述为具有日期/时间值而不是CDATA值。
-
-### 3.2 顶级信息
-
-本节描述XBEL文档的顶级元素类型。
-
-#### 3.2.1 ``元素
-
-``元素定义了存储在xbel实例中的顶级数据结构。它可以包含可选的``、``和``元素,后面跟着`%nodes.mix`中的任意数量的元素。这类似于``元素,但它可能不是嵌套的,并且具有不同的属性。
-
-属性
-
-``元素带有一个version属性,该属性有一个固定的值,指定xbel DTD的版本。其他属性表示与``元素的相似性。
-
-version, fixed:指定使用的DTD版本的固定值。
-
-id:ID值,允许链接到该元素;只有``元素的ref属性支持相应的IDREF值。
-
-added:日期/时间值,可用于记录何时创建书签集合。
-
-前置
-
-``元素在许多方面与``元素类似,但可能不会被折叠。辅助信息,例如一个可选的``元素,可能以与用户界面中``完全不同的方式显示。
-
-### 3.3 常见的元素
-
-本节中描述的元素可能出现在XBEL实例中的不同上下文中,但在每种情况下都共享基本的语义解释。
-
-#### 3.3.1 ``元素
-
-``元素用于标记与包围的元素相关联的标题。它用于``、``和``元素。这个元素总是可选的,并且只能包含字符数据。
-
-前置
-
-软件提供了书签信息给用户以任何形式应该使用该元素的内容识别资源给用户。可能需要额外的信息来做出明确的识别。
-应用程序可以在搜索操作中使用``的文本。
-
-基本原理
-
-许多互联网资源都用一个简短的标题来描述,通常由书签功能显示。与检索资源来重新加载标题相比,存储标题可以显著提高用户界面的响应性。XBEL的设计者知道,所有浏览器都采用标题存储。
-
-
-#### 3.3.2 ``元素
-
-``元素用于存储外层元素的可读描述。对于``或``元素,这可以用于更彻底地解释存储在集合中的书签的主题以及它们为什么有趣。对于``,书签指向的资源摘要可能更合适。这个元素总是可选的,只能包含字符数据。
-
-前置
-
-当用户请求包含该描述的文件夹或书签的更多信息时,可以显示此元素的内容。在``的情况下,可以在通过网络实际发出检索资源的请求之前使用它。
-应用程序可以在搜索操作中使用``的文本。
-
-基本原理
-
-许多Internet浏览器支持用人类可读的文本简单地注释书签数据。该成员用于支持该数据的交换。
-
-#### 3.3.3 ``元素
-
-``元素用于存储与立即包围的元素相关的元数据。其预期用途是``存储一系列``元素,每个元素属于某个应用程序。因此,“应用程序”可以是一个程序,例如一个特定的Internet浏览器,也可以是一个更通用的元数据方案,例如都柏林核心[Dub97]。
-
-``元素总是可选的。如果存在,它必须包含一个或多个``元素。
-
-前置
-
-如果应用程序不能处理组成的``元素的内容,则期望忽略``元素。``元素是应该透明传递还是删除取决于处理应用程序的目的,但应努力保持每当封装元素的信息被保留,即使在一个修改的形式。
-
-基本原理
-
-该元素提供了一种简洁的方法,将特定于应用程序的元数据与书签数据中更普遍支持的结构隔离开来。
-
-#### 3.3.4 ``元素
-
-``元素用作一个容器,用于存储与属于单个元数据方案的节点相关的所有辅助信息。``的具体内容高度依赖于所应用的元数据方案;应该使用XML命名空间来标识在元素中使用的显式标记。
-
-``元素总是可选的。注意,必须删除不包含``元素的``元素。
-
-属性
-
-owner:需要CDATA值指定哪个应用程序拥有元素的内容。此属性的值应该是一个URI,它引用以人类或机器可处理形式的应用程序和内容结构的定义。并不要求URI可以通过网络寻址。我们希望将命名空间属性添加到元素中,以指定为``元素的内容定义的标记。
-
-前置
-
-在``元素中,每个``元素都要求owner属性有一个唯一的值。修改``元素内容的程序应确保在受影响的``元素内,应用程序通常修改的所有者值只存在一个``。<用于其他所有者的元数据>元素应该不受影响。
-``内容的具体解释高度依赖于所有者和应用程序,不属于本文档的范围。
-
-基本原理
-
-为支持所有者标识,需要``元素。数据的多个所有者共享一个文档类型作为他们的信息,但需要单独处理是完全合理的。资源描述框架提供了一种方法的示例,该方法要求多个应用程序共享一个命名空间[LS98,BGL98]。还需要一些其他形式的所有权标识,以确保处理器可以避免破坏彼此的数据。
-
-### 3.4 数据组织
-
-本节中描述的成员用于对``节点集合进行组织。``用于支持分层组织,``用于支持非分层组织。
-
-#### 3.4.1 ``元素
-
-``元素是用于支持分层数据组织的元素。它是唯一允许在自身内部嵌套的元素类型。
-
-该元素可以包含可选的``、``和``元素。`%nodes.mix`是允许的。
-
-属性
-
-id:ID值,允许链接到该元素;只有``元素的ref属性支持相应的IDREF值。
-
-added:日期/时间值,记录将文件夹添加到实例所表示的书签集合的时间。
-
-folded:令牌记录文件夹的内容是否应该显示默认的用户界面,值为“yes”或“no”。
-
-前置
-
-用户界面应该显示``元素作为折叠列表,允许用户按需显示或隐藏元素的内容。适当行为以外的用户界面将特定于应用程序的。
-
-基本原理
-
-``元素可以用来表示书签集合中的层次关系,就像当前Internet浏览器中的那样。
-
-
-#### 3.4.2 ``元素
-
-``元素可用于以非层次结构的方式分隔集合中的书签。它可以在``或``元素中使用。
-
-前置
-
-这个元素可以通过在交互式用户界面中显示水平或垂直空白来表示,也可以通过打印表示来表示。
-
-基本原理
-
-需要一个简单的分隔符来支持现有互联网浏览器的书签结构。
-
-### 3.5 书签数据
-
-只有一种元素类型用于封装特定于某个书签的信息。没有证明需要替代元素。
-
-#### 3.5.1 ``元素
-
-``元素用于存储有关特定资源的信息。该元素可以包含可选元素``, ``和``。
-
-属性
-
-``元素比XBEL中定义的其他元素包含更多的属性。这些属性用于携带大多数主流浏览器在书签中维护的公共信息。
-
-href, required:指定由``元素描述的资源的URI。
-
-id:ID值,允许链接到该元素;只有``元素的ref属性支持相应的IDREF值。
-
-added:日期/时间值,表示``元素添加到书签集合的时间。
-
-modified:日期/时间值,记录了对``标识的资源的最后一次已知更改的时间。
-
-visited:日期/时间值,表示用户最后一次“访问”资源的时间。注意,如果软件检查的是自用户上次访问资源以来发生过变化的资源,那么modified的值可能比visited的值更近。这个特性在浏览器中越来越常见。
-
-前置
-
-在用户界面中,``通常应该由``元素的内容表示(如果存在的话)。书签的表示应该是`hot `,允许用户遍历引用的资源。关于资源的附加信息,例如在``元素中给出的描述,应该可供用户根据需要使用。
-在用户界面之外,处理可能过于针对应用程序,因此不适合在这里讨论。
-
-基本原理
-
-使用单个结构化元素类型来表示外部资源简化了处理,同时允许在每个资源上维护丰富的信息集。
-
-
-### 3.6 内部参考
-
-提供了一个元素来支持对XBEL实例中其他元素的内部引用。
-
-#### 3.6.1 ``元素
-
-属性
-``只需要一个属性,用于标识链接引用。
-
-ref, required:IDREF值指``或``元素或文档``元素。
-
-前置
-
-在用户界面中显示书签的软件应该从视觉上区分别名和其他书签,但允许透明地检查参考对象。Netscape Navigator使用斜体显示书签标题。适当的视觉区分可能取决于用户界面的其他方面。
-除了用户界面方面的考虑,别名的处理是特定于应用程序的。然而,一些可能有用的指导。当遇到``时,应用程序只需要遍历``并处理未被处理的referent,否则``通常会被忽略。只有当应用程序正在处理书签层次结构的一部分而不是整个树时,这才会成为问题。
-
-基本原理
-
-Netscape Navigator(网景Navigator,现在叫Firefox)和Microsoft Internet Explorer(微软IE)的书签可以包含层次结构中其他节点的“别名”。Navigator只支持对节点添加别名,而ie也支持对文件夹添加别名。
-导航器的格式只是将属性aliasid添加到被称为别名的节点,将属性aliasof添加到实际的别名。所有其他每个别名的主要信息是重复的书签条目。XBEL使用一个不同的元素和XML提供的ID/IDREF机制来避免冗余并支持验证。
-
+## 3. XBEL文档结构
+
+本节介绍XBEL文档的结构。其中包括DTD中定义的每个元素和属性的信息。一些描述包括对用于构造DTD的参数实体的引用;这些在4.1节“参数实体的使用”中有描述。
+
+### 3.1 日期/时间属性值
+
+在这个文档类型中定义的几个属性要求将日期/时间值存储为CDATA。对于这些属性,值必须格式化为ISO 8601:1988包含日期[fS88,Hou93,Kuh98]的值。只要设置时间值的应用程序可以使用该信息,就应该提供时间值。值的格式被限制为配置文件中指定的格式,定义为日期和时间格式[WW98]。需要这种形式的值的属性将在下面描述为具有日期/时间值而不是CDATA值。
+
+### 3.2 顶级信息
+
+本节描述XBEL文档的顶级元素类型。
+
+#### 3.2.1 ``元素
+
+``元素定义了存储在xbel实例中的顶级数据结构。它可以包含可选的``、``和``元素,后面跟着`%nodes.mix`中的任意数量的元素。这类似于``元素,但它可能不是嵌套的,并且具有不同的属性。
+
+属性
+
+``元素带有一个version属性,该属性有一个固定的值,指定xbel DTD的版本。其他属性表示与``元素的相似性。
+
+version, fixed:指定使用的DTD版本的固定值。
+
+id:ID值,允许链接到该元素;只有``元素的ref属性支持相应的IDREF值。
+
+added:日期/时间值,可用于记录何时创建书签集合。
+
+前置
+
+``元素在许多方面与``元素类似,但可能不会被折叠。辅助信息,例如一个可选的``元素,可能以与用户界面中``完全不同的方式显示。
+
+### 3.3 常见的元素
+
+本节中描述的元素可能出现在XBEL实例中的不同上下文中,但在每种情况下都共享基本的语义解释。
+
+#### 3.3.1 ``元素
+
+``元素用于标记与包围的元素相关联的标题。它用于``、``和``元素。这个元素总是可选的,并且只能包含字符数据。
+
+前置
+
+软件提供了书签信息给用户以任何形式应该使用该元素的内容识别资源给用户。可能需要额外的信息来做出明确的识别。
+应用程序可以在搜索操作中使用``的文本。
+
+基本原理
+
+许多互联网资源都用一个简短的标题来描述,通常由书签功能显示。与检索资源来重新加载标题相比,存储标题可以显著提高用户界面的响应性。XBEL的设计者知道,所有浏览器都采用标题存储。
+
+
+#### 3.3.2 ``元素
+
+``元素用于存储外层元素的可读描述。对于``或``元素,这可以用于更彻底地解释存储在集合中的书签的主题以及它们为什么有趣。对于``,书签指向的资源摘要可能更合适。这个元素总是可选的,只能包含字符数据。
+
+前置
+
+当用户请求包含该描述的文件夹或书签的更多信息时,可以显示此元素的内容。在``的情况下,可以在通过网络实际发出检索资源的请求之前使用它。
+应用程序可以在搜索操作中使用``的文本。
+
+基本原理
+
+许多Internet浏览器支持用人类可读的文本简单地注释书签数据。该成员用于支持该数据的交换。
+
+#### 3.3.3 ``元素
+
+``元素用于存储与立即包围的元素相关的元数据。其预期用途是``存储一系列``元素,每个元素属于某个应用程序。因此,“应用程序”可以是一个程序,例如一个特定的Internet浏览器,也可以是一个更通用的元数据方案,例如都柏林核心[Dub97]。
+
+``元素总是可选的。如果存在,它必须包含一个或多个``元素。
+
+前置
+
+如果应用程序不能处理组成的``元素的内容,则期望忽略``元素。``元素是应该透明传递还是删除取决于处理应用程序的目的,但应努力保持每当封装元素的信息被保留,即使在一个修改的形式。
+
+基本原理
+
+该元素提供了一种简洁的方法,将特定于应用程序的元数据与书签数据中更普遍支持的结构隔离开来。
+
+#### 3.3.4 ``元素
+
+``元素用作一个容器,用于存储与属于单个元数据方案的节点相关的所有辅助信息。``的具体内容高度依赖于所应用的元数据方案;应该使用XML命名空间来标识在元素中使用的显式标记。
+
+``元素总是可选的。注意,必须删除不包含``元素的``元素。
+
+属性
+
+owner:需要CDATA值指定哪个应用程序拥有元素的内容。此属性的值应该是一个URI,它引用以人类或机器可处理形式的应用程序和内容结构的定义。并不要求URI可以通过网络寻址。我们希望将命名空间属性添加到元素中,以指定为``元素的内容定义的标记。
+
+前置
+
+在``元素中,每个``元素都要求owner属性有一个唯一的值。修改``元素内容的程序应确保在受影响的``元素内,应用程序通常修改的所有者值只存在一个``。<用于其他所有者的元数据>元素应该不受影响。
+``内容的具体解释高度依赖于所有者和应用程序,不属于本文档的范围。
+
+基本原理
+
+为支持所有者标识,需要``元素。数据的多个所有者共享一个文档类型作为他们的信息,但需要单独处理是完全合理的。资源描述框架提供了一种方法的示例,该方法要求多个应用程序共享一个命名空间[LS98,BGL98]。还需要一些其他形式的所有权标识,以确保处理器可以避免破坏彼此的数据。
+
+### 3.4 数据组织
+
+本节中描述的成员用于对``节点集合进行组织。``用于支持分层组织,``用于支持非分层组织。
+
+#### 3.4.1 ``元素
+
+``元素是用于支持分层数据组织的元素。它是唯一允许在自身内部嵌套的元素类型。
+
+该元素可以包含可选的``、``和``元素。`%nodes.mix`是允许的。
+
+属性
+
+id:ID值,允许链接到该元素;只有``元素的ref属性支持相应的IDREF值。
+
+added:日期/时间值,记录将文件夹添加到实例所表示的书签集合的时间。
+
+folded:令牌记录文件夹的内容是否应该显示默认的用户界面,值为“yes”或“no”。
+
+前置
+
+用户界面应该显示``元素作为折叠列表,允许用户按需显示或隐藏元素的内容。适当行为以外的用户界面将特定于应用程序的。
+
+基本原理
+
+``元素可以用来表示书签集合中的层次关系,就像当前Internet浏览器中的那样。
+
+
+#### 3.4.2 ``元素
+
+``元素可用于以非层次结构的方式分隔集合中的书签。它可以在``或``元素中使用。
+
+前置
+
+这个元素可以通过在交互式用户界面中显示水平或垂直空白来表示,也可以通过打印表示来表示。
+
+基本原理
+
+需要一个简单的分隔符来支持现有互联网浏览器的书签结构。
+
+### 3.5 书签数据
+
+只有一种元素类型用于封装特定于某个书签的信息。没有证明需要替代元素。
+
+#### 3.5.1 ``元素
+
+``元素用于存储有关特定资源的信息。该元素可以包含可选元素``, ``和``。
+
+属性
+
+``元素比XBEL中定义的其他元素包含更多的属性。这些属性用于携带大多数主流浏览器在书签中维护的公共信息。
+
+href, required:指定由``元素描述的资源的URI。
+
+id:ID值,允许链接到该元素;只有``元素的ref属性支持相应的IDREF值。
+
+added:日期/时间值,表示``元素添加到书签集合的时间。
+
+modified:日期/时间值,记录了对``标识的资源的最后一次已知更改的时间。
+
+visited:日期/时间值,表示用户最后一次“访问”资源的时间。注意,如果软件检查的是自用户上次访问资源以来发生过变化的资源,那么modified的值可能比visited的值更近。这个特性在浏览器中越来越常见。
+
+前置
+
+在用户界面中,``通常应该由``元素的内容表示(如果存在的话)。书签的表示应该是`hot `,允许用户遍历引用的资源。关于资源的附加信息,例如在``元素中给出的描述,应该可供用户根据需要使用。
+在用户界面之外,处理可能过于针对应用程序,因此不适合在这里讨论。
+
+基本原理
+
+使用单个结构化元素类型来表示外部资源简化了处理,同时允许在每个资源上维护丰富的信息集。
+
+
+### 3.6 内部参考
+
+提供了一个元素来支持对XBEL实例中其他元素的内部引用。
+
+#### 3.6.1 ``元素
+
+属性
+``只需要一个属性,用于标识链接引用。
+
+ref, required:IDREF值指``或``元素或文档``元素。
+
+前置
+
+在用户界面中显示书签的软件应该从视觉上区分别名和其他书签,但允许透明地检查参考对象。Netscape Navigator使用斜体显示书签标题。适当的视觉区分可能取决于用户界面的其他方面。
+除了用户界面方面的考虑,别名的处理是特定于应用程序的。然而,一些可能有用的指导。当遇到``时,应用程序只需要遍历``并处理未被处理的referent,否则``通常会被忽略。只有当应用程序正在处理书签层次结构的一部分而不是整个树时,这才会成为问题。
+
+基本原理
+
+Netscape Navigator(网景Navigator,现在叫Firefox)和Microsoft Internet Explorer(微软IE)的书签可以包含层次结构中其他节点的“别名”。Navigator只支持对节点添加别名,而ie也支持对文件夹添加别名。
+导航器的格式只是将属性aliasid添加到被称为别名的节点,将属性aliasof添加到实际的别名。所有其他每个别名的主要信息是重复的书签条目。XBEL使用一个不同的元素和XML提供的ID/IDREF机制来避免冗余并支持验证。
+
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML4.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML4.md
similarity index 97%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML4.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML4.md
index a60c9029..24642ae9 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML4.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML4.md
@@ -1,37 +1,37 @@
-## 4. DTD 结构
-
-本节讨论 DTD 自身的组织结构,主要是为了 XBEL 的维护者以及未来可能定义的任何后续文档类型感兴趣。
-
-### 4.1 参数实体的使用
-
-XBEL DTD 中有限地使用参数实体。后缀表示法采用了“XMLspec”DTD 报告 [Mal98] 中的方法。具体而言,".mix" 后缀用于定义可重复或元素组合的实体,".att" 则用于定义属性的实体。
-
-#### 4.1.1 %nodes.mix 实体
-
-`%nodes.mix` 实体列出了可以用于形成由 XBEL 实例描述的层次数据结构中的节点的元素类型。此实体包含``、``、``和``元素的混合内容。
-
-#### 4.1.2 %node.att 实体
-
-此实体用于定义保存书签数据的实际内容的元素类型的属性。它被应用到``和 ``元素上。它定义了可选的added和id属性。
-
-#### 4.1.3 %url.att 实体
-
-此实体定义了引用特定资源的元素上可用的属性。在 XBEL 1.0 中,仅适用于 ``元素。它定义了必需的 href 属性和可选的 modified 和 visited 属性。
-
-### 4.2 扩展 DTD
-
-对 XBEL 的可扩展性依赖于三个基础:XML 命名空间和接受规范的实例,本地化参数实体以及 DTD 本身的简单性。
-
-对于 DTD 扩展的主要期望是通过使用 XML 命名空间引入和定义新元素和属性。尽管命名空间仍处于 W3C 的工作草案阶段,但在广泛部署的基于XML的标记语言中,命名空间提供了最灵活的扩展机制。在命名空间的上下文中,尚未明确定义验证要求之前,使用命名空间的 XBEL 实例可以将格式良好的规则视为部分验证的工具。
-
-更传统的文档类型扩展使用保留用于本地化的参数实体。XBEL 公共文本提供了三个这样的实体作为“钩子”,允许进行本地定制。对于 Section 4.1 中描述的每个参数实体,“Use of Parameter Entities”,都声明了一个 `%local.name`变体,并在上述每个实体的定义中使用它。这种方式不如命名空间方法灵活,但可以创建一个新的文档类型,可以与当前工具一起用于验证,而无需从头开始创建一个新的公共文本。
-
-可扩展性的第三个基础是 DTD 的简单性,只有通过采用“偷取此代码”的方式进行重用才能有效地使用。XBEL 的简单性使得我们可以很容易地理解其全部内容,并通过创建新的公共文本来创建一个变体文档类型。
-
-### 4.3 通用实体
-
-XBEL DTD 没有定义任何通用实体。
-
-原因
-
+## 4. DTD 结构
+
+本节讨论 DTD 自身的组织结构,主要是为了 XBEL 的维护者以及未来可能定义的任何后续文档类型感兴趣。
+
+### 4.1 参数实体的使用
+
+XBEL DTD 中有限地使用参数实体。后缀表示法采用了“XMLspec”DTD 报告 [Mal98] 中的方法。具体而言,".mix" 后缀用于定义可重复或元素组合的实体,".att" 则用于定义属性的实体。
+
+#### 4.1.1 %nodes.mix 实体
+
+`%nodes.mix` 实体列出了可以用于形成由 XBEL 实例描述的层次数据结构中的节点的元素类型。此实体包含``、``、``和``元素的混合内容。
+
+#### 4.1.2 %node.att 实体
+
+此实体用于定义保存书签数据的实际内容的元素类型的属性。它被应用到``和 ``元素上。它定义了可选的added和id属性。
+
+#### 4.1.3 %url.att 实体
+
+此实体定义了引用特定资源的元素上可用的属性。在 XBEL 1.0 中,仅适用于 ``元素。它定义了必需的 href 属性和可选的 modified 和 visited 属性。
+
+### 4.2 扩展 DTD
+
+对 XBEL 的可扩展性依赖于三个基础:XML 命名空间和接受规范的实例,本地化参数实体以及 DTD 本身的简单性。
+
+对于 DTD 扩展的主要期望是通过使用 XML 命名空间引入和定义新元素和属性。尽管命名空间仍处于 W3C 的工作草案阶段,但在广泛部署的基于XML的标记语言中,命名空间提供了最灵活的扩展机制。在命名空间的上下文中,尚未明确定义验证要求之前,使用命名空间的 XBEL 实例可以将格式良好的规则视为部分验证的工具。
+
+更传统的文档类型扩展使用保留用于本地化的参数实体。XBEL 公共文本提供了三个这样的实体作为“钩子”,允许进行本地定制。对于 Section 4.1 中描述的每个参数实体,“Use of Parameter Entities”,都声明了一个 `%local.name`变体,并在上述每个实体的定义中使用它。这种方式不如命名空间方法灵活,但可以创建一个新的文档类型,可以与当前工具一起用于验证,而无需从头开始创建一个新的公共文本。
+
+可扩展性的第三个基础是 DTD 的简单性,只有通过采用“偷取此代码”的方式进行重用才能有效地使用。XBEL 的简单性使得我们可以很容易地理解其全部内容,并通过创建新的公共文本来创建一个变体文档类型。
+
+### 4.3 通用实体
+
+XBEL DTD 没有定义任何通用实体。
+
+原因
+
由于 XBEL 旨在作为软件之间的交换格式,而不是作为作者格式,因此无需支持用于输入特殊字符的典型实体。与Unicode字符不对应的实体于特定应用程序,无法有意义地预测 [UC96,UC98]。
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML5.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML5.md
similarity index 96%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML5.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML5.md
index 58a75b28..ac1a83c5 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML5.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML5.md
@@ -1,101 +1,101 @@
-# A. 公开文本
-
-本节包含XBEL DTD的整个公共文本,对应于1.4节中给出的正式公共标识符。不引用额外的外部实体。
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+# A. 公开文本
+
+本节包含XBEL DTD的整个公共文本,对应于1.4节中给出的正式公共标识符。不引用额外的外部实体。
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
```
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML6.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML6.md
similarity index 95%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML6.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML6.md
index 10515903..0ec2fbd4 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML6.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML6.md
@@ -1,78 +1,78 @@
-# 参考书目
-
-- BGL98
-Dan Brickley, R. V. Guha, and Andrew Layman.
-Resource description framework (RDF) schema specification.
-Working draft, World Wide Web Consortium, Aug 1998.
-http://www.w3.org/TR/WD-rdf-schema.
-
-- BHL98
-Tim Bray, Dave Hollander, and Andrew Layman.
-Namespaces in XML.
-Working draft, World Wide Web Consortium, Sep 1998.
-http://www.w3.org/TR/WD-xml-names.
-
-- BPSM98
-Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen.
-Extensible markup language (XML) 1.0.
-Recommendation, World Wide Web Consortium, Feb 1998.
-http://www.w3.org/TR/REC-xml.
-
-- Dra
-Fred L. Drake, Jr.
-The XML bookmark exchange language resource page.
-http://www.python.org/topics/xml/xbel/.
-
-- Dub97
-Dublin Core Working Group.
-Dublin core metadata, Nov 1997.
-http://purl.oclc.org/metadata/dublin_core/.
-
-- fS88
-International Organization for Standardization.
-Data elements and interchange formats -- Information interchange -- Representation of dates and times.
-International Organization for Standardization, 1988.
-
-- Hou93
-Gary Houston.
-ISO 8601 date/time representations, Jan 1993.
-ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO8601.ps.Z.
-
-- Kuc
-Andrew M. Kuchling.
-Python and XML processing.
-http://www.python.org/topics/xml/.
-
-- Kuh98
-Markus Kuhn.
-A summary of the international standard date and time notation, Sep 1998.
-http://www.cl.cam.ac.uk/ mgk25/iso-time.html.
-
-- LS98
-Ora Lassila and Ralph R. Swick.
-Resource description framework (RDF) model and syntax specification.
-Working draft, World Wide Web Consortium, Oct 1998.
-http://www.w3.org/TR/WD-rdf-syntax.
-
-- Mal98
-Eve Maler.
-W3C XML Specification DTD (`XMLspec').
-World Wide Web Consortium, Sep 1998.
-http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm.
-
-- UC96
-The Unicode Consotium.
-The Unicode Standard, Version 2.0.
-Addison-Wesley Developers Press, Reading, MA, 1996.
-
-- UC98
-The Unicode Consortium.
-The Unicode standard, version 2.1.
-Technical Report 8, The Unicode Consortium, San Jose, CA, Sep 1998.
-http://www.unicode.org/unicode/reports/tr8.html.
-
-- WW98
-Misha Wolf and Charles Wicksteed.
-Date and time formats.
-Technical note, World Wide Web Consortium, Sep 1998.
+# 参考书目
+
+- BGL98
+Dan Brickley, R. V. Guha, and Andrew Layman.
+Resource description framework (RDF) schema specification.
+Working draft, World Wide Web Consortium, Aug 1998.
+http://www.w3.org/TR/WD-rdf-schema.
+
+- BHL98
+Tim Bray, Dave Hollander, and Andrew Layman.
+Namespaces in XML.
+Working draft, World Wide Web Consortium, Sep 1998.
+http://www.w3.org/TR/WD-xml-names.
+
+- BPSM98
+Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen.
+Extensible markup language (XML) 1.0.
+Recommendation, World Wide Web Consortium, Feb 1998.
+http://www.w3.org/TR/REC-xml.
+
+- Dra
+Fred L. Drake, Jr.
+The XML bookmark exchange language resource page.
+http://www.python.org/topics/xml/xbel/.
+
+- Dub97
+Dublin Core Working Group.
+Dublin core metadata, Nov 1997.
+http://purl.oclc.org/metadata/dublin_core/.
+
+- fS88
+International Organization for Standardization.
+Data elements and interchange formats -- Information interchange -- Representation of dates and times.
+International Organization for Standardization, 1988.
+
+- Hou93
+Gary Houston.
+ISO 8601 date/time representations, Jan 1993.
+ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO8601.ps.Z.
+
+- Kuc
+Andrew M. Kuchling.
+Python and XML processing.
+http://www.python.org/topics/xml/.
+
+- Kuh98
+Markus Kuhn.
+A summary of the international standard date and time notation, Sep 1998.
+http://www.cl.cam.ac.uk/ mgk25/iso-time.html.
+
+- LS98
+Ora Lassila and Ralph R. Swick.
+Resource description framework (RDF) model and syntax specification.
+Working draft, World Wide Web Consortium, Oct 1998.
+http://www.w3.org/TR/WD-rdf-syntax.
+
+- Mal98
+Eve Maler.
+W3C XML Specification DTD (`XMLspec').
+World Wide Web Consortium, Sep 1998.
+http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm.
+
+- UC96
+The Unicode Consotium.
+The Unicode Standard, Version 2.0.
+Addison-Wesley Developers Press, Reading, MA, 1996.
+
+- UC98
+The Unicode Consortium.
+The Unicode standard, version 2.1.
+Technical Report 8, The Unicode Consortium, San Jose, CA, Sep 1998.
+http://www.unicode.org/unicode/reports/tr8.html.
+
+- WW98
+Misha Wolf and Charles Wicksteed.
+Date and time formats.
+Technical note, World Wide Web Consortium, Sep 1998.
http://www.w3.org/TR/WD-rdf-schema.
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML7.md b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML7.md
similarity index 90%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML7.md
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML7.md
index a33f51e9..816b56f2 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML7.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML7.md
@@ -1,17 +1,17 @@
-# 关于这个文档
-
-XML书签交换语言(The XML Bookmark Exchange Language)
-
-该文档是使用LaTeX2HTML翻译器版本98.2 beta6(1998年8月14日)生成的。
-
-版权©1993,1994,1995,1996,1997,Nikos Drakos,计算机基础学习单元(Computer Based Learning Unit),利兹大学(University of Leeds)。
-
-命令行参数如下:
-
-```
-latex2html -init_file /home/fdrake/projects/python/Doc/perl/l2hinit.Perl -init_file /usr/tmp/mkhowto-fdrake-10036。perl dir xbel xbel.tex。
-```
-
-翻译是由Fred L. Drake在1998-10-29
-
+# 关于这个文档
+
+XML书签交换语言(The XML Bookmark Exchange Language)
+
+该文档是使用LaTeX2HTML翻译器版本98.2 beta6(1998年8月14日)生成的。
+
+版权©1993,1994,1995,1996,1997,Nikos Drakos,计算机基础学习单元(Computer Based Learning Unit),利兹大学(University of Leeds)。
+
+命令行参数如下:
+
+```
+latex2html -init_file /home/fdrake/projects/python/Doc/perl/l2hinit.Perl -init_file /usr/tmp/mkhowto-fdrake-10036。perl dir xbel xbel.tex。
+```
+
+翻译是由Fred L. Drake在1998-10-29
+
简体中文翻译由DSOE1024在2023-8-31
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML书签交换语言原文.pdf b/04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML书签交换语言原文.pdf
similarity index 100%
rename from 05_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML书签交换语言原文.pdf
rename to 04_社区贡献/开发指南/freedesktop-translate/XML书签交换语言/XML书签交换语言原文.pdf
diff --git a/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/README.md b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/README.md
new file mode 100644
index 00000000..9539b830
--- /dev/null
+++ b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/README.md
@@ -0,0 +1 @@
+关于UTF8字符串.md
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/UTF8草案.md b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/UTF8草案.md
similarity index 98%
rename from 05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/UTF8草案.md
rename to 04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/UTF8草案.md
index 66b20d48..565aece4 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/UTF8草案.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/UTF8草案.md
@@ -1,193 +1,193 @@
-# 客户端间Unicode文本交换
-
-
-> 2000年1月4日 Juliusz Chroboczek
-
-> 草案!
-
-
-摘要:提出了一种新的属性类型和选择目标
-
-UTF8字符串是携带UTF-8编码的Unicode文本。这个文档只处理UTF8字符串的定义;任何相关的API扩展应在将来的文件中加以说明。
-
-这份文件目前没有任何官方权威;
-然而,它是相当稳定的。
-
-
-## 简介及背景
-
-
-Unicode(UNICODE2, Unicode)是一个带有野心的编码字符集,适用于所有已知文本数据的交换当前和历史的脚本。Unicode字符表是由称为代码点的无符号整数索引。按照惯例,我们为编码点89AB(十六进制)的Unicode字符编写U+89AB。
-
-Unicode字符集的码点对码点完全相同于ISO10646。主要区别在于Unicode定义了文本处理算法,而ISO10646则没有。
-
-UTF-8是一种将Unicode文本编码为8位字节字符流的技术。UTF-8编码具有以下优点和属性:
-
-- 它兼容的7位ASCII,在该映射编码为8位字节的任意ASCII字符字符串UTF-8不需要任何转换;
-
-- 它是无状态的:在任何时候都可以开始解释一个UTF-8编码的字符串;
-
-- UTF-8和16位或32位Unicode值流之间的转换在计算上是微不足道的。
-
-加上Unicode的通用性,这些属性构成了UTF-8纯文本的理想交换格式。特别是,UTF-8允许客户端无缝交换选择ICCCM包含独立于语言环境的多语言文本。
-
-多语言文本目前首选的X11交换格式是复合文本(CTEXT),它是ISO2022的一个大子集。因此,它需要有状态解析,并且是人为在所有用途相同的字符之间的区别,但碰巧属于不同的字符集。
-
-本文提出了一个新的属性类型和选择目标UTF8字符串,携带UTF-8编码的Unicode文本。这个文档只处理UTF8_STRING的定义;API扩展制作更方便的UTF8_STRING操作将在以后的文档,并且不在本文档的范围内。
-
-
-## 规范的一部分
-
-
-本文档建议原子名UTF8字符串(UTF8_STRING)应该是在X.Org注册。这个原子的主要用途是性质类型和选目标,尽管其用于其他目的是不排除在外。
-
-如果属性类型为UTF8_STRING,它应该携带8位数据(即指定格式8)。它应该被解释为编码的字符串根据Unicode标准定义的UTF-8,版本2.0或任何更新的版本。数据仅由UTF-8字符串组成;特别地,它不携带签名,也没有零字节。
-
-类型的属性中的数据没有更多的暗示UTF8字符串。特别是,它不需要在规范的形式,并可能
-包含任何Unicode控制字符,包括但不限于,C0和C1控制字符,段落和换行,方向标记,或平面14语言标记。
-
-如果选择请求指定目标UTF8字符串,则选择holder应该使选择作为UTF-8字符串可用,带
-输入UTF8字符串,格式为8。
-
-为了互操作性的利益,选择的语义目标文本不改变;特别是,用a来回答选择UTF8字符串类型的类型到指定TEXT的请求明确不允许。
-
-
-## 客户端指引
-
-
-内部使用文本编码的客户端可以很容易地映射到鼓励使用UTF8作为首选交换格式。我们鼓励这些应用程序遵守下面的指导方针。这些指导方针都不应被视为规范。
-
-## 组合字符
-
-
-预计在短期内,将会有一些应用程序不能正确处理组合字符。这也是期望任何可以接受组合字符的应用程序将能够正确地解释预先编写的形式。对于这个因此,建议客户端在只要有可能,它们的预先组合形式。
-
-当然,在实际可行的情况下,我们也鼓励客户端接受组合字符。
-
-## 行和段落分隔符
-
-
-传统上,X客户端使用C0字符0x0A换行符来分离行文本。我们建议通过这个公约转换为UTF8字符串属性类型。
-
-客户端应该提供UTF8_STRING类型的选择单独的线和一个U + 000换行字符。段落应该由两个或更多次出现的序列分隔U+ 000a进线。
-
-Unicode引入了两个新的控制字符,用于分隔行和段落,U+2029段落分隔符(PS)和U+2028行分隔符。我们建议这些字符不应该被使用选择供应商。然而,我们强烈建议选择请求者接受并解释这两个特征;一个建议策略是将U+2028行分隔符解释为单个U+000A行FEED和U+2029段落分隔符作为两次出现的序列U+000A线进给。
-
-Unicode BIDI算法与U+000A的交互换行将
-需要澄清。现在,我们建议使用单个U+000A线
-提要不应导致BIDI算法被重置,而序列
-两次或两次以上出现U+000A换行应做到。
-
-## C0和C1控制字符
-
-
-Unicode包含两个范围的控制字符,分别是C0和C1,与ISO8859系列中的控制字符范围的编码。
-
-除了U+000A换行符外,这些字符的使用应该避免选择提供者,因为它们没有很好的定义的语义。然而,选择请求者应该是准备接受任意控制字符。特别是,U+000C形式进料(FF)和U+000B水平制表(HT)是可能的由运行在X11下的应用程序使用,特别是终端模拟器。我们建议解释如下。
-
-U+000C FORM FEED (FF)导致分页。它不应该导致要重置的BIDI算法的状态。简单地把它当作U+000A换行是一个合适的策略。U+000B水平表(HT)应被视为应用程序相关的线性空白的数量。只是对待它像U+0020空间是一个合理的策略。
-
-任何其他的C0或C1控制字符都应该是简单的被选择请求者丢弃。
-
-
-## 选择所有者的指导方针
-
-
-希望进行选择的客户端,称为选择所有者以文本形式提供,应:
-
-1. 响应类型为TARGETS的转换请求(至少)
-TEXT, STRING, UTF8_STRING,可能还有COMPOUND_TEXT。
-
-2. 响应带有目标UTF8字符串的转换请求没有初始签名和结束NULL的UTF-8编码字符串字节存储在类型为UTF8_STRING的属性中。为了最大化互操作性方面,这个字符串最好是预先组合好的形式,但客户端可以自由地使用任意的Unicode字符串当不需要转换为预合成形式时。生产这样的属性涉及生成合适的Unicode控制字符,例如U+000A LINE FEED,以及可能的方向标记和面14语言标签。
-
-3. 来响应带有目标STRING的转换请求选择ISO 8859-1,并以属性表示结果字符串类型。不映射到ISO 8859-1的字符应该是以特定于应用程序的方式替换,或者通过重新映射到类似ISO 8859-1字符(例如,映射Unicode引用)标记为ASCII引号),或替换为易于识别的ASCII
-字符,如' ?'或' #'。
-
-4. 可选地用target响应转换请求COMPOUND_TEXT,具有特定于应用程序和语言环境的转换
-将数据转换成复合文本[CTEXT]。确切的语义转换在本文档中没有描述。
-
-5. 用多态目标TEXT响应转换请求检查所选文本是否可以精确地表示为ISO8859-1字符串。如果是这种情况,选择所有者应该按照第3点进行;否则,按照第4点继续进行。
-
-
-## 请求者的指导方针
-
-
-客户端,称为请求者,希望使用一个可能
-以文本形式提供,应该:
-
-1. 使用目标TARGETS进行转换请求,并检查目标UTF8_STRING、STRING和optional的可用性COMPOUND_TEXT和TEXT。
-
-2. 如果找到了目标UTF8_STRING,请求者应该发出一个目标UTF8_STRING的转换请求。如果这个转换如果成功,请求者应该处理结果的UTF-8编码字符串以特定于应用程序的方式。字符串应该是解释为没有签名或终止NULL字节。在特别地,一个初始的U+FEFF不破零宽度空格或一个finalU+0000 NULL不应该被丢弃。
-
-请求者应该健壮地处理不正确或过长的UTF-8序列。它应该能够任意解释或丢弃Unicode控制字符,包括U+000A LINE FEED,方向标记,以及平面14语言标记。
-
-3.如果没有找到目标UTF8_STRING,或者在步骤中进行转换如果找到了目标COMPOUND_TEXT并且请求者愿意执行从COMPOUND_TEXT到其内部格式,请求者应发出转换请求与目标COMPOUND_TEXT。如果选择转换成功,则然后,请求者应该继续尽最大努力从将COMPOUND_TEXT格式转换为其内部格式。
-
-虽然这一步是可选的,但强烈建议客户执行不要尝试它,因为COMPOUND_TEXT是目前唯一的广泛支持的选择目标和支持交换的属性类型超出ISO 8859-1表的文本。
-
-4. 如果上述步骤2和步骤3都不成功,则目标如果发现字符串,客户端应该发出类型的转换请求字符串。生成的属性应该具有STRING类型并包含ISO 8859-1编码字符串。此字符串中的任何控制字符
-应以特定应用程序的方式进行解释;在特别地,0x0 LINE FEED应该被解释为换行符。
-
-方法进行转换选择多态目标TEXT,然后应该准备好接收属性使用任何文本编码,包括但不限于字符串和组合文本。
-
-
-## 样例实现
-
-
-指南上面的示例实现集成
-使用Thomas Dickey的`XTerm `,补丁级别为108或更高。它是
-可以从
-
-http://www.clark.net/pub/dickey/
-
-`XTerm `的这个实现有不同的版本
-3.9.15及之后的XFree86。XFree86可以从
-
-http://www.xfree86.org
-
-## 当前实践
-
-作者可用的客户端都不符合上述建议。许多客户端使用UTF-8字符串作为属性类型字符串(针对目标文本、字符串或两者兼而有之),这违反了ICCCM约定(ICCCM)。有些客户端试图将Unicode字符串转换为复合文本,并使它们作为属性类型COMPOUND_TEXT可用,遵循ICCCM,但需要复杂的、有状态的转换哪一个不是一对一的,并且可能会被选择反过来请求者。已经发现其他客户端使用UTF-8编码字符串可以在依赖属性类型(如en_US.UTF-8),它在运行的客户端之间进行选择传输在不同的地方非常困难或不可能。
-
-
-## 与Unicode相关的其他格式
-
-
-除了UTF-8, Unicode和ISO 10646都定义了16位格式称为utf - 16和32位格式称为utf - 32。ISO 10646此外,还定义了一种称为UCS-4的32位格式。
-
-UTF-8和其他格式之间的转换是计算上的微不足道的。当限制为BMP时(Unicode字符集codepoints小于2 ^ 16),UTF-8携带最多50%的开销相比于UTF-16, 比UTF-32和UCS-4更紧凑。
-
-出于这些原因,本文件不建议定义机制用于交换编码为UTF-16、UTF-32或UCS-4的数据,这样的机制只会导致混乱和互操作性问题,同时没有给用户带来明显的好处。似乎未来不太可能需要这种机制。
-
-
-## 参考文献
-
-
-- [ARBITRARY] Arbitrary Character Sets. John McCarthy. RFC 373, July
-1972.
-
-- [ASCII] ISO/IEC 646:1991. Information technology -- ISO 7-bit coded
-character set for information interchange
-
-- [CTEXT] Compound Text Encoding, version 1.1. Robert W Scheifler.
-
-- [ICCCM] David Rosenthal and Stuart W. Marks. Inter-Client
-Communication Conventions Manual, Version 2.0.
-
-- [ISO10646] ISO/IEC 10646-1:1993. Information technology -- Universal
-Multiple-Octet Coded Character Set (UCS) -- Part 1:
-Architecture and Basic Multilingual Plane.
-
-- [ISO2022] ISO/IEC 2022:1994 Information technology -- Character code
-structure and extension techniques
-
-- [UTF-8] F. Yergeau. UTF-8, a transformation format of ISO 10646.
-RFC 2279, January 1998.
-
-- [UNICODE2] The Unicode Consortium. The Unicode Standard -- Version
-2.0. Addison-Wesley, 1996. Supplemented by
-The Unicode Standard -- Version 2.1, available from
-http://www.unicode.org/unicode/reports/tr8.html
-
-- [UNICODE] The Unicode Consortium. The Unicode Standard -- Version
+# 客户端间Unicode文本交换
+
+
+> 2000年1月4日 Juliusz Chroboczek
+
+> 草案!
+
+
+摘要:提出了一种新的属性类型和选择目标
+
+UTF8字符串是携带UTF-8编码的Unicode文本。这个文档只处理UTF8字符串的定义;任何相关的API扩展应在将来的文件中加以说明。
+
+这份文件目前没有任何官方权威;
+然而,它是相当稳定的。
+
+
+## 简介及背景
+
+
+Unicode(UNICODE2, Unicode)是一个带有野心的编码字符集,适用于所有已知文本数据的交换当前和历史的脚本。Unicode字符表是由称为代码点的无符号整数索引。按照惯例,我们为编码点89AB(十六进制)的Unicode字符编写U+89AB。
+
+Unicode字符集的码点对码点完全相同于ISO10646。主要区别在于Unicode定义了文本处理算法,而ISO10646则没有。
+
+UTF-8是一种将Unicode文本编码为8位字节字符流的技术。UTF-8编码具有以下优点和属性:
+
+- 它兼容的7位ASCII,在该映射编码为8位字节的任意ASCII字符字符串UTF-8不需要任何转换;
+
+- 它是无状态的:在任何时候都可以开始解释一个UTF-8编码的字符串;
+
+- UTF-8和16位或32位Unicode值流之间的转换在计算上是微不足道的。
+
+加上Unicode的通用性,这些属性构成了UTF-8纯文本的理想交换格式。特别是,UTF-8允许客户端无缝交换选择ICCCM包含独立于语言环境的多语言文本。
+
+多语言文本目前首选的X11交换格式是复合文本(CTEXT),它是ISO2022的一个大子集。因此,它需要有状态解析,并且是人为在所有用途相同的字符之间的区别,但碰巧属于不同的字符集。
+
+本文提出了一个新的属性类型和选择目标UTF8字符串,携带UTF-8编码的Unicode文本。这个文档只处理UTF8_STRING的定义;API扩展制作更方便的UTF8_STRING操作将在以后的文档,并且不在本文档的范围内。
+
+
+## 规范的一部分
+
+
+本文档建议原子名UTF8字符串(UTF8_STRING)应该是在X.Org注册。这个原子的主要用途是性质类型和选目标,尽管其用于其他目的是不排除在外。
+
+如果属性类型为UTF8_STRING,它应该携带8位数据(即指定格式8)。它应该被解释为编码的字符串根据Unicode标准定义的UTF-8,版本2.0或任何更新的版本。数据仅由UTF-8字符串组成;特别地,它不携带签名,也没有零字节。
+
+类型的属性中的数据没有更多的暗示UTF8字符串。特别是,它不需要在规范的形式,并可能
+包含任何Unicode控制字符,包括但不限于,C0和C1控制字符,段落和换行,方向标记,或平面14语言标记。
+
+如果选择请求指定目标UTF8字符串,则选择holder应该使选择作为UTF-8字符串可用,带
+输入UTF8字符串,格式为8。
+
+为了互操作性的利益,选择的语义目标文本不改变;特别是,用a来回答选择UTF8字符串类型的类型到指定TEXT的请求明确不允许。
+
+
+## 客户端指引
+
+
+内部使用文本编码的客户端可以很容易地映射到鼓励使用UTF8作为首选交换格式。我们鼓励这些应用程序遵守下面的指导方针。这些指导方针都不应被视为规范。
+
+## 组合字符
+
+
+预计在短期内,将会有一些应用程序不能正确处理组合字符。这也是期望任何可以接受组合字符的应用程序将能够正确地解释预先编写的形式。对于这个因此,建议客户端在只要有可能,它们的预先组合形式。
+
+当然,在实际可行的情况下,我们也鼓励客户端接受组合字符。
+
+## 行和段落分隔符
+
+
+传统上,X客户端使用C0字符0x0A换行符来分离行文本。我们建议通过这个公约转换为UTF8字符串属性类型。
+
+客户端应该提供UTF8_STRING类型的选择单独的线和一个U + 000换行字符。段落应该由两个或更多次出现的序列分隔U+ 000a进线。
+
+Unicode引入了两个新的控制字符,用于分隔行和段落,U+2029段落分隔符(PS)和U+2028行分隔符。我们建议这些字符不应该被使用选择供应商。然而,我们强烈建议选择请求者接受并解释这两个特征;一个建议策略是将U+2028行分隔符解释为单个U+000A行FEED和U+2029段落分隔符作为两次出现的序列U+000A线进给。
+
+Unicode BIDI算法与U+000A的交互换行将
+需要澄清。现在,我们建议使用单个U+000A线
+提要不应导致BIDI算法被重置,而序列
+两次或两次以上出现U+000A换行应做到。
+
+## C0和C1控制字符
+
+
+Unicode包含两个范围的控制字符,分别是C0和C1,与ISO8859系列中的控制字符范围的编码。
+
+除了U+000A换行符外,这些字符的使用应该避免选择提供者,因为它们没有很好的定义的语义。然而,选择请求者应该是准备接受任意控制字符。特别是,U+000C形式进料(FF)和U+000B水平制表(HT)是可能的由运行在X11下的应用程序使用,特别是终端模拟器。我们建议解释如下。
+
+U+000C FORM FEED (FF)导致分页。它不应该导致要重置的BIDI算法的状态。简单地把它当作U+000A换行是一个合适的策略。U+000B水平表(HT)应被视为应用程序相关的线性空白的数量。只是对待它像U+0020空间是一个合理的策略。
+
+任何其他的C0或C1控制字符都应该是简单的被选择请求者丢弃。
+
+
+## 选择所有者的指导方针
+
+
+希望进行选择的客户端,称为选择所有者以文本形式提供,应:
+
+1. 响应类型为TARGETS的转换请求(至少)
+TEXT, STRING, UTF8_STRING,可能还有COMPOUND_TEXT。
+
+2. 响应带有目标UTF8字符串的转换请求没有初始签名和结束NULL的UTF-8编码字符串字节存储在类型为UTF8_STRING的属性中。为了最大化互操作性方面,这个字符串最好是预先组合好的形式,但客户端可以自由地使用任意的Unicode字符串当不需要转换为预合成形式时。生产这样的属性涉及生成合适的Unicode控制字符,例如U+000A LINE FEED,以及可能的方向标记和面14语言标签。
+
+3. 来响应带有目标STRING的转换请求选择ISO 8859-1,并以属性表示结果字符串类型。不映射到ISO 8859-1的字符应该是以特定于应用程序的方式替换,或者通过重新映射到类似ISO 8859-1字符(例如,映射Unicode引用)标记为ASCII引号),或替换为易于识别的ASCII
+字符,如' ?'或' #'。
+
+4. 可选地用target响应转换请求COMPOUND_TEXT,具有特定于应用程序和语言环境的转换
+将数据转换成复合文本[CTEXT]。确切的语义转换在本文档中没有描述。
+
+5. 用多态目标TEXT响应转换请求检查所选文本是否可以精确地表示为ISO8859-1字符串。如果是这种情况,选择所有者应该按照第3点进行;否则,按照第4点继续进行。
+
+
+## 请求者的指导方针
+
+
+客户端,称为请求者,希望使用一个可能
+以文本形式提供,应该:
+
+1. 使用目标TARGETS进行转换请求,并检查目标UTF8_STRING、STRING和optional的可用性COMPOUND_TEXT和TEXT。
+
+2. 如果找到了目标UTF8_STRING,请求者应该发出一个目标UTF8_STRING的转换请求。如果这个转换如果成功,请求者应该处理结果的UTF-8编码字符串以特定于应用程序的方式。字符串应该是解释为没有签名或终止NULL字节。在特别地,一个初始的U+FEFF不破零宽度空格或一个finalU+0000 NULL不应该被丢弃。
+
+请求者应该健壮地处理不正确或过长的UTF-8序列。它应该能够任意解释或丢弃Unicode控制字符,包括U+000A LINE FEED,方向标记,以及平面14语言标记。
+
+3.如果没有找到目标UTF8_STRING,或者在步骤中进行转换如果找到了目标COMPOUND_TEXT并且请求者愿意执行从COMPOUND_TEXT到其内部格式,请求者应发出转换请求与目标COMPOUND_TEXT。如果选择转换成功,则然后,请求者应该继续尽最大努力从将COMPOUND_TEXT格式转换为其内部格式。
+
+虽然这一步是可选的,但强烈建议客户执行不要尝试它,因为COMPOUND_TEXT是目前唯一的广泛支持的选择目标和支持交换的属性类型超出ISO 8859-1表的文本。
+
+4. 如果上述步骤2和步骤3都不成功,则目标如果发现字符串,客户端应该发出类型的转换请求字符串。生成的属性应该具有STRING类型并包含ISO 8859-1编码字符串。此字符串中的任何控制字符
+应以特定应用程序的方式进行解释;在特别地,0x0 LINE FEED应该被解释为换行符。
+
+方法进行转换选择多态目标TEXT,然后应该准备好接收属性使用任何文本编码,包括但不限于字符串和组合文本。
+
+
+## 样例实现
+
+
+指南上面的示例实现集成
+使用Thomas Dickey的`XTerm `,补丁级别为108或更高。它是
+可以从
+
+http://www.clark.net/pub/dickey/
+
+`XTerm `的这个实现有不同的版本
+3.9.15及之后的XFree86。XFree86可以从
+
+http://www.xfree86.org
+
+## 当前实践
+
+作者可用的客户端都不符合上述建议。许多客户端使用UTF-8字符串作为属性类型字符串(针对目标文本、字符串或两者兼而有之),这违反了ICCCM约定(ICCCM)。有些客户端试图将Unicode字符串转换为复合文本,并使它们作为属性类型COMPOUND_TEXT可用,遵循ICCCM,但需要复杂的、有状态的转换哪一个不是一对一的,并且可能会被选择反过来请求者。已经发现其他客户端使用UTF-8编码字符串可以在依赖属性类型(如en_US.UTF-8),它在运行的客户端之间进行选择传输在不同的地方非常困难或不可能。
+
+
+## 与Unicode相关的其他格式
+
+
+除了UTF-8, Unicode和ISO 10646都定义了16位格式称为utf - 16和32位格式称为utf - 32。ISO 10646此外,还定义了一种称为UCS-4的32位格式。
+
+UTF-8和其他格式之间的转换是计算上的微不足道的。当限制为BMP时(Unicode字符集codepoints小于2 ^ 16),UTF-8携带最多50%的开销相比于UTF-16, 比UTF-32和UCS-4更紧凑。
+
+出于这些原因,本文件不建议定义机制用于交换编码为UTF-16、UTF-32或UCS-4的数据,这样的机制只会导致混乱和互操作性问题,同时没有给用户带来明显的好处。似乎未来不太可能需要这种机制。
+
+
+## 参考文献
+
+
+- [ARBITRARY] Arbitrary Character Sets. John McCarthy. RFC 373, July
+1972.
+
+- [ASCII] ISO/IEC 646:1991. Information technology -- ISO 7-bit coded
+character set for information interchange
+
+- [CTEXT] Compound Text Encoding, version 1.1. Robert W Scheifler.
+
+- [ICCCM] David Rosenthal and Stuart W. Marks. Inter-Client
+Communication Conventions Manual, Version 2.0.
+
+- [ISO10646] ISO/IEC 10646-1:1993. Information technology -- Universal
+Multiple-Octet Coded Character Set (UCS) -- Part 1:
+Architecture and Basic Multilingual Plane.
+
+- [ISO2022] ISO/IEC 2022:1994 Information technology -- Character code
+structure and extension techniques
+
+- [UTF-8] F. Yergeau. UTF-8, a transformation format of ISO 10646.
+RFC 2279, January 1998.
+
+- [UNICODE2] The Unicode Consortium. The Unicode Standard -- Version
+2.0. Addison-Wesley, 1996. Supplemented by
+The Unicode Standard -- Version 2.1, available from
+http://www.unicode.org/unicode/reports/tr8.html
+
+- [UNICODE] The Unicode Consortium. The Unicode Standard -- Version
3.0. Addison-Wesley, 2000.
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8_STRING.md b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8_STRING.md
similarity index 97%
rename from 05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8_STRING.md
rename to 04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8_STRING.md
index 3c6d73cc..79e6c204 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8_STRING.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8_STRING.md
@@ -1,55 +1,55 @@
-# 关于 ***UTF8_STRING***
-
-> 该页面编写于2000年,当时正在初步部署 ***UTF8_STRING*** 。此后,对 ***UTF8_STRING*** 的支持已经得到普及。特别是关于XFree86的任何声明仍适用于X.Org,并且所有最新的工具包都对 ***UTF8_STRING*** 有完全支持。
-
-> 据我所知,下面提供的草案仍然是 ***UTF8_STRING*** 唯一权威规范。
-
- ***UTF8_STRING*** 是一个由X.Org项目正在标准化的新的X11编码方案。 ***UTF8_STRING*** 允许在 X11 客户端之间无缝交换国际文本数据;其主要应用是选择交换(剪切和粘贴)。
-
- ***UTF8_STRING*** 经过精心设计,保持了与现有X11客户端的兼容性;启用 ***UTF8_STRING*** 功能的客户端将使用 ***UTF8_STRING*** 与其他新客户端进行交换,在与旧客户端通信时则回退到复合文本(COMPOUND_TEXT,是一种多字符集数据(如多语言文本)的编码格式)。
-
- ***UTF8_STRING*** 支持应由您正在使用的用户界面库提供,因此对程序员来说应该是完全透明的。仅在你编写使用原始 Xlib库[1] 或 Xt库[2] 的函数访问选择的新部件时,才需要注意 ***UTF8_STRING*** 。
-
-当前版本的 ***UTF8_STRING*** 的文档可以在这个 ***UTF8_STRING*** 草案中找到。
-
-## XFree86库中的 ***UTF8_STRING*** 支持
-
-自4.2版本起, XFree86库 [3]中包含了对 ***UTF8_STRING*** 的大量支持(其中大部分由Bruno Haible完成)。由于这些扩展,只需几行代码即可将 ***UTF8_STRING*** 支持添加到现有客户端中。
-
-值得注意的改变包括:
-
-- 增加了 ***XICCEncodingStyle*** 枚举类型,其中包括一个表示 ***UTF8_STRING*** 的成员 ***XUTF8StringStyle*** ;
-
-- 这些实用程序能够正确理解和解析包含 ***UTF8_STRING*** 的文本属性数据;包括 ***XTextPropertyToStringList***、***XmbTextPropertyToTextList***和 ***XwcTextPropertyToTextList***。
-
-- 所有用于构造文本属性的实用程序都接受 ***XUTF8StringStyle*** 作为属性样式;包括 ***XmbTextListToTextProperty*** 和 ***XwcTextListToTextProperty*** 。
-
-此外,还包含了一些与现有API类似的UTF-8类型;这些包括 ***Xutf8SetWMProperties***、 ***Xutf8TextListToTextProperty*** 、 ***Xutf8TextPropertyToTextList***,以及 ***Xutf8TextEscapement*** 、 ***Xutf8TextExtents*** 、 ***Xutf8TextPerCharExtents*** 、 ***Xutf8DrawText*** 、 ***Xutf8DrawString*** 、 ***Xutf8DrawImageString*** 、 ***Xutf8ResetIC和Xutf8LookupString*** 。
-
-## 客户端中的 ***UTF8_STRING*** 支持
-
-许多X11客户端完全支持 ***UTF8_STRING*** 进行选择交换;其中包括:
-
-- XTerm的XFree86版本(还请参阅手册页);
-- Xaw文本部件的XFree86版本(因而也适用于xedit工具);
-- KDE 2应用程序;
-- 当前版本的Gtk+工具包,因此也适用于当前版本的Gnome;
-- Mozilla的X11版本及其变体
-- 当前版本的Tk工具包,因此也适用于使用Tcl/Tk编写的应用程序。
-
-为了方便地将任意BMP字符插入到所有正确的国际化X11客户端中(包括在一定程度上不支持 ***UTF8_STRING*** 的客户端),你可能想要使用ucm实用程序。
-
-## 更多信息
-
-更多有关在自由Unix-like操作系统下的Unicode支持的详细信息,请参阅Markus Kuhn的Unicode FAQ。
-
-
-### 注释
-
-> 1:X11协议的C语言接口库,用于与X11服务器进行通信
-
-> 2:X Toolkit Intrinsics,X桌面工具包
-
-> 3:XFree86是一个自由开源的X11实现,早期广泛用于Unix-like操作系统上的图形界面系统
-
+# 关于 ***UTF8_STRING***
+
+> 该页面编写于2000年,当时正在初步部署 ***UTF8_STRING*** 。此后,对 ***UTF8_STRING*** 的支持已经得到普及。特别是关于XFree86的任何声明仍适用于X.Org,并且所有最新的工具包都对 ***UTF8_STRING*** 有完全支持。
+
+> 据我所知,下面提供的草案仍然是 ***UTF8_STRING*** 唯一权威规范。
+
+ ***UTF8_STRING*** 是一个由X.Org项目正在标准化的新的X11编码方案。 ***UTF8_STRING*** 允许在 X11 客户端之间无缝交换国际文本数据;其主要应用是选择交换(剪切和粘贴)。
+
+ ***UTF8_STRING*** 经过精心设计,保持了与现有X11客户端的兼容性;启用 ***UTF8_STRING*** 功能的客户端将使用 ***UTF8_STRING*** 与其他新客户端进行交换,在与旧客户端通信时则回退到复合文本(COMPOUND_TEXT,是一种多字符集数据(如多语言文本)的编码格式)。
+
+ ***UTF8_STRING*** 支持应由您正在使用的用户界面库提供,因此对程序员来说应该是完全透明的。仅在你编写使用原始 Xlib库[1] 或 Xt库[2] 的函数访问选择的新部件时,才需要注意 ***UTF8_STRING*** 。
+
+当前版本的 ***UTF8_STRING*** 的文档可以在这个 ***UTF8_STRING*** 草案中找到。
+
+## XFree86库中的 ***UTF8_STRING*** 支持
+
+自4.2版本起, XFree86库 [3]中包含了对 ***UTF8_STRING*** 的大量支持(其中大部分由Bruno Haible完成)。由于这些扩展,只需几行代码即可将 ***UTF8_STRING*** 支持添加到现有客户端中。
+
+值得注意的改变包括:
+
+- 增加了 ***XICCEncodingStyle*** 枚举类型,其中包括一个表示 ***UTF8_STRING*** 的成员 ***XUTF8StringStyle*** ;
+
+- 这些实用程序能够正确理解和解析包含 ***UTF8_STRING*** 的文本属性数据;包括 ***XTextPropertyToStringList***、***XmbTextPropertyToTextList***和 ***XwcTextPropertyToTextList***。
+
+- 所有用于构造文本属性的实用程序都接受 ***XUTF8StringStyle*** 作为属性样式;包括 ***XmbTextListToTextProperty*** 和 ***XwcTextListToTextProperty*** 。
+
+此外,还包含了一些与现有API类似的UTF-8类型;这些包括 ***Xutf8SetWMProperties***、 ***Xutf8TextListToTextProperty*** 、 ***Xutf8TextPropertyToTextList***,以及 ***Xutf8TextEscapement*** 、 ***Xutf8TextExtents*** 、 ***Xutf8TextPerCharExtents*** 、 ***Xutf8DrawText*** 、 ***Xutf8DrawString*** 、 ***Xutf8DrawImageString*** 、 ***Xutf8ResetIC和Xutf8LookupString*** 。
+
+## 客户端中的 ***UTF8_STRING*** 支持
+
+许多X11客户端完全支持 ***UTF8_STRING*** 进行选择交换;其中包括:
+
+- XTerm的XFree86版本(还请参阅手册页);
+- Xaw文本部件的XFree86版本(因而也适用于xedit工具);
+- KDE 2应用程序;
+- 当前版本的Gtk+工具包,因此也适用于当前版本的Gnome;
+- Mozilla的X11版本及其变体
+- 当前版本的Tk工具包,因此也适用于使用Tcl/Tk编写的应用程序。
+
+为了方便地将任意BMP字符插入到所有正确的国际化X11客户端中(包括在一定程度上不支持 ***UTF8_STRING*** 的客户端),你可能想要使用ucm实用程序。
+
+## 更多信息
+
+更多有关在自由Unix-like操作系统下的Unicode支持的详细信息,请参阅Markus Kuhn的Unicode FAQ。
+
+
+### 注释
+
+> 1:X11协议的C语言接口库,用于与X11服务器进行通信
+
+> 2:X Toolkit Intrinsics,X桌面工具包
+
+> 3:XFree86是一个自由开源的X11实现,早期广泛用于Unix-like操作系统上的图形界面系统
+
> 翻译:DSOE1024 校对:DSOE1024
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8字符串原文.txt b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8字符串原文.txt
similarity index 97%
rename from 05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8字符串原文.txt
rename to 04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8字符串原文.txt
index c24bfe17..2deb3db8 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8字符串原文.txt
+++ b/04_社区贡献/开发指南/freedesktop-translate/关于UTF8字符串/关于UTF8字符串原文.txt
@@ -1,36 +1,36 @@
-About UTF8_STRING
-This page was written in 2000, when UTF8_STRING was being initially deployed. Since then, support for UTF8_STRING has become widespread. In particular, anything claimed about XFree86 still applies to X.Org, and all recent toolkits have full support for UTF8_STRING.
-
-As far as I know, the draft provided below is still the only authoritative specification of UTF8_STRING.
-
-UTF8_STRING is a new X11 atom currently in the process of being standardised by X.Org. UTF8_STRING allows seamless interchange of international textual data between X11 clients; its main application is selection interchange (cut and paste).
-
-UTF8_STRING was carefully designed to preserve compatibility with existing X11 clients; a UTF8_STRING-enabled client will use UTF8_STRING for interchange with other new clients, and fall back to COMPOUND_TEXT when speaking to older clients.
-
-UTF8_STRING support should be provided by the widget set (user-interface library) that you are using, and hence be completely transparent to the programmer. You need to be aware of UTF8_STRING only if you write a new widget that uses raw Xlib or Xt functions to access the selection.
-
-UTF8_STRING is currently documented in this UTF8_STRING draft.
-
-UTF8_STRING support in XFree86 libraries
-A lot of support for UTF8_STRING is included in the XFree86 libraries since version 4.2 (most of this work was done by Bruno Haible). Thanks to these extensions, adding UTF8_STRING support to an existing clients can be done in a few lines of code.
-
-Notable changes include:
-
-the XICCEncodingStyle enumeration type has been extended with a XUTF8StringStyle member which represents UTF8_STRING;
-all utilities for interpreting text properties grok UTF8_STRING; this includes XTextPropertyToStringList, XmbTextPropertyToTextList, and XwcTextPropertyToTextList.
-all utilities to construct text properties accept XUTF8StringStyle as the property style; this includes XmbTextListToTextProperty and XwcTextListToTextProperty.
-In addition, a number of UTF-8 analogues to existing APIs have been included; these are Xutf8SetWMProperties, Xutf8TextListToTextProperty, Xutf8TextPropertyToTextList, as well as Xutf8TextEscapement, Xutf8TextExtents, Xutf8TextPerCharExtents, Xutf8DrawText, Xutf8DrawString, Xutf8DrawImageString, Xutf8ResetIC, Xutf8LookupString.
-
-UTF8_STRING support in clients
-Many X11 clients fully support UTF8_STRING for selection interchange; this includes:
-
-the XFree86 version of XTerm (see also the manual page);
-the XFree86 version of the Xaw text widget (and hence the xedit utility);
-KDE 2 applications;
-current versions of the Gtk+ toolkit, and hence current versions of Gnome;
-the X11 version of Mozilla and its variants;
-current versions of the Tk toolkit, and hence applications misguidedly written in Tcl/Tk.
-In order to conveniently insert arbitrary BMP characters into all properly internationalised X11 clients (including, to a certain extent, those that do not support UTF8_STRING), you may want to use the ucm utility.
-
-Further information
+About UTF8_STRING
+This page was written in 2000, when UTF8_STRING was being initially deployed. Since then, support for UTF8_STRING has become widespread. In particular, anything claimed about XFree86 still applies to X.Org, and all recent toolkits have full support for UTF8_STRING.
+
+As far as I know, the draft provided below is still the only authoritative specification of UTF8_STRING.
+
+UTF8_STRING is a new X11 atom currently in the process of being standardised by X.Org. UTF8_STRING allows seamless interchange of international textual data between X11 clients; its main application is selection interchange (cut and paste).
+
+UTF8_STRING was carefully designed to preserve compatibility with existing X11 clients; a UTF8_STRING-enabled client will use UTF8_STRING for interchange with other new clients, and fall back to COMPOUND_TEXT when speaking to older clients.
+
+UTF8_STRING support should be provided by the widget set (user-interface library) that you are using, and hence be completely transparent to the programmer. You need to be aware of UTF8_STRING only if you write a new widget that uses raw Xlib or Xt functions to access the selection.
+
+UTF8_STRING is currently documented in this UTF8_STRING draft.
+
+UTF8_STRING support in XFree86 libraries
+A lot of support for UTF8_STRING is included in the XFree86 libraries since version 4.2 (most of this work was done by Bruno Haible). Thanks to these extensions, adding UTF8_STRING support to an existing clients can be done in a few lines of code.
+
+Notable changes include:
+
+the XICCEncodingStyle enumeration type has been extended with a XUTF8StringStyle member which represents UTF8_STRING;
+all utilities for interpreting text properties grok UTF8_STRING; this includes XTextPropertyToStringList, XmbTextPropertyToTextList, and XwcTextPropertyToTextList.
+all utilities to construct text properties accept XUTF8StringStyle as the property style; this includes XmbTextListToTextProperty and XwcTextListToTextProperty.
+In addition, a number of UTF-8 analogues to existing APIs have been included; these are Xutf8SetWMProperties, Xutf8TextListToTextProperty, Xutf8TextPropertyToTextList, as well as Xutf8TextEscapement, Xutf8TextExtents, Xutf8TextPerCharExtents, Xutf8DrawText, Xutf8DrawString, Xutf8DrawImageString, Xutf8ResetIC, Xutf8LookupString.
+
+UTF8_STRING support in clients
+Many X11 clients fully support UTF8_STRING for selection interchange; this includes:
+
+the XFree86 version of XTerm (see also the manual page);
+the XFree86 version of the Xaw text widget (and hence the xedit utility);
+KDE 2 applications;
+current versions of the Gtk+ toolkit, and hence current versions of Gnome;
+the X11 version of Mozilla and its variants;
+current versions of the Tk toolkit, and hence applications misguidedly written in Tcl/Tk.
+In order to conveniently insert arbitrary BMP characters into all properly internationalised X11 clients (including, to a certain extent, those that do not support UTF8_STRING), you may want to use the ucm utility.
+
+Further information
For more information about Unicode support under Free Unix-like operating systems, please consult Markus Kuhn's Unicode FAQ.
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/LICENSE b/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/LICENSE
similarity index 100%
rename from 05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/LICENSE
rename to 04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/LICENSE
diff --git a/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/README.md b/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/README.md
new file mode 100644
index 00000000..46244eaa
--- /dev/null
+++ b/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/README.md
@@ -0,0 +1 @@
+自由媒体播放器规范翻译.md
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/开源媒体播放器规范翻译.md b/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/开源媒体播放器规范翻译.md
similarity index 98%
rename from 05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/开源媒体播放器规范翻译.md
rename to 04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/开源媒体播放器规范翻译.md
index 0c71f392..0eedbd08 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/开源媒体播放器规范翻译.md
+++ b/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/开源媒体播放器规范翻译.md
@@ -1,256 +1,256 @@
-# 开源媒体播放器格式
-
-> 标签规范
-> 1.1版本;2010年10月16日
-> 版权所有:Jeff Mitchell [mitchell@kde.org]
-
-## 摘要
-
-该规范描述了各种音频文件元数据,旨在提高开源音乐播放器之间的互操作性,例如评级、播放量、表演者等。它通过为目前还不存在的通用功能需求提出标准来实现这一点,并以一种易于跨播放器和跨格式的方式来实现。它被设计得非常强大来应对未来的需求,并防止与其他标签标识符和值发生可能的冲突。
-
-## 目录
-
-* 1 前言
- * 1.1 许可协议
- * 1.2 术语
-
-* 2 音频元数据标签
- * 2.1 常用数据和标签信息
- * 2.1.1 MP3
- * 2.1.2 VorbisComments
- * 2.1.3 APEv2
- * 2.1.4 MP4
- * 2.1.5 Windows Media
- * 2.2 评分标签
- * 2.2.1 所有评级标签
- * 2.2.2 FMPS_Rating
- * 2.2.3 FMPS_Rating_User
- * 2.3 FMPS_Rating_Critic
- * 2.3.1 FMPS_Rating_Algorithm
- * 2.4 Playcount标签
- * 2.4.1 所有Playcount标签
- * 2.4.2 用户播放计数条件
- * 2.4.3 FMPS_Playcount
- * 2.4.4 FMPS_Playcount_User
- * 2.4.5 FMPS_Playcount_Algorithm
- * 2.5 表演者
- * 2.6 歌词
- * 2.7 专辑/合辑(“各种艺术家”)标识符
-
-
-## 1.前言
-
-### 1.1 许可证
-
-您可以根据以下任一许可使用本规范,由您自行决定。大多数人希望在知识共享下使用它;GPL替代方案是为了防止规范的未来版本包含你想在GPL程序中使用的代码片段:
-
-
-
-1. 本规范遵循知识 ***CC-BY-ND-3.0*** 协议。您可以自由复制、发布和传播本作品,前提是保留版权信息和许可信息页面(http://creativecommons.org/licenses/by-nd/3.0/)的完整URL。如果您更改、转换或在本作品的基础上构建,您只能在与本作品相同或类似的许可下发布由此产生的作品
-
-2. 这个项目是开源软件;您可以根据自由软件基金会发布的GNU通用公共许可条款重新发布或修改它;许可证的版本为2,或者(由您选择)任何更高的版本。发布这个项目是希望它有用,但没有任何保证;甚至没有隐含的适销性或适用于特定目的的保证。有关更多细节,请参阅GNU通用公共许可证。参见http://www.gnu.org/licenses/
-
-### 1.2 术语
-
-术语遵循RFC2119中规定的“在rfc中用于表示需求级别的关键字”。更多信息请参见http://www.ietf.org/rfc/rfc2119.txt
-
-## 2 音频元数据标签
-
-元数据标签格式是从Quod Libet的VorbisComments演变而来的
-http://code.google.com/p/quodlibet/wiki/Specs_VorbisComments 上的建议,然而,这不仅试图解决该URL规范的歧义和不兼容性,而且还定义了应如何跨格式应用此功能。它的目的是,可用于当前未指定的格式插入元数据的方法,本文档将更新以满足这些需求。
-
-所有新指定的标签都带有一个标识符“FMPS_”,用于将标签与本规范绑定。原因很简单:由于官方元数据规范未能定义或定义不可用的标记,这些值仅在采用该规范时是官方的。如果没有一个标识符来为这些值的含义和限制提供上下文,就有可能出现不符合要求的媒体播放器以不兼容的方式使用相同的标签名的情况,无论有意还是无意,而且无法确定不符合要求的播放器对标签的看似兼容的使用实际上是否会导致用户预期的行为。因此,“FMPS_”标识符和此规范文档以类似于XML模式声明的方式使用。
-由于这些标识符仅由播放者和高级用户读取和修改,因此预计不会阻碍采用或造成不必要的负担
-
-### 2.1 常用数据和标签信息
-
-本节提供了与下面描述的所有标记相关的“前置”信息,例如使用什么编码以及在各种格式中使用哪些标记
-
-对于所有标签格式,定义如下:
-
-- 所有标识符都是ASCII字符串,在下面的几节中定义。所有标识符字符串都必须对冒号(‘:’)、分号(’;‘)和反斜杠(‘\’)使用反斜杠进行转义
-
-- 所有值(包括数值)都存储为字符串,必须遵守相关标签格式规范中允许的编码和长度限制,但应尽可能使用Unicode
-
- - 为了使规范简单,没有定义控制字符的范围,这些字符永远不应该包含在字符串中。假定使用的字符串处理库可以正确地处理遇到的任何此类字符。但是,强烈建议不要使用这种控制字符,除非在下面指定
-
- - 所有的值的字符串都必须转义每个冒号(‘:’)、分号(’;‘)和反斜杠(‘\’)
-
-
-- 尽管为不同类型的标记指定了标识符的大小写,但与标识符字符串的比较必须不区分大小写
-
-- 句号(英文状态的句号)用于将浮点值中的数字与浮点的小数部分分隔开。所有浮点值必须包括一个句号(1是不可接受的;1.0是正确的)。
-
-- 浮点数应该限制为6位小数
-
-- 所有列表都是值字符串。对于任何列表,条目必须用双分号‘;;’分隔,条目内的字段必须用双冒号‘::’分隔(以下各节举例)。这些分隔标记不能用反斜杠转义。这使得大多数字符串库可以轻松地拆分列表项和输入字段;条目和字段可以用双分号/双冒号分隔,随后的字段可以有任何转义值被替换
-
-
-以下各节描述应在何处以特定的标记格式存储信息
-
-#### 2.1.1 MP3
-
-MP3值必须存储在TXXX帧中,描述设置为指定的标识符,文本设置为值的字符串表示。按照以下章节的规定,描述应采用驼峰命名法,例如FMPS_Rating
-
-#### 2.1.2 VorbisComments
-
-任何支持VorbisComments的文件(Vorbis、FLAC、Theora、Speex)都必须使用注释,其中键设置为指定的标识符,值设置为值的字符串表示。键必须全部为大写,例如FMPS_RATING
-
-#### 2.1.3 APEv2
-
-任何支持APEv2的文件都必须添加注释,其中键设置为指定的标识符,值设置为该值的字符串表示。键必须全部为大写,例如FMPS_RATING
-
-#### 2.1.4 MP4
-
-MP4的值必须存储在----:com.apple.iTunes:<带值的标识符>,是表示标签值的字符串。按照以下章节的规定,该标示符应采用驼峰命名法,例如FMPS_Rating
-
-#### 2.1.5 Windows Media
-
-Windows媒体值必须存储在FMPS/Identifier命名空间中,其值是表示标签值的字符串。按照以下章节的规定,该标示符应采用驼峰命名法,例如FMPS_Rating
-
-### 2.2 Rating Tags
-
-大多数媒体播放器支持对内容进行评级的概念,但是在文件中存储评级的标准还不存在。一些文件元数据格式完全没有评级字段;另一些要求将个人身份信息用作标识符(如用户的电子邮件地址)或组织标识符(这降低了跨播放器兼容性)。因此,目标很简单:避免任何个人识别信息,但避免将评级与特定播放器联系在一起。
-
-目前定义了三种类型的评分:用户评分、评论家评分和自动(或算法)评分。
-
-虽然用户更自然地能够理解整数评级,但只有高级用户才会直接与这些标签交互;否则,它们将通过符合规范的应用程序呈现给用户。与此同时,将评分存储为浮点数有一些实际的好处,主要是因为精度的提高允许使用许多有趣和有用的算法评分方案。然而,不必要地同时使用整数和浮点值会增加规范和应用程序代码的复杂性。因此,这两个值都被存储为浮点数。如果需要,可以在应用程序的代码中轻松地完成这些和应用程序中呈现给用户的整数比例之间的转换。
-
-定义了4个标签,对应于定义的3种评级类型,外加一个标准值:FMPS_Rating_User;FMPS_Rating_Critic;FMPS_Rating_Algorithm;以及FMPS_Rating(规范值)。一个文件如果没有用于特定目的的评级标签,则被认为是未评级的(用户、评论或算法)
-
-#### 2.2.1 所有评级标签
-
-- 评级应为0.0到1.0之间的浮动值,包括0.0和1.0。0.0应为可能的最低评级;1.0是最高的评分
-
-- 评级应该只在必要时进行舍入,以提高跨播放器兼容性
-
-#### 2.2.2 FMPS_Rating
-
-- FMPS_Rating中的规范评级值应该在用户对曲目评级时设置。这是FMPS_Rating_User中为该特定用户存储的任何值的附加值。这个值是规范的,因为如果一个播放器不支持多个用户(或者没有设置用户标识符),这个值就必须返回
-
-- 如果用户从媒体播放器的数据库中删除了曲目的评级,那么FMPS_Rating标签的值也应该被清除
-
-#### 2.2.3 FMPS_Rating_User
-
-- 如果玩家支持播放者的概念(可能从操作系统发现当前用户),并希望允许用户保持独立的评分,它必须将这些值存储在FMPS_Rating_User标签中
-
-- 支持多用户评分的应用程序应该为用户提供一种方式来定义他们首选的标识符
-
-- 这些值是2.1节定义的列表形式,列表项的格式为UserIdentifier::Value。不能有空值字符串
-
-示例:``` “Alice Abba::0.6;;Bob Beatles::0.8” ```
-
-### 2.3 FMPS_Rating_Critic
-
-- 值必须是2.1节中定义的列表形式,列表项的格式为Publication::Critic::Rating。如果评论人是独立的,或者评级是由没有署名的出版物做出的,则必须使用特殊值“FMPS_Nothing”表示这一点;不能有空字符串
-
-示例:``` “Rolling Stone::Ralph Gleason::0.83;;musicOMH.com::FMPS_Nothing::0.76;;Metacritic::FMPS_Nothing::0.8;;FMPS_Nothing::Some Dude::0.9” ```
-
-#### 2.3.1 FMPS_Rating_Algorithm
-
-- 值必须是2.1节定义的列表形式,列表项的格式为Application::Algorithm::Rating。所有字段都必须定义。字段不能为空
-
-- 在全局/协作/跨应用(global/collaborative/cross-application)的情况下,应用的值应该设置为某个商定的值。换句话说,建议使用应用程序名称作为标识符的应用程序部分,但它也可以用于标识一组算法,或其他可以用于标识的任意值
-
-示例:``` “Amarok::AutoRate::0.52;;VLC::Standard::0.6;;QuodLibet::RatingPlugin\:X::0.35;;The Free Music Player Alliance::Rating Algorithm 1::0.5” ```
-
-
-关于浮点值的注意事项:有些播放器可能只允许用户以1到5之间的整数增量进行评分;其他0和10;等等......然而,播放器应该确保他们所显示和用于任何目的的评级与保存在标签中的评级保持一致,只有在绝对必要的时候才取整这个数字
-
-例如,如果一首歌的评分为0.9,而应用程序只使用五星图标以全星递增的方式显示评分,则应用程序将其四舍五入为五星。然而,如果播放器还以数字形式显示评级,应用程序将在数字字段中显示4.5,而不是在星形图标中显示的5,从而更准确地反映用户的设置评级
-
-### 2.4 Playcount标签
-
-与评级一样,除了标准值之外,还有多种playcount标签(user和algorithmic)。user标签记录一首歌为用户播放了多少次。auto/algorithmic值可以以特定于应用程序的方式使用,做一些有趣的事情;例如,累计跟踪播放的歌曲的确切百分比,以便向用户显示他们收听某首歌曲的天数/小时/分钟/秒
-
-定义了三个标签,对应于定义的两种类型的播放计数,外加一个规范值:FMPS_Playcount_User;FMPS_Playcount_Algorithm;以及FMPS_Playcount(规范值)。如果一个文件没有playcount标记用于特定目的,则认为该文件在该目的下(用户或算法)未播放
-
-#### 2.4.1 所有播放数标签
-
-- Playcounts必须是一个不小于0.0的浮点值。0.0是有效的,表示未播放。
-
-- 最大值比32位无符号整数所能存储的最大值小0.000001,最大值为4,294,967 294.999999。这样playcount的值可以在必要时舍入为一个等价的整数(例如显示给用户)
-
-#### 2.4.2 用户播放数标准
-
-用户播放数并不意味着由用户设置,而是遵循这些定义用户行为的规则。如果一个文件满足以下条件,则认为它“已播放”,灵感来自Last.Fm的自动关闭规则:
-
-- 如果音轨长度小于30秒,则必须播放整首歌曲
-
-- 如果音轨长度超过30秒但小于8分钟,则至少要播放文件的50%,通过音轨长度计算。例如,如果一个音轨长1分钟,那么至少播放了30秒的音轨,如果用户向后跳了多次,并且连续听了3次相同的10秒的音轨,则可以认为这是一个有效的播放计数
-
-- 如果音轨长于8分钟,则必须播放至少4分钟的音轨
-
-用户播放次数有一个额外的限制,即它们必须是表示整数的浮点值(1.0、141.0等)。它们从来都不是小数值;一首歌要么播放,要么不播放
-
-#### 2.4.3 FMPS_Playcount
-
-- FMPS_Playcount中的规范playcount值应该在用户播放曲目时设置。这是FMPS_Playcount_User中为该用户存储的任何值的附加值。这个值是规范的,因为如果一个播放器不支持多个用户(或者没有设置用户标识符),这个值必须返回
-
-- 如果一个用户设置了一个标识符来存储每个用户的播放计数,当设置此值时,它必须设置为该用户的播放计数的值。换句话说,FMPS_Playcount中保存的最后一个值将等同于最新的用户个人播放数(如果有的话)
-
-- 如果用户在媒体播放器的数据库中重置了一个曲目的播放计数,那么FMPS_Playcount标签的值也应该被清除
-
-- 根据2.4.2节的规则,FMPS_Playcount必须存储曲目的“全部次播放”
-
-#### 2.4.4 FMPS_Playcount_User
-
-- 如果一个播放器支持多用户的概念(可能从操作系统发现当前用户),并希望允许用户保持独立的播放计数,它必须将这些值存储在FMPS_Playcount_User标签中
-
-- 支持多用户播放次数的应用程序应该为用户提供一种方式来定义他们的首选标识符
-
-- 这些值必须是2.1节定义的列表形式,列表项的格式为UserIdentifier::Value。不能有空字符串
-
-- 根据2.4.2节的规则,FMPS_Playcount_User必须存储曲目的“全部播放”
-
-示例:``` “Alice Abba::1.0;;Bob Beatles::133.0”. ```
-
-#### 2.4.5 FMPS_Playcount_Algorithm
-
-- 这些值必须是2.3.1节中定义的列表形式,列表项的格式为Application::Algorithm::Playcount。所有字段都必须定义。字段不能为空
-
-- 在全局/协作/跨应用(global/collaborative/cross-application)的情况下,应用的值应该设置为某个商定的值。换句话说,建议使用应用程序名称作为标识符的应用程序部分,但它也可以用于标识一组算法,或其他可以用于标识的任意值
-
-- 对于算法来说,曲目长度必须考虑为1.0次播放次数;跳过部分音轨的用户可能会使这个值降低到1.0以下,重复部分音轨的用户可能会使这个值增加到1.0以上。
-
-示例: ``` “437 Amarok::AutoPlaycount::152.69;;VLC::Standard::198.0;;QuodLibet::PlaycountPlugin\:X::1652.19;;The 438 Music Player Alliance::Playcount Algorithm 1::0.5” ```
-
-### 2.5 Performer Roles
-
-表演者允许您描述一个音轨中的表演者。当前对标签格式中这些角色的支持通常是零星的或难以解析的。可以指定尽可能多的这些标签,以包括所有相关的表演者信息
-
-- 表演者使用标识符“fmps_performer”。该值必须是一个列表,格式为Performer::Role,其中Role是用户定义的角色(" Guitar ", " Guitar (Backup) ", " Vocals ")
-
-示例:``` “Willy Nelson::Guitar;;Eric Clapton::Guitar 452 (Backup);;B.B. King::Vocals” ```
-
-### 2.6 歌词
-
-将歌词嵌入到文件中允许用户保存自定义歌词,并且在不连接互联网时仍然可以看到歌词。由于不同的用户可能希望有不同的歌词集(例如,根据只有音乐的曲目定制歌词),不同的互联网源可能有不同的歌词,因此可以通过指定源来存储多个歌词值
-
-- (规范的)歌词文本的标识符是“FMPS_Lyrics”。该值必须是字符串。在保存字符串时,空格、制表符和换行符应该保留,并且应该正确地显示给用户
-
-- 歌词也可以存储在FMPS_Lyrics_Sources中作为一个列表(如2.1节定义),在这种情况下,表单必须是Source::Data
-
-示例:``` “Alice Aardvark::[lyrics];;Bob
-Baboon::[lyrics];;http\://www.lyricssite.net::[lyrics]” ```
-
-### 2.7 专辑/合辑(“各类艺术家”)标识符
-
-音乐播放器很难发现合集(或“各种艺术家”专辑)。有时,用户将编译后的所有文件放在一个目录中,并希望音乐播放器能够理解这一点;有时,用户将它们放在不同的目录中,但具有相同的专辑名,并希望音乐播放器能够理解这一点;等等......
-
-虽然有现有的解决方案来识别属于同一专辑的专辑和歌曲(例如MusicBrainz标识符),但许多用户没有或不想用MusicBrainz信息标记他们的歌曲。因此,这个标签为应用程序提供了一种简单的方法,可以将专辑标识符分配给曲目,表明曲目所属的专辑。它还提供了一种简单的方法来标记专辑是否为合辑。
-
-这样就可以实现这样的用例:允许用户标记属于单个编译的多个曲目,然后当用户下次将这些曲目添加到音乐播放器时,这些曲目显示为在一个编译中一起出现。
-
-本节故意不定义有关专辑/合集的信息;预计用户必须在适当的现有标签中提供该信息,例如用于VorbisComments的ALBUM和albumartist
-
-- 专辑/编译标记(album/compilation)的标识符是FMPS_Albums_Compilations。虽然这个标签对于合集/各种艺术家的专辑最有用,但对于播放器来说,使用这个标签识别单个艺术家的专辑仍然有很大的用处。因此,播放器不能假设该标签的存在是否表明该曲目属于合集/各种艺术家的专辑,而必须明确地从标签值中获得该信息
-
-- 值必须是一个列表(如2.1节所定义),形式为Application::Type::Identifier。如果用户希望将一个音轨标记为存在于多个编译中,或者为一个编译提供用户定义的名称,应用程序可能有多个标识符。但每个链表项必须是唯一的。与本规范中的其他标记类似,在应用程序名称上的互操作可能有重要的实用价值
-
-- Type必须是下列值之一,不带引号:"
-“Album”(指一张通用专辑,通常由单个艺术家创作)或“Compilation”(指合辑,通常由多个/不同的艺术家创作)。对该值的检查必须不区分大小写。将来可能会添加更多的值;如果播放器遇到未知值,默认输入" Album "
-
-示例:```“Amarok::Album::2982ab29ef;;AmarokUser::Compilation::My
-528 Compilation;;Banshee::Compilation::ad8slpbzl229zier;;FMPSAlliance::Album::de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3”```
-
+# 开源媒体播放器格式
+
+> 标签规范
+> 1.1版本;2010年10月16日
+> 版权所有:Jeff Mitchell [mitchell@kde.org]
+
+## 摘要
+
+该规范描述了各种音频文件元数据,旨在提高开源音乐播放器之间的互操作性,例如评级、播放量、表演者等。它通过为目前还不存在的通用功能需求提出标准来实现这一点,并以一种易于跨播放器和跨格式的方式来实现。它被设计得非常强大来应对未来的需求,并防止与其他标签标识符和值发生可能的冲突。
+
+## 目录
+
+* 1 前言
+ * 1.1 许可协议
+ * 1.2 术语
+
+* 2 音频元数据标签
+ * 2.1 常用数据和标签信息
+ * 2.1.1 MP3
+ * 2.1.2 VorbisComments
+ * 2.1.3 APEv2
+ * 2.1.4 MP4
+ * 2.1.5 Windows Media
+ * 2.2 评分标签
+ * 2.2.1 所有评级标签
+ * 2.2.2 FMPS_Rating
+ * 2.2.3 FMPS_Rating_User
+ * 2.3 FMPS_Rating_Critic
+ * 2.3.1 FMPS_Rating_Algorithm
+ * 2.4 Playcount标签
+ * 2.4.1 所有Playcount标签
+ * 2.4.2 用户播放计数条件
+ * 2.4.3 FMPS_Playcount
+ * 2.4.4 FMPS_Playcount_User
+ * 2.4.5 FMPS_Playcount_Algorithm
+ * 2.5 表演者
+ * 2.6 歌词
+ * 2.7 专辑/合辑(“各种艺术家”)标识符
+
+
+## 1.前言
+
+### 1.1 许可证
+
+您可以根据以下任一许可使用本规范,由您自行决定。大多数人希望在知识共享下使用它;GPL替代方案是为了防止规范的未来版本包含你想在GPL程序中使用的代码片段:
+
+
+
+1. 本规范遵循知识 ***CC-BY-ND-3.0*** 协议。您可以自由复制、发布和传播本作品,前提是保留版权信息和许可信息页面(http://creativecommons.org/licenses/by-nd/3.0/)的完整URL。如果您更改、转换或在本作品的基础上构建,您只能在与本作品相同或类似的许可下发布由此产生的作品
+
+2. 这个项目是开源软件;您可以根据自由软件基金会发布的GNU通用公共许可条款重新发布或修改它;许可证的版本为2,或者(由您选择)任何更高的版本。发布这个项目是希望它有用,但没有任何保证;甚至没有隐含的适销性或适用于特定目的的保证。有关更多细节,请参阅GNU通用公共许可证。参见http://www.gnu.org/licenses/
+
+### 1.2 术语
+
+术语遵循RFC2119中规定的“在rfc中用于表示需求级别的关键字”。更多信息请参见http://www.ietf.org/rfc/rfc2119.txt
+
+## 2 音频元数据标签
+
+元数据标签格式是从Quod Libet的VorbisComments演变而来的
+http://code.google.com/p/quodlibet/wiki/Specs_VorbisComments 上的建议,然而,这不仅试图解决该URL规范的歧义和不兼容性,而且还定义了应如何跨格式应用此功能。它的目的是,可用于当前未指定的格式插入元数据的方法,本文档将更新以满足这些需求。
+
+所有新指定的标签都带有一个标识符“FMPS_”,用于将标签与本规范绑定。原因很简单:由于官方元数据规范未能定义或定义不可用的标记,这些值仅在采用该规范时是官方的。如果没有一个标识符来为这些值的含义和限制提供上下文,就有可能出现不符合要求的媒体播放器以不兼容的方式使用相同的标签名的情况,无论有意还是无意,而且无法确定不符合要求的播放器对标签的看似兼容的使用实际上是否会导致用户预期的行为。因此,“FMPS_”标识符和此规范文档以类似于XML模式声明的方式使用。
+由于这些标识符仅由播放者和高级用户读取和修改,因此预计不会阻碍采用或造成不必要的负担
+
+### 2.1 常用数据和标签信息
+
+本节提供了与下面描述的所有标记相关的“前置”信息,例如使用什么编码以及在各种格式中使用哪些标记
+
+对于所有标签格式,定义如下:
+
+- 所有标识符都是ASCII字符串,在下面的几节中定义。所有标识符字符串都必须对冒号(‘:’)、分号(’;‘)和反斜杠(‘\’)使用反斜杠进行转义
+
+- 所有值(包括数值)都存储为字符串,必须遵守相关标签格式规范中允许的编码和长度限制,但应尽可能使用Unicode
+
+ - 为了使规范简单,没有定义控制字符的范围,这些字符永远不应该包含在字符串中。假定使用的字符串处理库可以正确地处理遇到的任何此类字符。但是,强烈建议不要使用这种控制字符,除非在下面指定
+
+ - 所有的值的字符串都必须转义每个冒号(‘:’)、分号(’;‘)和反斜杠(‘\’)
+
+
+- 尽管为不同类型的标记指定了标识符的大小写,但与标识符字符串的比较必须不区分大小写
+
+- 句号(英文状态的句号)用于将浮点值中的数字与浮点的小数部分分隔开。所有浮点值必须包括一个句号(1是不可接受的;1.0是正确的)。
+
+- 浮点数应该限制为6位小数
+
+- 所有列表都是值字符串。对于任何列表,条目必须用双分号‘;;’分隔,条目内的字段必须用双冒号‘::’分隔(以下各节举例)。这些分隔标记不能用反斜杠转义。这使得大多数字符串库可以轻松地拆分列表项和输入字段;条目和字段可以用双分号/双冒号分隔,随后的字段可以有任何转义值被替换
+
+
+以下各节描述应在何处以特定的标记格式存储信息
+
+#### 2.1.1 MP3
+
+MP3值必须存储在TXXX帧中,描述设置为指定的标识符,文本设置为值的字符串表示。按照以下章节的规定,描述应采用驼峰命名法,例如FMPS_Rating
+
+#### 2.1.2 VorbisComments
+
+任何支持VorbisComments的文件(Vorbis、FLAC、Theora、Speex)都必须使用注释,其中键设置为指定的标识符,值设置为值的字符串表示。键必须全部为大写,例如FMPS_RATING
+
+#### 2.1.3 APEv2
+
+任何支持APEv2的文件都必须添加注释,其中键设置为指定的标识符,值设置为该值的字符串表示。键必须全部为大写,例如FMPS_RATING
+
+#### 2.1.4 MP4
+
+MP4的值必须存储在----:com.apple.iTunes:<带值的标识符>,是表示标签值的字符串。按照以下章节的规定,该标示符应采用驼峰命名法,例如FMPS_Rating
+
+#### 2.1.5 Windows Media
+
+Windows媒体值必须存储在FMPS/Identifier命名空间中,其值是表示标签值的字符串。按照以下章节的规定,该标示符应采用驼峰命名法,例如FMPS_Rating
+
+### 2.2 Rating Tags
+
+大多数媒体播放器支持对内容进行评级的概念,但是在文件中存储评级的标准还不存在。一些文件元数据格式完全没有评级字段;另一些要求将个人身份信息用作标识符(如用户的电子邮件地址)或组织标识符(这降低了跨播放器兼容性)。因此,目标很简单:避免任何个人识别信息,但避免将评级与特定播放器联系在一起。
+
+目前定义了三种类型的评分:用户评分、评论家评分和自动(或算法)评分。
+
+虽然用户更自然地能够理解整数评级,但只有高级用户才会直接与这些标签交互;否则,它们将通过符合规范的应用程序呈现给用户。与此同时,将评分存储为浮点数有一些实际的好处,主要是因为精度的提高允许使用许多有趣和有用的算法评分方案。然而,不必要地同时使用整数和浮点值会增加规范和应用程序代码的复杂性。因此,这两个值都被存储为浮点数。如果需要,可以在应用程序的代码中轻松地完成这些和应用程序中呈现给用户的整数比例之间的转换。
+
+定义了4个标签,对应于定义的3种评级类型,外加一个标准值:FMPS_Rating_User;FMPS_Rating_Critic;FMPS_Rating_Algorithm;以及FMPS_Rating(规范值)。一个文件如果没有用于特定目的的评级标签,则被认为是未评级的(用户、评论或算法)
+
+#### 2.2.1 所有评级标签
+
+- 评级应为0.0到1.0之间的浮动值,包括0.0和1.0。0.0应为可能的最低评级;1.0是最高的评分
+
+- 评级应该只在必要时进行舍入,以提高跨播放器兼容性
+
+#### 2.2.2 FMPS_Rating
+
+- FMPS_Rating中的规范评级值应该在用户对曲目评级时设置。这是FMPS_Rating_User中为该特定用户存储的任何值的附加值。这个值是规范的,因为如果一个播放器不支持多个用户(或者没有设置用户标识符),这个值就必须返回
+
+- 如果用户从媒体播放器的数据库中删除了曲目的评级,那么FMPS_Rating标签的值也应该被清除
+
+#### 2.2.3 FMPS_Rating_User
+
+- 如果玩家支持播放者的概念(可能从操作系统发现当前用户),并希望允许用户保持独立的评分,它必须将这些值存储在FMPS_Rating_User标签中
+
+- 支持多用户评分的应用程序应该为用户提供一种方式来定义他们首选的标识符
+
+- 这些值是2.1节定义的列表形式,列表项的格式为UserIdentifier::Value。不能有空值字符串
+
+示例:``` “Alice Abba::0.6;;Bob Beatles::0.8” ```
+
+### 2.3 FMPS_Rating_Critic
+
+- 值必须是2.1节中定义的列表形式,列表项的格式为Publication::Critic::Rating。如果评论人是独立的,或者评级是由没有署名的出版物做出的,则必须使用特殊值“FMPS_Nothing”表示这一点;不能有空字符串
+
+示例:``` “Rolling Stone::Ralph Gleason::0.83;;musicOMH.com::FMPS_Nothing::0.76;;Metacritic::FMPS_Nothing::0.8;;FMPS_Nothing::Some Dude::0.9” ```
+
+#### 2.3.1 FMPS_Rating_Algorithm
+
+- 值必须是2.1节定义的列表形式,列表项的格式为Application::Algorithm::Rating。所有字段都必须定义。字段不能为空
+
+- 在全局/协作/跨应用(global/collaborative/cross-application)的情况下,应用的值应该设置为某个商定的值。换句话说,建议使用应用程序名称作为标识符的应用程序部分,但它也可以用于标识一组算法,或其他可以用于标识的任意值
+
+示例:``` “Amarok::AutoRate::0.52;;VLC::Standard::0.6;;QuodLibet::RatingPlugin\:X::0.35;;The Free Music Player Alliance::Rating Algorithm 1::0.5” ```
+
+
+关于浮点值的注意事项:有些播放器可能只允许用户以1到5之间的整数增量进行评分;其他0和10;等等......然而,播放器应该确保他们所显示和用于任何目的的评级与保存在标签中的评级保持一致,只有在绝对必要的时候才取整这个数字
+
+例如,如果一首歌的评分为0.9,而应用程序只使用五星图标以全星递增的方式显示评分,则应用程序将其四舍五入为五星。然而,如果播放器还以数字形式显示评级,应用程序将在数字字段中显示4.5,而不是在星形图标中显示的5,从而更准确地反映用户的设置评级
+
+### 2.4 Playcount标签
+
+与评级一样,除了标准值之外,还有多种playcount标签(user和algorithmic)。user标签记录一首歌为用户播放了多少次。auto/algorithmic值可以以特定于应用程序的方式使用,做一些有趣的事情;例如,累计跟踪播放的歌曲的确切百分比,以便向用户显示他们收听某首歌曲的天数/小时/分钟/秒
+
+定义了三个标签,对应于定义的两种类型的播放计数,外加一个规范值:FMPS_Playcount_User;FMPS_Playcount_Algorithm;以及FMPS_Playcount(规范值)。如果一个文件没有playcount标记用于特定目的,则认为该文件在该目的下(用户或算法)未播放
+
+#### 2.4.1 所有播放数标签
+
+- Playcounts必须是一个不小于0.0的浮点值。0.0是有效的,表示未播放。
+
+- 最大值比32位无符号整数所能存储的最大值小0.000001,最大值为4,294,967 294.999999。这样playcount的值可以在必要时舍入为一个等价的整数(例如显示给用户)
+
+#### 2.4.2 用户播放数标准
+
+用户播放数并不意味着由用户设置,而是遵循这些定义用户行为的规则。如果一个文件满足以下条件,则认为它“已播放”,灵感来自Last.Fm的自动关闭规则:
+
+- 如果音轨长度小于30秒,则必须播放整首歌曲
+
+- 如果音轨长度超过30秒但小于8分钟,则至少要播放文件的50%,通过音轨长度计算。例如,如果一个音轨长1分钟,那么至少播放了30秒的音轨,如果用户向后跳了多次,并且连续听了3次相同的10秒的音轨,则可以认为这是一个有效的播放计数
+
+- 如果音轨长于8分钟,则必须播放至少4分钟的音轨
+
+用户播放次数有一个额外的限制,即它们必须是表示整数的浮点值(1.0、141.0等)。它们从来都不是小数值;一首歌要么播放,要么不播放
+
+#### 2.4.3 FMPS_Playcount
+
+- FMPS_Playcount中的规范playcount值应该在用户播放曲目时设置。这是FMPS_Playcount_User中为该用户存储的任何值的附加值。这个值是规范的,因为如果一个播放器不支持多个用户(或者没有设置用户标识符),这个值必须返回
+
+- 如果一个用户设置了一个标识符来存储每个用户的播放计数,当设置此值时,它必须设置为该用户的播放计数的值。换句话说,FMPS_Playcount中保存的最后一个值将等同于最新的用户个人播放数(如果有的话)
+
+- 如果用户在媒体播放器的数据库中重置了一个曲目的播放计数,那么FMPS_Playcount标签的值也应该被清除
+
+- 根据2.4.2节的规则,FMPS_Playcount必须存储曲目的“全部次播放”
+
+#### 2.4.4 FMPS_Playcount_User
+
+- 如果一个播放器支持多用户的概念(可能从操作系统发现当前用户),并希望允许用户保持独立的播放计数,它必须将这些值存储在FMPS_Playcount_User标签中
+
+- 支持多用户播放次数的应用程序应该为用户提供一种方式来定义他们的首选标识符
+
+- 这些值必须是2.1节定义的列表形式,列表项的格式为UserIdentifier::Value。不能有空字符串
+
+- 根据2.4.2节的规则,FMPS_Playcount_User必须存储曲目的“全部播放”
+
+示例:``` “Alice Abba::1.0;;Bob Beatles::133.0”. ```
+
+#### 2.4.5 FMPS_Playcount_Algorithm
+
+- 这些值必须是2.3.1节中定义的列表形式,列表项的格式为Application::Algorithm::Playcount。所有字段都必须定义。字段不能为空
+
+- 在全局/协作/跨应用(global/collaborative/cross-application)的情况下,应用的值应该设置为某个商定的值。换句话说,建议使用应用程序名称作为标识符的应用程序部分,但它也可以用于标识一组算法,或其他可以用于标识的任意值
+
+- 对于算法来说,曲目长度必须考虑为1.0次播放次数;跳过部分音轨的用户可能会使这个值降低到1.0以下,重复部分音轨的用户可能会使这个值增加到1.0以上。
+
+示例: ``` “437 Amarok::AutoPlaycount::152.69;;VLC::Standard::198.0;;QuodLibet::PlaycountPlugin\:X::1652.19;;The 438 Music Player Alliance::Playcount Algorithm 1::0.5” ```
+
+### 2.5 Performer Roles
+
+表演者允许您描述一个音轨中的表演者。当前对标签格式中这些角色的支持通常是零星的或难以解析的。可以指定尽可能多的这些标签,以包括所有相关的表演者信息
+
+- 表演者使用标识符“fmps_performer”。该值必须是一个列表,格式为Performer::Role,其中Role是用户定义的角色(" Guitar ", " Guitar (Backup) ", " Vocals ")
+
+示例:``` “Willy Nelson::Guitar;;Eric Clapton::Guitar 452 (Backup);;B.B. King::Vocals” ```
+
+### 2.6 歌词
+
+将歌词嵌入到文件中允许用户保存自定义歌词,并且在不连接互联网时仍然可以看到歌词。由于不同的用户可能希望有不同的歌词集(例如,根据只有音乐的曲目定制歌词),不同的互联网源可能有不同的歌词,因此可以通过指定源来存储多个歌词值
+
+- (规范的)歌词文本的标识符是“FMPS_Lyrics”。该值必须是字符串。在保存字符串时,空格、制表符和换行符应该保留,并且应该正确地显示给用户
+
+- 歌词也可以存储在FMPS_Lyrics_Sources中作为一个列表(如2.1节定义),在这种情况下,表单必须是Source::Data
+
+示例:``` “Alice Aardvark::[lyrics];;Bob
+Baboon::[lyrics];;http\://www.lyricssite.net::[lyrics]” ```
+
+### 2.7 专辑/合辑(“各类艺术家”)标识符
+
+音乐播放器很难发现合集(或“各种艺术家”专辑)。有时,用户将编译后的所有文件放在一个目录中,并希望音乐播放器能够理解这一点;有时,用户将它们放在不同的目录中,但具有相同的专辑名,并希望音乐播放器能够理解这一点;等等......
+
+虽然有现有的解决方案来识别属于同一专辑的专辑和歌曲(例如MusicBrainz标识符),但许多用户没有或不想用MusicBrainz信息标记他们的歌曲。因此,这个标签为应用程序提供了一种简单的方法,可以将专辑标识符分配给曲目,表明曲目所属的专辑。它还提供了一种简单的方法来标记专辑是否为合辑。
+
+这样就可以实现这样的用例:允许用户标记属于单个编译的多个曲目,然后当用户下次将这些曲目添加到音乐播放器时,这些曲目显示为在一个编译中一起出现。
+
+本节故意不定义有关专辑/合集的信息;预计用户必须在适当的现有标签中提供该信息,例如用于VorbisComments的ALBUM和albumartist
+
+- 专辑/编译标记(album/compilation)的标识符是FMPS_Albums_Compilations。虽然这个标签对于合集/各种艺术家的专辑最有用,但对于播放器来说,使用这个标签识别单个艺术家的专辑仍然有很大的用处。因此,播放器不能假设该标签的存在是否表明该曲目属于合集/各种艺术家的专辑,而必须明确地从标签值中获得该信息
+
+- 值必须是一个列表(如2.1节所定义),形式为Application::Type::Identifier。如果用户希望将一个音轨标记为存在于多个编译中,或者为一个编译提供用户定义的名称,应用程序可能有多个标识符。但每个链表项必须是唯一的。与本规范中的其他标记类似,在应用程序名称上的互操作可能有重要的实用价值
+
+- Type必须是下列值之一,不带引号:"
+“Album”(指一张通用专辑,通常由单个艺术家创作)或“Compilation”(指合辑,通常由多个/不同的艺术家创作)。对该值的检查必须不区分大小写。将来可能会添加更多的值;如果播放器遇到未知值,默认输入" Album "
+
+示例:```“Amarok::Album::2982ab29ef;;AmarokUser::Compilation::My
+528 Compilation;;Banshee::Compilation::ad8slpbzl229zier;;FMPSAlliance::Album::de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3”```
+
diff --git a/05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/自由媒体播放器规范原文.txt b/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/自由媒体播放器规范原文.txt
similarity index 97%
rename from 05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/自由媒体播放器规范原文.txt
rename to 04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/自由媒体播放器规范原文.txt
index 6e21a3fd..080cd30d 100644
--- a/05_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/自由媒体播放器规范原文.txt
+++ b/04_社区贡献/开发指南/freedesktop-translate/开源媒体播放器规范/自由媒体播放器规范原文.txt
@@ -1,528 +1,528 @@
-Free Media Player Specifications
-
-Tag Specification
-
-version 1.1; October 16, 2010
-
-Copyright 2009-2010 by Jeff Mitchell [mitchell@kde.org]
-
-Abstract
-
-This specification describes various audio file tag metadata
-intended to increase interoperability between free music players
-for things such as ratings, playcounts, performer roles, and
-more. It does this by proposing standards for common
-functionality needs where none currently exist, and doing so in a
-way that is easily adoptable cross-player and cross-format. It is
-designed to be robust against future needs and to prevent
-possible conflicts with other tag identifiers and values.
-
-Table of Contents
-
- 1 Front Matter
- 1.1 License
- 1.2 Terminology
- 2 Audio Metadata Tags
- 2.1 Common Data and Tag Information
- 2.1.1 MP3
- 2.1.2 VorbisComments
- 2.1.3 APEv2
- 2.1.4 MP4
- 2.1.5 Windows Media
- 2.2 Rating Tags
- 2.2.1 All Rating Tags
- 2.2.2 FMPS_Rating
- 2.2.3 FMPS_Rating_User
- 2.3 FMPS_Rating_Critic
- 2.3.1 FMPS_Rating_Algorithm
- 2.4 Playcount Tags
- 2.4.1 All Playcount Tags
- 2.4.2 User Playcount Criteria
- 2.4.3 FMPS_Playcount
- 2.4.4 FMPS_Playcount_User
- 2.4.5 FMPS_Playcount_Algorithm
- 2.5 Performer Roles
- 2.6 Lyrics
- 2.7 Album/Compilation (“Various Artistsâ€) Identifier
-
-
-1 Front Matter
-
-1.1 License
-
-You may use this specification under either of the following
-licenses, at your discretion. Most will want to use it under
-Creative Commons; the GPL alternative is in case future versions
-of the spec contain e.g. code snippets that you would like to use
-in GPL programs:
-
-1. This specification is licensed under the Creative Commons
- Attribution-Share Alike 3.0 Unported License. You are free to
- copy, distribute and transmit this work, provided that the
- copyright information and full URL to the license information
- page (http://creativecommons.org/licenses/by-nd/3.0/) remain
- intact. If you alter, transform, or build upon this work, you
- may distribute the resulting work only under the same or
- similar license to this one.
-
-2. This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License as
- published by the Free Software Foundation; either version 2 of
- the License, or (at your option) any later version. This
- program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details. See http://www.gnu.org/licenses/
- .
-
-1.2 Terminology
-
-Terminology follws that specified in RFC2119, “Key words for use
-in RFCs to Indicate Requirement Levelsâ€. See http://www.ietf.org/rfc/rfc2119.txt
- for more information.
-
-2 Audio Metadata Tags
-
-The metadata tag formats evolved from Quod Libet's VorbisComments
-suggestions at http://code.google.com/p/quodlibet/wiki/Specs_VorbisComments
-, however this attempts to not only address ambiguities and
-incompatibilities with the specification at that URL, but also to
-define how this functionality should be applied across formats.
-It is intended that as usable ways of inserting the metadata
-described become available for formats not currently specified,
-that this document will be updated to meet those needs.
-
-All newly-specified tags carry an identifier “FMPS_†to tie the
-tags to this specification. The reason is simple: since the
-official metadata specifications either fail to define or define
-unusable tags, these values are only official to the extent that
-this specification is adopted. Without an identifier to give
-context to the meanings and limitations of the values, there is a
-real possibility that a noncompliant media player will use the
-same tag names in an incompatible fashion, whether intentionally
-or not, and there is no way to determine whether a seemingly
-compatible use of the tags by a noncompliant player actually
-results in user-intended behavior. The “FMPS_†identifier and
-this specification document is therefore used in a similar
-fashion to XML schema declarations.
-
-As these identifiers are read and modified only by players and
-advanced users, it is not expected to be a hindrance to adoption
-or to cause undue burden on either.
-
-2.1 Common Data and Tag Information
-
-This section provides “up-front†information that is pertinent to
-all tags described below, such as what encoding to use and which
-tags to use in various formats.
-
-For all tag formats, the following is defined:
-
-• All identifiers are ASCII strings, and defined in the sections
- below. All identifier strings must escape each colon (':'),
- semicolon (';') and backslash ('\') with a backslash.
-
-• All values (including numeric values) are stored as strings,
- which MUST adhere to the allowed encoding and length limits in
- the relevant tag format specifications, but SHOULD use Unicode
- whenever possible.
-
- – To keep the specification simple, no ranges of control
- characters are defined which should never be included in a
- string. It is assumed that the used string-handling library
- will properly handle any such characters encountered. It is
- highly recommended, however, that no such control characters
- are used, except when specified below.
-
- – All value strings must escape each colon (':'), semicolon
- (';') and backslash ('\') with a backslash.
-
-• Although identifier case is specified for the different types
- of tags, comparisons against identifier strings MUST be
- case-insensitive.
-
-• A period/full stop is used to separate the digits in a float
- value from the fractional part of the float. All float values
- MUST include a period/full stop (1 is not acceptable; 1.0 is
- correct).
-
-• Float values SHOULD be limited to six decimal places.
-
-• All lists are value strings. For any lists, entries MUST be
- separated with a double semicolon ';;' and fields within an
- entry MUST be separated with a double colon '::' (examples in
- following sections). These separation markers MUST NOT be
- escaped with backslashes. This allows for easy splitting of
- list entries and entry fields with most string libraries; the
- entries and fields can be split by double semicolon/double
- colon, and the ensuing fields can have any escaped values
- substituted.
-
-The following sections describe where the information should be
-stored in specific tag formats.
-
-2.1.1 MP3
-
-MP3 values MUST be stored in a TXXX frame with the Description
-set to the specified identifier and the Text set to the string
-representation of the value. The Description SHOULD be in
-CamelCase as specified in the following sections, e.g.
-FMPS_Rating.
-
-2.1.2 VorbisComments
-
-Any file supporting VorbisComments (Vorbis, FLAC, Theora, Speex)
-MUST use a comment with the Key set to the specified identifier
-and the Value set to the string representation of the value. The
-Key SHOULD be in all upper-case, e.g. FMPS_RATING.
-
-2.1.3 APEv2
-
-Any file supporting APEv2 MUST add a comment with the Key set to
-the specified identifier and the Value set to the string
-representation of the value. The Key SHOULD be in all upper-case,
-e.g. FMPS_RATING.
-
-2.1.4 MP4
-
-MP4 values MUST be stored at ----:com.apple.iTunes:Identifier
-with the value a string representation of the tag's value. The
-Identifier SHOULD be in CamelCase as specified in the following
-sections, e.g. FMPS_Rating.
-
-2.1.5 Windows Media
-
-Windows Media values MUST be stored in the FMPS/Identifier
-namespace with the value a string representation of the tag's
-value. The Identifier SHOULD be in CamelCase as specified in the
-following sections, e.g. FMPS_Rating.
-
-2.2 Rating Tags
-
-Most media players support the notion of rating content, however
-standards for storing ratings in files do not exist. Some file
-metadata formats completely lack rating fields; others require
-personally identifiable information to be used as an identifier
-(such as a user's email address) or an organizational identifier
-(which reduces cross-player compatibility). The goal therefore is
-simple: to avoid any personally identifying information but to
-avoid tying the rating to a specific player.
-
-Three types of ratings are currently defined: user ratings,
-critic ratings, and automatic (or algorithmic) ratings.
-
-Although users are more naturally able to understand integer
-ratings, only advanced users will interact with these tags
-directly; otherwise they will be presented to the user via a
-conforming application. Meanwhile, there are tangible benefits to
-storing ratings as floating-point numbers, mainly due to the fact
-that the increased precision allows for a number of interesting
-and useful algorithmic rating schemes to be used. However, using
-both integer and floating-point values unnecessarily increases
-complexity of both this spec and application code. Therefore,
-both values are stored as floating-point numbers. Conversion to
-and from these and an integer scale presented to the user in an
-application is easily accomplished in the application's code if
-it is so desired.
-
-Four tags are defined, corresponding to the three types of
-defined ratings, plus a canonical value: FMPS_Rating_User;
-FMPS_Rating_Critic; FMPS_Rating_Algorithm; and FMPS_Rating (the
-canonical value). A file that has no rating tag for a specific
-purpose is to be considered unrated for that purpose (user,
-critic or algorithm).
-
-2.2.1 All Rating Tags
-
-• Ratings SHALL be a float value between 0.0 and 1.0, inclusive.
- 0.0 SHALL be the lowest possible rating; 1.0 is the highest
- possible rating.
-
-• Ratings SHOULD only be rounded when necessary, in order to
- increase cross-player compatibility.
-
-2.2.2 FMPS_Rating
-
-• The canonical rating value in FMPS_Rating SHOULD be set
- whenever a user rates the track. This is in addition to any
- value stored for that particular user in FMPS_Rating_User. This
- value is canonical because if a player does not support
- multiple users (or if no user identifier is set), this is the
- value that MUST be returned.
-
-• If a user removes ratings from a track in the media player's
- database, the value of the FMPS_Rating tag SHOULD be cleared as
- well.
-
-2.2.3 FMPS_Rating_User
-
-• If a player supports the notion of multiple users (perhaps from
- discovery of the current user from the operating system) and
- wishes to allow the users to keep separate ratings, it MUST
- store these values in the FMPS_Rating_User tag.
-
-• Applications supporting multiple user ratings SHOULD have a way
- for users to define their preferred identifier.
-
-• The values are in the form of a list as defined in Section 2.1,
- with list entries in the format of UserIdentifier::Value. There
- MUST NOT be empty value strings.
-
-Example: “Alice Abba::0.6;;Bob Beatles::0.8â€.
-
-2.3 FMPS_Rating_Critic
-
-• The values MUST be in the form of a list as defined in Section
- 2.1, with list entries in the format of
- Publication::Critic::Rating. If the critic is unaffiliated, or
- if the rating is by a publication with no byline, the special
- value “FMPS_Nothing†MUST be used to denote this; there MUST
- NOT be empty strings.
-
-Example: “Rolling Stone::Ralph
-Gleason::0.83;;musicOMH.com::FMPS_Nothing::0.76;;Metacritic::FMPS_Nothing::0.8;;FMPS_Nothing::Some
-Dude::0.9â€
-
-2.3.1 FMPS_Rating_Algorithm
-
-• The values MUST be in the form of a list as defined in Section
- 2.1, with list entries in the format of
- Application::Algorithm::Rating. All fields MUST be defined;
- fields MUST NOT be left empty.
-
-• In cases where the algorithm is intended to be
- global/collaborative/cross-application, the Application value
- SHOULD be set to some agreed-upon value. In other words, it is
- RECOMMENDED to use the application name for the Application
- part of the identifier, but it MAY also be used to identify a “
- group†of algorithms, or some arbitrary other value that can be
- used for identification.
-
-Example: “
-Amarok::AutoRate::0.52;;VLC::Standard::0.6;;QuodLibet::RatingPlugin\:X::0.35;;The
-Free Music Player Alliance::Rating Algorithm 1::0.5â€
-
-A note on the floating point values: some players may only allow
-users to rate in increments of whole numbers between 1 and 5;
-others 0 and 10; and so on. However, players SHOULD ensure that
-the rating they display and use for any purpose adheres to that
-saved in the tag whenever possible, only rounding this number
-when absolutely necessary.
-
-For instance, if a track has a rating of 0.9 and an application
-only shows ratings using five star icons in full-star increments,
-this would be rounded within the application to five stars.
-Howeer, if the player also shows the rating numerically, the
-application would display 4.5 in the numeric field instead of the
-same 5 shown in the star icons, thus more accurately reflecting
-the user's set rating.
-
-2.4 Playcount Tags
-
-As with ratings, there are multiple kinds of playcount tags (user
-and algorithmic) in addition to a canonical value. The user tag
-tracks how many times a song has been played for a user. The
-auto/algorithmic value can be used in an application-specific way
-to do interesting things; for instance, to cumulatively track
-exact percentages of tracks played, in order to display to the
-user the number of days/hous/minutes/seconds they have spent
-listening to a particular song.
-
-Three tags are defined, corresponding to the two types of defined
-playcounts, plus a canonical value: FMPS_Playcount_User;
-FMPS_Playcount_Algorithm; and FMPS_Playcount (the canonical
-value). A file that has no playcount tag for a specific purpose
-is to be considered unplayed for that purpose (user or
-algorithm).
-
-2.4.1 All Playcount Tags
-
-• Playcounts MUST be a float value not less than 0.0. 0.0 is
- valid and means unplayed.
-
-• The maximum value SHALL be 0.000001 less than the largest value
- able to be stored in a 32-bit unsigned integer:
- 4,294,967,294.999999. This is so that playcount values can be
- rounded to an integer equivalent, if necessary (e.g. for
- display to the user).
-
-2.4.2 User Playcount Criteria
-
-The user playcount isn't meant to be set by the user, but rather
-to follow these rules that define user behavior. A file is to be
-considered “played†if it meets the following criteria, inspired
-by Last.fm's scrobbling rules:
-
-• If the track is less than thirty seconds long, the entire song
- MUST be played.
-
-• If the track is more than thirty seconds long but less than
- eight minutes long, at least fifty percent of the file MUST be
- played, calculated via length of track. For instance, if a
- track is one minute long, at least thirty seconds of the track
- must have been played, although if the user skips backwards
- multiple times and listens to the same ten seconds of the track
- three times in a row, this may be considered a valid playcount.
-
-• If the track is longer than eight minutes, at least four
- minutes of the track MUST be played.
-
-User playcounts have an additional restriction in that they MUST
-be float values representing integers (1.0, 141.0, etc.). They
-are never fractional values; a song was either played, or it
-wasn't.
-
-2.4.3 FMPS_Playcount
-
-• The canonical playcount value in FMPS_Playcount SHOULD be set
- whenever a user plays a track. This is in addition to any value
- stored for that user in FMPS_Playcount_User. This value is
- canonical because if a player does not support multiple users
- (or if no user identifier is set) this is the value that MUST
- be returned.
-
-• If a user has an identifier set to store per-user playcounts,
- when this value is set it MUST be set to the value of that
- user's playcount. In other words, the last value held in
- FMPS_Playcount will be equivalent to the latest user's personal
- playcount, if any.
-
-• If a user resets the playcount for a track in the media
- player's database, the value of the FMPS_Playcount tag SHOULD
- be cleared as well.
-
-• FMPS_Playcount MUST store “full plays†of a track according to
- the rules in Section 2.4.2.
-
-2.4.4 FMPS_Playcount_User
-
-• If a player supports the notion of multiple users (perhaps from
- discovery of the current user from the operating system) and
- wishes to allow the users to keep separate playcounts, it MUST
- store these values in the FMPS_Playcount_User tag.
-
-• Applications supporting multiple user playcounts SHOULD have a
- way for users to define their preferred identifier.
-
-• The values MUST be in the form of a list as defined in Section
- 2.1, with list entries in the format of UserIdentifier::Value.
- There MUST NOT be empty strings.
-
-• FMPS_Playcount_User MUST store “full plays†of a track
- according to the rules in Section 2.4.2.
-
-Example: “Alice Abba::1.0;;Bob Beatles::133.0â€.
-
-2.4.5 FMPS_Playcount_Algorithm
-
-• The values MUST be in the form of a list as defined in Section
- 2.3.1, with list entries in the format of
- Application::Algorithm::Playcount. All fields MUST be defined;
- fields MUST NOT be left empty.
-
-• In cases where the algorithm is intended to be
- global/collaborative/cross-application, the Application value
- SHOULD be set to some agreed-upon value. In other words, it is
- RECOMMENDED to use the application name for the Application
- part of the identifier, but it MAY also be used to identify a “
- group†of algorithms, or some arbitrary other value that can be
- used for identification.
-
-• For algorithms, a track's length MUST be considered to be worth
- 1.0 playcounts; the user skipping parts of the track MAY
- decrease the value below 1.0, and the user repeating parts of
- the track MAY increase this value past 1.0.
-
-Example: “
-Amarok::AutoPlaycount::152.69;;VLC::Standard::198.0;;QuodLibet::PlaycountPlugin\:X::1652.19;;The
-Music Player Alliance::Playcount Algorithm 1::0.5â€
-
-2.5 Performer Roles
-
-Performer roles allow you to describe the performers in a track.
-Current support for these roles in tag formats is often sporadic
-or difficult to parse. As many of these tags as desired can be
-specified, to include all relevant performer information.
-
-• Performer roles use the identifier “FMPS_Performersâ€. The value
- MUST be a list in the form of Performer::Role, where Role is
- the user-defined role (“Guitarâ€, “Guitar (Backup)â€, “Vocalsâ€).
-
-Example: “Willy Nelson::Guitar;;Eric Clapton::Guitar
-(Backup);;B.B. King::Vocalsâ€
-
-2.6 Lyrics
-
-Embedding lyrics into a file allows users to save custom lyrics
-and to still see the lyrics when not connected to the Internet.
-Since different users may wish to have different sets of lyrics
-(for example, if customizing lyrics against a music-only track)
-and different Internet sources may have different lyrics, it is
-possible to store multiple lyrics values by specifying a source.
-
-• The identifier for the (canonical) lyrics text is “FMPS_Lyricsâ€
- . The value MUST be a string. Spaces, tabs, and newlines SHOULD
- be preserved when saving the string, and SHOULD be displayed
- properly to the user.
-
-• Lyrics MAY also be stored in FMPS_Lyrics_Sources as a list (as
- defined in Section 2.1), in which case the form MUST be
- Source::Data.
-
-Example: “Alice Aardvark::[lyrics];;Bob
-Baboon::[lyrics];;http\://www.lyricssite.net::[lyrics]â€
-
-2.7 Album/Compilation (“Various Artistsâ€) Identifier
-
-Compilations (or “Various Artists†albums) can be difficult for
-music players to discover. Sometimes the user places all files
-from a compilation in one directory and expects that the music
-player will understand this; sometimes the user has them in
-different directories but with the same album name and expects
-that the music player will understand this; and so on.
-
-Although there are existing solutions to identify albums and
-songs that belong to the same album (such as MusicBrainz
-identifiers) many users have not or do not want to tag their
-songs with MusicBrainz information. This tag therefore provides a
-simple way for an application to assign a album identifier to a
-track, indicating to what album a track belongs. It also provides
-a simple way of marking the album as a compilation or not.
-
-This enables such use-cases as allowing a user to mark multiple
-tracks that are part of a single compilation, and then have those
-tracks show up as being together in a compilation the next time
-the user adds the tracks to the music player.
-
-This section purposefully does not define information about the
-album/compilation; it is expected that the user must supply that
-information in appropriate existing tags, e.g. ALBUM and
-ALBUMARTIST for VorbisComments.
-
-• The identifier for the album/compilation tag is
- FMPS_Albums_Compilations. Although this tag will be most useful
- for compilation/Various Artists albums, there may still be
- significant utility for a player in using this tag to identify
- single-artist albums. As a result, players MUST NOT make
- assumptions about whether the presence of this tag identifies
- the track as belonging to a compilation/Various Artists album
- and MUST explicitly derive this information from the tag value.
-
-• Values MUST be a list (as defined in Section 2.1) in the form
- of Application::Type::Identifier. Applications MAY have more
- than one identifier, if the user wants to mark a track as being
- present in multiple compilations, or to give user-defined names
- to a compilation. However, each list entry MUST be unique.
- Similarly to other tags in this specification, there may be
- significant utility in interoperating on the application names.
-
-• Type MUST be one of the following values, without quotes: “
- Album†(indicating a general-purpose album, usually by a single
- artist) or “Compilation†(indicating a compilation album,
- usually by multiple/various artists). Checks against this value
- MUST be case-insensitive. More values may be added in the
- future; if a player encounters an unknown value it SHOULD
- default to type “Albumâ€.
-
-Example: “Amarok::Album::2982ab29ef;;AmarokUser::Compilation::My
-Compilation;;Banshee::Compilation::ad8slpbzl229zier;;FMPSAlliance::Album::de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3â€
+Free Media Player Specifications
+
+Tag Specification
+
+version 1.1; October 16, 2010
+
+Copyright 2009-2010 by Jeff Mitchell [mitchell@kde.org]
+
+Abstract
+
+This specification describes various audio file tag metadata
+intended to increase interoperability between free music players
+for things such as ratings, playcounts, performer roles, and
+more. It does this by proposing standards for common
+functionality needs where none currently exist, and doing so in a
+way that is easily adoptable cross-player and cross-format. It is
+designed to be robust against future needs and to prevent
+possible conflicts with other tag identifiers and values.
+
+Table of Contents
+
+ 1 Front Matter
+ 1.1 License
+ 1.2 Terminology
+ 2 Audio Metadata Tags
+ 2.1 Common Data and Tag Information
+ 2.1.1 MP3
+ 2.1.2 VorbisComments
+ 2.1.3 APEv2
+ 2.1.4 MP4
+ 2.1.5 Windows Media
+ 2.2 Rating Tags
+ 2.2.1 All Rating Tags
+ 2.2.2 FMPS_Rating
+ 2.2.3 FMPS_Rating_User
+ 2.3 FMPS_Rating_Critic
+ 2.3.1 FMPS_Rating_Algorithm
+ 2.4 Playcount Tags
+ 2.4.1 All Playcount Tags
+ 2.4.2 User Playcount Criteria
+ 2.4.3 FMPS_Playcount
+ 2.4.4 FMPS_Playcount_User
+ 2.4.5 FMPS_Playcount_Algorithm
+ 2.5 Performer Roles
+ 2.6 Lyrics
+ 2.7 Album/Compilation (“Various Artistsâ€) Identifier
+
+
+1 Front Matter
+
+1.1 License
+
+You may use this specification under either of the following
+licenses, at your discretion. Most will want to use it under
+Creative Commons; the GPL alternative is in case future versions
+of the spec contain e.g. code snippets that you would like to use
+in GPL programs:
+
+1. This specification is licensed under the Creative Commons
+ Attribution-Share Alike 3.0 Unported License. You are free to
+ copy, distribute and transmit this work, provided that the
+ copyright information and full URL to the license information
+ page (http://creativecommons.org/licenses/by-nd/3.0/) remain
+ intact. If you alter, transform, or build upon this work, you
+ may distribute the resulting work only under the same or
+ similar license to this one.
+
+2. This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2 of
+ the License, or (at your option) any later version. This
+ program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details. See http://www.gnu.org/licenses/
+ .
+
+1.2 Terminology
+
+Terminology follws that specified in RFC2119, “Key words for use
+in RFCs to Indicate Requirement Levelsâ€. See http://www.ietf.org/rfc/rfc2119.txt
+ for more information.
+
+2 Audio Metadata Tags
+
+The metadata tag formats evolved from Quod Libet's VorbisComments
+suggestions at http://code.google.com/p/quodlibet/wiki/Specs_VorbisComments
+, however this attempts to not only address ambiguities and
+incompatibilities with the specification at that URL, but also to
+define how this functionality should be applied across formats.
+It is intended that as usable ways of inserting the metadata
+described become available for formats not currently specified,
+that this document will be updated to meet those needs.
+
+All newly-specified tags carry an identifier “FMPS_†to tie the
+tags to this specification. The reason is simple: since the
+official metadata specifications either fail to define or define
+unusable tags, these values are only official to the extent that
+this specification is adopted. Without an identifier to give
+context to the meanings and limitations of the values, there is a
+real possibility that a noncompliant media player will use the
+same tag names in an incompatible fashion, whether intentionally
+or not, and there is no way to determine whether a seemingly
+compatible use of the tags by a noncompliant player actually
+results in user-intended behavior. The “FMPS_†identifier and
+this specification document is therefore used in a similar
+fashion to XML schema declarations.
+
+As these identifiers are read and modified only by players and
+advanced users, it is not expected to be a hindrance to adoption
+or to cause undue burden on either.
+
+2.1 Common Data and Tag Information
+
+This section provides “up-front†information that is pertinent to
+all tags described below, such as what encoding to use and which
+tags to use in various formats.
+
+For all tag formats, the following is defined:
+
+• All identifiers are ASCII strings, and defined in the sections
+ below. All identifier strings must escape each colon (':'),
+ semicolon (';') and backslash ('\') with a backslash.
+
+• All values (including numeric values) are stored as strings,
+ which MUST adhere to the allowed encoding and length limits in
+ the relevant tag format specifications, but SHOULD use Unicode
+ whenever possible.
+
+ – To keep the specification simple, no ranges of control
+ characters are defined which should never be included in a
+ string. It is assumed that the used string-handling library
+ will properly handle any such characters encountered. It is
+ highly recommended, however, that no such control characters
+ are used, except when specified below.
+
+ – All value strings must escape each colon (':'), semicolon
+ (';') and backslash ('\') with a backslash.
+
+• Although identifier case is specified for the different types
+ of tags, comparisons against identifier strings MUST be
+ case-insensitive.
+
+• A period/full stop is used to separate the digits in a float
+ value from the fractional part of the float. All float values
+ MUST include a period/full stop (1 is not acceptable; 1.0 is
+ correct).
+
+• Float values SHOULD be limited to six decimal places.
+
+• All lists are value strings. For any lists, entries MUST be
+ separated with a double semicolon ';;' and fields within an
+ entry MUST be separated with a double colon '::' (examples in
+ following sections). These separation markers MUST NOT be
+ escaped with backslashes. This allows for easy splitting of
+ list entries and entry fields with most string libraries; the
+ entries and fields can be split by double semicolon/double
+ colon, and the ensuing fields can have any escaped values
+ substituted.
+
+The following sections describe where the information should be
+stored in specific tag formats.
+
+2.1.1 MP3
+
+MP3 values MUST be stored in a TXXX frame with the Description
+set to the specified identifier and the Text set to the string
+representation of the value. The Description SHOULD be in
+CamelCase as specified in the following sections, e.g.
+FMPS_Rating.
+
+2.1.2 VorbisComments
+
+Any file supporting VorbisComments (Vorbis, FLAC, Theora, Speex)
+MUST use a comment with the Key set to the specified identifier
+and the Value set to the string representation of the value. The
+Key SHOULD be in all upper-case, e.g. FMPS_RATING.
+
+2.1.3 APEv2
+
+Any file supporting APEv2 MUST add a comment with the Key set to
+the specified identifier and the Value set to the string
+representation of the value. The Key SHOULD be in all upper-case,
+e.g. FMPS_RATING.
+
+2.1.4 MP4
+
+MP4 values MUST be stored at ----:com.apple.iTunes:Identifier
+with the value a string representation of the tag's value. The
+Identifier SHOULD be in CamelCase as specified in the following
+sections, e.g. FMPS_Rating.
+
+2.1.5 Windows Media
+
+Windows Media values MUST be stored in the FMPS/Identifier
+namespace with the value a string representation of the tag's
+value. The Identifier SHOULD be in CamelCase as specified in the
+following sections, e.g. FMPS_Rating.
+
+2.2 Rating Tags
+
+Most media players support the notion of rating content, however
+standards for storing ratings in files do not exist. Some file
+metadata formats completely lack rating fields; others require
+personally identifiable information to be used as an identifier
+(such as a user's email address) or an organizational identifier
+(which reduces cross-player compatibility). The goal therefore is
+simple: to avoid any personally identifying information but to
+avoid tying the rating to a specific player.
+
+Three types of ratings are currently defined: user ratings,
+critic ratings, and automatic (or algorithmic) ratings.
+
+Although users are more naturally able to understand integer
+ratings, only advanced users will interact with these tags
+directly; otherwise they will be presented to the user via a
+conforming application. Meanwhile, there are tangible benefits to
+storing ratings as floating-point numbers, mainly due to the fact
+that the increased precision allows for a number of interesting
+and useful algorithmic rating schemes to be used. However, using
+both integer and floating-point values unnecessarily increases
+complexity of both this spec and application code. Therefore,
+both values are stored as floating-point numbers. Conversion to
+and from these and an integer scale presented to the user in an
+application is easily accomplished in the application's code if
+it is so desired.
+
+Four tags are defined, corresponding to the three types of
+defined ratings, plus a canonical value: FMPS_Rating_User;
+FMPS_Rating_Critic; FMPS_Rating_Algorithm; and FMPS_Rating (the
+canonical value). A file that has no rating tag for a specific
+purpose is to be considered unrated for that purpose (user,
+critic or algorithm).
+
+2.2.1 All Rating Tags
+
+• Ratings SHALL be a float value between 0.0 and 1.0, inclusive.
+ 0.0 SHALL be the lowest possible rating; 1.0 is the highest
+ possible rating.
+
+• Ratings SHOULD only be rounded when necessary, in order to
+ increase cross-player compatibility.
+
+2.2.2 FMPS_Rating
+
+• The canonical rating value in FMPS_Rating SHOULD be set
+ whenever a user rates the track. This is in addition to any
+ value stored for that particular user in FMPS_Rating_User. This
+ value is canonical because if a player does not support
+ multiple users (or if no user identifier is set), this is the
+ value that MUST be returned.
+
+• If a user removes ratings from a track in the media player's
+ database, the value of the FMPS_Rating tag SHOULD be cleared as
+ well.
+
+2.2.3 FMPS_Rating_User
+
+• If a player supports the notion of multiple users (perhaps from
+ discovery of the current user from the operating system) and
+ wishes to allow the users to keep separate ratings, it MUST
+ store these values in the FMPS_Rating_User tag.
+
+• Applications supporting multiple user ratings SHOULD have a way
+ for users to define their preferred identifier.
+
+• The values are in the form of a list as defined in Section 2.1,
+ with list entries in the format of UserIdentifier::Value. There
+ MUST NOT be empty value strings.
+
+Example: “Alice Abba::0.6;;Bob Beatles::0.8â€.
+
+2.3 FMPS_Rating_Critic
+
+• The values MUST be in the form of a list as defined in Section
+ 2.1, with list entries in the format of
+ Publication::Critic::Rating. If the critic is unaffiliated, or
+ if the rating is by a publication with no byline, the special
+ value “FMPS_Nothing†MUST be used to denote this; there MUST
+ NOT be empty strings.
+
+Example: “Rolling Stone::Ralph
+Gleason::0.83;;musicOMH.com::FMPS_Nothing::0.76;;Metacritic::FMPS_Nothing::0.8;;FMPS_Nothing::Some
+Dude::0.9â€
+
+2.3.1 FMPS_Rating_Algorithm
+
+• The values MUST be in the form of a list as defined in Section
+ 2.1, with list entries in the format of
+ Application::Algorithm::Rating. All fields MUST be defined;
+ fields MUST NOT be left empty.
+
+• In cases where the algorithm is intended to be
+ global/collaborative/cross-application, the Application value
+ SHOULD be set to some agreed-upon value. In other words, it is
+ RECOMMENDED to use the application name for the Application
+ part of the identifier, but it MAY also be used to identify a “
+ group†of algorithms, or some arbitrary other value that can be
+ used for identification.
+
+Example: “
+Amarok::AutoRate::0.52;;VLC::Standard::0.6;;QuodLibet::RatingPlugin\:X::0.35;;The
+Free Music Player Alliance::Rating Algorithm 1::0.5â€
+
+A note on the floating point values: some players may only allow
+users to rate in increments of whole numbers between 1 and 5;
+others 0 and 10; and so on. However, players SHOULD ensure that
+the rating they display and use for any purpose adheres to that
+saved in the tag whenever possible, only rounding this number
+when absolutely necessary.
+
+For instance, if a track has a rating of 0.9 and an application
+only shows ratings using five star icons in full-star increments,
+this would be rounded within the application to five stars.
+Howeer, if the player also shows the rating numerically, the
+application would display 4.5 in the numeric field instead of the
+same 5 shown in the star icons, thus more accurately reflecting
+the user's set rating.
+
+2.4 Playcount Tags
+
+As with ratings, there are multiple kinds of playcount tags (user
+and algorithmic) in addition to a canonical value. The user tag
+tracks how many times a song has been played for a user. The
+auto/algorithmic value can be used in an application-specific way
+to do interesting things; for instance, to cumulatively track
+exact percentages of tracks played, in order to display to the
+user the number of days/hous/minutes/seconds they have spent
+listening to a particular song.
+
+Three tags are defined, corresponding to the two types of defined
+playcounts, plus a canonical value: FMPS_Playcount_User;
+FMPS_Playcount_Algorithm; and FMPS_Playcount (the canonical
+value). A file that has no playcount tag for a specific purpose
+is to be considered unplayed for that purpose (user or
+algorithm).
+
+2.4.1 All Playcount Tags
+
+• Playcounts MUST be a float value not less than 0.0. 0.0 is
+ valid and means unplayed.
+
+• The maximum value SHALL be 0.000001 less than the largest value
+ able to be stored in a 32-bit unsigned integer:
+ 4,294,967,294.999999. This is so that playcount values can be
+ rounded to an integer equivalent, if necessary (e.g. for
+ display to the user).
+
+2.4.2 User Playcount Criteria
+
+The user playcount isn't meant to be set by the user, but rather
+to follow these rules that define user behavior. A file is to be
+considered “played†if it meets the following criteria, inspired
+by Last.fm's scrobbling rules:
+
+• If the track is less than thirty seconds long, the entire song
+ MUST be played.
+
+• If the track is more than thirty seconds long but less than
+ eight minutes long, at least fifty percent of the file MUST be
+ played, calculated via length of track. For instance, if a
+ track is one minute long, at least thirty seconds of the track
+ must have been played, although if the user skips backwards
+ multiple times and listens to the same ten seconds of the track
+ three times in a row, this may be considered a valid playcount.
+
+• If the track is longer than eight minutes, at least four
+ minutes of the track MUST be played.
+
+User playcounts have an additional restriction in that they MUST
+be float values representing integers (1.0, 141.0, etc.). They
+are never fractional values; a song was either played, or it
+wasn't.
+
+2.4.3 FMPS_Playcount
+
+• The canonical playcount value in FMPS_Playcount SHOULD be set
+ whenever a user plays a track. This is in addition to any value
+ stored for that user in FMPS_Playcount_User. This value is
+ canonical because if a player does not support multiple users
+ (or if no user identifier is set) this is the value that MUST
+ be returned.
+
+• If a user has an identifier set to store per-user playcounts,
+ when this value is set it MUST be set to the value of that
+ user's playcount. In other words, the last value held in
+ FMPS_Playcount will be equivalent to the latest user's personal
+ playcount, if any.
+
+• If a user resets the playcount for a track in the media
+ player's database, the value of the FMPS_Playcount tag SHOULD
+ be cleared as well.
+
+• FMPS_Playcount MUST store “full plays†of a track according to
+ the rules in Section 2.4.2.
+
+2.4.4 FMPS_Playcount_User
+
+• If a player supports the notion of multiple users (perhaps from
+ discovery of the current user from the operating system) and
+ wishes to allow the users to keep separate playcounts, it MUST
+ store these values in the FMPS_Playcount_User tag.
+
+• Applications supporting multiple user playcounts SHOULD have a
+ way for users to define their preferred identifier.
+
+• The values MUST be in the form of a list as defined in Section
+ 2.1, with list entries in the format of UserIdentifier::Value.
+ There MUST NOT be empty strings.
+
+• FMPS_Playcount_User MUST store “full plays†of a track
+ according to the rules in Section 2.4.2.
+
+Example: “Alice Abba::1.0;;Bob Beatles::133.0â€.
+
+2.4.5 FMPS_Playcount_Algorithm
+
+• The values MUST be in the form of a list as defined in Section
+ 2.3.1, with list entries in the format of
+ Application::Algorithm::Playcount. All fields MUST be defined;
+ fields MUST NOT be left empty.
+
+• In cases where the algorithm is intended to be
+ global/collaborative/cross-application, the Application value
+ SHOULD be set to some agreed-upon value. In other words, it is
+ RECOMMENDED to use the application name for the Application
+ part of the identifier, but it MAY also be used to identify a “
+ group†of algorithms, or some arbitrary other value that can be
+ used for identification.
+
+• For algorithms, a track's length MUST be considered to be worth
+ 1.0 playcounts; the user skipping parts of the track MAY
+ decrease the value below 1.0, and the user repeating parts of
+ the track MAY increase this value past 1.0.
+
+Example: “
+Amarok::AutoPlaycount::152.69;;VLC::Standard::198.0;;QuodLibet::PlaycountPlugin\:X::1652.19;;The
+Music Player Alliance::Playcount Algorithm 1::0.5â€
+
+2.5 Performer Roles
+
+Performer roles allow you to describe the performers in a track.
+Current support for these roles in tag formats is often sporadic
+or difficult to parse. As many of these tags as desired can be
+specified, to include all relevant performer information.
+
+• Performer roles use the identifier “FMPS_Performersâ€. The value
+ MUST be a list in the form of Performer::Role, where Role is
+ the user-defined role (“Guitarâ€, “Guitar (Backup)â€, “Vocalsâ€).
+
+Example: “Willy Nelson::Guitar;;Eric Clapton::Guitar
+(Backup);;B.B. King::Vocalsâ€
+
+2.6 Lyrics
+
+Embedding lyrics into a file allows users to save custom lyrics
+and to still see the lyrics when not connected to the Internet.
+Since different users may wish to have different sets of lyrics
+(for example, if customizing lyrics against a music-only track)
+and different Internet sources may have different lyrics, it is
+possible to store multiple lyrics values by specifying a source.
+
+• The identifier for the (canonical) lyrics text is “FMPS_Lyricsâ€
+ . The value MUST be a string. Spaces, tabs, and newlines SHOULD
+ be preserved when saving the string, and SHOULD be displayed
+ properly to the user.
+
+• Lyrics MAY also be stored in FMPS_Lyrics_Sources as a list (as
+ defined in Section 2.1), in which case the form MUST be
+ Source::Data.
+
+Example: “Alice Aardvark::[lyrics];;Bob
+Baboon::[lyrics];;http\://www.lyricssite.net::[lyrics]â€
+
+2.7 Album/Compilation (“Various Artistsâ€) Identifier
+
+Compilations (or “Various Artists†albums) can be difficult for
+music players to discover. Sometimes the user places all files
+from a compilation in one directory and expects that the music
+player will understand this; sometimes the user has them in
+different directories but with the same album name and expects
+that the music player will understand this; and so on.
+
+Although there are existing solutions to identify albums and
+songs that belong to the same album (such as MusicBrainz
+identifiers) many users have not or do not want to tag their
+songs with MusicBrainz information. This tag therefore provides a
+simple way for an application to assign a album identifier to a
+track, indicating to what album a track belongs. It also provides
+a simple way of marking the album as a compilation or not.
+
+This enables such use-cases as allowing a user to mark multiple
+tracks that are part of a single compilation, and then have those
+tracks show up as being together in a compilation the next time
+the user adds the tracks to the music player.
+
+This section purposefully does not define information about the
+album/compilation; it is expected that the user must supply that
+information in appropriate existing tags, e.g. ALBUM and
+ALBUMARTIST for VorbisComments.
+
+• The identifier for the album/compilation tag is
+ FMPS_Albums_Compilations. Although this tag will be most useful
+ for compilation/Various Artists albums, there may still be
+ significant utility for a player in using this tag to identify
+ single-artist albums. As a result, players MUST NOT make
+ assumptions about whether the presence of this tag identifies
+ the track as belonging to a compilation/Various Artists album
+ and MUST explicitly derive this information from the tag value.
+
+• Values MUST be a list (as defined in Section 2.1) in the form
+ of Application::Type::Identifier. Applications MAY have more
+ than one identifier, if the user wants to mark a track as being
+ present in multiple compilations, or to give user-defined names
+ to a compilation. However, each list entry MUST be unique.
+ Similarly to other tags in this specification, there may be
+ significant utility in interoperating on the application names.
+
+• Type MUST be one of the following values, without quotes: “
+ Album†(indicating a general-purpose album, usually by a single
+ artist) or “Compilation†(indicating a compilation album,
+ usually by multiple/various artists). Checks against this value
+ MUST be case-insensitive. More values may be added in the
+ future; if a player encounters an unknown value it SHOULD
+ default to type “Albumâ€.
+
+Example: “Amarok::Album::2982ab29ef;;AmarokUser::Compilation::My
+Compilation;;Banshee::Compilation::ad8slpbzl229zier;;FMPSAlliance::Album::de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3â€
diff --git a/05_社区贡献/开发指南/openKylin+SDK开发指南V2.3.md b/04_社区贡献/开发指南/openKylin+SDK开发指南V2.3.md
similarity index 100%
rename from 05_社区贡献/开发指南/openKylin+SDK开发指南V2.3.md
rename to 04_社区贡献/开发指南/openKylin+SDK开发指南V2.3.md
diff --git a/05_社区贡献/开发指南/openKylin打包指南.md b/04_社区贡献/开发指南/openKylin打包指南.md
similarity index 100%
rename from 05_社区贡献/开发指南/openKylin打包指南.md
rename to 04_社区贡献/开发指南/openKylin打包指南.md
diff --git a/05_社区贡献/开发指南/openKylin源码包git工作流.md b/04_社区贡献/开发指南/openKylin源码包git工作流.md
similarity index 97%
rename from 05_社区贡献/开发指南/openKylin源码包git工作流.md
rename to 04_社区贡献/开发指南/openKylin源码包git工作流.md
index 3aa90c17..a13a4880 100644
--- a/05_社区贡献/开发指南/openKylin源码包git工作流.md
+++ b/04_社区贡献/开发指南/openKylin源码包git工作流.md
@@ -1,799 +1,799 @@
-# openKylin源码包git工作流
-
-
-
-# 1. git分支设置
-
-| 分支 | 说明 | 举例 |
-| --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
-| 上游分支 | 不包含debian目录的分支,保存软件包的上游源码。 修改包只需要一个上游分支,统一命名为upstream。 对于自研包,可能会多版本并行开发,所以可能会有多个上游分支,为了避免与打包分支混淆,上游分支名称里不能使用“/” | upstream master 1.0 2.0 |
-| 开发分支 | 用于包维护者提交修改的分支,包含debian目录。 相对于上游分支修改的内容可以直接提交到这个分支。开发分支中源码包格式为native | 名称格式为:发行版代号/系列代号 openKylin 1.0版本开发分支命名为:openkylin/yangtze |
-| 打包分支 | 修改包要求使用quilt格式进行打包,这个分支下,包维护者相对上游分支做的修改都以patch形式保存在debian/patches目录中,便于更新上游版本时进行取舍。仅能用于当前发行版的包可以使用native格式打包,此时不需创建打包分支。 CI平台自动完成开发分支到打包分支的同步。 | openkylin/yangtze对应的打包分支,在分支名前面加上packaging/: packaging/openkylin/yangtze |
-| patch-queue分支 | CI构建环境中使用的临时分支,不会提交到源码管理平台,辅助将开发分支的修改内容生成patch保存到打包分支。 | patch-queue/packaging/openkylin/yangtze |
-
-
-
-# 2. 源码包导入
-
-源码包导入会自动创建上游分支和打包分支,对于quilt格式的源码包,需要将打包分支转化成native格式,便于开发者利用git管理文件修改历史。
-
-
-
-git_init.sh脚本描述了具体操作步骤:
-
-```
-#!/bin/bash
-
-set -e
-
-[ ! -d $1 ] && echo "should specify source path" exit 1;
-
-cd $1
-
-# 切换到打包分支
-git checkout openkylin/yangtze
-git checkout -b packaging/openkylin/yangtze
-
-# 创建临时的集成patch分支,会自动命名为 patch-queue/openkylin/yangtze
-gbp pq import
-
-# fix patches date format
-gbp pq export
-
-git add debian
-git commit -m "format patches" || true
-
-git checkout openkylin/yangtze
-
-# 在打包分支集成patch
-git merge patch-queue/packaging/openkylin/yangtze -m "apply patches"
-
-# 删除临时分支
-git branch -D patch-queue/packaging/openkylin/yangtze
-
-# 删除debian/patches目录
-rm -rf debian/patches
-
-# 修改format格式
-echo "3.0 (native)" > debian/source/format
-
-#提交改动
-git add debian
-git commit -m "changed debian/source/format to native"
-
-```
-
-## 2.1 使用工具导入
-
-可以使用`source-packing`工具进行导入:
-
-主要分三步:
-
-1. 对源码重新打包:
-
-```Bash
-./source-packing rebuild-source --dsc-file sqlite3_3.31.1-4kylin0.3.dsc --new-revisions ok1
-```
-
-此时会生成 `sqlite3_3.31.1-ok1.dsc`新的dsc文件
-
-1. 反向构建出git仓库:
-
-```Bash
-./source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch openkylin/yangtze
-```
-
-1. 关联远端仓库并推送到远端仓库(如果远端仓库没有创建,那么需要先创建远端仓库)
-
-```Bash
-# 进入到第二步构建出的源码仓库
-cd sqlite3
-# 关联远端仓库并推送到远端仓库
-git remote add origin git@gitee.com:openkylin/sqlte3.git
-git push --tags
-git push --all
-```
-
-详细使用方式如下项目文档描述:[源码反向构建工具-source-packing](https://gitee.com/openkylin/packaging-tools#源码反向构建工具-source-packing)
-
-备注:可以使用手动的方式进行源码的导入,具体可以参考2.2,2.3小节(如使用2.1工具反向构建成功,2.2、2.3小节内容可跳过)
-
-## 2.2 导入源码
-
-```Bash
-gbp import-dsc --pristine-tar --debian-branch=openkylin/yangtze --upstream-branch=upstream live-build_3.0~a57-1kylin38.20.04.2.dsc live-build
-```
-
-参数含义
-
-| --pristine-tar | 记录原始orig tar包的数据,避免重新用gbp打包后tar包内容发生变化 |
-| ------------------ | ------------------------------------------------------------ |
-| --debian-branch= | 指定打包分支名称,打包分支命名参考 https://docs.qq.com/doc/DQ2tlZ1BYUHBIVGp4 |
-| --upstream-branch= | 指定上游分支名称,修改包使用upstream,自研包使用master |
-
-除了我们指定的两个分支,gbp import-dsc命令还会自动创建两个tag:
-
-- debian/3.0_a57-1kylin38.20.04.2 打包分支在3.0~a57-1kylin38.20.04.2版本的状态
-- upstream/3.0_a57 本次导入的上游版本3.0~a57的状态,我们打包quilt格式的源码包时需要参考这个tag
-
-### 2.2.1 当存在多个orig包的特殊情况处理
-
-3.0 (quilt)格式的源码包支持多个orig包,有的软件包会将上游源码的主目录和个别子目录分别打包
-
-https://manpages.debian.org/testing/git-buildpackage/gbp-buildpackage.1.en.html#git~6
-
-例如sqlite3,3.31.1-4版本的源码包中有两个orig:sqlite3_3.31.1.orig.tar.xz,sqlite3_3.31.1.orig-www.tar.xz,编译时会先解压sqlite3_3.31.1.orig.tar.xz,然后将sqlite3_3.31.1.orig-www.tar.xz解压到www子目录。
-
-这种情况的包,gbp导入时能够识别,但是执行gbp buildpackage时需要指定--git-component=www才能成功打包。
-
-可以创建debian/gbp.conf,将--git-component选项固定下来
-
-```Prolog
-[buildpackage]
-component=www
-# 如有多个,要写成 component=['ft2docs', 'ft2demos']
-```
-
-不同的包component各不相同,需要分别创建debian/gbp.conf文件
-
-还有个坑,假如orig和orig-component包的压缩方式不一样,一个是xz,一个是gz,gbp buildpackage时会报错:
-
-```Plain%20Text
-gbp:warning: Components specified, pristine-tar-commit not yet supported - disabling it.
-gbp:info: Creating /home/xiewei/git/perl_5.30.0.orig.tar.xz
-gbp:info: Creating /home/xiewei/git/perl_5.30.0.orig-regen-configure.tar.xz
-gbp:error: Error creating perl_5.30.0.orig-regen-configure.tar.xz: Pristine-tar couldn't checkout "perl_5.30.0.orig-regen-configure.tar.xz": fatal: Path 'perl_5.30.0.orig-regen-configure.tar.xz.delta' does not exist in 'refs/heads/pristine-tar'
-pristine-tar: git show refs/heads/pristine-tar:perl_5.30.0.orig-regen-configure.tar.xz.delta failed
-```
-
-修复方法:
-
-1. 统一压缩格式,把perl_5.30.0.orig-regen-configure.tar.gz重新打包成perl_5.30.0.orig-regen-configure.tar.xz
-
-```Apache
-zcat perl_5.30.0.orig-regen-configure.tar.gz | xz -c - > perl_5.30.0.orig-regen-configure.tar.xz
-```
-
-1. 导入pristine-tar信息
-
-```Shell
-gbp pristine-tar commit --component=regen-configure path-to/perl_5.30.0.orig-regen-configure.tar.xz
-```
-
-## 2.3 创建开发分支,集成patch(将源码转换为native格式,便于开发人员本地测试编译)
-
-```Bash
-git checkout openkylin/yangtze # 切换到打包分支
-gbp pq import # 创建临时的集成patch分支,会自动命名为 patch-queue/openkylin/yangtze
-gbp pq export # 自动格式化patch,回到openkylin/yangtze分支
-git add debian
-git commit -m 'format patch'
-git branch packaging/openkylin/yangtze # 创建quilt的分支,用于正式打包
-git merge patch-queue/openkylin/yangtze -m "apply patches" # 在打包分支集成patch
-git branch -D patch-queue/openkylin/yangtze # 删除临时分支
-然后删除debian/patches目录,将debian/source/format修改为“3.0 (native)”
-rm -rf debian/pathes
-echo "3.0 (native)" > debian/source/format
-提交改动
-```
-
-
-
-# 3. 开发维护人员修改软件包(在开发分支如openkylin/yangtze下进行维护)
-
-## 3.1. 产线代码修改
-
-开发维护人员克隆正式版的git库到个人空间,然后直接在打包分支上修改源码文件和debian/changelog。
-
-```Bash
-git checkout openkylin/yangtze
-# 修改源码文件
-vim ...
-# 修改changelog,按软件包版本号规范修改版本号,对于版本号中带‘-’符号的,不能修改'-'前面的部分
-dch -R
-git add .
-git commit
-```
-
-再推送到个人gitee或gitlab仓库,提交PR给maintainer审核。
-
-本地调试时可以直接用debuild进行编译测试。
-
-## 3.2. 在打包分支修改后向上游提交patch
-
-向上游提交改动需要先导出patch
-
-首先执行git log,找到本次修改之前和之后的commit编号
-
-```Bash
-git log
-
-commit 5ba63fabc689b225cd7823a81655e531f54eed46 (HEAD -> openkylin/yangtze)
-Author: Xie Wei
-Date: Mon Apr 18 16:41:59 2022 +0800
-
- edit version and copying
-
-commit 5c066ae094a7788c6507413891dab66db36cd07b
-Author: Xie Wei
-Date: Mon Apr 18 16:40:56 2022 +0800
-
- edit COPYING
-
-commit e5a25c0fba1b1b68e023062878962abbebf1f8ea
-Author: Xie Wei
-Date: Mon Apr 18 16:40:31 2022 +0800
-
- edit version
-
-commit 8c8ad046e88f2692bef8b193b517666d82ca6957
-Author: Xie Wei
-Date: Mon Apr 18 16:35:37 2022 +0800
-
- native
-```
-
-如上所示,假设要把version和copying的改动作为一个完整的patch提交,那么应该对比倒数第1个commit和倒数第4个commit之间的改动。
-
-```Apache
-# 生成patch时忽略debian目录,较早的commit放在前面,较新的commit放在后面
-git diff --binary -r 8c8ad046e88f2692bef8b193b517666d82ca6957 -r 5ba63fabc689b225cd7823a81655e531f54eed46 ':!debian' > /tmp/live-build-change-version-copying.patch
-```
-
-生成patch之后,就要看上游社区接受什么样的提交方式,直接发patch的此文不介绍,假设它支持在gitee或github提交PR,那么我们先在相应的托管平台fork自己的仓库,然后clone到本地,再导入patch
-
-```Apache
-# clone自己在托管平台fork的仓库
-git clone git@gitee.com:xiewei/live-build.git live-build-upstream
-cd live-build-upstream
-# 切换到需要提交的分支,取决于patch针对的版本,以及上游社区的分支规定
-git checkout master
-git apply /tmp/live-build-change-version-copying.patch
-git add .
-# 提交修改说明
-git commit
-# push到自己fork的仓库
-git push
-```
-
-然后就是在托管平台上操作,从自己的仓库提交一个PR到上游社区。
-
-如果上游有更新,提交PR前要先同步上游改动,解决冲突后,再提交PR
-
-```Bash
-# 首先将上游仓库的地址添加到remote,clone下来后只需要做一次,因为我们只需要读取,添加https协议的地址就行了。
-git remote add upstream https://gitee.com/upstream/live-build.git
-# 同步上游更新,最后一个参数是要同步的分支名
-git pull upstream master
-# 如果有冲突,按照提示解决冲突,没有冲突则可以push到自己fork的仓库了
-git push
-```
-
-
-
-# 4. 上传编译平台(CI平台自动实现)
-
-上传编译平台时,需要尽量以quilt格式上传,充分重用orig.tar文件,节省带宽和服务器空间。
-
-将native格式源码包转化成quilt格式的动作会通过CI平台自动完成。
-
-
-
-## 4.1 以quilt格式打包
-
-在打包环境中clone git库,同步开发分支的代码到打包分支进行打包
-
-native转换成quilt,主要差异在于要相对于upstream的代码改动形成补丁,而不是直接在源码文件上修改,我们利用gbp pq来生成补丁。
-
-```Bash
-# 切换到打包分支
-git checkout packaging/openkylin/yangtze
-# 创建临时patch-queue,自动切换到patch-queue/packaging/openkylin/yangtze
-gbp pq import
-# 在patch-queue中提交开发分支最新的改动
-git diff --binary -r openkylin/yangtze -- ':!debian' | git apply -R
-git add . -f
-# 把开发分支最新的commit信息提交到patch-queue分支,用于导出patch
-git log -r openkylin/yangtze -1 --pretty=format:"%s" | git commit -F -
-# 导出patch,自动切换到packaging/openkylin/yangtze
-gbp pq export
-# 同步开发分支对于debian目录的改动,忽略patches和source/format
-git diff --binary -r openkylin/yangtze -- debian ':!debian/patches' ':!debian/source/format' | git apply -R
-
-git add debian
-# 把开发分支最新的commit信息提交到打包分支,不需要人工输入
-git log -r openkylin/yangtze -1 --pretty=format:"%s" | git commit -F -
-# 打包源码,因为gbp默认要在master分支打包,所以要加 --git-ignore-branch 参数,--git-tag参数可以在打包成功后自动创建tag
-gbp buildpackage --git-ignore-branch --git-tag --git-pristine-tar --git-pristine-tar-commit -S -nc
-# packaging/openkylin/yangtze分支需要自动保存到gitee或者gitlab
-git push
-git push --tags
-```
-
-假如native分支涉及二进制文件修改,生成的patch也会有二进制信息,buildpackage时会提示`detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion)`
-
-debian推荐把要替换的二进制文件放在debian目录中,再修改debian/*.install或者debian/rules的install步骤,在编译时覆盖上游的二进制文件。debian中包含二进制文件,无论是图片还是patch,都需要将文件路径添加到debian/source/include-binaries中,或者是直接在debian/source/options里添加一行include-binaries,允许包含任何二进制文件。
-
-https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html
-
-> If you wish to replace upstream provided PNG file **data/hello.png** with maintainer provided one **debian/hello.png**, editing **debian/install** isn’t enough. When you add **debian/hello.png**, you need to add a line "`include-binaries`" to **debian/source/options** since PNG is a binary file. See `dpkg-source`(1).
-
-根据版本号获取upstream标签的方法: (在已有patch基础上进行比较,不再直接对比upstream)
-
-```Python
-from gbp.deb.git import DebianGitRepository
-version = '3.0~a57-1kylin38.20.04.4.4'
-upstream_version = version.split('-')[0]
-# '3.0~a57'
-upstream_tag = DebianGitRepository.version_to_tag('upstream/%(version)s', upstream_version)
-# 'upstream/3.0_a57'
-```
-
-## 4.2 以native格式打包
-
-native格式软件包可以在开发分支直接打包源码,上传编译平台。
-
-```Bash
-# 切换到开发分支
-git checkout openkylin/yangtze
-# 打包源码,因为gbp默认要在master分支打包,所以要加 --git-ignore-branch 参数,--git-tag参数可以在打包成功后自动创建tag
-gbp buildpackage --git-ignore-branch --git-tag -S
-# 打包时创建的tag同步到gitee或gitlab
-git push --tags
-```
-
-
-
-# 5. 更新upstream版本(需要maintainer手动处理)
-
-软件包需要更新上游版本号时,要先导入上游源码,并添加相应的标签。这一步需要由maintainer在正式版的git库中操作。
-
-然后开发者可以将打包分支的代码rebase到新版本。
-
-## 5.1 导入上游新版本的源码(修改包)
-
-当软件包的上游版本更新时,需要新导入orig包
-
-```Bash
-gbp import-orig ../live-build_4.0.orig.tar.gz --no-merge --pristine-tar --upstream-branch=upstream
-git checkout upstream
-git push
-git push --tags
-```
-
-参数含义
-
-| --pristine-tar | 记录原始orig tar包的数据,避免重新用gbp打包后tar包内容发生变化 |
-| ------------------ | ------------------------------------------------------------ |
-| --no-merge | 不将上游版本的代码合并到打包分支,因为我们的开发分支是native格式的,基于upstream修改了源码,一般是没办法自动合并的 |
-| --upstream-branch= | 指定上游分支名称,修改包使用upstream |
-
-在以上的例子中,会新创建一个tag:upstream/4.0
-
-## 5.2 创建新版本的标签(自研包)
-
-maintainer基于upstream分支(或者其他的上游稳定版本分支)创建upstream/<新版本号>的标签,作为新版本打包的上游。
-
-可以在gitlab和gitee上操作。
-
-## 5.3 打包分支rebase到新版本
-
-### 5.3.1 判断旧版本上是否有patch
-
-```Bash
-git checkout packaging/openkylin/yangtze
-wc debian/patches/series
-# 查看patch数量
-```
-
-如果没有patch,按5.3.2、5.3.4操作。
-
-如果有patch,按5.3.3、5.3.4操作。
-
-### 5.3.2 无patch情况下rebase
-
-更新packaging分支
-
-```Bash
-git checkout packaging/openkylin/yangtze
-# 假设原版本号是2:4.11.6-ok1,新的upstream版本号2:4.13.17
-git merge upstream/4.13.17
-```
-
-更新开发分支
-
-```Bash
-git checkout openkylin/yangtze
-# 假设原版本号是2:4.11.6-ok1,新的upstream版本号2:4.13.17
-git merge upstream/4.13.17
-```
-
-在开发分支修改包版本号
-
-```Bash
-# 此时,可以在开发分支对基于上游upstream的代码进行调试,如:
-# 1. 修改代码,直到能编译出二进制包以及能正常安装
-vim xxx
-# 2. 在开发分支下进行debuild进行编译测试
-debuild
-# 3. 提交改动
-git add xxx
-# 4. 修改一下debian/changelog,版本号基于新的upstream version。
-dch -R
-git add debian/changelog
-git commit -m 'merge upstream 4.13.17'
-```
-
-### 5.3.3 有patch情况下rebase
-
-#### 5.3.3.1 获取旧版本patch对应的commit id
-
-```Bash
-# 基于旧版本创建临时分支
-git checkout packaging/openkylin/yangtze
-# 导入patch,形成git commit记录
-# 导入前也可以筛选一下补丁列表,修改debian/patches/series,删除不要的补丁,然后提交即可
-gbp pq import --force
-# 计算补丁数量
-wc debian/patches/series # 14 14 511 debian/patches/series
-# 获取commit id,重定向到文件保存
-git log --max-count=14 > /tmp/patch-list.txt
-```
-
-#### 5.3.3.2 更新packaging分支
-
-```Bash
-git checkout packaging/openkylin/yangtze
-# 假设原版本号是2:4.11.6-ok1,新的upstream版本号2:4.13.17
-git merge upstream/4.13.17
-```
-
-#### 5.3.3.3 筛选需要移植的patch,分别cherry-pick
-
-```Bash
-# 切换到packaging分支
-git checkout packaging/openkylin/yangtze
-# 清空patch列表
-git rm debian/patches/series
-git commit -m 'prepare for new patch list'
-# 创建临时分支,移植低版本patch
-gbp pq import --force
-# 从后往前读取patch-queue commit列表文件 /tmp/patch-list.txt,根据提交信息和补丁文件名确定是否要集成该补丁,对需要集成的补丁执行cherry-pick
-git cherry-pick b2cf5dd7923c50c4b4e1809564a7da63a3e38312 f32df40245f054363698225f44158c2673a06978 2853828b649d5c826bda93c9a11a9720954b915c
-# 导出patch列表
-gbp pq export
-git add debian/patches
-# 然后记得修改一下debian/changelog,版本号基于新的upstream version。
-dch -R
-git add debian/changelog
-git commit -m 'Apply patches on new upstream 4.13.17'
-# patch-queue分支可以删除了
-git branch -D patch-queue/packaging/openkylin/yangtze
-```
-
-假如存在冲突,根据实际需求进行冲突合并(git mergetool; git cherry-pick --continue)或者跳过此patch(git cherry-pick --skip)。
-
-> git cherry-pick基础用法
-
-> 挑选一个commit-id合并
-
-> ```
-> git cherry-pick commit-id
-> ```
-
-- > 注意:合并过来的commit-id将会变掉,产生一个新的commit-id,跟原来的不在相同
-
-> 挑选多个commit-id合并
-
-> ```
-> git cherry-pick commit-idA commit-idB
-> ```
-
-> 挑选连续的多个commit-id合并
-
-> ```
-> git cherry-pick commit-idA..commit-idB
-> ```
-
-- > 该指令是将从commit-idA开始到commit-idB之间的所有commit-id提交记录都合并过来,需要注意的是,commit-idA必须比commit-idB提前提交,也就是说在被挑选的分支上,先有的commit-idA,然后才有的commit-idB
-
-#### 5.3.3.4 反向同步到开发分支
-
-```Bash
-git checkout openkylin/yangtze
-git diff --binary -r patch-queue/packaging/openkylin/yangtze -- ':!debian/source/format' | git apply -R
-git add .
-git commit -m 'merge upstream 4.13.17'
-```
-
-### 5.3.4 提交到git服务器
-
-提交开发分支与packaging打包分支即可,其他临时分支不要提交
-
-```
-!push时,要先push packaging打包分支,再push 开发分支。
-```
-
-```Bash
-git checkout packaging/openkylin/yangtze
-git push
-git checkout openkylin/yangtze
-git push
-```
-
-
-
-# 6. 自研包改为quilt格式
-
-(1)解压源码包。
-
-```Apache
-dpkg-source -x kylin-camera_1.2kord01rc2.22.dsc
-cd kylin-camera-1.2kord01rc2.22
-```
-
-(2)修改changelog,版本号改为{upstream_version}-{revision}形式。
-
-```
-dch -R
-# 在编辑器中,将版本号从1.2kord01rc2.22改为1.2kord01rc2.22-0k1
-```
-
-(3)修改debian/source/format文件,改为3.0 (quilt)
-
-```Bash
-mkdir -p debian/source
-echo "3.0 (quilt)" > debian/source/format
-```
-
-(4)打包orig.tar
-
-```Bash
-debmake -t
-```
-
-(5)生成新的dsc
-
-```Bash
-dpkg-buildpackage -S -nc
-```
-
-(6)导入到git
-
-```Apache
-cd ../
-gbp import-dsc --pristine-tar --debian-branch=openkylin/yangtze --upstream-branch=upstream kylin-camera_1.2kord01rc2.22-0k1.dsc kylin-camera
-```
-
-
-
-# 7. 自研包不改变代码情况下修改上游版本号
-
-例如ukui在某个节点时,要将当前已导入的包统一升级上游版本号,需要按如下流程操作,
-
-(1)切换到开发分支 (例如openkylin/yangtze)。
-
-```Shell
-git checkout openkylin/yangtze
-```
-
-(2)读取debian/changelog,确认当前upstream版本。
-
- 例如changelog中的版本号为3.10.0-0k0
-
-(3)修改changelog版本号,upstream version改成新版本号,假设要设置为3.13.0,那么changelog中的包版本号可以改成3.13.0-0k0。然后提交改动。
-
-(4)添加对应新版本号的upstream标签。
-
-```Shell
-git tag upstream/3.13.0 upstream/3.10.0
-```
-
-(5)openkylin/yangtze分支的改动以及新标签upstream/3.13.0推送到git服务器。
-
-```Shell
-git push
-git push --tags
-```
-
-(6)生成新版本orig.tar包(CI平台完成)。
-
-```Shell
-# 将changelog改动同步到打包分支
-git diff --binary -r openkylin/yangtze debian ':!debian/patches' ':!debian/source/format' | git apply -R
-git add debian
-git log -r openkylin/yangtze -1 --pretty=format:"%s" | git commit -F -
-# 打包,并自动保存orig.tar
-gbp buildpackage --git-ignore-branch --git-tag --git-pristine-tar --git-pristine-tar-commit -S -nc
-# 打包新的upstream版本后,pristine-tar分支会更新,需要上传到git服务器
-git push
-git push origin pristine-tar
-```
-
-
-
-# 8. 使用Kylin修改过的源码覆盖openkylin社区仓库
-
-前提是upstream版本没有改变,为quilt格式,否则需要清空仓库全新导入或者走“更新upstream版本”流程。
-
-(1)在打包分支覆盖debian目录
-
-```Shell
-# 切换到打包分支
-
-# 删除现有debian目录,准备用Kylin的版本覆盖
-# 解压Kylin版本的*.debian.tar文件
-```
-
-(2)修改changelog中的版本号与系列代号
-
-新增一条修改记录,版本号为-ok,N是数字,要比覆盖前openkylin中的版本号大。
-
-(3)覆盖开发分支
-
-
-
-# 9. 从头开始实现自动打包
-
-本节介绍如何在只有upstream等不包含debian配置文件的分支时,如何创建开发分支与打包分支
-
-即从upstream建立openkylin/yangtze和packaging/openkylin/yangtze分支。
-
-## 9.1 首先从gitee上的openkylin clone一份干净的代码
-
-```Bash
-git clone git@gitee.com:openkylin/<包名>
-cd <包名>
-```
-
-## 9.2 在upstream分支上添加upstream标签
-
-我们要选择一个上游版本对应的commit,打上upstream标签。
-
-分别可以用以下几种方式实现,假设上游版本号定为1.2.3
-
-(1)以upstream分支最新版本进行打包
-
-```Bash
-git tag upstream/v1.2.3 upstream
-```
-
-(2)以已存在的tag打包,假设已经有一个tag,名称为v1.2.3
-
-```Bash
-git tag upstream/1.2.3 v1.2.3
-```
-
-(3)以upstream分支某个commit为基点打包
-
-```Bash
-git log upstream # 找到想要使用的commit id
-git tag upstream/1.2.3 031eae9e49ef7b523286410d45ee44ba57e29f79
-```
-
-## 9.3 基于upstream标签创建打包分支,添加debian打包配置文件
-
-```Bash
-git checkout -b packaging/openkylin/yangtze upstream/1.2.3
-# 把准备好的debian打包配置文件复制过来
-cp -r /path-to/debian ./
-# 修改changelog,确保版本号为"1.2.3-"开头,并符合版本号规范
-dch -R
-# 确保源码包为quilt格式
-mkdir -p debian/source
-echo "3.0 (quilt)" > debian/source/format
-# 测试打包,并保存pristine-tar数据
-gbp buildpackage --git-ignore-branch --git-tag --git-pristine-tar --git-pristine-tar-commit -S -nc
-```
-
-## 9.4 创建相应的开发分支,方便开发人员修改代码后本地测试
-
-```Bash
-# 创建临时的集成patch分支,会自动命名为 patch-queue/packaging/openkylin/yangtze
-gbp pq import
-# 重命名为标准的开发分支名称
-git checkout -b openkylin/yangtze
-# 删除临时分支
-git branch -D patch-queue/packaging/openkylin/yangtze
-# 然后删除debian/patches目录,将debian/source/format修改为“3.0 (native)”
-rm -rf debian/pathes
-echo "3.0 (native)" > debian/source/format
-git add debian
-git commit -m 'change format to native'
-```
-
-## 9.5 推送到git服务器
-
-```Bash
-# 因为新建打包分支涉及到3个分支的修改,推送时使用push --all简化操作,这也是为什么一定要clone一份干净的代码来操作
-git push origin --tags
-git push origin --all
-```
-
-## 9.6 创建新版本系列开发分支
-
-当前openkylin 1.0版本已发布,2.0版本的开发分支名称已确定为openkylin/nile,本节介绍如何实现2.0版本代码自动打包。
-
-如果2.0版本不继承1.0版本代码开发,那么可以参考第9节进行,只需要把分支名称中的yangtze改为nile。
-
-如果2.0版本继承1.0版本代码,由包维护者在gitee上按如下流程操作:
-
-1. 访问仓库的分支列表
-
-
-
-2. 点击“新建分支”
-
-
-
-1. 输入分支名,分别新建两个分支:
-
- openkylin/nile 基于openkylin/yangtze
-
- packaging/openkylin/nile 基于 packaging/openkylin/yangtze
-
-
-
-# 10. 已有native格式的分支,转换成quilt格式
-
-(1)先基于当前版本创建upstream分支和tag
-
-```Bash
-# 假设原来的分支名为master,changelog中的版本号为1.2.3,要创建的开发分支为openkylin/yangtze
-# 创建upstream分支
-git checkout -b upstream master
-# upstream分支不应该有debian目录
-git rm -rf debian
-git commit -m 'import upstream 1.2.3'
-# 创建一个upstream标签,版本号不能包含 - 符号
-git tag upstream/1.2.3
-```
-
-(2)创建打包分支
-
-```Bash
-# 创建打包分支
-git checkout -b packaging/openkylin/yangtze master
-# 版本号和源码包格式改为quilt
-dch -v 1.2.3-0k1 "quilt format" -D v101 --force-distribution
-echo '3.0 (quilt)' > debian/source/format
-git add debian
-git commit -m 'to quilt format'
-# 基于打包分支创建新的开发分支
-git checkout -b openkylin/yangtze
-echo "3.0 (native)" > debian/source/format
-git commit -m 'to native format'
-# 测试打包,并保存pristine-tar信息
-git checkout packaging/openkylin/yangtze
-gbp buildpackage --git-pristine-tar --git-pristine-tar-commit --git-ignore-branch -S -nc
-```
-
-
-# 附:个别问题处理
-
-**1.**
-
-gbp:error: Error creating libwacom_1.3.orig.tar.xz: Pristine-tar couldn't checkout "libwacom_1.3.orig.tar.xz": fatal: Path 'libwacom_1.3.orig.tar.xz.delta' does not exist in 'refs/remotes/origin/pristine-tar'
-
-原因是初始导入的压缩包是gz格式的,debian/gbp.conf中却指定了压缩格式为xz。
-
-解决方法,在openkylin/yangtze分支修改debian/gbp.conf,删除compression=xz,提交。
-
-**2.**
-
-gbp:error: Error creating kbd_2.0.4.orig.tar.xz: Pristine-tar couldn't checkout "kbd_2.0.4.orig.tar.xz": xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
-
-压缩格式一致,但是checksum不同,可能是导入时文件损坏或者环境和ci环境版本不同导致的,需重新导入一次
-
-**3.**
-
-dpkg-source: error: detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion).
-
-假如开发分支涉及二进制文件修改,生成的patch也会有二进制信息,buildpackage时会提示`detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion)`
-
-debian推荐把要替换的二进制文件放在debian目录中,再修改debian/*.install或者debian/rules的install步骤,在编译时覆盖上游的二进制文件。debian中包含二进制文件,无论是图片还是patch,都需要将文件路径添加到debian/source/include-binaries中,或者是直接在debian/source/options里添加一行include-binaries,允许包含任何二进制文件。
-
-https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html
-
-> If you wish to replace upstream provided PNG file **data/hello.png** with maintainer provided one **debian/hello.png**, editing **debian/install** isn’t enough. When you add **debian/hello.png**, you need to add a line "`include-binaries`" to **debian/source/options** since PNG is a binary file. See `dpkg-source`(1).
-
+# openKylin源码包git工作流
+
+
+
+# 1. git分支设置
+
+| 分支 | 说明 | 举例 |
+| --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| 上游分支 | 不包含debian目录的分支,保存软件包的上游源码。 修改包只需要一个上游分支,统一命名为upstream。 对于自研包,可能会多版本并行开发,所以可能会有多个上游分支,为了避免与打包分支混淆,上游分支名称里不能使用“/” | upstream master 1.0 2.0 |
+| 开发分支 | 用于包维护者提交修改的分支,包含debian目录。 相对于上游分支修改的内容可以直接提交到这个分支。开发分支中源码包格式为native | 名称格式为:发行版代号/系列代号 openKylin 1.0版本开发分支命名为:openkylin/yangtze |
+| 打包分支 | 修改包要求使用quilt格式进行打包,这个分支下,包维护者相对上游分支做的修改都以patch形式保存在debian/patches目录中,便于更新上游版本时进行取舍。仅能用于当前发行版的包可以使用native格式打包,此时不需创建打包分支。 CI平台自动完成开发分支到打包分支的同步。 | openkylin/yangtze对应的打包分支,在分支名前面加上packaging/: packaging/openkylin/yangtze |
+| patch-queue分支 | CI构建环境中使用的临时分支,不会提交到源码管理平台,辅助将开发分支的修改内容生成patch保存到打包分支。 | patch-queue/packaging/openkylin/yangtze |
+
+
+
+# 2. 源码包导入
+
+源码包导入会自动创建上游分支和打包分支,对于quilt格式的源码包,需要将打包分支转化成native格式,便于开发者利用git管理文件修改历史。
+
+
+
+git_init.sh脚本描述了具体操作步骤:
+
+```
+#!/bin/bash
+
+set -e
+
+[ ! -d $1 ] && echo "should specify source path" exit 1;
+
+cd $1
+
+# 切换到打包分支
+git checkout openkylin/yangtze
+git checkout -b packaging/openkylin/yangtze
+
+# 创建临时的集成patch分支,会自动命名为 patch-queue/openkylin/yangtze
+gbp pq import
+
+# fix patches date format
+gbp pq export
+
+git add debian
+git commit -m "format patches" || true
+
+git checkout openkylin/yangtze
+
+# 在打包分支集成patch
+git merge patch-queue/packaging/openkylin/yangtze -m "apply patches"
+
+# 删除临时分支
+git branch -D patch-queue/packaging/openkylin/yangtze
+
+# 删除debian/patches目录
+rm -rf debian/patches
+
+# 修改format格式
+echo "3.0 (native)" > debian/source/format
+
+#提交改动
+git add debian
+git commit -m "changed debian/source/format to native"
+
+```
+
+## 2.1 使用工具导入
+
+可以使用`source-packing`工具进行导入:
+
+主要分三步:
+
+1. 对源码重新打包:
+
+```Bash
+./source-packing rebuild-source --dsc-file sqlite3_3.31.1-4kylin0.3.dsc --new-revisions ok1
+```
+
+此时会生成 `sqlite3_3.31.1-ok1.dsc`新的dsc文件
+
+1. 反向构建出git仓库:
+
+```Bash
+./source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch openkylin/yangtze
+```
+
+1. 关联远端仓库并推送到远端仓库(如果远端仓库没有创建,那么需要先创建远端仓库)
+
+```Bash
+# 进入到第二步构建出的源码仓库
+cd sqlite3
+# 关联远端仓库并推送到远端仓库
+git remote add origin git@gitee.com:openkylin/sqlte3.git
+git push --tags
+git push --all
+```
+
+详细使用方式如下项目文档描述:[源码反向构建工具-source-packing](https://gitee.com/openkylin/packaging-tools#源码反向构建工具-source-packing)
+
+备注:可以使用手动的方式进行源码的导入,具体可以参考2.2,2.3小节(如使用2.1工具反向构建成功,2.2、2.3小节内容可跳过)
+
+## 2.2 导入源码
+
+```Bash
+gbp import-dsc --pristine-tar --debian-branch=openkylin/yangtze --upstream-branch=upstream live-build_3.0~a57-1kylin38.20.04.2.dsc live-build
+```
+
+参数含义
+
+| --pristine-tar | 记录原始orig tar包的数据,避免重新用gbp打包后tar包内容发生变化 |
+| ------------------ | ------------------------------------------------------------ |
+| --debian-branch= | 指定打包分支名称,打包分支命名参考 https://docs.qq.com/doc/DQ2tlZ1BYUHBIVGp4 |
+| --upstream-branch= | 指定上游分支名称,修改包使用upstream,自研包使用master |
+
+除了我们指定的两个分支,gbp import-dsc命令还会自动创建两个tag:
+
+- debian/3.0_a57-1kylin38.20.04.2 打包分支在3.0~a57-1kylin38.20.04.2版本的状态
+- upstream/3.0_a57 本次导入的上游版本3.0~a57的状态,我们打包quilt格式的源码包时需要参考这个tag
+
+### 2.2.1 当存在多个orig包的特殊情况处理
+
+3.0 (quilt)格式的源码包支持多个orig包,有的软件包会将上游源码的主目录和个别子目录分别打包
+
+https://manpages.debian.org/testing/git-buildpackage/gbp-buildpackage.1.en.html#git~6
+
+例如sqlite3,3.31.1-4版本的源码包中有两个orig:sqlite3_3.31.1.orig.tar.xz,sqlite3_3.31.1.orig-www.tar.xz,编译时会先解压sqlite3_3.31.1.orig.tar.xz,然后将sqlite3_3.31.1.orig-www.tar.xz解压到www子目录。
+
+这种情况的包,gbp导入时能够识别,但是执行gbp buildpackage时需要指定--git-component=www才能成功打包。
+
+可以创建debian/gbp.conf,将--git-component选项固定下来
+
+```Prolog
+[buildpackage]
+component=www
+# 如有多个,要写成 component=['ft2docs', 'ft2demos']
+```
+
+不同的包component各不相同,需要分别创建debian/gbp.conf文件
+
+还有个坑,假如orig和orig-component包的压缩方式不一样,一个是xz,一个是gz,gbp buildpackage时会报错:
+
+```Plain%20Text
+gbp:warning: Components specified, pristine-tar-commit not yet supported - disabling it.
+gbp:info: Creating /home/xiewei/git/perl_5.30.0.orig.tar.xz
+gbp:info: Creating /home/xiewei/git/perl_5.30.0.orig-regen-configure.tar.xz
+gbp:error: Error creating perl_5.30.0.orig-regen-configure.tar.xz: Pristine-tar couldn't checkout "perl_5.30.0.orig-regen-configure.tar.xz": fatal: Path 'perl_5.30.0.orig-regen-configure.tar.xz.delta' does not exist in 'refs/heads/pristine-tar'
+pristine-tar: git show refs/heads/pristine-tar:perl_5.30.0.orig-regen-configure.tar.xz.delta failed
+```
+
+修复方法:
+
+1. 统一压缩格式,把perl_5.30.0.orig-regen-configure.tar.gz重新打包成perl_5.30.0.orig-regen-configure.tar.xz
+
+```Apache
+zcat perl_5.30.0.orig-regen-configure.tar.gz | xz -c - > perl_5.30.0.orig-regen-configure.tar.xz
+```
+
+1. 导入pristine-tar信息
+
+```Shell
+gbp pristine-tar commit --component=regen-configure path-to/perl_5.30.0.orig-regen-configure.tar.xz
+```
+
+## 2.3 创建开发分支,集成patch(将源码转换为native格式,便于开发人员本地测试编译)
+
+```Bash
+git checkout openkylin/yangtze # 切换到打包分支
+gbp pq import # 创建临时的集成patch分支,会自动命名为 patch-queue/openkylin/yangtze
+gbp pq export # 自动格式化patch,回到openkylin/yangtze分支
+git add debian
+git commit -m 'format patch'
+git branch packaging/openkylin/yangtze # 创建quilt的分支,用于正式打包
+git merge patch-queue/openkylin/yangtze -m "apply patches" # 在打包分支集成patch
+git branch -D patch-queue/openkylin/yangtze # 删除临时分支
+然后删除debian/patches目录,将debian/source/format修改为“3.0 (native)”
+rm -rf debian/pathes
+echo "3.0 (native)" > debian/source/format
+提交改动
+```
+
+
+
+# 3. 开发维护人员修改软件包(在开发分支如openkylin/yangtze下进行维护)
+
+## 3.1. 产线代码修改
+
+开发维护人员克隆正式版的git库到个人空间,然后直接在打包分支上修改源码文件和debian/changelog。
+
+```Bash
+git checkout openkylin/yangtze
+# 修改源码文件
+vim ...
+# 修改changelog,按软件包版本号规范修改版本号,对于版本号中带‘-’符号的,不能修改'-'前面的部分
+dch -R
+git add .
+git commit
+```
+
+再推送到个人gitee或gitlab仓库,提交PR给maintainer审核。
+
+本地调试时可以直接用debuild进行编译测试。
+
+## 3.2. 在打包分支修改后向上游提交patch
+
+向上游提交改动需要先导出patch
+
+首先执行git log,找到本次修改之前和之后的commit编号
+
+```Bash
+git log
+
+commit 5ba63fabc689b225cd7823a81655e531f54eed46 (HEAD -> openkylin/yangtze)
+Author: Xie Wei
+Date: Mon Apr 18 16:41:59 2022 +0800
+
+ edit version and copying
+
+commit 5c066ae094a7788c6507413891dab66db36cd07b
+Author: Xie Wei
+Date: Mon Apr 18 16:40:56 2022 +0800
+
+ edit COPYING
+
+commit e5a25c0fba1b1b68e023062878962abbebf1f8ea
+Author: Xie Wei
+Date: Mon Apr 18 16:40:31 2022 +0800
+
+ edit version
+
+commit 8c8ad046e88f2692bef8b193b517666d82ca6957
+Author: Xie Wei
+Date: Mon Apr 18 16:35:37 2022 +0800
+
+ native
+```
+
+如上所示,假设要把version和copying的改动作为一个完整的patch提交,那么应该对比倒数第1个commit和倒数第4个commit之间的改动。
+
+```Apache
+# 生成patch时忽略debian目录,较早的commit放在前面,较新的commit放在后面
+git diff --binary -r 8c8ad046e88f2692bef8b193b517666d82ca6957 -r 5ba63fabc689b225cd7823a81655e531f54eed46 ':!debian' > /tmp/live-build-change-version-copying.patch
+```
+
+生成patch之后,就要看上游社区接受什么样的提交方式,直接发patch的此文不介绍,假设它支持在gitee或github提交PR,那么我们先在相应的托管平台fork自己的仓库,然后clone到本地,再导入patch
+
+```Apache
+# clone自己在托管平台fork的仓库
+git clone git@gitee.com:xiewei/live-build.git live-build-upstream
+cd live-build-upstream
+# 切换到需要提交的分支,取决于patch针对的版本,以及上游社区的分支规定
+git checkout master
+git apply /tmp/live-build-change-version-copying.patch
+git add .
+# 提交修改说明
+git commit
+# push到自己fork的仓库
+git push
+```
+
+然后就是在托管平台上操作,从自己的仓库提交一个PR到上游社区。
+
+如果上游有更新,提交PR前要先同步上游改动,解决冲突后,再提交PR
+
+```Bash
+# 首先将上游仓库的地址添加到remote,clone下来后只需要做一次,因为我们只需要读取,添加https协议的地址就行了。
+git remote add upstream https://gitee.com/upstream/live-build.git
+# 同步上游更新,最后一个参数是要同步的分支名
+git pull upstream master
+# 如果有冲突,按照提示解决冲突,没有冲突则可以push到自己fork的仓库了
+git push
+```
+
+
+
+# 4. 上传编译平台(CI平台自动实现)
+
+上传编译平台时,需要尽量以quilt格式上传,充分重用orig.tar文件,节省带宽和服务器空间。
+
+将native格式源码包转化成quilt格式的动作会通过CI平台自动完成。
+
+
+
+## 4.1 以quilt格式打包
+
+在打包环境中clone git库,同步开发分支的代码到打包分支进行打包
+
+native转换成quilt,主要差异在于要相对于upstream的代码改动形成补丁,而不是直接在源码文件上修改,我们利用gbp pq来生成补丁。
+
+```Bash
+# 切换到打包分支
+git checkout packaging/openkylin/yangtze
+# 创建临时patch-queue,自动切换到patch-queue/packaging/openkylin/yangtze
+gbp pq import
+# 在patch-queue中提交开发分支最新的改动
+git diff --binary -r openkylin/yangtze -- ':!debian' | git apply -R
+git add . -f
+# 把开发分支最新的commit信息提交到patch-queue分支,用于导出patch
+git log -r openkylin/yangtze -1 --pretty=format:"%s" | git commit -F -
+# 导出patch,自动切换到packaging/openkylin/yangtze
+gbp pq export
+# 同步开发分支对于debian目录的改动,忽略patches和source/format
+git diff --binary -r openkylin/yangtze -- debian ':!debian/patches' ':!debian/source/format' | git apply -R
+
+git add debian
+# 把开发分支最新的commit信息提交到打包分支,不需要人工输入
+git log -r openkylin/yangtze -1 --pretty=format:"%s" | git commit -F -
+# 打包源码,因为gbp默认要在master分支打包,所以要加 --git-ignore-branch 参数,--git-tag参数可以在打包成功后自动创建tag
+gbp buildpackage --git-ignore-branch --git-tag --git-pristine-tar --git-pristine-tar-commit -S -nc
+# packaging/openkylin/yangtze分支需要自动保存到gitee或者gitlab
+git push
+git push --tags
+```
+
+假如native分支涉及二进制文件修改,生成的patch也会有二进制信息,buildpackage时会提示`detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion)`
+
+debian推荐把要替换的二进制文件放在debian目录中,再修改debian/*.install或者debian/rules的install步骤,在编译时覆盖上游的二进制文件。debian中包含二进制文件,无论是图片还是patch,都需要将文件路径添加到debian/source/include-binaries中,或者是直接在debian/source/options里添加一行include-binaries,允许包含任何二进制文件。
+
+https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html
+
+> If you wish to replace upstream provided PNG file **data/hello.png** with maintainer provided one **debian/hello.png**, editing **debian/install** isn’t enough. When you add **debian/hello.png**, you need to add a line "`include-binaries`" to **debian/source/options** since PNG is a binary file. See `dpkg-source`(1).
+
+根据版本号获取upstream标签的方法: (在已有patch基础上进行比较,不再直接对比upstream)
+
+```Python
+from gbp.deb.git import DebianGitRepository
+version = '3.0~a57-1kylin38.20.04.4.4'
+upstream_version = version.split('-')[0]
+# '3.0~a57'
+upstream_tag = DebianGitRepository.version_to_tag('upstream/%(version)s', upstream_version)
+# 'upstream/3.0_a57'
+```
+
+## 4.2 以native格式打包
+
+native格式软件包可以在开发分支直接打包源码,上传编译平台。
+
+```Bash
+# 切换到开发分支
+git checkout openkylin/yangtze
+# 打包源码,因为gbp默认要在master分支打包,所以要加 --git-ignore-branch 参数,--git-tag参数可以在打包成功后自动创建tag
+gbp buildpackage --git-ignore-branch --git-tag -S
+# 打包时创建的tag同步到gitee或gitlab
+git push --tags
+```
+
+
+
+# 5. 更新upstream版本(需要maintainer手动处理)
+
+软件包需要更新上游版本号时,要先导入上游源码,并添加相应的标签。这一步需要由maintainer在正式版的git库中操作。
+
+然后开发者可以将打包分支的代码rebase到新版本。
+
+## 5.1 导入上游新版本的源码(修改包)
+
+当软件包的上游版本更新时,需要新导入orig包
+
+```Bash
+gbp import-orig ../live-build_4.0.orig.tar.gz --no-merge --pristine-tar --upstream-branch=upstream
+git checkout upstream
+git push
+git push --tags
+```
+
+参数含义
+
+| --pristine-tar | 记录原始orig tar包的数据,避免重新用gbp打包后tar包内容发生变化 |
+| ------------------ | ------------------------------------------------------------ |
+| --no-merge | 不将上游版本的代码合并到打包分支,因为我们的开发分支是native格式的,基于upstream修改了源码,一般是没办法自动合并的 |
+| --upstream-branch= | 指定上游分支名称,修改包使用upstream |
+
+在以上的例子中,会新创建一个tag:upstream/4.0
+
+## 5.2 创建新版本的标签(自研包)
+
+maintainer基于upstream分支(或者其他的上游稳定版本分支)创建upstream/<新版本号>的标签,作为新版本打包的上游。
+
+可以在gitlab和gitee上操作。
+
+## 5.3 打包分支rebase到新版本
+
+### 5.3.1 判断旧版本上是否有patch
+
+```Bash
+git checkout packaging/openkylin/yangtze
+wc debian/patches/series
+# 查看patch数量
+```
+
+如果没有patch,按5.3.2、5.3.4操作。
+
+如果有patch,按5.3.3、5.3.4操作。
+
+### 5.3.2 无patch情况下rebase
+
+更新packaging分支
+
+```Bash
+git checkout packaging/openkylin/yangtze
+# 假设原版本号是2:4.11.6-ok1,新的upstream版本号2:4.13.17
+git merge upstream/4.13.17
+```
+
+更新开发分支
+
+```Bash
+git checkout openkylin/yangtze
+# 假设原版本号是2:4.11.6-ok1,新的upstream版本号2:4.13.17
+git merge upstream/4.13.17
+```
+
+在开发分支修改包版本号
+
+```Bash
+# 此时,可以在开发分支对基于上游upstream的代码进行调试,如:
+# 1. 修改代码,直到能编译出二进制包以及能正常安装
+vim xxx
+# 2. 在开发分支下进行debuild进行编译测试
+debuild
+# 3. 提交改动
+git add xxx
+# 4. 修改一下debian/changelog,版本号基于新的upstream version。
+dch -R
+git add debian/changelog
+git commit -m 'merge upstream 4.13.17'
+```
+
+### 5.3.3 有patch情况下rebase
+
+#### 5.3.3.1 获取旧版本patch对应的commit id
+
+```Bash
+# 基于旧版本创建临时分支
+git checkout packaging/openkylin/yangtze
+# 导入patch,形成git commit记录
+# 导入前也可以筛选一下补丁列表,修改debian/patches/series,删除不要的补丁,然后提交即可
+gbp pq import --force
+# 计算补丁数量
+wc debian/patches/series # 14 14 511 debian/patches/series
+# 获取commit id,重定向到文件保存
+git log --max-count=14 > /tmp/patch-list.txt
+```
+
+#### 5.3.3.2 更新packaging分支
+
+```Bash
+git checkout packaging/openkylin/yangtze
+# 假设原版本号是2:4.11.6-ok1,新的upstream版本号2:4.13.17
+git merge upstream/4.13.17
+```
+
+#### 5.3.3.3 筛选需要移植的patch,分别cherry-pick
+
+```Bash
+# 切换到packaging分支
+git checkout packaging/openkylin/yangtze
+# 清空patch列表
+git rm debian/patches/series
+git commit -m 'prepare for new patch list'
+# 创建临时分支,移植低版本patch
+gbp pq import --force
+# 从后往前读取patch-queue commit列表文件 /tmp/patch-list.txt,根据提交信息和补丁文件名确定是否要集成该补丁,对需要集成的补丁执行cherry-pick
+git cherry-pick b2cf5dd7923c50c4b4e1809564a7da63a3e38312 f32df40245f054363698225f44158c2673a06978 2853828b649d5c826bda93c9a11a9720954b915c
+# 导出patch列表
+gbp pq export
+git add debian/patches
+# 然后记得修改一下debian/changelog,版本号基于新的upstream version。
+dch -R
+git add debian/changelog
+git commit -m 'Apply patches on new upstream 4.13.17'
+# patch-queue分支可以删除了
+git branch -D patch-queue/packaging/openkylin/yangtze
+```
+
+假如存在冲突,根据实际需求进行冲突合并(git mergetool; git cherry-pick --continue)或者跳过此patch(git cherry-pick --skip)。
+
+> git cherry-pick基础用法
+
+> 挑选一个commit-id合并
+
+> ```
+> git cherry-pick commit-id
+> ```
+
+- > 注意:合并过来的commit-id将会变掉,产生一个新的commit-id,跟原来的不在相同
+
+> 挑选多个commit-id合并
+
+> ```
+> git cherry-pick commit-idA commit-idB
+> ```
+
+> 挑选连续的多个commit-id合并
+
+> ```
+> git cherry-pick commit-idA..commit-idB
+> ```
+
+- > 该指令是将从commit-idA开始到commit-idB之间的所有commit-id提交记录都合并过来,需要注意的是,commit-idA必须比commit-idB提前提交,也就是说在被挑选的分支上,先有的commit-idA,然后才有的commit-idB
+
+#### 5.3.3.4 反向同步到开发分支
+
+```Bash
+git checkout openkylin/yangtze
+git diff --binary -r patch-queue/packaging/openkylin/yangtze -- ':!debian/source/format' | git apply -R
+git add .
+git commit -m 'merge upstream 4.13.17'
+```
+
+### 5.3.4 提交到git服务器
+
+提交开发分支与packaging打包分支即可,其他临时分支不要提交
+
+```
+!push时,要先push packaging打包分支,再push 开发分支。
+```
+
+```Bash
+git checkout packaging/openkylin/yangtze
+git push
+git checkout openkylin/yangtze
+git push
+```
+
+
+
+# 6. 自研包改为quilt格式
+
+(1)解压源码包。
+
+```Apache
+dpkg-source -x kylin-camera_1.2kord01rc2.22.dsc
+cd kylin-camera-1.2kord01rc2.22
+```
+
+(2)修改changelog,版本号改为{upstream_version}-{revision}形式。
+
+```
+dch -R
+# 在编辑器中,将版本号从1.2kord01rc2.22改为1.2kord01rc2.22-0k1
+```
+
+(3)修改debian/source/format文件,改为3.0 (quilt)
+
+```Bash
+mkdir -p debian/source
+echo "3.0 (quilt)" > debian/source/format
+```
+
+(4)打包orig.tar
+
+```Bash
+debmake -t
+```
+
+(5)生成新的dsc
+
+```Bash
+dpkg-buildpackage -S -nc
+```
+
+(6)导入到git
+
+```Apache
+cd ../
+gbp import-dsc --pristine-tar --debian-branch=openkylin/yangtze --upstream-branch=upstream kylin-camera_1.2kord01rc2.22-0k1.dsc kylin-camera
+```
+
+
+
+# 7. 自研包不改变代码情况下修改上游版本号
+
+例如ukui在某个节点时,要将当前已导入的包统一升级上游版本号,需要按如下流程操作,
+
+(1)切换到开发分支 (例如openkylin/yangtze)。
+
+```Shell
+git checkout openkylin/yangtze
+```
+
+(2)读取debian/changelog,确认当前upstream版本。
+
+ 例如changelog中的版本号为3.10.0-0k0
+
+(3)修改changelog版本号,upstream version改成新版本号,假设要设置为3.13.0,那么changelog中的包版本号可以改成3.13.0-0k0。然后提交改动。
+
+(4)添加对应新版本号的upstream标签。
+
+```Shell
+git tag upstream/3.13.0 upstream/3.10.0
+```
+
+(5)openkylin/yangtze分支的改动以及新标签upstream/3.13.0推送到git服务器。
+
+```Shell
+git push
+git push --tags
+```
+
+(6)生成新版本orig.tar包(CI平台完成)。
+
+```Shell
+# 将changelog改动同步到打包分支
+git diff --binary -r openkylin/yangtze debian ':!debian/patches' ':!debian/source/format' | git apply -R
+git add debian
+git log -r openkylin/yangtze -1 --pretty=format:"%s" | git commit -F -
+# 打包,并自动保存orig.tar
+gbp buildpackage --git-ignore-branch --git-tag --git-pristine-tar --git-pristine-tar-commit -S -nc
+# 打包新的upstream版本后,pristine-tar分支会更新,需要上传到git服务器
+git push
+git push origin pristine-tar
+```
+
+
+
+# 8. 使用Kylin修改过的源码覆盖openkylin社区仓库
+
+前提是upstream版本没有改变,为quilt格式,否则需要清空仓库全新导入或者走“更新upstream版本”流程。
+
+(1)在打包分支覆盖debian目录
+
+```Shell
+# 切换到打包分支
+
+# 删除现有debian目录,准备用Kylin的版本覆盖
+# 解压Kylin版本的*.debian.tar文件
+```
+
+(2)修改changelog中的版本号与系列代号
+
+新增一条修改记录,版本号为-ok,N是数字,要比覆盖前openkylin中的版本号大。
+
+(3)覆盖开发分支
+
+
+
+# 9. 从头开始实现自动打包
+
+本节介绍如何在只有upstream等不包含debian配置文件的分支时,如何创建开发分支与打包分支
+
+即从upstream建立openkylin/yangtze和packaging/openkylin/yangtze分支。
+
+## 9.1 首先从gitee上的openkylin clone一份干净的代码
+
+```Bash
+git clone git@gitee.com:openkylin/<包名>
+cd <包名>
+```
+
+## 9.2 在upstream分支上添加upstream标签
+
+我们要选择一个上游版本对应的commit,打上upstream标签。
+
+分别可以用以下几种方式实现,假设上游版本号定为1.2.3
+
+(1)以upstream分支最新版本进行打包
+
+```Bash
+git tag upstream/v1.2.3 upstream
+```
+
+(2)以已存在的tag打包,假设已经有一个tag,名称为v1.2.3
+
+```Bash
+git tag upstream/1.2.3 v1.2.3
+```
+
+(3)以upstream分支某个commit为基点打包
+
+```Bash
+git log upstream # 找到想要使用的commit id
+git tag upstream/1.2.3 031eae9e49ef7b523286410d45ee44ba57e29f79
+```
+
+## 9.3 基于upstream标签创建打包分支,添加debian打包配置文件
+
+```Bash
+git checkout -b packaging/openkylin/yangtze upstream/1.2.3
+# 把准备好的debian打包配置文件复制过来
+cp -r /path-to/debian ./
+# 修改changelog,确保版本号为"1.2.3-"开头,并符合版本号规范
+dch -R
+# 确保源码包为quilt格式
+mkdir -p debian/source
+echo "3.0 (quilt)" > debian/source/format
+# 测试打包,并保存pristine-tar数据
+gbp buildpackage --git-ignore-branch --git-tag --git-pristine-tar --git-pristine-tar-commit -S -nc
+```
+
+## 9.4 创建相应的开发分支,方便开发人员修改代码后本地测试
+
+```Bash
+# 创建临时的集成patch分支,会自动命名为 patch-queue/packaging/openkylin/yangtze
+gbp pq import
+# 重命名为标准的开发分支名称
+git checkout -b openkylin/yangtze
+# 删除临时分支
+git branch -D patch-queue/packaging/openkylin/yangtze
+# 然后删除debian/patches目录,将debian/source/format修改为“3.0 (native)”
+rm -rf debian/pathes
+echo "3.0 (native)" > debian/source/format
+git add debian
+git commit -m 'change format to native'
+```
+
+## 9.5 推送到git服务器
+
+```Bash
+# 因为新建打包分支涉及到3个分支的修改,推送时使用push --all简化操作,这也是为什么一定要clone一份干净的代码来操作
+git push origin --tags
+git push origin --all
+```
+
+## 9.6 创建新版本系列开发分支
+
+当前openkylin 1.0版本已发布,2.0版本的开发分支名称已确定为openkylin/nile,本节介绍如何实现2.0版本代码自动打包。
+
+如果2.0版本不继承1.0版本代码开发,那么可以参考第9节进行,只需要把分支名称中的yangtze改为nile。
+
+如果2.0版本继承1.0版本代码,由包维护者在gitee上按如下流程操作:
+
+1. 访问仓库的分支列表
+
+
+
+2. 点击“新建分支”
+
+
+
+1. 输入分支名,分别新建两个分支:
+
+ openkylin/nile 基于openkylin/yangtze
+
+ packaging/openkylin/nile 基于 packaging/openkylin/yangtze
+
+
+
+# 10. 已有native格式的分支,转换成quilt格式
+
+(1)先基于当前版本创建upstream分支和tag
+
+```Bash
+# 假设原来的分支名为master,changelog中的版本号为1.2.3,要创建的开发分支为openkylin/yangtze
+# 创建upstream分支
+git checkout -b upstream master
+# upstream分支不应该有debian目录
+git rm -rf debian
+git commit -m 'import upstream 1.2.3'
+# 创建一个upstream标签,版本号不能包含 - 符号
+git tag upstream/1.2.3
+```
+
+(2)创建打包分支
+
+```Bash
+# 创建打包分支
+git checkout -b packaging/openkylin/yangtze master
+# 版本号和源码包格式改为quilt
+dch -v 1.2.3-0k1 "quilt format" -D v101 --force-distribution
+echo '3.0 (quilt)' > debian/source/format
+git add debian
+git commit -m 'to quilt format'
+# 基于打包分支创建新的开发分支
+git checkout -b openkylin/yangtze
+echo "3.0 (native)" > debian/source/format
+git commit -m 'to native format'
+# 测试打包,并保存pristine-tar信息
+git checkout packaging/openkylin/yangtze
+gbp buildpackage --git-pristine-tar --git-pristine-tar-commit --git-ignore-branch -S -nc
+```
+
+
+# 附:个别问题处理
+
+**1.**
+
+gbp:error: Error creating libwacom_1.3.orig.tar.xz: Pristine-tar couldn't checkout "libwacom_1.3.orig.tar.xz": fatal: Path 'libwacom_1.3.orig.tar.xz.delta' does not exist in 'refs/remotes/origin/pristine-tar'
+
+原因是初始导入的压缩包是gz格式的,debian/gbp.conf中却指定了压缩格式为xz。
+
+解决方法,在openkylin/yangtze分支修改debian/gbp.conf,删除compression=xz,提交。
+
+**2.**
+
+gbp:error: Error creating kbd_2.0.4.orig.tar.xz: Pristine-tar couldn't checkout "kbd_2.0.4.orig.tar.xz": xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
+
+压缩格式一致,但是checksum不同,可能是导入时文件损坏或者环境和ci环境版本不同导致的,需重新导入一次
+
+**3.**
+
+dpkg-source: error: detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion).
+
+假如开发分支涉及二进制文件修改,生成的patch也会有二进制信息,buildpackage时会提示`detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion)`
+
+debian推荐把要替换的二进制文件放在debian目录中,再修改debian/*.install或者debian/rules的install步骤,在编译时覆盖上游的二进制文件。debian中包含二进制文件,无论是图片还是patch,都需要将文件路径添加到debian/source/include-binaries中,或者是直接在debian/source/options里添加一行include-binaries,允许包含任何二进制文件。
+
+https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html
+
+> If you wish to replace upstream provided PNG file **data/hello.png** with maintainer provided one **debian/hello.png**, editing **debian/install** isn’t enough. When you add **debian/hello.png**, you need to add a line "`include-binaries`" to **debian/source/options** since PNG is a binary file. See `dpkg-source`(1).
+
diff --git a/05_社区贡献/开发指南/openKylin源码自主选型构建流程.md b/04_社区贡献/开发指南/openKylin源码自主选型构建流程.md
similarity index 97%
rename from 05_社区贡献/开发指南/openKylin源码自主选型构建流程.md
rename to 04_社区贡献/开发指南/openKylin源码自主选型构建流程.md
index 62c9f4f9..cbfe4a42 100644
--- a/05_社区贡献/开发指南/openKylin源码自主选型构建流程.md
+++ b/04_社区贡献/开发指南/openKylin源码自主选型构建流程.md
@@ -1,714 +1,714 @@
-# openKylin源码自主选型构建流程
-
-# 一、软件包版本号选型
-
-## 1. 选型策略
-
-### 1.1 软件项目选型策略
-
-
-- 持续积极引入全“A”软件(版本)
-
-- 鼓励引入仅含”A"和”B”软件(版本)tory-view-113483.html
-
-- 谨慎引入含"C“软件(版本)
-
-- 拒绝引入/及时删除含“D”或者“C >= 3”的软件(版本)
-
-### 1.2 软件版本选型策略
-
-- 长期支持版本(暂时openKylin还没定长期支持版本,1.0目前来说不是长期支持版)
- - 兼顾质量与稳定,优先选择主流OS广泛应用的版本。
- - 升级后不影响兼容性列表。
- - 同一个版本生命周期内不做大版本变动,仅采取特性、补丁回合的方式解决质量问题。
-
-- 社区开发版本
- - 满足基本合规问题下,尽可能集成更多软件,优先选择开源组件当前稳定分支的最新版本。
- - 及时跟进上游社区动态,合并开源软件新特性版本。
-
-### 1.3 软件分级与兼容性原则
-
-| **级别** | **范围** | **原则** |
-| -------- | --------------------------------------- | ------------------------------------------------------------ |
-| 一级 | kernel、glibc、gcc、zlib等系统核心组件 | API和ABI主版本的生命周期内保持稳定,并且在接下来的一个主版本中也尽量保持稳定 |
-| 二级 | dbus、openssl、bzip2、systemd等基础软件 | API和ABI在单个主版本的生存周期内保持稳定,依赖的应用程序在单个主版本生命周期内原则上无需重大修改 |
-| 三级 | 其他应用软件等 | API和ABI在单个主版本的生存周期内不强制保持稳定,存在依赖关系的应用程序保持联动升级 |
-
-## 2. 具体流程
-
-1. 依据“软件项目选型策略"挑选需要引入的新项目
-
-2. 依据"软件版本选型策略"挑选该项目需要引入的某一个版本
-
-3. 输出“项目选型报告”,包含新项目的合规性、兼容性、重要程度、活跃度、质量、安全性具体情况,以及选中版本的新特性、兼容性、影响域、其他发行版中版本情况对比等内容;
-
-4. 技术委员会通过后按以下流程开展具体工作
-
-### 2.1 获取软件包的项目地址
-
-获取项目地址用于查看软件包当前的项目详情、开发状态、编译安装、使用说明等相关内容
-
-可以从以下几个方法去获取软件包的项目地址:
-
-#### 2.1.1 debian社区的软件包追踪平台
-
-基本上绝大部分的软件包都可以在debian社区的软件包追踪平台([tracker.debian.org](https://tracker.debian.org/))上找到
-
-例如:查找`libnftnl`软件包
-
-
-
-如上图,可以通过右上角的homepage信息去获取软件包的项目地址;
-
-#### 2.1.2 dsc文件
-
-可以在debian社区([tracker.debian.org](https://tracker.debian.org/))、ubuntu(https://launchpad.net)等平台查看软件包的dsc文件,dsc文件中可能有描述当前软件包的项目地址信息。
-
-如:`libnftnl`在debian社区查看软件包[dsc文件](https://deb.debian.org/debian/pool/main/libn/libnftnl)(以下以[1.1.2-2版本](https://deb.debian.org/debian/pool/main/libn/libnftnl/libnftnl_1.1.2-2.dsc)为例):
-
-```Bash
-# 去除gpg签名信息,方便查看
-Format: 3.0 (quilt)
-Source: libnftnl
-Binary: libnftnl11, libnftnl-dev
-Architecture: linux-any
-Version: 1.1.2-2
-Maintainer: Debian Netfilter Packaging Team
-Uploaders: Arturo Borrero Gonzalez
-Homepage: https://git.netfilter.org/libnftnl
-Standards-Version: 4.2.1
-Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
-Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
-Build-Depends: debhelper (>= 11), libmnl-dev, libtool, pkg-config
-Package-List:
- libnftnl-dev deb libdevel optional arch=linux-any
- libnftnl11 deb libs optional arch=linux-any
-Checksums-Sha1:
- c0f880588fabaa845a88fb5a2bdad0dea7481857 366014 libnftnl_1.1.2.orig.tar.bz2
- 0a9063e79191955fbf59482d75c7bfb62aded816 912 libnftnl_1.1.2.orig.tar.bz2.asc
- 505f8b44e3adb574dc3cf657580e9d73f0b0a853 8772 libnftnl_1.1.2-2.debian.tar.xz
-Checksums-Sha256:
- a5c7b7a6c13c9c5898b13fcb1126fefce2015d5a96d7c354b19aaa40b6aece5d 366014 libnftnl_1.1.2.orig.tar.bz2
- 4178552d7ad210e9f17df3c079ac6de032f62c72774d59bfac404a023d48950b 912 libnftnl_1.1.2.orig.tar.bz2.asc
- 4ef80a0c344b23624d24b7dd4be1b73a7b96d86089813c545705f8093067ce13 8772 libnftnl_1.1.2-2.debian.tar.xz
-Files:
- 14093a238d5025d4a452e6d1cef88c58 366014 libnftnl_1.1.2.orig.tar.bz2
- e10dcb9138261d92e7569bd72b809a28 912 libnftnl_1.1.2.orig.tar.bz2.asc
- 518ff0360f67c8031a31792a257a5c3b 8772 libnftnl_1.1.2-2.debian.tar.xz
-```
-
-如高亮处:
-
-- **Homepage** :项目地址
-
-- **Vcs-Browser** :版本控制系统浏览平台(类似于github、gitee、gitlab等平台)
-
-- **Vcs-Git** :git仓库地址
-
-#### 2.1.3 debian/control文件
-
-首先先从debian社区、ubuntu社区(launchpad.net)任意下载源码包,并解压缩。
-
-```Bash
-# 从ubuntu社区(launchpad.net)平台下载源码包
-# 也可以通过添加deb-src源的方式使用apt-source来下载源码
-# 使用dget需要安装devscripts
-dget -x https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/libnftnl/1.2.3-1/libnftnl_1.2.3-1.dsc
-
-# 进入到解压缩目录
-cd libnftnl-1.2.3
-```
-
-查看`debian/control`文件,查找是否有`Homepage`、`Vcs-Git`、`Vcs-Browser`等相关字段
-
-如:
-
-```Bash
-$ grep -E "^(Homepage|Vcs-*)" debian/control
-Homepage: https://git.netfilter.org/libnftnl
-Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl.git
-Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
-```
-
-上述高亮处各字段的说明与2.1.2小节的内容一致
-
-#### 2.1.4 debian/watch文件
-
-与2.1.3小节一样,需要先下载源码。这次查看的是`debian/watch`文件
-
-**debian/watch** 文件主要是用来记录上游源码的下载地址(该文件不是必须的,因此在某些源码包中可能没有该文件)
-
-```Bash
-$ cat debian/watch
-version=3
-opts=pgpsigurlmangle=s/$/.sig/ http://ftp.netfilter.org/pub/libnftnl/libnftnl-(\S+).tar.bz2
-```
-
-通过该文件记录的上游源码下载地址,可以找到其对应的项目地址
-
-如:
-
-```Bash
-# 其下载地址一般是ftp或git release下载地址
-# 如果其下载地址是由别的平台托管的那么可能就无法获悉其项目地址
-http://ftp.netfilter.org/pub/libnftnl
-
-# 通过上述地址猜测可能的项目地址是
-http://netfilter.org/pub/libnftnl
-```
-
-### 2.2 获取软件包的版本情况
-
-通过查看项目地址获悉当前项目的最新稳定版本列表。
-
-可以通过以下几种方式查看:
-
-- debian/watch 文件
-
-在2.1.4小节中如果软件包的有debian/watch文件,可以查看该项目的上游软件包压缩包下载地址。
-
-```
-!其下载地址中可能有beta版本,其名字类似于xxxx-beta.tar.gz。一般这种beta版本的源码不应该被选择。
-```
-
-- git仓库
-
-如果是git仓库,可以查看其对应的是否有发布 git release:
-
-1. 如果有,那么可以在git release页面获取其版本列表
-
-2. 如果没有,查看其对应的`branch(分支)`、`tag(标记)`是否有相关版本列表信息
-
-
-
-# 二、构建源码包
-
-从第一章节中选出待构建软件包的版本以及下载地址。
-
-如果远端仓库已有项目,需要变更upstream版本,那么请查看第4小节的内容。
-
-## 1. 下载源码并修改源码目录格式
-
-下载源码包到本地,并解压缩
-
-```Bash
-# 下载源码
-wget https://www.netfilter.org/pub/libnftnl/libnftnl-1.2.3.tar.bz2
-
-# 解压缩
-tar -xaf libnftnl-1.2.3.tar.bz2
-```
-
-修改源码目录,使其符合**-**格式。如:
-
-```Bash
-$ ls -al
-drwxr-x---@ - luzp 10 8月 02:24 libnftnl-1.2.3
-.rw-rw----@ 395k luzp 10 8月 02:24 libnftnl-1.2.3.tar.bz2
-```
-
-## 2. 构建出debian打包目录
-
-### 2.1 upstream源码包含debian目录
-
-```
-!注意:如果上游源码目录中包含debian目录,此时我们需要手动对上游的debian目录进行改名,避免我们再重新生成debian目录时引起别的问题
-```
-
-- 备份原有的debian目录
-
-```Bash
-mv debian debian-orig
-```
-
-- 重新构建debian目录
-
-```Bash
-debmake -u -r <修订版本号> -t
-```
-
-此时,会在源码的同级目录新创建个目录,其格式为<原来的源码目录名称>-
-
-假如:
-
-源码压缩包是`amdgcn-tools-13.tar.gz`
-
-```Bash
-# 解压源码
-# 解压后的源码目录为amdgcn-tools-13
-tar -xaf amdgcn-tools-13.tar.gz
-
-# 进入源码目录,并备份原来的debian目录
-cd amdgcn-tools-13
-mv debian debian-orig
-
-# 重新构建debian目录
-debmake -u13 -rok1 -t
-
-# 执行完成之后,会在amdgcn-tools-13同级目录生成一个新的目录
-# <原来的源码目录>-,也就是下面的目录
-ls amdgcn-tools-13-13
-```
-
-### 2.2 直接构建debian目录
-
-如果上游源码是纯源码,那么直接构建debian目录即可。
-
-```Bash
-# 构建debian目录
-debmake -z tar.bz2
-```
-
-- -z 指定源码的压缩包格式
- - libnftnl-1.2.3.tar.bz2 就指定为 -z tar.bz2
-
- - 默认的源码压缩格式是tar.gz
-
-- -b 如果是perl或python的源码包可以指定该参数,为debmake创建出更多配套对应编程语言的文件
-
-```Bash
-# 如果是python
-debmake -b":python3"
-
-# perl
-debmake -b":perl"
-```
-
-- -t 重新生成上游源码包(即xxx.orig.tar.gz)
-
-更详细的debmake用法可以查看其man手册
-
-```Bash
-man debmake
-```
-
-## 3. 修改构建规则
-
-主要是修改debian目录中的文件。
-
-### 3.1 control
-
-`control`文件涉及两个部分的内容:
-
-#### 3.1.1 源码包部分
-
-描述当前这个源码包的简要信息,以及构建该源码包的编译依赖等
-
-其中有几个字段需要注意:
-
-- **Section**
-
-描述软件包的类型,用于软件包的分类。比如`mysql-8`应属于`database`
-
-可选的内容有:
-
-admin, cli-mono, comm, database, debug, devel, doc, editors, education, electronics, embedded, fonts, games, gnome, gnu-r, gnustep, graphics, hamradio, haskell, httpd, interpreters, introspection, java, javascript, kde, kernel, libdevel, libs, lisp, localization, mail, math, metapackages, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, rust, science, shells, sound, tasks, tex, text, utils, vcs, video, web, x11, xfce, zope
-
-- **Priority**
- - 软件包的优先级
-
- - required 系统必须的包
- - important 重要的软件包,系统非必须的包,但是希望系统中最好能预装的
- - standard 标准相对独立的软件包
- - optional 这是默认优先级选项,除非这个软件包是系统必须的包,否则应该使用该选项
-
-- **Maintainer**
-
-需要写成当前openkylin负责该软件包的sig组,如`packaging sig`组的写成`Openkylin Developers `
-
-- **Vcs-Browser**:
-
-写成对应的gitee仓库地址, 如 https://gitee.com/openkylin/autoconf
-
-- **Vcs-Git**
-
-写成对应的gitee仓库git地址 ,如 https://gitee.com/openkylin/autoconf.git
-
-- **Build-Depends和**
-
-编译体系结构相关代码所需要的编译依赖
-
-- **Build-Depends-Indep**
-
-编译体系结构无关的代码所需要的编译依赖
-
-对于**Build-Depends**和**Build-Depends-Indep**可以从项目地址中查找是否有相关编译依赖说明。
-
----
-**注意:** 如果control文件参考了其他OS发行版的规则,需要去除或替换其他OS版本中的版本号规则,例如:
-
-```
-Build-Depends:
- pkg1 (>= 1.0.0-0ubuntu1),
- pkg1 (< 1.2.0-1debian2),
- pkg2 (> 1.0.0.build),
- pkg3 (> 2.0ubuntu19)
-```
-
-首先,需要明确对于quilt格式的版本号其一般带有"-",格式为`-`,而native格式的源码包一般不包含"-"
-
-修改流程可以分两步进行
-
-**第一步:**
-
-对于quilt格式的版本,pkg1中的版本号 1.0.0-0ubuntu1 和 1.2.0-1debian2 其包含特定OS发行版的版本号,因此要修改。也就变成:
-
-```
-pkg1 (>= 1.0.0),
-pkg1 (< 1.2.0),
-```
-
-对于native格式的版本号,首先需要确定其upstream版本,对于pkg2和pkg3:
-
-(1)尝试找到pkg2的1.0.0版本,如果能找到,那么1.0.0就是upstream版本,其编译依赖改为:pkg2 (> 1.0.0);同理pkg3
-
-(2)如果找不到pkg2的upstream版本,此外当前版本号没有包含其他OS发行版名称,那么可以保留(因为使用source-package工具重打包源码,其upstream版本号也就是当前的版本号);但是对于pkg3,如果pkg3是OS自研的(其源码名称一般也包含OS名称,例如ubuntu-keyring),那么此时可以将此包重新改名,由openkylin重新维护,对应源码名称改为openkylin-keyring,版本号也重新制定,例如可以制定为1:1.0.0;如果不是OS自研包,最好我们也重新制定版本号,按我们自己的版本号去维护,可以内部讨论,例如这里也指定为1:1.0.0。**注意这里,最好要使用:格式的版本号,其表明带有:的版本号总会比不带的版本号高。**
-
-那么,对于pkg2,pkg3,其修改为:
-
-```
-pkg2 (> 1.0.0.build),
-pkg3 (> 1:1.0.0)
-```
-
-**第二步(native格式的不用处理):**
-
-第二步是在第一步的基础上改进。总体上我们要明确其他OS发行版中-横线后面的修订版本的内容。
-
-对于-,一般来说每个revision是修复了某个bug、安全漏洞等。对于ubuntu,每个revision都是由几个patch组成。
-
-因此对于pkg1 (>= 1.0.0-0ubuntu1),其明确规定是0ubuntu1修订版本之后的才能使用,也就意味着使用pkg1的1.0.0版本是存在风险的,最直接的现象就是编译不通过。
-
-因此,这就需要结合我们实际的pkg1的版本情况来:
-
-(1)如果仓库存在pkg1,其版本为1.0.0-ok1。为了保证上述编译能通过,需要集成ubuntu的1.0.0-0ubuntu1中的patch。如果已经集成相关patch,那么编译依赖就变成:
-
-```
-pkg1 (>= 1.0.0-ok1),
-pkg1 (< 1.2.0),
-```
-
-集成了patch之后仓库中的pkg1版本变为1.0.0-ok2。那么在编译依赖的地方就变成:
-
-```
-pkg1 (>= 1.0.0-ok2),
-pkg1 (< 1.2.0),
-```
-
-(2)如果仓库不存在pkg1,那么我们首次自主选型构建时,选型的版本最好是在1.0.0~1.2.0 之间选择,保证能满足各个依赖包的编译依赖。
-
-上面所说,都是基于编译依赖来处理。同理二进制包的安装依赖字段如果也指定了版本号,那么处理方式也是和上面的一样。
-
-#### 3.1.2 二进制包部分
-
-描述当前源码包可以被分为哪些二进制包程序。
-
-常见的分包类型为:
-
-- lib
-
-共享库,其二进制包包名一般为 `lib-xxx`
-
-- dev
-
-共享库头文件及相关开发文件,其二进制包名一般为`lib-xxx-dev`
-
-- doc
-
-软件包的文档
-
-如果其文档对应的是某个可执行程序的文档,其二进制包包名一般为`xxx-doc`
-
-如果其文档是某个开发库的文档,其二进制包包名一般为`lib-xxx-doc`
-
-- bin
-
-软件包的二进制程序,如编译型语言(比如c/c++)的二进制程序,以及解释型编程语言(比如python、perl)的可执行程序,其二进制包包名一般为其对应的二进制程序名称
-
-这个分包时,可以结合`debmake`在构建`debian`打包目录时一起使用,如:
-
-```Bash
-# 软件包名称为 foo , 其提供二进制程序与二进制程序的文档
-debmake -b"foo:bin,foo-doc:doc"
-
-# 软件包名称为 libfoo , 是一个开发库源码,其提供开发库与开发库的文档
-debmake -b"libfoo:lib,libfoo-doc:doc"
-
-# 执行完之后,会自动将各个二进制包信息模板写入到debian/control文件中
-```
-
-### 3.2 rules
-
-软件包的编译构建规则
-
-### 3.3 changelog
-
-修改软件包的版本号,格式为:-
-
-一般来说,对于openkylin社区,使用`ok1`作为第一次revisions,如:
-
-```Bash
-autoconf (2.71-ok1) yangtze; urgency=low
-
- * Build for openKylin.
-
- -- Lu zhiping Fri, 26 Aug 2022 15:25:09 +0800
-```
-
-### 3.4 source/format
-
-必须将源码包的格式设为`quilt`格式
-
-```Bash
-echo "3.0 (quilt)" > debian/source/format
-```
-
-```Bash
-echo "3.0 (quilt)" > debian/source/format
-```
-
-### 3.5 其他文件
-
-xxx.install
-
-xxx.doc
-
-xxx.symbols
-
-xxx.manpages
-
-### 3.6 应用其他OS发行版的补丁
-
-如果其他OS发行版有该软件包的补丁,那么我们需要分析考虑是否应用他们的补丁。
-
-可以先从以下方面去考虑是否应用其他OS发行版的补丁:
-
-- 补丁的修复内容是什么?补丁没能被上游社区吸收的原因,是否是无关紧要的补丁?
-
-- 是否是以前的旧版本才有的补丁,新版本是否已经集成?
-
-- 是否是重大漏洞修复补丁?
-
-- 是否是特定OS发行版才需要的补丁?
-
-- 如果不应用补丁是否出现编译问题,安装是否有问题?
-
-```
-而且,应用上游社区的patches最好是在构建出git仓库之后再应用patches,这样能在git commit中保留上游社区patch的信息
-```
-
-下面的内容是在第五章节构建出git仓库之后应用patch的步骤:
-
-如果需要应用上游社区的patch,最好是保留他们patch信息的内容与作者信息等。可以通过git工具直接应用上游社区的patch:
-
-- git am应用patch
-
-git am应用patch会自动保留patch的信息
-
-```Bash
-git am xxxx.patch
-```
-
-- git apply应用patch
-
-但是有些patch的信息格式不是完全适用于git am,那么可以使用git apply导入patch,然后再进行commit添加patch信息
-
-```Bash
-# 导入patch信息
-git apply xxx.patch
-
-# 添加改动
-git add .
-
-# 在编辑框中填写patch的相关信息,如
-# patch的作者,patch的内容等
-git commit
-```
-
-导入patch之后,想对新导入patch的内容进行编译测试,那么可以使用gbp工具来生成新的源码(新的dsc文件)
-
-```Bash
-# 修改changelog新增版本号
-vim debian/changelog
-
-# 编译源码,会生成新的dsc文件
-gbp buildpackage -S -sa -nc --git-prisine-tar --git-ignore-branch
-```
-
-## 4. 导入上游upstream源码
-
-如果远端仓库已有项目,需要变更upstream版本。
-
-(1)从上游社区下载源码压缩包
-
-(2)对源码压缩包重新加压缩使其符合`_.orig.tar.[gz|xz|bz2]`格式
-
-```Bash
-#例如:
-# 从上游源码社区获取的源码压缩包为 requests-2.27.1.tar.gz
-# 首先解压源码
-tar -xaf requests-2.27.1.tar.gz
-
-# 修改源码目录为 -
-# 假如从上游社区的源码压缩包解压出来的目录是requests
-mv requests requests-2.27.1
-
-# 重新压缩,使其符合 _.orig.tar.[gz|xz|bz2]
-tar -czf requests-2.27.1 requests-2.27.1.orig.tar.gz
-```
-
-(3)克隆gitee远端仓库源码到本地,进入源码目录
-
-```Bash
-# 克隆远端仓库
-git clone git@gitee.com:openkylin/requests.git
-
-# 进入源码目录
-cd requests
-```
-
-(4)变更upstream源码
-
-参考[openKylin源码包git工作流](openKylin源码包git工作流.md) 的第六章节《更新upstream版本》
-
-- a. 导入上游upstream版本(第二步生成的压缩包)
-
-- - ```Bash
- gbp import-orig requests-2.27.1.orig.tar.gz --no-merge --pristine-tar --upstream-branch=upstream
- git checkout upstream
- git push
- git push --tags
- ```
-
-- b. 筛选旧版本patch (结合[openKylin源码包git工作流](openKylin源码包git工作流.md) 6.3.3小节进行)
-
-- - 如果patch是研发的patch,那么需要与相关研发确认该patch在新的upstream源码中是否还需要
- - 如果patch是其他OS发行版的patch,那么需要结合OS发行版的最新版本源码中确认是否还需要该patch
-
-- c. 引入其他OS发行版的patch
-
-- - 可以参考3.6小节《应用其他OS发行版的补丁》。
-
- - 使用git am或git apply 或其他方式导入其他OS发行版的patch
-
-- d. 修改debian目录的其他编译构建文件
-
-- - debian/control
- - debian/changelog 需保留原有的changelog信息
- - debian/rules
- - deiban/其他文件
-
-修改完成之后,可以按第5小节,先本地编译测试,测试无问题后再推送到远端仓库上。
-
-## 5. 编译源码包
-
-完成对debian目录构建规则的完善之后,先基于此编译一轮源码包。会生成dsc文件
-
-```Bash
-# 切到开发分支上
-git checkout openkylin/yangtze
-# 在源码目录执行
-dpkg-source -b .
-```
-
-
-
-# 三、编译
-
-根据上一章节的内容构建出源码包之后,进行编译。
-
-可以下载一个openkylin的chroot环境,在chroot环境中进行编译调试。
-
-x86的chroot:http://files.build.openkylin.top/51159/chroot-openkylin-yangtze-amd64.tar.gz
-
-riscv的chroot: http://files.build.openkylin.top/51197/chroot-openkylin-yangtze-riscv64.tar.gz
-
-在这一阶段会对debian打包目录中的打包构建规则进行不断的修改和优化,直至打包出一个完整可安装的二进制包。
-
-
-
-# 四、安装测试
-
-简单测试编译出的二进制程序是否可安装,安装之后系统是否正常等
-
-
-
-# 五、构建git仓库
-
-## 1. 创建gitee仓库
-
-fork openkylin的community仓库
-
-```Bash
-# fork到个人仓库之后,克隆个人仓库到本地
-git clone git@gitee.com:/community.git
-
-# 然后在对应的sig组sig.yaml文件中添加源码包名称
-# 例如为packaging sig新增软件包,source-name 需写实际的软件包名称
-echo "- " >> sig/packaging/sig.yaml
-
-# 然后提交改动,推送到个人仓库
-git add sig/packaging/sig.yaml
-git commit -m "新增xxx软件包"
-git push origin master
-```
-
-在gitee网页端创建PR,然后由community项目负责人审查,审查通过后CI平台会自动创建对应的git仓库
-
-## 2. 构建git仓库
-
-对第二章节构建出来的源码包进行git仓库的构建。
-
-- 下载工具
-
-按照[source-packaging](https://gitee.com/openkylin/packaging-tools#源码反向构建工具-source-packing)工具的使用方法下载工具和相关依赖的安装
-
-- 构建git仓库
-
-```Bash
-./source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch openkylin/yangtze
-```
-
-更详细的git工作流可以参考[openKylin源码包git工作流](openKylin源码包git工作流.md)
-
-## 3. 关联远端仓库,并推送到gitee
-
-需要包在第三章节编译、第四章节安装测试没问题了之后,才推送到gitee仓库上
-
-```Bash
-# 进入到第二步构建出的源码仓库
-cd sqlite3
-# 关联远端仓库并推送到远端仓库
-git remote add origin git@gitee.com:openkylin/sqlte3.git
-git push --all && git push --tags
-```
-
-
-
-# 六、其他内容
-
-1. gitee的ci流程简要描述:
-
-```Bash
-1. 软件包第一次推送:
-maintainer首次将包通过push的方式推送到gitee的仓库上,此时ci平台会将其打包发送到okbs编译平台进行编译,当前的编译地址是(https://build.openkylin.top/~cibot/+archive/openkylin/citest/+packages)
-
-2. 后续的修改贡献:
-开发者需要fork仓库到个人仓库中,然后在个人仓库上进行开发修改,源码修改完毕后再修改changelog新增版本号,然后提交PR到原始仓库。
-
-maintainer审查PR,PR审查通过后,CI平台自动对当前的PR进行打包发送到OKBS编译平台进行编译,编译结果将会以评论的方式添加到对应的PR中,maintainer根据编译结果以及CI平台的门禁检查结果来考虑是否接收该PR
-```
-
-2. 各发行版源地址,以gvfs为例:
-
-Debian 11: https://tracker.debian.org/pkg/gvfs
-
-Ubuntu 22.04: https://launchpad.net/ubuntu/+source/gvfs
-
-Fedora 36: https://src.fedoraproject.org/rpms/gvfs
-
-Arch: https://archlinux.org/packages/extra/x86_64/gvfs/
-
-Deepin: https://ftp.sjtu.edu.cn/deepin/pool/
-
-openEuler: https://gitee.com/src-openeuler/gvfs
+# openKylin源码自主选型构建流程
+
+# 一、软件包版本号选型
+
+## 1. 选型策略
+
+### 1.1 软件项目选型策略
+
+
+- 持续积极引入全“A”软件(版本)
+
+- 鼓励引入仅含”A"和”B”软件(版本)tory-view-113483.html
+
+- 谨慎引入含"C“软件(版本)
+
+- 拒绝引入/及时删除含“D”或者“C >= 3”的软件(版本)
+
+### 1.2 软件版本选型策略
+
+- 长期支持版本(暂时openKylin还没定长期支持版本,1.0目前来说不是长期支持版)
+ - 兼顾质量与稳定,优先选择主流OS广泛应用的版本。
+ - 升级后不影响兼容性列表。
+ - 同一个版本生命周期内不做大版本变动,仅采取特性、补丁回合的方式解决质量问题。
+
+- 社区开发版本
+ - 满足基本合规问题下,尽可能集成更多软件,优先选择开源组件当前稳定分支的最新版本。
+ - 及时跟进上游社区动态,合并开源软件新特性版本。
+
+### 1.3 软件分级与兼容性原则
+
+| **级别** | **范围** | **原则** |
+| -------- | --------------------------------------- | ------------------------------------------------------------ |
+| 一级 | kernel、glibc、gcc、zlib等系统核心组件 | API和ABI主版本的生命周期内保持稳定,并且在接下来的一个主版本中也尽量保持稳定 |
+| 二级 | dbus、openssl、bzip2、systemd等基础软件 | API和ABI在单个主版本的生存周期内保持稳定,依赖的应用程序在单个主版本生命周期内原则上无需重大修改 |
+| 三级 | 其他应用软件等 | API和ABI在单个主版本的生存周期内不强制保持稳定,存在依赖关系的应用程序保持联动升级 |
+
+## 2. 具体流程
+
+1. 依据“软件项目选型策略"挑选需要引入的新项目
+
+2. 依据"软件版本选型策略"挑选该项目需要引入的某一个版本
+
+3. 输出“项目选型报告”,包含新项目的合规性、兼容性、重要程度、活跃度、质量、安全性具体情况,以及选中版本的新特性、兼容性、影响域、其他发行版中版本情况对比等内容;
+
+4. 技术委员会通过后按以下流程开展具体工作
+
+### 2.1 获取软件包的项目地址
+
+获取项目地址用于查看软件包当前的项目详情、开发状态、编译安装、使用说明等相关内容
+
+可以从以下几个方法去获取软件包的项目地址:
+
+#### 2.1.1 debian社区的软件包追踪平台
+
+基本上绝大部分的软件包都可以在debian社区的软件包追踪平台([tracker.debian.org](https://tracker.debian.org/))上找到
+
+例如:查找`libnftnl`软件包
+
+
+
+如上图,可以通过右上角的homepage信息去获取软件包的项目地址;
+
+#### 2.1.2 dsc文件
+
+可以在debian社区([tracker.debian.org](https://tracker.debian.org/))、ubuntu(https://launchpad.net)等平台查看软件包的dsc文件,dsc文件中可能有描述当前软件包的项目地址信息。
+
+如:`libnftnl`在debian社区查看软件包[dsc文件](https://deb.debian.org/debian/pool/main/libn/libnftnl)(以下以[1.1.2-2版本](https://deb.debian.org/debian/pool/main/libn/libnftnl/libnftnl_1.1.2-2.dsc)为例):
+
+```Bash
+# 去除gpg签名信息,方便查看
+Format: 3.0 (quilt)
+Source: libnftnl
+Binary: libnftnl11, libnftnl-dev
+Architecture: linux-any
+Version: 1.1.2-2
+Maintainer: Debian Netfilter Packaging Team
+Uploaders: Arturo Borrero Gonzalez
+Homepage: https://git.netfilter.org/libnftnl
+Standards-Version: 4.2.1
+Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
+Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
+Build-Depends: debhelper (>= 11), libmnl-dev, libtool, pkg-config
+Package-List:
+ libnftnl-dev deb libdevel optional arch=linux-any
+ libnftnl11 deb libs optional arch=linux-any
+Checksums-Sha1:
+ c0f880588fabaa845a88fb5a2bdad0dea7481857 366014 libnftnl_1.1.2.orig.tar.bz2
+ 0a9063e79191955fbf59482d75c7bfb62aded816 912 libnftnl_1.1.2.orig.tar.bz2.asc
+ 505f8b44e3adb574dc3cf657580e9d73f0b0a853 8772 libnftnl_1.1.2-2.debian.tar.xz
+Checksums-Sha256:
+ a5c7b7a6c13c9c5898b13fcb1126fefce2015d5a96d7c354b19aaa40b6aece5d 366014 libnftnl_1.1.2.orig.tar.bz2
+ 4178552d7ad210e9f17df3c079ac6de032f62c72774d59bfac404a023d48950b 912 libnftnl_1.1.2.orig.tar.bz2.asc
+ 4ef80a0c344b23624d24b7dd4be1b73a7b96d86089813c545705f8093067ce13 8772 libnftnl_1.1.2-2.debian.tar.xz
+Files:
+ 14093a238d5025d4a452e6d1cef88c58 366014 libnftnl_1.1.2.orig.tar.bz2
+ e10dcb9138261d92e7569bd72b809a28 912 libnftnl_1.1.2.orig.tar.bz2.asc
+ 518ff0360f67c8031a31792a257a5c3b 8772 libnftnl_1.1.2-2.debian.tar.xz
+```
+
+如高亮处:
+
+- **Homepage** :项目地址
+
+- **Vcs-Browser** :版本控制系统浏览平台(类似于github、gitee、gitlab等平台)
+
+- **Vcs-Git** :git仓库地址
+
+#### 2.1.3 debian/control文件
+
+首先先从debian社区、ubuntu社区(launchpad.net)任意下载源码包,并解压缩。
+
+```Bash
+# 从ubuntu社区(launchpad.net)平台下载源码包
+# 也可以通过添加deb-src源的方式使用apt-source来下载源码
+# 使用dget需要安装devscripts
+dget -x https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/libnftnl/1.2.3-1/libnftnl_1.2.3-1.dsc
+
+# 进入到解压缩目录
+cd libnftnl-1.2.3
+```
+
+查看`debian/control`文件,查找是否有`Homepage`、`Vcs-Git`、`Vcs-Browser`等相关字段
+
+如:
+
+```Bash
+$ grep -E "^(Homepage|Vcs-*)" debian/control
+Homepage: https://git.netfilter.org/libnftnl
+Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl.git
+Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
+```
+
+上述高亮处各字段的说明与2.1.2小节的内容一致
+
+#### 2.1.4 debian/watch文件
+
+与2.1.3小节一样,需要先下载源码。这次查看的是`debian/watch`文件
+
+**debian/watch** 文件主要是用来记录上游源码的下载地址(该文件不是必须的,因此在某些源码包中可能没有该文件)
+
+```Bash
+$ cat debian/watch
+version=3
+opts=pgpsigurlmangle=s/$/.sig/ http://ftp.netfilter.org/pub/libnftnl/libnftnl-(\S+).tar.bz2
+```
+
+通过该文件记录的上游源码下载地址,可以找到其对应的项目地址
+
+如:
+
+```Bash
+# 其下载地址一般是ftp或git release下载地址
+# 如果其下载地址是由别的平台托管的那么可能就无法获悉其项目地址
+http://ftp.netfilter.org/pub/libnftnl
+
+# 通过上述地址猜测可能的项目地址是
+http://netfilter.org/pub/libnftnl
+```
+
+### 2.2 获取软件包的版本情况
+
+通过查看项目地址获悉当前项目的最新稳定版本列表。
+
+可以通过以下几种方式查看:
+
+- debian/watch 文件
+
+在2.1.4小节中如果软件包的有debian/watch文件,可以查看该项目的上游软件包压缩包下载地址。
+
+```
+!其下载地址中可能有beta版本,其名字类似于xxxx-beta.tar.gz。一般这种beta版本的源码不应该被选择。
+```
+
+- git仓库
+
+如果是git仓库,可以查看其对应的是否有发布 git release:
+
+1. 如果有,那么可以在git release页面获取其版本列表
+
+2. 如果没有,查看其对应的`branch(分支)`、`tag(标记)`是否有相关版本列表信息
+
+
+
+# 二、构建源码包
+
+从第一章节中选出待构建软件包的版本以及下载地址。
+
+如果远端仓库已有项目,需要变更upstream版本,那么请查看第4小节的内容。
+
+## 1. 下载源码并修改源码目录格式
+
+下载源码包到本地,并解压缩
+
+```Bash
+# 下载源码
+wget https://www.netfilter.org/pub/libnftnl/libnftnl-1.2.3.tar.bz2
+
+# 解压缩
+tar -xaf libnftnl-1.2.3.tar.bz2
+```
+
+修改源码目录,使其符合**-**格式。如:
+
+```Bash
+$ ls -al
+drwxr-x---@ - luzp 10 8月 02:24 libnftnl-1.2.3
+.rw-rw----@ 395k luzp 10 8月 02:24 libnftnl-1.2.3.tar.bz2
+```
+
+## 2. 构建出debian打包目录
+
+### 2.1 upstream源码包含debian目录
+
+```
+!注意:如果上游源码目录中包含debian目录,此时我们需要手动对上游的debian目录进行改名,避免我们再重新生成debian目录时引起别的问题
+```
+
+- 备份原有的debian目录
+
+```Bash
+mv debian debian-orig
+```
+
+- 重新构建debian目录
+
+```Bash
+debmake -u -r <修订版本号> -t
+```
+
+此时,会在源码的同级目录新创建个目录,其格式为<原来的源码目录名称>-
+
+假如:
+
+源码压缩包是`amdgcn-tools-13.tar.gz`
+
+```Bash
+# 解压源码
+# 解压后的源码目录为amdgcn-tools-13
+tar -xaf amdgcn-tools-13.tar.gz
+
+# 进入源码目录,并备份原来的debian目录
+cd amdgcn-tools-13
+mv debian debian-orig
+
+# 重新构建debian目录
+debmake -u13 -rok1 -t
+
+# 执行完成之后,会在amdgcn-tools-13同级目录生成一个新的目录
+# <原来的源码目录>-,也就是下面的目录
+ls amdgcn-tools-13-13
+```
+
+### 2.2 直接构建debian目录
+
+如果上游源码是纯源码,那么直接构建debian目录即可。
+
+```Bash
+# 构建debian目录
+debmake -z tar.bz2
+```
+
+- -z 指定源码的压缩包格式
+ - libnftnl-1.2.3.tar.bz2 就指定为 -z tar.bz2
+
+ - 默认的源码压缩格式是tar.gz
+
+- -b 如果是perl或python的源码包可以指定该参数,为debmake创建出更多配套对应编程语言的文件
+
+```Bash
+# 如果是python
+debmake -b":python3"
+
+# perl
+debmake -b":perl"
+```
+
+- -t 重新生成上游源码包(即xxx.orig.tar.gz)
+
+更详细的debmake用法可以查看其man手册
+
+```Bash
+man debmake
+```
+
+## 3. 修改构建规则
+
+主要是修改debian目录中的文件。
+
+### 3.1 control
+
+`control`文件涉及两个部分的内容:
+
+#### 3.1.1 源码包部分
+
+描述当前这个源码包的简要信息,以及构建该源码包的编译依赖等
+
+其中有几个字段需要注意:
+
+- **Section**
+
+描述软件包的类型,用于软件包的分类。比如`mysql-8`应属于`database`
+
+可选的内容有:
+
+admin, cli-mono, comm, database, debug, devel, doc, editors, education, electronics, embedded, fonts, games, gnome, gnu-r, gnustep, graphics, hamradio, haskell, httpd, interpreters, introspection, java, javascript, kde, kernel, libdevel, libs, lisp, localization, mail, math, metapackages, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, rust, science, shells, sound, tasks, tex, text, utils, vcs, video, web, x11, xfce, zope
+
+- **Priority**
+ - 软件包的优先级
+
+ - required 系统必须的包
+ - important 重要的软件包,系统非必须的包,但是希望系统中最好能预装的
+ - standard 标准相对独立的软件包
+ - optional 这是默认优先级选项,除非这个软件包是系统必须的包,否则应该使用该选项
+
+- **Maintainer**
+
+需要写成当前openkylin负责该软件包的sig组,如`packaging sig`组的写成`Openkylin Developers `
+
+- **Vcs-Browser**:
+
+写成对应的gitee仓库地址, 如 https://gitee.com/openkylin/autoconf
+
+- **Vcs-Git**
+
+写成对应的gitee仓库git地址 ,如 https://gitee.com/openkylin/autoconf.git
+
+- **Build-Depends和**
+
+编译体系结构相关代码所需要的编译依赖
+
+- **Build-Depends-Indep**
+
+编译体系结构无关的代码所需要的编译依赖
+
+对于**Build-Depends**和**Build-Depends-Indep**可以从项目地址中查找是否有相关编译依赖说明。
+
+---
+**注意:** 如果control文件参考了其他OS发行版的规则,需要去除或替换其他OS版本中的版本号规则,例如:
+
+```
+Build-Depends:
+ pkg1 (>= 1.0.0-0ubuntu1),
+ pkg1 (< 1.2.0-1debian2),
+ pkg2 (> 1.0.0.build),
+ pkg3 (> 2.0ubuntu19)
+```
+
+首先,需要明确对于quilt格式的版本号其一般带有"-",格式为`-`,而native格式的源码包一般不包含"-"
+
+修改流程可以分两步进行
+
+**第一步:**
+
+对于quilt格式的版本,pkg1中的版本号 1.0.0-0ubuntu1 和 1.2.0-1debian2 其包含特定OS发行版的版本号,因此要修改。也就变成:
+
+```
+pkg1 (>= 1.0.0),
+pkg1 (< 1.2.0),
+```
+
+对于native格式的版本号,首先需要确定其upstream版本,对于pkg2和pkg3:
+
+(1)尝试找到pkg2的1.0.0版本,如果能找到,那么1.0.0就是upstream版本,其编译依赖改为:pkg2 (> 1.0.0);同理pkg3
+
+(2)如果找不到pkg2的upstream版本,此外当前版本号没有包含其他OS发行版名称,那么可以保留(因为使用source-package工具重打包源码,其upstream版本号也就是当前的版本号);但是对于pkg3,如果pkg3是OS自研的(其源码名称一般也包含OS名称,例如ubuntu-keyring),那么此时可以将此包重新改名,由openkylin重新维护,对应源码名称改为openkylin-keyring,版本号也重新制定,例如可以制定为1:1.0.0;如果不是OS自研包,最好我们也重新制定版本号,按我们自己的版本号去维护,可以内部讨论,例如这里也指定为1:1.0.0。**注意这里,最好要使用:格式的版本号,其表明带有:的版本号总会比不带的版本号高。**
+
+那么,对于pkg2,pkg3,其修改为:
+
+```
+pkg2 (> 1.0.0.build),
+pkg3 (> 1:1.0.0)
+```
+
+**第二步(native格式的不用处理):**
+
+第二步是在第一步的基础上改进。总体上我们要明确其他OS发行版中-横线后面的修订版本的内容。
+
+对于-,一般来说每个revision是修复了某个bug、安全漏洞等。对于ubuntu,每个revision都是由几个patch组成。
+
+因此对于pkg1 (>= 1.0.0-0ubuntu1),其明确规定是0ubuntu1修订版本之后的才能使用,也就意味着使用pkg1的1.0.0版本是存在风险的,最直接的现象就是编译不通过。
+
+因此,这就需要结合我们实际的pkg1的版本情况来:
+
+(1)如果仓库存在pkg1,其版本为1.0.0-ok1。为了保证上述编译能通过,需要集成ubuntu的1.0.0-0ubuntu1中的patch。如果已经集成相关patch,那么编译依赖就变成:
+
+```
+pkg1 (>= 1.0.0-ok1),
+pkg1 (< 1.2.0),
+```
+
+集成了patch之后仓库中的pkg1版本变为1.0.0-ok2。那么在编译依赖的地方就变成:
+
+```
+pkg1 (>= 1.0.0-ok2),
+pkg1 (< 1.2.0),
+```
+
+(2)如果仓库不存在pkg1,那么我们首次自主选型构建时,选型的版本最好是在1.0.0~1.2.0 之间选择,保证能满足各个依赖包的编译依赖。
+
+上面所说,都是基于编译依赖来处理。同理二进制包的安装依赖字段如果也指定了版本号,那么处理方式也是和上面的一样。
+
+#### 3.1.2 二进制包部分
+
+描述当前源码包可以被分为哪些二进制包程序。
+
+常见的分包类型为:
+
+- lib
+
+共享库,其二进制包包名一般为 `lib-xxx`
+
+- dev
+
+共享库头文件及相关开发文件,其二进制包名一般为`lib-xxx-dev`
+
+- doc
+
+软件包的文档
+
+如果其文档对应的是某个可执行程序的文档,其二进制包包名一般为`xxx-doc`
+
+如果其文档是某个开发库的文档,其二进制包包名一般为`lib-xxx-doc`
+
+- bin
+
+软件包的二进制程序,如编译型语言(比如c/c++)的二进制程序,以及解释型编程语言(比如python、perl)的可执行程序,其二进制包包名一般为其对应的二进制程序名称
+
+这个分包时,可以结合`debmake`在构建`debian`打包目录时一起使用,如:
+
+```Bash
+# 软件包名称为 foo , 其提供二进制程序与二进制程序的文档
+debmake -b"foo:bin,foo-doc:doc"
+
+# 软件包名称为 libfoo , 是一个开发库源码,其提供开发库与开发库的文档
+debmake -b"libfoo:lib,libfoo-doc:doc"
+
+# 执行完之后,会自动将各个二进制包信息模板写入到debian/control文件中
+```
+
+### 3.2 rules
+
+软件包的编译构建规则
+
+### 3.3 changelog
+
+修改软件包的版本号,格式为:-
+
+一般来说,对于openkylin社区,使用`ok1`作为第一次revisions,如:
+
+```Bash
+autoconf (2.71-ok1) yangtze; urgency=low
+
+ * Build for openKylin.
+
+ -- Lu zhiping Fri, 26 Aug 2022 15:25:09 +0800
+```
+
+### 3.4 source/format
+
+必须将源码包的格式设为`quilt`格式
+
+```Bash
+echo "3.0 (quilt)" > debian/source/format
+```
+
+```Bash
+echo "3.0 (quilt)" > debian/source/format
+```
+
+### 3.5 其他文件
+
+xxx.install
+
+xxx.doc
+
+xxx.symbols
+
+xxx.manpages
+
+### 3.6 应用其他OS发行版的补丁
+
+如果其他OS发行版有该软件包的补丁,那么我们需要分析考虑是否应用他们的补丁。
+
+可以先从以下方面去考虑是否应用其他OS发行版的补丁:
+
+- 补丁的修复内容是什么?补丁没能被上游社区吸收的原因,是否是无关紧要的补丁?
+
+- 是否是以前的旧版本才有的补丁,新版本是否已经集成?
+
+- 是否是重大漏洞修复补丁?
+
+- 是否是特定OS发行版才需要的补丁?
+
+- 如果不应用补丁是否出现编译问题,安装是否有问题?
+
+```
+而且,应用上游社区的patches最好是在构建出git仓库之后再应用patches,这样能在git commit中保留上游社区patch的信息
+```
+
+下面的内容是在第五章节构建出git仓库之后应用patch的步骤:
+
+如果需要应用上游社区的patch,最好是保留他们patch信息的内容与作者信息等。可以通过git工具直接应用上游社区的patch:
+
+- git am应用patch
+
+git am应用patch会自动保留patch的信息
+
+```Bash
+git am xxxx.patch
+```
+
+- git apply应用patch
+
+但是有些patch的信息格式不是完全适用于git am,那么可以使用git apply导入patch,然后再进行commit添加patch信息
+
+```Bash
+# 导入patch信息
+git apply xxx.patch
+
+# 添加改动
+git add .
+
+# 在编辑框中填写patch的相关信息,如
+# patch的作者,patch的内容等
+git commit
+```
+
+导入patch之后,想对新导入patch的内容进行编译测试,那么可以使用gbp工具来生成新的源码(新的dsc文件)
+
+```Bash
+# 修改changelog新增版本号
+vim debian/changelog
+
+# 编译源码,会生成新的dsc文件
+gbp buildpackage -S -sa -nc --git-prisine-tar --git-ignore-branch
+```
+
+## 4. 导入上游upstream源码
+
+如果远端仓库已有项目,需要变更upstream版本。
+
+(1)从上游社区下载源码压缩包
+
+(2)对源码压缩包重新加压缩使其符合`_.orig.tar.[gz|xz|bz2]`格式
+
+```Bash
+#例如:
+# 从上游源码社区获取的源码压缩包为 requests-2.27.1.tar.gz
+# 首先解压源码
+tar -xaf requests-2.27.1.tar.gz
+
+# 修改源码目录为 -
+# 假如从上游社区的源码压缩包解压出来的目录是requests
+mv requests requests-2.27.1
+
+# 重新压缩,使其符合 _.orig.tar.[gz|xz|bz2]
+tar -czf requests-2.27.1 requests-2.27.1.orig.tar.gz
+```
+
+(3)克隆gitee远端仓库源码到本地,进入源码目录
+
+```Bash
+# 克隆远端仓库
+git clone git@gitee.com:openkylin/requests.git
+
+# 进入源码目录
+cd requests
+```
+
+(4)变更upstream源码
+
+参考[openKylin源码包git工作流](openKylin源码包git工作流.md) 的第六章节《更新upstream版本》
+
+- a. 导入上游upstream版本(第二步生成的压缩包)
+
+- - ```Bash
+ gbp import-orig requests-2.27.1.orig.tar.gz --no-merge --pristine-tar --upstream-branch=upstream
+ git checkout upstream
+ git push
+ git push --tags
+ ```
+
+- b. 筛选旧版本patch (结合[openKylin源码包git工作流](openKylin源码包git工作流.md) 6.3.3小节进行)
+
+- - 如果patch是研发的patch,那么需要与相关研发确认该patch在新的upstream源码中是否还需要
+ - 如果patch是其他OS发行版的patch,那么需要结合OS发行版的最新版本源码中确认是否还需要该patch
+
+- c. 引入其他OS发行版的patch
+
+- - 可以参考3.6小节《应用其他OS发行版的补丁》。
+
+ - 使用git am或git apply 或其他方式导入其他OS发行版的patch
+
+- d. 修改debian目录的其他编译构建文件
+
+- - debian/control
+ - debian/changelog 需保留原有的changelog信息
+ - debian/rules
+ - deiban/其他文件
+
+修改完成之后,可以按第5小节,先本地编译测试,测试无问题后再推送到远端仓库上。
+
+## 5. 编译源码包
+
+完成对debian目录构建规则的完善之后,先基于此编译一轮源码包。会生成dsc文件
+
+```Bash
+# 切到开发分支上
+git checkout openkylin/yangtze
+# 在源码目录执行
+dpkg-source -b .
+```
+
+
+
+# 三、编译
+
+根据上一章节的内容构建出源码包之后,进行编译。
+
+可以下载一个openkylin的chroot环境,在chroot环境中进行编译调试。
+
+x86的chroot:http://files.build.openkylin.top/51159/chroot-openkylin-yangtze-amd64.tar.gz
+
+riscv的chroot: http://files.build.openkylin.top/51197/chroot-openkylin-yangtze-riscv64.tar.gz
+
+在这一阶段会对debian打包目录中的打包构建规则进行不断的修改和优化,直至打包出一个完整可安装的二进制包。
+
+
+
+# 四、安装测试
+
+简单测试编译出的二进制程序是否可安装,安装之后系统是否正常等
+
+
+
+# 五、构建git仓库
+
+## 1. 创建gitee仓库
+
+fork openkylin的community仓库
+
+```Bash
+# fork到个人仓库之后,克隆个人仓库到本地
+git clone git@gitee.com:/community.git
+
+# 然后在对应的sig组sig.yaml文件中添加源码包名称
+# 例如为packaging sig新增软件包,source-name 需写实际的软件包名称
+echo "- " >> sig/packaging/sig.yaml
+
+# 然后提交改动,推送到个人仓库
+git add sig/packaging/sig.yaml
+git commit -m "新增xxx软件包"
+git push origin master
+```
+
+在gitee网页端创建PR,然后由community项目负责人审查,审查通过后CI平台会自动创建对应的git仓库
+
+## 2. 构建git仓库
+
+对第二章节构建出来的源码包进行git仓库的构建。
+
+- 下载工具
+
+按照[source-packaging](https://gitee.com/openkylin/packaging-tools#源码反向构建工具-source-packing)工具的使用方法下载工具和相关依赖的安装
+
+- 构建git仓库
+
+```Bash
+./source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch openkylin/yangtze
+```
+
+更详细的git工作流可以参考[openKylin源码包git工作流](openKylin源码包git工作流.md)
+
+## 3. 关联远端仓库,并推送到gitee
+
+需要包在第三章节编译、第四章节安装测试没问题了之后,才推送到gitee仓库上
+
+```Bash
+# 进入到第二步构建出的源码仓库
+cd sqlite3
+# 关联远端仓库并推送到远端仓库
+git remote add origin git@gitee.com:openkylin/sqlte3.git
+git push --all && git push --tags
+```
+
+
+
+# 六、其他内容
+
+1. gitee的ci流程简要描述:
+
+```Bash
+1. 软件包第一次推送:
+maintainer首次将包通过push的方式推送到gitee的仓库上,此时ci平台会将其打包发送到okbs编译平台进行编译,当前的编译地址是(https://build.openkylin.top/~cibot/+archive/openkylin/citest/+packages)
+
+2. 后续的修改贡献:
+开发者需要fork仓库到个人仓库中,然后在个人仓库上进行开发修改,源码修改完毕后再修改changelog新增版本号,然后提交PR到原始仓库。
+
+maintainer审查PR,PR审查通过后,CI平台自动对当前的PR进行打包发送到OKBS编译平台进行编译,编译结果将会以评论的方式添加到对应的PR中,maintainer根据编译结果以及CI平台的门禁检查结果来考虑是否接收该PR
+```
+
+2. 各发行版源地址,以gvfs为例:
+
+Debian 11: https://tracker.debian.org/pkg/gvfs
+
+Ubuntu 22.04: https://launchpad.net/ubuntu/+source/gvfs
+
+Fedora 36: https://src.fedoraproject.org/rpms/gvfs
+
+Arch: https://archlinux.org/packages/extra/x86_64/gvfs/
+
+Deepin: https://ftp.sjtu.edu.cn/deepin/pool/
+
+openEuler: https://gitee.com/src-openeuler/gvfs
diff --git a/05_社区贡献/开发指南/openKylin系统输入法适配指南.md b/04_社区贡献/开发指南/openKylin系统输入法适配指南.md
old mode 100755
new mode 100644
similarity index 100%
rename from 05_社区贡献/开发指南/openKylin系统输入法适配指南.md
rename to 04_社区贡献/开发指南/openKylin系统输入法适配指南.md
diff --git a/05_社区贡献/开发指南/openKylin软件包版权协议补充指南.md b/04_社区贡献/开发指南/openKylin软件包版权协议补充指南.md
similarity index 100%
rename from 05_社区贡献/开发指南/openKylin软件包版权协议补充指南.md
rename to 04_社区贡献/开发指南/openKylin软件包版权协议补充指南.md
diff --git a/05_社区贡献/开发指南/riscv上安装openKylin.md b/04_社区贡献/开发指南/riscv上安装openKylin.md
similarity index 98%
rename from 05_社区贡献/开发指南/riscv上安装openKylin.md
rename to 04_社区贡献/开发指南/riscv上安装openKylin.md
index de231cc7..415285c7 100644
--- a/05_社区贡献/开发指南/riscv上安装openKylin.md
+++ b/04_社区贡献/开发指南/riscv上安装openKylin.md
@@ -309,6 +309,39 @@ openkylin适配VisionFive 2的镜像可以通过以下链接下载
此命令假设您已将 SD 卡插入开发板的 SD 卡插槽中。 如果您使用的是 USB 读卡器,它可能会显示为 /dev/sdb 或类似的内容而不是 /dev/mmcblk0
+## 烧录后分配SD卡剩余空间
+
+先使用fdisk命令查看sd卡分区情况
+
+> fdisk -l
+
+
+> fdisk /dev/mmcblk1
+
+删除分区4
+
+> d
+
+> 4
+
+新建分区4,大小为剩余空间
+
+> n
+
+> 4
+
+不移除签名
+
+> N
+
+写入修改
+
+> w
+
+调整分区大小
+
+> resize2fs /dev/mmcblk1p4
+
## 通过NVMe启动
首先使用磁盘工具将NVMe硬盘格式化。
之后通过命令行将镜像刷入NVMe硬盘,请运行:
@@ -320,7 +353,7 @@ openkylin适配VisionFive 2的镜像可以通过以下链接下载
注意:要非常小心上述命令中的“of”参数。 如果使用了错误的磁盘,您可能会丢失数据。也可通过磁盘工具的回复磁盘映像功能来将镜像刷入SD卡或NVMe硬盘。
-## 烧录后分NVMe硬盘剩余空间
+## 烧录后分配NVMe硬盘剩余空间
执行以下命令将NVMe硬盘剩余空间分配到根分区。
注:此命令假设您sd卡的设备号为/dev/sdb,分盘时请根据实际的设备号进行分盘。
> sudo apt install cloud-utils
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64修改密码.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64修改密码.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64修改密码.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64修改密码.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64安装gparted.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64安装gparted.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64安装gparted.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64安装gparted.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64完成分区调整应用.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64完成分区调整应用.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64完成分区调整应用.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64完成分区调整应用.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64拉动调整分区.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64拉动调整分区.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64拉动调整分区.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64拉动调整分区.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64控制面板特效关闭.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64控制面板特效关闭.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64控制面板特效关闭.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64控制面板特效关闭.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64桌面-embedded.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64桌面-embedded.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64桌面-embedded.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64桌面-embedded.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64烧录程序SD卡选择.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64烧录程序SD卡选择.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64烧录程序SD卡选择.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64烧录程序SD卡选择.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64烧录程序安装地址.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64烧录程序安装地址.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64烧录程序安装地址.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64烧录程序安装地址.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64烧录程序镜像选择.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64烧录程序镜像选择.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64烧录程序镜像选择.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64烧录程序镜像选择.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64电源取消休眠与关闭显示器.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64电源取消休眠与关闭显示器.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64电源取消休眠与关闭显示器.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64电源取消休眠与关闭显示器.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64登录界面-embedded.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64登录界面-embedded.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64登录界面-embedded.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64登录界面-embedded.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64确定调整分区对应磁盘.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64确定调整分区对应磁盘.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64确定调整分区对应磁盘.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64确定调整分区对应磁盘.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64调整分区后点击应用.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64调整分区后点击应用.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64调整分区后点击应用.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64调整分区后点击应用.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64选择调整分区大小.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64选择调整分区大小.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64选择调整分区大小.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在arm设备上安装_common/arm64选择调整分区大小.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64双椒派串口信息.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64双椒派串口信息.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64双椒派串口信息.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64双椒派串口信息.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64双椒派接线方式.jpg b/04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64双椒派接线方式.jpg
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64双椒派接线方式.jpg
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64双椒派接线方式.jpg
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64双椒派板卡信息.jpg b/04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64双椒派板卡信息.jpg
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64双椒派板卡信息.jpg
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64双椒派板卡信息.jpg
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64电源取消休眠与关闭显示器-embedded.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64电源取消休眠与关闭显示器-embedded.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64电源取消休眠与关闭显示器-embedded.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64电源取消休眠与关闭显示器-embedded.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64空间resize-embedded.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64空间resize-embedded.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64空间resize-embedded.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64空间resize-embedded.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64空间不足-embedded.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64空间不足-embedded.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64空间不足-embedded.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在chilliepi(双椒派)上安装openKylin/arm64空间不足-embedded.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64coolpi接线方式.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在coolpi上安装openKylin/arm64coolpi接线方式.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64coolpi接线方式.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在coolpi上安装openKylin/arm64coolpi接线方式.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64树莓派接线方式.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在树莓派上安装openKylin/arm64树莓派接线方式.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64树莓派接线方式.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在树莓派上安装openKylin/arm64树莓派接线方式.png
diff --git a/05_社区贡献/开发指南/assets/arm64系统安装/arm64选择wayland方式登录.png b/04_社区贡献/开发指南/在arm设备上安装/assets/在树莓派上安装openKylin/arm64选择wayland方式登录.png
similarity index 100%
rename from 05_社区贡献/开发指南/assets/arm64系统安装/arm64选择wayland方式登录.png
rename to 04_社区贡献/开发指南/在arm设备上安装/assets/在树莓派上安装openKylin/arm64选择wayland方式登录.png
diff --git a/04_社区贡献/开发指南/在arm设备上安装/在chilliepi(双椒派)上安装openKylin.md b/04_社区贡献/开发指南/在arm设备上安装/在chilliepi(双椒派)上安装openKylin.md
new file mode 100644
index 00000000..9f92ae17
--- /dev/null
+++ b/04_社区贡献/开发指南/在arm设备上安装/在chilliepi(双椒派)上安装openKylin.md
@@ -0,0 +1,82 @@
+## 一.镜像下载
+
+通过以下链接下载:
+
+https://www.openkylin.top/downloads
+
+下载得到 openKylin-1.0-chilliepi-arm64.img.xz 文件
+
+## 二. 板卡信息
+
+### 1. 接口信息
+
+上安装openKylin/arm64双椒派板卡信息.jpg)
+
+### 2. 串口信息
+
+上安装openKylin/arm64双椒派串口信息.png)
+
+## 三.镜像烧录
+
+注意:**双椒派上推荐使用金士顿 SD 卡**
+
+### 方法 1: 使用 dd 命令
+
+- 烧录镜像
+ ```
+ xz -k -d -v openKylin-1.0-chilliepi-arm64.img.xz
+ sudo dd if=openKylin-1.0-chilliepi-arm64.img of=/dev/ status=progress
+ ```
+
+### 方法 2: 使用 rpi-imager 工具
+
+烧录程序安装:https://www.raspberrypi.com/software/
+
+
+
+插入 SD 卡,打开 rpi-imager,选择自定义镜像,然后选择镜像文件
+
+
+
+选择 SD 卡,点击 WRITE,等待制作完成
+
+
+
+## 四. chilliepi 上启动 openkylin
+
+- 连接好键盘鼠标;插好 SD 卡;将 chilliepi 开发板通过 DP 线与显示器连接,建议通过电缆直连支持 DP 接口的显示器,如果通过转换器可能出现不兼容无显示的情况
+ 上安装openKylin/arm64双椒派接线方式.jpg)
+- 通过串口连接开发板,插上电源, 快速按任意键, 使其进入到 u-boot 命令行界面
+- 设置 U-boot 启动参数
+ ```sh
+ setenv bootargs console=ttyAMA1,115200 audit=0 earlycon=pl011,0x2800d000 root=/dev/mmcblk1p2 rootdelay=3 rw;
+ setenv bootcmd 'mmc dev 1;fatload mmc 1:1 0x90000000 e2000d-chilli.dtb;fatload mmc 1:1 0x90100000 Image;booti 0x90100000 - 0x90000000;'
+ saveenv
+ ```
+- 拔下电源, 拔下 SD 卡;插上 SDCard, 再插上电源, 即可启动系统。默认用户名/密码是
+ ```
+ > username:openkylin
+ > password:openkylin
+ ```
+
+
+
+
+## 五.其他事项
+
+### 1.磁盘大小
+
+制作镜像的时候,默认的根分区大小是在文件系统大小的基础上额外加了一些空间,如果出现磁盘空间不足的情况
+上安装openKylin/arm64空间不足-embedded.png)
+
+可以使用如下命令调整一下根分区大小,打开终端,执行如下命令可以将根分区扩展到最大
+```sh
+sudo resize-assistant
+```
+上安装openKylin/arm64空间resize-embedded.png)
+
+### 2.关闭显示器或休眠后唤醒黑屏
+
+建议用户在控制面板的电源里设置从不关闭显示器与电源,可避免该问题
+
+上安装openKylin/arm64电源取消休眠与关闭显示器-embedded.png)
\ No newline at end of file
diff --git a/04_社区贡献/开发指南/在arm设备上安装/在coolpi上安装openKylin.md b/04_社区贡献/开发指南/在arm设备上安装/在coolpi上安装openKylin.md
new file mode 100644
index 00000000..9b367144
--- /dev/null
+++ b/04_社区贡献/开发指南/在arm设备上安装/在coolpi上安装openKylin.md
@@ -0,0 +1,93 @@
+## 一.镜像下载
+
+通过以下链接下载:
+
+https://www.openkylin.top/downloads
+
+下载后右键解压得到.img文件,xz后缀的镜像文件则可以不用解压直接使用
+
+
+
+## 二.镜像烧录
+
+烧录程序安装:https://www.raspberrypi.com/software/
+
+
+
+
+插入SD卡,打开rpi-imager,选择自定义镜像,然后选择安装好的.img镜像文件
+
+
+
+
+选择SD卡,点击WRITE,等待制作完成
+
+
+
+
+
+## 三.coolpi openkylin启动
+
+接好coolpi开发板的电源线、显示器线,连接好键盘鼠标,插好SD卡
+
+
+coolpi启动时,可能存在一直黑屏的状态,或突然进入一个有问题的kylin操作系统(这是由于coolpi板子加载SD卡出错导致),插拔电源线重新启动即可
+
+
+进入到登录界面,点击登录,即可登录到桌面
+
+
+
+
+
+
+## 四.其他事项
+### 1.系统卡顿
+
+该问题由窗管占用cpu率较高导致,进入桌面后,到控制面板关闭特效模式,可以使得卡顿能够有效缓解
+
+
+
+
+### 2.修改密码
+
+由于系统没有引导安装,因此刚装完的系统是没有设置密码的,需要用户自己装机后手动配置一遍密码,以便于使用系统时遇到需要输入密码的场景
+
+
+
+
+### 3.磁盘分区
+
+制作镜像的时候,默认的分区大小是镜像的大小,因此装机后可能需要用户手动调整一下分区大小
+
+首先连接网络,右键桌面打开终端,sudo apt update更新源后安装gparted程序
+
+
+
+
+终端运行gparted,首先确立调整的磁盘是否正确
+
+
+
+
+选中writable分区,然后点击菜单栏的分区,选择调整分区大小
+
+
+
+
+拉动箭头调整分区,可以拉到最大,也可以调整合适大小,然后点击调整大小按钮
+
+
+
+
+点击应用全部操作,完成分区调整
+
+
+
+
+
+### 4.关闭显示器或休眠后唤醒黑屏
+
+建议用户在控制面板的电源里设置从不关闭显示器与电源,可避免该问题
+
+
\ No newline at end of file
diff --git a/04_社区贡献/开发指南/在arm设备上安装/在树莓派上安装openKylin.md b/04_社区贡献/开发指南/在arm设备上安装/在树莓派上安装openKylin.md
new file mode 100644
index 00000000..66a751d2
--- /dev/null
+++ b/04_社区贡献/开发指南/在arm设备上安装/在树莓派上安装openKylin.md
@@ -0,0 +1,93 @@
+## 一.镜像下载
+
+通过以下链接下载:
+
+https://www.openkylin.top/downloads
+
+下载后右键解压得到.img文件,xz后缀的镜像文件则可以不用解压直接使用
+
+
+## 二.镜像烧录
+
+烧录程序安装:https://www.raspberrypi.com/software/
+
+
+
+
+插入SD卡,打开rpi-imager,选择自定义镜像,然后选择安装好的.img镜像文件
+
+
+
+
+选择SD卡,点击WRITE,等待制作完成
+
+
+
+
+
+## 三.树莓派openkylin启动
+
+接好树莓派的电源线、显示器线,连接好键盘鼠标,插好SD卡
+
+
+树莓派启动时,可能存在一直黑屏的状态,插拔电源线重新启动即可
+
+
+进入到登录界面,在右下角选择ukui-Wayland的方式,然后点击登录,即可登录到桌面(由于该镜像缺少x11相关包,因此无法使用kwin-x11进入桌面)
+
+
+
+
+
+
+
+## 四.其他事项
+### 1.系统卡顿
+
+该问题由窗管占用cpu率较高导致,进入桌面后,到控制面板关闭特效模式,可以使得卡顿能够有效缓解
+
+
+
+
+### 2.修改密码
+
+由于系统没有引导安装,因此刚装完的系统是没有设置密码的,需要用户自己装机后手动配置一遍密码,以便于使用系统时遇到需要输入密码的场景
+
+
+
+
+### 3.磁盘分区
+
+制作镜像的时候,默认的分区大小是镜像的大小,因此装机后可能需要用户手动调整一下分区大小
+
+首先连接网络,右键桌面打开终端,sudo apt update更新源后安装gparted程序
+
+
+
+
+终端运行gparted,首先确立调整的磁盘是否正确
+
+
+
+
+选中writable分区,然后点击菜单栏的分区,选择调整分区大小
+
+
+
+
+拉动箭头调整分区,可以拉到最大,也可以调整合适大小,然后点击调整大小按钮
+
+
+
+
+点击应用全部操作,完成分区调整
+
+
+
+
+
+### 4.关闭显示器或休眠后唤醒黑屏
+
+建议用户在控制面板的电源里设置从不关闭显示器与电源,可避免该问题
+
+
\ No newline at end of file
diff --git a/04_社区贡献/开发指南/在arm设备上安装/在飞腾派上安装openKylin.md b/04_社区贡献/开发指南/在arm设备上安装/在飞腾派上安装openKylin.md
new file mode 100644
index 00000000..b5831c13
--- /dev/null
+++ b/04_社区贡献/开发指南/在arm设备上安装/在飞腾派上安装openKylin.md
@@ -0,0 +1,41 @@
+## 一.镜像下载
+
+通过以下链接下载:
+
+- 4G版本: https://www.openkylin.top/downloads/download-smp.php?id=39
+- 2G版本: https://www.openkylin.top/downloads/download-smp.php?id=40
+
+根据个人需要下载对应的版本,下面以2G版本为例说明,下载得到 openKylin-1.0.1-phytiumpi-2G-arm64.img.xz 文件
+
+## 二.镜像烧录
+
+### 方法 1: 使用 dd 命令
+
+- 烧录镜像
+ ```
+ xz -k -d -v openKylin-1.0.1-phytiumpi-2G-arm64.img.xz
+ sudo dd if=openKylin-1.0.1-phytiumpi-2G-arm64.img of=/dev/ status=progress
+ ```
+
+### 方法 2: 使用 rpi-imager 工具
+
+烧录程序安装:https://www.raspberrypi.com/software/
+
+
+
+插入 SD 卡,打开 rpi-imager,选择自定义镜像,然后选择镜像文件
+
+
+
+选择 SD 卡,点击 WRITE,等待制作完成
+
+
+
+## 三. 启动系统
+
+- 插上 SDCard, 插上电源, 启动系统,默认用户名/密码是
+
+```
+> username:openkylin
+> password:openkylin
+```
diff --git a/05_社区贡献/开发指南/应用移植指南/移植openKylin应用到其他Linux发行版教程.md b/04_社区贡献/开发指南/应用移植指南/移植openKylin应用到其他Linux发行版教程.md
similarity index 100%
rename from 05_社区贡献/开发指南/应用移植指南/移植openKylin应用到其他Linux发行版教程.md
rename to 04_社区贡献/开发指南/应用移植指南/移植openKylin应用到其他Linux发行版教程.md
diff --git a/05_社区贡献/开发指南/应用移植指南/移植windows应用到openKylin教程.md b/04_社区贡献/开发指南/应用移植指南/移植windows应用到openKylin教程.md
similarity index 100%
rename from 05_社区贡献/开发指南/应用移植指南/移植windows应用到openKylin教程.md
rename to 04_社区贡献/开发指南/应用移植指南/移植windows应用到openKylin教程.md
diff --git a/05_社区贡献/开发指南/应用移植指南/移植移动应用到openKylin教程.md b/04_社区贡献/开发指南/应用移植指南/移植移动应用到openKylin教程.md
similarity index 100%
rename from 05_社区贡献/开发指南/应用移植指南/移植移动应用到openKylin教程.md
rename to 04_社区贡献/开发指南/应用移植指南/移植移动应用到openKylin教程.md
diff --git a/05_社区贡献/开发指南/本地编译Pytorch.md b/04_社区贡献/开发指南/本地编译Pytorch.md
similarity index 97%
rename from 05_社区贡献/开发指南/本地编译Pytorch.md
rename to 04_社区贡献/开发指南/本地编译Pytorch.md
index 6e330493..8235f32d 100644
--- a/05_社区贡献/开发指南/本地编译Pytorch.md
+++ b/04_社区贡献/开发指南/本地编译Pytorch.md
@@ -1,333 +1,333 @@
-### 本地编译Pytorch
-### **获取源代码**
-链接:https://pan.baidu.com/s/1-kaWPzqAb6g7l4Bdhh-KPw?pwd=843d
-
-提取码:843d
-
-源码包为原始pytorch仓库的完整克隆,克隆日期为2月20日,需要最新版本的请自行拉取
-### **修改源代码**
-##### **荔枝派和算能开发板**
-对于荔枝派和算能的硬件环境,需要将源代码目录中的 pytorch/third_party/cpuinfo目录替换为算能的cpuinfo目录,具体如下
-```
-cd pytorch/third_party
-# 删除原有cpuinfo目录
-sudo rm -r cpuinfo
-# 克隆算能的cpuinfo目录
-sudo git clone https://github.com/sophgo/cpuinfo.git
-
-```
-##### **其他硬件环境**
-对于其他硬件环境,可以暂时不替换cpuinfo目录,建议替换
-##### **修改代码文件**
-**1.aten/src/ATen/CMakeLists.txt**
-
-将语句:
-```
-if(NOT MSVC AND NOT EMSCRIPTEN AND NOT INTERN_BUILD_MOBILE)
-
-```
-替换为:
-```
-if(FALSE)
-```
-**2.caffe2/CMakeLists.txt**
-
-将语句:
-```
-target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 sleef gtest_main)
-```
-
-替换为:
-```
-target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 gtest_main)
-```
-**3.test/cpp/api/CMakeLists.txt**
-
-在语句:
-```
-add_executable(test_api ${TORCH_API_TEST_SOURCES})
-```
-后添加:
-```
-target_compile_options(test_api PUBLIC -Wno-nonnull)
-```
-### **编译工具链安装**
-```
-apt install libopenblas-dev libblas-dev m4 cmake cython3 ccache
-
-# 若执行过程中有以下报错,则杀死10198进程:Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 10198 (apt)
-kill -9 10198
-
-# 安装过程中,若发现libopenblas-dev无法正常安装,则跳过其直接安装libblas-dev m4 cmake cython3 ccache
-apt install libblas-dev m4 cmake cython3 ccache
-
-# libopenblas-dev无法安装的替代方案:手动安装OpenBLAS
-git clone https://github.com/xianyi/OpenBLAS.git
-cd OpenBLAS
-make -j8
-sudo make PREFIX=/usr/local/OpenBLAS install
-# 进入/etc,用vim打开profile
-[在最后一行添加]: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/OpenBLAS/lib/
-source /etc/profile
-
-```
-### Python环境配置
-```
-apt install python3
-apt install python-is-python3 python-dev-is-python3
-apt autoremove
-# 下载好python3后发现没有pip、yaml等工具
-apt install python3-pip
-pip install pyyaml
-
-```
-##### 编译前安装Numpy
-```
-python3 -m pip install numpy --upgrade -i
-https://pypi.tuna.tsinghua.edu.cn/simple
-```
-### **环境变量配置**
-```
-export USE_CUDA=0 #不编译CUDA版本
-export USE_DISTRIBUTED=0 #不支持分布式
-export USE_MKLDNN=0 #不支持MKLDNN
-export MAX_J0BS=16 #最大线程数 ,按需填写
-```
-### **编译pytorch前注意事项**
-
-● 一定要确认完整克隆好,如果对自己的网络没有信心,请直接从百度网盘下载源码包,注意源码包为原始pytorch仓库的完整克隆,克隆日期为2月20日,需要最新版本的请自行拉取
-
-● 确认gcc版本
-
-```
-gcc -v
-```
-
-gcc13以下的版本会遇到undefined reference to `__atomic_exchange_1'问题,可以通过patchelf解决,或者通过patch CMakefile文件的方式解决。
-```
-# path为存放libtorch_cpu.so的路径
-patchelf --add-needed libatomic.so.1 /path/libtorch_cpu.so
-# 若提示无patchelf命令,则执行下列语句
-apt install patchelf
-```
-
-patch内容详情:
-```
-From 40bae41e910c2aa0cc4d79457199152a21b99add Mon Sep 17 00:00:00 2001
-From: Bits
-Date: Thu, 22 Feb 2024 10:09:15 +0800
-Subject: [PATCH] =?UTF-8?q?GCC13=E4=BB=A5=E4=B8=8B=E7=89=88=E6=9C=AC?=
- =?UTF-8?q?=E7=BC=96=E8=AF=91=E9=9C=80=E8=A6=81=E9=93=BE=E6=8E=A5atomic?=
- =?UTF-8?q?=E5=BA=93?=
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
----
- caffe2/CMakeLists.txt | 6 +++---
- test/cpp/api/CMakeLists.txt | 4 ++--
- test/cpp/jit/CMakeLists.txt | 2 +-
- test/cpp/lazy/CMakeLists.txt | 2 +-
- test/cpp/tensorexpr/CMakeLists.txt | 4 ++--
- test/edge/CMakeLists.txt | 2 +-
- torch/lib/libshm/CMakeLists.txt | 2 +-
- 7 files changed, 11 insertions(+), 11 deletions(-)
-
-diff --git a/caffe2/CMakeLists.txt b/caffe2/CMakeLists.txt
-index 17582104933..ebfd4c1c10e 100644
---- a/caffe2/CMakeLists.txt
-+++ b/caffe2/CMakeLists.txt
-@@ -1425,7 +1425,7 @@ if($ENV{TH_BINARY_BUILD})
- endif()
- endif()
-
--target_link_libraries(torch_cpu PUBLIC c10)
-+target_link_libraries(torch_cpu PUBLIC c10 atomic)
- target_link_libraries(torch_cpu PUBLIC ${Caffe2_PUBLIC_DEPENDENCY_LIBS})
- target_link_libraries(torch_cpu PRIVATE ${Caffe2_DEPENDENCY_LIBS})
- target_link_libraries(torch_cpu PRIVATE ${Caffe2_DEPENDENCY_WHOLE_LINK_LIBS})
-@@ -1750,7 +1750,7 @@ if(BUILD_TEST)
- if(NOT MSVC)
- add_executable(${test_name}_${CPU_CAPABILITY} "${test_src}" ../aten/src/ATen/native/quantized/AffineQuantizerBase.cpp)
- # TODO: Get rid of c10 dependency (which is only needed for the implementation of AT_ERROR)
-- target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 sleef gtest_main)
-+ target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 sleef gtest_main atomic)
- if(USE_FBGEMM)
- target_link_libraries(${test_name}_${CPU_CAPABILITY} fbgemm)
- endif()
-@@ -1781,7 +1781,7 @@ if(BUILD_TEST)
- foreach(test_src ${Caffe2_CPU_TEST_SRCS})
- get_filename_component(test_name ${test_src} NAME_WE)
- add_executable(${test_name} "${test_src}")
-- target_link_libraries(${test_name} torch_library gtest_main)
-+ target_link_libraries(${test_name} torch_library gtest_main atomic)
- target_include_directories(${test_name} PRIVATE $)
- target_include_directories(${test_name} PRIVATE $)
- target_include_directories(${test_name} PRIVATE ${Caffe2_CPU_INCLUDE})
-diff --git a/test/cpp/api/CMakeLists.txt b/test/cpp/api/CMakeLists.txt
-index 42b67d8cb25..3be0b803828 100644
---- a/test/cpp/api/CMakeLists.txt
-+++ b/test/cpp/api/CMakeLists.txt
-@@ -49,7 +49,7 @@ endif()
-
- add_executable(test_api ${TORCH_API_TEST_SOURCES})
- target_include_directories(test_api PRIVATE ${ATen_CPU_INCLUDE})
--target_link_libraries(test_api PRIVATE torch gtest)
-+target_link_libraries(test_api PRIVATE torch gtest atomic)
- if(NOT MSVC)
- target_compile_options_if_supported(test_api -Wno-unused-variable)
- endif()
-@@ -79,4 +79,4 @@ endif()
-
- add_executable(parallel_benchmark ${TORCH_API_TEST_DIR}/parallel_benchmark.cpp)
- target_include_directories(parallel_benchmark PRIVATE ${ATen_CPU_INCLUDE})
--target_link_libraries(parallel_benchmark PRIVATE torch)
-+target_link_libraries(parallel_benchmark PRIVATE torch atomic)
-diff --git a/test/cpp/jit/CMakeLists.txt b/test/cpp/jit/CMakeLists.txt
-index 2d88d3f7172..17a268b89a0 100644
---- a/test/cpp/jit/CMakeLists.txt
-+++ b/test/cpp/jit/CMakeLists.txt
-@@ -107,7 +107,7 @@ if(USE_ASAN)
- endif()
-
- target_link_libraries(
-- test_jit PRIVATE flatbuffers)
-+ test_jit PRIVATE flatbuffers atomic)
-
-
- # TODO temporary until we can delete the old gtest polyfills.
-diff --git a/test/cpp/lazy/CMakeLists.txt b/test/cpp/lazy/CMakeLists.txt
-index be37b47ac9b..aef985e6ea7 100644
---- a/test/cpp/lazy/CMakeLists.txt
-+++ b/test/cpp/lazy/CMakeLists.txt
-@@ -27,7 +27,7 @@ add_executable(test_lazy
- # TODO temporary until we can delete the old gtest polyfills.
- target_compile_definitions(test_lazy PRIVATE USE_GTEST)
-
--set(LAZY_TEST_DEPENDENCIES torch gtest)
-+set(LAZY_TEST_DEPENDENCIES torch gtest atomic)
-
- target_link_libraries(test_lazy PRIVATE ${LAZY_TEST_DEPENDENCIES})
- target_include_directories(test_lazy PRIVATE ${ATen_CPU_INCLUDE})
-diff --git a/test/cpp/tensorexpr/CMakeLists.txt b/test/cpp/tensorexpr/CMakeLists.txt
-index 012471d0e58..5b0a4c540f3 100644
---- a/test/cpp/tensorexpr/CMakeLists.txt
-+++ b/test/cpp/tensorexpr/CMakeLists.txt
-@@ -39,7 +39,7 @@ add_executable(test_tensorexpr
- ${TENSOREXPR_TEST_ROOT}/padded_buffer.cpp
- ${TENSOREXPR_TEST_SRCS})
-
--target_link_libraries(test_tensorexpr PRIVATE torch gtest)
-+target_link_libraries(test_tensorexpr PRIVATE torch gtest atomic)
- target_include_directories(test_tensorexpr PRIVATE ${ATen_CPU_INCLUDE})
- target_compile_definitions(test_tensorexpr PRIVATE USE_GTEST)
- if(NOT MSVC)
-@@ -47,7 +47,7 @@ if(NOT MSVC)
- endif()
-
- add_executable(tutorial_tensorexpr ${TENSOREXPR_TEST_ROOT}/tutorial.cpp)
--target_link_libraries(tutorial_tensorexpr PRIVATE torch)
-+target_link_libraries(tutorial_tensorexpr PRIVATE torch atomic)
- target_include_directories(tutorial_tensorexpr PRIVATE ${ATen_CPU_INCLUDE})
-
- # The test case depends on the xnnpack header which in turn depends on the
-diff --git a/test/edge/CMakeLists.txt b/test/edge/CMakeLists.txt
-index 2f29f27e0b3..311062891cf 100644
---- a/test/edge/CMakeLists.txt
-+++ b/test/edge/CMakeLists.txt
-@@ -58,7 +58,7 @@ add_executable(test_edge_op_registration
-
- target_compile_definitions(test_edge_op_registration PRIVATE USE_GTEST)
-
--set(TEST_DEPENDENCIES gtest unbox_lib)
-+set(TEST_DEPENDENCIES gtest unbox_lib atomic)
-
- target_link_libraries(test_edge_op_registration PRIVATE
- ${TEST_DEPENDENCIES}
-diff --git a/torch/lib/libshm/CMakeLists.txt b/torch/lib/libshm/CMakeLists.txt
-index a3b41d0a0b0..a1db648342c 100644
---- a/torch/lib/libshm/CMakeLists.txt
-+++ b/torch/lib/libshm/CMakeLists.txt
-@@ -60,7 +60,7 @@ if(UNIX AND NOT APPLE)
- endif()
-
- add_executable(torch_shm_manager manager.cpp)
--target_link_libraries(torch_shm_manager PRIVATE shm c10)
-+target_link_libraries(torch_shm_manager PRIVATE shm c10 atomic)
- set_target_properties(torch_shm_manager PROPERTIES
- INSTALL_RPATH "${_rpath_portable_origin}/../lib")
-
---
-2.34.1
-
-
-
-```
-gcc13版本及以上没有此问题,但是可能出现软件包依赖问题,通过
-```
-export BUILD_TEST=0
-```
-可以解决。
-
-● 确认安装ninja,如果系统不能执行ninja,请apt安装ninja-build包或者从源码编译安装。
-
-● 编译前安装numpy
-
-```
-python3 -m pip install numpy --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
-
-```
-● 构建指令可以用`python setup.py bdist_wheel` 替代 `python setup.py develop --cmake`可以省去sudo管理员权限,构建完成后将会在dist目录下生成whl安装包。
-
-● 编译开始时显示的Failed不影响编译结果。缺少apt_pkg不影响编译。
-
-### **开始编译**
-```
-sudo python3 setup.py develop --cmake
-
-```
-### **编译及引用过程可能会遇到的问题**
-**1.Could not find any of CMakeLists.txt, Makefile, setup.py, LICENSE, LICENSE.md, LICENSE.txt in /root/xxx/pytorch/third_party/pthreadpool**
-
-问题来源:编译过程
-
-问题分析:由于网络的问题,clone仓库时有部分包未成功下载,导致文件夹为空
-
-解决方法:重新下载对应包
-```
-cd third_party
-rm -rf pthreadpool
-sudo git clone pthreadpool的url
-```
-**2./usr/bin/ld: /root/xxx/pytorch/build/lib/libtorch_cpu.so: undefined reference to `__atomic_exchange_1’ collect2: error: ld returned 1 exit status**
-
- 问题来源:编译过程
-
- 问题分析:对__atomic_exchange_1的未定义引用
-
-解决方法:使用patchelf添加需要的动态库
-
-```
-# path为存放libtorch_cpu.so的路径
-patchelf --add-needed libatomic.so.1 /path/libtorch_cpu.so
-# 若提示无patchelf命令,则执行下列语句
-apt install patchelf
-```
-**3.Error in cpuinfo: processor architecture is not supported in cpuinfo**
-
-问题来源:编译完成后,使用python时“import torch”报错
-
-问题分析:git clone时下载的cpuinfo不支持Risc-V架构
-
-解决方法:删除当前存在的cpuinfo并重新下载最新支持Risc-V架构的cpuinfo
-cpuinfo路径为pytorch/third_party/cpuinfo,因此先进入pytorch/third_party目录
- 在终端执行以下指令
-
-```
-rm -rf cpuinfo
-git clone https://github.com/sophgo/cpuinfo.git
-# clone完成后需要重新编译
-sudo python3 setup.py develop --cmake
-
-```
+### 本地编译Pytorch
+### **获取源代码**
+链接:https://pan.baidu.com/s/1-kaWPzqAb6g7l4Bdhh-KPw?pwd=843d
+
+提取码:843d
+
+源码包为原始pytorch仓库的完整克隆,克隆日期为2月20日,需要最新版本的请自行拉取
+### **修改源代码**
+##### **荔枝派和算能开发板**
+对于荔枝派和算能的硬件环境,需要将源代码目录中的 pytorch/third_party/cpuinfo目录替换为算能的cpuinfo目录,具体如下
+```
+cd pytorch/third_party
+# 删除原有cpuinfo目录
+sudo rm -r cpuinfo
+# 克隆算能的cpuinfo目录
+sudo git clone https://github.com/sophgo/cpuinfo.git
+
+```
+##### **其他硬件环境**
+对于其他硬件环境,可以暂时不替换cpuinfo目录,建议替换
+##### **修改代码文件**
+**1.aten/src/ATen/CMakeLists.txt**
+
+将语句:
+```
+if(NOT MSVC AND NOT EMSCRIPTEN AND NOT INTERN_BUILD_MOBILE)
+
+```
+替换为:
+```
+if(FALSE)
+```
+**2.caffe2/CMakeLists.txt**
+
+将语句:
+```
+target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 sleef gtest_main)
+```
+
+替换为:
+```
+target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 gtest_main)
+```
+**3.test/cpp/api/CMakeLists.txt**
+
+在语句:
+```
+add_executable(test_api ${TORCH_API_TEST_SOURCES})
+```
+后添加:
+```
+target_compile_options(test_api PUBLIC -Wno-nonnull)
+```
+### **编译工具链安装**
+```
+apt install libopenblas-dev libblas-dev m4 cmake cython3 ccache
+
+# 若执行过程中有以下报错,则杀死10198进程:Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 10198 (apt)
+kill -9 10198
+
+# 安装过程中,若发现libopenblas-dev无法正常安装,则跳过其直接安装libblas-dev m4 cmake cython3 ccache
+apt install libblas-dev m4 cmake cython3 ccache
+
+# libopenblas-dev无法安装的替代方案:手动安装OpenBLAS
+git clone https://github.com/xianyi/OpenBLAS.git
+cd OpenBLAS
+make -j8
+sudo make PREFIX=/usr/local/OpenBLAS install
+# 进入/etc,用vim打开profile
+[在最后一行添加]: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/OpenBLAS/lib/
+source /etc/profile
+
+```
+### Python环境配置
+```
+apt install python3
+apt install python-is-python3 python-dev-is-python3
+apt autoremove
+# 下载好python3后发现没有pip、yaml等工具
+apt install python3-pip
+pip install pyyaml
+
+```
+##### 编译前安装Numpy
+```
+python3 -m pip install numpy --upgrade -i
+https://pypi.tuna.tsinghua.edu.cn/simple
+```
+### **环境变量配置**
+```
+export USE_CUDA=0 #不编译CUDA版本
+export USE_DISTRIBUTED=0 #不支持分布式
+export USE_MKLDNN=0 #不支持MKLDNN
+export MAX_J0BS=16 #最大线程数 ,按需填写
+```
+### **编译pytorch前注意事项**
+
+● 一定要确认完整克隆好,如果对自己的网络没有信心,请直接从百度网盘下载源码包,注意源码包为原始pytorch仓库的完整克隆,克隆日期为2月20日,需要最新版本的请自行拉取
+
+● 确认gcc版本
+
+```
+gcc -v
+```
+
+gcc13以下的版本会遇到undefined reference to `__atomic_exchange_1'问题,可以通过patchelf解决,或者通过patch CMakefile文件的方式解决。
+```
+# path为存放libtorch_cpu.so的路径
+patchelf --add-needed libatomic.so.1 /path/libtorch_cpu.so
+# 若提示无patchelf命令,则执行下列语句
+apt install patchelf
+```
+
+patch内容详情:
+```
+From 40bae41e910c2aa0cc4d79457199152a21b99add Mon Sep 17 00:00:00 2001
+From: Bits
+Date: Thu, 22 Feb 2024 10:09:15 +0800
+Subject: [PATCH] =?UTF-8?q?GCC13=E4=BB=A5=E4=B8=8B=E7=89=88=E6=9C=AC?=
+ =?UTF-8?q?=E7=BC=96=E8=AF=91=E9=9C=80=E8=A6=81=E9=93=BE=E6=8E=A5atomic?=
+ =?UTF-8?q?=E5=BA=93?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+---
+ caffe2/CMakeLists.txt | 6 +++---
+ test/cpp/api/CMakeLists.txt | 4 ++--
+ test/cpp/jit/CMakeLists.txt | 2 +-
+ test/cpp/lazy/CMakeLists.txt | 2 +-
+ test/cpp/tensorexpr/CMakeLists.txt | 4 ++--
+ test/edge/CMakeLists.txt | 2 +-
+ torch/lib/libshm/CMakeLists.txt | 2 +-
+ 7 files changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/caffe2/CMakeLists.txt b/caffe2/CMakeLists.txt
+index 17582104933..ebfd4c1c10e 100644
+--- a/caffe2/CMakeLists.txt
++++ b/caffe2/CMakeLists.txt
+@@ -1425,7 +1425,7 @@ if($ENV{TH_BINARY_BUILD})
+ endif()
+ endif()
+
+-target_link_libraries(torch_cpu PUBLIC c10)
++target_link_libraries(torch_cpu PUBLIC c10 atomic)
+ target_link_libraries(torch_cpu PUBLIC ${Caffe2_PUBLIC_DEPENDENCY_LIBS})
+ target_link_libraries(torch_cpu PRIVATE ${Caffe2_DEPENDENCY_LIBS})
+ target_link_libraries(torch_cpu PRIVATE ${Caffe2_DEPENDENCY_WHOLE_LINK_LIBS})
+@@ -1750,7 +1750,7 @@ if(BUILD_TEST)
+ if(NOT MSVC)
+ add_executable(${test_name}_${CPU_CAPABILITY} "${test_src}" ../aten/src/ATen/native/quantized/AffineQuantizerBase.cpp)
+ # TODO: Get rid of c10 dependency (which is only needed for the implementation of AT_ERROR)
+- target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 sleef gtest_main)
++ target_link_libraries(${test_name}_${CPU_CAPABILITY} c10 sleef gtest_main atomic)
+ if(USE_FBGEMM)
+ target_link_libraries(${test_name}_${CPU_CAPABILITY} fbgemm)
+ endif()
+@@ -1781,7 +1781,7 @@ if(BUILD_TEST)
+ foreach(test_src ${Caffe2_CPU_TEST_SRCS})
+ get_filename_component(test_name ${test_src} NAME_WE)
+ add_executable(${test_name} "${test_src}")
+- target_link_libraries(${test_name} torch_library gtest_main)
++ target_link_libraries(${test_name} torch_library gtest_main atomic)
+ target_include_directories(${test_name} PRIVATE $)
+ target_include_directories(${test_name} PRIVATE $)
+ target_include_directories(${test_name} PRIVATE ${Caffe2_CPU_INCLUDE})
+diff --git a/test/cpp/api/CMakeLists.txt b/test/cpp/api/CMakeLists.txt
+index 42b67d8cb25..3be0b803828 100644
+--- a/test/cpp/api/CMakeLists.txt
++++ b/test/cpp/api/CMakeLists.txt
+@@ -49,7 +49,7 @@ endif()
+
+ add_executable(test_api ${TORCH_API_TEST_SOURCES})
+ target_include_directories(test_api PRIVATE ${ATen_CPU_INCLUDE})
+-target_link_libraries(test_api PRIVATE torch gtest)
++target_link_libraries(test_api PRIVATE torch gtest atomic)
+ if(NOT MSVC)
+ target_compile_options_if_supported(test_api -Wno-unused-variable)
+ endif()
+@@ -79,4 +79,4 @@ endif()
+
+ add_executable(parallel_benchmark ${TORCH_API_TEST_DIR}/parallel_benchmark.cpp)
+ target_include_directories(parallel_benchmark PRIVATE ${ATen_CPU_INCLUDE})
+-target_link_libraries(parallel_benchmark PRIVATE torch)
++target_link_libraries(parallel_benchmark PRIVATE torch atomic)
+diff --git a/test/cpp/jit/CMakeLists.txt b/test/cpp/jit/CMakeLists.txt
+index 2d88d3f7172..17a268b89a0 100644
+--- a/test/cpp/jit/CMakeLists.txt
++++ b/test/cpp/jit/CMakeLists.txt
+@@ -107,7 +107,7 @@ if(USE_ASAN)
+ endif()
+
+ target_link_libraries(
+- test_jit PRIVATE flatbuffers)
++ test_jit PRIVATE flatbuffers atomic)
+
+
+ # TODO temporary until we can delete the old gtest polyfills.
+diff --git a/test/cpp/lazy/CMakeLists.txt b/test/cpp/lazy/CMakeLists.txt
+index be37b47ac9b..aef985e6ea7 100644
+--- a/test/cpp/lazy/CMakeLists.txt
++++ b/test/cpp/lazy/CMakeLists.txt
+@@ -27,7 +27,7 @@ add_executable(test_lazy
+ # TODO temporary until we can delete the old gtest polyfills.
+ target_compile_definitions(test_lazy PRIVATE USE_GTEST)
+
+-set(LAZY_TEST_DEPENDENCIES torch gtest)
++set(LAZY_TEST_DEPENDENCIES torch gtest atomic)
+
+ target_link_libraries(test_lazy PRIVATE ${LAZY_TEST_DEPENDENCIES})
+ target_include_directories(test_lazy PRIVATE ${ATen_CPU_INCLUDE})
+diff --git a/test/cpp/tensorexpr/CMakeLists.txt b/test/cpp/tensorexpr/CMakeLists.txt
+index 012471d0e58..5b0a4c540f3 100644
+--- a/test/cpp/tensorexpr/CMakeLists.txt
++++ b/test/cpp/tensorexpr/CMakeLists.txt
+@@ -39,7 +39,7 @@ add_executable(test_tensorexpr
+ ${TENSOREXPR_TEST_ROOT}/padded_buffer.cpp
+ ${TENSOREXPR_TEST_SRCS})
+
+-target_link_libraries(test_tensorexpr PRIVATE torch gtest)
++target_link_libraries(test_tensorexpr PRIVATE torch gtest atomic)
+ target_include_directories(test_tensorexpr PRIVATE ${ATen_CPU_INCLUDE})
+ target_compile_definitions(test_tensorexpr PRIVATE USE_GTEST)
+ if(NOT MSVC)
+@@ -47,7 +47,7 @@ if(NOT MSVC)
+ endif()
+
+ add_executable(tutorial_tensorexpr ${TENSOREXPR_TEST_ROOT}/tutorial.cpp)
+-target_link_libraries(tutorial_tensorexpr PRIVATE torch)
++target_link_libraries(tutorial_tensorexpr PRIVATE torch atomic)
+ target_include_directories(tutorial_tensorexpr PRIVATE ${ATen_CPU_INCLUDE})
+
+ # The test case depends on the xnnpack header which in turn depends on the
+diff --git a/test/edge/CMakeLists.txt b/test/edge/CMakeLists.txt
+index 2f29f27e0b3..311062891cf 100644
+--- a/test/edge/CMakeLists.txt
++++ b/test/edge/CMakeLists.txt
+@@ -58,7 +58,7 @@ add_executable(test_edge_op_registration
+
+ target_compile_definitions(test_edge_op_registration PRIVATE USE_GTEST)
+
+-set(TEST_DEPENDENCIES gtest unbox_lib)
++set(TEST_DEPENDENCIES gtest unbox_lib atomic)
+
+ target_link_libraries(test_edge_op_registration PRIVATE
+ ${TEST_DEPENDENCIES}
+diff --git a/torch/lib/libshm/CMakeLists.txt b/torch/lib/libshm/CMakeLists.txt
+index a3b41d0a0b0..a1db648342c 100644
+--- a/torch/lib/libshm/CMakeLists.txt
++++ b/torch/lib/libshm/CMakeLists.txt
+@@ -60,7 +60,7 @@ if(UNIX AND NOT APPLE)
+ endif()
+
+ add_executable(torch_shm_manager manager.cpp)
+-target_link_libraries(torch_shm_manager PRIVATE shm c10)
++target_link_libraries(torch_shm_manager PRIVATE shm c10 atomic)
+ set_target_properties(torch_shm_manager PROPERTIES
+ INSTALL_RPATH "${_rpath_portable_origin}/../lib")
+
+--
+2.34.1
+
+
+
+```
+gcc13版本及以上没有此问题,但是可能出现软件包依赖问题,通过
+```
+export BUILD_TEST=0
+```
+可以解决。
+
+● 确认安装ninja,如果系统不能执行ninja,请apt安装ninja-build包或者从源码编译安装。
+
+● 编译前安装numpy
+
+```
+python3 -m pip install numpy --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
+
+```
+● 构建指令可以用`python setup.py bdist_wheel` 替代 `python setup.py develop --cmake`可以省去sudo管理员权限,构建完成后将会在dist目录下生成whl安装包。
+
+● 编译开始时显示的Failed不影响编译结果。缺少apt_pkg不影响编译。
+
+### **开始编译**
+```
+sudo python3 setup.py develop --cmake
+
+```
+### **编译及引用过程可能会遇到的问题**
+**1.Could not find any of CMakeLists.txt, Makefile, setup.py, LICENSE, LICENSE.md, LICENSE.txt in /root/xxx/pytorch/third_party/pthreadpool**
+
+问题来源:编译过程
+
+问题分析:由于网络的问题,clone仓库时有部分包未成功下载,导致文件夹为空
+
+解决方法:重新下载对应包
+```
+cd third_party
+rm -rf pthreadpool
+sudo git clone pthreadpool的url
+```
+**2./usr/bin/ld: /root/xxx/pytorch/build/lib/libtorch_cpu.so: undefined reference to `__atomic_exchange_1’ collect2: error: ld returned 1 exit status**
+
+ 问题来源:编译过程
+
+ 问题分析:对__atomic_exchange_1的未定义引用
+
+解决方法:使用patchelf添加需要的动态库
+
+```
+# path为存放libtorch_cpu.so的路径
+patchelf --add-needed libatomic.so.1 /path/libtorch_cpu.so
+# 若提示无patchelf命令,则执行下列语句
+apt install patchelf
+```
+**3.Error in cpuinfo: processor architecture is not supported in cpuinfo**
+
+问题来源:编译完成后,使用python时“import torch”报错
+
+问题分析:git clone时下载的cpuinfo不支持Risc-V架构
+
+解决方法:删除当前存在的cpuinfo并重新下载最新支持Risc-V架构的cpuinfo
+cpuinfo路径为pytorch/third_party/cpuinfo,因此先进入pytorch/third_party目录
+ 在终端执行以下指令
+
+```
+rm -rf cpuinfo
+git clone https://github.com/sophgo/cpuinfo.git
+# clone完成后需要重新编译
+sudo python3 setup.py develop --cmake
+
+```
### 原文链接:[https://blog.csdn.net/m0_49267873/article/details/135670989](https://blog.csdn.net/m0_49267873/article/details/135670989)
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/桌面环境移植.md b/04_社区贡献/开发指南/桌面环境移植.md
similarity index 100%
rename from 05_社区贡献/开发指南/桌面环境移植.md
rename to 04_社区贡献/开发指南/桌面环境移植.md
diff --git a/05_社区贡献/开发指南/移植GNU Hello软件到openKylin.md b/04_社区贡献/开发指南/移植GNU Hello软件到openKylin.md
similarity index 100%
rename from 05_社区贡献/开发指南/移植GNU Hello软件到openKylin.md
rename to 04_社区贡献/开发指南/移植GNU Hello软件到openKylin.md
diff --git a/04_社区贡献/开发指南/端侧AI模型管理.md b/04_社区贡献/开发指南/端侧AI模型管理.md
new file mode 100644
index 00000000..fd0cb58e
--- /dev/null
+++ b/04_社区贡献/开发指南/端侧AI模型管理.md
@@ -0,0 +1,59 @@
+# 端侧 AI 模型管理
+
+openKylin 系统不仅支持云端模型,也支持本地大模型。系统中集成了麒麟 AI 模型管理工具,可以自动下载本地大模型。性能不错的机器可以使用本地大模型体验 AI 助手。
+
+## 工具获取
+
+麒麟模型管理工具包名是`kylin-ai-model-manager`,新的 openKylin 系统中已经默认集成了此包。若你的系统中还没有,可以执行`sudo apt install kylin-ai-model-manager`进行安装。
+
+## 工具使用
+
+### 工具启动
+
+在开始菜单中打开`麒麟模型管理工具`。
+
+### 模型下载
+
+当前支持的模型有三种,分别用于自然语言处理、语音识别和搜索。
+
+#### 一键下载
+
+模型管理工具支持一键下载,只需点击`一键下载`按钮,然后输入管理员密码即可。
+(管理员密码只在一定时间内有效,由于网络速度影响,下载时间不确定,所以下载期间可能多次请求管理员权限。建议在一键下载完成后,再次点击`一键下载`按钮,再下载一次,确保没有因管理员权限失效导致的下载失败。下载完成后可以点击`检查本地模型文件`按钮,若有下载失败的模型,可以再次点击`一键下载`按钮重新下载。)
+
+#### 高级下载
+
+用户也可以自行选择下载的模型。
+
+ - `自然语言处理`模型只有一个:
+ 1. 在`模型类型`处选择`nlp`;
+ 2. 点击`下载模型`按钮即可;
+
+ - `语音识别`模型有 5 个:
+ 1. 在`模型类型`处选择`speech`;
+ 2. 在`模型名称`处选择一个模型;
+ 3. 点击`下载模型`按钮即可;
+ 4. 重复 2 和 3 直到下载完成所有`speech`模型;
+
+ - `搜索`模型有 2 个:
+ 1. 在`模型类型`处选择`搜索`;
+ 2. 在`模型名称`处选择一个模型;
+ 3. 点击`下载模型`按钮即可;
+ 4. 重复 2 和 3 直到下载完成所有`搜索`模型;
+
+### 模型检查
+
+工具中有一个`检查本地模型文件`按钮,用于检查下载模型的完整性。如果所有模型均存在且文件正确,则输出全为成功;若输出有失败,请重新下载对应模型。
+
+### 工具退出
+
+模型下载成功后,工具可以退出。
+
+## 注意
+
+1. 模型下载需要连接**可以访问`https://www.modelscope.cn/`的网络**。
+2. 初次下载模型时,需要先下载一些依赖,时间可能较长,请耐心等待。
+
+## 更新
+
+该工具目前主要为下载大模型试用,功能非常不完善。之后会有全新的设计和功能。感谢理解,敬请期待:)
diff --git a/05_社区贡献/开发指南/语音助手适配说明.md b/04_社区贡献/开发指南/语音助手适配说明.md
similarity index 100%
rename from 05_社区贡献/开发指南/语音助手适配说明.md
rename to 04_社区贡献/开发指南/语音助手适配说明.md
diff --git a/05_社区贡献/开放麒麟社区全览白皮书-案例模板.md b/04_社区贡献/开放麒麟社区全览白皮书-案例模板.md
similarity index 98%
rename from 05_社区贡献/开放麒麟社区全览白皮书-案例模板.md
rename to 04_社区贡献/开放麒麟社区全览白皮书-案例模板.md
index b9a3e0be..c3be1559 100644
--- a/05_社区贡献/开放麒麟社区全览白皮书-案例模板.md
+++ b/04_社区贡献/开放麒麟社区全览白皮书-案例模板.md
@@ -1,31 +1,31 @@
-# 一、技术创新案例参考模板
-## 背景概述
-xxxx项目是一个基于Python的自动化测试框架,旨在提供一种简单易用的方式来进行软件测试。该框架支持多种测试类型,包括单元测试、集成测试和端到端测试,并且提供了一些常用的测试工具和库,如pytest、unittest、selenium等。
-## 功能介绍
-xxxxxx自动化测试框架的主要功能包括:
-●支持多种测试类型,包括单元测试、集成测试和端到端测试。
-●支持使用常用的测试工具和库,如pytest、unittest、selenium等。
-●提供测试用例管理功能,可以方便地创建、编辑和删除测试用例。
-●支持测试报告生成,可以方便地查看测试结果和错误信息。
-## 应用场景
-xxxxx自动化测试框架适用于各种需要进行自动化测试的场景,如Web应用程序、移动应用程序、桌面应用程序等。它可以用于测试单个模块,也可以用于对整个系统进行全面的测试。
-## 项目地址
-xxxxx项目位于gitee上,地址为:https://gitee.com/xxxx/yyyy。你可以在上面的地址中找到更多的文档、示例和资源。如果你对该项目有任何问题或建议,可以在该项目的issues页面中进行讨论。
-
-
-# 二、行业应用案例参考模板
-## 应用场景
-需要明确说明该案例所涉及的应用场景。例如,该案例可能涉及制造业、物流、金融科技、医疗保健等领域。
-## 实施方案
-针对所涉及的应用场景,详细描述所采用的实施方案。这包括所使用的技术、工具、软件或服务等,以及它们如何被用来解决该领域的问题或提高效率。实施方案应包括详细的步骤、时间表和所需的资源。
-## 合作伙伴
-xxxxxxx
-
-
-# 三、用户使用案例参考模板
-## 使用场景
-描述一个用户在openKylin社区产品或服务的具体场景。这包括使用的设备、应用场景、任务和目的等信息。
-## 解决问题
-列举用户在使用openKylin社区产品或服务时所遇到的问题或挑战,以及利用该产品或服务如何解决了这些问题。
-## 用户类型
-描述使用openKylin社区产品或服务的用户类型,例如个人用户、企业用户、开发者等。这有助于读者更好地理解该产品或服务的应用范围和用户群体。
+# 一、技术创新案例参考模板
+## 背景概述
+xxxx项目是一个基于Python的自动化测试框架,旨在提供一种简单易用的方式来进行软件测试。该框架支持多种测试类型,包括单元测试、集成测试和端到端测试,并且提供了一些常用的测试工具和库,如pytest、unittest、selenium等。
+## 功能介绍
+xxxxxx自动化测试框架的主要功能包括:
+●支持多种测试类型,包括单元测试、集成测试和端到端测试。
+●支持使用常用的测试工具和库,如pytest、unittest、selenium等。
+●提供测试用例管理功能,可以方便地创建、编辑和删除测试用例。
+●支持测试报告生成,可以方便地查看测试结果和错误信息。
+## 应用场景
+xxxxx自动化测试框架适用于各种需要进行自动化测试的场景,如Web应用程序、移动应用程序、桌面应用程序等。它可以用于测试单个模块,也可以用于对整个系统进行全面的测试。
+## 项目地址
+xxxxx项目位于gitee上,地址为:https://gitee.com/xxxx/yyyy。你可以在上面的地址中找到更多的文档、示例和资源。如果你对该项目有任何问题或建议,可以在该项目的issues页面中进行讨论。
+
+
+# 二、行业应用案例参考模板
+## 应用场景
+需要明确说明该案例所涉及的应用场景。例如,该案例可能涉及制造业、物流、金融科技、医疗保健等领域。
+## 实施方案
+针对所涉及的应用场景,详细描述所采用的实施方案。这包括所使用的技术、工具、软件或服务等,以及它们如何被用来解决该领域的问题或提高效率。实施方案应包括详细的步骤、时间表和所需的资源。
+## 合作伙伴
+xxxxxxx
+
+
+# 三、用户使用案例参考模板
+## 使用场景
+描述一个用户在openKylin社区产品或服务的具体场景。这包括使用的设备、应用场景、任务和目的等信息。
+## 解决问题
+列举用户在使用openKylin社区产品或服务时所遇到的问题或挑战,以及利用该产品或服务如何解决了这些问题。
+## 用户类型
+描述使用openKylin社区产品或服务的用户类型,例如个人用户、企业用户、开发者等。这有助于读者更好地理解该产品或服务的应用范围和用户群体。
diff --git a/05_社区贡献/查看源代码.md b/04_社区贡献/查看源代码.md
similarity index 100%
rename from 05_社区贡献/查看源代码.md
rename to 04_社区贡献/查看源代码.md
diff --git a/05_社区贡献/翻译任务合集.md b/04_社区贡献/翻译任务合集.md
similarity index 100%
rename from 05_社区贡献/翻译任务合集.md
rename to 04_社区贡献/翻译任务合集.md
diff --git a/05_社区贡献/适配任务合集.md b/04_社区贡献/适配任务合集.md
similarity index 100%
rename from 05_社区贡献/适配任务合集.md
rename to 04_社区贡献/适配任务合集.md
diff --git a/05_社区贡献/非代码贡献指南.md b/04_社区贡献/非代码贡献指南.md
similarity index 100%
rename from 05_社区贡献/非代码贡献指南.md
rename to 04_社区贡献/非代码贡献指南.md
diff --git a/06_最新动向/.keep b/05_最新动向/.keep
similarity index 100%
rename from 06_最新动向/.keep
rename to 05_最新动向/.keep
diff --git a/05_最新动向/社区运营报告.md b/05_最新动向/社区运营报告.md
new file mode 100644
index 00000000..fcbe8def
--- /dev/null
+++ b/05_最新动向/社区运营报告.md
@@ -0,0 +1,5 @@
+# 社区运营报告
+- [openKylin社区2024年4月运营报告](https://www.openkylin.top/news/3384-cn.html)
+- [openKylin社区2024年3月运营报告](https://www.openkylin.top/news/3361-cn.html)
+- [openKylin社区2024年2月运营报告](https://www.openkylin.top/news/3331-cn.html)
+- [openKylin社区2024年1月运营报告](https://www.openkylin.top/news/3323-cn.html)
\ No newline at end of file
diff --git a/05_社区贡献/开发指南/arm上安装openKylin.md b/05_社区贡献/开发指南/arm上安装openKylin.md
deleted file mode 100644
index 95e9d367..00000000
--- a/05_社区贡献/开发指南/arm上安装openKylin.md
+++ /dev/null
@@ -1,332 +0,0 @@
----
-title: 在ARM上安装openKylin
-description:
-published: true
-date: 2023-01-12T02:42:26.148Z
-tags:
-editor: markdown
-dateCreated: 2023-01-12T02:36:15.135Z
----
-
-# 一、在 coolpi 上安装openKylin
-
-## 一.镜像下载
-
-通过以下链接下载:
-
-https://www.openkylin.top/downloads
-
-下载后右键解压得到.img文件,xz后缀的镜像文件则可以不用解压直接使用
-
-
-
-## 二.镜像烧录
-
-烧录程序安装:https://www.raspberrypi.com/software/
-
-
-
-
-插入SD卡,打开rpi-imager,选择自定义镜像,然后选择安装好的.img镜像文件
-
-
-
-
-选择SD卡,点击WRITE,等待制作完成
-
-
-
-
-
-## 三.coolpi openkylin启动
-
-接好coolpi开发板的电源线、显示器线,连接好键盘鼠标,插好SD卡
-
-
-coolpi启动时,可能存在一直黑屏的状态,或突然进入一个有问题的kylin操作系统(这是由于coolpi板子加载SD卡出错导致),插拔电源线重新启动即可
-
-
-进入到登录界面,点击登录,即可登录到桌面
-
-
-
-
-
-
-## 四.其他事项
-### 1.系统卡顿
-
-该问题由窗管占用cpu率较高导致,进入桌面后,到控制面板关闭特效模式,可以使得卡顿能够有效缓解
-
-
-
-
-### 2.修改密码
-
-由于系统没有引导安装,因此刚装完的系统是没有设置密码的,需要用户自己装机后手动配置一遍密码,以便于使用系统时遇到需要输入密码的场景
-
-
-
-
-### 3.磁盘分区
-
-制作镜像的时候,默认的分区大小是镜像的大小,因此装机后可能需要用户手动调整一下分区大小
-
-首先连接网络,右键桌面打开终端,sudo apt update更新源后安装gparted程序
-
-
-
-
-终端运行gparted,首先确立调整的磁盘是否正确
-
-
-
-
-选中writable分区,然后点击菜单栏的分区,选择调整分区大小
-
-
-
-
-拉动箭头调整分区,可以拉到最大,也可以调整合适大小,然后点击调整大小按钮
-
-
-
-
-点击应用全部操作,完成分区调整
-
-
-
-
-
-### 4.关闭显示器或休眠后唤醒黑屏
-
-建议用户在控制面板的电源里设置从不关闭显示器与电源,可避免该问题
-
-
-
-
-
-# 二、在树莓派上安装openKylin
-
-## 一.镜像下载
-
-通过以下链接下载:
-
-https://www.openkylin.top/downloads
-
-下载后右键解压得到.img文件,xz后缀的镜像文件则可以不用解压直接使用
-
-
-## 二.镜像烧录
-
-烧录程序安装:https://www.raspberrypi.com/software/
-
-
-
-
-插入SD卡,打开rpi-imager,选择自定义镜像,然后选择安装好的.img镜像文件
-
-
-
-
-选择SD卡,点击WRITE,等待制作完成
-
-
-
-
-
-## 三.树莓派openkylin启动
-
-接好树莓派的电源线、显示器线,连接好键盘鼠标,插好SD卡
-
-
-树莓派启动时,可能存在一直黑屏的状态,插拔电源线重新启动即可
-
-
-进入到登录界面,在右下角选择ukui-Wayland的方式,然后点击登录,即可登录到桌面(由于该镜像缺少x11相关包,因此无法使用kwin-x11进入桌面)
-
-
-
-
-
-
-
-## 四.其他事项
-### 1.系统卡顿
-
-该问题由窗管占用cpu率较高导致,进入桌面后,到控制面板关闭特效模式,可以使得卡顿能够有效缓解
-
-
-
-
-### 2.修改密码
-
-由于系统没有引导安装,因此刚装完的系统是没有设置密码的,需要用户自己装机后手动配置一遍密码,以便于使用系统时遇到需要输入密码的场景
-
-
-
-
-### 3.磁盘分区
-
-制作镜像的时候,默认的分区大小是镜像的大小,因此装机后可能需要用户手动调整一下分区大小
-
-首先连接网络,右键桌面打开终端,sudo apt update更新源后安装gparted程序
-
-
-
-
-终端运行gparted,首先确立调整的磁盘是否正确
-
-
-
-
-选中writable分区,然后点击菜单栏的分区,选择调整分区大小
-
-
-
-
-拉动箭头调整分区,可以拉到最大,也可以调整合适大小,然后点击调整大小按钮
-
-
-
-
-点击应用全部操作,完成分区调整
-
-
-
-
-
-### 4.关闭显示器或休眠后唤醒黑屏
-
-建议用户在控制面板的电源里设置从不关闭显示器与电源,可避免该问题
-
-
-
-# 三、在 chilliepi(双椒派) 上 安装 openKylin
-
-## 一.镜像下载
-
-通过以下链接下载:
-
-https://www.openkylin.top/downloads
-
-下载得到 openKylin-1.0-chilliepi-arm64.img.xz 文件
-
-## 二. 板卡信息
-
-### 1. 接口信息
-
-
-
-### 2. 串口信息
-
-
-
-## 三.镜像烧录
-
-注意:**双椒派上推荐使用金士顿 SD 卡**
-
-### 方法 1: 使用 dd 命令
-
-- 烧录镜像
- ```
- xz -k -d -v openKylin-1.0-chilliepi-arm64.img.xz
- sudo dd if=openKylin-1.0-chilliepi-arm64.img of=/dev/ status=progress
- ```
-
-### 方法 2: 使用 rpi-imager 工具
-
-烧录程序安装:https://www.raspberrypi.com/software/
-
-
-
-插入 SD 卡,打开 rpi-imager,选择自定义镜像,然后选择镜像文件
-
-
-
-选择 SD 卡,点击 WRITE,等待制作完成
-
-
-
-## 四. chilliepi 上启动 openkylin
-
-- 连接好键盘鼠标;插好 SD 卡;将 chilliepi 开发板通过 DP 线与显示器连接,建议通过电缆直连支持 DP 接口的显示器,如果通过转换器可能出现不兼容无显示的情况
- 
-- 通过串口连接开发板,插上电源, 快速按任意键, 使其进入到 u-boot 命令行界面
-- 设置 U-boot 启动参数
- ```sh
- setenv bootargs console=ttyAMA1,115200 audit=0 earlycon=pl011,0x2800d000 root=/dev/mmcblk1p2 rootdelay=3 rw;
- setenv bootcmd 'mmc dev 1;fatload mmc 1:1 0x90000000 e2000d-chilli.dtb;fatload mmc 1:1 0x90100000 Image;booti 0x90100000 - 0x90000000;'
- saveenv
- ```
-- 拔下电源, 拔下 SD 卡;插上 SDCard, 再插上电源, 即可启动系统。默认用户名/密码是
- ```
- > username:openkylin
- > password:openkylin
- ```
-
-
-
-
-## 五.其他事项
-
-### 1.磁盘大小
-
-制作镜像的时候,默认的根分区大小是在文件系统大小的基础上额外加了一些空间,如果出现磁盘空间不足的情况
-
-
-可以使用如下命令调整一下根分区大小,打开终端,执行如下命令可以将根分区扩展到最大
-```sh
-sudo resize-assistant
-```
-
-
-### 2.关闭显示器或休眠后唤醒黑屏
-
-建议用户在控制面板的电源里设置从不关闭显示器与电源,可避免该问题
-
-
-
-# 四、在 飞腾派 上 安装 openKylin
-
-## 一.镜像下载
-
-通过以下链接下载:
-
-- 4G版本: https://www.openkylin.top/downloads/download-smp.php?id=39
-- 2G版本: https://www.openkylin.top/downloads/download-smp.php?id=40
-
-根据个人需要下载对应的版本,下面以2G版本为例说明,下载得到 openKylin-1.0.1-phytiumpi-2G-arm64.img.xz 文件
-
-## 二.镜像烧录
-
-### 方法 1: 使用 dd 命令
-
-- 烧录镜像
- ```
- xz -k -d -v openKylin-1.0.1-phytiumpi-2G-arm64.img.xz
- sudo dd if=openKylin-1.0.1-phytiumpi-2G-arm64.img of=/dev/