Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
6705 lines (6532 sloc) 514 KB
AOSCC 2018 — 主群组
From 2018-07-17 11:08:55 to 2018-07-30 03:40:32, total 5971
[2018-07-17 11:08:55] gumblex >>> [chat_add_user]
[2018-07-17 12:22:42] Mingcong Bai >>> [chat_change_photo]
[2018-07-17 12:22:58] Mingcong Bai >>> [chat_change_photo]
[2018-07-17 14:32:14] 希瑀 蔡 >>> [chat_add_user]
[2018-07-17 14:33:11] 迫真 正版 >>> [chat_add_user]
[2018-07-17 15:01:02] LAX VPS >>> [chat_add_user]
[2018-07-17 21:14:50] LAX VPS [Re: 10] >>> get
[2018-07-17 21:21:43] LAX VPS >>> @JeffBai need to invite @aoscc2018_bot
[2018-07-17 21:24:55] Mingcong Bai >>> 我的 iOS App bug 了
[2018-07-17 21:25:01] Mingcong Bai >>> 点不动
[2018-07-17 21:25:11] LAX VPS >>> 噗
[2018-07-17 21:27:11] Mingcong Bai >>> [chat_add_user]
[2018-07-17 21:27:14] Mingcong Bai >>> 搞定
[2018-07-17 21:28:02] AOSCC Relay bot >>> [Lily-Ayta] ojbk 不过irc这边的mod flag(
[2018-07-18 09:19:04] Mingcong Bai [Re: 19] >>> @Icenowy
[2018-07-18 09:19:13] 冰淇琳 >>> ?
[2018-07-18 09:19:37] Mingcong Bai >>> mod flag?
[2018-07-18 09:19:51] Mingcong Bai >>> 还是我理解错了什么
[2018-07-18 11:53:29] 井生 羽衣 >>> [chat_add_user]
[2018-07-19 12:52:18] 猫晴 弥柚 >>> [chat_add_user]
[2018-07-19 12:53:27] Sakamoto Tanmy >>> [chat_add_user]
[2018-07-19 12:55:56] Luke Yue >>> [chat_add_user]
[2018-07-19 12:57:16] 无聊怪 >>> [chat_add_user]
[2018-07-19 12:58:34] Ted Cynx >>> [chat_add_user]
[2018-07-19 13:00:14] Lion [Re: 24] >>> 野兽前辈瞩目
[2018-07-19 13:02:39] Mingcong Bai >>> 欢迎来到 AOSCC 2018 主群组!本群组和 IRC 频道 #aoscc-2018 同步。
— 本群组仅限 AOSCC 议程内使用,在议程规定时间之外请不要在此处进行任何讨论。
— 本群组禁止一切与议程中话题无关的讨论。
— 本群组禁止使用 Sticker。
集会日程: https://github.com/AOSC-Dev/aoscc/blob/master/2018/README.md
AOSCC 主群组: https://t.me/joinchat/BMnG90FZDQlSnazLvYCWpA
———————
**AOSCC 2018 已开始收集代号提名和壁纸投稿**
本年度 Core 6 代号将以 F 开头,但是:
— 代号不得包含政治意味和该方面敏感内容
— 代号不得包含任何粗俗和侮辱性语言
— 代号不得为 F 单字母
— 代号不得包含不可自由使用的商标
本年度收集默认壁纸投稿以及壁纸集投稿,其中默认壁纸投稿要求:
— 默认壁纸为原创且可跟随 AOSC OS 重分发的作品
— 默认壁纸为计算机平面或各类辅助设计,不接受任何未经风格化处理的摄影作品
— 默认壁纸不得包含政治意味和该方面敏感内容
— 默认壁纸限定每人投一种设计,但不限定同样设计下不同风格组成的集合
而壁纸集投稿的话只要求原创、可分发及禁止政治意味和该方面敏感内容。
代号提名(UTC 时间 7 月 21 日前)及壁纸投稿(UTC 时间 7 月 28 日前)请发送到 aoscc2018@aosc.io 。 [webpage]
[2018-07-19 13:02:46] Mingcong Bai [Re: 31] >>> pinned the message
[2018-07-19 13:03:53] Catten Linger >>> [chat_add_user]
[2018-07-19 13:03:59] Catten Linger >>> \ o /
[2018-07-19 13:04:29] Mingcong Bai >>> 我清理下消息(见 pin msg
[2018-07-19 13:05:49] Mingcong Bai >>> **AOSCC 2018 已开始收集代号提名和壁纸投稿**
本年度 Core 6 代号将以 F 开头,但是:
— 代号不得包含政治意味和该方面敏感内容
— 代号不得包含任何粗俗和侮辱性语言
— 代号不得为 F 单字母
— 代号不得包含不可自由使用的商标
本年度收集默认壁纸投稿以及壁纸集投稿,其中默认壁纸投稿要求:
— 默认壁纸为原创且可跟随 AOSC OS 重分发的作品
— 默认壁纸为计算机平面或各类辅助设计,不接受任何未经风格化处理的摄影作品
— 默认壁纸不得包含政治意味和该方面敏感内容
— 默认壁纸限定每人投一种设计,但不限定同样设计下不同风格组成的集合
而壁纸集投稿的话只要求原创、可分发及禁止政治意味和该方面敏感内容。
代号提名(UTC 时间 7 月 21 日前)及壁纸投稿(UTC 时间 7 月 28 日前)请发送到 aoscc2018@aosc.io 。
[2018-07-19 17:08:16] Estel >>> [chat_add_user]
[2018-07-19 17:19:01] liushuyu >>> @JeffBai 我需要更改主题,应该是 "AOSC OS: Contiguous Integration of System Delivery"
[2018-07-19 18:15:53] OriginCode >>> [chat_add_user]
[2018-07-19 23:12:10] FlyGoat >>> [chat_add_user]
[2018-07-20 00:17:54] 御坂0x4e21 看到她灌水一律赶她下线 >>> [chat_add_user]
[2018-07-20 09:34:15] CRT >>> [chat_add_user]
[2018-07-20 10:24:50] Hung-I Wang >>> [chat_add_user]
[2018-07-20 11:25:55] NeoTimesharingSystem >>> [chat_add_user]
[2018-07-20 11:26:18] Fung Gwo >>> [chat_add_user]
[2018-07-20 11:35:27] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> [chat_add_user]
[2018-07-20 12:28:20] 櫻川 Y00 | 为什么男装这么无聊 >>> [chat_add_user]
[2018-07-20 13:08:28] 迫真 正版 >>> 你们选代号的时候我这边早上8点的样子
[2018-07-20 13:08:34] 迫真 正版 >>> 好方(x
[2018-07-20 13:09:41] Lion [Re: 49] >>> 嘘,会议时间还没到🌚
[2018-07-20 13:10:07] 迫真 正版 [Re: 50] >>> 反正日程都出来了(小声
[2018-07-20 13:12:26] Lion [Re: 51] >>> 看第一条消息第一小条(゜-゜)
[2018-07-20 13:12:47] 迫真 正版 >>> ao
[2018-07-20 13:20:38] AOSCC Relay bot >>> [YJSNPI] IRC Channel 這邊 Topic 都沒設置嘛
[2018-07-20 17:12:21] fr >>> [chat_add_user]
[2018-07-20 21:02:52] jactry >>> [chat_add_user]
[2018-07-20 21:16:47] AOSCC Relay bot >>> [mingcongbai] test
[2018-07-20 21:16:59] Mingcong Bai >>> test
[2018-07-20 21:55:37] 千 qian >>> [chat_add_user]
[2018-07-20 21:55:40] 𝓦𝓑𝓒𝓛 >>> [chat_add_user]
[2018-07-20 22:42:46] 白雾 纱织 >>> [chat_add_user]
[2018-07-21 00:38:36] Mingcong Bai [Fwd: Mingcong Bai] >>> 本年度 Core 6 代号将以 F 开头,但是:
— 代号不得包含政治意味和该方面敏感内容
— 代号不得包含任何粗俗和侮辱性语言
— 代号不得为 F 单字母
— 代号不得包含不可自由使用的商标
代号提名将于北京时间周六早八点(UTC 零时)截止。有意提名者请抓紧时间发送代号到 aoscc2018@aosc.io 。
[2018-07-21 05:02:56] Mingcong Bai >>> [Forwarded from Mingcong Bai]
本年度 Core 6 代号将以 F 开头,但是:
— 代号不得包含政治意味和该方面敏感内容
— 代号不得包含任何粗俗和侮辱性语言
— 代号不得为 F 单字母
— 代号不得包含不可自由使用的商标
代号提名将于北京时间周六早八点(UTC 零时)截止。有意提名者请抓紧时间发送代号到 aoscc2018@aosc.io 。
[2018-07-21 05:08:47] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 每天滚动播送消息(
[2018-07-21 07:31:33] Mingcong Bai >>> 各位早上好,今日议程还有一个半小时就开始了。不过今天早上九点到九点半是给各位自由活动的时间(现场 AOSCC 模拟器 2018),接下来今天早上有两个讨论话题:
— 9:30 - 10:30,调整 AOSC OS 的更新周期和里程碑计划集成(本人主持)
— 11:00 - 12:00,AOSC OS 打包工作流和工具链版本管控(@Lionium 主持)
而后今晚有三个议程:
— 21:00 - 22:00,关于 AOSC OS 安全更新工作流程的介绍和安全更新维护者召集(@l2dy0 主持)
— 22:15 - 23:15,关于 AOSC OS 软件包二进制优化 overlay 的实现计划(@lmy441900 主持)
— 23:30 - 0:00,Core 6 代号投票
[2018-07-21 07:32:57] Mingcong Bai >>> 每个话题开始前我将 pin 上话题标题并通知所有成员。
[2018-07-21 07:40:16] Leway Colin >>> 👌
[2018-07-21 08:00:15] Mingcong Bai >>> 倒计时一小时,代号征集截止
[2018-07-21 08:01:34] Mingcong Bai >>> 将有 30 个代号加入今晚的投票(因为数量繁多且 @vote 无法处理超过 10 个选项,所以分开了三个小组;将进行多轮投票)。
[2018-07-21 08:03:26] OriginCode >>> 了解
[2018-07-21 08:20:31] AOSCC Relay bot >>> [mingcongbai] Pre-assembly IRC test
[2018-07-21 08:20:39] Mingcong Bai >>> Pre-assembly Telegram test
[2018-07-21 08:20:42] Mingcong Bai >>> Good.
[2018-07-21 08:49:50] liushuyu >>> 按照章程,第一场是预热/闲聊对吧
[2018-07-21 08:50:59] Mingcong Bai [Re: 65] >>> 嗯,九点到九点半,见上
[2018-07-21 08:51:18] Mingcong Bai >>> (今年第一次最大化 Telegram Desktop(x
[2018-07-21 08:55:57] Mingcong Bai >>> 五分钟 | Five Minutes | Пять минут
[2018-07-21 08:57:19] Zero King >>> 5分鐘 | 五分 | 5 분
[2018-07-21 08:58:18] Mingcong Bai >>> năm phút
[2018-07-21 08:58:53] OriginCode >>> 2分钟倒计时(
[2018-07-21 08:59:52] liushuyu >>> 10 秒
[2018-07-21 09:00:07] liushuyu >>> 好了
[2018-07-21 09:00:07] Mingcong Bai >>> #TOPIC 9:00 - 9:30 — 热场,闲聊
[2018-07-21 09:00:08] Lion >>> 喵
[2018-07-21 09:00:12] Mingcong Bai [Re: 83] >>> pinned the message
[2018-07-21 09:00:26] 迫真 正版 >>> 你是一个
[2018-07-21 09:00:28] liushuyu [Re: 84] >>> 狮子今天起这么早
[2018-07-21 09:00:29] 迫真 正版 >>> 开发者
[2018-07-21 09:00:44] Mingcong Bai >>> 各位早(
[2018-07-21 09:00:44] Lion [Re: 87] >>> 待会第二个就到我了🌝
[2018-07-21 09:00:49] liushuyu >>> 有点违反常理吧(
[2018-07-21 09:00:50] Mingcong Bai >>> 最后罗嗦一句
[2018-07-21 09:00:52] 迫真 正版 >>> 话说还有honeydrive这样的发行版啊
[2018-07-21 09:00:59] 迫真 正版 >>> 🌚
[2018-07-21 09:01:00] Mingcong Bai >>> 接下来今天早上有两个讨论话题:
— 9:30 - 10:30,调整 AOSC OS 的更新周期和里程碑计划集成(本人主持)
— 11:00 - 12:00,AOSC OS 打包工作流和工具链版本管控(@Lionium 主持)
而后今晚有三个议程:
— 21:00 - 22:00,关于 AOSC OS 安全更新工作流程的介绍和安全更新维护者召集(@l2dy0 主持)
— 22:15 - 23:15,关于 AOSC OS 软件包二进制优化 overlay 的实现计划(@lmy441900 主持)
— 23:30 - 0:00,Core 6 代号投票
[2018-07-21 09:01:00] OriginCode >>> 开始闲聊(
[2018-07-21 09:01:01] liushuyu [Re: 89] >>> 晚上好(
[2018-07-21 09:01:07] Mingcong Bai [Re: 93] >>> 这啥
[2018-07-21 09:01:11] Mingcong Bai [Re: 97] >>> 晚上好(
[2018-07-21 09:01:14] 迫真 正版 [Re: 98] >>> 蜜罐发行版
[2018-07-21 09:01:30] Mingcong Bai [Re: 100] >>> 最近还听说有个 Freenode 组织者做的发行版
[2018-07-21 09:01:30] Zero King >>> honeypot(
[2018-07-21 09:01:35] OriginCode >>> (咱还有半小时左右到晚饭场地)
[2018-07-21 09:01:36] 迫真 正版 >>> Honeypots in a box!
[2018-07-21 09:01:38] Mingcong Bai >>> “为了保存我的一些特殊爱好”
[2018-07-21 09:01:41] Lion [Re: 100] >>> 从头到尾安“充满恶意”的发行版??
[2018-07-21 09:01:58] Mingcong Bai >>> https://www.dailydot.com/debug/linux-exherbo-developer-debunked/ [webpage]
[2018-07-21 09:01:59] OriginCode [Re: 101] >>> 哦?
[2018-07-21 09:02:00] liushuyu [Re: 106] >>> 吸引狮子么(
[2018-07-21 09:02:03] Mingcong Bai [Re: 107] >>> 噢?
[2018-07-21 09:02:11] Lion [Re: 109] >>> 装爆
[2018-07-21 09:02:11] Mingcong Bai >>> 我上次看见的就是这个……
[2018-07-21 09:02:12] 猫晴 弥柚 >>> 早
[2018-07-21 09:02:17] Mingcong Bai [Re: 113] >>> 早上好
[2018-07-21 09:02:20] liushuyu [Re: 113] >>> 早
[2018-07-21 09:02:23] Mingcong Bai >>> (能专心聊天感觉真好
[2018-07-21 09:02:26] 迫真 正版 [Re: 106] >>> 是的,因为3年没更新,基于xubuntu 12.04…
[2018-07-21 09:02:26] 猫晴 弥柚 >>> utctime 1:00
[2018-07-21 09:02:27] OriginCode [Re: 113] >>> 早
[2018-07-21 09:02:29] 井生 羽衣 >>> 早喵~
[2018-07-21 09:02:34] Mingcong Bai [Re: 118] >>> 哇你在 GMT?
[2018-07-21 09:02:35] liushuyu >>> 早
[2018-07-21 09:02:38] Mingcong Bai [Re: 120] >>> 早
[2018-07-21 09:02:48] Lion [Re: 117] >>> 故意不更新还行
[2018-07-21 09:02:49] Mingcong Bai >>> 可惜不是现场(
[2018-07-21 09:02:50] OriginCode >>> 18点(
[2018-07-21 09:02:53] liushuyu >>> OpenJDK 8 的字体系统真的很先进(
[2018-07-21 09:02:55] Mingcong Bai [Re: 126] >>> 20:02
[2018-07-21 09:03:18] liushuyu [Re: 127] >>> 昨天调查清楚了(
[2018-07-21 09:03:23] Mingcong Bai [Re: 129] >>> 唔
[2018-07-21 09:03:28] OriginCode >>> 明天早上起来还得开会(
[2018-07-21 09:03:29] 猫晴 弥柚 >>> 单纯的用utctime来协调俺和俺的诸多盆友时区不同步的问题
[2018-07-21 09:03:43] Mingcong Bai >>> 目前状态( [photo]
[2018-07-21 09:03:48] Mingcong Bai [Re: 132] >>> 聪明
[2018-07-21 09:03:49] 迫真 正版 >>> 我的azure好像显示UTC的
[2018-07-21 09:03:54] 迫真 正版 >>> 233
[2018-07-21 09:03:56] liushuyu [Re: 130] >>> OpenJDK 会给不同框架用不同的方法
[2018-07-21 09:04:08] Mingcong Bai >>> 可怜的 @Icenowy 昨天似乎半夜才到家
[2018-07-21 09:04:10] Lion [Re: 133] >>> 开放括号不关
[2018-07-21 09:04:17] Mingcong Bai >>> 所以尽早我管 IRC(
[2018-07-21 09:04:20] Mingcong Bai >>> 今早 *
[2018-07-21 09:04:20] Lion >>> 爱右括号组织表示……
[2018-07-21 09:04:21] 迫真 正版 [Re: 134] >>> 我把西雅图和国内时差刻在DNA里了(没有
[2018-07-21 09:04:26] Mingcong Bai [Re: 142] >>> Dayum.
[2018-07-21 09:04:30] 猫晴 弥柚 >>> 有人在过utc-5,有人在过utc-6,有人在过utc+8,+5,+1s
[2018-07-21 09:04:38] Mingcong Bai [Re: 143] >>> [photo]
[2018-07-21 09:04:38] 死 肥 宅 鹹魚 [Re: 139] >>> 是原罪
[2018-07-21 09:04:40] OriginCode >>> 目前状态( [photo]
[2018-07-21 09:04:43] liushuyu >>> 1. Awt 使用自己的 t2k 实现
2. JavaFX 使用 fc
[2018-07-21 09:04:50] AOSCC Relay bot >>> [Umbelost] woc YJSNPI 是谁
[2018-07-21 09:04:55] 迫真 正版 [Re: 146] >>> 我一般看到时间直接算((
[2018-07-21 09:05:00] Mingcong Bai [Re: 150] >>> 不清楚诶……
[2018-07-21 09:05:02] liushuyu [Re: 142] >>> )))))) 怎么样
[2018-07-21 09:05:08] OriginCode >>> )
[2018-07-21 09:05:18] 迫真 正版 >>> 热爱Linux的先辈是鉴
[2018-07-21 09:05:18] Mingcong Bai >>> IRC 上 YJSNPI 是谁?
[2018-07-21 09:05:22] Lion [Re: 153] >>> 爱左括号组织……
[2018-07-21 09:05:23] 死 肥 宅 鹹魚 [Re: 150] >>> 我
[2018-07-21 09:05:28] Mingcong Bai [Re: 158] >>> hhhhhh
[2018-07-21 09:05:32] Mingcong Bai [Re: 157] >>> 你看你看(
[2018-07-21 09:05:32] 井生 羽衣 [Re: 158] >>> hhhhhhh
[2018-07-21 09:05:51] liushuyu [Re: 157] >>> 快去学习 Lisp(
[2018-07-21 09:05:52] Mingcong Bai >>> 对了如果各位想用语音发点东西也是可以接受的
[2018-07-21 09:05:52] Lion [Re: 160] >>> 不用括号一身轻🌝
[2018-07-21 09:05:52] 迫真 正版 >>> 😁
[2018-07-21 09:06:02] Mingcong Bai >>> 我会帮忙转文字
[2018-07-21 09:06:07] Lion [Re: 162] >>> Nooooo
[2018-07-21 09:06:14] liushuyu [Re: 166] >>> 人工语音识别(
[2018-07-21 09:06:16] 死 肥 宅 鹹魚 >>> 我另外還有個比利海靈頓(
[2018-07-21 09:06:24] Mingcong Bai >>> 发日语的话帮不上忙(
[2018-07-21 09:06:24] 迫真 正版 >>> 我有jinkela
[2018-07-21 09:06:26] 死 肥 宅 鹹魚 >>> 就是太久沒登錄了不知道還能不能用
[2018-07-21 09:06:28] 迫真 正版 >>> 🌚
[2018-07-21 09:06:32] Zero King >>> 目前状态( [photo]
[2018-07-21 09:06:37] Mingcong Bai [Re: 171] >>> 说起来代号里面真有金坷垃
[2018-07-21 09:06:42] 死 肥 宅 鹹魚 [Re: 170] >>> 君日本語學習可以
[2018-07-21 09:06:53] 迫真 正版 [Re: 175] >>> 肥料(小声
[2018-07-21 09:06:56] liushuyu [Re: 170] >>> 识别系统可以使用 zh_CN en_* ru_RU (
[2018-07-21 09:06:59] Mingcong Bai [Re: 176] >>> 我大屁眼子…… 呸
[2018-07-21 09:07:02] Mingcong Bai >>> 脑袋受不了
[2018-07-21 09:07:10] Mingcong Bai [Re: 178] >>> de_DE 也可以,识别率比较低(
[2018-07-21 09:07:15] 迫真 正版 >>> 特首要学114种语言
[2018-07-21 09:07:15] Mingcong Bai >>> zh_YUE 也可以
[2018-07-21 09:07:20] 井生 羽衣 [Re: 175] >>> 大概是我提的(
[2018-07-21 09:07:29] Mingcong Bai [Re: 182] >>> 以及 514 种非洲方言
[2018-07-21 09:07:29] 猫晴 弥柚 [Re: 182] >>> 羡慕114种语言
[2018-07-21 09:07:34] OriginCode >>> 呜这里只有我一个用手机开会的么(
[2018-07-21 09:07:34] Mingcong Bai [Re: 184] >>> 好像是(
[2018-07-21 09:07:41] 死 肥 宅 鹹魚 [Re: 185] >>> hhhhh
[2018-07-21 09:07:44] liushuyu [Re: 183] >>> 不是 yue_YUE 么(政治正确?
[2018-07-21 09:07:45] Lion >>> 学习一个一个一个语言
[2018-07-21 09:07:46] Luke Yue >>> 手机路过(
[2018-07-21 09:07:51] Mingcong Bai [Re: 174] >>> 我真的不敢肯定是 macOS 还是 *nix(
[2018-07-21 09:07:56] OriginCode [Re: 185] >>> 特首要学所有中国方言(
[2018-07-21 09:08:01] Luke Yue >>> 在驾校围观开会(
[2018-07-21 09:08:06] 死 肥 宅 鹹魚 [Re: 193] >>> 賭五毛 macOS
[2018-07-21 09:08:07] Mingcong Bai [Re: 190] >>> 好好(另外看群规,最上面一条消息
[2018-07-21 09:08:13] Mingcong Bai [Re: 196] >>> 影子不像?
[2018-07-21 09:08:16] Zero King [Re: 193] >>> 两个不同的Telegram当然是macOS
[2018-07-21 09:08:20] Luke Yue >>> 看字体是 macOS(
[2018-07-21 09:08:22] 猫晴 弥柚 >>> 手机当然是用来开小差去撩小姐姐的啦
[2018-07-21 09:08:29] Mingcong Bai [Re: 199] >>> 有道理(
[2018-07-21 09:08:31] liushuyu [Re: 197] >>> 抱歉
[2018-07-21 09:08:38] OriginCode >>> 看字体+字体渲染是 macOS
[2018-07-21 09:08:47] OriginCode >>> 实锤(
[2018-07-21 09:08:54] 迫真 正版 >>> lol
[2018-07-21 09:08:58] Mingcong Bai >>> 说起来现在我在电脑上看见 Noto 以外的字体我都开始觉得别扭了
[2018-07-21 09:09:07] Mingcong Bai >>> iOS 上的引号我也看不惯
[2018-07-21 09:09:14] liushuyu >>> 现在水量应该超过任何水群
[2018-07-21 09:09:15] 迫真 正版 [Re: 207] >>> 装个Windows(逃
[2018-07-21 09:09:15] OriginCode [Re: 207] >>> Source Han Sans(
[2018-07-21 09:09:23] Mingcong Bai [Re: 209] >>> Drawn this channel! (
[2018-07-21 09:09:25] Lion >>> 说起来这里的图片可以转发去 IRC 的吗?
[2018-07-21 09:09:30] Mingcong Bai [Re: 211] >>> 其实就一个
[2018-07-21 09:09:32] 死 肥 宅 鹹魚 >>> San Francisco, San Francisco
[2018-07-21 09:09:33] Mingcong Bai [Re: 213] >>> 可以
[2018-07-21 09:09:41] 死 肥 宅 鹹魚 >>> 蘋方,蘋方
[2018-07-21 09:09:42] Lion >>> 吼啊
[2018-07-21 09:09:42] Mingcong Bai >>> [photo]
[2018-07-21 09:09:58] OriginCode [Re: 217] >>> 在 Arch 上渲染成一坨
[2018-07-21 09:10:03] OriginCode >>> 不能看(
[2018-07-21 09:10:10] 迫真 正版 >>> 233
[2018-07-21 09:10:19] Mingcong Bai >>> 一个 1600x1200 用户的故事 [photo]
[2018-07-21 09:10:23] 死 肥 宅 鹹魚 >>> 我這邊是 Firefox 海星,Chrome 上爆炸了
[2018-07-21 09:10:30] Mingcong Bai >>> Telegram 100% 看得难受,但是 125% 又太大了
[2018-07-21 09:10:32] 井生 羽衣 [Re: 219] >>> [photo]
[2018-07-21 09:10:34] 死 肥 宅 鹹魚 [Re: 223] >>> 羨慕了
[2018-07-21 09:10:44] 迫真 正版 [Re: 223] >>> 羡慕死了
[2018-07-21 09:10:46] Mingcong Bai >>> (而且因为经常把窗口放到右上角所以老看不见
[2018-07-21 09:10:47] liushuyu [Re: 219] >>> 噢,对了 OpenJDK 强行指定 NotoSansCJK 它会选择日语字形渲染简体中文
[2018-07-21 09:10:50] 死 肥 宅 鹹魚 >>> 果凍 IRC 客戶端用的啥
[2018-07-21 09:10:50] OriginCode [Re: 224] >>> Noto Sans 吼啊
[2018-07-21 09:10:53] Mingcong Bai [Re: 230] >>> 肯定……
[2018-07-21 09:10:58] Mingcong Bai [Re: 231] >>> Polari
[2018-07-21 09:11:04] 迫真 正版 >>> 我还是1440x900
[2018-07-21 09:11:06] Mingcong Bai >>> (一看就不是个天天用 IRC 的
[2018-07-21 09:11:10] OriginCode [Re: 223] >>> xmdys
[2018-07-21 09:11:11] 猫晴 弥柚 >>> 压得跟手机端一样的工作区域(方便干别的 [photo]
[2018-07-21 09:11:18] 迫真 正版 [Re: 236] >>> 我每次登录都去开vacation
[2018-07-21 09:11:19] OriginCode [Re: 236] >>> 曾经是(
[2018-07-21 09:11:19] Mingcong Bai [Re: 238] >>> 其实我一般情况下就这样
[2018-07-21 09:11:24] 迫真 正版 >>> 懂吗(x
[2018-07-21 09:11:25] liushuyu [Re: 233] >>> 因为不支持 ttc(
[2018-07-21 09:11:35] Mingcong Bai [Re: 242] >>> ?
[2018-07-21 09:11:37] Mingcong Bai >>> 不懂
[2018-07-21 09:11:38] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 223] >>> 一个 3840 x 1080 用户的故事 [photo]
[2018-07-21 09:11:42] OriginCode [Re: 241] >>> i3 排成这样(x
[2018-07-21 09:11:43] 迫真 正版 [Re: 244] >>> 几个月上一次
[2018-07-21 09:11:45] Mingcong Bai [Re: 246] >>> Woohoo 32:9
[2018-07-21 09:11:48] liushuyu >>> 代码里面是自动选择 ttc 里面第一个字体
[2018-07-21 09:11:52] OriginCode [Re: 246] >>> xmsl
[2018-07-21 09:11:54] 死 肥 宅 鹹魚 [Re: 246] >>> #RICH
[2018-07-21 09:11:55] 猫晴 弥柚 >>> 羡慕高分屏
[2018-07-21 09:11:56] Mingcong Bai >>> 怀疑 @cth451 有三个脑子
[2018-07-21 09:12:00] 死 肥 宅 鹹魚 >>> 羨慕死了.webp
[2018-07-21 09:12:08] 死 肥 宅 鹹魚 >>> 三個腦子hhhhhh
[2018-07-21 09:12:08] OriginCode >>> 等我回家也是 3840*1080(
[2018-07-21 09:12:14] Mingcong Bai >>> 说起来我们来 po 一下面前的工作区域吧(
[2018-07-21 09:12:16] 死 肥 宅 鹹魚 [Re: 257] >>> #RICH 真好
[2018-07-21 09:12:16] liushuyu [Re: 254] >>> CTH Brain Patch rev. 3.0 (
[2018-07-21 09:12:19] 迫真 正版 >>> 有三个脑子也打不了osu std模式
[2018-07-21 09:12:24] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 254] >>> 只有一个
[2018-07-21 09:12:38] Lion [Re: 262] >>> 一个一个一个
[2018-07-21 09:12:38] liushuyu [Re: 262] >>> 1核 3 线程?
[2018-07-21 09:12:42] 迫真 正版 [Re: 260] >>> 大脑升级
[2018-07-21 09:12:43] Mingcong Bai >>> [photo]
[2018-07-21 09:12:45] OriginCode [Re: 259] >>> 从家里堆的一堆东西里面翻出来了个戴尔的全新显示器
[2018-07-21 09:12:45] 死 肥 宅 鹹魚 [Re: 258] >>> P50 * 1,沒了(
[2018-07-21 09:12:54] 死 肥 宅 鹹魚 [Re: 267] >>> 羨慕了
[2018-07-21 09:12:55] Mingcong Bai [Re: 268] >>> 不不来照片(
[2018-07-21 09:13:01] Mingcong Bai [Re: 266] >>> ^
[2018-07-21 09:13:07] liushuyu [Re: 265] >>> 如何获取更新(
[2018-07-21 09:13:10] 迫真 正版 >>> [photo]
[2018-07-21 09:13:13] OriginCode [Re: 258] >>> HUAWEI P10 Plus(Bootloader Unlocked)没了(
[2018-07-21 09:13:21] Mingcong Bai [Re: 272] >>> 想起 Borat 里面一个故事
[2018-07-21 09:13:31] 迫真 正版 [Re: 273] >>> 特首请不要盯着贴纸看
[2018-07-21 09:13:35] 迫真 正版 >>> 🌚
[2018-07-21 09:13:45] Luke Yue >>> [photo]
[2018-07-21 09:13:47] Luke Yue >>> 工作区域
[2018-07-21 09:13:48] Luke Yue >>> [document]
[2018-07-21 09:13:59] Mingcong Bai [Re: 272] >>> "My brother he got headache, my sister opened his head, and put some tears in it... He now retard."
[2018-07-21 09:14:02] 迫真 正版 >>> 特首有权删sticker吗(小声
[2018-07-21 09:14:14] Mingcong Bai [Re: 282] >>> Of course - I dictator
[2018-07-21 09:14:18] Luke Yue >>> 忘了(
[2018-07-21 09:14:18] liushuyu [Re: 281] >>> 咦?(
[2018-07-21 09:14:29] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> [photo]
[2018-07-21 09:14:31] Mingcong Bai [Re: 285] >>> 网搜 Borat
[2018-07-21 09:14:41] 迫真 正版 [Re: 283] >>> Heil
[2018-07-21 09:14:45] 迫真 正版 >>> (不
[2018-07-21 09:14:50] Mingcong Bai >>> 说起来有人想做 admin 吗
[2018-07-21 09:14:55] Mingcong Bai >>> 或者说“愿意”
[2018-07-21 09:15:00] 迫真 正版 >>> 用户名admin
密码admin
[2018-07-21 09:15:04] 迫真 正版 >>> (无端联想
[2018-07-21 09:15:14] Zero King [Re: 290] >>> 职责?
[2018-07-21 09:15:35] Mingcong Bai [Re: 294] >>> 看第一条消息并保障消息符合上面的规定
[2018-07-21 09:15:37] 猫晴 弥柚 >>> 对了我黄油离0.1版不远了(好像一个月前也这么说 [photo]
[2018-07-21 09:15:43] OriginCode [Re: 290] >>> 职责(
[2018-07-21 09:15:48] Mingcong Bai [Fwd: Mingcong Bai] >>> 看第一条消息并保障消息符合上面的规定
[2018-07-21 09:15:56] OriginCode [Re: 298] >>> 了解(
[2018-07-21 09:15:57] Mingcong Bai >>> 看见 sticker 删,看见政治内容删
[2018-07-21 09:16:01] Mingcong Bai >>> 然后提醒那个人
[2018-07-21 09:16:14] Mingcong Bai >>> 除此之外的话,我们这个群是公开群
[2018-07-21 09:16:30] OriginCode >>> 像咱这种不能实时在会场的可以吗?
[2018-07-21 09:16:34] Mingcong Bai >>> 所以如果有 сука блять 进来就删
[2018-07-21 09:16:37] Mingcong Bai [Re: 303] >>> 可以
[2018-07-21 09:16:42] 迫真 正版 [Re: 304] >>> 哈哈哈哈
[2018-07-21 09:16:45] 迫真 正版 >>> 正确用途(不是
[2018-07-21 09:16:56] 迫真 正版 >>> 字面意义上的porn spam
[2018-07-21 09:17:06] Mingcong Bai >>> @OriginCode Promoted as admin
[2018-07-21 09:17:15] OriginCode [Re: 305] >>> 那咱要一个吧(伸手
[2018-07-21 09:17:21] Mingcong Bai [Re: 310] >>> Preempted (
[2018-07-21 09:17:35] OriginCode >>> 啊美国的漫游好慢(
[2018-07-21 09:17:35] Zero King [Re: 295] >>> IRC admin呢?
[2018-07-21 09:17:47] 迫真 正版 >>> [photo]
[2018-07-21 09:17:51] Mingcong Bai [Re: 313] >>> 是 @Icenowy ,但是她现在说太累了,所以今早我先顶着
[2018-07-21 09:17:52] OriginCode [Re: 313] >>> IRC 没法删信息啊
[2018-07-21 09:17:52] 迫真 正版 >>> 泡一壶有助睡眠
[2018-07-21 09:18:03] Mingcong Bai [Re: 316] >>> 踢人和设定 topic
[2018-07-21 09:18:09] Mingcong Bai >>> 所以活其实不多
[2018-07-21 09:18:11] 迫真 正版 >>> 可以警告三次然后开机票
[2018-07-21 09:18:15] OriginCode >>> 嗯
[2018-07-21 09:18:15] 迫真 正版 >>> 😁
[2018-07-21 09:18:32] Zero King [Re: 318] >>> 给我个op用来kick
[2018-07-21 09:18:42] Mingcong Bai [Re: 323] >>> 我看看我能不能做……
[2018-07-21 09:18:59] OriginCode [Re: 324] >>> chanserv 能做(
[2018-07-21 09:19:02] Mingcong Bai >>> 你的 IRC id 是什么
[2018-07-21 09:19:04] Mingcong Bai >>> @l2dy0
[2018-07-21 09:19:25] Mingcong Bai >>> l2dy?
[2018-07-21 09:19:31] Zero King >>> Yes.
[2018-07-21 09:19:55] 死 肥 宅 鹹魚 [Re: 270] >>> 吸毒 [photo]
[2018-07-21 09:20:16] Mingcong Bai [Re: 329] >>> 没有 mode 命令是什么情况
[2018-07-21 09:20:42] 迫真 正版 [Re: 330] >>> 我现在都有点不习惯镜面“自拍”屏了
[2018-07-21 09:20:46] Zero King [Re: 331] >>> 要看客户端吧
[2018-07-21 09:21:04] OriginCode [Re: 330] >>> 今天咱喝了一肚子水了
[2018-07-21 09:21:07] 死 肥 宅 鹹魚 [Re: 332] >>> 我這個算鏡面麼...
[2018-07-21 09:21:22] OriginCode [Re: 331] >>> /msg chanserv mode?
[2018-07-21 09:21:32] 死 肥 宅 鹹魚 >>> 這屏幕是屑(
[2018-07-21 09:21:38] OriginCode >>> 特首有管理员权限么(
[2018-07-21 09:21:51] Mingcong Bai [Re: 338] >>> 我目前 +o
[2018-07-21 09:21:59] 死 肥 宅 鹹魚 >>> 亮度不行色域不行還老反光(
[2018-07-21 09:22:00] OriginCode >>> 了解
[2018-07-21 09:22:07] 迫真 正版 [Re: 335] >>> 话说你这个是触屏吗(
[2018-07-21 09:22:12] 迫真 正版 >>> 好像还是电磁屏来着?
[2018-07-21 09:22:16] Mingcong Bai [Re: 341] >>> 看起来我没权限
[2018-07-21 09:22:17] 死 肥 宅 鹹魚 [Re: 342] >>> 是,還能用筆
[2018-07-21 09:22:18] Mingcong Bai >>> @lilyayta
[2018-07-21 09:22:33] OriginCode [Re: 345] >>> 羡慕(
[2018-07-21 09:22:34] Mingcong Bai >>> P50 真是好文明
[2018-07-21 09:22:35] 井生 羽衣 >>> [photo]
[2018-07-21 09:22:46] 迫真 正版 [Re: 348] >>> 电池(呕
[2018-07-21 09:23:00] Mingcong Bai [Re: 350] >>> True...
[2018-07-21 09:23:02] 迫真 正版 >>> 真的是T410s既视感
[2018-07-21 09:23:06] OriginCode [Re: 345] >>> 有 GNOME 体验吗?
[2018-07-21 09:23:07] liushuyu >>> 现在这个群非常考验你的大脑的任务调度能力(
[2018-07-21 09:23:21] 迫真 正版 [Re: 354] >>> 装个EXEC内核就可以了
[2018-07-21 09:23:22] 无聊怪 [Re: 349] >>> 好大一块下巴
[2018-07-21 09:23:23] Mingcong Bai [Re: 349] >>> MATE 用户这里有没有(
[2018-07-21 09:23:26] 无聊怪 >>> 😂
[2018-07-21 09:23:30] liushuyu [Re: 357] >>> 我!(
[2018-07-21 09:23:33] OriginCode [Re: 354] >>> Overflowed
[2018-07-21 09:23:36] 迫真 正版 >>> KDE用户这里有没有
[2018-07-21 09:23:38] 死 肥 宅 鹹魚 [Re: 353] >>> Hail KDE
[2018-07-21 09:23:44] liushuyu [Re: 361] >>> 有(
[2018-07-21 09:23:45] Mingcong Bai >>> Hail KDE (
[2018-07-21 09:23:51] 迫真 正版 [Fwd: Mingcong Bai] >>> Hail KDE (
[2018-07-21 09:23:56] 迫真 正版 >>> 自从换了KDE后
[2018-07-21 09:24:00] liushuyu >>> 复读机时间?
[2018-07-21 09:24:01] 井生 羽衣 [Re: 357] >>> xfce(
[2018-07-21 09:24:03] 迫真 正版 >>> ……算了广告不打了
[2018-07-21 09:24:05] 死 肥 宅 鹹魚 [Re: 363] >>> 你到底用啥(
[2018-07-21 09:24:12] 无聊怪 >>> /me MATE / KDE 用户
[2018-07-21 09:24:15] OriginCode [Re: 361] >>> AOSC OS GNOME,Arch Linux KDE
[2018-07-21 09:24:16] liushuyu [Re: 370] >>> 两台设备么
[2018-07-21 09:24:18] 死 肥 宅 鹹魚 [Re: 366] >>> 腰不疼了腿不酸了
[2018-07-21 09:24:22] Mingcong Bai [Re: 371] >>> This, is a wise man
[2018-07-21 09:24:31] 猫晴 弥柚 [Re: 361] >>> 有啊
[2018-07-21 09:24:43] liushuyu [Re: 374] >>> 头不疼了,就连心脏也不跳了(
[2018-07-21 09:24:54] Mingcong Bai [Re: 377] >>> 内核也 tickless 了
[2018-07-21 09:25:01] 死 肥 宅 鹹魚 [Re: 377] >>> Walking dead
[2018-07-21 09:25:13] Mingcong Bai >>> 下个议程还有 5 分钟(
[2018-07-21 09:25:21] OriginCode >>> Kernel Panic(
[2018-07-21 09:25:24] Lion [Re: 361] >>> 我呀😽
[2018-07-21 09:25:33] Mingcong Bai >>> 问个问题,我这里准备的资料是一大段的,主要是提了四五个建议
[2018-07-21 09:25:40] OriginCode >>> 凉透了
[2018-07-21 09:25:46] Mingcong Bai >>> 你们希望我一下全发出来还是一个一个来讨论?
[2018-07-21 09:26:22] 猫晴 弥柚 >>> 一下子发出来,然后一个一个讨论(
[2018-07-21 09:26:23] OriginCode >>> 一个一个讨论?
[2018-07-21 09:26:32] 迫真 正版 >>> 特首趁此机会练练打字吧(x
[2018-07-21 09:26:33] OriginCode [Fwd: 猫晴 弥柚] >>> 一下子发出来,然后一个一个讨论(
[2018-07-21 09:26:36] Mingcong Bai [Re: 386] >>> 啊这是前者
[2018-07-21 09:26:56] 死 肥 宅 鹹魚 [Re: 388] >>> 人肉 OCR(x
[2018-07-21 09:27:03] Mingcong Bai [Re: 388] >>> 啥(
[2018-07-21 09:27:12] 迫真 正版 [Re: 392] >>> 抄一遍(x
[2018-07-21 09:27:17] OriginCode [Re: 388] >>> 特首应该打好了(
[2018-07-21 09:27:28] liushuyu >>> 还有三分钟
[2018-07-21 09:27:28] Mingcong Bai [Re: 394] >>> 嗯我打好了(
[2018-07-21 09:27:36] OriginCode >>> 特首可以使用古老的手抄(
[2018-07-21 09:27:43] 迫真 正版 >>> “抄”送到tg文本框
[2018-07-21 09:27:47] 猫晴 弥柚 >>> 然后扫图上传
[2018-07-21 09:27:52] Mingcong Bai >>> @liushuyu You've gotta fix that... [photo]
[2018-07-21 09:27:58] Mingcong Bai [Re: 398] >>> hhhh
[2018-07-21 09:28:01] Mingcong Bai >>> 还没那么快(
[2018-07-21 09:28:11] OriginCode >>> 特首字如何?
[2018-07-21 09:28:33] Mingcong Bai [Re: 403] >>> 英文和俄语是连笔
[2018-07-21 09:28:36] Mingcong Bai >>> 中文一般
[2018-07-21 09:28:37] 迫真 正版 >>> 当成画画就行了(x
[2018-07-21 09:28:37] Zero King [Re: 385] >>> 全发的话pin吗?
[2018-07-21 09:28:46] liushuyu [Re: 400] >>> 善
[2018-07-21 09:28:49] Mingcong Bai [Re: 407] >>> 可以
[2018-07-21 09:28:49] 猫晴 弥柚 >>> 俄文手写体还是算了吧
[2018-07-21 09:28:53] OriginCode [Re: 405] >>> 求图(逃
[2018-07-21 09:28:54] 猫晴 弥柚 >>> 太恐怖了
[2018-07-21 09:29:01] 迫真 正版 >>> 我都没听说过pluma(
[2018-07-21 09:29:07] OriginCode [Fwd: 迫真 正版] >>> 我都没听说过pluma(
[2018-07-21 09:29:20] 迫真 正版 >>> 原来是mate的
[2018-07-21 09:29:23] 迫真 正版 >>> 行吧
[2018-07-21 09:29:25] 井生 羽衣 [Re: 389] >>> +1
[2018-07-21 09:29:28] 死 肥 宅 鹹魚 >>> 要對一個果凍進行處決(x [photo]
[2018-07-21 09:29:42] OriginCode >>> [document]
[2018-07-21 09:29:52] OriginCode >>> emm
[2018-07-21 09:29:55] OriginCode >>> 等等(
[2018-07-21 09:29:55] Mingcong Bai >>> @OriginCode 你这个狗管理怎么(
[2018-07-21 09:29:56] 迫真 正版 >>> 我现在在Windows下用geany了
[2018-07-21 09:29:58] 井生 羽衣 >>> 啊忘了買果凍了
[2018-07-21 09:29:59] OriginCode >>> 手贱了(
[2018-07-21 09:30:10] 迫真 正版 >>> 特首:反了
[2018-07-21 09:30:13] OriginCode [Re: 422] >>> 抱歉(
[2018-07-21 09:30:13] Mingcong Bai >>> [photo]
[2018-07-21 09:30:19] Mingcong Bai >>> Shall we begin?
[2018-07-21 09:30:20] 猫晴 弥柚 [Fwd: 井生 羽衣] >>> 啊忘了買果凍了
[2018-07-21 09:30:32] 井生 羽衣 >>> Ready
[2018-07-21 09:30:34] OriginCode [Re: 429] >>> y
[2018-07-21 09:30:36] Mingcong Bai >>> 那我全发出来了
[2018-07-21 09:31:01] Mingcong Bai >>> #TOPIC 9:30 - 10:30 — 调整 AOSC OS 的更新周期和里程碑计划集成
去年这个时候我提出让 AOSC OS 转入半滚动更新模型,提供 testing 和 master/bugfix 两个更新分支,并且采用一个基于月度的更新日程。很明显,目前虽然这个模型本身保持住了,但是“月度”更新的目标却远远没有达到(上次更新是四月底),而且这个时间上的拖延还导致了一些依赖更大范围更新的 bug 修复没能及时推送给非 testing 用户。最典型的例子是 Qt 和 GLVND 的 bug,导致 Plasma Desktop 和 Telegram Desktop 部分透明效果不可用,这个问题是五月底提出的,目前的计划是在 25 日推送的更新中修复。
简单总结就是下面几点:
— 我们的人力不允许月度更新。这不只是个“如何把握更新量”的问题,而是我们作为业余维护者时常能遇到的时间安排问题(比如我本人目前因为学业和校内工作导致的时间和精力不足)导致很多时候计划虽然能提出来,却很难能保证准时完成。
— 每个周期中缺乏一系列类似“里程碑”的大目标和主题,绝大多数工作都放到了追赶更新上而(和前两年一样)缺乏对现有发行版的修缮。
— 稳定和 testing 分支缺乏交互,后者提供的修复不能及时集成到稳定分支——而目前的时间周期问题导致了稳定用户并不能享受到太多的实际稳定性/可用性。
于是提出下面几点建议:
— 将更新周期拉长到一个季度,并且预留最后一个月用于测试和处理架构之间同步。
— 进一步扩大更新例外列表( https://wiki.aosc.io/developers/aosc-os/monthly-exceptions )的范围,尤其是 patch release 级别和 LTS 系列的更新(比如 kde-workspace 从 5.13.3 更新到 5.13.4)。
— 在每个周期中计划好软件更新的目标分支(KDE Plasma 大约每个季度会发布一个 LTS 分支,可以考虑让我们的更新日程结尾对齐到这种时间点,于是稳定用户可以跟着这个分支获取更新。
— 使用文档/Wiki 记录我们的更新周期日程和上述的判定过程(可以直接将现在的 Exceptions 页扩展为这个内容)。 [webpage]
[2018-07-21 09:31:05] Mingcong Bai [Re: 434] >>> pinned the message
[2018-07-21 09:31:35] Mingcong Bai >>> 总体来说这是我的设想,里面举了几个近两个月发现的问题,看看大家怎么想……
[2018-07-21 09:32:08] OriginCode >>> Telegram 的透明问题貌似现在还有?
[2018-07-21 09:32:18] Mingcong Bai [Re: 437] >>> 是的,这是目前 testing 里面才解决了的问题
[2018-07-21 09:32:22] Mingcong Bai >>> 通过更新 Qt
[2018-07-21 09:32:45] Mingcong Bai >>> 实际上如果 bugfix 里面推送了 Qt 5.10 系列的 patch release 也许能解决问题
[2018-07-21 09:32:49] OriginCode [Re: 438] >>> 了解(
[2018-07-21 09:32:56] Mingcong Bai >>> 就是这方面的做法还没有具体定义过
[2018-07-21 09:34:09] OriginCode >>> 以及还有些 Stable 源里面的打包失误(
[2018-07-21 09:34:21] 迫真 正版 >>> 季度还是不错的
[2018-07-21 09:34:35] Mingcong Bai [Re: 443] >>> 是的,我感觉目前 stable 出来之后维护是不够的
[2018-07-21 09:34:48] Mingcong Bai >>> 一个是用户完全得不到除了安全更新之外的任何更新
[2018-07-21 09:34:55] 死 肥 宅 鹹魚 >>> 資辭
[2018-07-21 09:35:08] Mingcong Bai >>> 一个是他们遇到问题修复起来也慢,或者像上面说的那样拖延很久
[2018-07-21 09:35:21] OriginCode >>> 嗯
[2018-07-21 09:35:54] Zero King >>> 那么我们应该偏好使用LTS版本?例如把node降到8。
[2018-07-21 09:36:04] Mingcong Bai [Re: 450] >>> 是的,这点我得请教下……
[2018-07-21 09:36:07] 猫晴 弥柚 >>> 我对‘更新’的过程不是很理解,无法实现自动化反馈的方案吗
[2018-07-21 09:36:26] Mingcong Bai >>> 我上面提到,如果我们用季度更新,那么是否应该在每个季度周期前计划好对齐到什么版本?
[2018-07-21 09:36:44] Mingcong Bai >>> “在每个周期中计划好软件更新的目标分支(KDE Plasma 大约每个季度会发布一个 LTS 分支,可以考虑让我们的更新日程结尾对齐到这种时间点,于是稳定用户可以跟着这个分支获取更新。”
[2018-07-21 09:36:50] Mingcong Bai [Re: 452] >>> 能稍微解释下吗?
[2018-07-21 09:36:54] OriginCode >>> 最近 LTS 版本?
[2018-07-21 09:37:09] Mingcong Bai [Re: 456] >>> 嗯比如我假设三个月后 Plasma 要发布 5.15,是个 LTS
[2018-07-21 09:37:15] Mingcong Bai >>> 那么我们应该努力对齐那个版本分支
[2018-07-21 09:37:24] OriginCode >>> 对
[2018-07-21 09:37:29] Mingcong Bai >>> 然后 bugfix 在接下来一个周期都会得到 5.15.x 的更新
[2018-07-21 09:37:32] Zero King >>> +1
[2018-07-21 09:37:38] liushuyu [Re: 454] >>> 如果某个软件提供 mainline 和 LTS 我觉得需要看情况
[2018-07-21 09:37:38] Lion [Re: 452] >>> 下一节我的部分会有详细描述。目前主要靠人力、GitHub 项目半自动、repology 网站辅助,等。
[2018-07-21 09:37:44] 死 肥 宅 鹹魚 >>> 資辭(
[2018-07-21 09:37:46] liushuyu >>> 不一定要用 LTS
[2018-07-21 09:37:54] Mingcong Bai [Re: 465] >>> 这怎么说?
[2018-07-21 09:38:03] OriginCode [Re: 458] >>> 但是不同组件的 LTS 版本释出周期不同如何解决?
[2018-07-21 09:38:09] liushuyu [Re: 466] >>> 比如 Java
[2018-07-21 09:38:10] Mingcong Bai [Re: 467] >>> 这确实是个问题
[2018-07-21 09:38:24] Mingcong Bai >>> 大的项目一般都会有个固定的 LTS 周期
[2018-07-21 09:38:25] liushuyu >>> 还有 LMMS 之流
[2018-07-21 09:38:40] liushuyu >>> LTS 远比 mainline 老的软件
[2018-07-21 09:38:43] Mingcong Bai >>> 而且我有点怀疑这么做的话很可能会制约 testing 方面的更新(因为不敢跳到下个分支
[2018-07-21 09:39:06] 无聊怪 >>> 那就需要分成两个分支了
[2018-07-21 09:39:08] Mingcong Bai [Re: 472] >>> 特例肯定是有的
[2018-07-21 09:39:15] Mingcong Bai [Re: 474] >>> 嗯?
[2018-07-21 09:39:19] 无聊怪 >>> stable 提供 lts 软件包
[2018-07-21 09:39:33] Zamir SUN >>> 我赞成季度(甚至半年)一个周期
[2018-07-21 09:39:36] 无聊怪 >>> 另一个分支提供 mainline 的
[2018-07-21 09:39:38] OriginCode >>> 干脆变成 AOSC OS LTS (
[2018-07-21 09:39:51] Lion >>> “这不只是个如何把握更新量的问题,而是我们作为业余维护者时常遇到的时间安排问题导致很多时候计划虽然能提出来,却很难保证准时完成” 这一部分我感觉有点争议
[2018-07-21 09:39:56] Uncle Lin >>> [chat_add_user]
[2018-07-21 09:39:57] Sakamoto Tanmy >>> 插嘴:没有直播不开心(
[2018-07-21 09:39:58] Mingcong Bai [Re: 479] >>> LTS, Mainline, Testing?
[2018-07-21 09:40:02] 死 肥 宅 鹹魚 >>> AOSC OS Leap, AOSC OS Tumbleweed(x
[2018-07-21 09:40:03] 井生 羽衣 >>> 以及萬一某個軟件的 LTS 版本咕了(推遲發佈了)怎麼辦
[2018-07-21 09:40:04] Mingcong Bai [Re: 483] >>> 哪来的直播
[2018-07-21 09:40:12] OriginCode [Re: 485] >>> Nice(
[2018-07-21 09:40:27] 无聊怪 [Re: 484] >>> 其实我也不太清楚 Testing 跟 mainline 怎么处理比较好
[2018-07-21 09:40:32] OriginCode >>> 还有已经消失的 Factory
[2018-07-21 09:40:34] Mingcong Bai [Re: 484] >>> 我对这种设定原则上没有什么反对,但是…… 工作量会很大
[2018-07-21 09:40:36] Zero King >>> 我提到node主要是node的安全更新如果是非LTS就很可能要升minor release了。
[2018-07-21 09:40:42] Zamir SUN [Re: 478] >>> 但觉得 bugfix 应该尽量及时
[2018-07-21 09:40:45] Mingcong Bai [Re: 492] >>> 嗯这个是
[2018-07-21 09:40:50] 无聊怪 >>> 现在的想法是 testing 是用于测试 lts 软件包的
[2018-07-21 09:41:02] Mingcong Bai [Re: 493] >>> 我觉得现在 bugfix 是一个做好就不更新的分支
[2018-07-21 09:41:10] OriginCode [Re: 495] >>> 这样 testing 太滞后了吧(
[2018-07-21 09:41:14] Mingcong Bai >>> 我们应该更积极维护
[2018-07-21 09:41:14] 无聊怪 >>> mainline 则是现在的 testing
[2018-07-21 09:41:34] liushuyu [Re: 477] >>> 这个我觉得可以,还有 mainline 和 LTS 不兼容的问题,Java 11 有 arm 的 hs 但是不完全向下兼容 Java 8
[2018-07-21 09:41:36] Mingcong Bai [Re: 481] >>> 具体说说?
[2018-07-21 09:41:46] Lion [Re: 481] >>> 我觉得最直接的问题是我们没有把冻结真正做到位。一个仅仅和时间挂钩的周期,应该是尽可能无视上游更新的量,而仅仅在每个月有限的时间内做能做的事情。
[2018-07-21 09:42:01] Mingcong Bai [Re: 502] >>> 嗯这个我上面提到了
[2018-07-21 09:42:03] Zamir SUN >>> 我不是指 bugfix分支,而是说,对于 bug 的修复(而不是更新版本)要仍然有保障(例如一个月。?)
[2018-07-21 09:42:11] Zero King [Re: 500] >>> Java可以打多个包
[2018-07-21 09:42:20] Lion >>> 换句话说,“以清空更新” 为目的,不可能真正落实周期制度
[2018-07-21 09:42:30] liushuyu [Re: 505] >>> 对,就是这么想的
[2018-07-21 09:42:34] Zamir SUN [Re: 502] >>> 赞同狮子
[2018-07-21 09:42:40] Mingcong Bai [Re: 502] >>> 我这个观点主要说的是周期太短很容易由于时间安排上的突发事件会造成问题
[2018-07-21 09:42:50] Lion >>> 要划定时间的强制限制,允许堆积未完成的任务
[2018-07-21 09:43:09] Mingcong Bai >>> 因为如果一直赶着要做完你是不可能上周期的
[2018-07-21 09:43:15] Lion [Re: 509] >>> 哪怕有这些突发的出入,我觉得也是可以接受的
[2018-07-21 09:43:33] Mingcong Bai [Re: 512] >>> 我假设一下
[2018-07-21 09:43:38] liushuyu >>> 所以需要 stage 变更
[2018-07-21 09:43:40] OriginCode >>> 这样?:
KDE LTS 组件更新 - Bugfix... - GNOME LTS 组件更新 - Bugfix
[2018-07-21 09:43:48] Mingcong Bai >>> 我从现状说,我和 @colin4124 两个人是主要的打包者
[2018-07-21 09:44:03] Mingcong Bai >>> 如果我在月初要准备 paper,两周没法干太多事情
[2018-07-21 09:44:10] Mingcong Bai >>> @colin4124 刚好又身体不舒服(假设
[2018-07-21 09:44:11] liushuyu >>> 比方说 staging 在 freeze 之后,如果有东西需要更新
[2018-07-21 09:44:17] Mingcong Bai >>> 那么我们实际上剩下的时间也不多了
[2018-07-21 09:44:30] Mingcong Bai >>> (当然这和车祸指数也有关系
[2018-07-21 09:44:35] Lion [Re: 520] >>> 我觉得这种“闲月”是可以接受的
[2018-07-21 09:44:41] Mingcong Bai [Re: 522] >>> 嗯?
[2018-07-21 09:45:04] Mingcong Bai [Re: 514] >>> 我还是担心三层更新会造成工作量飙升
[2018-07-21 09:45:17] Lion >>> 相反,如果因为车祸指数太低了,导致时间波动而一直放大时间的弹性,这个周期就被破坏了
[2018-07-21 09:45:20] Mingcong Bai >>> 这样的话实际上需要三份系统同时测试
[2018-07-21 09:45:43] Mingcong Bai [Re: 525] >>> 车祸指数在这里说的是主要维护者/技能比较完全者的数量之少
[2018-07-21 09:45:48] Lion >>> 我觉得周期不能动才是关键,哪怕是每月或是每两月
[2018-07-21 09:46:24] Lion [Re: 527] >>> y,我知道。我指的是人少所以每个人有自己的事情的概率会很大程度影响到最终效果
[2018-07-21 09:46:44] OriginCode >>> 要不要去宣传一波 AOSC 招点人力?(逃
[2018-07-21 09:46:55] Mingcong Bai [Re: 530] >>> 我们先暂时不讨论这个问题……
[2018-07-21 09:47:25] Lion [Re: 529] >>> 噢,不是概率,是波动
[2018-07-21 09:48:08] Mingcong Bai >>> 定个具体时间固然是好,但是我们需要允许测试时间不足而导致的跳票情况?
[2018-07-21 09:48:57] Lion [Re: 533] >>> 是,这本来就是周期所暗示的结果
[2018-07-21 09:49:49] Lion >>> “很不幸,这个xx包这周期不能进了,但其他已经打好的包我们将要 ship 了。这个包下周期进。”
[2018-07-21 09:50:58] Lion >>> 如果用 “不跳票” 来限制我们自己,相反拖延了其他的包,让一堆的包跟着拖延…我感觉某种意义上这才是大规模的跳票吧
[2018-07-21 09:51:19] Mingcong Bai >>> 嗯
[2018-07-21 09:51:30] Mingcong Bai >>> 我先整理下上面我们集到的点子
[2018-07-21 09:53:27] Mingcong Bai >>> — 总体赞成延长周期到季度
— 固定每个周期的截止时间并且尽量地去保证准时
— 考虑增加一个新的测试级别(LTS,长期稳定,仅接受 LTS 和 patch release 更新;Testing,测试 LTS 分支的更新;Mainline,对应现在的 staging 分支);那么,要如何去计划这方面的工作,如何去符合季度周期? cc @sakiiily
[2018-07-21 09:53:36] Mingcong Bai >>> 上述几点是否准确?
[2018-07-21 09:54:54] 无聊怪 >>> 对
[2018-07-21 09:55:03] Mingcong Bai >>> @Lionium
[2018-07-21 09:55:37] Mingcong Bai >>> 那么假设我们需要这么做,可以考虑让 Mainline 在三个月内自由追赶更新,Testing 做 LTS 分支服务,而 LTS 只接受 Merge?
[2018-07-21 09:55:37] Lion >>> 第二点总结得没问题
[2018-07-21 09:56:11] Mingcong Bai >>> 那么也就是说 Mainline 达到新的分支之前,Testing 分支去跟 patch release
[2018-07-21 09:56:17] Mingcong Bai >>> 而 LTS 接受 Testing 测试过的包
[2018-07-21 09:56:33] Mingcong Bai >>> ……那么 Mainline 还有没有必要接受季度周期的制约?
[2018-07-21 09:57:06] 井生 羽衣 >>> 第三點我有些沒聽明白……就是說 Mainline 是否還專門測試?
[2018-07-21 09:57:22] Mingcong Bai [Re: 548] >>> Mainline 是个无主之地
[2018-07-21 09:57:47] Mingcong Bai >>> Testing 接受 Mainline 收到的新分支更新
[2018-07-21 09:58:00] Lion >>> [document]
[2018-07-21 09:58:00] Mingcong Bai >>> 但是具体怎么处理这两个分支里面的 patch release 更新,我没什么头绪……
[2018-07-21 09:58:30] Mingcong Bai >>> 我尝试画个图
[2018-07-21 09:59:07] 井生 羽衣 >>> 啊我沒看到 mainline 對應當前的 staging
[2018-07-21 09:59:18] 井生 羽衣 >>> 這樣就理解了
[2018-07-21 09:59:21] 死 肥 宅 鹹魚 >>> 還有個相關的問題,源上面的目錄結構能否做到像 Debian 那樣在鏈接結尾加上類別名稱就能添加對應類別
比如 https://mirrors.blablabla.tld/debian main contrib 什麼的這樣
[2018-07-21 09:59:44] 死 肥 宅 鹹魚 >>> 現在這樣要添加源相對麻煩一些
[2018-07-21 10:00:10] Mingcong Bai >>> (画不好
[2018-07-21 10:00:17] Mingcong Bai >>> 我稍微总结下
[2018-07-21 10:01:06] Lion [Re: 556] >>> 应该是可以的,之前主群有过讨论。唯一的问题是怎么过渡比较平滑
[2018-07-21 10:01:27] Lion >>> “非扁平源结构”
[2018-07-21 10:01:29] 井生 羽衣 >>> 主要是 mainline 這個名字很難讓人一下子反應過來它比 testing 更不「穩定」
[2018-07-21 10:01:39] Lion [Re: 562] >>> true
[2018-07-21 10:01:40] Mingcong Bai >>> — Mainline 是现在的 staging,不受周期制约(?),追赶一切更新
— Testing 接受 staging 的 LTS 分支更新(但是没有 LTS 定义的上游怎么处理?)
— LTS 接受测试过的 LTS 分支更新,并且接受 LTS 分支的 patch release 更新;Testing 在 LTS 接受某个分支后可以考虑继续接受 Mainline 的分支更新
[2018-07-21 10:01:53] Mingcong Bai [Re: 563] >>> 嗯,我们先看看这个逻辑能不能行得通吧
[2018-07-21 10:01:55] OriginCode [Re: 562] >>> 那 beta,alpha?
[2018-07-21 10:02:26] Mingcong Bai [Re: 564] >>> 现在的一个空洞在于 Testing 怎么判断接受哪部分的更新
[2018-07-21 10:02:57] 死 肥 宅 鹹魚 [Re: 562] >>> Unstable(學習 Debiantai
[2018-07-21 10:03:32] Lion >>> Debian 似乎有个叫做 Sid 的?
[2018-07-21 10:03:36] Zero King >>> 以及mainline不受制约怎么保证下个周期的LTS?
[2018-07-21 10:03:48] Lion >>> 有人简单介绍一下 Debian 的前沿版本之间的关系吗
[2018-07-21 10:04:10] 死 肥 宅 鹹魚 [Re: 569] >>> 也叫 Unstable(似乎
[2018-07-21 10:04:26] Mingcong Bai [Re: 570] >>> 是,不好把握
[2018-07-21 10:04:36] Mingcong Bai >>> 有 LTS 分支的上游很明显
[2018-07-21 10:04:43] Mingcong Bai >>> 但是没有的话就很难了
[2018-07-21 10:05:02] Mingcong Bai >>> 或者说我感觉只能通过人为判定
[2018-07-21 10:05:47] 死 肥 宅 鹹魚 >>> Debiantai 的命名 [photo]
[2018-07-21 10:06:31] Lion [Re: 575] >>> 我感觉会遇到很棘手的版本的问题,特别是如果我们没有相当的 backport 技术能力的话
[2018-07-21 10:06:56] 无聊怪 >>> 无 LTS 上游可以参考 debian 什么的版本号?
[2018-07-21 10:07:08] Mingcong Bai [Re: 578] >>> 这个问题会在什么情况出现?
[2018-07-21 10:07:20] Mingcong Bai >>> (类似 Qt 半透明的问题?
[2018-07-21 10:07:54] Lion >>> 我举个例子,有包 A 1-lts,有包 B 1,B 1 依赖 A 1。
[2018-07-21 10:08:34] Lion >>> 后来上游 B 更新为 B 3,我们的 LTS 线基本不动它
[2018-07-21 10:08:53] Lion >>> 但万一有一天出现安全漏洞,必须将 B 1 升级为 B 3+
[2018-07-21 10:09:19] Lion >>> 而 B 3 以后的版本已经不能再依赖 A 1-lts 了,至少要 A 2
[2018-07-21 10:09:52] Lion >>> 那么就有软件包要被 “拖出” lts 版本了
[2018-07-21 10:10:05] Mingcong Bai >>> 其实这种情况,安全更新我们不是 100% 要保证推送的……
[2018-07-21 10:10:14] Mingcong Bai >>> 比如现在的 liblouis 和 ffmpeg 安全漏洞
[2018-07-21 10:10:24] Mingcong Bai >>> 我们根本不会考虑推送到稳定
[2018-07-21 10:10:50] Mingcong Bai >>> ¹ https://github.com/AOSC-Dev/aosc-os-abbs/issues/1208
² https://github.com/AOSC-Dev/aosc-os-abbs/issues/1293 [webpage]
[2018-07-21 10:11:08] Mingcong Bai >>> cc @量
[2018-07-21 10:11:40] Lion >>> 所以我感觉 LTS 的维护,主要就是固定版本后,backport。那么如果我们又 backport 不成,就只好按需推进版本。
[2018-07-21 10:12:55] Lion >>> 当然发行版打包本身的问题,是直接修修就好了。主要是怕上游的 bug 修复很难轻巧地做进 LTS 线里。
[2018-07-21 10:13:09] Mingcong Bai >>> 我感觉这种案例其实不多
[2018-07-21 10:13:17] Mingcong Bai >>> 遇到了我们也可以集中去解决一下
[2018-07-21 10:14:47] Lion >>> 因为上面说的,lts 包评判标准不确定。那么就有可能对包版本集合的“前沿”判断不准确,会不会有什么影响。是这样的一个疑惑
[2018-07-21 10:14:59] Mingcong Bai >>> 啊你是这个意思……
[2018-07-21 10:15:16] Mingcong Bai >>> 虽然我必须说,需要掐分支的时候,这种风险基本不可能避免……
[2018-07-21 10:15:34] Mingcong Bai >>> 就算我们的知识体系很完善,比如我们知道 GNOME 3.28 是当前稳定而 3.29 是很明显不稳定的版本
[2018-07-21 10:15:50] Mingcong Bai >>> 我们依然不能避免 GNOME 后来出个漏洞但是只在 3.29 上修复
[2018-07-21 10:16:15] Mingcong Bai >>> 其实这个情况在 liblouis 这种不用 patch release(也就是 x.y.z 里面 z)更新的包最常见
[2018-07-21 10:16:20] Mingcong Bai >>> 他们每次发布新版本都会出安全问题
[2018-07-21 10:16:35] Mingcong Bai >>> 而每次安全问题是包含在一个 ABI 甚至 API 不兼容的包里面的
[2018-07-21 10:16:57] Mingcong Bai [Fwd: fpsNoooob] >>> 🌚🔫但是 testing 没人权
[2018-07-21 10:16:57] Mingcong Bai [Fwd: fpsNoooob] >>> 比如现在的 shadowsocks-libev 🤣🤣🤣
[2018-07-21 10:16:57] Mingcong Bai [Fwd: Robobo] >>> Package: shadowsocks-libev
old-bpo: 2.6.3+ds-3+deb9u1~bpo8+1
old-bpo-sl: 3.2.0+ds-3~bpo8+1
stable: 2.6.3+ds-3+deb9u1
stable-sec: 2.6.3+ds-3+deb9u1
stable-bpo: 3.2.0+ds-3~bpo9+1
unstable: 3.2.0+ds-3
[2018-07-21 10:17:01] Mingcong Bai >>> 刚好看见我就转过来了
[2018-07-21 10:17:15] Mingcong Bai >>> Debian 的分支管理很严格,代价也很重
[2018-07-21 10:17:47] Lion >>> 感觉像 RedHat 系之类的充满 LTS 味的发行版就基本靠 backport 来维护安全
[2018-07-21 10:18:30] Lion >>> Arch Gentoo 这些日滚夜滚(指更新频率高)的,直接靠跟上去最新版本来维护安全
[2018-07-21 10:18:33] Mingcong Bai >>> 对
[2018-07-21 10:18:51] Mingcong Bai >>> 我们刚好处于一个又追新又想保障分支稳定的……
[2018-07-21 10:18:53] Mingcong Bai >>> 很尴尬
[2018-07-21 10:19:27] Mingcong Bai [Re: 606] >>> 不过这个例子里面我指的是挑选分支的时候的一种后果(不过我们有 Exception 所以应该会好一点
[2018-07-21 10:20:40] 死 肥 宅 鹹魚 [Re: 610] >>> Gentoo 的穩定分支差不多是跟 Debian 一個級別的(老)
[2018-07-21 10:21:11] Mingcong Bai >>> 另外一个选择是,让 Mainline 只能跟 Mainline 而不能去跟明显的测试和不稳定分支
[2018-07-21 10:21:20] Mingcong Bai >>> 包括 Node 也只能在 LTS 之间跳
[2018-07-21 10:21:28] Mingcong Bai >>> GNOME 不能上 3.29 或者任何单数 minor
[2018-07-21 10:21:56] Mingcong Bai >>> 但是其他无明显分支项目比如 Coreutils
[2018-07-21 10:22:11] Mingcong Bai >>> 那么就根据 Testing 分支的时间需要来引入更新,然后充分测试
[2018-07-21 10:22:21] Mingcong Bai >>> LTS 分支不接受任何无明显分支界定的更新
[2018-07-21 10:22:37] Mingcong Bai >>> 只在 Testing 每季度结尾测试充分后并入到 LTS
[2018-07-21 10:23:48] Lion >>> (我们能暂时换一个准确的名字来讨论这个方案吗)
[2018-07-21 10:24:00] Mingcong Bai [Re: 623] >>> “三分支模型”?
[2018-07-21 10:24:08] Mingcong Bai >>> 还是说每个分支的名字
[2018-07-21 10:24:12] Lion >>> 比如 testing, lts-testing, lts?
[2018-07-21 10:24:41] Mingcong Bai >>> 我暂时这么叫吧,先不讨论名字:Chimera 不稳定分支,Testing 稳定测试分支,Stable 稳定分支
[2018-07-21 10:24:57] Mingcong Bai >>> Chimera 是三头六身怪兽,不详细解释了
[2018-07-21 10:26:44] Lion >>> 现在谈的是一个新的可选方案对吧……暂时用准确的贴近当前定义的名字,避免修辞吧。
[2018-07-21 10:26:49] Mingcong Bai >>> 重新整理下就是这样:
— Chimera 不接受不稳定和测试版本/分支(无明显分支界定的不能打任何 beta/rc,不接受 GNOME 3.29 这类明显的不稳定分支,Node 这类明显需要保障分支内安全更新的在 LTS 分支之间跳),但是不接受季度时间限制
— Testing 在季度周期(假设两个月更新,一个月测试)内引入新的 LTS 和稳定分支,无明显分支的也引入,但是要在第二个月结尾截止,然后一个月测试
— Stable 只在三个月内提供当前 LTS 分支和稳定分支内的 patch release 更新(比如 GNOME 3.28.1 到 3.28.3
[2018-07-21 10:27:01] Mingcong Bai >>> 大概是这么一回事
[2018-07-21 10:27:15] 井生 羽衣 >>> 所以說新的方案除了週期長度和 exception 之外,和 debian 模型最主要有哪些差別?
[2018-07-21 10:27:33] Mingcong Bai [Re: 632] >>> 具体测试方法不同
[2018-07-21 10:27:40] Mingcong Bai >>> 除此之外确实没有别的不同
[2018-07-21 10:28:01] Lion >>> 目前讨论的有多少个可选方案?
[2018-07-21 10:28:07] Mingcong Bai [Re: 630] >>> 另外暂时提出 Exception 针对 Stable 分支,基于现有的列表看
[2018-07-21 10:28:14] Mingcong Bai [Re: 635] >>> 就这一个
[2018-07-21 10:28:17] Lion >>> 原始方案扩展为季度的方案,以及这个?
[2018-07-21 10:28:19] Mingcong Bai >>> 时间周期是季度,三个分支
[2018-07-21 10:28:20] Mingcong Bai >>> 对
[2018-07-21 10:28:37] Lion [Re: 637] >>> wut,刚才说的那个那么快就采纳了吗
[2018-07-21 10:28:49] Mingcong Bai >>> 我没说采纳
[2018-07-21 10:28:57] Mingcong Bai >>> 而是目前没人提出另一个方案
[2018-07-21 10:29:13] Mingcong Bai >>> 所以我就在努力去填满现有的方案了
[2018-07-21 10:29:43] Mingcong Bai >>> 另外提醒下下个议程开始时间还有半小时,假设半小时内没有结论就用后面的空位继续讨论
[2018-07-21 10:30:35] Mingcong Bai >>> @Lionium 愿意继续跟着这个思路走吗,还是我们应该重新讨论一次?
[2018-07-21 10:30:42] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 636] >>> +1
[2018-07-21 10:30:42] 死 肥 宅 鹹魚 >>> 我覺得海星,就是工作量怕是又增加了...
[2018-07-21 10:30:57] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 测试可能需要大规模部署 burnable vm
[2018-07-21 10:31:00] Mingcong Bai [Re: 648] >>> 工作量增加肯定是的了……
[2018-07-21 10:31:07] Mingcong Bai >>> 不过主要还是测试上
[2018-07-21 10:31:10] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> (LVM 无所畏惧
[2018-07-21 10:31:12] Mingcong Bai >>> 更新软件包实际上不需要多少时间的
[2018-07-21 10:31:31] 死 肥 宅 鹹魚 >>> 人太少(
[2018-07-21 10:31:35] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 但是 nvidia 之类直接访问硬件的软件会受局限
[2018-07-21 10:31:59] Mingcong Bai [Re: 655] >>> 这种肯定需要实地测试的
[2018-07-21 10:31:59] 猿渡 美晴 >>> [chat_add_user]
[2018-07-21 10:32:29] Staph. aureus | In your GI Tract >>> SITS 有 NVIDIA 顯示卡,如果需要測試可以聯絡我
[2018-07-21 10:32:47] Lion [Re: 646] >>> 没问题,只是这个规模感觉开展起来比较艰难
[2018-07-21 10:32:57] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 658] >>> 最佳方案是 burnable vm,测试需要的硬件的时候 pass thru
[2018-07-21 10:33:11] Mingcong Bai [Re: 659] >>> 不过依然要考虑时间上
[2018-07-21 10:33:14] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 不止是 nv
[2018-07-21 10:33:15] Lion [Re: 651] >>> 不是,不仅仅在测试上
[2018-07-21 10:33:21] Mingcong Bai >>> 做不完的事情要收手
[2018-07-21 10:33:32] Mingcong Bai >>> 这直接影响我们到底能有多新
[2018-07-21 10:33:42] Lion >>> 如果这样的话,我们的仓库拓扑可能又要变了
[2018-07-21 10:33:51] Mingcong Bai >>> 嗯,三个仓库了
[2018-07-21 10:33:55] Mingcong Bai >>> 三个分支
[2018-07-21 10:34:01] Zero King >>> 提议提高安全更新的优先级
[2018-07-21 10:34:08] Zero King >>> 尽量不跳安全更新
[2018-07-21 10:34:26] Mingcong Bai [Re: 670] >>> 以 Stable 上其他任何更新为代价去保障安全更新,是这样吗
[2018-07-21 10:34:37] Zero King [Fwd: Mingcong Bai] >>> 其实这种情况,安全更新我们不是 100% 要保证推送的……
[2018-07-21 10:34:37] Zero King [Fwd: Mingcong Bai] >>> 比如现在的 liblouis 和 ffmpeg 安全漏洞
[2018-07-21 10:34:37] Zero King [Fwd: Mingcong Bai] >>> 我们根本不会考虑推送到稳定
[2018-07-21 10:35:08] Zero King >>> 就是不能直接在bugfix上修复的
[2018-07-21 10:35:18] Zero King >>> 优先在staging修复
[2018-07-21 10:37:24] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 689] >>> 注意
[2018-07-21 10:37:29] Mingcong Bai [Re: 686] >>> 层叠
[2018-07-21 10:37:34] Mingcong Bai >>> 版本必定有别
[2018-07-21 10:37:44] Mingcong Bai >>> Stable 也不会比 Testing 新,以此类推
[2018-07-21 10:37:45] 井生 羽衣 [Re: 689] >>> 噢
[2018-07-21 10:37:48] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 这将会导致不同 branch 有相同版本号的同一个包
[2018-07-21 10:38:16] Mingcong Bai [Re: 696] >>> 这个情况需要设定源优先级或者像现在的情况下,bump REL
[2018-07-21 10:38:16] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 需要刻意在 faster ring 上 bump rel
[2018-07-21 10:38:22] Mingcong Bai >>> 对,需要做这件事情
[2018-07-21 10:38:53] Lion [Re: 696] >>> 这个情况要避免的,解决方法是加 rel,至于自动化检测则是另外的话题了
[2018-07-21 10:39:02] Lion >>> 🌝
[2018-07-21 10:39:11] Mingcong Bai >>> 我再总结一次?
[2018-07-21 10:40:34] Leway Colin >>> 嗯
[2018-07-21 10:40:51] Staph. aureus | In your GI Tract [Re: 696] >>> 好奇下這樣會出問題嗎?
[2018-07-21 10:40:52] 井生 羽衣 [Re: 689] >>> 這麼說來這也是和 debian 模型的一個不同之處了?
[2018-07-21 10:41:27] Staph. aureus | In your GI Tract >>> 如果不同 Branch 有同一個版本的同一個包,應該包內容是一致的吧?
[2018-07-21 10:41:33] Lion >>> 唔。如果说周期工作一定要给一些包开例外的话,也应该保证最基本的一点空闲时间是绝对不允许例外的。类似于 “绝对不应期” 的数天或者一周。
[2018-07-21 10:41:53] Mingcong Bai >>> 关于分支定义:
— Chimera 不接受不稳定和测试版本/分支(无明显分支界定的不能打任何 beta/rc,不接受 GNOME 3.29 这类明显的不稳定分支,Node 这类明显需要保障分支内安全更新的在 LTS 分支之间跳),但是不接受季度时间限制
— Testing 在季度周期(假设两个月更新,一个月测试)内引入新的 LTS 和稳定分支,无明显分支的也引入,但是要在第二个月结尾截止,然后一个月测试
— Stable 只在三个月内提供当前 LTS 分支和稳定分支内的 patch release 更新(比如 GNOME 3.28.1 到 3.28.3)
安全更新和 Exception:
— 安全更新首要保证 Stable,假设无法通过任何手段保障 Stable,则向稳定性更低的方向走(Testing,Testing 不行就到 Chimera)
— Exception 更新推送到 Stable(当然,需要测试)
— 如果 Stable 版本因为安全或 Exception 比任何其他分支的版本高则需要 cherry-pick 到稳定性更低的分支,并且 bump REL 以保障其他分支的更新
[2018-07-21 10:42:09] Mingcong Bai [Re: 707] >>> 这个我们可能要开第二次讨论了
[2018-07-21 10:42:15] Mingcong Bai >>> 不过我们概念上可以确定下
[2018-07-21 10:42:33] Lion [Re: 707] >>> 这最后的一点作为周转和这些例外的紧急测试时间
[2018-07-21 10:42:35] Zero King [Re: 678] >>> 浪费太多精力就不值得了。我这个提议是针对“做不完的事情要收手”。
[2018-07-21 10:42:48] Mingcong Bai >>> 假设我们三个月的周期,两个月打包,第三个月 freeze Testing 和 Stable,则这个时间段里面不接受 Exceptions 更新
[2018-07-21 10:43:25] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 706] >>> 不一致
[2018-07-21 10:43:30] Mingcong Bai [Re: 712] >>> 知会
[2018-07-21 10:43:40] Mingcong Bai [Re: 706] >>> 每分支重构
[2018-07-21 10:43:44] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 706] >>> 下面可能 ld 不同的 so version.
[2018-07-21 10:43:49] Lion [Re: 706] >>> 可能不一致,但首先就不能这么打
[2018-07-21 10:44:03] Mingcong Bai >>> 我们需要保证越不稳定的分支里面版本越新
[2018-07-21 10:44:17] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 大批考古在处理不同源的行为不太明朗
[2018-07-21 10:44:19] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> * dpkg
[2018-07-21 10:44:33] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 或者说是 apt
[2018-07-21 10:44:40] Lion [Re: 706] >>> 我在主群跟你说说包的各种唯一性问题吧
[2018-07-21 10:44:48] Mingcong Bai >>> 假设 Stable 里面有 Thunderbird 52.9.2,那么 cherry-pick 到另外两个分支的时候则需要让 Testing 得到 52.9.2-1 而 Chimera 得到 52.9.2-2
[2018-07-21 10:45:03] Mingcong Bai [Re: 724] >>> @cth451 正确?
[2018-07-21 10:45:04] 死 肥 宅 鹹魚 [Re: 720] >>> (大批考古 hhhh)
[2018-07-21 10:45:07] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 725] >>> Yep
[2018-07-21 10:45:11] Mingcong Bai >>> K
[2018-07-21 10:45:21] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 否则没人知道 apt 会选择哪个
[2018-07-21 10:46:54] Mingcong Bai >>> 关于分支定义:
— Chimera 不接受不稳定和测试版本/分支(无明显分支界定的不能打任何 beta/rc,不接受 GNOME 3.29 这类明显的不稳定分支,Node 这类明显需要保障分支内安全更新的在 LTS 分支之间跳),但是不接受季度时间限制
— Testing 在季度周期(假设两个月更新,一个月测试)内引入新的 LTS 和稳定分支,无明显分支的也引入,但是要在第二个月结尾截止,然后一个月测试
— Stable 只在三个月内提供当前 LTS 分支和稳定分支内的 patch release 更新(比如 GNOME 3.28.1 到 3.28.3)
安全更新和 Exception:
— 安全更新首要保证 Stable,假设无法通过任何手段保障 Stable,则向稳定性更低的方向走(Testing,Testing 不行就到 Chimera)
— Exception 更新推送到 Stable(当然,需要测试)
— 如果 Stable 版本因为安全或 Exception 比任何其他分支的版本高则需要 cherry-pick 到稳定性更低的分支,并且 bump REL 以保障其他分支的更新(假设 Stable 里面有 Thunderbird 52.9.2,那么 cherry-pick 到另外两个分支的时候则需要让 Testing 得到 52.9.2-1 而 Chimera 得到 52.9.2-2)
周期集成:
— Chimera 不接受周期管制
— Testing 和 Stable 接受周期管制,而且有冻结期(假设第二个月后季度结余时间作为冻结期)
— 冻结期内不接受任何 Exception 类更新
— Stable 在冻结期内接受安全更新
[2018-07-21 10:47:10] Mingcong Bai >>> @cth451 @Lionium @l2dy0 请验证内容准确性
[2018-07-21 10:47:49] Mingcong Bai >>> 各位感觉这样的一个设计可否接受?
[2018-07-21 10:47:58] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> OK
[2018-07-21 10:48:16] Zero King >>> Merge时还是用rebase?
[2018-07-21 10:48:25] Mingcong Bai [Re: 734] >>> Hmm 这个我们还没讨论到
[2018-07-21 10:48:30] Mingcong Bai >>> 先排除到问题之外吧
[2018-07-21 10:48:37] Mingcong Bai >>> (肯定会有第二次讨论的,不要担心
[2018-07-21 10:49:08] Mingcong Bai >>> 等 at 内人员都验证后我就先关闭这次讨论了,我会再安排个时间(现在还有空位,大概是明天
[2018-07-21 10:50:35] Zero King >>> OK,就是工作量比较大
[2018-07-21 10:50:42] Zero King >>> > bump REL 以保障其他分支的更新
[2018-07-21 10:50:54] Lion >>> Chimera 那个……措辞改一下吧
[2018-07-21 10:50:59] Mingcong Bai [Re: 741] >>> 嗯这个会做
[2018-07-21 10:51:01] Mingcong Bai >>> 先看思路吧
[2018-07-21 10:51:06] Lion >>> 把“但是”提到前面来
[2018-07-21 10:51:13] Mingcong Bai [Re: 744] >>> 哪个
[2018-07-21 10:51:49] Mingcong Bai >>> 噢我知道了,Chimera 那段?
[2018-07-21 10:52:05] Lion >>> 不是 “但是不接受季度限制”,而是 “它不受季度周期限制,但不更新标注为 rc、nightly 之类的上游版本”
[2018-07-21 10:52:34] Mingcong Bai [Re: 747] >>> 已修改
[2018-07-21 10:52:35] 井生 羽衣 >>> 安全更新 >「假设无法通过任何手段保障 Stable」建議寫明常見的原因
[2018-07-21 10:52:44] Mingcong Bai [Re: 749] >>> 好
[2018-07-21 10:52:52] Lion >>> 下面的 周期集成 一段里也是不接受→不受
[2018-07-21 10:53:36] Zero King >>> 好像没有提到安全更新在Chimera的优先级?
[2018-07-21 10:53:50] Mingcong Bai [Re: 752] >>> 那么再确定下
[2018-07-21 10:54:09] Mingcong Bai >>> 也就是说 Stable 接受安全更新之外,其他分支也需要接受安全更新而且优先完成?
[2018-07-21 10:54:30] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 752] >>> 核心就是如果下面更了
[2018-07-21 10:54:34] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 上面也得跳
[2018-07-21 10:54:47] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 但是破坏稳定的时候
[2018-07-21 10:54:49] Mingcong Bai [Re: 756] >>> 下面更新的幅度不一定会超过上面,这个也要注意
[2018-07-21 10:54:51] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 下面可以不懂
[2018-07-21 10:54:56] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> *动
[2018-07-21 10:55:01] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 上面跳
[2018-07-21 10:55:08] Zero King >>> 我之前提到的是Stable无法修复的情况下
[2018-07-21 10:55:13] Mingcong Bai >>> 噢知道了
[2018-07-21 10:55:19] Mingcong Bai >>> 我加上优先
[2018-07-21 10:55:36] Zero King >>> 尽量避免因为其他更新跳票
[2018-07-21 10:55:58] Zero King >>> 因为一个周期就是一个季度
[2018-07-21 10:56:11] Mingcong Bai >>> “安全更新首要保证 Stable,假设无法通过任何手段保障 Stable(如需要大幅度更新或当前人力无法保障 backport),则根据上述更新规则向稳定性更低的方向走(Testing,Testing 不行就到 Chimera),任何最后接受安全更新的分支需要优先保证安全更新”
[2018-07-21 10:56:13] Mingcong Bai >>> @l2dy0
[2018-07-21 10:56:51] Mingcong Bai >>> 还是说和你的意思是反的
[2018-07-21 10:57:32] Mingcong Bai >>> @Lionium 其他地方还有问题吗
[2018-07-21 10:57:35] Zero King >>> 三个分支的merge关系是怎样的?
[2018-07-21 10:57:52] Mingcong Bai [Re: 771] >>> 暂时不提新问题了,下个议程时间到了,二次讨论的时候再提一下?
[2018-07-21 10:58:32] Zero King >>> 按原分支是保证bugfix,无法保证则在staging分支中优先处理
[2018-07-21 10:58:41] Mingcong Bai [Re: 773] >>> 嗯对
[2018-07-21 10:58:53] Zero King >>> OK
[2018-07-21 10:58:56] Mingcong Bai >>> 好的
[2018-07-21 10:59:03] Mingcong Bai >>> 剩下 @Lionium 确定一下
[2018-07-21 10:59:19] Lion [Re: 770] >>> 安全更新方面我没什么看法,其他部分感觉可以吧
[2018-07-21 10:59:24] Mingcong Bai >>> 好
[2018-07-21 10:59:28] Mingcong Bai >>> 这个话题结束了
[2018-07-21 10:59:37] Lion >>> 噢别
[2018-07-21 10:59:53] Mingcong Bai >>> 还有二次讨论,我稍后就给时间……
[2018-07-21 10:59:53] Lion >>> 我还没喘过一口气就到我了吗…
[2018-07-21 11:00:00] Lion >>> 11 点了
[2018-07-21 11:00:04] Mingcong Bai >>> 那么推到 11:15?
[2018-07-21 11:00:21] Lion >>> 好的
[2018-07-21 11:00:34] Mingcong Bai >>> #TOPIC 11:15 - 12:15 — AOSC OS 打包工作流和工具链版本管控
[2018-07-21 11:00:38] Mingcong Bai [Re: 787] >>> pinned the message
[2018-07-21 11:00:53] Mingcong Bai [Re: 786] >>> 超过时限就二次讨论吧,我们还有空余时间的,可以看看 README
[2018-07-21 11:01:05] Mingcong Bai >>> 另外我开了个公告板,刚刚确定的内容会发到那里
[2018-07-21 11:01:10] Mingcong Bai >>> https://t.me/aoscc2018bulletin [webpage]
[2018-07-21 11:05:49] AOSCC Relay bot >>> [mingcongbai] IRC 用户可参考此处 https://pastebin.aosc.io/paste/y7hBIrWbvSav2SL9AAacTA [webpage]
[2018-07-21 11:11:55] Mingcong Bai >>> 上述讨论第二议程将于 7 月 22 日 23:00 - 0:00 进行二次讨论。
详见: https://github.com/AOSC-Dev/aoscc/blob/master/2018/README.md [webpage]
[2018-07-21 11:14:53] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 791] >>> 我日这个壁纸疯狂 spoiler
[2018-07-21 11:15:05] Piung Zjeuh >>> [chat_add_user]
[2018-07-21 11:15:09] Mingcong Bai [Re: 794] >>> LOL
[2018-07-21 11:15:12] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 虽然早就已经露出去了(
[2018-07-21 11:15:17] Mingcong Bai >>> @Lionium 上场啦
[2018-07-21 11:15:39] Lion >>> 114514
[2018-07-21 11:15:43] Mingcong Bai >>> 514
[2018-07-21 11:16:08] Lion >>> AOSC OS 打包工作流和工具链版本管控
[2018-07-21 11:16:22] Mingcong Bai >>> "Are we Live?"
[2018-07-21 11:16:32] Lion >>> 我分段来开展这个话题
[2018-07-21 11:16:34] AOSCC Relay bot >>> [YJSNPI] 噫喲
[2018-07-21 11:16:47] Lion >>> 大家在中途可以适当插嘴
[2018-07-21 11:17:10] Lion >>> 先是对打包一个简单的介绍。简单粗暴地说,打包无非是从代码生成 .deb 文件。
[2018-07-21 11:17:22] Lion >>> 对于一个包来说,很是简单。但之后可以看到,为整个系统打包实际上面临着重重困难。
[2018-07-21 11:17:49] Mingcong Bai >>> 插嘴(雾,我不敢了
[2018-07-21 11:19:08] Lion >>> 在做(看)的各位里面有打过包的有没打过的,特别是也有在其他系统上有打包经验的人。在这里介绍一下 AOSC OS 打包的常见操作
[2018-07-21 11:19:14] Lion >>> 从实际中常见的一个打包的例子来介绍:
[2018-07-21 11:19:32] Lion >>> #栗子 某特首,打开一箩筐网页,订阅邮件,日理万机,观察各种软件的更新动态。
[2018-07-21 11:19:52] Lion >>> 它注意到有一个叫做 systemd 的包,从 239 升级到了 240。于是它输入:
[2018-07-21 11:20:08] Lion >>> cd /bootroots/ciel/testing
nano TREE/extra-admin/systemd/spec #(并把 PKGVER=239 改为了 240,Ctrl+S 保存, Ctrl+X 退出)
ciel rollback -i amd64 #(amd64 是一个容器实例的名字)
ciel build -i amd64 systemd
[2018-07-21 11:20:28] Mingcong Bai >>> Nano fuck yeah
[2018-07-21 11:20:44] Lion >>> 好了,某特首继续阅读其他的新闻。
[2018-07-21 11:20:57] Lion >>> 电脑一热,新鲜的包子自动出现在了 OUTPUT/os-amd64/os3-dpkg/s/systemd_240-0_amd64.deb
[2018-07-21 11:21:04] Lion >>> 狭义上,打包的任务就结束了。
[2018-07-21 11:21:29] Lion >>> (没有政治指代)
[2018-07-21 11:21:42] Lion >>> 在随后的几天里,OUTPUT 文件夹里的包子一个一个多了起来。
[2018-07-21 11:21:48] 无聊怪 >>> 只要改版本号,中间的步骤 ciel 都完成了吗?
[2018-07-21 11:21:48] 死 肥 宅 鹹魚 [Re: 818] >>> hhhhhh
[2018-07-21 11:21:56] Lion [Re: 820] >>> 是的
[2018-07-21 11:22:07] Lion [Re: 819] >>> 文件夹就像膀胱,总有憋不住的那一天,某特首进行了一定的操作
[2018-07-21 11:22:16] Mingcong Bai [Re: 823] >>> *cough*
[2018-07-21 11:22:17] Lion >>> scp -r -P **** os-amd64 ****@repo.aosc.io:/mirror/os-amd64/testing
[2018-07-21 11:22:28] Lion >>> 这一大笼包就进了 testing 测试源。打包从输入到输出的全过程就结束了。
[2018-07-21 11:23:06] Sakamoto Tanmy >>> [document]
[2018-07-21 11:23:19] 死 肥 宅 鹹魚 [Re: 820] >>> 但是會有那種喪心病狂的老改構建系統的東西(就不能只改版本號了(x
[2018-07-21 11:23:20] Mingcong Bai >>> @skmt_tanmy 本群不能用 sticker
[2018-07-21 11:23:23] Lion >>> 顺带一提,实际上,此时 testing 源的用户没法立刻使用这些包。
[2018-07-21 11:23:40] Mingcong Bai [Re: 828] >>> 改版本号是最最基本的情况,有复杂很多的情况,@Lionium 一会会介绍
[2018-07-21 11:23:43] Sakamoto Tanmy [Re: 829] >>> sticker
[2018-07-21 11:23:45] Lion >>> 位于台湾的 repo.aosc.io 源服务器收到了这些包,按照东八区时间,每日 0 4 8 12 16 20 时的时候,自动扫描一次 /mirror/os-amd64 等文件夹,在其下生成 Packages 和 InRelease 文件。Packages 记录有新的包的信息,意味着从此时开始,用户已经可以在 apt update 后看到新的包了。
[2018-07-21 11:24:09] Lion >>> ↑从 scp/rsync 推上包到真正可用的细节。
[2018-07-21 11:24:49] Lion >>> 其实大家看到,更新一个包并不是特别的复杂
[2018-07-21 11:25:03] Mingcong Bai >>> 在最简单的例子里 *
[2018-07-21 11:25:30] Lion >>> 当然,如果 ciel build -i amd64 systemd 这一行满屏的消息滑过去之后突然报错,就是另一回事了
[2018-07-21 11:25:57] Lion >>> 上述,更新一个包,最顺利的流程就是这样的。
[2018-07-21 11:26:40] Sakamoto Tanmy >>> 插嘴:什么时候有从Ubuntu的功能呢(
[2018-07-21 11:26:47] Lion >>> 但是打包碰壁远远不只更新一下版本号就完成这么简单(尽管大多数情况下确实只需要改一下版本号)。
[2018-07-21 11:26:49] Mingcong Bai [Re: 839] >>> 比如?
[2018-07-21 11:26:53] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 822] >>> 所以为什么不搞个 nvchecker 呢
[2018-07-21 11:27:08] Lion [Re: 842] >>> 嘿,有了
[2018-07-21 11:27:09] Sakamoto Tanmy [Re: 841] >>> 输入法抽风没打完(
[2018-07-21 11:27:09] Mingcong Bai [Re: 842] >>> 其实现在有实现,参考 AOSC-Dev/scriptlets
[2018-07-21 11:27:19] Mingcong Bai [Re: 844] >>> 还是没明白
[2018-07-21 11:27:35] Sakamoto Tanmy [Re: 846] >>> 换源,dist upgrade(
[2018-07-21 11:27:48] Mingcong Bai [Re: 847] >>> 不可能,完全不是一个依赖树
[2018-07-21 11:27:53] Mingcong Bai >>> 以后也不可能
[2018-07-21 11:27:53] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 843] >>> 那快和隔壁arch自动化程度差不多了(不成
出问题的话
[2018-07-21 11:27:54] Staph. aureus | In your GI Tract [Re: 846] >>> (這句意思是叫你先 standby )
[2018-07-21 11:28:10] Lion [Re: 840] >>> 那么,现在我们引入一下各种打包的情况的一个整体观。
[2018-07-21 11:28:26] Lion >>> 刚才的例子里,是一个“更新”包的操作,打包所需要的脚本早已在 TREE/extra-admin/systemd 里的 spec 和 autobuild 文件夹里写好了,
[2018-07-21 11:28:29] Mingcong Bai [Re: 850] >>> 个人感觉自动化更新方面程度是够了,测试就还差距挺大
[2018-07-21 11:28:48] Lion [Re: 853] >>> 除了最常见的更新,新增软件包也是需要打包的。
[2018-07-21 11:28:55] Lion >>> 于是有人在电脑上实验和测试,最后手写出 spec 和 autobuild 各个文件,最后交给工具链打出最后的成品。
[2018-07-21 11:28:58] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 854] >>> 所以说不出问题的话
[2018-07-21 11:29:20] Lion >>> 但这是可以说最难的一个部分
[2018-07-21 11:29:29] Mingcong Bai [Re: 857] >>> 打包不能一味依靠这种猜测…… 无论风险多大都应该有测试架构,这个是 Arch 做得很好的一部分……
[2018-07-21 11:29:49] Lion >>> 参考数据库管理系统的理论,可以把打包视为“去变更”一个叫做 repo.aosc.io 的特殊数据库。
[2018-07-21 11:30:11] Lion >>> 数据库的操作又一个基本的概念叫做 CURD,指创建、更新、替换、删除四种常见操作
[2018-07-21 11:30:37] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 859] >>> ciel 内部现在依赖检测和安装重演做的怎么样
[2018-07-21 11:31:14] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 比如说上次给人打到 /usr 下了?
[2018-07-21 11:31:28] Mingcong Bai [Re: 862] >>> 这方面功能是 acbs/autobuild 实现的,说实话进展不大
[2018-07-21 11:32:06] Lion [Re: 862] >>> // (中途偏题回复) 可以,因为只要 rollback 得干净,缺乏依赖是不能构建的。但是这是间接的、依靠错误来检测构建依赖
[2018-07-21 11:32:19] Lion [Re: 861] >>> CURD,先从创建一个包开始看
[2018-07-21 11:32:47] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 865] >>> 所以无法检测多余依赖?)好像插嘴插多了
[2018-07-21 11:33:00] Mingcong Bai [Re: 867] >>> 对
[2018-07-21 11:33:04] Lion [Re: 867] >>> (去主群继续)
[2018-07-21 11:33:17] Mingcong Bai [Re: 869] >>> 主群我去对话吧
[2018-07-21 11:33:18] Lion [Re: 866] >>> (提醒:接下来有大段列表清单)
[2018-07-21 11:33:19] Mingcong Bai >>> 你继续
[2018-07-21 11:33:42] Lion >>> **************** 拉个线
[2018-07-21 11:33:46] Lion >>> 0、确定用于构建的系统本身已经最新
[2018-07-21 11:34:01] Lion >>> 1、查询、确定使用哪个上游,网址
[2018-07-21 11:34:09] Lion >>> 2、本地存一份代码
[2018-07-21 11:34:20] Lion >>> 3、观察依赖等信息,观察 ./configure --help ……
[2018-07-21 11:34:51] Lion >>> 4、添加 autobuild 目录
[2018-07-21 11:35:09] Lion >>> 5、书写 defines 文件,软件包描述、依赖、构建依赖……
[2018-07-21 11:36:29] Lion >>> 6、运行 autobuild 尝试构建为 .deb (还记得 ciel 更新的时候吗?其实就是容器运行了 acbs-build,然后 acbs-build 下载源码并最后调用 autobuild 构建)
[2018-07-21 11:36:59] Lion >>> => 出错?加入 prepare 文件,在构建前加以调整。
=> 添加 patches 文件夹,修改构建脚本、源代码,提取为补丁,放入 patches 文件夹。
=> 放弃自带构建工具链,人工书写 build 文件,自行构建。
=> 构建后数据复制不够完整?有特殊权限需求?加入 beyond 文件做后续处理。
[2018-07-21 11:37:19] Lion >>> 7、在 TREE 上的特定分类里,例如 extra-admin 里,新建包名的文件夹例如 meowmeow
[2018-07-21 11:37:47] Lion >>> 8、在文件夹内书写 spec 文件,指出上游版本、来源和网址(需要一些 Bash 的字符串操作技巧)等
[2018-07-21 11:38:16] Lion >>> 9、把刚才实验得到的 autobuild 文件夹全套复制进 meowmeow 文件夹内。(spec 与 autobuild 文件夹同一层级)
[2018-07-21 11:38:44] Lion >>> 10、TREE 提交 git 变更
=> PR,如果对自己写的构建脚本集信心不大
=> pull --rebase 更新本地后,push(此时应该位于 testing 分支)。
[2018-07-21 11:38:58] Lion >>> 11、适时 scp 或 rsync 将打好的 .deb 文件送上源服务器,等待扫描。
[2018-07-21 11:39:12] Lion >>> **************** 拉个清单结束线
[2018-07-21 11:39:41] Mingcong Bai >>> 嗯基本没问题
[2018-07-21 11:39:48] Mingcong Bai >>> 只是还有切割软件包的情况
[2018-07-21 11:39:53] Lion >>> 别急
[2018-07-21 11:40:16] Lion >>> 其实这个流程我写的时候都觉得很累……
[2018-07-21 11:40:55] Lion >>> 大体上可以分为:调查、写脚本、构建等待、提交和推包,四个阶段
[2018-07-21 11:42:14] Lion >>> 但是 “写脚本、构建等待” 其实经常需要来回重复,研究到底为什么出了问题。特别是一些没有严格代码规范和成熟的构建脚本套路的个人开发者的作品,经常会出问题
[2018-07-21 11:43:26] Lion >>> 另一方面,大型软件的工具链哪怕相当成熟易用,配置漏了点什么,想重新构建的时间代价也不小。
[2018-07-21 11:44:00] Lion >>> 这就是 CURD 之中 C 的目前的工作流情况
[2018-07-21 11:44:08] Lion >>> 其后是 U,更新
[2018-07-21 11:44:58] Lion >>> 更新的操作在刚才的虚构的例子中也有体现了,相对加入一个新包简单得多。
[2018-07-21 11:45:03] Lion >>> 0、确定用于构建的系统本身已经最新
1、确定新的版本号
2、修改 spec,非 SF GH GL 等托管的则需要确认网址依然可用。
3、构建为 .deb (可以使用 ciel 一步完成)
=> 出错?仿照 创建 的操作,上网调查、修改调试,等等
4、适时将 .deb 文件推送上服务器
[2018-07-21 11:45:55] Lion >>> 绝大多数情况下,更新一个软件包不会有太大问题。
[2018-07-21 11:46:18] Lion >>> 随后是R替换和D删除,一起讲
[2018-07-21 11:46:39] Lion >>> 这是指一种,软件包发生结构性变化,例如:分包、并包
[2018-07-21 11:46:50] Lion >>> 这样的情况
[2018-07-21 11:47:06] Lion >>> 这里特指动词的“分包”
[2018-07-21 11:47:12] Lion >>> 或者说分裂、合并
[2018-07-21 11:48:10] 死 肥 宅 鹹魚 >>> Mitosis
[2018-07-21 11:48:11] Lion >>> 这里需要考虑的类似更新,要升级一下版本号(其实是修订号)。同时添加特殊的包间关系参数
[2018-07-21 11:48:56] Lion >>> 先用更新的例子引入一下记号:一个包 A 1,更新,变成 A 2
[2018-07-21 11:49:11] Staph. aureus | In your GI Tract [Re: 905] >>> 錯了,是 Meiosis
[2018-07-21 11:49:31] 死 肥 宅 鹹魚 [Re: 908] >>> (剛剛沒想到這一點
[2018-07-21 11:49:38] Lion >>> 假如 A 分裂成 A 和 B:A 1 => A 2 & B 2
[2018-07-21 11:50:09] Lion >>> 那么 B 2 上面要写:
PKGBREAK="A<=1"
PKGREP="A<=1"
[2018-07-21 11:50:36] Lion >>> 这样用户就能平滑更新为两个包(A 2, B 2)了
[2018-07-21 11:51:13] Lion >>> 并包简单得多:例如 A 1 & B 1 => A 2
[2018-07-21 11:51:33] Lion >>> 那么 A 2 上写
PKGBREAK="B<=1.0"
PKGREP="B<=1.0"
[2018-07-21 11:51:35] Lion >>> 即可
[2018-07-21 11:52:11] 死 肥 宅 鹹魚 [Re: 911] >>> A2 不需要變麼?
[2018-07-21 11:52:24] Lion [Re: 916] >>> A 只需要更新到 A 2 就可以了
[2018-07-21 11:53:03] 死 肥 宅 鹹魚 [Re: 917] >>> 所以說從 A1 更新上去的時候不會自動安裝 B2 麼
[2018-07-21 11:53:26] Lion [Re: 918] >>> 噢,这是个问题 @JeffBai
[2018-07-21 11:53:36] Mingcong Bai [Re: 919] >>> 确实不会
[2018-07-21 11:53:41] Mingcong Bai >>> 但是这也是分包的意义之一……
[2018-07-21 11:54:15] 死 肥 宅 鹹魚 >>> 然後 B2 那邊不需要寫依賴 A2 麼 🙈
[2018-07-21 11:54:25] Lion [Re: 914] >>> 注:
Break 表示安装“此包”将会于“彼包”冲突
Replace 表示安装“此包”可以卸载“彼包”
[2018-07-21 11:54:27] Mingcong Bai [Re: 922] >>> 这个看具体情况判定
[2018-07-21 11:54:45] 死 肥 宅 鹹魚 [Re: 921] >>> 所以這種情況下用戶不就有可能發現更新了之後某個包功能少了什麼的...
[2018-07-21 11:55:05] Mingcong Bai [Re: 925] >>> 我一般会在 changelog 里面写的
[2018-07-21 11:55:07] Lion [Re: 922] >>> 可以在更上一级依赖里写入 B 2。如果是需要预装的情况,或者是适合加入 *-base 组的包
[2018-07-21 11:55:15] Mingcong Bai [Re: 927] >>> 嗯
[2018-07-21 11:55:18] Mingcong Bai >>> 这个我可以举个例子
[2018-07-21 11:55:20] 死 肥 宅 鹹魚 [Re: 926] >>> 嗯 🙈
[2018-07-21 11:55:37] Mingcong Bai >>> 假设我们有 hunspell 这个包,包含 runtime 和 dict
[2018-07-21 11:55:51] Mingcong Bai >>> 接下来分包得到 hunspell 和 hunspell-dict
[2018-07-21 11:56:01] Mingcong Bai >>> 可以再来个包 hunspell-full 依赖两者
[2018-07-21 11:56:12] Mingcong Bai >>> 然后其他本来同时需要这两者的包可以直接依赖 hunspell-full
[2018-07-21 11:56:15] Mingcong Bai >>> 基本如此
[2018-07-21 11:56:25] 死 肥 宅 鹹魚 >>> 嗯 🙈
[2018-07-21 11:56:27] 死 肥 宅 鹹魚 >>> 明白了
[2018-07-21 11:56:33] Mingcong Bai >>> @Lionium 提醒下议程时间还有 15 分钟
[2018-07-21 11:56:37] Lion >>> y
[2018-07-21 11:57:02] Lion >>> 长期以来的各种工作流程基本就是这样。
[2018-07-21 11:58:45] Lion >>> 但是首先,我们并没有一个很好的归档,把打包的准确先后操作写清楚。我们目前有 acbs、autobuild3 这些工具的独立简介,和配置、各文件的含义。类似于 Reference 而非一个书面的有顺序的教程
[2018-07-21 11:59:42] Lion >>> 所以我提议有打包经验的各位可以有可能的话,书面总结一下自己的经验(老实说我都还从来没打过一个完整的包)
[2018-07-21 12:00:02] Lion >>> 日志、博客之类的都是不错的载体,操作明确、有资料可参考,这样的工作流才能吸引更多的开发者参与贡献。
[2018-07-21 12:00:07] Mingcong Bai >>> Wok taken at https://t.me/jellywok [webpage]
[2018-07-21 12:00:27] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 942] >>> hmmm
[2018-07-21 12:00:42] Mingcong Bai >>> 博客可以用于引用
[2018-07-21 12:00:50] Mingcong Bai >>> "Good Guides"
[2018-07-21 12:00:57] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 943] >>> 我可能把 dotfiles 丢上来
[2018-07-21 12:01:02] Lion >>> 其后是工作流过于经验化,这当然无可厚非。没有一个集成的环境,或者工具链,也很难做到能够确定一个通用工作流
[2018-07-21 12:01:18] Lion >>> 但是长期来看, 需要将经验型的人为操作逐渐转变为自动化操作
[2018-07-21 12:01:32] Lion >>> 难以短期内迅速实现自动化,目前缺乏很多的经验,其一就是需要向其他的已经实现自动化的发行版学习经验。
[2018-07-21 12:01:50] Lion >>> 其二是,我发现一些短期来说力所能及的事情,
[2018-07-21 12:02:15] Lion >>> 比如刚才说的书面化记载打包的流程、经验
[2018-07-21 12:02:20] Mingcong Bai >>> 嗯
[2018-07-21 12:02:30] Lion >>> 第二个是我最想说的
[2018-07-21 12:02:34] Lion >>> 调查实验阶段经常遇到的操作,归纳进自己的 Checklist(检查清单)。鼓励分享 Checklist。
[2018-07-21 12:03:00] Lion >>> 这一个操作可以很好推进自动化
[2018-07-21 12:03:13] Mingcong Bai >>> 你的意思是更完善的 QA 吗
[2018-07-21 12:03:15] Lion >>> 因为,我们还可以(现在就可以)实现自动化上述 Checklist 的辅助性工具。这类辅助性工具还应该可以完成快速生成 autobuild 文件夹模板等功能。
[2018-07-21 12:03:29] Lion [Re: 958] >>> 不不不,用于调查的工具,不仅限于 QA
[2018-07-21 12:03:30] Junde Yhi >>> 我又想把我说了不做的东西拿出来吹了
[2018-07-21 12:03:41] Mingcong Bai [Re: 961] >>> ?
[2018-07-21 12:04:48] Lion >>> 比如自动以一个易读的格式列出 ./configure --help 里的特性,扫描代码里使用了什么 python 版本,扫描 CMake 里调用了什么 find_packages() ……等等
[2018-07-21 12:05:55] Lion >>> 这些东西我们立刻就可以做,而且因为其辅助性质,可以在想用的时候用,给人作为一个参考,暂时不需要作为一个自动化工具流的一部分。
[2018-07-21 12:06:03] Mingcong Bai >>> 这点子有意思
[2018-07-21 12:06:20] Lion >>> 这些东西可以减少很多很多在打新包时候的工作量
[2018-07-21 12:06:36] Mingcong Bai >>> 而且也比直接抄其他发行版更准确
[2018-07-21 12:06:38] Lion >>> 我们的 autobuild3 本身有一定的检测的功能
[2018-07-21 12:06:45] Lion >>> 但是不够作为参考
[2018-07-21 12:07:06] Lion >>> 而且也不视觉化,不方便供总体审视上游代码的情况
[2018-07-21 12:07:49] Mingcong Bai >>> Right.
[2018-07-21 12:08:48] Lion >>> 不用急着思考怎么实现,把可行的点子都在 checklist 上列出来就好。无论是人做还是机器做,有了一条简单的指令式思路,都会方便很多。
[2018-07-21 12:09:31] Lion >>> 这是我的一个想法,最后作为这些工作流自动化 “之路” 的辅助,提出一下工具链自身的版本控制问题
[2018-07-21 12:09:43] Mingcong Bai >>> 嗯
[2018-07-21 12:11:23] Lion >>> 目前的主要工具链有:1、autobuild,用于执行构建脚本。2、acbs-build,用于自动下载源代码、安装依赖、并执行 autobuild。3、ciel,一个容器化环境,自动部署系统和 TREE。
[2018-07-21 12:11:55] Junde Yhi >>> [photo]
[2018-07-21 12:12:09] Lion >>> 我提议寻找一个地方,比如 deb 内的附加数据中,记录工具链的版本。
[2018-07-21 12:12:17] 猫晴 弥柚 >>> 工作流的话,个人建议可以先解决下自动跟进更新和进行推送的事情,手动翻订阅查邮件效率太低也太麻烦了
[2018-07-21 12:12:37] Lion >>> 然后在 scp 推上源,扫描的时候,拒绝接收那些被弃用的老版本工具链
[2018-07-21 12:12:42] Leway Colin [Re: 978] >>> 这个现在已经有了
[2018-07-21 12:12:43] Mingcong Bai [Re: 978] >>> 最后一点的话我们已经有工具辅助这个过程了,但是依然需要鼓励打包者去阅读必要信息
[2018-07-21 12:13:00] OriginCode >>> Wiki 上不考慮寫點麼(
[2018-07-21 12:13:13] Leway Colin >>> 因为依赖第三方的不一定准
[2018-07-21 12:13:18] Lion [Re: 978] >>> y,这个是上游跟踪了。是任何 Linux 发行版的头号难题,宜另外讨论
[2018-07-21 12:13:20] Mingcong Bai [Re: 982] >>> Ciel 的话因为本身还没稳定下来
[2018-07-21 12:14:08] OriginCode >>> (
[2018-07-21 12:14:28] Mingcong Bai >>> 至于保留额外版本信息的话,DEBIAN 文件夹里面的任何额外文件都不会影响打包
[2018-07-21 12:14:30] Lion [Re: 979] >>> 有了这样一个版本强制机制之后,工具链的演进可以更快推进,便于间接改善软件包质量
[2018-07-21 12:14:54] Mingcong Bai >>> 不过既然我们现在 Autobuild3 里面还有实现其他 PM 的计划,我认为应该保存在包解压出来的文件里
[2018-07-21 12:15:01] Mingcong Bai >>> 而不是在元数据里面
[2018-07-21 12:15:11] Mingcong Bai >>> 或者,实现个抽象方式
[2018-07-21 12:15:42] Lion [Re: 988] >>> 但是因为这是一个强制措施,所以需要打包者的合作才能进行。(当然使用 ciel 等容器打包,经常更新打包系统的人不存在这个问题)
[2018-07-21 12:15:55] 猫晴 弥柚 [Re: 981] >>> 主要是将必要信息统一推送至显眼位置,比如我这边同时做了qq/tg/桌面/邮件/mastodon,多端推送,根据消息类型决定位置
[2018-07-21 12:16:20] Mingcong Bai [Re: 993] >>> 你是说我们发行版更新的包?还是说打包过程中收集信息的途径?
[2018-07-21 12:16:36] Mingcong Bai >>> 如果是后者,你可以看看这个 https://packages.aosc.io/srcupd/aosc-os-abbs [webpage]
[2018-07-21 12:16:37] Lion [Re: 993] >>> 顺带一提,我之前一直想弄个 Eletron 应用拿来观察上游更新
[2018-07-21 12:16:50] Mingcong Bai [Re: 995] >>> 还有 json 输出
[2018-07-21 12:16:56] Lion [Re: 996] >>> 但是可惜我前端不够好,弄不好界面
[2018-07-21 12:17:11] Zero King >>> 讨论超时了
[2018-07-21 12:17:19] Lion >>> 噢,
[2018-07-21 12:17:26] Mingcong Bai [Re: 999] >>> @Lionium 考虑选择一个时间二次讨论吧
[2018-07-21 12:17:31] Lion >>> 我的发言结束了
[2018-07-21 12:17:37] Mingcong Bai >>> [document]
[2018-07-21 12:17:48] Mingcong Bai [Re: 1002] >>> 是否需要额外进行讨论?
[2018-07-21 12:18:02] Lion >>> 但是如果大家对内容有更深入的讨论,可以到主群继续
[2018-07-21 12:18:11] Mingcong Bai [Re: 1005] >>> 👍
[2018-07-21 12:18:18] Lion [Re: 1004] >>> 或者有人愿意在此地进行我也不反对……看你怎么安排了
[2018-07-21 12:18:33] Mingcong Bai >>> 这个我建议你选定个时间放入日程
[2018-07-21 12:18:44] Mingcong Bai >>> 否则就作为一般讨论在主群里面进行
[2018-07-21 12:19:41] 猫晴 弥柚 [Re: 998] >>> 我最早的时候是直接echo到终端,后面实验的结果是,我并不能持续的切换到终端去观察,然后通过桌面消息推送了一下,受限于桌面调戏的即时性,最后推到了im里,单独开个window我认为是无必要的
[2018-07-21 12:21:20] Lion [Re: 1009] >>> 就在主群吧
[2018-07-21 12:21:42] Lion [Re: 1010] >>> 我们去主群继续
[2018-07-21 12:25:20] Mingcong Bai >>> Day 1 上午所有议程已经结束,今晚还有三个议程:
— 21:00 - 22:00,关于 AOSC OS 安全更新工作流程的介绍和安全更新维护者召集(@l2dy0 主持)
— 22:15 - 23:15,关于 AOSC OS 软件包二进制优化 overlay 的实现计划(@lmy441900 主持)
— 23:30 - 0:00,Core 6 代号投票
______________________________
实用链接:
— AOSCC 2018 公告栏: https://t.me/aoscc2018bulletin
— AOSCC 2018 投票区,今晚的 Core 6 代号投票将在此处进行,请择时加入: https://t.me/aoscc2018polls
今晚 23:30 - 0:00 将对 AOSC OS Core 6 代号进行投票,因为代号候选较多,投票将进行多轮并在今晚选出最终胜出者。目前已收到的代号列表可参考此链接: https://pastebin.aosc.io/paste/cjSKP~s3jFAotcFVJLfiLg 。届时还将提供 7 个空位供现场抢注提名其他代号。 [webpage]
[2018-07-21 12:25:24] Mingcong Bai [Re: 1013] >>> pinned the message
[2018-07-21 12:44:26] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 现有代号在哪看来着
[2018-07-21 12:44:48] Lion [Re: 1015] >>> 头上
[2018-07-21 12:45:48] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 1016] >>> 望天)没看到
[2018-07-21 12:45:57] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 有个投票群
[2018-07-21 12:46:03] Mingcong Bai >>> 今晚抢提名的时候先到先得,直接叫出来,然后就地筛选,选出前七个直接加入候选。
[2018-07-21 12:46:29] Mingcong Bai [Re: 1018] >>> 对,各位麻烦尽快加一下(不过晚上我还会再提醒
[2018-07-21 12:46:38] 御坂0x4e21 看到她灌水一律赶她下线 [Re: 1015] >>> https://pastebin.aosc.io/paste/cjSKP~s3jFAotcFVJLfiLg
[2018-07-21 12:46:41] Mingcong Bai >>> t.me/aoscc2018polls [webpage]
[2018-07-21 12:46:57] Mingcong Bai >>> 投票只会发到那里
[2018-07-21 12:47:38] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 求加一个 FranXX (🙋🏿‍♂
[2018-07-21 12:47:51] Mingcong Bai [Re: 1024] >>> 23:30 的时候提
[2018-07-21 12:47:56] Mingcong Bai >>> 现在不计
[2018-07-21 12:48:01] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 可能睡了
[2018-07-21 12:48:11] Mingcong Bai [Re: 1027] >>> 那没办法了(
[2018-07-21 12:48:33] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 1028] >>> 等下
[2018-07-21 12:48:35] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 这不是投票
[2018-07-21 12:48:41] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 是提名
[2018-07-21 12:48:53] Mingcong Bai >>> 我知道啊
[2018-07-21 12:48:56] 迫真 正版 >>> (
[2018-07-21 12:49:00] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 🌑
[2018-07-21 12:49:07] Mingcong Bai >>> 23:30 的时候抢提
[2018-07-21 12:49:10] Lion >>> *现场抢注*
[2018-07-21 12:49:10] Mingcong Bai >>> 然后计入候选
[2018-07-21 12:49:52] Lion [Re: 1031] >>> 正常的提名渠道已经在今天(北京)早上 8 点之前结束了
[2018-07-21 12:50:17] Mingcong Bai >>> 各位晚安,傍晚见(
[2018-07-21 12:54:09] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 那算了🌑
[2018-07-21 13:08:06] LAX VPS [Re: 331] >>> /msg chanserv flags
[2018-07-21 13:08:46] Mingcong Bai [Re: 1041] >>> 说我没权限
[2018-07-21 13:08:54] Mingcong Bai >>> 你给 l2dy 加个 o 吧
[2018-07-21 13:09:12] LAX VPS [Re: 1043] >>> ack
[2018-07-21 13:10:26] LAX VPS [Re: 328] >>> Flags +o were set on l2dy in #aoscc-2018.
[2018-07-21 13:11:12] Lion >>> 去 Pre-asm 说吧
[2018-07-21 13:12:15] ksqsf genuine >>> [chat_add_user]
[2018-07-21 18:40:01] liushuyu >>> 剩余 2 小时 20 分
[2018-07-21 20:40:17] liushuyu >>> 剩余 20 分钟
[2018-07-21 20:55:13] Mingcong Bai >>> 五分钟
[2018-07-21 21:00:10] Mingcong Bai >>> #TOPIC 21:00 - 22:00 — 关于 AOSC OS 安全更新工作流程的介绍和安全更新维护者召集 (@l2dy0)
[2018-07-21 21:00:15] Mingcong Bai [Re: 1051] >>> pinned the message
[2018-07-21 21:00:34] Zero King >>> 首先我介绍以下现在 AOSC OS 处理安全漏洞的流程
[2018-07-21 21:01:20] Zero King >>> 1. 我会从各种邮件列表订阅和RSS收到安全漏洞信息
[2018-07-21 21:01:37] Zero King [Re: 1054] >>> RSS现在只有各种浏览器
[2018-07-21 21:02:15] Zero King >>> 然后会通过 @aoscpkgbot 和 GitHub 网页查看我们是否有这个包,版本是否受影响
[2018-07-21 21:02:28] Zero King >>> [photo]
[2018-07-21 21:02:34] Zero King >>> 2. Triage 安全漏洞
[2018-07-21 21:03:08] Zero King >>> 由于人手不足,我们没有继续区分安全更新的优先级
[2018-07-21 21:03:29] Zero King >>> 3. 创建带有 security 标签的 issue`(很多时候还带 `upgrade )
[2018-07-21 21:04:17] Zero King >>> 然后就是由 @JeffBai 做的一些事
[2018-07-21 21:04:23] Zero King >>> 4. Triage 安全 issue(更新到 staging / bugfix、更新或打补丁、不合法或滞留)
[2018-07-21 21:04:31] Zero King >>> 5. 打包并测试
[2018-07-21 21:04:36] Zero King >>> 6. 推送 commit 和更新
[2018-07-21 21:04:47] Zero King >>> 7. 在 issue 里引用 commit 并关闭 issue
[2018-07-21 21:05:04] Zero King >>> 8. 之后再由我分配AOSA
[2018-07-21 21:05:23] Zero King >>> 9. @JeffBai 编写并发布安全公告(邮件形式)
[2018-07-21 21:05:29] Zero King >>> 10. 我来更新 wiki
[2018-07-21 21:05:53] Mingcong Bai >>> P.S. 今年的 AOSA 列表放在这个 wiki 页面里面 https://wiki.aosc.io/aosa/archive/2018 [webpage]
[2018-07-21 21:06:10] Zero King >>> 这就是现在的漏洞处理流程
[2018-07-21 21:06:58] Zero King >>> 有什么疑问吗?
[2018-07-21 21:07:43] Mingcong Bai >>> 你一般关注的漏洞信息来源除了 oss-security 还有些什么?很多时候你能很快响应一些 oss-security 里面没有提到的问题
[2018-07-21 21:07:51] Zero King >>> 很多。。。
[2018-07-21 21:08:08] Zero King >>> Arch Linux Security Advisory
[2018-07-21 21:08:16] Zero King >>> opensuse-security@opensuse.org
[2018-07-21 21:08:29] Zero King >>> debian-security-announce@lists.debian.org
[2018-07-21 21:08:39] Zero King >>> gentoo-announce@lists.gentoo.org
[2018-07-21 21:08:53] Zero King >>> ubuntu-security-announce@lists.ubuntu.com
[2018-07-21 21:08:58] Zero King >>> rhsa-announce@redhat.com
[2018-07-21 21:09:05] Mingcong Bai >>> 噢,就是上次你说过因为我们没有长期活跃的漏洞测试者所以没法获得第一手资料
[2018-07-21 21:09:17] Mingcong Bai >>> 所以更多是在依赖二级资源吗
[2018-07-21 21:09:47] Zero King >>> 第一手资料不好获得。
[2018-07-21 21:10:27] Zero King >>> 例如最近的 neomutt/mutt 安全漏洞,如果不是我在 embargo 范围内都不会注意到。
[2018-07-21 21:10:55] Mingcong Bai >>> 嗯
[2018-07-21 21:11:20] Mingcong Bai >>> 要改善现在的情况只能通过直接参与到 Embargo 列表里面对吗
[2018-07-21 21:11:49] Zero King >>> 我觉得现在的情况已经足够好了
[2018-07-21 21:12:43] Zero King [Re: 1082] >>> 其次就是人手/能力不足,对于描述不清晰的漏洞我无法判断我们是否受影响。
[2018-07-21 21:14:23] Mingcong Bai >>> 尤其 Qemu 和内核的漏洞,光是比对信息就相当耗时了
[2018-07-21 21:14:54] Zero King [Re: 1079] >>> 其实还有,我就不继续列了
[2018-07-21 21:15:14] Junde Yhi >>> 这之中有哪些环节允许更多的人参与?
[2018-07-21 21:15:28] Zero King >>> 招聘AOSA安全维护人员
* QA 工程师(测试更新和PoC)
* 漏洞收集后备人员(有人应聘的话会把邮件列表订阅迁移到lists.aosc.io下的一个邮件列表)
* 打包人员(See "AOSC OS: Packaging Workflow and Toolchain Enforcement")
* AOSA编辑(收集漏洞和修复信息并在邮件列表和网站上发布)
[2018-07-21 21:16:03] Zero King >>> 每个环节都缺人(
[2018-07-21 21:16:17] Mingcong Bai >>> “漏洞收集后备人员(有人应聘的话会把邮件列表订阅迁移到lists.aosc.io下的一个邮件列表)”
[2018-07-21 21:16:28] Mingcong Bai >>> 这里说的是把你现在的收集途径放到一个列表里面?
[2018-07-21 21:16:32] Zero King >>> 是
[2018-07-21 21:16:33] Mingcong Bai >>> 转发 *
[2018-07-21 21:16:35] Mingcong Bai >>> 嗯
[2018-07-21 21:16:53] Mingcong Bai [Re: 1090] >>> 现在响应信息发布实际上是很快的,只是车祸指数高
[2018-07-21 21:17:01] Zero King >>> 邮件列表应该可以订阅邮件列表?
[2018-07-21 21:17:31] Mingcong Bai >>> 反而是打包方面(不过这个可以先看早上的周期讨论),一个是没有一个明确的优先级定义,一个是没有足够的人去快速响应
[2018-07-21 21:17:45] Mingcong Bai [Re: 1099] >>> Hmm 这个我真的不清楚
[2018-07-21 21:17:49] Mingcong Bai >>> 可以问问 infra
[2018-07-21 21:18:53] Mingcong Bai >>> AOSA 编辑的话,我总感觉是不是能自动化一下邮件发布?现在虽然我有说半个月会发布一次,但是很多时候到了那天有可能会在忙其他的事情…… 这个实在有点不理想
[2018-07-21 21:20:06] Zero King >>> CVE枚举无法自动化
[2018-07-21 21:20:27] Zero King >>> Issue template for vulnerability report (must include English)
[2018-07-21 21:20:38] Zero King >>> 我们可能需要一个漏洞报告的标准模板
[2018-07-21 21:21:28] Zero King >>> 然后因为在GitHub上为了国际化需要使用英语
[2018-07-21 21:21:48] Mingcong Bai >>> 这个的具体目的是?
[2018-07-21 21:22:22] Zero King >>> 比如说CVE在issue里填好,才能自动生成安全公告
[2018-07-21 21:22:48] Mingcong Bai >>> 我刚刚大略搜索了一下似乎没找到什么 Issue to Email 的途径……
[2018-07-21 21:23:01] Mingcong Bai >>> 倒是有通过邮件创建和控制 issue 的方法
[2018-07-21 21:23:45] Zero King >>> 这只能自己写
[2018-07-21 21:24:02] Mingcong Bai >>> Hmm.
[2018-07-21 21:25:34] Mingcong Bai >>> 那么假设我们可以排除邮件列表的人工参与……
[2018-07-21 21:25:48] Mingcong Bai >>> @liushuyu @Lionium website-site-ng 是否有可能支持类似的自动化发布?
[2018-07-21 21:25:59] liushuyu [Re: 1115] >>> 应该可以
[2018-07-21 21:26:47] Zero King >>> AOSA编辑如果招到人我们是否切换到每个AOSA一封邮件?
[2018-07-21 21:27:06] Mingcong Bai [Re: 1117] >>> 假设能实现自动化邮件我建议就这么做
[2018-07-21 21:27:12] Zero King >>> 修改好issue内容后使用脚本发送邮件等
[2018-07-21 21:27:21] Mingcong Bai >>> 反倒是 Issue 那边需要填入更多内容……
[2018-07-21 21:27:56] Zero King >>> 所以说“如果招到了AOSA编辑”...
[2018-07-21 21:28:10] Mingcong Bai [Re: 1121] >>> 好吧我们这里用词有点混淆了
[2018-07-21 21:28:29] Mingcong Bai >>> 我刚刚在说的是邮件和主页方面发布的信息,你这里说的是 GH Issue 的编写者?
[2018-07-21 21:28:43] Zero King >>> 自动化(
[2018-07-21 21:29:04] Zero King >>> 邮件和主页发布的所有信息来自issue
[2018-07-21 21:30:01] Zero King [Re: 1125] >>> (除 correction)
[2018-07-21 21:30:13] Mingcong Bai >>> 关于 issue 的固定格式你有什么想法吗
[2018-07-21 21:30:21] Mingcong Bai >>> 必须包含什么信息?
[2018-07-21 21:30:30] Zero King >>> 参考其他发行版吧
[2018-07-21 21:31:04] Mingcong Bai >>> — 包名
— 漏洞简述(“远程执行 blablabla”)
— 来源
— CVE 或其他编号
— 版本范围
[2018-07-21 21:31:07] Mingcong Bai >>> 类似这样?
[2018-07-21 21:31:52] Zero King >>> 版本范围是指的我们包的版本?
[2018-07-21 21:32:07] Mingcong Bai >>> 嗯,受影响的版本(和分支,假设我们真的换到三分支了)
[2018-07-21 21:32:14] Mingcong Bai >>> 甚至做个 matrix
[2018-07-21 21:32:33] Zero King >>> 必需的是AOSA号码、包名和新包版本
[2018-07-21 21:33:04] Mingcong Bai >>> 基本的漏洞描述还是得有吧?
[2018-07-21 21:33:24] Zero King >>> 现在就没有啊。这要看人力
[2018-07-21 21:34:12] Mingcong Bai >>> 现在似乎至少还是有个 cross-ref 的,CVE 编号(在一些情况下)能提供不少信息
[2018-07-21 21:34:36] Zero King >>> 但很多时候我们都会漏CVE。
[2018-07-21 21:35:19] Mingcong Bai >>> 就是说类似 Qemu 的情况?
[2018-07-21 21:35:56] Mingcong Bai >>> 另外现在还存在的问题是发布 AOSA 的限定条件
[2018-07-21 21:36:12] Mingcong Bai >>> 很多时候实际上其他架构还没修复我就把 issue 给 close 了,这个行为以后需要改正……
[2018-07-21 21:36:20] Mingcong Bai >>> 可能以后提供个 checklist 会好点
[2018-07-21 21:38:57] Zero King [Re: 1141] >>> 我的理解是在之前的版本受到该安全漏洞影响的前提下,在带有修复的版本到达主源时分配AOSA。
[2018-07-21 21:39:27] Zero King >>> 因而对于bugfix就是立即分配,对于staging可以累积到merge分配。
[2018-07-21 21:40:02] Mingcong Bai >>> 嗯,不过上面说的架构问题,那个是我的锅,以后需要更严格地跟踪每个架构的修复情况
[2018-07-21 21:41:03] Zero King >>> 还有需要讨论的吗?
[2018-07-21 21:41:34] Mingcong Bai >>> 我觉得现在这个流程是相对明确的,更多是需要去改善……
[2018-07-21 21:41:39] Mingcong Bai >>> 然后就是要人(
[2018-07-21 21:42:39] Zero King >>> 话题结束,招人信息加入公告版?
[2018-07-21 21:42:47] Mingcong Bai >>> 好的
[2018-07-21 21:43:13] Mingcong Bai >>> #TOPIC 21:45 - 22:15 空闲时间,自由交流
[2018-07-21 21:43:16] Mingcong Bai [Re: 1152] >>> pinned the message
[2018-07-21 21:43:22] Zero King >>> 本话题只有4个人参与(
[2018-07-21 21:43:29] Junde Yhi >>> (
[2018-07-21 21:43:35] 死 肥 宅 鹹魚 >>> 不敢插嘴(
[2018-07-21 21:43:43] Catten Linger [Fwd: 死 肥 宅 鹹魚] >>> 不敢插嘴(
[2018-07-21 21:43:44] Mingcong Bai [Re: 1154] >>> 感觉不是个通识内容……
[2018-07-21 21:43:50] Junde Yhi >>> 我现在发现我很擅长说了不做
[2018-07-21 21:43:59] 死 肥 宅 鹹魚 [Fwd: Junde Yhi] >>> 我现在发现我很擅长说了不做
[2018-07-21 21:44:06] Junde Yhi >>> QA 问题我在 AOSCC 2017 上就讲过
[2018-07-21 21:44:24] Junde Yhi >>> 那个时候 @l2dy0 还没有出现
[2018-07-21 21:44:56] Zero King [Re: 1161] >>> 包括安全更新特有的PoC?
[2018-07-21 21:45:14] Junde Yhi [Re: 1163] >>> 没有,只是 Call for participation
[2018-07-21 21:46:17] Xiaoxing Ye [Re: 1159] >>> 说的不是我吗(
[2018-07-21 21:46:48] 御坂0x4e21 看到她灌水一律赶她下线 [Re: 1159] >>> 我现在不要说做一些什么了,连说都不知道说什么……
[2018-07-21 21:47:22] liushuyu [Re: 1164] >>> 所以 MIPS port 现在是彻底瘫痪了么(
[2018-07-21 21:47:36] Junde Yhi [Re: 1167] >>> 嗯,会重做的
[2018-07-21 21:47:51] Junde Yhi >>> 你看刚才我在隔壁 Debian 群就很崩溃
[2018-07-21 21:48:21] Junde Yhi [Fwd: Aron Xu] >>> 有可能是中彩了吧
[2018-07-21 21:48:56] Mingcong Bai >>> 什么情况?
[2018-07-21 21:49:33] Junde Yhi >>> 刚刚正好和 Aron Xu 聊到 Debian 的 mips port
[2018-07-21 21:50:12] Junde Yhi [Fwd: Aron Xu] >>> 那还是你们的问题惹……
[2018-07-21 21:50:12] Junde Yhi [Fwd: Aron Xu] >>> 其实你们的硬件也很奇怪,我只拿到过1000 1500和3000
[2018-07-21 21:50:12] Junde Yhi [Fwd: Aron Xu] >>> 没听说过loongson 3a 2000系列的产品
[2018-07-21 21:50:12] Junde Yhi [Fwd: Aron Xu] >>> 可能是中间版本?
[2018-07-21 21:51:08] Junde Yhi [Fwd: Junde Yhi] >>> 我们的 mipsel 移植也没有 atomic 支持
[2018-07-21 21:51:08] Junde Yhi [Fwd: Aron Xu] >>> 龙芯没这个问题
[2018-07-21 21:51:08] Junde Yhi [Fwd: Aron Xu] >>> cavium硬件的专属bug
[2018-07-21 21:51:19] 冰淇琳 [Re: 1175] >>> 无 fuck 说
[2018-07-21 21:51:50] liushuyu [Re: 1177] >>> 参见 Loongson 的 OpenJDK 8 HS 实现(
[2018-07-21 21:52:19] Mingcong Bai [Re: 1177] >>> 我发现现在 armel 有的时候也会遇到 atomic 坑了
[2018-07-21 21:52:21] Mingcong Bai >>> 很奇怪
[2018-07-21 21:52:39] Mingcong Bai >>> ppc32be, mipsel, armel
[2018-07-21 21:52:44] Mingcong Bai >>> 这三个架构都会遇到这种问题
[2018-07-21 21:53:07] 冰淇琳 >>> 可能因为常用的原子操作都不能直接指令完成
[2018-07-21 21:53:16] 冰淇琳 >>> 需要 libatomic 库
[2018-07-21 21:53:27] 冰淇琳 >>> 但是我们的 libatomic 库又没能自动引入
[2018-07-21 21:53:37] Mingcong Bai [Re: 1188] >>> 对……
[2018-07-21 21:53:43] 冰淇琳 >>> 是 gcc spec 问题?
[2018-07-21 21:53:43] Mingcong Bai >>> 这个问题是出在什么环节了……
[2018-07-21 21:53:53] Mingcong Bai [Re: 1190] >>> spec 里面应该没有定义这个?
[2018-07-21 21:54:00] Mingcong Bai >>> 还是说我们要自己加上
[2018-07-21 21:54:02] 冰淇琳 >>> libatomic 是 gcc ship 的库
[2018-07-21 21:54:40] Mingcong Bai [Re: 1194] >>> 对,但是要什么情况下才会自动 link 上?
[2018-07-21 21:54:47] 冰淇琳 >>> 应该是默认
[2018-07-21 21:54:49] Mingcong Bai >>> 感觉还是需要项目本身去指定?
[2018-07-21 21:55:07] 冰淇琳 >>> 好像不用。。。
[2018-07-21 21:55:22] Mingcong Bai >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 [webpage]
[2018-07-21 21:55:57] Mingcong Bai >>> "The problem would be any platforms where (a)
there is no --as-needed support, but (b) shared libraries are supported
and linking with a shared library introduces a dependency into the binary
even if no symbols from that shared library are used."
[2018-07-21 21:55:59] Mingcong Bai >>> Oops?
[2018-07-21 21:56:00] Zero King >>> @JeffBai 公告版里不要带“我”
[2018-07-21 21:56:11] Mingcong Bai [Re: 1202] >>> K
[2018-07-21 21:56:34] Mingcong Bai >>> Fixed
[2018-07-21 21:56:49] 冰淇琳 >>> emmm
[2018-07-21 21:56:51] 冰淇琳 >>> 的确是不自动
[2018-07-21 21:56:57] Mingcong Bai [Re: 1200] >>> @Icenowy 有可能是我们默认指定 --as-needed 导致的?
[2018-07-21 21:57:01] 冰淇琳 >>>
icenowy@ice-x230 [ tmp ] $ gcc test.c
/tmp/ccnPNCsX.o:test.c:function main: error: undefined reference to '__atomic_load'
/tmp/ccnPNCsX.o:test.c:function main: error: undefined reference to '__atomic_compare_exchange'
/tmp/ccnPNCsX.o:test.c:function main: error: undefined reference to '__atomic_feraiseexcept'
/tmp/ccnPNCsX.o:test.c:function main: error: undefined reference to '__atomic_load'
/tmp/ccnPNCsX.o:test.c:function main: error: undefined reference to '__atomic_load'
collect2: 错误:ld 返回 1
[2018-07-21 21:57:14] Mingcong Bai [Re: 1208] >>> AMD64 上都这样?
[2018-07-21 21:57:18] 冰淇琳 >>> 嗯
[2018-07-21 21:57:45] Mingcong Bai >>> 那么是否应该考虑在那三个已知有问题的架构上自动 append -latomic?
[2018-07-21 21:58:04] Mingcong Bai >>> 不过我也遇到几个例子,比如 MariaDB
[2018-07-21 21:58:10] Zero King [Re: 1146] >>> 其他架构不能即时修复的话先分配AOSA也可以吧?
[2018-07-21 21:58:17] Mingcong Bai >>> 它会指定个 LINK_LIBRARY 列表
[2018-07-21 21:58:27] Mingcong Bai >>> LDFLAGS 无法提供到这个列表里面,还得手动 hack
[2018-07-21 21:58:39] Mingcong Bai [Re: 1213] >>> 确定无法更新的情况下?
[2018-07-21 21:58:49] 冰淇琳 >>> 来
[2018-07-21 21:58:52] 冰淇琳 >>> 让我们手撕 spec
[2018-07-21 21:59:26] Zero King [Re: 1216] >>> 如果打包人手不足,优先保证amd64
[2018-07-21 21:59:27] 冰淇琳 >>> 去主群
[2018-07-21 21:59:32] Mingcong Bai [Re: 1220] >>> K
[2018-07-21 21:59:35] Mingcong Bai [Re: 1219] >>> 好
[2018-07-21 21:59:44] Mingcong Bai >>> 这个我们还得后续确定下然后写到文档里面
[2018-07-21 21:59:46] Mingcong Bai >>> 免得误会
[2018-07-21 22:00:02] Mingcong Bai >>> @lmy441900 15 分后开始,是否就绪?
[2018-07-21 22:04:06] Junde Yhi >>> 大概可以,我没怎么准备
[2018-07-21 22:04:24] Mingcong Bai >>> K
[2018-07-21 22:04:27] Mingcong Bai >>> 十分钟后见
[2018-07-21 22:10:00] liushuyu >>> 5 分钟
[2018-07-21 22:13:57] 死 肥 宅 鹹魚 >>> 2 分鐘(
[2018-07-21 22:15:04] Mingcong Bai >>> #TOPIC 22:15 - 23:15 — 关于 AOSC OS 软件包二进制优化 overlay 的实现计划
[2018-07-21 22:15:07] Mingcong Bai [Re: 1231] >>> pinned the message
[2018-07-21 22:15:11] Mingcong Bai >>> @lmy441900 You're up.
[2018-07-21 22:15:34] Junde Yhi >>> Thank you Jeff. Welcome to AOSCC!...
[2018-07-21 22:15:42] Junde Yhi >>> ---
[2018-07-21 22:16:11] Junde Yhi >>> 那么现在有一个问题,有没有人不知道 Overlay 是什么概念
[2018-07-21 22:16:28] 死 肥 宅 鹹魚 >>> 超過躺下!(x
[2018-07-21 22:16:31] Mingcong Bai >>> 估计大多都不知道…… 还是考虑先重新介绍下?
[2018-07-21 22:16:36] Zero King >>> 类似Gentoo overlay?
[2018-07-21 22:17:27] Junde Yhi >>> Overlay 是 AOSCC 2017 之前提出的一个概念
[2018-07-21 22:18:09] Junde Yhi >>> 是针对 现代 处理器上的特性重新编译的一部分包
[2018-07-21 22:18:59] Junde Yhi >>> 比如目前 AOSC OS amd64 架构最低支持到 Pentium 4 Prescott
[2018-07-21 22:19:35] Junde Yhi >>> 我们会考虑到很多包(可能)可以利用编译器的自动树形向量化来提高运算性能
[2018-07-21 22:20:04] Junde Yhi >>> 就可以把编译器架构设置到比较高的指令集水平(比如 AVX)
[2018-07-21 22:20:35] Junde Yhi >>> 让编译器来把密集运算的代码进行向量化,利用 现代 处理器的特性来提高性能
[2018-07-21 22:21:37] Junde Yhi >>> 但是为了这部分性能提升而全盘重新编译是不值得的,所以 Overlay 就是使用包管理(dpkg)区分这两个版本,让用户 opt-in 的一批软件包
[2018-07-21 22:21:57] Junde Yhi >>> 这批软件包就只能在支持我们设定的更高指令集的处理器上运行
[2018-07-21 22:22:09] Junde Yhi >>> 这大概就是 Overlay 的一个想法
[2018-07-21 22:22:38] Junde Yhi >>> 那么 Overlay 在 AOSCC 2017 的时候有过一个 Talk 讲了我们的一些思考
[2018-07-21 22:22:49] Junde Yhi >>> 但是很明显我们什么都没有做(笑)
[2018-07-21 22:23:11] Mingcong Bai >>> Well,这个功能我倒是在 Autobuild3 里面实现了,master
* c515c49 (HEAD -> master, origin/testing, origin/master, origin/HEAD) arch/_common_switches: fix syntax
...
* 684eace contrib/autobuild-aoscarchive: fix overlay subdir check
* 702b60a contrib/autobuild-aoscarchive: one more syntax fix
* d9101d8 meta: more fixups for overlay
* 07cee5a proc/35-build_env_src: fix typo
* b9bb93b meta/overlay: haswell+ -> avx2+
* 58db2a6 autobuild-aoscarchive: fix syntax
...
* f396ff0 arch/amd64_haswell+: simplify
* 2cb6aa2 pm/dpkg/lib.sh: remove a trailing space
* fed5b3d meta: overlay support
[2018-07-21 22:23:16] Junde Yhi >>> 现在的问题还是当初的问题没有变化
[2018-07-21 22:23:28] Junde Yhi [Re: 1251] >>> 包没打出来一个
[2018-07-21 22:23:37] Mingcong Bai >>> Right.
[2018-07-21 22:23:50] Junde Yhi >>> 支持的话 apt-gen-list 也算早就有了
[2018-07-21 22:24:13] liushuyu >>> ld 的 find path 好像也到位了
[2018-07-21 22:24:34] Junde Yhi [Re: 1252] >>> 就是如何评价我们去做这个尝试(
[2018-07-21 22:24:35] Mingcong Bai [Re: 1256] >>> 实际上我们用不到这个特性,因为软件包里面文件路径都是一样的
[2018-07-21 22:24:47] Mingcong Bai [Re: 1257] >>> 求翻译
[2018-07-21 22:25:15] Junde Yhi >>> 已知 AVX 和 AVX2 确实能提升不少计算密集程序的性能
[2018-07-21 22:25:30] Junde Yhi >>> 但是也会导致一部分程序因为树形向量化而降低性能
[2018-07-21 22:25:56] Junde Yhi >>> 而且 Intel 的处理器在使用 AVX{,2} 指令集的时候功耗会明显增加
[2018-07-21 22:26:16] Junde Yhi >>> 一部分程序的性能提升不明显,比如 Veracrypt
[2018-07-21 22:26:45] Junde Yhi >>> 我当初去做的测试只覆盖了很小的几个程序
[2018-07-21 22:26:59] Junde Yhi >>> Botan 是完全看不出什么变化
[2018-07-21 22:27:04] liushuyu [Re: 1262] >>> 以及 @Icenowy 提到部分 CPU 的 avx 指令集是模拟的(
[2018-07-21 22:27:28] 冰淇琳 [Re: 1266] >>> 那是特例。
[2018-07-21 22:27:33] Mingcong Bai >>> 不过考虑到之前设定的 AMD64 overlay 是 haswell+ 也就是 -march=haswell
[2018-07-21 22:27:37] 冰淇琳 >>> 只要实现 optional 开启就行
[2018-07-21 22:27:41] Mingcong Bai >>> 是否可能有其他指令集影响了性能?
[2018-07-21 22:27:52] Junde Yhi [Re: 1270] >>> 没有,我是都试过的
[2018-07-21 22:28:33] Junde Yhi >>> 单调开 -mavx 和 -march=haswell 对 Veracrypt 的各算法速度 Benchmark 没有什么区别
[2018-07-21 22:28:46] Junde Yhi >>> 就可以确定是 avx 指令集的作用
[2018-07-21 22:28:51] Mingcong Bai >>> 也就是说都有类似的提升?
[2018-07-21 22:29:00] Junde Yhi >>> 嗯
[2018-07-21 22:29:04] liushuyu >>> 上次 @lmy441900 不是讲过 Intel 寄存器偷工减料的问题么(
[2018-07-21 22:29:25] Mingcong Bai [Re: 1275] >>> 另外我还有个疑问
[2018-07-21 22:29:28] Junde Yhi >>> 还有一个问题,真正需要 avx 和 avx2 的程序早就有做适配了
[2018-07-21 22:29:36] liushuyu >>> 然后已知 LMMS 有负优化
[2018-07-21 22:29:41] Mingcong Bai >>> 有一些软件,比如 libjpeg-turbo 会编译 avx2 的 asm
[2018-07-21 22:29:46] liushuyu >>> 我能观测到的
[2018-07-21 22:29:52] Mingcong Bai >>> 这种情况下如果没有指定 -march 是否会起作用?
[2018-07-21 22:29:59] Junde Yhi [Re: 1282] >>> 我猜是会的
[2018-07-21 22:30:03] liushuyu [Re: 1282] >>> 怕是要看软件
[2018-07-21 22:30:11] liushuyu >>> 比如 Gnuradio
[2018-07-21 22:30:12] Mingcong Bai [Re: 1283] >>> 所以还是要看具体例子去测试……
[2018-07-21 22:30:20] liushuyu >>> 是动态检测的
[2018-07-21 22:30:24] Junde Yhi >>> 套路就是几乎所有调 AES-NI 指令集的
[2018-07-21 22:30:30] Junde Yhi >>> 都是先做一次试探
[2018-07-21 22:30:39] Junde Yhi >>> 得到 SIGILL 之后就不再使用
[2018-07-21 22:30:46] liushuyu >>> SIGILL 了就算了
[2018-07-21 22:30:56] Mingcong Bai [Re: 1290] >>> 有意思
[2018-07-21 22:31:05] liushuyu >>> 有些带 asm 的是改不了了
[2018-07-21 22:31:05] Junde Yhi >>> (内核也是)
[2018-07-21 22:31:11] Mingcong Bai >>> 另外作为参考,这是最近的一个 avx2 编译器优化测试 https://www.phoronix.com/scan.php?page=article&item=gcc-81-1280v5&num=1 [webpage]
[2018-07-21 22:31:35] Mingcong Bai [Re: 1294] >>> 不过内核编译的时候可以选择目标内核而且 Phoronix 应该也有过测试,性能是有提升的
[2018-07-21 22:32:11] Junde Yhi [Re: 1296] >>> 内核也是会在启动的时候选择 ASM 版本的各种计算函数的
[2018-07-21 22:32:22] Mingcong Bai [Re: 1295] >>> 可以看见 GraphicsMagick 和 C-Ray 有比较明显的改善
[2018-07-21 22:32:32] Mingcong Bai [Re: 1297] >>> 稍等我看看能不能找到那篇
[2018-07-21 22:32:57] liushuyu >>> 我觉得是不是这个 subsystem 需要选择性挑选软件包
[2018-07-21 22:33:02] Junde Yhi >>> 这个性能提升,Phoronix 没有测功耗
[2018-07-21 22:33:10] Junde Yhi [Re: 1300] >>> 是要
[2018-07-21 22:33:20] liushuyu >>> 挑选对性能提升较好的才分进去
[2018-07-21 22:33:20] Junde Yhi >>> 这个配置大部分包没有用处
[2018-07-21 22:33:22] Mingcong Bai [Re: 1301] >>> 嗯这个我们需要购买工具去测试
[2018-07-21 22:33:51] Junde Yhi >>> 我觉得可以这样
[2018-07-21 22:34:04] Junde Yhi >>> 我们就试他一把
[2018-07-21 22:34:10] Mingcong Bai >>> https://github.com/graysky2/kernel_gcc_patch#conclusion [webpage]
[2018-07-21 22:34:14] Junde Yhi >>> 然后就像 @JeffBai 之前提到的那样
[2018-07-21 22:34:22] Junde Yhi >>> 收 #optreq
[2018-07-21 22:34:39] Mingcong Bai [Re: 1310] >>> 然后根据测试去决定 approve 还是 decline?
[2018-07-21 22:34:50] Junde Yhi [Re: 1311] >>> 可以
[2018-07-21 22:35:00] liushuyu >>> 这个测试包括什么
[2018-07-21 22:35:09] Junde Yhi >>> 我们自己往 overlay 加包也走这套
[2018-07-21 22:35:21] Junde Yhi [Re: 1313] >>> 倒是没想好
[2018-07-21 22:35:31] Junde Yhi >>> 一般程序内置 Benchmark 我们就跑那个
[2018-07-21 22:35:37] liushuyu >>> 主观的检查数个功能是否有性能提升
[2018-07-21 22:35:45] liushuyu [Re: 1316] >>> 那没有的呢
[2018-07-21 22:35:47] Junde Yhi >>> 没有的话本来我想写 phoronix-test-suite 的
[2018-07-21 22:35:51] Mingcong Bai >>> "-march= is an ISA selection option; it tells the compiler that it may use the instructions from the ISA. On an Intel/AMD64 platform with -march=native -O2 or lower OPT level, the code will likely end up with AVX instructions used but using shorter SSE XMM registers. To take full advantage of AVX YMM registers, the -ftree-vectorize, -O3 or -Ofast options should be used as well["
https://wiki.gentoo.org/wiki/GCC_optimization#-march [webpage]
[2018-07-21 22:35:58] Junde Yhi >>> 但是我之前写过一些
[2018-07-21 22:36:06] Junde Yhi >>> phoronix-test-suite 没文档
[2018-07-21 22:36:08] Mingcong Bai >>> march 的作用应该不只是对于 asm
[2018-07-21 22:36:33] 冰淇琳 >>> march 基本对 asm 无效
[2018-07-21 22:36:34] Mingcong Bai [Re: 1322] >>> http://www.phoronix-test-suite.com/documentation/ [webpage]
[2018-07-21 22:36:34] Junde Yhi [Re: 1323] >>> ASM 是一定会被写进二进制
[2018-07-21 22:36:41] 冰淇琳 >>> 仅作用于被编译的语言
[2018-07-21 22:36:42] liushuyu >>> 我们的旗子里面已经有 tree vectorize 了
[2018-07-21 22:36:47] Junde Yhi [Re: 1325] >>> 怎么写他的 suite 没文档
[2018-07-21 22:37:05] Mingcong Bai [Re: 1329] >>> 哦哦
[2018-07-21 22:37:05] Junde Yhi >>> 难道现在有了
[2018-07-21 22:37:12] Mingcong Bai >>> 这个我没细读
[2018-07-21 22:37:18] Mingcong Bai >>> 实在不行可以问问 Michael
[2018-07-21 22:38:06] Mingcong Bai >>> Clear Linux 在几个月前还在给 Qt 做 AVX2 构建模板,但是暂时没有任何性能数据
[2018-07-21 22:38:16] Mingcong Bai >>> - https://github.com/clearlinux/autospec/pull/175
- https://www.phoronix.com/scan.php?page=news_item&px=AVX2-Qt-Optimized-Clear-Linux [webpage]
[2018-07-21 22:38:34] Mingcong Bai >>> 我们可以确定会用 AVX2 作为 AMD64 暂时的 overlay 基准吗
[2018-07-21 22:39:18] Junde Yhi >>> 我选择 -march=haswell 本来是以为别的一些编译器开关可以优化些别的
[2018-07-21 22:39:55] Junde Yhi >>> 比如 BMI F16C FMA 等等
[2018-07-21 22:40:29] Mingcong Bai >>> https://sourceware.org/ml/libc-alpha/2017-08/msg00645.html 这里的例子,无论开不开 march,新的处理器都能利用到吗 @Icenowy
[2018-07-21 22:40:30] Junde Yhi >>> 但是现在这些指令集能获得什么加成还不知道
[2018-07-21 22:40:55] Mingcong Bai [Re: 1340] >>> Hmm
[2018-07-21 22:40:59] Mingcong Bai >>> 说起这个我有个问题
[2018-07-21 22:41:21] Mingcong Bai >>> 假设,我们只指定 -mavx2`,那么是否会打开 -mavx` 和下面所有的 sse 级别优化?
[2018-07-21 22:41:46] Junde Yhi [Re: 1339] >>> + if (CPU_FEATURES_ARCH_P (cpu_features, FMA_Usable)
+ && CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable))
+ return OPTIMIZE (fma);
+
+ return OPTIMIZE (sse2);
[2018-07-21 22:42:07] Mingcong Bai [Re: 1344] >>> Oof. 这是在构建时探测构建机器的吗
[2018-07-21 22:42:10] liushuyu >>> 我问个很愚蠢的问题(
[2018-07-21 22:42:16] Junde Yhi [Re: 1343] >>> 会打开 -mavx,因为 avx 对 sse 是取代关系,所以 sse 会被全开(全关)
[2018-07-21 22:42:19] Junde Yhi [Re: 1345] >>> 是的
[2018-07-21 22:42:28] Junde Yhi [Re: 1345] >>> 不是,运行时
[2018-07-21 22:42:40] Junde Yhi >>> sysdeps/x86_64/fpu/multiarch/ifunc-fma.h
[2018-07-21 22:42:43] Mingcong Bai [Re: 1349] >>> Oh. 所以针对这个特性是不需要额外开 march 就能利用到的?
[2018-07-21 22:42:44] liushuyu >>> ab3 在构建 h+ 应用时候需要独立的 spec 么
[2018-07-21 22:42:52] Mingcong Bai [Re: 1352] >>> 不需要
[2018-07-21 22:42:54] Junde Yhi [Re: 1351] >>> 看起来是
[2018-07-21 22:43:00] Mingcong Bai >>> 只用在 Autobuild 里面指定 ARCH=amd64/avx2+
[2018-07-21 22:43:20] Mingcong Bai >>> 然后 Autobuld3 会应用新的 CFLAGS,然后打出来的包也会放在 overlay 里面
[2018-07-21 22:43:54] liushuyu [Re: 1355] >>> 啊,我的意思是有些应用可能会有特殊优化 flags 在构建是要传递给构建系统
[2018-07-21 22:44:14] Mingcong Bai [Re: 1357] >>> 你可以同理用 if branch
[2018-07-21 22:44:20] liushuyu >>> 比方说什么 -DENABLE_AVX 之类
[2018-07-21 22:44:36] liushuyu [Re: 1358] >>> 就是 build
里面判断 ARCH 么
[2018-07-21 22:44:42] Mingcong Bai >>> if [[ "${CROSS:-$ARCH}" = "amd64/avx2+" ]]; then
export CPPFLAGS="${CPPFLAGS} -DENABLE_AVX"
fi
[2018-07-21 22:44:47] Mingcong Bai [Re: 1360] >>> 在 prepare 里面
[2018-07-21 22:44:53] Mingcong Bai [Re: 1361] >>> ^
[2018-07-21 22:45:28] liushuyu [Re: 1362] >>> CMake 之类同理放 build 或者 defines 里面?
[2018-07-21 22:45:38] Mingcong Bai >>> 嗯,逻辑如上
[2018-07-21 22:45:43] liushuyu >>> 好
[2018-07-21 22:45:55] Mingcong Bai >>> Autobuild 里面看见的只是个不同的架构
[2018-07-21 22:46:08] Mingcong Bai >>> 类似你跑 amd64 vs 跑 arm64 包的时候做的调整
[2018-07-21 22:46:28] Mingcong Bai >>> 除了最后 autobuild-aoscarchive 放置包的路径之外没有任何区别
[2018-07-21 22:46:50] liushuyu >>> (怎么感觉像某果的 x86_64 和 x86_64h 的玩法
[2018-07-21 22:47:01] Mingcong Bai >>> 可以这么理解
[2018-07-21 22:47:16] Mingcong Bai >>> @lmy441900 可以描述下新的 apt-gen-list 行为吗
[2018-07-21 22:47:34] Mingcong Bai >>> 用户要怎么打开 overlay,overlay 打开又是如何更改 APT 配置文件的
[2018-07-21 22:47:42] Junde Yhi >>> 新 apt-gen-list 在脚本里面硬编码了一段 apt config
[2018-07-21 22:48:18] Junde Yhi >>> 为了方便操作,对默认配置使用了 deb822 格式的 sources 文件
[2018-07-21 22:48:26] liushuyu >>> overlay 已经有包了么
[2018-07-21 22:48:42] Junde Yhi >>> apt-gen-list 会去看 /proc/cpuinfo 的 flags
[2018-07-21 22:49:00] Junde Yhi >>> 如果这里面有架构设定的指令集,就会允许用户打开
[2018-07-21 22:49:47] Junde Yhi >>> 打开之后 apt-gen-list 首先会给 *.sources(每个源一个文件)append 一段 overlay 的源 URL
[2018-07-21 22:50:29] Junde Yhi >>> 然后会放一个优先级配置到 /etc/apt/preferences.d,让 apt 优先选取 overlay 中的包
[2018-07-21 22:51:11] Junde Yhi >>> overlay 中的包和 non-overlay 中的包版本是一致的,这时 apt update && apt upgrade 就可以上 overlay 包
[2018-07-21 22:52:02] Junde Yhi >>> 否则用户可以退出 Insider overlay 计划,把优先级退到 500 以下就可以更新回原来没有特殊参数构建的包
[2018-07-21 22:52:16] Junde Yhi [Re: 1382] >>> 这里目前没有做回退,要手动操作
[2018-07-21 22:52:24] Mingcong Bai [Re: 1382] >>> 更改优先级需要手动操作吗
[2018-07-21 22:52:27] Mingcong Bai >>> Oh...
[2018-07-21 22:52:31] Junde Yhi >>> 可以做的
[2018-07-21 22:52:40] Mingcong Bai >>> 嗯,这个应该也自动化一下
[2018-07-21 22:52:52] Mingcong Bai >>> 另外一点
[2018-07-21 22:53:13] Mingcong Bai >>> 是一系列问题
[2018-07-21 22:54:09] Mingcong Bai >>> — 是否应该在安装文档里面指引用户打开 overlay,或者通过 systemd service 在第一次启动时探测并打开 overlay?
— 假设我们可以确定 AVX2 指令优化会导致显著能耗增加,是否应该在 apt-gen-list 和文档里面写个警告?
[2018-07-21 22:54:27] Junde Yhi >>> 我觉得是 opt-in
[2018-07-21 22:54:33] Junde Yhi >>> 就是默认不开启
[2018-07-21 22:54:46] Junde Yhi [Re: 1390] >>> 可以写个警告
[2018-07-21 22:55:00] Mingcong Bai [Re: 1390] >>> 以及发热 *
[2018-07-21 22:55:01] liushuyu [Re: 1392] >>> 那只能靠文档了
[2018-07-21 22:55:15] Mingcong Bai [Re: 1392] >>> 除了能源/温度之外还有什么可能的风险吗
[2018-07-21 22:55:38] Lion [Re: 1115] >>> 可以吧
[2018-07-21 22:56:13] liushuyu [Re: 1396] >>> 应该没有了吧
[2018-07-21 22:56:34] Mingcong Bai >>> 那么为什么需要 opt-in 让用户手动打开呢……
[2018-07-21 22:56:45] liushuyu >>> AOSC 的文档我感觉似乎没什么人注意,是我的错觉么
[2018-07-21 22:57:05] Mingcong Bai [Re: 1400] >>> 不是
[2018-07-21 22:57:08] Junde Yhi [Re: 1399] >>> 目前还是 experimental 的,我建议 opt-in
[2018-07-21 22:57:09] liushuyu >>> 写在文档里面怕是会有人看不到
[2018-07-21 22:57:16] Mingcong Bai [Re: 1402] >>> 明白
[2018-07-21 22:57:37] Mingcong Bai >>> 另外我观察到一个有意思的例子
[2018-07-21 22:58:01] Mingcong Bai >>> [document]
[2018-07-21 22:58:13] Mingcong Bai >>> https://www.phoronix.com/scan.php?page=news_item&px=MTQ1MTA [photo]
[2018-07-21 22:58:39] Junde Yhi >>> 另外就是我自己的考虑了,首先我肯定有设备不会打开 Overlay,其次我是不喜欢有东西帮我考虑问题
[2018-07-21 22:58:55] Mingcong Bai [Re: 1408] >>> 能理解
[2018-07-21 22:59:04] Mingcong Bai >>> 而且这种需要警告的情况下,还是不应该默认开
[2018-07-21 22:59:12] Mingcong Bai >>> 毕竟这样用户很可能不会注意到可能的后果
[2018-07-21 22:59:22] Mingcong Bai [Re: 1407] >>> @lmy441900 这种可能是预热导致的?
[2018-07-21 22:59:34] Mingcong Bai >>> (但是你之前说过 avx2 才有这种情况?
[2018-07-21 22:59:40] Junde Yhi [Re: 1412] >>> 不是,应该就是纯粹的性能倒退
[2018-07-21 22:59:58] Junde Yhi >>> 不能完全说是预热导致的问题
[2018-07-21 23:00:39] Junde Yhi >>> 应该说它没有完全长时间利用 avx,得不到性能提升
[2018-07-21 23:00:47] Junde Yhi >>> 噢对了,我之前在 Rust 那边看到有个人写的对 avx 的思考……
[2018-07-21 23:01:06] liushuyu [Re: 1417] >>> 怎么说?
[2018-07-21 23:01:11] Junde Yhi [Fwd: Rust每日新闻] >>> 简单描述了AVX指令(英特尔处理器上的SIMD)可能存在的性能缺陷
可能对某些人有用
https://gist.github.com/rygorous/32bc3ea8301dba09358fd2c64e02d774 [webpage]
[2018-07-21 23:01:16] gumblex [Re: 1262] >>> 而且用多了会降频
[2018-07-21 23:01:34] liushuyu [Re: 1420] >>> 过热的副作用?
[2018-07-21 23:01:37] Junde Yhi [Re: 1420] >>> 看起来是只要用了就会降频
[2018-07-21 23:01:42] Mingcong Bai [Re: 1421] >>> Intel 的设计
[2018-07-21 23:01:55] Mingcong Bai >>> 类似单核 Turbo Boost 和全核 Turbo Boost 的频率区别
[2018-07-21 23:01:58] Mingcong Bai >>> 这个在 AMD 上也有
[2018-07-21 23:02:36] Mingcong Bai >>> 我还有一个担忧就是 Ryzen 和 -march=haswell 的兼容性
[2018-07-21 23:02:47] Mingcong Bai >>> 我认为如果测试后发现有问题可能还是需要拆散所有的 flags
[2018-07-21 23:03:09] Junde Yhi [Re: 1426] >>> 理论上 -march=haswell 就对标 Ryzen 的 zen 微架构
[2018-07-21 23:03:18] Junde Yhi >>> 是一个子集
[2018-07-21 23:03:24] Mingcong Bai >>> 嗯,不过作为一个应急计划?
[2018-07-21 23:03:35] Junde Yhi >>> 可以
[2018-07-21 23:04:24] Lion [Re: 1207] >>> 岔个话题,这个 --as-needed 参数当时是怎么考虑的?
[2018-07-21 23:04:49] Mingcong Bai [Re: 1432] >>> 这是当时 GNOME 一个 linker bug(因为比较常见),你可以去看看 Arch 里面任意的 GNOME 包
[2018-07-21 23:04:55] Lion >>> 作为默认参数其实是有一定风险的……
[2018-07-21 23:04:59] liushuyu >>> 剩余 10 分钟
[2018-07-21 23:05:07] Mingcong Bai [Re: 1431] >>> 最后我还是想推荐一下 Overlay 命名
[2018-07-21 23:05:17] Lion [Re: 1434] >>> 具体问题我在主群已经举例子了
[2018-07-21 23:05:21] Mingcong Bai >>> haswell+ vs avx2+,我觉得还是应该定义到优化本体
[2018-07-21 23:05:32] Mingcong Bai >>> 否则 AMD 用户可能会被迷惑,感觉不能开
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> 这个“二进制”链接的时候切勿 as-needed
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> 甚至软件会指定一个
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> no-as-needed
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> 无论是软件还是库,在内存空间里用到“这种写法”都只能让 ld 避开筛查
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> 简而言之就是利用 ld 的 DT_NEEDED 形成的二进制 .so依赖,来实现免 dlopen 直接 dlsym。
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> 给你提供一个真实事故案例参照吧:virtualgl(这个“库”不是拿来继续被链接的,而是用来 LD_PRELOAD 的)
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> 哦不,virtualgl+32
[2018-07-21 23:05:49] Lion [Fwd: Lion] >>> https://github.com/AOSC-Dev/aosc-os-abbs/commit/01ccac201f8e4369235b5709b49d9bcaf78ef757 [webpage]
[2018-07-21 23:05:59] Mingcong Bai [Re: 1438] >>> 这个我预先在 autobuild3 里面改了,这个看各位怎么想?
[2018-07-21 23:06:15] gumblex [Re: 1318] >>> 自带单元测试?
[2018-07-21 23:06:31] Mingcong Bai [Re: 1449] >>> 或者利用典型用例
[2018-07-21 23:06:36] liushuyu [Re: 1448] >>> 我觉得 avx2+ 好一些,而且避免潜在商标
[2018-07-21 23:07:13] gumblex >>> 还有一个问题,有没有可能我们自己加 PGO
[2018-07-21 23:07:22] Mingcong Bai [Re: 1452] >>> 什么意思
[2018-07-21 23:07:27] Mingcong Bai [Re: 1451] >>> @lmy441900 Yes?
[2018-07-21 23:07:45] gumblex >>> 上游没提供 pgo 选项但可以这么编译
[2018-07-21 23:08:01] Mingcong Bai [Re: 1455] >>> 这个和具体的指令集 overlay 没有关系,如果需要的话我们可以全局开
[2018-07-21 23:08:06] liushuyu [Re: 1452] >>> 那也是选择性的了
[2018-07-21 23:08:26] Lion [Re: 1442] >>> 我有一个想法,可能对解决这套参数的冲突问题有所帮助。 @Icenowy @JeffBai 我们要不要考虑对构建期的各种 flags 变量,区分前缀(建议)和后缀(强制)两种调整?
[2018-07-21 23:08:28] liushuyu >>> 有些软件不好跑 PGO
[2018-07-21 23:08:31] Junde Yhi [Re: 1454] >>> 我主要是考虑到这里面不止 avx2
[2018-07-21 23:08:36] Junde Yhi >>> 但是也可以
[2018-07-21 23:08:42] Junde Yhi >>> 我觉得可以
[2018-07-21 23:08:45] Mingcong Bai [Re: 1458] >>> Right,我先记下
[2018-07-21 23:08:57] Mingcong Bai >>> 然后我还有一个计划
[2018-07-21 23:09:00] liushuyu [Re: 1460] >>> 那叫什么, higher x64 么(
[2018-07-21 23:09:12] Junde Yhi [Re: 1465] >>> modern x64
[2018-07-21 23:09:13] Mingcong Bai >>> 我准备给 ppc32be (powerpc) 上加 AltiVec/G4 overlay
[2018-07-21 23:09:28] Mingcong Bai >>> 名称我没想好,暂时先作为一个初步想法好了
[2018-07-21 23:09:33] Mingcong Bai [Re: 1466] >>> 这个时效性有问题
[2018-07-21 23:09:44] Mingcong Bai >>> 十年后你不能叫 Haswell Modern
[2018-07-21 23:09:49] liushuyu [Re: 1467] >>> AltiVec 是商标么
[2018-07-21 23:09:54] Mingcong Bai [Re: 1471] >>> 是商标
[2018-07-21 23:10:11] Junde Yhi >>> avx2+ 吧
[2018-07-21 23:10:21] Junde Yhi >>> 或者这个 + 你们觉得有没有必要
[2018-07-21 23:10:23] liushuyu >>> 5 分钟
[2018-07-21 23:10:29] Mingcong Bai [Re: 1473] >>> 好的那么我总结下,然后各位确定下?
[2018-07-21 23:10:33] gumblex [Re: 1439] >>> 还有 bmi(
[2018-07-21 23:10:38] Mingcong Bai [Re: 1474] >>> 我觉得这里表达的应该是 > AVX2?
[2018-07-21 23:10:39] Junde Yhi >>> 有 + 是因为之前给的是微架构名
[2018-07-21 23:10:41] Mingcong Bai >>> >= *
[2018-07-21 23:10:43] liushuyu [Re: 1474] >>> 有除了 avx2 的指令
[2018-07-21 23:10:48] Lion [Re: 1463] >>> 因为很多问题出现在构建的工具链给了一套参数,结果我们强制用对立参数覆盖了。比如 -O,我们用 -O3 强制覆盖,比如 -Wl,--no-as-needed ,我们后面来一句 -Wl,--as-needed 又完蛋了。我们把参数加到了一切参数后面其实是个很强的影响
[2018-07-21 23:11:11] Mingcong Bai [Re: 1479] >>> 因为不只是 avx2
[2018-07-21 23:11:22] Mingcong Bai >>> 而且暗指用于带有 avx2 或更新的处理器?
[2018-07-21 23:11:34] Junde Yhi >>> 不是我的本意,但是也 OK
[2018-07-21 23:11:38] Mingcong Bai >>> 好的
[2018-07-21 23:11:40] Mingcong Bai >>> 我总结一下
[2018-07-21 23:12:12] gumblex [Re: 1484] >>> 那个狮子的 bmi 怎么处理
[2018-07-21 23:13:11] Junde Yhi [Re: 1488] >>> break
[2018-07-21 23:13:43] Lion >>> 🌚
[2018-07-21 23:14:11] Junde Yhi >>> 实际上主力军是 AVX
[2018-07-21 23:14:23] Junde Yhi >>> 因为 AVX2 是浮点运算指令集
[2018-07-21 23:14:31] Junde Yhi >>> AVX 是整数向量加速
[2018-07-21 23:14:52] Mingcong Bai >>> — Overlay 属于可选 opt-in 项目,并且需要警告用户可能的温度/功耗后果。
— 指令集优化 Overlay 将首先用于带有 AVX2 的 AMD64 处理器(Intel Haswell 或更新,AMD Ryzen 或更新),名称为 avx+。这个 Overlay 暂定 CFLAGS 为 `-march=haswell`,如果导致部分 Intel Haswell 处理器(如一些缺少特定指令的低端处理器)或 AMD 处理器出现问题,那么考虑应急计划,单独打开特定指令集。
— apt-gen-list 和 autobuild3 支持已经就绪,需要补充文档。
— 初步计划给 32 位 PowerPC 大端序 Macintosh 做一个 Overlay,针对 AltiVec 指令集。
[2018-07-21 23:14:58] gumblex [Re: 1489] >>> 我意思是广告是不是要加小字
[2018-07-21 23:15:20] Mingcong Bai [Re: 1494] >>> @lmy441900 @liushuyu @Lionium 请认证一下上述内容
[2018-07-21 23:15:21] Junde Yhi [Re: 1494] >>> 2+
[2018-07-21 23:15:32] Mingcong Bai [Re: 1497] >>> Fixed
[2018-07-21 23:15:36] Junde Yhi >>> avx 在 snb 就有了
[2018-07-21 23:15:43] Mingcong Bai [Re: 1499] >>> Typo
[2018-07-21 23:15:52] liushuyu [Re: 1494] >>> Confirmed
[2018-07-21 23:15:56] Mingcong Bai [Re: 1496] >>> 以及 @gumblex
[2018-07-21 23:16:14] Junde Yhi [Re: 1494] >>> apt-gen-list 还要做修补
[2018-07-21 23:16:17] gumblex [Re: 1494] >>> 狮子的那个考虑在 apt-gen-list 里检测?
[2018-07-21 23:16:27] Lion >>> BMI 本身就不是 AVX2 指令集的一部分啊
[2018-07-21 23:16:27] Lion >>> BMI2*
[2018-07-21 23:16:38] Mingcong Bai [Re: 1503] >>> Fixed.
[2018-07-21 23:16:42] Mingcong Bai [Re: 1504] >>> 应该会的
[2018-07-21 23:16:42] Junde Yhi [Re: 1505] >>> 对,所以这个命名需要标小字
[2018-07-21 23:16:47] gumblex >>> 你广告是 avx2 但必须要 bmi
[2018-07-21 23:16:51] 御坂0x4e21 看到她灌水一律赶她下线 [Re: 1494] >>> 是否考虑开放一个用户提交列表,列出明确无法使用的 CPU 型号……?
[2018-07-21 23:17:01] Mingcong Bai [Re: 1511] >>> 我列为问题
[2018-07-21 23:17:09] Junde Yhi >>> 之前我用 haswell+ 这个死长的名字就是为了表明这里面不止 avx2
[2018-07-21 23:17:22] Junde Yhi >>> + 表示 skylake 也可以用
[2018-07-21 23:17:35] Lion [Re: 1509] >>> 唉…你还不如不要用这个名字了
[2018-07-21 23:17:39] Lion >>> Haswell+ 就好了
[2018-07-21 23:17:42] liushuyu [Re: 1513] >>> AVX2+ 的加号的意义
[2018-07-21 23:17:51] gumblex [Re: 1516] >>> AMD 表示
[2018-07-21 23:17:52] liushuyu [Re: 1516] >>> 又回去了(
[2018-07-21 23:18:23] 御坂0x4e21 看到她灌水一律赶她下线 >>> haswell-ryzen+(×
[2018-07-21 23:18:24] Lion [Re: 1518] >>> 没办法啊…给编译器开的就是一套按照某款 CPU 设计的组合优化参数
[2018-07-21 23:18:40] Junde Yhi >>> 龙芯那边还要 ls3a2kc+(
[2018-07-21 23:18:45] Mingcong Bai >>> 那么我先列为问题吧,有必要的话我们可以二次讨论
[2018-07-21 23:18:58] Lion >>> 总不能说 amd64 就不能是 Intel 的架构了吧(哪怕 Intel 自己搞了个同义词)
[2018-07-21 23:19:12] Mingcong Bai [Fwd: Mingcong Bai] >>> — Overlay 属于可选 opt-in 项目,并且需要警告用户可能的温度/功耗后果。
— 指令集优化 Overlay 将首先用于带有 AVX2 的 AMD64 处理器(Intel Haswell 或更新,AMD Ryzen 或更新),名称为 avx2+。这个 Overlay 暂定 CFLAGS 为 `-march=haswell`,如果导致部分 Intel Haswell 处理器(如一些缺少特定指令的低端处理器)或 AMD 处理器出现问题,那么考虑应急计划,单独打开特定指令集。
— Autobuild3 支持已经就绪,而 apt-gen-list 依然需要补充部分功能。两者均需要补充文档。
— 初步计划给 32 位 PowerPC 大端序 Macintosh 做一个 Overlay,针对 AltiVec 指令集。
当前顾虑/疑问
— 是否考虑开放一个用户提交列表,列出明确无法使用的 CPU 型号?
— Haswell+ 作为 overlay 名称是否更准确?
[2018-07-21 23:19:36] Mingcong Bai >>> @lmy441900 是否考虑在 29 日补充讨论?
[2018-07-21 23:19:39] Mingcong Bai >>> 时间已经到了
[2018-07-21 23:19:58] Junde Yhi >>> 因为刚才大家说 avx2+ 的 + 还可以作引申理解,表示这里面还有更多
[2018-07-21 23:20:11] Junde Yhi >>> 我觉得标个小字可能就还行
[2018-07-21 23:20:26] liushuyu >>> 我觉得xia写到文档吧
[2018-07-21 23:21:02] Lion >>> 如果确实主要就是这个指令集的话,那没问题。文档肯定要写的,并列出简单的判定方法
[2018-07-21 23:21:06] Mingcong Bai [Re: 1526] >>> @lmy441900 还有 9 分钟就到投票时间了
[2018-07-21 23:21:19] liushuyu >>> 反正默认禁用,如果有人要开启,一定问过人或者看过文档
[2018-07-21 23:21:45] Junde Yhi >>> 所以 29 号之前对这个课题先不要有动作
[2018-07-21 23:22:00] Junde Yhi >>> 我们敲定之后再做下一步打算,省得改来改去
[2018-07-21 23:22:08] Junde Yhi >>> OK 今天先到这里
[2018-07-21 23:22:20] Mingcong Bai [Fwd: Mingcong Bai] >>> — Overlay 属于可选 opt-in 项目,并且需要警告用户可能的温度/功耗后果。
— 指令集优化 Overlay 将首先用于带有 AVX2 的 AMD64 处理器(Intel Haswell 或更新,AMD Ryzen 或更新),名称为 avx2+。这个 Overlay 暂定 CFLAGS 为 `-march=haswell`,如果导致部分 Intel Haswell 处理器(如一些缺少特定指令的低端处理器)或 AMD 处理器出现问题,那么考虑应急计划,单独打开特定指令集。
— Autobuild3 支持已经就绪,而 apt-gen-list 依然需要补充部分功能。两者均需要补充文档。
— 初步计划给 32 位 PowerPC 大端序 Macintosh 做一个 Overlay,针对 AltiVec 指令集。
— Overlay 定义需要额外文档。
— 7 月 29 日需要额外讨论,在此之前不要进行任何实现操作。
当前顾虑/疑问
— 是否考虑开放一个用户提交列表,列出明确无法使用的 CPU 型号?
— Haswell+ 作为 overlay 名称是否更准确?
[2018-07-21 23:22:26] Mingcong Bai >>> 好的那我发到公告了
[2018-07-21 23:22:32] Junde Yhi >>> ACK
[2018-07-21 23:22:43] Mingcong Bai >>> 30 分之前自由活动
[2018-07-21 23:22:50] liushuyu >>> →→→ END
[2018-07-21 23:22:57] 死 肥 宅 鹹魚 [Re: 1537] >>> pakreqBot 也就緒(x
[2018-07-21 23:23:08] Junde Yhi >>> *哐……哗啦*
[2018-07-21 23:23:21] 死 肥 宅 鹹魚 >>> [document]
[2018-07-21 23:23:23] gumblex >>> packages 站等你有包在改
[2018-07-21 23:23:24] Junde Yhi >>> *杂乱的人声和脚步声*
[2018-07-21 23:23:24] liushuyu [Re: 1542] >>> 咸鱼 你看过 Tg 认证么(
[2018-07-21 23:23:38] 死 肥 宅 鹹魚 [Re: 1547] >>> 那是啥
[2018-07-21 23:23:42] Junde Yhi [Re: 1545] >>> ok
[2018-07-21 23:23:59] liushuyu [Re: 1548] >>> 这样 pakreq 站可以图形化批量打勾(
[2018-07-21 23:24:12] 死 肥 宅 鹹魚 [Re: 1550] >>> 哦你說那個登錄啊
[2018-07-21 23:24:28] Mingcong Bai [Fwd: LAX VPS] >>> @gumblex 投票群的ID(
[2018-07-21 23:24:30] 死 肥 宅 鹹魚 >>> 還以爲你說某種奇怪的 certification(
[2018-07-21 23:24:45] Zero King >>> Update pinned message?
[2018-07-21 23:24:52] Mingcong Bai [Re: 1554] >>> Will upate at 30
[2018-07-21 23:24:57] 死 肥 宅 鹹魚 >>> 那個有做的打算,什麼時候完成不能保證(
[2018-07-21 23:25:34] liushuyu [Re: 1556] >>> Current ETA 3347/10/30?(
[2018-07-21 23:25:55] 死 肥 宅 鹹魚 [Re: 1557] >>> 9999/99/99
[2018-07-21 23:26:13] 死 肥 宅 鹹魚 >>> (x
[2018-07-21 23:26:17] gumblex >>> +infinity
[2018-07-21 23:26:18] liushuyu [Re: 1558] >>> Date format invalid
[2018-07-21 23:26:33] gumblex [Re: 1560] >>> certified by PostgreSQL(
[2018-07-21 23:26:46] 死 肥 宅 鹹魚 [Re: 1562] >>> hhhhh
[2018-07-21 23:29:41] liushuyu >>> 20 秒
[2018-07-21 23:30:02] Mingcong Bai >>> #TOPIC 23:30 - 0:00 — Core 6 代号投票
[2018-07-21 23:30:05] Mingcong Bai [Re: 1565] >>> pinned the message
[2018-07-21 23:30:41] 死 肥 宅 鹹魚 >>> 去另一個羣麼?
[2018-07-21 23:30:50] Mingcong Bai >>> 好的在投票之前,我们还需要再征集 7 个代号,各位请先参考 https://pastebin.aosc.io/paste/cjSKP~s3jFAotcFVJLfiLg 看看现有的代号,然后以这个格式提交额外代号:
代号(中文解释)
[2018-07-21 23:30:56] Mingcong Bai [Re: 1567] >>> Patience my friend.
[2018-07-21 23:31:08] Mingcong Bai [Re: 1568] >>> 先到先得,提出来的代号当场审阅
[2018-07-21 23:31:25] 死 肥 宅 鹹魚 >>> FsckThisShitImOut
[2018-07-21 23:31:37] Mingcong Bai [Re: 1571] >>> Invalidated. 脏话
[2018-07-21 23:31:39] liushuyu >>> No offense
[2018-07-21 23:31:40] Junde Yhi [Re: 1571] >>> 笑出声
[2018-07-21 23:31:45] 死 肥 宅 鹹魚 [Re: 1572] >>> (233
[2018-07-21 23:31:56] 死 肥 宅 鹹魚 >>> FsckThisShootImOut
[2018-07-21 23:32:00] Junde Yhi >>> 我替我同学提名一个
[2018-07-21 23:32:09] liushuyu [Re: 1576] >>> Invalid
[2018-07-21 23:32:11] Junde Yhi >>> 等一下,我先查重
[2018-07-21 23:32:14] Mingcong Bai >>> Foo Young(芙蓉蛋)
[2018-07-21 23:32:17] 死 肥 宅 鹹魚 >>> 提艾老闆提一個 FranXX
[2018-07-21 23:32:21] LAX VPS >>> Fibroken(光缆断啦)
[2018-07-21 23:32:26] Mingcong Bai [Re: 1581] >>> FranXX In
[2018-07-21 23:32:33] Mingcong Bai [Re: 1581] >>> 我需要个中文定义
[2018-07-21 23:32:37] Mingcong Bai [Re: 1582] >>> Taken.
[2018-07-21 23:32:40] Mingcong Bai >>> 3/7 occupied.
[2018-07-21 23:32:41] Lion [Re: 1584] >>> 一个动漫
[2018-07-21 23:32:42] Leway Colin [Re: 1580] >>> 😂😂
[2018-07-21 23:32:42] 死 肥 宅 鹹魚 [Re: 1584] >>> 那部動畫
[2018-07-21 23:32:59] 死 肥 宅 鹹魚 >>> Darling in the FranXX
[2018-07-21 23:33:03] Lion >>> 亲爱的什么的
[2018-07-21 23:33:07] Mingcong Bai [Re: 1591] >>> 知道了
[2018-07-21 23:33:09] 死 肥 宅 鹹魚 >>> https://www.wikiwand.com/en/Darling_in_the_Franxx [webpage]
[2018-07-21 23:33:11] Mingcong Bai >>> 还有四个位置
[2018-07-21 23:33:15] 死 肥 宅 鹹魚 >>> 國家隊
[2018-07-21 23:33:17] Lion >>> 的弗朗西克斯x
[2018-07-21 23:33:18] gumblex >>> Fujian (
[2018-07-21 23:33:25] Mingcong Bai [Re: 1597] >>> Taken. 4/7
[2018-07-21 23:33:36] Junde Yhi [Re: 1589] >>> 我有一句……不知该说不该说
[2018-07-21 23:33:41] Lion [Re: 1597] >>> 这是一个什么思路hhh
[2018-07-21 23:33:45] Mingcong Bai [Re: 1599] >>> 你同学的代号是?
[2018-07-21 23:33:49] Zero King >>> Fork
[2018-07-21 23:33:50] liushuyu [Re: 1599] >>> 放(
[2018-07-21 23:33:56] Mingcong Bai [Re: 1602] >>> Taken. 5/7
[2018-07-21 23:34:00] CRT >>> 人字拖还行,听起来比触发器好一点(
[2018-07-21 23:34:03] Junde Yhi [Re: 1601] >>> 重了
[2018-07-21 23:34:03] gumblex [Re: 1600] >>> "Chongqing"
[2018-07-21 23:34:06] Junde Yhi >>> Foxtrot
[2018-07-21 23:34:07] Mingcong Bai [Re: 1606] >>> K
[2018-07-21 23:34:12] Mingcong Bai >>> 还有两个位置
[2018-07-21 23:34:16] 死 肥 宅 鹹魚 [Re: 1597] >>> emmm Fork 我之前第一封郵件裏發了
[2018-07-21 23:34:28] Lion [Re: 1607] >>> 那么确切地说是 Hujian
[2018-07-21 23:34:30] 死 肥 宅 鹹魚 >>> emmm Fork 我之前第一封郵件裏發了
[2018-07-21 23:34:34] 死 肥 宅 鹹魚 >>> 然後被刷掉了(
[2018-07-21 23:34:40] Mingcong Bai [Re: 1613] >>> 嘛这次没奖励就算了……
[2018-07-21 23:34:44] 死 肥 宅 鹹魚 [Re: 1615] >>> (
[2018-07-21 23:34:49] Mingcong Bai [Fwd: Mingcong Bai] >>> 还有两个位置
[2018-07-21 23:34:49] Junde Yhi >>> 看到 Fantasia 我就想到我即将抽不到的卡
[2018-07-21 23:34:59] liushuyu >>> "Order yours now, positions are filling up quickly!"
[2018-07-21 23:35:13] Mingcong Bai >>> Farseer(先知)
[2018-07-21 23:35:16] Mingcong Bai >>> 6/7
[2018-07-21 23:35:22] Zero King >>> Freedom!
[2018-07-21 23:35:22] Mingcong Bai >>> Let's get one more.
[2018-07-21 23:35:30] Lion >>> 🌚
[2018-07-21 23:35:30] liushuyu [Re: 1622] >>> 7/7
[2018-07-21 23:35:31] 死 肥 宅 鹹魚 >>> FeelsLibreMan
[2018-07-21 23:35:37] Mingcong Bai [Re: 1622] >>> This?
[2018-07-21 23:35:41] Mingcong Bai [Re: 1626] >>> Or this?
[2018-07-21 23:35:53] Zero King >>> Feel free(
[2018-07-21 23:36:03] liushuyu >>> Which came first gets in?
[2018-07-21 23:36:13] 死 肥 宅 鹹魚 [Re: 1630] >>> (
[2018-07-21 23:36:22] Zero King [Re: 1629] >>> (pun intended)
[2018-07-21 23:36:28] gumblex [Re: 1597] >>> Foshan )
[2018-07-21 23:37:05] Mingcong Bai [Re: 1630] >>> K
[2018-07-21 23:37:07] Mingcong Bai >>> Freedom it is
[2018-07-21 23:37:17] Mingcong Bai >>> 各位稍等
[2018-07-21 23:37:20] 死 肥 宅 鹹魚 [Re: 1633] >>> Fooshan
[2018-07-21 23:37:24] Mingcong Bai >>> 我开始制作投票
[2018-07-21 23:37:34] Mingcong Bai >>> 各位麻烦抓紧时间加入 aosc.io/aoscc2018polls [webpage]
[2018-07-21 23:37:40] Mingcong Bai >>> 所有投票都在那里进行
[2018-07-21 23:37:42] 死 肥 宅 鹹魚 [Re: 1637] >>> (By Icenowy
[2018-07-21 23:37:52] Zero King >>> 或者IRC?
[2018-07-21 23:37:55] Junde Yhi [Re: 1639] >>> Not Found
[2018-07-21 23:37:56] 死 肥 宅 鹹魚 [Re: 1639] >>> Not Found
[2018-07-21 23:38:00] Mingcong Bai [Re: 1642] >>> IRC 单独进行
[2018-07-21 23:38:00] gumblex [Re: 1639] >>> 404
[2018-07-21 23:38:06] Mingcong Bai >>> https://t.me/aoscc2018polls
[2018-07-21 23:38:07] 死 肥 宅 鹹魚 >>> t.me 打錯了吧(
[2018-07-21 23:38:08] Mingcong Bai >>> 抱歉打错
[2018-07-21 23:38:15] Mingcong Bai >>> 现在里面才 19 个人
[2018-07-21 23:38:46] Lion [Re: 1649] >>> 删了错的信息吧
[2018-07-21 23:39:26] Mingcong Bai >>> 正在联系 @lilyayta
[2018-07-21 23:40:20] liushuyu >>> 我觉得恐怕 30 分钟投不完
[2018-07-21 23:41:08] Zero King >>> 并行投票?
[2018-07-21 23:41:43] Lion >>> 这是要有八亿玩家在线激战就好了
[2018-07-21 23:41:51] gumblex [Re: 1647] >>> 在托腮广告吗
[2018-07-21 23:44:16] Mingcong Bai [Re: 1656] >>> Please
[2018-07-21 23:44:26] Mingcong Bai >>> 好的我现在发布投票
[2018-07-21 23:48:57] Zamir SUN >>> 注意不要错误地在某个投票小组点多次
[2018-07-21 23:49:06] Zamir SUN >>> 当你点第三次的时候会被提示操作过频繁
[2018-07-21 23:49:17] Zamir SUN >>> 然后就得等会儿才能用了
[2018-07-21 23:50:34] OriginCode >>> 已投(8:50)
[2018-07-21 23:51:08] NeoTimesharingSystem >>> 以頭
[2018-07-21 23:51:25] 御坂0x4e21 看到她灌水一律赶她下线 >>> 已投
[2018-07-21 23:51:25] Mingcong Bai [Re: 1663] >>> 咦你用的是拼音?
[2018-07-21 23:51:31] NeoTimesharingSystem [Re: 1665] >>> 注音
[2018-07-21 23:51:32] Lion >>> 以头
[2018-07-21 23:51:33] Mingcong Bai >>> 已投
[2018-07-21 23:51:36] Mingcong Bai [Re: 1666] >>> Huh
[2018-07-21 23:51:45] NeoTimesharingSystem >>> 繁體的
[2018-07-21 23:51:52] Mingcong Bai >>> 明白了
[2018-07-21 23:51:53] 御坂0x4e21 看到她灌水一律赶她下线 >>> ㄧˇㄊㄡˊ
[2018-07-21 23:52:09] Staph. aureus | In your GI Tract >>> 「已投」不分簡繁
[2018-07-21 23:52:20] liushuyu >>> Voted
[2018-07-21 23:53:07] 死 肥 宅 鹹魚 >>> 已投(
[2018-07-21 23:53:09] Mingcong Bai >>> IRC 频道没有独特用户
[2018-07-21 23:53:15] Mingcong Bai >>> 所以投票也没意义了
[2018-07-21 23:53:17] LAX VPS >>> (
[2018-07-21 23:54:00] Mingcong Bai >>> 我们投票率已经超过北美某国了,鼓掌(
[2018-07-21 23:54:18] NeoTimesharingSystem >>> Canada?
[2018-07-21 23:54:19] Mingcong Bai >>> Oops 忘了不能发政治内容
[2018-07-21 23:54:23] Mingcong Bai [Re: 1680] >>> US
[2018-07-21 23:54:25] LAX VPS >>> voted
[2018-07-21 23:54:41] 白雾 纱织 >>> voted
[2018-07-21 23:55:43] NeoTimesharingSystem >>> 已換票
[2018-07-21 23:55:51] Mingcong Bai [Re: 1685] >>> 没问题
[2018-07-21 23:56:36] Mingcong Bai >>> 零点还有决赛
[2018-07-21 23:56:42] Mingcong Bai >>> 看来只会有四个选项
[2018-07-21 23:57:27] 白雾 纱织 >>> 疯狂拉票(x
[2018-07-21 23:58:34] Staph. aureus | In your GI Tract >>> 建議給8個選項⋯⋯
[2018-07-21 23:58:42] Mingcong Bai >>> Why?
[2018-07-21 23:59:04] NeoTimesharingSystem >>> 五個選項方便算百分比
[2018-07-21 23:59:17] Mingcong Bai [Re: 1692] >>> 不便
[2018-07-21 23:59:24] Mingcong Bai >>> 因为需要从每个小组选出胜出代号
[2018-07-21 23:59:48] Staph. aureus | In your GI Tract >>> 目前小組中除了一組以外都有兩個差不太多票數的選項
[2018-07-22 00:00:03] Mingcong Bai >>> 行
[2018-07-22 00:00:07] Mingcong Bai >>> 那我取两个
[2018-07-22 00:01:06] gumblex >>> 刺激
[2018-07-22 00:01:10] Staph. aureus | In your GI Tract >>> 有一組還平票了⋯⋯
[2018-07-22 00:01:34] Lion [Re: 1697] >>> 娶两个还行
[2018-07-22 00:02:11] Zero King [Re: 1700] >>> 娶…
[2018-07-22 00:02:20] 死 肥 宅 鹹魚 [Re: 1700] >>> 左擁右抱
[2018-07-22 00:02:34] Staph. aureus | In your GI Tract >>> IRC 投票情況如何?
[2018-07-22 00:02:52] LAX VPS >>> 没特别的用户(
[2018-07-22 00:02:55] LAX VPS >>> 0
[2018-07-22 00:02:57] Zero King [Fwd: Mingcong Bai] >>> IRC 频道没有独特用户
[2018-07-22 00:02:57] Zero King [Fwd: Mingcong Bai] >>> 所以投票也没意义了
[2018-07-22 00:06:13] Mingcong Bai >>> 这 @catten 不会要赢两次壁纸了吧
[2018-07-22 00:06:21] Mingcong Bai >>> AOSC OS 历史上代号胜出最多的人
[2018-07-22 00:06:27] 白雾 纱织 >>> wwwww(
[2018-07-22 00:06:31] Catten Linger >>> (震茶杯.gif
[2018-07-22 00:06:33] 白雾 纱织 >>> 嘘(
[2018-07-22 00:06:37] 御坂0x4e21 看到她灌水一律赶她下线 >>> 为什么我投票之后没改,结果该选项居然变成0了?
[2018-07-22 00:06:46] Mingcong Bai [Re: 1713] >>> Huh?
[2018-07-22 00:06:48] 御坂0x4e21 看到她灌水一律赶她下线 >>> 于是又投了一次……
[2018-07-22 00:06:49] Mingcong Bai >>> 网络问题?
[2018-07-22 00:06:49] 死 肥 宅 鹹魚 [Re: 1713] >>> Bug?
[2018-07-22 00:06:55] 御坂0x4e21 看到她灌水一律赶她下线 >>> 不知道……
[2018-07-22 00:08:19] Staph. aureus | In your GI Tract >>> 變成了 Fib vs Fsck 的感覺⋯⋯
[2018-07-22 00:09:11] 迫真 正版 [Re: 1719] >>> hhhh
[2018-07-22 00:10:02] 死 肥 宅 鹹魚 >>> 乾脆投別的人也改投那倆麼算了(
[2018-07-22 00:10:16] Mingcong Bai >>> 如果战平的话
[2018-07-22 00:10:19] Mingcong Bai >>> 还有总决赛
[2018-07-22 00:10:28] Staph. aureus | In your GI Tract >>> 然後最後一刻重新洗牌(
[2018-07-22 00:10:35] Mingcong Bai [Re: 1724] >>> Expected (
[2018-07-22 00:10:35] 死 肥 宅 鹹魚 [Re: 1723] >>> 然後加時賽(
[2018-07-22 00:10:46] Mingcong Bai >>> AOSC FIFA
[2018-07-22 00:10:51] LAX VPS [Re: 1726] >>> 接着点球大战
[2018-07-22 00:10:53] LAX VPS >>> (
[2018-07-22 00:11:05] LAX VPS >>> 意大利对英格兰
[2018-07-22 00:11:12] LAX VPS >>> (smg。)
[2018-07-22 00:11:12] Zero King >>> 截至的时候平了(
[2018-07-22 00:11:26] OriginCode [Re: 1728] >>> 怎么点球。。。
[2018-07-22 00:11:28] Mingcong Bai [Re: 1732] >>> 那就单挑(
[2018-07-22 00:11:45] Mingcong Bai >>> 单挑平了的话请个人
[2018-07-22 00:11:51] 死 肥 宅 鹹魚 >>> FeelsGoodMan 真慘(
[2018-07-22 00:12:00] Mingcong Bai [Re: 1736] >>> FeelsMinorityMan
[2018-07-22 00:12:04] 死 肥 宅 鹹魚 >>> 剛剛還有一個人的(
[2018-07-22 00:12:06] LAX VPS >>> oh feelsnotgood
[2018-07-22 00:12:21] Mingcong Bai >>> 怎么群里 32 个人有 33 投票(
[2018-07-22 00:12:28] liushuyu >>> 啊, Fsck 要输了(
[2018-07-22 00:12:35] Zero King [Re: 1740] >>> Fwd?
[2018-07-22 00:12:46] Catten Linger [Re: 1740] >>> 怕是有鬼来投票
[2018-07-22 00:12:47] 死 肥 宅 鹹魚 [Re: 1740] >>> emmmm?
[2018-07-22 00:12:56] 死 肥 宅 鹹魚 [Re: 1742] >>> 投票不能 Fed 的
[2018-07-22 00:12:58] liushuyu >>> 35 票
[2018-07-22 00:13:17] Xiaoxing Ye >>> 灵异事件
[2018-07-22 00:13:28] Xiaoxing Ye >>> btw 这年头投票还要会鳄鱼(
[2018-07-22 00:13:30] Xiaoxing Ye >>> *俄语
[2018-07-22 00:13:43] Staph. aureus | In your GI Tract >>> Two Min 啦
[2018-07-22 00:13:45] Catten Linger >>> 要是输了就不用找通灵师请 Fibonacci 本人来作壁纸了(x
[2018-07-22 00:13:45] LAX VPS >>> tnl
[2018-07-22 00:13:47] Catten Linger >>> (安详
[2018-07-22 00:13:49] LAX VPS >>> 突然恶臭
[2018-07-22 00:13:58] 死 肥 宅 鹹魚 [Re: 1751] >>> hhhhhh
[2018-07-22 00:14:17] Mingcong Bai >>> 还有一分钟,要反悔赶紧了!
[2018-07-22 00:14:28] liushuyu >>> 34/33 票??
[2018-07-22 00:14:32] Lion >>> 1919191919
[2018-07-22 00:14:35] Lion >>> 一个一个一个
[2018-07-22 00:14:50] Lion >>> (绷紧)
[2018-07-22 00:14:57] Xiaoxing Ye >>> 紧张刺激的时刻!
[2018-07-22 00:15:21] AOSCC Relay bot >>> [YJSNPI] いいよ
[2018-07-22 00:15:52] Xiaoxing Ye >>> 恭喜 fsck!
[2018-07-22 00:15:52] Lion >>> 去了(指投票)
[2018-07-22 00:15:58] Catten Linger >>> 还行,省了一笔通灵费
[2018-07-22 00:16:06] Mingcong Bai >>> Fsck 是谁提的?
[2018-07-22 00:16:14] 死 肥 宅 鹹魚 [Re: 1765] >>> hhhh
[2018-07-22 00:16:16] 死 肥 宅 鹹魚 [Re: 1766] >>> 我
[2018-07-22 00:16:27] Xiaoxing Ye >>> Fibonacci 老先生:我还想出来聊聊天
[2018-07-22 00:16:34] Mingcong Bai [Re: 1768] >>> 破格送你一张贴纸
[2018-07-22 00:16:43] Catten Linger [Re: 1769] >>> 还请回吧(盖上棺材板
[2018-07-22 00:16:46] Mingcong Bai >>> [document]
[2018-07-22 00:16:46] 死 肥 宅 鹹魚 [Re: 1770] >>> 什麼鬼(
[2018-07-22 00:16:55] Mingcong Bai [Re: 1772] >>> 打印出来贴电脑吧(
[2018-07-22 00:17:04] Xiaoxing Ye [Re: 1771] >>> 啊……(余音
[2018-07-22 00:17:18] Catten Linger >>> 盖实.jpg
[2018-07-22 00:17:32] Sakamoto Tanmy >>> [document]
[2018-07-22 00:17:32] 死 肥 宅 鹹魚 [Re: 1772] >>> hhhhh
[2018-07-22 00:17:38] 死 肥 宅 鹹魚 >>> [document]
[2018-07-22 00:17:51] Zero King >>> No stickers?
[2018-07-22 00:17:51] 死 肥 宅 鹹魚 [Re: 1779] >>> 覺得應該貼這個
[2018-07-22 00:17:59] Mingcong Bai >>> Right stop.
[2018-07-22 00:18:02] Xiaoxing Ye [Re: 1774] >>> 感情送的是源文件啊
[2018-07-22 00:18:07] Catten Linger >>> 看看明年我是继续请魂还是其他风格 _(:з」∠)_
[2018-07-22 00:18:09] Mingcong Bai >>> 转群吧
[2018-07-22 00:18:14] Mingcong Bai >>> 各位早上九点半见
[2018-07-22 00:18:27] Zero King [Re: 1772] >>> Delete this.
[2018-07-22 00:18:41] Mingcong Bai [Re: 1787] >>> Yeppers.
[2018-07-22 00:19:01] Mingcong Bai >>> ————— 群组封闭至北京时间 9:30 —————
[2018-07-22 00:41:48] 死 肥 宅 鹹魚 >>> 忘了我這邊路由 12:00 重啟 🤦‍♀️
[2018-07-22 09:18:31] Mingcong Bai >>> 各位早上好,欢迎来到 AOSCC 2018 Day 2!
早上的两个讨论话题主要围绕 AOSC OS 的发行方式、日程和自动化:
— 9:30 - 10:30,关于 AOSC OS 未来系统发行方式的讨论(本人主持)
— 11:00 - 12:00,AOSC OS 系统发行自动化及持续集成 (CI) (@liushuyu 主持)
晚上的日程如下:
— 21:00 - 22:00,AOSC OS 各源码树实现数据校验和 (Checksum) 及响应工作流调整(@Lionium 主持)
— 22:30 - 11:30,关于 AOSC OS 转入季度更新、分支调整及里程碑集成的二次讨论(本人主持)
[2018-07-22 09:30:00] Mingcong Bai >>> #TOPIC 9:30 - 10:30 — 关于 AOSC OS 未来系统发行方式和计划的讨论
[2018-07-22 09:30:04] Mingcong Bai [Re: 1792] >>> pinned the message
[2018-07-22 09:30:17] Mingcong Bai >>> Hmm 现在有多少人活着?
[2018-07-22 09:30:22] Zero King >>> +1
[2018-07-22 09:30:29] 死 肥 宅 鹹魚 >>> 活着
[2018-07-22 09:30:34] 冰淇琳 >>> 还没死
[2018-07-22 09:30:41] liushuyu >>> 存活
[2018-07-22 09:30:44] Mingcong Bai >>> Right.
[2018-07-22 09:30:56] Mingcong Bai >>> 我像昨天一样发一大段然后顺着讨论可以吗?
[2018-07-22 09:31:33] liushuyu [Re: 1800] >>> 没意见
[2018-07-22 09:31:48] 死 肥 宅 鹹魚 [Fwd: liushuyu] >>> 没意见
[2018-07-22 09:32:26] Mingcong Bai >>> Right 不多浪费时间了,下面这段描述了当前的问题和一些变化,然后有一个点子,下面有数个问题
[2018-07-22 09:32:45] Mingcong Bai >>> 各位注意到什么需要讨论的就直接说吧
[2018-07-22 09:32:47] Mingcong Bai >>> AOSC OS 现行的发行方法有这两种:
— Tarball,系统根打包,直接解包后手动配置
— Raw Image,用于 ARMv7 和 AArch64 设备,直接写入 SD/MMC 介质
那么很明显,现状有这些不理想的地方:
— 没有 Live 介质,无论是安装还是系统维护都要借助其他发行版;发行版安装虽有文档却也不甚便利
— 没有固定的发行日程,今年只更新过一次,加之系统更新量之多,安装和配置运行都不很方便,甚至会出现不可更新的情况
这个问题其实从 2016 年的 AOSCC 就讨论过,一直说要有 Live 要有频繁更新,但是我们没有很好地去落实计划。尤其一些维护不足的特定设备比如 Raspberry Pi 更是被完全忽略了(大约一年半)。但是好消息是现在有了 CIEL! 协助自动且可复现地生成 Tarball 和其他发行介质(比如 Live,毕竟只是个脚本),剩下的工作基本是写一个“菜谱”或 recipe 了。
此外还有一个已经提出许久的问题,希望在此重新讨论:
— 为至少 AMD64 用户提供一个运行于内存中的小型系统用于维护和修复系统(类似 GParted 还是应该更小一些且只提供 CLI?)。
那么,剩下要讨论的问题还有这些:
— 频率?发行频率应该如何计划,跟随季度/每月/每周(包含周期内安全更新)?
— 安装程序还是手动操作?安装程序应该做到什么程度,向导还是脚本?
[2018-07-22 09:33:57] liushuyu >>> 反正 AOSC 确实需要有足够的设备持续测试 device-specific 镜像
[2018-07-22 09:34:13] liushuyu >>> 安装程序我觉得最好要新手友好
[2018-07-22 09:34:30] liushuyu >>> 因为非新手知道怎么做(
[2018-07-22 09:34:49] 死 肥 宅 鹹魚 >>> 有了 Live 總還保留 tarball 的吧?
[2018-07-22 09:35:11] Mingcong Bai [Re: 1809] >>> 我的想法是提供一个单一的 Live 安装环境
[2018-07-22 09:35:17] Mingcong Bai >>> 剩余的版本一律还是 tarball
[2018-07-22 09:35:24] Mingcong Bai >>> Live 用于提供安装和配置
[2018-07-22 09:35:54] liushuyu [Re: 1810] >>> 我觉得可以
[2018-07-22 09:35:56] Mingcong Bai >>> 也就是说更类似 Debian Installer,只是更加 ${INSERT_USER_FRIENDLY_TRAITS}
[2018-07-22 09:36:13] 死 肥 宅 鹹魚 >>> 主要是感覺很多時候做了安裝器就不夠靈活了,所以最好還是能保留 tarball...
[2018-07-22 09:36:32] liushuyu [Re: 1814] >>> ""
[2018-07-22 09:36:32] Mingcong Bai >>> 嗯是的,因为对于我们这里现有用户来说 tarball 是个更方便的安装方法
[2018-07-22 09:36:39] Mingcong Bai [Re: 1816] >>> Harsh.
[2018-07-22 09:36:41] Mingcong Bai >>> (
[2018-07-22 09:36:58] Mingcong Bai >>> 安装程序的话我希望引出一个老概念
[2018-07-22 09:37:03] Mingcong Bai >>> 我大概描述一下
[2018-07-22 09:37:08] Mingcong Bai >>> @liushuyu 应该知道这个的
[2018-07-22 09:37:09] liushuyu [Re: 1820] >>> Cliinst 么(
[2018-07-22 09:37:15] Mingcong Bai >>> 不是
[2018-07-22 09:37:28] liushuyu >>> 还是某 Qt 的安装器
[2018-07-22 09:37:36] Mingcong Bai >>> 类似美式三明治 Which Wich 的点菜单
[2018-07-22 09:37:38] Mingcong Bai >>> 稍等
[2018-07-22 09:37:42] NeoTimesharingSystem >>> 應該要像 Arch Linux
[2018-07-22 09:37:44] Mingcong Bai >>> 我发张图来
[2018-07-22 09:37:47] NeoTimesharingSystem >>> CLI 手動
[2018-07-22 09:38:09] liushuyu [Re: 1830] >>> 有,tarball 安装是 cli 手动
[2018-07-22 09:38:24] liushuyu >>> 这里现在在想如何引导新手
[2018-07-22 09:38:30] NeoTimesharingSystem >>> 其實 Live 系統可以只用一個 Initramfs,然後安裝靠網路
[2018-07-22 09:38:42] Mingcong Bai >>> [photo]
[2018-07-22 09:39:00] Mingcong Bai [Re: 1834] >>> 转译到我们的用途来说,大概如下
[2018-07-22 09:39:40] liushuyu [Re: 1834] >>> 噢,这挺科学的
[2018-07-22 09:40:50] Mingcong Bai >>> 1. 你想要什么 Flavour/Variant(Base/KDE/GNOME/...)?
2. 你要安装到哪里?
3. 源和网络设置
4. 你是否要打开 Overlay?
5. 你还要附加什么(NVIDIA Proprietary/optenv32/devel-base/...)?
6. 你不想要什么?
[2018-07-22 09:41:11] Mingcong Bai >>> 一个单页滚动的 UI,各个选项有简短介绍
[2018-07-22 09:41:19] Mingcong Bai >>> 选好后一个 Go 按钮就可以完成安装
[2018-07-22 09:41:28] liushuyu [Re: 1838] >>> 做成 GUI 还是 TUI
[2018-07-22 09:41:39] Mingcong Bai [Re: 1840] >>> 我建议做个流程库而后适配前端
[2018-07-22 09:42:20] Mingcong Bai >>> @Neo_Chen Arch 的安装方式可能很难套用到我们的现状上,因为我们是属于预先配置的系统,不过可以根据上面流程作如下更改达到类似效果
[2018-07-22 09:42:50] Sakamoto Tanmy [Re: 1812] >>> netinstaller
[2018-07-22 09:43:38] Mingcong Bai [Re: 1837] >>> 1-Alt. “我要自己组装”!
2. 你要安装到哪里?
3. 源和网络设置
4. 你是否要打开 Overlay/Testing/Chimera(暂定)?
5. 你想要什么 base,或提供一个包列表(旁边给一个终端按钮?)
[2018-07-22 09:43:56] 迫真 正版 >>> 能debootstrap吗(
[2018-07-22 09:44:21] Mingcong Bai [Re: 1845] >>> 需要实现
[2018-07-22 09:44:32] liushuyu [Re: 1844] >>> 所以需要网络?
[2018-07-22 09:44:45] Mingcong Bai [Re: 1844] >>> 走这个流程的话,安装程序会下载个 stub 然后根据要求组装
[2018-07-22 09:45:03] Mingcong Bai [Re: 1847] >>> 是的,不过我们的发行版网络连接大多情况下是不成问题的
[2018-07-22 09:45:12] Mingcong Bai >>> Firmware 和内核支持都是包括完全的
[2018-07-22 09:45:49] Mingcong Bai >>> 再者安装程序也需要提供镜像选择,应该总有一个可用的……
[2018-07-22 09:46:40] Mingcong Bai >>> @liushuyu 如何?
[2018-07-22 09:47:03] liushuyu >>> BCM(
[2018-07-22 09:47:28] 死 肥 宅 鹹魚 >>> BCM
[2018-07-22 09:47:32] liushuyu >>> 自带 b43 固件么
[2018-07-22 09:47:38] Mingcong Bai >>> b43 会有一部分
[2018-07-22 09:47:47] Mingcong Bai >>> 但是 BCM 真的属于我们解决不了的问题
[2018-07-22 09:47:53] Mingcong Bai >>> 除非安装程序加上本地内容探测
[2018-07-22 09:48:03] Mingcong Bai >>> 然后允许安装个特定版本的 tarball
[2018-07-22 09:48:05] Mingcong Bai >>> 之类的
[2018-07-22 09:49:19] 死 肥 宅 鹹魚 >>> 話說打出來的 Live 是自帶安裝所需要的所有文件還是需要再下載
[2018-07-22 09:49:29] 迫真 正版 >>> bcm一般手动选吧,虽然我不知道Ubuntu怎么就能不需要介入
[2018-07-22 09:49:36] Mingcong Bai [Re: 1861] >>> 我的想法的话,默认不带任何本地内容
[2018-07-22 09:49:40] NeoTimesharingSystem [Re: 1861] >>> 應該用下載的
[2018-07-22 09:49:41] Mingcong Bai >>> 也就是说有个安装和配置环境
[2018-07-22 09:49:52] Mingcong Bai >>> 至于具体内容是什么,这个我暂时没有想法
[2018-07-22 09:49:58] NeoTimesharingSystem >>> 不然就分版本,Netinstall 和 Full
[2018-07-22 09:50:02] 死 肥 宅 鹹魚 [Re: 1863] >>> 那 BCM(
[2018-07-22 09:50:10] 迫真 正版 >>> netinstall和live
[2018-07-22 09:50:14] Mingcong Bai [Re: 1867] >>> 我们的 Full 很可能就要超过 10GB 了…… 假设需要提供所有的内容
[2018-07-22 09:50:19] 迫真 正版 [Re: 1868] >>> 一般live没驱动才正常
[2018-07-22 09:50:26] NeoTimesharingSystem [Re: 1870] >>> 學 Slackware
[2018-07-22 09:50:29] Zamir SUN [Re: 1865] >>> 所以本质是个网络安装介质了
[2018-07-22 09:50:32] Mingcong Bai [Re: 1872] >>> 能描述一下吗
[2018-07-22 09:50:42] 迫真 正版 >>> 然后安装时识别到了bcm给你下载blob
[2018-07-22 09:50:47] Mingcong Bai [Re: 1873] >>> 是的,纯粹是多了个“点菜单”类似的安装程序
[2018-07-22 09:51:03] NeoTimesharingSystem [Re: 1874] >>> 只有附帶常用的
[2018-07-22 09:51:06] 死 肥 宅 鹹魚 [Re: 1875] >>> 沒有網絡,怎麼下載 blob(
[2018-07-22 09:51:12] Zamir SUN [Re: 1870] >>> 要有选择性。 Fedora 整个源也巨大。但是安装盘不大
[2018-07-22 09:51:15] NeoTimesharingSystem [Re: 1878] >>> Zmodem
[2018-07-22 09:51:20] Mingcong Bai [Re: 1875] >>> 这个可以做,但是不能默认点选
[2018-07-22 09:51:35] 迫真 正版 [Re: 1878] >>> wiki里推荐ath9kUSB无线网卡(x
[2018-07-22 09:51:43] Mingcong Bai [Re: 1879] >>> 我再重新解释一下……
[2018-07-22 09:51:48] NeoTimesharingSystem >>> 怎麼不 Realtek 8187?
[2018-07-22 09:52:06] Mingcong Bai >>> 比如,用户可以下载一个 Live 安装环境,然后根据文档把系统 tarball 放到比如 /tarballs 目录
[2018-07-22 09:52:09] Zamir SUN [Re: 1883] >>> 我看到你说不带本地内容了
[2018-07-22 09:52:14] 迫真 正版 >>> 我以前在Mac上装Debian就问旁边的人要了个tplink的无线网卡
[2018-07-22 09:52:27] 死 肥 宅 鹹魚 [Re: 1882] >>> 233(但是好像 USB 只有 ath9k_htc 吧,那個似乎也要 blob
[2018-07-22 09:52:42] Mingcong Bai >>> 安装程序能探测到里面的 tarball,然后在没有任何网络连接的时候,只允许用户选择安装那个 tarball 对应的系统
[2018-07-22 09:52:48] NeoTimesharingSystem [Re: 1885] >>> 這個 /tarball 在 tmpfs?
[2018-07-22 09:52:53] Mingcong Bai [Fwd: Mingcong Bai] >>> 除非安装程序加上本地内容探测
[2018-07-22 09:52:53] Mingcong Bai [Fwd: Mingcong Bai] >>> 然后允许安装个特定版本的 tarball
[2018-07-22 09:52:53] Mingcong Bai [Fwd: Mingcong Bai] >>> 之类的
[2018-07-22 09:52:58] Mingcong Bai [Re: 1893] >>> @zamirsun
[2018-07-22 09:53:06] NeoTimesharingSystem >>> cat /proc/cpuinfo
[2018-07-22 09:53:16] Mingcong Bai [Re: 1890] >>> 不,在这个介质的 .iso/.zip 里面
[2018-07-22 09:53:36] Mingcong Bai >>> 相当于用户手动 cache 一个安装内容
[2018-07-22 09:53:44] NeoTimesharingSystem >>> 這樣估計 Medium 有多大?
[2018-07-22 09:53:53] NeoTimesharingSystem >>> 2 GiB?
[2018-07-22 09:54:03] Mingcong Bai [Re: 1898] >>> 我猜测 Live 环境在 300-500MiB,而 tarball 大概 1.5-2GiB
[2018-07-22 09:54:09] Mingcong Bai >>> 嗯所以你的猜测比较准确了
[2018-07-22 09:54:23] NeoTimesharingSystem >>> 另外,tarball 的壓縮方式要用 xz 嗎?
[2018-07-22 09:54:34] Mingcong Bai [Re: 1902] >>> 现有的 tarball 就是 xz
[2018-07-22 09:54:41] Mingcong Bai >>> 不过你给了我一个点子
[2018-07-22 09:54:42] 迫真 正版 >>> 650M还能离线安装的live是怎么做的
[2018-07-22 09:55:00] Mingcong Bai >>> 用户自己打包现有的系统,然后放到 /tarballs 里面,安装程序允许用户选择自定义 tarball
[2018-07-22 09:55:08] NeoTimesharingSystem [Re: 1905] >>> 只有附基本系統就可以
[2018-07-22 09:55:17] Mingcong Bai >>> 这样也就重新部署了一下自己的系统,当然,由于具体配置,出现问题用户后果自负
[2018-07-22 09:56:00] NeoTimesharingSystem >>> 所以有 Custom ISO 的工具?
[2018-07-22 09:56:09] Mingcong Bai [Re: 1909] >>> 不
[2018-07-22 09:56:11] Mingcong Bai >>> 我举个例子
[2018-07-22 09:56:18] liushuyu >>> 不同卡的适用固件不一样的嘛
[2018-07-22 09:56:20] NeoTimesharingSystem >>> 直接 mkisofs?
[2018-07-22 09:56:23] Mingcong Bai >>> 我在机器 A 上有一份 AOSC OS
[2018-07-22 09:56:55] Mingcong Bai >>> 我在 9 月 1 日备份了这份系统(通过一开始提到的点子,那个内存中运行的维护环境),通过工具/手动打成 tarball
[2018-07-22 09:57:10] Mingcong Bai >>> 然后 10 月 1 日机器 A 上 AOSC OS 滚挂了或者自己搞坏了
[2018-07-22 09:57:15] Mingcong Bai >>> 那么用户可以下载一份 Live
[2018-07-22 09:57:16] 迫真 正版 >>> 出AOSC版ghost算了(小声
[2018-07-22 09:57:27] Mingcong Bai >>> 在 /tarballs 里面放个自己备份的 tarball
[2018-07-22 09:57:30] NeoTimesharingSystem [Re: 1918] >>> GHOST 不支援 EXT4 吧?
[2018-07-22 09:57:37] Mingcong Bai >>> 然后安装程序时选择一个自定义 tarball
[2018-07-22 09:57:44] Mingcong Bai >>> 安装后即相当于恢复了自己的系统
[2018-07-22 09:57:50] 迫真 正版 [Re: 1920] >>> 做个基于AOSC的AOSC Emergency
[2018-07-22 09:57:50] Mingcong Bai >>> 自己备份的系统 *
[2018-07-22 09:58:00] Mingcong Bai >>> 不知道这个思路是否可行?
[2018-07-22 09:58:03] 迫真 正版 >>> 不是真的拿ghost来用(
[2018-07-22 09:58:06] Mingcong Bai >>> 我觉得在一定情况下应该是可以用的
[2018-07-22 09:58:25] NeoTimesharingSystem [Re: 1919] >>> 既然 /tarballs 是位於 squashfs,那加入內容就要重新打包啊
[2018-07-22 09:58:31] Mingcong Bai [Re: 1928] >>> 不啊
[2018-07-22 09:58:46] Mingcong Bai >>> 我完全可以把 Live 介质挂载到另外一个点上
[2018-07-22 09:59:05] Mingcong Bai >>> 你可以参考下 GParted Live,它会把启动介质挂载到 /lib/live/medium
[2018-07-22 09:59:13] Mingcong Bai >>> 然后 squashfs 挂载到 /lib/live/rootfs
[2018-07-22 09:59:22] Mingcong Bai >>> (或者类似的路径,记不清
[2018-07-22 09:59:29] NeoTimesharingSystem >>> 用 9p 檔案系統分發 tarball 呢?
[2018-07-22 09:59:33] 迫真 正版 >>> 总之你在live里是能查看你的U盘的
[2018-07-22 09:59:41] Mingcong Bai [Re: 1934] >>> 能描述一下吗
[2018-07-22 09:59:58] NeoTimesharingSystem [Re: 1936] >>> 分散式檔案系統
[2018-07-22 10:00:08] Mingcong Bai >>> 这我知道,但是这是什么概念……
[2018-07-22 10:00:28] Mingcong Bai >>> 在这个应用场景下
[2018-07-22 10:00:31] NeoTimesharingSystem [Re: 1938] >>> 直接方便的選擇檔案
[2018-07-22 10:00:46] NeoTimesharingSystem >>> ls 一下就好
[2018-07-22 10:00:52] 迫真 正版 >>> plan 9 filesystem protocol
[2018-07-22 10:01:00] Mingcong Bai >>> 这个和放置多个 tarball 有什么区别呢?
[2018-07-22 10:01:08] NeoTimesharingSystem [Re: 1943] >>> 省空間
[2018-07-22 10:01:25] Mingcong Bai >>> 抱歉我实在不知道 9p 文件系统是怎么存放文件的……
[2018-07-22 10:01:40] NeoTimesharingSystem >>> 前提是網路並非 Dial Up 連線
[2018-07-22 10:01:51] NeoTimesharingSystem [Re: 1945] >>> 有個 File Server
[2018-07-22 10:02:06] 迫真 正版 >>> 我觉得在做出live雏形前先不考虑吧(小声
[2018-07-22 10:02:08] NeoTimesharingSystem >>> 所以也沒多分散式
[2018-07-22 10:02:21] Mingcong Bai >>> 在这个情况下感觉和一般文件没什么区别了……
[2018-07-22 10:02:34] NeoTimesharingSystem >>> 好吧
[2018-07-22 10:02:46] Mingcong Bai >>> 我稍微整理下刚刚我们提到/讨论过的问题
[2018-07-22 10:04:41] gumblex [Re: 1863] >>> 我觉得带个 base
[2018-07-22 10:05:36] NeoTimesharingSystem >>> 這樣吧: Live Medium 自帶 Base System 安裝,要 DE 的在安裝時選擇下載
[2018-07-22 10:06:21] Mingcong Bai >>> — Live 环境提供一个基本环境(类似 GParted,但是具体包含什么组件尚不确定),里面默认不包含任何的系统 tarball。
— 安装程序类似 Which Wich 的点菜单,单页滚动 UI,让用户选择各个安装选项(https://3.bp.blogspot.com/-Xv3kq_UsZX0/WPZ4wQtECDI/AAAAAAAADUY/MGEnX3QN84Qmyz4ho3OzP7fR252JCsSbACEw/s1600/Which%2BWich%2BEnvelope.jpg)。
一般模式:
1. 你想要什么 Flavour/Variant(Base/KDE/GNOME/...)?
2. 你要安装到哪里?
3. 源和网络设置
4. 你是否要打开 Overlay/Testing/Chimera(暂定)?
5. 你还要附加什么(NVIDIA Proprietary/optenv32/devel-base/...)?
6. 你不想要什么?
专家(?)模式:
1-Alt. “我要自己组装”!
2. 你要安装到哪里?
3. 源和网络设置
4. 你是否要打开 Overlay/Testing/Chimera(暂定)?
5. 你想要什么 base,或提供一个包列表(旁边给一个终端按钮?)
— 安装程序支持探测本地内容,假设 /tarballs 里面放 tarball,自动探测其版本(对应 checksum);也可以支持自定义 tarball(提供选项)
— 额外思考,配合当前已安装的 AOSC OS 附带的一个内存中运行的基本维护环境,可以用于备份当前系统。而备份后的系统也可以放到 /tarballs 里面,安装程序即可成为个系统恢复工具 [webpage]
[2018-07-22 10:06:35] Mingcong Bai [Re: 1954] >>> 不是个坏主意,这样用户无论如何都能安装出点东西来
[2018-07-22 10:07:02] NeoTimesharingSystem [Re: 1956] >>> 同時也可以縮小 Live Medium
[2018-07-22 10:07:13] Mingcong Bai [Re: 1957] >>> 缩小?这是额外附带的数据诶
[2018-07-22 10:07:28] gumblex [Re: 1947] >>> 那协议慢的要死根本不能跨网络用
[2018-07-22 10:07:46] NeoTimesharingSystem [Re: 1958] >>> 額外資料也會佔光碟空間啊
[2018-07-22 10:08:06] NeoTimesharingSystem [Re: 1959] >>> 好吧
[2018-07-22 10:08:10] Mingcong Bai >>> Live:
- Live 环境标准内容(内核、内存盘、squashfs)
- /tarballs 或其他本地内容
[2018-07-22 10:08:32] Mingcong Bai [Re: 1962] >>> 那么我们如果需要带个 Base,那么 Base tarball 会在 /tarballs 里面提供给安装程序探测
[2018-07-22 10:08:36] NeoTimesharingSystem >>> Ramdisk 是 tmpfs?
[2018-07-22 10:08:42] gumblex [Re: 1961] >>> 比 ftp 还废话
[2018-07-22 10:08:43] Mingcong Bai [Re: 1964] >>> initrd
[2018-07-22 10:09:27] Mingcong Bai >>> Live 和最终安装出来的系统没有关系(需要切除文件,所以不是个标准 AOSC OS)
[2018-07-22 10:09:28] liushuyu [Re: 1955] >>> 新手 和 专家
[2018-07-22 10:09:36] NeoTimesharingSystem >>> initrd 其實是 ramfs 吧
[2018-07-22 10:09:39] Mingcong Bai [Re: 1968] >>> Arch Linux 模式(雾
[2018-07-22 10:09:43] Mingcong Bai [Re: 1969] >>> 是的
[2018-07-22 10:09:53] NeoTimesharingSystem [Re: 1970] >>> 不如 Gentoo 模式
[2018-07-22 10:09:56] Mingcong Bai >>> 关于 Live 我还是希望给用户提供一个基本的 X 环境
[2018-07-22 10:10:08] Mingcong Bai >>> 不知道各位怎么想这事儿
[2018-07-22 10:10:11] NeoTimesharingSystem [Re: 1973] >>> Xterm + TWM 就好
[2018-07-22 10:10:13] 冰淇琳 [Re: 1805] >>> 另外 Septs 曾经提到过
[2018-07-22 10:10:13] 冰淇琳 >>> 为 AMD64 提供 raw image
[2018-07-22 10:10:32] liushuyu [Re: 1973] >>> 什么 DE 呢
[2018-07-22 10:10:32] liushuyu >>> 总不能用 i3 吧
[2018-07-22 10:10:33] 迫真 正版 [Re: 1975] >>> 不符合AOSC目标定位,虽然现在的安装方式很硬核
[2018-07-22 10:10:38] Mingcong Bai [Re: 1978] >>> Why DE?
[2018-07-22 10:10:41] gumblex [Re: 1963] >>> 能不能像 Debian 一样实际上实现一个本地源
[2018-07-22 10:10:51] Mingcong Bai [Re: 1982] >>> 这个我提到了,本地内容探测
[2018-07-22 10:10:56] NeoTimesharingSystem [Re: 1977] >>> Raw Image 就不能改 File System 了
[2018-07-22 10:11:00] Mingcong Bai >>> 具体规范我觉得我们今天没时间也没必要…… 决定
[2018-07-22 10:11:03] gumblex [Re: 1983] >>> 不是
[2018-07-22 10:11:07] Mingcong Bai [Re: 1986] >>> 嗯?
[2018-07-22 10:11:14] 迫真 正版 [Re: 1984] >>> 目标是允许直接dd启动
[2018-07-22 10:11:27] gumblex >>> Debian 的做法不是存一堆 deb 包按需现场安装吗
[2018-07-22 10:11:39] Mingcong Bai [Re: 1989] >>> 对,你看看上面安装流程的“附加组件”问题
[2018-07-22 10:11:45] 冰淇琳 [Re: 1984] >>> 嗯
[2018-07-22 10:11:50] 冰淇琳 >>> 那就 e4 咯
[2018-07-22 10:11:56] NeoTimesharingSystem [Re: 1988] >>> 還有個問題: Backup MBR 不會出現在 Last Sector
[2018-07-22 10:11:56] Mingcong Bai >>> 我们没有必要从一个一个 deb 安装,可以用一个 tarball 作为基础
[2018-07-22 10:12:08] 冰淇琳 >>> 反正 raw image 的 target 用户应该也不会考虑乱换文件系统
[2018-07-22 10:12:16] liushuyu [Re: 1994] >>> 放个 base 好了
[2018-07-22 10:12:24] Mingcong Bai [Re: 1996] >>> Live 至少带个 Base
[2018-07-22 10:12:36] liushuyu [Re: 1995] >>> 也不好换(
[2018-07-22 10:12:38] 迫真 正版 [Re: 1993] >>> 不假设用户在装完前乱搞文件系统
[2018-07-22 10:12:38] Mingcong Bai >>> 但是如果用户想要本地存 KDE
[2018-07-22 10:12:40] NeoTimesharingSystem >>> 一個 base tarball 然後再裝 DE,完美
[2018-07-22 10:12:42] gumblex [Re: 1994] >>> 我意思是 tarball 里有重复的,比如 gnome 里已经有 base 了
[2018-07-22 10:12:43] Mingcong Bai >>> 那么就自己动
[2018-07-22 10:13:07] Mingcong Bai [Re: 2002] >>> 我不是很希望复杂化这个内容
[2018-07-22 10:13:09] NeoTimesharingSystem [Re: 2002] >>> 做 overlay Tarball
[2018-07-22 10:13:12] Mingcong Bai >>> 用户放什么 tarball 就安装什么
[2018-07-22 10:13:31] NeoTimesharingSystem >>> 或 post-install chroot
[2018-07-22 10:13:34] gumblex [Re: 2002] >>> 搞个 diff (
[2018-07-22 10:13:42] Mingcong Bai [Re: 2005] >>> 额外要生成数据,我们的源空间有限……
[2018-07-22 10:13:55] Mingcong Bai [Re: 2008] >>> 这个的话 Patch 太慢了……
[2018-07-22 10:14:12] liushuyu [Re: 2008] >>> vcdiff 么(
[2018-07-22 10:14:15] Mingcong Bai >>> 感觉让用户放个 tarball 进目录应该不算很难?
[2018-07-22 10:14:24] liushuyu >>> 太烧 CPU 了
[2018-07-22 10:14:24] gumblex [Re: 2011] >>> tarball diff (
[2018-07-22 10:14:43] NeoTimesharingSystem [Re: 2009] >>> 一個 Base Tarball 然後 Overlayfs 裝東西,最後打包 Overlayfs 的內容?
[2018-07-22 10:15:03] liushuyu [Re: 2012] >>> 可以让用户选择然后程序下载
[2018-07-22 10:15:11] Mingcong Bai [Re: 2015] >>> OverlayFS 不是我们的安装方式……
[2018-07-22 10:15:18] Mingcong Bai [Re: 2016] >>> 好吧我再整理一次……
[2018-07-22 10:15:37] NeoTimesharingSystem >>> curl 某 CGI 獲得 Tarball List?
[2018-07-22 10:15:52] Mingcong Bai >>> — 默认情况下带个 Base,但是安装程序会让用户选择版本
— 如果用户在 /tarballs 里面放个 GNOME tarball,安装程序可以探测到 GNOME tarball,直接通过那个来安装
[2018-07-22 10:16:06] Mingcong Bai >>> 或者,用户可以直接选择 GNOME,在有网络的情况下,下载 GNOME tarball 直接安装
[2018-07-22 10:16:19] Mingcong Bai >>> 因为安装 deb 的时间代价是很大的,相对直接解压 tarball
[2018-07-22 10:16:21] gumblex >>> 就是像 Debian 一样,先解压 base tarball 再一个个按 ciel 的 recipe 安装 deb?
[2018-07-22 10:16:25] Mingcong Bai [Re: 2019] >>> Checksum
[2018-07-22 10:16:35] Mingcong Bai [Re: 2023] >>> 是个不错的选择,不过
[2018-07-22 10:16:39] Mingcong Bai [Re: 2022] >>> @gumblex ^
[2018-07-22 10:16:59] NeoTimesharingSystem >>> 剛剛提到用 Checksum 檢查 Tarball,可是當新的 Tarball Release 呢?
[2018-07-22 10:17:08] Mingcong Bai [Re: 2027] >>> ?
[2018-07-22 10:17:32] Mingcong Bai >>> Live 里面可以带个当前 tarball checksum 列表(用户也可以编辑
[2018-07-22 10:17:39] Mingcong Bai >>> 自带的 Base 当然也有 checksum
[2018-07-22 10:17:49] gumblex [Re: 2029] >>> gpg?
[2018-07-22 10:17:51] Mingcong Bai >>> 如果有网络的话,可以同步一个列表
[2018-07-22 10:18:00] gumblex >>> 就放个 master key
[2018-07-22 10:18:00] Mingcong Bai [Re: 2031] >>> 嗯总之不是文件名和大小就行……
[2018-07-22 10:18:10] NeoTimesharingSystem >>> 直接顯示檔案名稱就好吧?
[2018-07-22 10:18:26] Mingcong Bai [Re: 2035] >>> 我有点不太理解你具体在指什么
[2018-07-22 10:18:34] NeoTimesharingSystem [Re: 2036] >>> Tarball 的
[2018-07-22 10:18:37] gumblex [Re: 2034] >>> 得有吧,快速检查
[2018-07-22 10:18:49] Mingcong Bai [Re: 2038] >>> 但是不能作为最终标准
[2018-07-22 10:19:04] Mingcong Bai [Re: 2037] >>> 在哪里显示,用途是什么……
[2018-07-22 10:19:15] NeoTimesharingSystem [Re: 2040] >>> 安裝用的
[2018-07-22 10:19:25] Mingcong Bai [Re: 2041] >>> 纯粹 UI 来说,可以
[2018-07-22 10:19:34] Mingcong Bai >>> 但是安装程序确实应该进行额外完整性检查
[2018-07-22 10:19:38] Mingcong Bai >>> 以及 @gumblex 提到的签名检查
[2018-07-22 10:19:43] Mingcong Bai >>> 不是个坏主意
[2018-07-22 10:20:17] Staph. aureus | In your GI Tract >>> 要 Futureproof 只能上簽名檢查吧⋯⋯?
[2018-07-22 10:20:25] NeoTimesharingSystem >>> 其實要達到安全的話,要同時使用兩個 Checksum 演算法
[2018-07-22 10:20:27] Mingcong Bai [Re: 2023] >>> 所以我基于上面那个理由我还是希望直接提供 tarball 而不是走 recipe,纯粹从安装时间考虑
[2018-07-22 10:20:33] Mingcong Bai [Re: 2046] >>> 是的
[2018-07-22 10:20:35] Mingcong Bai [Re: 2047] >>> 嗯
[2018-07-22 10:20:47] Staph. aureus | In your GI Tract >>> 然後線上下載 Checksum 然後再完整性檢查
[2018-07-22 10:21:05] Mingcong Bai [Re: 2051] >>> 嗯,无论本地还是额外下载都要检查
[2018-07-22 10:21:08] NeoTimesharingSystem >>> 同時碰撞出兩種 Checksum 演算法太難了
[2018-07-22 10:21:16] gumblex >>> 【选择安装镜像】
1. ...-gnome-20180514
2. ...-kde-20180514
3. ...-custom-20180123
↺正在获取最新镜像列表…
[2018-07-22 10:21:26] Mingcong Bai >>> @gumblex deb 安装可以用于后面安装额外组件,比如 NVIDIA,optenv32
[2018-07-22 10:21:34] NeoTimesharingSystem >>> contrib?
[2018-07-22 10:21:35] Mingcong Bai [Re: 2054] >>> 嗯,大概这么一回事
[2018-07-22 10:21:43] Mingcong Bai >>> 然后找到的本地内容也会显示出来
[2018-07-22 10:22:02] Mingcong Bai [Re: 2056] >>> 本地系统也带了,只是有的组件实在不能让我们作为一个系统默认包含……
[2018-07-22 10:22:18] NeoTimesharingSystem [Re: 2059] >>> 例如?
[2018-07-22 10:22:23] Mingcong Bai [Re: 2060] >>> 固件
[2018-07-22 10:22:36] Mingcong Bai >>> 还有一些解码器(虽然是开源/自由软件,但是某些地区限制使用
[2018-07-22 10:22:44] gumblex [Re: 2054] >>> 这里就是自带一份列表,一个 master key,先显示列表,同时下载新的列表
[2018-07-22 10:22:52] NeoTimesharingSystem >>> 出口限制?
[2018-07-22 10:23:02] Mingcong Bai [Re: 2064] >>> 嗯,比如美国不能用的 libdvdcss
[2018-07-22 10:23:12] Mingcong Bai >>> (我们纯粹仗着没有定义国籍
[2018-07-22 10:23:48] NeoTimesharingSystem >>> DVD 的 CSS 被破解都是 199x 的事情了
[2018-07-22 10:23:50] Mingcong Bai >>> @liushuyu 假设我们只提供 WM
[2018-07-22 10:23:59] Mingcong Bai >>> 那么我们可以考虑做个 Ncurses 就好
[2018-07-22 10:24:18] Mingcong Bai >>> Live 还额外带个 NM 图形界面,还有 GParted 一类基本的助手工具
[2018-07-22 10:24:19] NeoTimesharingSystem >>> 用 dialog(1) 做?
[2018-07-22 10:24:22] Junde Yhi >>> 这么硬核
[2018-07-22 10:24:23] liushuyu [Re: 2069] >>> curses 不用 X 都好(
[2018-07-22 10:24:27] liushuyu [Re: 2070] >>> 哦
[2018-07-22 10:24:30] Mingcong Bai [Re: 2071] >>> Dialog 实在太廉价了
[2018-07-22 10:24:35] liushuyu >>> 这样就要 X 了
[2018-07-22 10:24:37] NeoTimesharingSystem >>> termcap 呢?
[2018-07-22 10:24:51] 死 肥 宅 鹹魚 [Re: 2075] >>> 大佬,你的安裝盤寫錯了啦
[2018-07-22 10:24:55] Mingcong Bai [Re: 2077] >>> 暂时可以不确定具体 toolkit
[2018-07-22 10:24:59] 迫真 正版 [Re: 2078] >>> ,,,
[2018-07-22 10:25:04] Mingcong Bai >>> 但是希望能保障上述的单页 UI 可以实现
[2018-07-22 10:25:08] Mingcong Bai >>> 我记得 Dialog 应该做不到
[2018-07-22 10:25:19] liushuyu >>> 差不多就是个 TUI 应用
[2018-07-22 10:25:21] Junde Yhi [Re: 2078] >>> 我昨天老硬盘上还翻到这张图
[2018-07-22 10:25:23] Mingcong Bai >>> 多步骤选单
[2018-07-22 10:25:27] Mingcong Bai >>> 然后保存多个配置
[2018-07-22 10:25:30] gumblex [Re: 2069] >>> X 里面弹一个终端?
[2018-07-22 10:25:30] 死 肥 宅 鹹魚 [Re: 2084] >>> 233
[2018-07-22 10:25:39] NeoTimesharingSystem [Re: 2087] >>> Xterm?
[2018-07-22 10:25:42] Mingcong Bai [Re: 2087] >>> 只是其中一个思路,或者可以用 GTK
[2018-07-22 10:25:46] Junde Yhi >>> 等一下,有 X 了为什么不用图形
[2018-07-22 10:25:46] Mingcong Bai >>> 既然有 GParted 在
[2018-07-22 10:25:51] gumblex [Re: 2089] >>> 中文支持不好
[2018-07-22 10:25:52] Mingcong Bai [Re: 2091] >>> (是我也反应过来了
[2018-07-22 10:26:02] gumblex >>> zenity?
[2018-07-22 10:26:11] Mingcong Bai [Re: 2095] >>> 能做多步骤选单吗
[2018-07-22 10:26:14] Junde Yhi >>> GTK 我可以搞啊
[2018-07-22 10:26:19] NeoTimesharingSystem [Re: 2093] >>> 不會啊,Font 試定好舊可以
[2018-07-22 10:26:24] Mingcong Bai [Re: 2097] >>> 那么我们暂时先说 GTK 好了
[2018-07-22 10:26:29] Mingcong Bai >>> 但是我觉得有必要
[2018-07-22 10:26:37] liushuyu [Re: 2097] >>> GTK/Qt 圣战(
[2018-07-22 10:26:40] gumblex [Re: 2096] >>> 参考 winetricks 那玩意?
[2018-07-22 10:26:44] Mingcong Bai >>> 提供一个 Ncurses 方便不能启动 X 的 NVIDIA Pascal 用户们
[2018-07-22 10:26:49] Mingcong Bai [Re: 2102] >>> 不,单页
[2018-07-22 10:26:55] Mingcong Bai >>> 我再发一次那张图
[2018-07-22 10:27:02] Mingcong Bai [Fwd: Mingcong Bai] >>> [photo]
[2018-07-22 10:27:07] NeoTimesharingSystem >>> 直接 OpenBSD Style 就簡單了
[2018-07-22 10:27:20] NeoTimesharingSystem >>> 「用問的」
[2018-07-22 10:27:27] Mingcong Bai [Re: 2103] >>> cc @liushuyu @lmy441900 我刚可能是想到这个(
[2018-07-22 10:27:42] Junde Yhi [Re: 2108] >>> 这让我想起内核的 make config
[2018-07-22 10:27:43] gumblex [Re: 2096] >>> NSIS!(逃
[2018-07-22 10:27:52] Mingcong Bai [Re: 2111] >>> 再次,看图
[2018-07-22 10:28:05] Mingcong Bai >>> 有图标还是友好很多……
[2018-07-22 10:28:09] NeoTimesharingSystem [Re: 2110] >>> Kernel Config 用 make config 簡直會出人命啊
[2018-07-22 10:28:11] Junde Yhi >>> (NSIS 真的是为所欲为的)
[2018-07-22 10:28:19] Mingcong Bai [Re: 2115] >>> Well
[2018-07-22 10:28:31] NeoTimesharingSystem >>> 用 Framebuffer 直接寫入也可以
[2018-07-22 10:28:37] Mingcong Bai >>> 好的这个话题最多还能再持续半个小时,我们可以开始讨论下发行日程的问题吗
[2018-07-22 10:28:41] Junde Yhi [Re: 2114] >>> 安装系统那几个选项倒是比较适合
[2018-07-22 10:28:45] Mingcong Bai >>> 多频繁,什么情况下?
[2018-07-22 10:28:52] Mingcong Bai >>> — 频率?发行频率应该如何计划,跟随季度/每月/每周(包含周期内安全更新)?
[2018-07-22 10:29:15] NeoTimesharingSystem [Re: 2121] >>> 每週吧
[2018-07-22 10:29:16] Mingcong Bai >>> 假设我们用三分支的情况下,应该发布基于什么分支的 Live/Tarball?
[2018-07-22 10:29:25] Mingcong Bai >>> Context 我发一下,刷个屏
[2018-07-22 10:29:33] Mingcong Bai [Fwd: AOSCC 2018 公告板] >>> 第一议程(第一次讨论,后续还有讨论,时间稍后公布): 调整 AOSC OS 的更新周期和里程碑计划集成
——————————————
— 总体赞成延长周期到季度
— 固定每个周期的截止时间并且尽量地去保证准时
— 增加一个新的测试级别
关于分支定义
— Chimera 不接受不稳定和测试版本/分支,不接受季度时间限制(但是无明显分支界定的不能打任何 beta/rc,不接受 GNOME 3.29 这类明显的不稳定分支,Node 这类明显需要保障分支内安全更新的在 LTS 分支之间跳)
— Testing 在季度周期(假设两个月更新,一个月测试)内引入新的 LTS 和稳定分支,无明显分支的也引入,但是要在第二个月结尾截止,然后一个月测试
— Stable 只在三个月内提供当前 LTS 分支和稳定分支内的 patch release 更新(比如 GNOME 3.28.1 到 3.28.3)
安全更新和 Exception
— 安全更新首要保证 Stable,假设无法通过任何手段保障 Stable(如需要大幅度更新或当前人力无法保障 backport),则根据上述更新规则向稳定性更低的方向走(Testing,Testing 不行就到 Chimera),任何最后接受安全更新的分支需要优先保证安全更新
— Exception 更新推送到 Stable(当然,需要测试)
— 如果 Stable 版本因为安全或 Exception 比任何其他分支的版本高则需要 cherry-pick 到稳定性更低的分支,并且 bump REL 以保障其他分支的更新(假设 Stable 里面有 Thunderbird 52.9.2,那么 cherry-pick 到另外两个分支的时候则需要让 Testing 得到 52.9.2-1 而 Chimera 得到 52.9.2-2)
周期集成
— Chimera 不受周期管制
— Testing 和 Stable 接受周期管制,而且有冻结期(假设第二个月后季度结余时间作为冻结期)
— 冻结期内不接受任何 Exception 类更新
— Stable 在冻结期内接受安全更新
[2018-07-22 10:29:36] 死 肥 宅 鹹魚 >>> 一季度吧,反正 Stable 更新也慢...
[2018-07-22 10:29:45] liushuyu [Re: 2123] >>> 我觉得 stable 吧
[2018-07-22 10:29:49] Junde Yhi >>> 首先季度的要
[2018-07-22 10:29:51] liushuyu >>> 时间可以长一点
[2018-07-22 10:29:52] Mingcong Bai [Re: 2126] >>> 唯一一点是是否集成安全更新
[2018-07-22 10:30:06] Mingcong Bai >>> 抱歉我错了
[2018-07-22 10:30:14] Mingcong Bai >>> 是是否包含安全更新或 patch level updates
[2018-07-22 10:30:24] NeoTimesharingSystem [Re: 2132] >>> 這個應該要有
[2018-07-22 10:30:34] gumblex [Re: 2121] >>> 季度啊
[2018-07-22 10:30:40] gumblex >>> 一起发
[2018-07-22 10:30:45] AOSCC Relay bot >>> [YJSNPI] 這個可以有(讚賞)
[2018-07-22 10:31:01] Mingcong Bai [Re: 2135] >>> 也就是说安全更新也让用户安装之后自己解决吗
[2018-07-22 10:31:06] Mingcong Bai >>> (虽然我能认同这个
[2018-07-22 10:31:09] Mingcong Bai >>> (考虑到存储问题
[2018-07-22 10:31:12] gumblex [Re: 2123] >>> stable 别的增量
[2018-07-22 10:31:19] AOSCC Relay bot >>> [Neo_Chen[FBSD]] 連安全更新都季度?
[2018-07-22 10:31:28] AOSCC Relay bot >>> [Neo_Chen[FBSD]] 這樣不就 Slackware 了
[2018-07-22 10:31:29] Mingcong Bai [Re: 2141] >>> 不这里混淆了点东西
[2018-07-22 10:31:37] gumblex [Re: 2137] >>> 或者每次有重要的发
[2018-07-22 10:31:39] Mingcong Bai >>> 安全更新是实时针对 Stable 发布的
[2018-07-22 10:31:53] Mingcong Bai >>> 这里的季度是说我们 tarball 生成和发布的频率
[2018-07-22 10:32:05] Mingcong Bai [Re: 2144] >>> 嗯,灵活点也好,但是至少保证季度?
[2018-07-22 10:32:20] Mingcong Bai >>> 然后遇到 Meltdown/Spectre 这种重大事件的时候更新?
[2018-07-22 10:32:24] NeoTimesharingSystem >>> Tarball 季度更新會因為 SA 更新?
[2018-07-22 10:32:39] Mingcong Bai [Re: 2149] >>> 这个是我们正在讨论的问题
[2018-07-22 10:32:44] Mingcong Bai >>> 如何把握这个问题
[2018-07-22 10:32:45] liushuyu [Re: 2148] >>> 对
[2018-07-22 10:32:47] gumblex >>> 反正跟 stable 一起发,重大更新发
[2018-07-22 10:32:55] Junde Yhi >>> 这里可以有 nightly 发行
[2018-07-22 10:32:58] Mingcong Bai [Re: 2153] >>> 我认同这个
[2018-07-22 10:33:00] NeoTimesharingSystem [Re: 2153] >>> 這樣沒問題
[2018-07-22 10:33:12] Mingcong Bai [Re: 2154] >>> Nightly 的话我们可能需要再来一台服务器了……
[2018-07-22 10:33:21] Junde Yhi [Re: 2157] >>> 我自己机器都可以
[2018-07-22 10:33:23] Mingcong Bai >>> 国立暨南大学那边看起来是没法提供了
[2018-07-22 10:33:27] Mingcong Bai [Re: 2158] >>> 网络?
[2018-07-22 10:33:49] NeoTimesharingSystem [Re: 2158] >>> Bandwidth 多少?
[2018-07-22 10:33:51] Junde Yhi >>> 要分开几台机做
[2018-07-22 10:33:55] Junde Yhi >>> 我意识到问题了
[2018-07-22 10:33:58] NeoTimesharingSystem >>> Uptime 比率?
[2018-07-22 10:34:02] Mingcong Bai >>> (不过说起来我也有打算上 NAS
[2018-07-22 10:34:07] Mingcong Bai >>> (但是网络条件就可能不理想了
[2018-07-22 10:34:14] Mingcong Bai >>> 我觉得要做这种还是提供个稳定服务好……
[2018-07-22 10:34:39] Mingcong Bai [Re: 2163] >>> ?
[2018-07-22 10:34:53] Junde Yhi [Re: 2168] >>> ?多大带宽都不行
[2018-07-22 10:35:01] Mingcong Bai >>> 除非有镜像
[2018-07-22 10:35:11] Mingcong Bai >>> 我觉得还是需要个 VPS/公开服务器
[2018-07-22 10:35:20] Mingcong Bai >>> Insert sponsor request here.
[2018-07-22 10:35:43] Mingcong Bai >>> 好的各位还有什么其他的疑问吗?这个工作我们后面会在主群里面继续讨论和推进
[2018-07-22 10:35:58] Mingcong Bai >>> 关于 Live 和发布计划
[2018-07-22 10:36:33] Mingcong Bai >>> 如果没有的话我整理下我们讨论的结果然后给各位验证下?
[2018-07-22 10:39:46] Mingcong Bai >>> 关于 Live 安装/维护环境的设计
— Live 环境提供一个基本环境(类似 GParted,但是具体包含什么组件尚不确定),里面默认不包含任何的系统 tarball。
— 安装程序类似 Which Wich 的点菜单,单页滚动 UI,让用户选择各个安装选项(https://3.bp.blogspot.com/-Xv3kq_UsZX0/WPZ4wQtECDI/AAAAAAAADUY/MGEnX3QN84Qmyz4ho3OzP7fR252JCsSbACEw/s1600/Which%2BWich%2BEnvelope.jpg)。
关于 Live 安装/维护环境的内容
— 标准内容(内核,启动配置,squashfs),以及 Base tarball
— 提供路径(比如 /tarballs)给用户自行包含本地内容供安装程序探测
关于安装流程
一般(新手?)模式:
1. 你想要什么 Flavour/Variant(Base/KDE/GNOME/...)?
2. 你要安装到哪里?
3. 源和网络设置
4. 你是否要打开 Overlay/Testing/Chimera(暂定)?
5. 你还要附加什么(NVIDIA Proprietary/optenv32/devel-base/...)?
6. 你不想要什么?
专家(?)模式:
1-Alt. “我要自己组装”!
2. 你要安装到哪里?
3. 源和网络设置
4. 你是否要打开 Overlay/Testing/Chimera(暂定)?
5. 你想要什么 base,或提供一个包列表(旁边给一个终端按钮?)
— 安装程序支持探测本地内容,假设 /tarballs 里面放 tarball,自动探测其版本(对应 checksum);也可以支持自定义 tarball(提供选项)
— 额外思考,配合当前已安装的 AOSC OS 附带的一个内存中运行的基本维护环境,可以用于备份当前系统。而备份后的系统也可以放到 /tarballs 里面,安装程序即可成为个系统恢复工具
关于系统发行更新频率
— 跟随 Stable 分支每季度更新
— 发生重大安全漏洞事件(例如年初 Spectre)的情况时额外进行更新 [webpage]
[2018-07-22 10:40:15] Mingcong Bai [Re: 2176] >>> @Staph @gumblex @Neo_Chen @lmy441900 @liushuyu @TheSaltedFish @nobootleg 请求认准
[2018-07-22 10:40:18] Mingcong Bai >>> 认证 *
[2018-07-22 10:40:22] NeoTimesharingSystem >>> 可以
[2018-07-22 10:40:41] Mingcong Bai [Re: 2177] >>> 以及 @l2dy0
[2018-07-22 10:41:15] 死 肥 宅 鹹魚 >>> 說個具體的東西... 安裝到的位置能不能有個自己掛載的選項(
[2018-07-22 10:41:32] 死 肥 宅 鹹魚 >>> 比如說我想用 Subvolume 什麼的 😂
[2018-07-22 10:41:36] Mingcong Bai [Re: 2181] >>> 这个理论上可以允许,流程里面提了个笼统的问题,我们后面实现的时候讨论吧?
[2018-07-22 10:41:37] NeoTimesharingSystem >>> 還有 File System 的選擇
[2018-07-22 10:41:43] 死 肥 宅 鹹魚 [Re: 2183] >>> 嗯
[2018-07-22 10:41:45] Mingcong Bai [Re: 2184] >>> 同理
[2018-07-22 10:41:50] Mingcong Bai >>> 除此之外有问题吗?
[2018-07-22 10:41:51] Zero King >>> 重大安全漏洞怎么判定…
[2018-07-22 10:41:59] Mingcong Bai [Re: 2188] >>> 这个可能需要社区讨论了……
[2018-07-22 10:42:07] NeoTimesharingSystem [Re: 2188] >>> 影響層面?
[2018-07-22 10:42:08] Mingcong Bai >>> 感觉没什么办法去量化标准
[2018-07-22 10:42:25] NeoTimesharingSystem >>> 畢竟漏洞不是天天出
[2018-07-22 10:42:30] Staph. aureus | In your GI Tract >>> 我記得有一個什麼安全漏洞分級表?
[2018-07-22 10:42:44] Mingcong Bai [Re: 2193] >>> 所以比如发生 5 个高危就更新什么的?
[2018-07-22 10:43:42] Zero King >>> 有这个 https://nvd.nist.gov/vuln-metrics/cvss [webpage]
[2018-07-22 10:43:45] Junde Yhi >>> 如果有 nightly 就可以合理地说,还没到发行周期,你可以安装之后马上升级,或安装 nightly
[2018-07-22 10:43:52] NeoTimesharingSystem [Re: 2194] >>> 五個太多了吧?
[2018-07-22 10:43:58] Mingcong Bai [Re: 2197] >>> 举个例子
[2018-07-22 10:44:01] Zero King >>> https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System [webpage]
[2018-07-22 10:44:14] Mingcong Bai [Re: 2196] >>> 好的
[2018-07-22 10:44:24] NeoTimesharingSystem >>> 算了
[2018-07-22 10:44:49] gumblex [Re: 2176] >>> 里面包括 base 吧
[2018-07-22 10:44:49] Junde Yhi >>> 问题是 nightly 目前看起来不太可行
[2018-07-22 10:45:31] Junde Yhi >>> 要是搁我学校机房倒是有几百兆的上传带宽
[2018-07-22 10:45:34] Mingcong Bai [Re: 2202] >>> @gumblex 标准内容(内核,启动配置,squashfs),以及 Base tarball
[2018-07-22 10:45:37] Junde Yhi >>> 但我不太确定
[2018-07-22 10:45:38] Mingcong Bai [Re: 2201] >>> ?
[2018-07-22 10:46:07] Mingcong Bai >>> @liushuyu @TheSaltedFish @nobootleg @lmy441900 可以确定上述内容没有问题吗
[2018-07-22 10:46:17] NeoTimesharingSystem [Re: 2207] >>> 因為沒有很熟這些,還是不扯太多了
[2018-07-22 10:46:21] 死 肥 宅 鹹魚 >>> 沒問題(
[2018-07-22 10:46:23] Mingcong Bai [Re: 2209] >>> 好的
[2018-07-22 10:47:18] 无聊怪 >>> 以及 LiveCD 构建工具呢
[2018-07-22 10:47:26] Junde Yhi >>> 暂时没什么问题
[2018-07-22 10:47:28] Mingcong Bai [Re: 2212] >>> 具体实现问题
[2018-07-22 10:47:31] NeoTimesharingSystem >>> 這邊的 Tarball 打包時都有 —numeric-owner 嗎?
[2018-07-22 10:47:42] Mingcong Bai [Re: 2215] >>> 指文件所有者?
[2018-07-22 10:47:46] gumblex [Re: 2192] >>> 其实没啥影响的漏洞天天出
[2018-07-22 10:48:07] Junde Yhi [Re: 2215] >>> 我没理解错意思的话,现在是发现有的
[2018-07-22 10:48:22] NeoTimesharingSystem [Re: 2216] >>> 只紀錄 UID,避免因為 Tar 內的 User 不存在現在系統上而出問題
[2018-07-22 10:48:34] Mingcong Bai [Re: 2219] >>> 那么我们确实记录了数字
[2018-07-22 10:48:45] NeoTimesharingSystem >>> 那就沒問題了
[2018-07-22 10:48:57] 无聊怪 >>> 以及如果安装 Chimera
[2018-07-22 10:49:09] Mingcong Bai [Re: 2176] >>> Still waiting on @Staph @liushuyu @nobootleg
[2018-07-22 10:49:29] 无聊怪 >>> 建议可以用类似 pacsrtap 这样的东西来安装
[2018-07-22 10:50:32] NeoTimesharingSystem [Re: 2224] >>> 那在 APT 上面得用 debootstrap?
[2018-07-22 10:50:39] 死 肥 宅 鹹魚 [Re: 2225] >>> 似乎不兼容
[2018-07-22 10:50:49] Mingcong Bai [Re: 2226] >>> 需要重新实现
[2018-07-22 10:50:50] 冰淇琳 >>> 需要自己写一个
[2018-07-22 10:50:58] liushuyu [Re: 2223] >>> 大体是好的,细节我觉得之后再谈
[2018-07-22 10:51:00] 冰淇琳 >>> 而且那是砖家模式用的
[2018-07-22 10:51:04] NeoTimesharingSystem >>> aoscstrap
[2018-07-22 10:51:05] Mingcong Bai [Re: 2229] >>> Thx
[2018-07-22 10:51:32] Mingcong Bai [Re: 2176] >>> @Staph @nobootleg 还有 9 分钟提出任何质疑
[2018-07-22 10:51:47] Staph. aureus | In your GI Tract >>> 我建議只要在 Live CD 的軟件包或者安裝包裡面有任何東西爆出 CVSS 7 以上的漏洞就馬上發新版本
[2018-07-22 10:52:30] Mingcong Bai [Re: 2234] >>> 已加入到“尚存疑问”
[2018-07-22 10:52:34] 冰淇琳 [Re: 2176] >>> 不想要什么不要在普通模式提供了
[2018-07-22 10:52:55] Staph. aureus | In your GI Tract >>> 然後線上存儲 Privkey 加密後的所有檔案的 hash 然後安裝器解密驗證。
[2018-07-22 10:53:00] 冰淇琳 >>> 因为很容易破坏 base 结构
[2018-07-22 10:53:01] Mingcong Bai [Re: 2236] >>> 而专家模式没必要提供这个选项
[2018-07-22 10:53:03] Staph. aureus | In your GI Tract >>> 其他應該沒什麼問題
[2018-07-22 10:53:10] Mingcong Bai [Re: 2238] >>> 好的
[2018-07-22 10:53:14] 冰淇琳 [Re: 2239] >>> 那就 drop 吧
[2018-07-22 10:53:29] Mingcong Bai >>> Edited.
[2018-07-22 10:53:38] 冰淇琳 >>> 砖家尚且容易玩脱
[2018-07-22 10:53:43] 冰淇琳 >>> 何况新手(
[2018-07-22 10:53:48] Mingcong Bai >>> 那么话题结束
[2018-07-22 10:54:00] Mingcong Bai >>> #TOPIC 11:00 前自由活动
[2018-07-22 10:54:02] Mingcong Bai [Re: 2247] >>> pinned the message
[2018-07-22 10:54:05] 冰淇琳 >>> woc 拖了这么久
[2018-07-22 10:54:10] Mingcong Bai >>> 下一个话题来自 @liushuyu
[2018-07-22 10:54:15] gumblex [Re: 2237] >>> sha256sum.sig 就行了吧
[2018-07-22 10:55:04] NeoTimesharingSystem >>> 我們的 GPG Public Key 要不要弄成 Keyring
[2018-07-22 10:55:07] Staph. aureus | In your GI Tract [Re: 2251] >>> 假定用戶沒有 HTTPS / HSTS
[2018-07-22 10:55:39] Junde Yhi [Re: 2251] >>> 信安的东西很难搞好,我见过一个论调就是不要把文件和文件散列值放在一个服务器上
[2018-07-22 10:56:17] Mingcong Bai >>> (明天翻译决议要翻译死我,还要写 News Post
[2018-07-22 10:56:24] Junde Yhi >>> 有了签名之后会好很多,但是签名本身也可以校验完整性
[2018-07-22 10:56:24] Mingcong Bai >>> (作业什么的,给狗吃的吧?
[2018-07-22 10:56:25] liushuyu >>> 4 分钟
[2018-07-22 10:57:22] Mingcong Bai [Re: 2249] >>> 以后需要在线举行(希望没有下次)的时候就有经验了
[2018-07-22 10:57:29] Mingcong Bai >>> 一个大话题最好两个小时
[2018-07-22 10:57:55] Mingcong Bai [Re: 2256] >>> 你现在写 GTK+ 桌面应用没问题了?(
[2018-07-22 10:58:07] Junde Yhi [Re: 2261] >>> 不能说没问题(
[2018-07-22 10:58:38] Junde Yhi >>> 不过实话说界面最简单的实现方式是网页
[2018-07-22 10:59:00] Mingcong Bai >>> 那是……
[2018-07-22 10:59:05] Mingcong Bai >>> 但是问题在于架构支持了
[2018-07-22 10:59:06] liushuyu >>> 1 分钟
[2018-07-22 10:59:21] Mingcong Bai >>> AMD64 引入个 Electron 什么的根本不在话下
[2018-07-22 10:59:29] NeoTimesharingSystem >>> 30 sec
[2018-07-22 10:59:31] Mingcong Bai >>> 别的架构跑个浏览器都是问题
[2018-07-22 10:59:33] ksqsf genuine >>> Installer 用 Electron 不是很奇怪吗(
[2018-07-22 10:59:37] Junde Yhi >>> 嗯
[2018-07-22 10:59:47] Mingcong Bai >>> GTK+ 考虑到有 GParted 的话
[2018-07-22 10:59:49] Mingcong Bai >>> 是最好的选择了
[2018-07-22 10:59:53] 迫真 正版 >>> 嗯
[2018-07-22 11:00:00] Mingcong Bai >>> #TOPIC 11:00 - 12:00 — AOSC OS 系统发行自动化及持续集成 (CI)
[2018-07-22 11:00:02] Mingcong Bai [Re: 2275] >>> pinned the message
[2018-07-22 11:00:06] Mingcong Bai >>> @liushuyu 514
[2018-07-22 11:01:24] Mingcong Bai >>> @liushuyu ping
[2018-07-22 11:01:42] liushuyu >>> 谢谢 老白
大家好,本场的主题是 Continuous Integration of System Delivery (系统发布的持续集成)
完整的文稿在 https://repo.aosc.io/aosc-documentation/aoscc-2018/AOSC2018_CI_scripts.odt
Google Docs: https://docs.google.com/document/d/1fx0zmnOP_pw-h6Qte_TmzQMH5C7Xn5lD_y8XWoXD_sc/edit?usp=drivesdk
如有疑问,欢迎在 AOSCC 2018 主群组提出
如果没有严重分歧或者问题的话,我们应该会很快选择一个方案实现如文档中述的想法
可能会有投票
谢谢! [webpage]
[2018-07-22 11:01:54] Mingcong Bai [Re: 2279] >>> Forbidden.
[2018-07-22 11:02:03] Mingcong Bai >>> Google Drive 可用
[2018-07-22 11:02:11] Mingcong Bai >>> 时间关系先删掉 repo 链接吧
[2018-07-22 11:02:13] Mingcong Bai >>> 后面再修
[2018-07-22 11:03:22] liushuyu >>>
给 IRC 用户的 TL;DR 版本:文档位于 https://docs.google.com/document/d/1fx0zmnOP_pw-h6Qte_TmzQMH5C7Xn5lD_y8XWoXD_sc/edit?usp=drivesdk 欢迎讨论,可能有投票,应该可以很快部署
[2018-07-22 11:03:41] liushuyu [Re: 2282] >>> 好了
[2018-07-22 11:06:06] Mingcong Bai >>> 提个问题,实现系统生成 CI 的动机是什么,是否和刚刚 @lmy441900 提出的 Nightly 实际功用类似?
[2018-07-22 11:06:27] liushuyu [Re: 2286] >>> 差不多,代替手工操作
[2018-07-22 11:06:46] 某10 >>> [chat_add_user]
[2018-07-22 11:06:50] liushuyu >>> 不过我们没有那么多存储空间,Nightly 肯定不行
[2018-07-22 11:07:08] Mingcong Bai [Re: 2289] >>> 嗯,也就是说 CI 在这里的意义是做一个 scratch build 而不发布吗
[2018-07-22 11:07:27] Junde Yhi >>> 自动化 tarball 打包吧(通俗地讲)
[2018-07-22 11:07:44] Mingcong Bai [Re: 2291] >>> 嗯,但是 CI 属于持续运行的检查?
[2018-07-22 11:07:44] liushuyu [Re: 2290] >>> 成熟没问题了可以变成 CD
[2018-07-22 11:08:02] Mingcong Bai [Re: 2293] >>> 注:Contiguous Distribution
[2018-07-22 11:08:42] liushuyu >>> (好冷
[2018-07-22 11:08:45] Mingcong Bai >>> 所以我们主要检查点是什么
[2018-07-22 11:09:05] Mingcong Bai [Re: 2295] >>> 感觉是个计划的话似乎确实除了最后的平台讨论之外没有什么好讨论的
[2018-07-22 11:09:11] liushuyu [Re: 2296] >>> 最初期的检查是打 tarball 的脚本
[2018-07-22 11:09:45] liushuyu >>> 后面当然是 tarball 是否打得出来,以及基础 QA
[2018-07-22 11:10:55] Junde Yhi >>> 我在 dabbs 模型里倾向于把所有的计算平台都视为无 Uptime 保证的机器
[2018-07-22 11:11:05] liushuyu >>> 稍后投票决定一下使用什么服务,共 2 轮,先决定使用自己的服务器还是别人的
[2018-07-22 11:11:27] Mingcong Bai [Re: 2301] >>> 自己的服务器改为 Relay 吧……
[2018-07-22 11:11:42] liushuyu [Re: 2300] >>> 但是 Pool 里面很明显需要可用设备 > 0
[2018-07-22 11:11:54] Mingcong Bai >>> 假设使用第三方服务
[2018-07-22 11:12:09] Mingcong Bai >>> 有多少能提供 ppc32/64be 和 mips32/64el 支持?
[2018-07-22 11:12:20] Mingcong Bai >>> 还是说这个 CI 只是针对 AMD64 的
[2018-07-22 11:12:20] Junde Yhi >>> Nein.
[2018-07-22 11:12:25] liushuyu [Re: 2305] >>> 恐怕只能用 Qemu
[2018-07-22 11:12:38] liushuyu [Re: 2305] >>> Minicloud 有 ppc 的容器
[2018-07-22 11:12:42] Junde Yhi >>> 这么多架构的机器就 Debian 有了
[2018-07-22 11:12:54] liushuyu >>> mips 怕是没有
[2018-07-22 11:13:21] Mingcong Bai >>> 那么实际上第三方平台是行不通的吧?
[2018-07-22 11:13:51] Junde Yhi >>> 从工程上看把什么平台都视作同等,那么第三方不第三方就无关紧要
[2018-07-22 11:14:11] Junde Yhi >>> 对整个 CI 网络来说,都是计算节点
[2018-07-22 11:14:26] liushuyu [Re: 2312] >>> 使用 Qemu,我在文档里面说过了,使用别人的东西很明显你的控制力就不足
[2018-07-22 11:14:29] Junde Yhi >>> 两种都可以用
[2018-07-22 11:15:31] liushuyu >>> 5 分钟后投票么
[2018-07-22 11:15:41] Junde Yhi >>> 能都投么
[2018-07-22 11:16:09] Mingcong Bai [Re: 2317] >>> 我的意见是投票没有什么必要了…… 第三方平台有硬性限制,而同时使用的话是个设计选择
[2018-07-22 11:16:11] Mingcong Bai >>> 你觉得呢
[2018-07-22 11:16:33] Junde Yhi >>> 可哟先启用第三方服务,然后逐步往网络添加节点,这里面就可以有自己的服务器
[2018-07-22 11:17:07] liushuyu [Re: 2321] >>> 很多服务不支持提供自己的 Node 的
[2018-07-22 11:17:18] liushuyu >>> 你需要使用他们的
[2018-07-22 11:17:26] Junde Yhi [Re: 2322] >>> 我们可以让 Controller 去擦这个屁股
[2018-07-22 11:17:34] Mingcong Bai [Re: 2322] >>> 让 CI 工具支持生成配置?
[2018-07-22 11:18:02] liushuyu [Re: 2325] >>> 主要是 CI 服务的 session 一般都很短
[2018-07-22 11:18:12] Mingcong Bai [Re: 2326] >>> 这不是同一个问题
[2018-07-22 11:18:12] liushuyu >>> 不会让你一直跑
[2018-07-22 11:18:13] Junde Yhi >>> 比如 Travis CI 有 API,我们就做个 Adapter 去控制 CI 创建实例
[2018-07-22 11:18:30] liushuyu [Re: 2327] >>> 抱歉,回错了
[2018-07-22 11:18:39] Junde Yhi >>> 对自己的服务器,就是控制 ciel(当然这里需要 cield)
[2018-07-22 11:18:42] Mingcong Bai [Re: 2329] >>> +
[2018-07-22 11:19:11] Junde Yhi >>> 不过这一切的基础就是那个中央控制节点…
[2018-07-22 11:19:21] Junde Yhi >>> (所以我说我擅长说了不做)
[2018-07-22 11:19:32] Junde Yhi >>> 我倒是一直在考虑这块
[2018-07-22 11:19:41] Junde Yhi >>> 就是还差了动手的时间
[2018-07-22 11:20:07] liushuyu [Re: 2329] >>> 当然 Travis CI 的问题在于能跑 CIEL! 的那种容器排队时间一般很长
[2018-07-22 11:20:21] liushuyu >>> 数分钟到数小时
[2018-07-22 11:20:28] gumblex [Re: 2324] >>> 问题是没人写这个控制器
[2018-07-22 11:20:41] liushuyu [Re: 2331] >>> 可以用 Jenkins
[2018-07-22 11:20:59] Junde Yhi [Re: 2339] >>> 是啊(笑)
[2018-07-22 11:21:00] liushuyu >>> 中央控制
[2018-07-22 11:21:14] liushuyu >>> 然后其他 Node 跑 Hudson
[2018-07-22 11:21:19] Junde Yhi >>> Jenkins 没有优先队列这个概念
[2018-07-22 11:21:29] Mingcong Bai [Re: 2341] >>> 其实可以针对平台目标写配置
[2018-07-22 11:21:36] Mingcong Bai >>> 甚至不需要 controller?
[2018-07-22 11:21:43] Mingcong Bai >>> 纯粹是最后收集信息的问题?
[2018-07-22 11:21:59] Junde Yhi [Re: 2346] >>> 我是结合 dabbs 模型来说的
[2018-07-22 11:21:59] liushuyu [Re: 2344] >>> 有插件系统啊,找找看
[2018-07-22 11:22:18] Mingcong Bai [Re: 2348] >>> 好吧我有点混淆了
[2018-07-22 11:23:00] liushuyu >>> 其实一开始我打算在文章里写死用 Jenkins 但是这很不民主
[2018-07-22 11:23:30] Mingcong Bai [Re: 2351] >>> (作为初步设想倒是没有必要拘泥太多,收集点意见其实都挺好了
[2018-07-22 11:23:32] liushuyu >>> 因为可能有用 drone 很好的人出来提意见
[2018-07-22 11:23:39] Junde Yhi >>> 如果 Jenkins 能通过各种方式满足我们的需要倒是个非常不错的解决方案
[2018-07-22 11:24:42] liushuyu >>> 而且我之前用过 drone/Travis CI/GitLab Runner/Jenkins/DroneIO 所以我个人是有比较的
[2018-07-22 11:25:22] Junde Yhi [Re: 2355] >>> 主要还是 AOSC 发行版级 CI 的考虑
[2018-07-22 11:25:34] liushuyu >>> 还有就是文档里面写的打 tarball 方式你们没有异议么
[2018-07-22 11:25:51] Mingcong Bai [Re: 2357] >>> 基本准确
[2018-07-22 11:25:58] Junde Yhi >>> 不是所有节点都 7x24 在线,不是所有节点都有相同性能(甚至差别巨大)
[2018-07-22 11:26:02] liushuyu [Re: 2358] >>> 有什么问题?
[2018-07-22 11:26:07] Mingcong Bai >>> 但是第 4 点
[2018-07-22 11:26:22] Mingcong Bai >>> 现在 Ciel 的行为是清理一切不受软件包管理的文件(除非在白名单里面
[2018-07-22 11:26:33] Mingcong Bai >>> 除此之外是没错的
[2018-07-22 11:27:32] Junde Yhi [Re: 2359] >>> Jenkins 主要本身没有根据性能来指派任务的能力
[2018-07-22 11:27:46] Junde Yhi >>> 别的看起来都有
[2018-07-22 11:29:09] liushuyu [Re: 2364] >>> 是,但是 Jenkins 倒是能派任务给多个 Node (假设配置正确)
[2018-07-22 11:29:36] Junde Yhi [Re: 2366] >>> 这很区块链(误)
[2018-07-22 11:29:51] Junde Yhi >>> 浪费得很
[2018-07-22 11:30:10] Junde Yhi >>> 就是想避免这些问题
[2018-07-22 11:30:20] Junde Yhi >>> 还有一些很复杂的需求
[2018-07-22 11:30:50] Junde Yhi >>> 比如说 mipsel 没机器了,我们可以把包扔到 mips64el 上开容器打
[2018-07-22 11:31:12] Junde Yhi >>> 再没有机器,可以扔到 amd64 上用 qemu 打
[2018-07-22 11:31:33] Mingcong Bai [Re: 2372] >>> 尝试用 Qemu 打 *
[2018-07-22 11:31:34] liushuyu [Re: 2370] >>> 说的不错,谁来做呢(
[2018-07-22 11:31:52] Junde Yhi [Re: 2374] >>> (我现在很自责了)
[2018-07-22 11:31:52] liushuyu [Re: 2372] >>> 这些可以用 Jenkins 脚本的
[2018-07-22 11:32:05] Junde Yhi [Re: 2376] >>> 那倒是可以一试
[2018-07-22 11:32:23] liushuyu [Re: 2377] >>> 是 Groovy 方言
[2018-07-22 11:32:32] Junde Yhi >>> 🌚…
[2018-07-22 11:32:50] liushuyu >>> 可以获得目的 Node 的系统环境
[2018-07-22 11:33:01] liushuyu >>> 这样你可以修改构建方法
[2018-07-22 11:34:36] Junde Yhi >>> 那可以一试
[2018-07-22 11:34:41] liushuyu [Re: 2373] >>> 我觉得最大可能性是所有 tarball 都在 amd64 上用 Qemu 打
[2018-07-22 11:35:00] Mingcong Bai [Re: 2383] >>> 这个倒是问题不大
[2018-07-22 11:35:01] Junde Yhi [Re: 2383] >>> 有时候比 Native 还慢
[2018-07-22 11:35:10] Junde Yhi >>> 哦 tarball
[2018-07-22 11:35:15] Junde Yhi >>> (
[2018-07-22 11:35:20] Junde Yhi >>> 这个问题不大
[2018-07-22 11:35:32] Junde Yhi >>> 我忘了主题了
[2018-07-22 11:35:40] Junde Yhi >>> 🌚🌝🌚🌝🌚
[2018-07-22 11:36:45] gumblex >>> 所以是不是把难编译的扔性能好的上,秒出的小包扔辣鸡机器上
[2018-07-22 11:37:16] Mingcong Bai [Re: 2391] >>> 是的,不过我们在讨论系统发行(
[2018-07-22 11:37:39] NeoTimesharingSystem >>> Tarball 不經過 QEMU 也可以吧?
[2018-07-22 11:37:47] liushuyu [Re: 2393] >>> 要装包(
[2018-07-22 11:37:50] NeoTimesharingSystem >>> 是 Big Endian 的問題?
[2018-07-22 11:38:07] liushuyu [Re: 2395] >>> 阅读那个文章
[2018-07-22 11:38:28] Mingcong Bai >>> 注: https://docs.google.com/document/d/1fx0zmnOP_pw-h6Qte_TmzQMH5C7Xn5lD_y8XWoXD_sc/edit?usp=drivesdk [webpage]
[2018-07-22 11:38:29] liushuyu [Re: 2392] >>> CI 怎么触发呢,cron?
[2018-07-22 11:38:38] Mingcong Bai [Re: 2398] >>> Good enough.
[2018-07-22 11:38:42] Junde Yhi [Re: 2398] >>> cron + 手动
[2018-07-22 11:38:53] liushuyu [Re: 2400] >>> Jenkins 完全可以
[2018-07-22 11:39:00] Junde Yhi >>> very ok
[2018-07-22 11:39:11] 死 肥 宅 鹹魚 >>> 食我 systemd timer 啦(x
[2018-07-22 11:39:24] 死 肥 宅 鹹魚 >>> 你們都不賣底褲的麼(x
[2018-07-22 11:39:29] liushuyu >>> Jenkins 自己的 cron 系统语法有一点点不同
[2018-07-22 11:39:49] Junde Yhi >>> 倒是能实现就好
[2018-07-22 11:40:17] liushuyu >>> 加了一个“在 x 时空闲期间”的指令
[2018-07-22 11:40:40] liushuyu >>> Jenkins 会看 system load
[2018-07-22 11:40:47] liushuyu >>> 太高会等
[2018-07-22 11:41:15] liushuyu >>> 好,还有什么问题吗
[2018-07-22 11:41:27] Mingcong Bai >>> 实现意愿?
[2018-07-22 11:41:47] liushuyu [Re: 2411] >>> 我写过 Jenkins Pipeline scripts 我可以来
[2018-07-22 11:41:52] Mingcong Bai >>> K
[2018-07-22 11:41:54] Mingcong Bai >>> 那我没问题了
[2018-07-22 11:42:14] liushuyu >>> 就是新的 arm tarball 打包脚本我不是很了解
[2018-07-22 11:42:35] Mingcong Bai >>> — 初步计划 https://docs.google.com/document/d/1fx0zmnOP_pw-h6Qte_TmzQMH5C7Xn5lD_y8XWoXD_sc/edit
— 计划根据实际情况混用第三方 CI 和社区 Relay 服务器配合工作 [webpage]
[2018-07-22 11:43:06] Mingcong Bai [Re: 2416] >>> @lmy441900 @liushuyu 可否确定?
[2018-07-22 11:43:29] liushuyu [Re: 2417] >>> 使用 Jenkins 的话就基本上倒向自建
[2018-07-22 11:43:44] liushuyu >>> 暗示 第三方不能用
[2018-07-22 11:43:53] Mingcong Bai >>> Edited
[2018-07-22 11:44:01] liushuyu >>> 因为不能加 Node
[2018-07-22 11:44:40] Mingcong Bai >>> 还有其他问题吗 cc @lmy441900
[2018-07-22 11:45:02] liushuyu >>> Jenkins master 放哪儿呢(
[2018-07-22 11:45:20] Mingcong Bai >>> 这个属于具体实现?
[2018-07-22 11:45:27] gumblex >>> Jenkins 是 java?
[2018-07-22 11:45:32] 死 肥 宅 鹹魚 [Re: 2425] >>> (嗯
[2018-07-22 11:45:35] liushuyu [Re: 2425] >>> 对
[2018-07-22 11:45:52] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 2423] >>> 大概需要什么配置
[2018-07-22 11:45:52] liushuyu [Re: 2424] >>> 差不多
[2018-07-22 11:46:00] gumblex >>> 辣鸡板子是不是装不了了
[2018-07-22 11:46:03] Junde Yhi [Re: 2422] >>> n
[2018-07-22 11:46:08] Mingcong Bai [Re: 2431] >>> K
[2018-07-22 11:46:13] liushuyu [Re: 2428] >>> master 不参加打包的话,要求不高
[2018-07-22 11:46:13] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 我 GCP git server 还有一点空余
[2018-07-22 11:46:18] Junde Yhi >>> 主流配置可以
[2018-07-22 11:46:19] Mingcong Bai >>> #TOPIC 12:00 前自由讨论
[2018-07-22 11:46:22] Mingcong Bai [Re: 2436] >>> pinned the message
[2018-07-22 11:46:24] Junde Yhi [Fwd: liushuyu] >>> master 不参加打包的话,要求不高
[2018-07-22 11:46:38] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 那扔我服务器上?
[2018-07-22 11:47:00] liushuyu [Re: 2439] >>> 可以(
[2018-07-22 11:47:02] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 不过只有一个 core
[2018-07-22 11:48:17] Mingcong Bai [Re: 2441] >>> @liushuyu
[2018-07-22 11:48:19] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 内存 5GB
[2018-07-22 11:48:39] liushuyu [Re: 2441] >>> Timer + Logger 不需要多少算力
[2018-07-22 11:49:01] liushuyu [Re: 2443] >>> RAM 大点可以(
[2018-07-22 11:49:07] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 2444] >>> 割一个 nspawn 出来听起来怎么样
[2018-07-22 11:49:23] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 2445] >>> (我 committed usage 就这么多
[2018-07-22 11:49:36] liushuyu [Re: 2446] >>> Jenkins 不能以 uid = 0 运行
[2018-07-22 11:49:47] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 2448] >>> namespace 隔离
[2018-07-22 11:50:05] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 容器里的 0 不是外面的 0
[2018-07-22 11:50:19] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 里面也可以单独配定用户
[2018-07-22 11:50:43] liushuyu [Re: 2450] >>> Jenkins 需要普通用户身份运行,你配置一个 1000 的用户
[2018-07-22 11:51:14] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 2452] >>> 现在弄?
[2018-07-22 11:51:22] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 不过容器里面跑啥 distro
[2018-07-22 11:52:12] liushuyu [Re: 2453] >>> 不需要,Jenkins 配置起来很快
[2018-07-22 11:52:15] Mingcong Bai [Re: 2454] >>> Systemd?
[2018-07-22 11:52:21] Mingcong Bai >>> 感觉这是唯一需求了
[2018-07-22 11:52:31] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ [Re: 2455] >>> Ok
[2018-07-22 11:52:37] liushuyu [Re: 2457] >>> 还需要个有 JIT 的 JDK
[2018-07-22 11:52:39] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 那后面再弄
[2018-07-22 11:52:50] cth451 ǝɔuǝƃɹǝʌᴉp‾ɥʇɔ >>> 环境会有单独的 ssh
[2018-07-22 11:52:51] Mingcong Bai [Re: 2459] >>> Practically everything
[2018-07-22 11:53:24] Mingcong Bai >>> 七分钟后封闭群组到晚上 21:00
[2018-07-22 11:53:32] Mingcong Bai >>> 要不我们先移步?
[2018-07-22 11:53:36] liushuyu [Re: 2464] >>> 好
[2018-07-22 11:53:55] Mingcong Bai >>> ————— (#DAY2) 群组封闭至北京时间 21:00 —————
[2018-07-22 11:54:02] Mingcong Bai [Re: 2466] >>> pinned the message
[2018-07-22 20:50:54] Lion >>> 各位同志大家好
[2018-07-22 20:51:20] liushuyu [Re: 2468] >>> 别激动,还有 9 分钟(
[2018-07-22 20:52:46] Lion >>> (8分钟后 D. Yang 同志将带领大家讨论,打包时的上游源码校验的实现)
[2018-07-22 20:55:55] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 👏
[2018-07-22 21:00:26] AOSCC Relay bot >>> [l2dy_] It's time!
[2018-07-22 21:00:34] Lion >>> 吼啦
[2018-07-22 21:01:21] Lion >>> @JeffBai 店长,拉个标题
[2018-07-22 21:01:41] liushuyu >>> 老板呢(
[2018-07-22 21:02:37] Mingcong Bai >>> #TOPIC 21:00 - 22:00 — AOSC OS 各源码树实现数据校验和 (Checksum) 及相应工作流调整
[2018-07-22 21:02:41] Mingcong Bai [Re: 2476] >>> pinned the message
[2018-07-22 21:02:56] Mingcong Bai [Re: 2474] >>> (我醒的真及时(x
[2018-07-22 21:02:58] Lion >>> 打包工具链中,“下载源代码”,“准备上游素材”的部分,位于 acbs。acbs 读取 spec 文件,下载上游的素材。
[2018-07-22 21:03:52] Lion >>> acbs 的实现中,是包含校验码的,但是我们目前基本没有怎么使用
[2018-07-22 21:04:35] Lion >>> 会顾昨天提及的工作流,我们看到那里面没有记录校验码/更新校验码的部分
[2018-07-22 21:05:17] Lion >>> 那么,我们应该如何引入这个参数呢?试想一下
[2018-07-22 21:06:27] Lion >>> (因为目前我们的工作流里就是没有它,所以这个议程以讨论和建议为主,欢迎提出各种意见)
[2018-07-22 21:06:58] Mingcong Bai >>> 感觉蛮尴尬的
[2018-07-22 21:07:25] Mingcong Bai >>> 源码不在本地就没法校验,那么要怎么保障第一次下载的源码是正确的呢
[2018-07-22 21:08:08] Lion >>> 对,acbs 要求校验码记录在 spec 里,这里其实出现了严重的工作流问题。我们的更新是不管上游的,甚至可以说,加上版本号就溜。
[2018-07-22 21:08:19] Zero King [Re: 2485] >>> 我会验证GPG签名/多地点下载/使用https。
[2018-07-22 21:08:24] Lion >>> “随后等打包的人打就是了”
[2018-07-22 21:09:26] Lion [Re: 2487] >>> 在安全的加强方面,我们可以很乐观地认为,https 的上游没有问题,git 的上游都没有问题
[2018-07-22 21:09:27] Mingcong Bai [Re: 2487] >>> (是的,虽然不是这个话题内容一部分,但是我建议推进一切 spec 转 https
[2018-07-22 21:09:57] Mingcong Bai [Re: 2487] >>> MacPort 是怎么记录校验和的?
[2018-07-22 21:10:06] Zero King >>> 直接写在Portfile里
[2018-07-22 21:10:18] Zero King >>> 默认两种checksum和一个size
[2018-07-22 21:10:45] Mingcong Bai [Re: 2493] >>> 那么从流程上说呢
[2018-07-22 21:10:47] Zero King [Re: 2491] >>> MacPorts…
[2018-07-22 21:10:53] Mingcong Bai >>> 怎样去获得 checksum
[2018-07-22 21:11:04] Mingcong Bai [Re: 2495] >>> Sorry 手机上太容易打漏字了(
[2018-07-22 21:11:22] Lion [Re: 2489] >>> HTTP 上游甚至 FTP 上游有不少。
抛开信道安全,更重要的是,我们要验证的是:
1. 第一个人打包(一般也不会有第二个人),它看到的源代码
2. 现在我想重新打包,我看到的源代码
这两者是否一致
[2018-07-22 21:11:23] Zero King [Re: 2494] >>> 首先修改版本,然后运行port install或upgrade加-v,之后命令会报错并输出正确的checksums
[2018-07-22 21:11:54] Zero King >>> 因为distfiles(源文件)有缓存,不需要重新下载
[2018-07-22 21:12:05] Lion [Re: 2498] >>> @l2dy0 是这样的吗
[2018-07-22 21:13:11] Mingcong Bai >>> 也就是说无条件信任第一个打包者记录的 checksum 吗
[2018-07-22 21:13:30] Zero King >>> MacPorts有CI/CD,它会重新下载一次
[2018-07-22 21:13:41] Mingcong Bai [Re: 2503] >>> Hmm
[2018-07-22 21:13:42] Lion >>> (注)目前的简化的工作流:甲更新 A 的版本,乙打包 A,乙上传 A。
[2018-07-22 21:13:58] Lion >>> 甲往往与乙同一人,但也可以不同。
[2018-07-22 21:14:07] Zero King >>> 我有时还会在自己的VPS上下载一次算checksum
[2018-07-22 21:14:19] Zero King >>> 校验和我觉得一是为了 https://reproducible-builds.org/ ,二是防止上游服务器被黑
[2018-07-22 21:14:43] Mingcong Bai [Re: 2508] >>> 作用我明白
[2018-07-22 21:14:46] 死 肥 宅 鹹魚 >>> Gentoo 那邊是寫完 ebuild 之後用工具下載文件然後生成一個 metadata 放到 Portage 樹裏面,之後別人再編譯的時候根據那個 metadata 來
[2018-07-22 21:15:02] 死 肥 宅 鹹魚 >>> manifest*
[2018-07-22 21:15:07] Lion [Re: 2510] >>> 我明白了
[2018-07-22 21:15:13] Zero King [Re: 2509] >>> 不一定所有人都明白(
[2018-07-22 21:15:17] Mingcong Bai >>> 纯粹有点觉得这样填入 checksum 有点让人满意信任
[2018-07-22 21:15:27] liushuyu [Re: 2514] >>> 难以*
[2018-07-22 21:15:32] Mingcong Bai >>> 不过也没法保证绝对安全……
[2018-07-22 21:15:40] Mingcong Bai [Re: 2515] >>> (嗯我马上上电脑
[2018-07-22 21:16:06] liushuyu [Re: 2514] >>> Fingers async unsafe(
[2018-07-22 21:16:10] Lion >>> 咸鱼,你的意思是,(提供更新信息的人)甲下载一次文件(但可以不打包),和版本号一起更新校验码。?
[2018-07-22 21:17:03] liushuyu >>> 还有一个问题,要是版本管理的话,好像不太好检查的样子,虽然 应该 不需要检查
[2018-07-22 21:17:09] 死 肥 宅 鹹魚 [Re: 2519] >>> 算是吧... 他們是有個叫 ebuild 的命令行工具來做這個事情
[2018-07-22 21:17:14] Lion [Re: 2514] >>> 这个确实不是问题,因为校验码并不是表示信任,而是表示一种确凿的历史状态。
[2018-07-22 21:17:29] Zero King [Re: 2522] >>> +1
[2018-07-22 21:17:33] Lion >>> “我看到的文件和当时的文件是否一致”
[2018-07-22 21:17:46] Mingcong Bai [Re: 2524] >>> Hmm... 了解
[2018-07-22 21:18:05] Lion >>> 如果不一致,那一定是有人出了问题,第一个人的网络,第二个人(我)的网络,上游(故意)
[2018-07-22 21:18:18] liushuyu [Re: 2525] >>> OpenJDK 的 AOSC repacks
[2018-07-22 21:18:48] 死 肥 宅 鹹魚 >>> 寫完 ebuild 之後 `ebuild manifest` 生成 Manifest,那個 Manifest 裏面有各種 Checksum。
實際操作的時候應該是要 `ebuild manifest merge` 之類的,如果打包成功了就直接推,下載文件受損了的話就刪了 Manifest 重新生成什麼的
[2018-07-22 21:19:10] Lion [Re: 2528] >>> 嗯
[2018-07-22 21:19:43] Mingcong Bai >>> 转译到我们的用例就是第一个打包的人写 spec 记录,然后就没了?
[2018-07-22 21:20:08] Lion >>> 那么如果要类比为 acbs 的使用,就等于,输入新的 PKGVER 之后,运行一下这个 manifest 命令更新其他信息?
[2018-07-22 21:20:23] Lion [Re: 2530] >>> 或者说有一套软件来自动更新
[2018-07-22 21:20:44] 死 肥 宅 鹹魚 [Re: 2528] >>> 那個 Manifest 裏不止有下載的文件的 checksum,還有 ebuild 本身以及附帶的文件的 Checksum
[2018-07-22 21:20:46] Lion >>> 是这样吗?
[2018-07-22 21:20:59] Lion [Re: 2533] >>> 嗯,吼的
[2018-07-22 21:21:06] 死 肥 宅 鹹魚 [Re: 2530] >>> 大概
[2018-07-22 21:21:10] liushuyu >>> OpenJDK 的 tarballs 是不稳定的,每次下载同一版本都不一样,AOSC 目前模式下倒是不太影响
[2018-07-22 21:21:19] liushuyu >>> 因为有 repack
[2018-07-22 21:21:30] Lion [Re: 2536] >>> (但我们各种文件脚本本身的校验和已经在 git 里有保证了)
[2018-07-22 21:21:56] 死 肥 宅 鹹魚 [Re: 2539] >>> 畢竟不一樣嘛(
[2018-07-22 21:22:02] Lion [Re: 2540] >>> w
[2018-07-22 21:22:25] liushuyu >>> 不过 OpenJDK 11 还需要继续做 repack 吗?(因为各个模块现在在一个树里面) @JeffBai
[2018-07-22 21:22:33] Lion >>> @liushuyu 提到的 repack 其实就是目前最为“不洁”的包
[2018-07-22 21:22:42] Mingcong Bai [Re: 2542] >>> 具体问题先不讨论了…… 按类别看
[2018-07-22 21:23:22] Lion >>> 因为难以编写脚本构建等一系列原因,不得不打包完之后直接放到仓库里,并且对过程全程无追踪🌝
[2018-07-22 21:23:26] liushuyu [Re: 2543] >>> 但是没有办法
[2018-07-22 21:23:56] Lion [Re: 2545] >>> “我感觉非常匿名老兄”
[2018-07-22 21:23:58] liushuyu >>> OpenJDK 的服务器基本上属于 it will work when it feel likes it
[2018-07-22 21:24:05] 死 肥 宅 鹹魚 >>> Arch 是怎麼解決的...
[2018-07-22 21:24:39] Mingcong Bai [Re: 2547] >>> FeelsIncognitoMan
[2018-07-22 21:25:04] Mingcong Bai [Re: 2549] >>> Arch ... 没注意看过
[2018-07-22 21:25:18] liushuyu [Re: 2549] >>> 一个一个下载(
[2018-07-22 21:25:35] liushuyu >>> 但是很明显我觉得运气成分太高(
[2018-07-22 21:26:03] Leway Colin >>> Arch 我看也是写的 Checksum 跟源码一起吧
[2018-07-22 21:26:22] Lion >>> 这样看好吗:我们引入一个工具(或者命令、子命令…),更新整个树里、发生变化了的 spec 的 checksum
[2018-07-22 21:26:44] liushuyu >>> 是的,但是其实 hg 生成的 tarball 不稳定,MacPorts 下载的是 Oracle 服务器上的东西
[2018-07-22 21:27:06] Mingcong Bai [Re: 2555] >>> 而后是否需要重构?
[2018-07-22 21:27:10] Lion >>> 其后,在 GitHub 上面加入 CI 工具,检查提交的文件里面,经过提交之后,checksum 是减少了还是增加了
[2018-07-22 21:27:23] Lion >>> 类似于 coverage 的检查
[2018-07-22 21:27:37] liushuyu [Re: 2559] >>> coverall 上身(
[2018-07-22 21:27:49] Lion [Re: 2557] >>> 我认为…唔……不需要
[2018-07-22 21:27:55] Mingcong Bai [Re: 2561] >>> K
[2018-07-22 21:28:02] Mingcong Bai >>> 另外一个就是刚刚提到的
[2018-07-22 21:28:04] Lion >>> 但是我承认这有点浪费流量。
[2018-07-22 21:28:10] 死 肥 宅 鹹魚 >>> Arch 那邊的 OpenJDK 9.... [photo]
[2018-07-22 21:28:14] Mingcong Bai >>> 是否应该推进 https
[2018-07-22 21:28:15] liushuyu [Re: 2564] >>> 这个倒是无所谓
[2018-07-22 21:28:22] Mingcong Bai [Re: 2565] >>> 实际上和我们 repack 做法一样
[2018-07-22 21:28:24] Zero King [Re: 2566] >>> Yes!
[2018-07-22 21:28:29] Mingcong Bai [Re: 2567] >>> 不被封号就好
[2018-07-22 21:28:32] Lion [Re: 2566] >>> Yes!
[2018-07-22 21:28:38] Mingcong Bai [Re: 2569] >>> 那么应该再加上这个警告
[2018-07-22 21:28:40] 死 肥 宅 鹹魚 [Re: 2566] >>> HTTPS Yes!
[2018-07-22 21:28:48] Mingcong Bai >>> 筛选一切未加密链接
[2018-07-22 21:28:51] Zero King [Re: 2572] >>> 有些上游不支持http(
[2018-07-22 21:28:52] Mingcong Bai >>> 然后提示修复
[2018-07-22 21:29:04] Mingcong Bai [Re: 2575] >>> ftp 的也得警告(
[2018-07-22 21:29:09] liushuyu [Re: 2570] >>> 不会的,只是帐号会不可见,但是还能用
[2018-07-22 21:29:28] Zero King >>> e.g. ntpsec只支持ftp
[2018-07-22 21:29:33] 死 肥 宅 鹹魚 [Re: 2575] >>> 比如 http://hg.openjdk.java.net
[2018-07-22 21:29:33] Lion >>> 我觉得,本来理论上应该在 GitHub 之类的 CI 上面,检查更新的链接是否可以访问
[2018-07-22 21:29:44] Lion >>> 换句话说,会不会 404
[2018-07-22 21:30:00] Mingcong Bai [Re: 2579] >>> 唉,我其实是很排斥 ftp 的
[2018-07-22 21:30:05] Lion [Re: 2582] >>> 但是这可能会导致……CI 被封号
[2018-07-22 21:30:17] Mingcong Bai >>> 一个是连接慢,一个是不安全
[2018-07-22 21:30:32] Lion [Re: 2585] >>> HELO man
[2018-07-22 21:30:46] liushuyu [Re: 2584] >>> 请求个 HEAD 应该不太可能,除非机房以为你在搞 DDoS
[2018-07-22 21:31:13] liushuyu >>> (加钱就能解决问题
[2018-07-22 21:31:50] liushuyu >>> 然后你会发现你又要选 CI 服务商了(
[2018-07-22 21:32:23] 死 肥 宅 鹹魚 >>> 自建!(被打死
[2018-07-22 21:32:30] Mingcong Bai >>> 或者用自己的服务器
[2018-07-22 21:32:41] Lion [Re: 2587] >>> 是,HEAD 请求就可以了(这里简介一下 HEAD:普通的网页访问都是 GET 或者 POST 一个路径,但如果是 HEAD,就类似于“我只看看你什么响应头,我不关注消息体”,可以节省流量,也降低服务器端的无意义消耗)
[2018-07-22 21:32:45] Mingcong Bai >>> 我这里有一台 Relay 可以干这事儿,存储也很大
[2018-07-22 21:33:03] liushuyu >>> 又是 Jenkins 吗(跑
[2018-07-22 21:33:07] 死 肥 宅 鹹魚 >>> 不介意的話我的服務器上也行
[2018-07-22 21:33:08] Lion >>> Doable w
[2018-07-22 21:33:14] 死 肥 宅 鹹魚 >>> (沒錯也是 Jenkins
[2018-07-22 21:33:22] liushuyu >>> (droneIO 在此用例下 也可以的
[2018-07-22 21:34:00] 死 肥 宅 鹹魚 [Re: 2598] >>> (感覺比 Jenkins 好看很多
[2018-07-22 21:34:05] Lion >>> 其实可能可以用 Travis?
[2018-07-22 21:34:08] liushuyu >>> (但是 droneIO 是个 Docker Hypervisor 镜像
[2018-07-22 21:34:20] Lion >>> 因为更新的包的链接可能也不多
[2018-07-22 21:34:26] Zero King [Re: 2592] >>> 我记得有些上游用HEAD会给403(
[2018-07-22 21:34:29] liushuyu [Re: 2600] >>> 这种情况很可能会被拉黑
[2018-07-22 21:34:46] liushuyu >>> (当然也可能是我多虑了
[2018-07-22 21:34:53] Lion >>> 我们目前包的规模是四千五千左右
[2018-07-22 21:35:10] liushuyu >>> Travis CI 的 systemd 差不多是烂的(
[2018-07-22 21:35:16] Lion [Re: 2604] >>> 这是我担心的,计算比对上游链接和校验码不成,反倒被封……
[2018-07-22 21:35:40] Lion [Re: 2603] >>> 噢…对。那 GET 之后迅速切断也可以接受
[2018-07-22 21:35:40] Mingcong Bai >>> 估计还是用自己的机器好点……
[2018-07-22 21:35:57] Lion >>> “歪?你怎么挂了??”
[2018-07-22 21:36:01] liushuyu >>> Your best bet is to use Docker on Travis CI —— Travis CI 客服
[2018-07-22 21:36:05] Lion >>> (指挂电话)
[2018-07-22 21:36:19] 死 肥 宅 鹹魚 >>> 自建吧,感覺主要是費網絡,性能到沒多少要求的樣子...
[2018-07-22 21:36:29] Lion [Re: 2614] >>> 是…
[2018-07-22 21:36:52] 死 肥 宅 鹹魚 >>> (開個 BandwagonHost(
[2018-07-22 21:37:08] liushuyu >>> Jenkins 倒是有插件能做 GitHub Integration,DroneIO 本身就是个 GitHub Integration
[2018-07-22 21:37:21] liushuyu >>> 后者配置起来要命
[2018-07-22 21:37:34] liushuyu >>> 而且只能用 Docker
[2018-07-22 21:37:48] 死 肥 宅 鹹魚 >>> (但是好看)
[2018-07-22 21:38:01] 死 肥 宅 鹹魚 >>> (Jenkins 那個什麼上世紀 UI)(x)
[2018-07-22 21:38:06] liushuyu [Re: 2620] >>> 错误信息也 好看
[2018-07-22 21:39:47] Lion >>> 那么我们直至现在的一些认识:
1. 加入工具辅助校验码更新
2. 在 GitHub 上,增加关注校验码的覆盖率变化的 CI 链
3. 在 GitHub 上,增加关注链接可达性的检测
[2018-07-22 21:39:51] 死 肥 宅 鹹魚 [Re: 2622] >>> Docker 的錯誤,能... 能叫錯誤麼
[2018-07-22 21:40:19] Zero King [Re: 2617] >>> 哪种方式集成的?注意 https://developer.github.com/changes/2018-04-25-github-services-deprecation/ [webpage]
[2018-07-22 21:40:27] liushuyu [Re: 2621] >>> 还好吧( [photo]
[2018-07-22 21:40:42] Mingcong Bai [Re: 2623] >>> 加入 http/ftp 非安全链接探测?
[2018-07-22 21:40:44] 死 肥 宅 鹹魚 [Re: 2623] >>> 還有個果凍可能不太喜歡的... commit 簽名?
[2018-07-22 21:40:45] Zero King [Re: 2626] >>> Blue Ocean(
[2018-07-22 21:40:57] 死 肥 宅 鹹魚 [Re: 2626] >>> (默認又沒啓用
[2018-07-22 21:41:01] Mingcong Bai [Re: 2628] >>> 如果有规定我会去遵守的
[2018-07-22 21:41:13] Lion [Re: 2627] >>> 嗯,我加上
[2018-07-22 21:41:26] liushuyu [Re: 2625] >>> DroneIO 是 GitHub App,Jenkins 是 Legacy Service
[2018-07-22 21:41:39] Zero King >>> 我推荐301检测
[2018-07-22 21:42:02] Lion [Re: 2628] >>> Commit 签名可以倡议但是不好强制……
[2018-07-22 21:42:19] liushuyu [Re: 2630] >>> 都 8102 年了,谁会去用 Classic UI(
[2018-07-22 21:42:49] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 2635] >>> 还好吧,我们这边一般都签
[2018-07-22 21:42:51] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 🙈
[2018-07-22 21:43:27] Lion [Re: 2635] >>> 但是办法也是有的。比如某人暂时没有带私钥,那就 PR 上去给别人审核之后 Reviewed-By: ,然后加签名。
[2018-07-22 21:43:30] 死 肥 宅 鹹魚 >>> 說到這個... 我自己還要去重新生成一個 GPG Key 了 😂
[2018-07-22 21:43:52] Zero King >>> 我也需要重新生成…
[2018-07-22 21:44:00] Zero King >>> 虽然我现在不怎么commit(
[2018-07-22 21:44:07] liushuyu [Re: 2624] >>> 那哪里是 Docker 的问题,分明是 YAML Parser 写的稀烂(
[2018-07-22 21:44:21] Lion [Re: 2637] >>> 是,很多的大型软件项目的提交,一些发行版的提交甚至有强制要求……
[2018-07-22 21:44:30] Lion >>> 不然 PR 会 bot failed
[2018-07-22 21:44:59] 死 肥 宅 鹹魚 [Re: 2643] >>> 2333
[2018-07-22 21:45:05] Mingcong Bai >>> 那么我们来个 bot?
[2018-07-22 21:45:17] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 2644] >>> 因为本来打包就要求开发者key
[2018-07-22 21:45:30] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 >>> 顺手提交到 github 也不是难事
[2018-07-22 21:45:38] Zero King [Re: 2634] >>> 不安全URL全报警太aggressive了。
[2018-07-22 21:45:39] liushuyu [Re: 2646] >>> 所有 YAML Linter 都说没问题,它就是解析不能
[2018-07-22 21:45:39] Lion [Re: 2647] >>> 我刚才说的那些部分其实都可以用 GitHub bot 实现
[2018-07-22 21:46:04] 死 肥 宅 鹹魚 [Re: 2644] >>> 我之前提交到 Mer Hybris 那邊是要求加 Signed-of by 😂
[2018-07-22 21:46:12] Mingcong Bai [Re: 2650] >>> 只是警告然后维护者尽可能去改
[2018-07-22 21:46:18] Mingcong Bai >>> 这样问题应该不大?
[2018-07-22 21:46:22] 无聊怪 >>> 什么时候才聊 bot 的问题 (
[2018-07-22 21:46:45] Lion [Re: 2653] >>> 概念不太一样,Review 是安全考虑,Sign 是权限考虑
[2018-07-22 21:47:18] Zero King [Re: 2653] >>> 那是DCO
[2018-07-22 21:47:33] 死 肥 宅 鹹魚 >>> 誒那我之前搞錯了
[2018-07-22 21:47:33] Zero King >>> https://developercertificate.org/ [webpage]
[2018-07-22 21:48:10] 艾颖初 (。•́︿•̀。) | Systemd 真好玩 [Re: 2649] >>> 另外如果是手工打的包,上传到服务器没有签名的话也不会过的
[2018-07-22 21:49:49] Lion >>> OK,那我总结一下目前为止的一些想法,看看有没有漏的
我们直至现在的一些认识:
1. 加入工具辅助校验码更新
2. 增加关注校验码的覆盖率变化的 GitHub Bot
3. 增加检测链接可达性的 GitHub Bot
4. 增加提交签名检测的 GitHub Bot(强制?建议?)
5. 增加关注 HTTPS 覆盖率(正面),FTP 覆盖率(负面)等协议的 GitHub Bot
[2018-07-22 21:50:21] Mingcong Bai [Re: 2662] >>> http 覆盖率也应该是负面?
[2018-07-22 21:50:25] liushuyu [Re: 2662] >>> 合并成一个 bot 好了(
[2018-07-22 21:50:28] Lion [Re: 2663] >>> 当然
[2018-07-22 21:50:35] Mingcong Bai [Re: 2665] >>> 那应该列上去
[2018-07-22 21:50:35] liushuyu >>> 封一个号就行了(
[2018-07-22 21:50:39] Lion [Re: 2664] >>> 嗯只是一个特性
[2018-07-22 21:50:48] liushuyu >>> 封一堆就算了)
[2018-07-22 21:50:52] Lion [Re: 2656] >>> 现在我们来聊一聊这里面的 GitHub Bot 和 Tg bot 的对应?
[2018-07-22 21:51:11] Mingcong Bai [Re: 2670] >>> @sakiiily 具体指的是什么问题?
[2018-07-22 21:51:12] Lion [Re: 2666] >>> 和 HTTP 是互斥的嘛,好吧我列上去
[2018-07-22 21:51:13] 死 肥 宅 鹹魚 [Re: 2669] >>> 能做成 GitHub APP 麼?
[2018-07-22 21:51:33] liushuyu [Re: 2673] >>> 不知道这个先进技术的用法(
[2018-07-22 21:51:34] 无聊怪 [Re: 2670] >>> 我觉得就目前来说没什么必要的交互要求吧
[2018-07-22 21:51:54] Lion [Re: 2675] >>> 嗯?交互需求指的是
[2018-07-22 21:52:03] Zero King >>> 本次话题还有8分钟
[2018-07-22 21:52:03] 无聊怪 >>> github bot 跟 aosc 的 tgbot 是完全分开的
[2018-07-22 21:52:08] 无聊怪 >>> 处理不同的事
[2018-07-22 21:52:26] liushuyu >>> 主要是你用别人家的东西肯定要受管(
[2018-07-22 21:52:33] Zero King >>> 开始偏题了(
[2018-07-22 21:52:35] 死 肥 宅 鹹魚 [Re: 2662] >>> 最後一個最好也有個加上一個能對某個包關閉某種檢測的方法...?
[2018-07-22 21:52:36] Lion [Re: 2678] >>> 唔,要推进 bot 的整合吗?
[2018-07-22 21:52:37] Mingcong Bai [Re: 2677] >>> 最多 38
[2018-07-22 21:52:57] Mingcong Bai >>> @Lionium 要不 22:30 之前自由讨论?
[2018-07-22 21:52:58] liushuyu [Re: 2681] >>> 楼要歪成比萨斜塔了(
[2018-07-22 21:53:05] 死 肥 宅 鹹魚 [Re: 2681] >>> 好啊,括號綜合徵
[2018-07-22 21:53:19] Mingcong Bai >>> 下个话题是新分支和更新计划的二次讨论
[2018-07-22 21:53:24] Lion [Re: 2681] >>> 不特别偏,我们这些 bot 难免也要和 Tg bot 交互,让这些堇告推到 Tg 里
[2018-07-22 21:53:29] 死 肥 宅 鹹魚 [Re: 2683] >>> 好耶,這樣就可以甩鍋給 gumblex 了(x
[2018-07-22 21:53:38] Lion [Re: 2690] >>> 惊了
[2018-07-22 21:53:46] Mingcong Bai [Re: 2690] >>> @gumblex 快自救(
[2018-07-22 21:53:57] Mingcong Bai [Re: 2685] >>> @Lionium ?
[2018-07-22 21:54:29] 死 肥 宅 鹹魚 >>> 如果 pakreqBot 能整合進 packages 的那個 bot 當然最好了(
[2018-07-22 21:54:32] 无聊怪 [Re: 2689] >>> 也难说,因为我不参与打包工作,不知道你们是怎样的
[2018-07-22 21:54:38] Lion [Re: 2693] >>> 好啊,或者给 15 分钟就好了
[2018-07-22 21:54:57] Mingcong Bai [Re: 2696] >>> 你说当前话题再给 15?
[2018-07-22 21:54:58] Lion [Re: 2682] >>> 唔…这个大家有什么意见吗?换句话说,白名单
[2018-07-22 21:55:10] Mingcong Bai [Re: 2698] >>> 认同
[2018-07-22 21:55:14] Lion [Re: 2697] >>> y,到 :15 可以了
[2018-07-22 21:55:16] Mingcong Bai >>> 但是每个案例必须提前讨论
[2018-07-22 21:55:19] Mingcong Bai [Re: 2700] >>> 没问题
[2018-07-22 21:55:37] Mingcong Bai >>> 但是注意最后留时间整理所有决定,让所有参与话题的人认证
[2018-07-22 21:55:42] Mingcong Bai >>> 然后我去发公告板
[2018-07-22 21:55:50] Zero King [Re: 2689] >>> 但话题是checksum相关,不是bot相关(
[2018-07-22 21:56:18] Lion [Re: 2705] >>> checksum 规则被违反的话要有一个通知渠道嘛🌝
[2018-07-22 21:56:44] Lion >>> 好吧,bot 再说。我们看看白名单怎么做
[2018-07-22 21:56:46] 死 肥 宅 鹹魚 >>> 提議:全部整合進 Packages, cc @gumblex
[2018-07-22 21:56:47] 死 肥 宅 鹹魚 >>> (跑
[2018-07-22 21:57:19] Lion >>> 白名单的话,一个是加入 spec?好吗
[2018-07-22 21:58:10] Mingcong Bai [Re: 2710] >>> 能稍微解释下什么案例需要吗
[2018-07-22 21:58:16] Lion >>> 就像编译器的各种 warning 的“豁免”参数一样,列一个 BYPASS_RULES=…
[2018-07-22 21:58:21] 死 肥 宅 鹹魚 [Re: 2711] >>> OpenJDK
[2018-07-22 21:58:29] Lion >>> 另外一种方案是在全树范围一个表
[2018-07-22 21:58:32] 死 肥 宅 鹹魚 >>> 沒有 HTTPS(
[2018-07-22 21:58:53] Lion [Re: 2711] >>> 有人回答一下吗?
[2018-07-22 21:58:59] Mingcong Bai [Re: 2716] >>> 有回答了
[2018-07-22 21:59:06] Mingcong Bai [Re: 2714] >>> 我建议用表
[2018-07-22 21:59:15] Mingcong Bai >>> 然后要求维护者填入原因
[2018-07-22 21:59:25] Mingcong Bai >>> (双列列表?
[2018-07-22 21:59:40] Lion >>> [systemd]
[2018-07-22 22:00:15] Mingcong Bai >>> ?
[2018-07-22 22:00:39] Lion >>> 实例x
[2018-07-22 22:00:50] 死 肥 宅 鹹魚 [Re: 2721] >>> hhhhhhh
[2018-07-22 22:00:52] Lion >>> 优秀借口全集
[2018-07-22 22:01:24] Mingcong Bai >>> ini 格式?
[2018-07-22 22:02:03] Lion [Re: 2726] >>> 适合多条对应
[2018-07-22 22:02:21] Mingcong Bai >>> 嗯
[2018-07-22 22:02:40] Lion >>> 只是一个示例,但我比较看好用 ini 记录仓库里这些例外(当然…用英语)
[2018-07-22 22:03:27] Lion >>> OK 那么白名单的问题解决了🌝
[2018-07-22 22:04:09] 死 肥 宅 鹹魚 >>> 還有個方法,有辦法能解析 Wiki 上的列表麼
[2018-07-22 22:04:56] Lion >>> OK,那我总结一下目前为止的一些想法,看看有没有漏的
我们直至现在的一些认识:
1. 加入工具辅助校验码更新
2. 增加关注校验码的覆盖率变化的 GitHub Bot
3. 增加检测链接可达性的 GitHub Bot
4. 增加提交签名检测的 GitHub Bot(强制?建议?)
5. 增加关注 HTTPS 覆盖率(正面),FTP 覆盖率(负面)等协议的 GitHub Bot
6. 白名单位于全树范围(如 whitelist.conf),例如使用 ini 格式,列出每个包及其具体检测项的豁免原因
[2018-07-22 22:05:13] Lion [Re: 2731] >>> 唔…比较难,但是可以
[2018-07-22 22:05:21] Mingcong Bai [Re: 2732] >>> 还是没加上 http(
[2018-07-22 22:05:44] gumblex [Re: 2592] >>> https://github.com/AOSC-Dev/abbs-meta/blob/master/tools/addchksum.sh [webpage]
[2018-07-22 22:05:58] gumblex >>> 我反正没被封
[2018-07-22 22:06:16] Lion [Re: 2735] >>> 🌝那就很棒
[2018-07-22 22:06:21] Mingcong Bai [Re: 2732] >>> 是否还要进行其他讨论?
[2018-07-22 22:06:28] Lion [Re: 2734] >>> 改好了
[2018-07-22 22:06:36] Zero King >>> 还有一点。现有的包需要全加吗?
[2018-07-22 22:06:48] Zero King >>> checksum
[2018-07-22 22:06:52] Mingcong Bai [Re: 2740] >>> 应当如此
[2018-07-22 22:07:09] Zero King [Re: 2742] >>> Very good.
[2018-07-22 22:07:12] Lion [Re: 2740] >>> 可以先做工具,随着更新,一批批加进去
[2018-07-22 22:07:25] Mingcong Bai [Re: 2744] >>> 我建议还是先解决历史遗留问题
[2018-07-22 22:07:27] Lion >>> 覆盖率增加有糖果奖励。
[2018-07-22 22:07:33] Mingcong Bai >>> 毕竟不需要重构
[2018-07-22 22:07:35] 死 肥 宅 鹹魚 [Re: 2735] >>> 提個建議,在 SHA256 以外再加一種 Checksum(
[2018-07-22 22:07:40] Lion [Re: 2745] >>> k
[2018-07-22 22:07:49] 死 肥 宅 鹹魚 >>> 避免那麼一點點點點點點巧合的機率(
[2018-07-22 22:08:01] Lion [Re: 2750] >>> 不用了
[2018-07-22 22:08:05] Lion >>> 🌝
[2018-07-22 22:08:12] Zero King >>> 我建议加size
[2018-07-22 22:08:13] 死 肥 宅 鹹魚 >>> 或者文件大小
[2018-07-22 22:08:19] Mingcong Bai [Re: 2750] >>> 价值实在有限
[2018-07-22 22:08:26] Mingcong Bai [Re: 2754] >>> 这个可以 cc @liushuyu
[2018-07-22 22:08:36] 死 肥 宅 鹹魚 [Re: 2755] >>> 但是再驗證一下也用不了多少時間嘛(
[2018-07-22 22:08:56] Lion >>> 合为一个字段就好了
[2018-07-22 22:09:20] Zero King [Re: 2757] >>> 大文件还是有影响的,文件大小就很快
[2018-07-22 22:09:23] Lion [Re: 2757] >>> 不,还是要很多时间的,边际收益为负
[2018-07-22 22:09:37] 死 肥 宅 鹹魚 >>> 那就文件大小吧 😂
[2018-07-22 22:09:52] Mingcong Bai >>> (好的时间不多了 @Lionium 最后整理一次内容吧
[2018-07-22 22:09:58] Mingcong Bai >>> 然后认证一下……
[2018-07-22 22:09:58] Lion >>> 其实我认为文件大小也没必要……
[2018-07-22 22:10:13] Lion >>> SHA 里面已经有大小信息了
[2018-07-22 22:10:41] Lion >>> 只是文件大小可以加速校验异常的“阳性”验证
[2018-07-22 22:10:46] Lion >>> 所以我不反对
[2018-07-22 22:10:52] Zero King [Re: 2765] >>> What?
[2018-07-22 22:10:58] Lion [Re: 2768] >>> 不知道吗…
[2018-07-22 22:11:06] 死 肥 宅 鹹魚 >>> 先驗證大小,再驗證 SHA
[2018-07-22 22:11:18] Lion >>> 内容后面加分隔,加文件尺寸,加padding
[2018-07-22 22:11:25] Lion >>> 这些都是密码学 hash 的基本要求
[2018-07-22 22:11:29] 死 肥 宅 鹹魚 >>> (然後某些情況下就能提速了)
[2018-07-22 22:11:42] Lion [Re: 2770] >>> 是
[2018-07-22 22:11:54] 死 肥 宅 鹹魚 [Re: 2774] >>> 資辭
[2018-07-22 22:12:08] 死 肥 宅 鹹魚 [Re: 2772] >>> 感覺什麼時候要去學點基礎(坑 +1
[2018-07-22 22:12:16] Lion [Re: 2773] >>> 极少情况,但实现难度不大,我支持
[2018-07-22 22:12:37] Lion >>> 可以了,我最后总结一下。(还有三分钟)
[2018-07-22 22:14:00] gumblex [Re: 2662] >>> 1 我有脚本上面给了
[2018-07-22 22:14:10] Lion >>> OK,那我总结一下目前为止的一些想法,看看有没有漏的
我们直至现在的一些认识:
1. 加入工具辅助校验码更新,校验码采用 (size, sha256) 的形式
2. 增加关注校验码的覆盖率变化的 GitHub Bot
3. 增加检测链接可达性的 GitHub Bot
4. 增加提交签名检测的 GitHub Bot(强制?建议?)
5. 增加关注 HTTP 残留率,FTP 残留率等不安全协议覆盖的 GitHub Bot
6. 白名单位于全树范围(如 whitelist.conf),例如使用 ini 格式,列出每个包及其具体检测项的豁免原因
7. 在工具设计完成后尽快对包进行一次全面的校验码覆盖
[2018-07-22 22:14:31] Lion [Re: 2779] >>> 稍等,我加进去
[2018-07-22 22:14:39] gumblex [Re: 2690] >>> ?
[2018-07-22 22:15:01] 死 肥 宅 鹹魚 [Re: 2780] >>> 我之前說扔 Wiki 主要是人要看的話更方便點(
[2018-07-22 22:15:02] Mingcong Bai [Re: 2780] >>> @gumblex @TheSaltedFish @l2dy0 请认证
[2018-07-22 22:15:11] 死 肥 宅 鹹魚 [Re: 2782] >>> pakreqBot
[2018-07-22 22:15:17] Mingcong Bai >>> (我这里没问题
[2018-07-22 22:15:19] 死 肥 宅 鹹魚 [Re: 2784] >>> 沒有問題(
[2018-07-22 22:16:10] Zero King [Re: 2771] >>> 最后输出已经无法逆出文件大小了(
[2018-07-22 22:16:19] Zero King >>> 白名单会很长吧
[2018-07-22 22:16:23] gumblex [Re: 2708] >>> 我这边一个问题是认证不好做,一个问题是 packages 站实际是没有持久性状态的,是独立的三台机器
[2018-07-22 22:16:47] Lion [Re: 2788] >>> 是,所以我认同加一个显式的大小,在一定程度下比较便利
[2018-07-22 22:17:27] gumblex [Re: 2748] >>> SHA256 被撞再说
[2018-07-22 22:17:56] Lion [Re: 2790] >>> 机器人问题我们有没有必要加一个日程?还是说在主群里随意讨论?
[2018-07-22 22:18:13] 死 肥 宅 鹹魚 [Re: 2790] >>> 後者是什麼情況...
[2018-07-22 22:18:22] liushuyu >>> 具体实现在主群里讨论吧
[2018-07-22 22:18:49] 死 肥 宅 鹹魚 >>> 認證的話現在先用 Telegram 那個頂一會兒?(以後慢慢做
[2018-07-22 22:19:09] Lion >>> 吼,那这个议程就到此结束了。接下来请大家去主(shui)群
[2018-07-22 22:19:11] 死 肥 宅 鹹魚 >>> 照理說 Python 的話現成實現應該很多啊 😂
[2018-07-22 22:19:31] Mingcong Bai >>> #TOPIC 22:30 前自由活动
[2018-07-22 22:19:34] Mingcong Bai [Re: 2801] >>> pinned the message
[2018-07-22 22:19:42] Zero King [Re: 2799] >>> 也可以留下来(
[2018-07-22 22:20:41] Lion [Re: 2803] >>> (`´)哼
[2018-07-22 22:20:44] liushuyu >>> OpenJDK 现在很僵硬,不好编译 11 因为 AOSC 没有 10(
[2018-07-22 22:21:06] Lion [Re: 2806] >>> 越级…bootstrap 吗?
[2018-07-22 22:21:22] 无聊怪 >>> gcc8 有赶上议程吗?
[2018-07-22 22:21:26] 无聊怪 >>> (
[2018-07-22 22:21:36] gumblex [Re: 2798] >>> 我不会做网页上的用户登录啊(
[2018-07-22 22:21:38] liushuyu [Re: 2807] >>> bootstrap 最多比当前正在编译的版本小一个Major 版本号
[2018-07-22 22:21:57] gumblex [Re: 2800] >>> 机器人这边手写都行
[2018-07-22 22:22:01] liushuyu >>> 否则编译会失败
[2018-07-22 22:22:08] Lion [Re: 2808] >>> 害怕了,最近确实有几个重量级的不兼容包更新………
[2018-07-22 22:22:46] Lion >>> GCC 7 →8,Python 3.6 →3.7,ffmpeg(?)
[2018-07-22 22:23:02] liushuyu [Re: 2816] >>> ffmpeg 3-> 4
[2018-07-22 22:23:04] Mingcong Bai [Re: 2808] >>> 下周的 Core 6 计划讨论
[2018-07-22 22:23:05] Lion [Re: 2815] >>> 你这网络是有多快!🌚
[2018-07-22 22:23:15] Mingcong Bai [Re: 2817] >>> FFmpeg 已经搞定了,在现在的 staging
[2018-07-22 22:23:21] gumblex [Re: 2819] >>> 🌚普通的 VPS 提供商啊
[2018-07-22 22:23:21] Lion [Re: 2817] >>> thx mr.fish
[2018-07-22 22:23:33] Zero King >>> 安全更新(
[2018-07-22 22:23:40] liushuyu >>> (OpenJDK 8 -> 11 ???
[2018-07-22 22:23:46] Lion [Re: 2821] >>> 🌚买机不慎,我的服务器的网络都很尴尬
[2018-07-22 22:23:58] 死 肥 宅 鹹魚 [Re: 2822] >>> Fish(disambiguation)
[2018-07-22 22:24:01] Lion [Re: 2824] >>> 唔…这个会破坏很多其他软件吗?
[2018-07-22 22:24:11] liushuyu [Re: 2825] >>> 你的服务器提供商是 Idol(
[2018-07-22 22:24:20] liushuyu [Re: 2827] >>> 会,API 完全不一样了
[2018-07-22 22:24:21] 死 肥 宅 鹹魚 [Re: 2827] >>> Update-alternatives?
[2018-07-22 22:24:22] Zero King [Re: 2827] >>> 很多,例如Android SDK
[2018-07-22 22:24:26] Lion [Re: 2828] >>> 是,它是。🌝
[2018-07-22 22:24:46] 无聊怪 >>> 建议 OpenJDK 多版本
[2018-07-22 22:24:49] Lion >>> 🌝🌝🌝🌝🌝不兼容的大版本总是一个棘手的问题
[2018-07-22 22:25:00] Lion >>> Qt 有 4/5,Python 有 2/3
[2018-07-22 22:25:01] liushuyu [Re: 2832] >>> 她?(
[2018-07-22 22:25:12] LAX VPS >>> arch-jaba
[2018-07-22 22:25:14] 死 肥 宅 鹹魚 >>> 不會吧... 我這邊用的蠟屐 Vultr 都海星(
[2018-07-22 22:25:20] gumblex [Re: 2825] >>> 🌝我这边不论什么网络,我的服务器的网络至少一台是很快的(
[2018-07-22 22:25:23] liushuyu [Re: 2835] >>> Qt 过两年有 6 了(
[2018-07-22 22:25:34] Lion [Re: 2836] >>> 非狮生物,拒绝敬称
[2018-07-22 22:25:52] Lion [Re: 2839] >>> 🌝……
[2018-07-22 22:26:00] gumblex >>> 您是否在使用:ConoHa
[2018-07-22 22:26:11] 死 肥 宅 鹹魚 >>> 這個蛤
[2018-07-22 22:26:20] Lion [Re: 2843] >>> ←_← 咳咳……
[2018-07-22 22:26:22] liushuyu [Re: 2843] >>> 很明显啊(
[2018-07-22 22:26:27] Mingcong Bai >>> (我去搞个早餐
[2018-07-22 22:26:32] Zero King >>> 我们还有需要投票的吗?
[2018-07-22 22:26:39] gumblex [Re: 2846] >>> 被限速怕了)
[2018-07-22 22:26:42] Mingcong Bai [Re: 2848] >>> 计划内只有下周的默认壁纸
[2018-07-22 22:26:49] Mingcong Bai >>> (然而目前只有一个候选
[2018-07-22 22:26:57] Lion >>> [photo]
[2018-07-22 22:26:58] gumblex >>> 线路大佬出现
[2018-07-22 22:26:59] LAX VPS [Re: 2843] >>> 用户下载个东西都能判断为DDoS的服务商
[2018-07-22 22:27:04] LAX VPS >>> LMPO
[2018-07-22 22:27:07] Mingcong Bai >>> "How Democracy Decays in AOSC"
[2018-07-22 22:27:11] 死 肥 宅 鹹魚 >>> 想當年我好不容易弄了點錢開了 ConoHa
然後手賤多加了 IP
然後錢一下子就用完了 🌝
[2018-07-22 22:27:12] Lion >>> 狮子刚才就是在冬菇鸡肉饭的怀抱里完成会议的🌚
[2018-07-22 22:27:32] Mingcong Bai [Re: 2858] >>> 我 Day 1 晚场(我这里早上)
[2018-07-22 22:27:36] Mingcong Bai >>> 一点东西没吃
[2018-07-22 22:27:45] Mingcong Bai >>> 搞完之后各种手麻(
[2018-07-22 22:28:01] 死 肥 宅 鹹魚 [Re: 2861] >>> 手麻是什麼原理
[2018-07-22 22:28:06] LAX VPS >>> 不好意思我刚刚是睡过来的🌚🌚🌚🌚
[2018-07-22 22:28:09] Lion [Re: 2861] >>> 高速运动一下你的手就可以缓解了
[2018-07-22 22:28:14] LAX VPS >>> 昨晚又四点了
[2018-07-22 22:28:16] liushuyu [Re: 2863] >>> 僵硬了(
[2018-07-22 22:28:22] Mingcong Bai >>> Right
[2018-07-22 22:28:25] Mingcong Bai >>> 还有两分钟
[2018-07-22 22:28:36] Lion [Re: 2862] >>> Checksum=1204826829:shashashashashashashashashasgashashasha
[2018-07-22 22:28:40] Lion >>> 之类的?
[2018-07-22 22:28:42] Xiaoxing Ye [Re: 2858] >>> 看饿了
[2018-07-22 22:28:53] 死 肥 宅 鹹魚 >>> 話說 aosc.io 有 RSS 麼
[2018-07-22 22:28:56] gumblex >>> [photo]
[2018-07-22 22:29:00] gumblex >>> 现在按 acbs 的标准是这样
[2018-07-22 22:29:02] liushuyu [Re: 2874] >>> 有
[2018-07-22 22:29:07] 死 肥 宅 鹹魚 [Re: 2870] >>> 有聲音的 Checksum
[2018-07-22 22:29:07] LAX VPS [Re: 2780] >>> 顺便说一下github不是有提供一个通过Web编辑的功能么
[2018-07-22 22:29:10] Lion [Re: 2875] >>> 咳咳……
[2018-07-22 22:29:24] LAX VPS >>> 这个情况下也会有vaild的签名
[2018-07-22 22:29:31] Mingcong Bai >>> [photo]
[2018-07-22 22:29:43] OriginCode [Re: 2882] >>> #朴素一餐
[2018-07-22 22:29:45] 死 肥 宅 鹹魚 [Re: 2882] >>> 吃過同款草莓醬(
[2018-07-22 22:29:56] Mingcong Bai [Re: 2884] >>> 昨天 32oz 装才 2.85USD
[2018-07-22 22:29:57] LAX VPS [Re: 2882] >>> 哎呀小资(
[2018-07-22 22:29:58] gumblex [Re: 2815] >>> (每个包下两遍
[2018-07-22 22:29:59] Mingcong Bai >>> 买爆
[2018-07-22 22:30:09] Mingcong Bai >>> Okay
[2018-07-22 22:30:10] Mingcong Bai >>> 时间到
[2018-07-22 22:30:15] Lion [Re: 2875] >>> 加入 SRCSIZE= 之类的吧…
[2018-07-22 22:30:33] Lion [Re: 2890] >>> (发不出声音了)
[2018-07-22 22:30:38] Mingcong Bai >>> #TOPIC 22:30 - 23:30 — 关于 AOSC OS 转入季度更新、分支调整及里程碑集成的二次讨论
[2018-07-22 22:30:41] 无聊怪 [Re: 2882] >>> 看样子很好吃
[2018-07-22 22:30:42] Mingcong Bai [Re: 2893] >>> pinned the message
[2018-07-22 22:30:47] Mingcong Bai [Re: 2894] >>> 嗯
[2018-07-22 22:30:53] Mingcong Bai >>> 我先发个昨天的决定
[2018-07-22 22:31:06] Mingcong Bai [Fwd: AOSCC 2018 公告板] >>> 第一议程(第一次讨论,后续还有讨论,时间稍后公布): 调整 AOSC OS 的更新周期和里程碑计划集成
——————————————
— 总体赞成延长周期到季度
— 固定每个周期的截止时间并且尽量地去保证准时
— 增加一个新的测试级别
关于分支定义
— Chimera 不接受不稳定和测试版本/分支,不接受季度时间限制(但是无明显分支界定的不能打任何 beta/rc,不接受 GNOME 3.29 这类明显的不稳定分支,Node 这类明显需要保障分支内安全更新的在 LTS 分支之间跳)
— Testing 在季度周期(假设两个月更新,一个月测试)内引入新的 LTS 和稳定分支,无明显分支的也引入,但是要在第二个月结尾截止,然后一个月测试
— Stable 只在三个月内提供当前 LTS 分支和稳定分支内的 patch release 更新(比如 GNOME 3.28.1 到 3.28.3)
安全更新和 Exception
— 安全更新首要保证 Stable,假设无法通过任何手段保障 Stable(如需要大幅度更新或当前人力无法保障 backport),则根据上述更新规则向稳定性更低的方向走(Testing,Testing 不行就到 Chimera),任何最后接受安全更新的分支需要优先保证安全更新
— Exception 更新推送到 Stable(当然,需要测试)
— 如果 Stable 版本因为安全或 Exception 比任何其他分支的版本高则需要 cherry-pick 到稳定性更低的分支,并且 bump REL 以保障其他分支的更新(假设 Stable 里面有 Thunderbird 52.9.2,那么 cherry-pick 到另外两个分支的时候则需要让 Testing 得到 52.9.2-1 而 Chimera 得到 52.9.2-2)
周期集成
— Chimera 不受周期管制
— Testing 和 Stable 接受周期管制,而且有冻结期(假设第二个月后季度结余时间作为冻结期)
— 冻结期内不接受任何 Exception 类更新
— Stable 在冻结期内接受安全更新
[2018-07-22 22:31:09] Mingcong Bai >>> 514
[2018-07-22 22:31:11] Mingcong Bai >>> 继续讨论
[2018-07-22 22:31:18] 死 肥 宅 鹹魚 [Re: 2891] >>> Gentoo 那邊( [photo]
[2018-07-22 22:31:24] Zero King [Re: 2899] >>> 这什么意思?
[2018-07-22 22:31:30] LAX VPS [Re: 2899] >>> 咳咳
[2018-07-22 22:31:37] Mingcong Bai [Re: 2902] >>> 114514 日语发音
[2018-07-22 22:31:47] Junde Yhi [Fwd: Junde Yhi] >>> HTTP 514 Server Decided Up
[2018-07-22 22:32:18] Mingcong Bai [Re: 2898] >>> 昨天我们还有什么没确定来着?
[2018-07-22 22:32:29] Zero King >>> merge方式
[2018-07-22 22:32:53] Zero King >>> 现在有一个问题是安全issue里引用的commit会失效(
[2018-07-22 22:33:17] Mingcong Bai [Re: 2908] >>> 可能没法避免?
[2018-07-22 22:33:23] gumblex >>> 还有一个问题是 packages 站(
[2018-07-22 22:33:32] Zero King [Re: 2909] >>> 如果用merge可以保留
[2018-07-22 22:33:33] gumblex >>> 虽然好像解决了)
[2018-07-22 22:33:37] 死 肥 宅 鹹魚 [Re: 2908] >>> 整個類似 gerrit 那樣的 Change ID?
[2018-07-22 22:33:49] Zero King [Re: 2911] >>> 现在是rebase
[2018-07-22 22:34:20] gumblex >>> [photo]
[2018-07-22 22:34:22] gumblex >>> 🌝
[2018-07-22 22:34:29] Mingcong Bai >>> 每个周期 Testing 和 Stable Merge 一次,然后 Testing 只和 Chimera 交易?
[2018-07-22 22:34:29] Lion >>> 我觉得 merge 其实没问题……没必要在合并的时候做大规模 rebase
[2018-07-22 22:34:43] Zero King [Re: 2917] >>> 交易…
[2018-07-22 22:34:46] Lion [Re: 2915] >>> “就像改过自新”了一样
[2018-07-22 22:34:49] gumblex >>> 我反正是 merge 党
[2018-07-22 22:34:56] Lion [Re: 2921] >>> +1
[2018-07-22 22:35:07] Mingcong Bai [Re: 2917] >>> 但是问题在于
[2018-07-22 22:35:27] Mingcong Bai >>> Testing 引入的是来自 Chimera 某个时间点上的一系列更新
[2018-07-22 22:35:37] Mingcong Bai >>> 而 Stable 还会获取 point release 和安全更新
[2018-07-22 22:35:53] Lion >>> (果然这三个名字还是很奇怪)
[2018-07-22 22:35:54] Mingcong Bai >>> 那么我们要怎么保障 Stable 和其他分支能有相应的更改呢
[2018-07-22 22:36:03] Mingcong Bai [Re: 2926] >>> 一会再讨论啦(
[2018-07-22 22:36:45] Lion [Re: 2927] >>> 没明白问题
[2018-07-22 22:36:49] Lion >>> 合并冲突?
[2018-07-22 22:36:49] gumblex >>> (不懂 git 操作发不出声音)
[2018-07-22 22:37:43] Mingcong Bai [Re: 2930] >>> — Chimera(最不稳定版本)只管死命更新
— Testing 从 Chimera 获取特定时间点的更新
— Stable 做 point release,安全更新以及 Exception 更新
[2018-07-22 22:37:45] OriginCode [Fwd: gumblex] >>> (不懂 git 操作发不出声音)
[2018-07-22 22:37:47] Lion >>> 能虚构一个的例子之类的吗?
[2018-07-22 22:37:51] Mingcong Bai >>> 好
[2018-07-22 22:37:58] Lion >>> 真的没看懂这里面问题是什么
[2018-07-22 22:38:06] Mingcong Bai >>> 假设现在到了九月底,GNOME 3.30 发布
[2018-07-22 22:38:32] Mingcong Bai >>> — Chimera 一下跳到 3.30
— Testing 暂时不接受 3.30(因为没到周期结束)
— Stable 接着跟 3.28 分支更新
[2018-07-22 22:39:00] Mingcong Bai >>> 那么到了周期结束
[2018-07-22 22:39:12] Mingcong Bai >>> Stable 对 3.28 分支打包有调整,修复了问题
[2018-07-22 22:39:16] Mingcong Bai >>> Testing 引入 3.30
[2018-07-22 22:39:20] Mingcong Bai >>> Chimera 接着发疯
[2018-07-22 22:39:54] Mingcong Bai >>> 那么我们是否需要在 Stable 引入更改的时候就开始从 Testing 和 Chimera cherry-pick Stable 更新?
[2018-07-22 22:40:57] Mingcong Bai >>> (看着大家欲言又止
[2018-07-22 22:41:04] Zero King [Re: 2938] >>> Testing不接收的话它的意义何在?
[2018-07-22 22:41:21] LAX VPS >>> stable is stable
[2018-07-22 22:41:23] Mingcong Bai [Re: 2945] >>> 噢抱歉我看错了……
[2018-07-22 22:41:25] OriginCode [Re: 2944] >>> 不,是根本不敢說話
[2018-07-22 22:41:29] Mingcong Bai >>> Testing 会收 3.30
[2018-07-22 22:41:34] Mingcong Bai >>> 但是 Stable 引入了比如一个 path fix
[2018-07-22 22:41:48] Mingcong Bai >>> 那么是否应该要求这个更改 cherry-pick 到其他几个分支?
[2018-07-22 22:42:04] 冰淇琳 [Re: 2950] >>> 我认为应该关闭 stable 直接 commit 的通道
[2018-07-22 22:42:05] LAX VPS >>> 首先要审查一番吧
[2018-07-22 22:42:11] 冰淇琳 >>> 必须从 testing cherry-pick
[2018-07-22 22:42:24] Mingcong Bai [Re: 2954] >>> 麻烦看看上面的内容
[2018-07-22 22:42:29] Mingcong Bai [Re: 2898] >>> ^
[2018-07-22 22:42:48] 冰淇琳 [Re: 2956] >>> emmm 的确是个问题
[2018-07-22 22:42:50] LAX VPS >>> 确定这个patch是否已经在新的版本中修复
[2018-07-22 22:43:09] 冰淇琳 [Re: 2954] >>> 那就加条件
[2018-07-22 22:43:11] Mingcong Bai >>> 那么也就是说各个分支维护需要做 regression testing
[2018-07-22 22:43:16] 冰淇琳 >>> 除非 cannot apply to testing
[2018-07-22 22:43:19] LAX VPS >>> 接着是是否会影响更新的版本
[2018-07-22 22:44:36] Mingcong Bai >>> 那么有这个假设的话
[2018-07-22 22:44:42] Mingcong Bai >>> merge 顺序应该很明显了?
[2018-07-22 22:44:53] Mingcong Bai >>> Chimera > Testing > Stable
[2018-07-22 22:45:00] 冰淇琳 >>> 嗯
[2018-07-22 22:45:02] OriginCode >>> 嗯哼
[2018-07-22 22:45:11] Mingcong Bai >>> @l2dy0
[2018-07-22 22:45:54] Zero King >>> 我们现在的master会怎么处理?
[2018-07-22 22:46:08] Mingcong Bai >>> 至于过渡方法
[2018-07-22 22:46:23] Mingcong Bai >>> 这次 merge 之后三个分支都会均等
[2018-07-22 22:46:29] OriginCode >>> 等下一個 LTS 週期?
[2018-07-22 22:46:30] Mingcong Bai >>> 那么删掉 bugfix 和 master 分支
[2018-07-22 22:46:42] Mingcong Bai >>> 然后从 staging(或者别的名字)创建两个分支
[2018-07-22 22:46:52] Mingcong Bai >>> 然后按规定开始更新操作
[2018-07-22 22:46:55] Zero King >>> 大家都同意从Git的rebase切换到merge?
[2018-07-22 22:47:09] Mingcong Bai >>> 我不反对
[2018-07-22 22:47:18] Mingcong Bai >>> 其他人怎么看?
[2018-07-22 22:47:21] OriginCode [Fwd: Mingcong Bai] >>> 我不反对
[2018-07-22 22:47:52] Mingcong Bai >>> BRB,洗个手
[2018-07-22 22:48:28] Zero King >>> HEAD设置为哪个分支?
[2018-07-22 22:49:36] Mingcong Bai >>> staging?
[2018-07-22 22:50:25] Mingcong Bai >>> 毕竟 staging 无论如何都是最先更新的
[2018-07-22 22:50:55] Lion [Re: 2982] >>> HEAD?
[2018-07-22 22:51:11] Zero King >>> clone的默认分支以及GitHub默认显示的分支
[2018-07-22 22:51:13] Lion >>> Git 里的 HEAD 的概念就是“当前节点”
[2018-07-22 22:51:20] Zero King >>> remote HEAD
[2018-07-22 22:51:21] Lion >>> 不是一个分支概念
[2018-07-22 22:51:29] Mingcong Bai [Re: 2986] >>> 那么保持现状?
[2018-07-22 22:51:36] Mingcong Bai >>> 感觉这个问题不是很大……
[2018-07-22 22:51:46] Lion [Re: 2986] >>> 噢你是说默认分支放哪一条
[2018-07-22 22:52:20] Lion >>> 我觉得我们的更新周期的分支名和 git 分支名对应不上这一点很成问题……
[2018-07-22 22:52:41] Lion >>> 一个词都没有对应🌚
[2018-07-22 22:53:15] Mingcong Bai >>> 现在在定一个概念
[2018-07-22 22:53:20] Mingcong Bai >>> 命名我们都没开始讨论……
[2018-07-22 22:53:48] Zero King >>> 我最初的想法只是node保留在LTS版本。现在多了个Chimera分支以后都不能全merge到一起了…
[2018-07-22 22:54:15] Mingcong Bai [Re: 2997] >>> 我的想法是 Chimera(暂定)也只能在 LTS 之间跳
[2018-07-22 22:54:23] Mingcong Bai >>> 毕竟我们到头来也是消费 LTS 分支而已
[2018-07-22 22:54:31] Zero King >>> 那要Testing做什么?
[2018-07-22 22:55:01] Mingcong Bai [Re: 3000] >>> Testing 主要作用其实就在那最后一个月的缓冲
[2018-07-22 22:55:08] Mingcong Bai >>> 而 Stable 在三个月内都是持续维护的
[2018-07-22 22:55:23] gumblex [Re: 2977] >>> 同意
[2018-07-22 22:55:25] Mingcong Bai >>> — Chimera 不接受不稳定和测试版本/分支,不接受季度时间限制(但是无明显分支界定的不能打任何 beta/rc,不接受 GNOME 3.29 这类明显的不稳定分支,Node 这类明显需要保障分支内安全更新的在 LTS 分支之间跳)
— Testing 在季度周期(假设两个月更新,一个月测试)内引入新的 LTS 和稳定分支,无明显分支的也引入,但是要在第二个月结尾截止,然后一个月测试
— Stable 只在三个月内提供当前 LTS 分支和稳定分支内的 patch release 更新(比如 GNOME 3.28.1 到 3.28.3)
[2018-07-22 22:55:46] Lion >>> 等一下不太对………
[2018-07-22 22:55:54] Lion >>> Chimera,不中断?
[2018-07-22 22:56:08] Mingcong Bai >>> 对
[2018-07-22 22:56:14] Lion >>> 这要酿成大问题………
[2018-07-22 22:56:23] Mingcong Bai >>> Chimera 的作用就在引更新
[2018-07-22 22:56:26] gumblex >>> 为啥要中断
[2018-07-22 22:56:31] Mingcong Bai [Re: 3008] >>> 比如?
[2018-07-22 22:56:56] Lion [Re: 3010] >>> 打包更新的人力太缺了(只有两人、三人),若是全都在更新,testing 还怎么维护
[2018-07-22 22:57:10] gumblex >>> git 的分支最好先给几个月别删,我这里可能出问题
[2018-07-22 22:57:26] Lion >>> 一个月时间依然全都去更新,不加“休息”的话可不是什么好事情
[2018-07-22 22:57:31] Zero King [Re: 2966] >>> 推荐每周期结束时反向merge
[2018-07-22 22:57:53] Mingcong Bai [Re: 3012] >>> 这个你稍微等一下,我正打算说这个问题
[2018-07-22 22:58:03] Mingcong Bai [Re: 3015] >>> 你是说每周 Testing merge Chimera?
[2018-07-22 22:58:58] Lion >>> 我以为是 Chimera 里面 2:1 的工作时间,Testing 只在第三个月底从 Chimera 里拉数据(如今的 stable)。Stable …是什么?
[2018-07-22 22:59:10] Mingcong Bai [Re: 3018] >>> 所以阅读很重要
[2018-07-22 22:59:14] Mingcong Bai [Fwd: Mingcong Bai] >>> — Chimera 不接受不稳定和测试版本/分支,不接受季度时间限制(但是无明显分支界定的不能打任何 beta/rc,不接受 GNOME 3.29 这类明显的不稳定分支,Node 这类明显需要保障分支内安全更新的在 LTS 分支之间跳)
— Testing 在季度周期(假设两个月更新,一个月测试)内引入新的 LTS 和稳定分支,无明显分支的也引入,但是要在第二个月结尾截止,然后一个月测试
— Stable 只在三个月内提供当前 LTS 分支和稳定分支内的 patch release 更新(比如 GNOME 3.28.1 到 3.28.3)
[2018-07-22 22:59:20] LAX VPS >>> chimera的话一直在66号公路上面跑不是啥问题吧
[2018-07-22 22:59:20] Lion >>> 我们的工作时间太长了毫无休止这就是目前的弊病啊
[2018-07-22 22:59:31] Lion >>> 现在还开放一条大马路
[2018-07-22 22:59:32] Mingcong Bai >>> Chimera 并不影响其他两个分支啊
[2018-07-22 22:59:34] Lion >>> 我觉得要玩
[2018-07-22 22:59:40] Lion [Re: 3024] >>> 当然影响啊
[2018-07-22 22:59:42] Mingcong Bai >>> 你是不是误解了什么……
[2018-07-22 23:00:00] LAX VPS [Re: 3023] >>> 实际上只不过是版本的控制多了一关
[2018-07-22 23:00:05] Lion >>> 人力是有限的啊…冻结期是必须要有的
[2018-07-22 23:00:08] Mingcong Bai >>> ……
[2018-07-22 23:00:09] gumblex >>> 就跟 Debian 的 sid 一样啊
[2018-07-22 23:00:09] Zero King >>> 参考 https://nvie.com/posts/a-successful-git-branching-model/ [webpage]
[2018-07-22 23:00:12] Mingcong Bai >>> 同志
[2018-07-22 23:00:17] Mingcong Bai >>> Testing 和 Stable 都有冻结
[2018-07-22 23:00:23] Lion >>> 在冻结期好好观察 bug,寻求修复……
[2018-07-22 23:00:24] Mingcong Bai >>> Chimera 只是做饭的
[2018-07-22 23:00:27] Mingcong Bai >>> 有两个吃饭的
[2018-07-22 23:00:38] Mingcong Bai >>> 至于人力问题,看来我必须现在提出来了
[2018-07-22 23:00:39] Lion [Re: 3034] >>> 冻结期是面向工程的……不是一个分支的概念
[2018-07-22 23:00:57] gumblex [Re: 3031] >>> sid 没大问题自动推 testing(
[2018-07-22 23:01:17] Mingcong Bai >>> — 一部分打包者专门维护 Chimera(Chimera 理论上是不需要测试的)
— 另一部分独立的维护者去维护 Testing 和 Stable,这方面工作量是和一开始类似的
[2018-07-22 23:01:19] Lion >>> 版本更新冻结了之后,就可以调理饭菜……如果你要比喻的话
[2018-07-22 23:01:36] Mingcong Bai >>> Chimera 只管更新,而其他两个分支才是需要维护和测试的
[2018-07-22 23:02:14] Lion [Re: 3041] >>> 我得指出你这个感觉和 testing + stable 的模式的模型几乎没有任何变化,甚至更差了
[2018-07-22 23:02:20] Mingcong Bai [Re: 3044] >>> 不
[2018-07-22 23:02:30] Mingcong Bai >>> Testing 和 Stable 现在就有硬时间周期了……
[2018-07-22 23:02:35] LAX VPS [Re: 3044] >>> 现在就是stable太爆炸了。。。
[2018-07-22 23:02:55] Mingcong Bai [Re: 3048] >>> Chimera 则不需要憋
[2018-07-22 23:03:02] Mingcong Bai >>> Testing 和 Stable 在周期安排内要憋
[2018-07-22 23:03:06] LAX VPS [Re: 3049] >>> 啊磁悬浮
[2018-07-22 23:03:14] Lion >>> 我们之前的 testing 说好了一个月的后几周是不再处理更新,而关注修复,然后并入 stable。
[2018-07-22 23:03:21] Mingcong Bai >>> 对啊……
[2018-07-22 23:03:26] Mingcong Bai >>> 现在也有个 Testing 和 Stable 啊
[2018-07-22 23:03:40] Lion >>> 现在成了大家(两位)都去 24*7*4 更新
[2018-07-22 23:03:45] Mingcong Bai >>> 不是……
[2018-07-22 23:03:45] gumblex >>> 我觉得新模型可以(
[2018-07-22 23:03:45] Lion >>> 我觉得极为不妥
[2018-07-22 23:03:50] Mingcong Bai >>> 唉你还是没理解
[2018-07-22 23:03:56] LAX VPS [Re: 3052] >>> 实际上并没有做到 因为周期太短
[2018-07-22 23:03:57] Mingcong Bai >>> 我直接点名吧
[2018-07-22 23:03:59] Lion >>> 谁来 testing 休息那几个星期测试
[2018-07-22 23:04:27] Lion [Re: 3060] >>> 因为最后 testing 还是一个劲不停地追更新上游……
[2018-07-22 23:04:39] Lion >>> 也没有停下来
[2018-07-22 23:04:42] LAX VPS [Re: 3063] >>> 对啊这就是问题所在
[2018-07-22 23:04:48] Lion >>> stable 欠维护
[2018-07-22 23:05:11] Lion [Re: 3065] >>> 所以啊,现在又来了一个 Chimera 一个劲不停更新,那么 Testing 是不是要欠维护了
[2018-07-22 23:05:19] LAX VPS >>> chimera的意义是让包在上海磁悬浮上面使劲跑
[2018-07-22 23:05:23] Lion >>> 其下的 Stable 那就更是岌岌可危了
[2018-07-22 23:05:25] LAX VPS >>> 并且拉长维护周期
[2018-07-22 23:05:26] Mingcong Bai >>> — @colin4124 这种更新爱好者完全可以去维护 Chimera,利用自动工具探测版本更新,并且确保构建成功
— @liushuyu @JeffBai 去维护 Testing 和 Stable,我们两个都有处理基本 bug 和重构的经验
— @liushuyu @JeffBai 额外处理 Stable 的 point release 更新/安全更新/Exception
[2018-07-22 23:05:47] Lion [Re: 3068] >>> 这可是要人拉着的
[2018-07-22 23:05:51] LAX VPS >>> 保证下面testing和stable
[2018-07-22 23:06:09] LAX VPS [Re: 3072] >>> 现在有自动化工具了所以我觉得没有太大的问题
[2018-07-22 23:06:16] Lion >>> 有人拉着 Chimera 高速列车,就少了人去保证下面的 Testing 和 Stable
[2018-07-22 23:06:26] Mingcong Bai [Re: 3075] >>> Chimera 应该得到最少的人力
[2018-07-22 23:06:30] 死 肥 宅 鹹魚 >>> 再自動化點就成 Fedora Rawhide 了(x
[2018-07-22 23:06:35] Mingcong Bai >>> 维护工作里面最容易的就是自动探测更新和保障构建成功
[2018-07-22 23:06:46] Mingcong Bai >>> 这点我认为可能是你没有长时间维护过软件包……
[2018-07-22 23:06:47] 无聊怪 >>> Chimera 应该需要测试
[2018-07-22 23:06:50] Lion >>> 所以原本的二层模型的人力资源还好保证,现在三层简直……人力贫瘠了
[2018-07-22 23:06:52] 无聊怪 >>> 最少的测试
[2018-07-22 23:06:56] 无聊怪 >>> 再发
[2018-07-22 23:06:57] Lion [Re: 3079] >>> 好吧
[2018-07-22 23:07:00] 无聊怪 >>> 而不是完全不测试
[2018-07-22 23:07:03] LAX VPS >>> 直接一个lilac+ci的事情
[2018-07-22 23:07:04] Mingcong Bai [Re: 3082] >>> 最少的测试,来自构建成功
[2018-07-22 23:07:24] Mingcong Bai [Re: 3084] >>> 所以实际上人力集中点还是 Testing 和 Stable
[2018-07-22 23:07:29] Mingcong Bai >>> 而这两个分支有时间周期的保护
[2018-07-22 23:07:36] 死 肥 宅 鹹魚 >>> 話說 AOSC OS 打包的時候跑 test case 麼(
[2018-07-22 23:07:52] LAX VPS [Re: 3085] >>> 一般来说能构建成功的基本没有太大的问题
[2018-07-22 23:07:53] Mingcong Bai >>> 这样一来去保证 Testing 的测试,去保证 Stable 的日常小范围更新
[2018-07-22 23:07:59] Mingcong Bai [Re: 3090] >>> Unit Testing?
[2018-07-22 23:08:04] Lion [Re: 3088] >>> 好吧,那我们实验瞧瞧接下来的一年的情况……
[2018-07-22 23:08:17] Mingcong Bai >>> 这个真的是硬性人力算力限制了……
[2018-07-22 23:08:23] 死 肥 宅 鹹魚 [Re: 3094] >>> 就比如說 GNU 工具鏈那些東西的 make test
[2018-07-22 23:08:29] gumblex >>> 自动测试写哪
[2018-07-22 23:08:36] Mingcong Bai >>> 你知道 Git 的 test suite 在我的 Ryzen 上都好几个小时吗……
[2018-07-22 23:08:42] gumblex [Re: 3097] >>> 不必全都通过就是(
[2018-07-22 23:08:45] 死 肥 宅 鹹魚 [Re: 3099] >>> (猜得出
[2018-07-22 23:08:54] Mingcong Bai [Re: 3095] >>> Chimera is for fun, Testing and Stable are for consumption
[2018-07-22 23:08:56] LAX VPS >>> 单元测试是很难搞定的。。。。
[2018-07-22 23:08:59] 死 肥 宅 鹹魚 >>> 見識過的 😂
[2018-07-22 23:09:05] gumblex [Re: 3099] >>> 我意思是得有 git —help 那种测试
[2018-07-22 23:09:05] Mingcong Bai [Re: 3103] >>> 但是是应该去保障的
[2018-07-22 23:09:15] Mingcong Bai >>> 但是我实在看不出有什么问题来保障 unit testing
[2018-07-22 23:09:20] Mingcong Bai >>> 什么方法 *
[2018-07-22 23:09:30] Mingcong Bai [Re: 3105] >>> 我会在 Autobuild3 里面实现一个测试脚本支持
[2018-07-22 23:09:31] 死 肥 宅 鹹魚 >>> 唉,錢(
[2018-07-22 23:09:34] Lion [Re: 3098] >>> 新的工具先走起吧。虽然分散的各路组件我感到有点不太友好
[2018-07-22 23:09:43] gumblex >>> 很多软件的单元测试都不过直接发版本
[2018-07-22 23:09:49] Lion >>> 之前我说的 checklist 和相应的自动化工具
[2018-07-22 23:09:53] Mingcong Bai [Re: 3111] >>> 其实可以让 Autobuild3 实现个安装后测试流程
[2018-07-22 23:09:56] LAX VPS [Re: 3106] >>> 说实在的我觉得除非是极其必要否则在有限成本和资源下没有必要做这回事
[2018-07-22 23:09:58] LAX VPS >>> 做不了
[2018-07-22 23:10:06] LAX VPS [Fwd: gumblex] >>> 很多软件的单元测试都不过直接发版本
[2018-07-22 23:10:16] Mingcong Bai [Re: 3116] >>> 说句实话,而且有点不负责任的一句话
[2018-07-22 23:10:21] 死 肥 宅 鹹魚 [Re: 3112] >>> drop 了 drop 了(x
[2018-07-22 23:10:25] gumblex [Re: 3112] >>> 比如 fossil(
[2018-07-22 23:10:30] LAX VPS [Re: 3112] >>> 应该说是绝大多数
[2018-07-22 23:10:46] gumblex [Re: 3121] >>> 我意思是单元测试里一堆 fail 没人管
[2018-07-22 23:10:47] 冰淇琳 >>> 其实一个字
[2018-07-22 23:10:50] 冰淇琳 >>> 穷
[2018-07-22 23:10:58] Lion [Re: 3112] >>> 举个例子,我们检测包的文件有没有越界,有没有跑到 /usr/local(我们暂且可以称之为 fhs-check)
[2018-07-22 23:11:00] LAX VPS [Re: 3124] >>> 并且人不多
[2018-07-22 23:11:04] Mingcong Bai >>> 第一是我们没这个时间和能力,第二是这几年来看来 unit test 对我们的实际 QA 工作没有什么实在联系,第三(最后)是我们还有几千个发行版伙伴(尤其 Debian Fedora)能完成这些工作
[2018-07-22 23:11:14] 死 肥 宅 鹹魚 >>> 個人認爲保證能用並且能過單元測試是發佈新版本的基礎條件 🌝
[2018-07-22 23:11:23] Mingcong Bai [Re: 3127] >>> 所以虽然很不负责任,但是…… 我觉得这点还不至于威胁我们的维护工作
[2018-07-22 23:11:32] Mingcong Bai [Re: 3125] >>> 这个其实 Autobuild3 已经有测试了
[2018-07-22 23:11:42] LAX VPS [Re: 3127] >>> 第三条甩锅嫌疑(
[2018-07-22 23:11:47] LAX VPS >>> 但是确实是如此
[2018-07-22 23:11:52] gumblex >>> 再比如 SQLite,版本能发出来是经过了私有软件的单元测试,你只要/能保证能正常运行
[2018-07-22 23:11:55] Mingcong Bai >>> 但是需要从 abicu(警告)提高到 abdie(完全错误退出)
[2018-07-22 23:12:04] LAX VPS >>> 对于一些维护者规模小的distro来说
[2018-07-22 23:12:06] 死 肥 宅 鹹魚 [Re: 3129] >>> 那這個大概就要等以後算力充裕了再來(
[2018-07-22 23:12:07] Zero King [Re: 3125] >>> 这不算单元测试吧
[2018-07-22 23:12:11] Lion [Re: 3130] >>> 你知道我说的是新的测试工具……把打包以外的东西全都放进一个“构建脚本执行器”上面有点不妥
[2018-07-22 23:12:13] Mingcong Bai [Re: 3133] >>> 上游发布版本之前(或者说开发过程中)应该也有做这个
[2018-07-22 23:12:21] Mingcong Bai [Re: 3138] >>> 啊明白
[2018-07-22 23:12:22] Lion [Re: 3137] >>> 其实我不是说单元测试了…
[2018-07-22 23:12:26] gumblex [Re: 3139] >>> 看开发商了
[2018-07-22 23:12:36] LAX VPS [Re: 3125] >>> 这个不算unit testing
[2018-07-22 23:12:38] Mingcong Bai >>> 单元测试在我们的 scope 里面不太可能在短期内实现的……
[2018-07-22 23:12:44] Lion >>> 比如 Go 的单元测试,极为庞大而且缓慢
[2018-07-22 23:12:46] LAX VPS [Re: 3143] >>> 但是是必要的一环
[2018-07-22 23:12:47] Mingcong Bai >>> 基本的自动测试肯定可以而且需要做
[2018-07-22 23:12:58] LAX VPS >>> 最起码不能打出来空包
[2018-07-22 23:13:00] LAX VPS >>> (
[2018-07-22 23:13:10] 死 肥 宅 鹹魚 [Re: 3148] >>> ++
[2018-07-22 23:13:15] Lion >>> 每一项都很细,而且还混了很多 regression test…
[2018-07-22 23:13:21] gumblex >>> 测试包括:能编译打包、能运行、运行结果没问题、打包没问题
[2018-07-22 23:13:34] Mingcong Bai >>> 对了说起更新行为的区别
[2018-07-22 23:13:39] Lion [Re: 3148] >>> 这个我不知道该叫什么了,这个和 fhs-check 可以归为一类,设立一个工具
[2018-07-22 23:13:41] gumblex [Re: 3152] >>> 「运行结果没问题」可能没法保证,别的我们得保证
[2018-07-22 23:13:55] Mingcong Bai >>> @gumblex 不知道你的 packages 版本探测能不能探测“当前 major 和 minor 内的更新”?
[2018-07-22 23:14:06] Mingcong Bai >>> 也就是知道 x.y 之后只探测 .z 的更新?
[2018-07-22 23:14:15] gumblex [Re: 3156] >>> 能
[2018-07-22 23:14:18] Mingcong Bai >>> 这个对 Stable 的维护很有帮助
[2018-07-22 23:14:19] Mingcong Bai >>> 太好了
[2018-07-22 23:14:32] gumblex [Re: 3157] >>> 🌚啊那现在不行
[2018-07-22 23:14:41] Mingcong Bai >>> 能实现吗
[2018-07-22 23:14:45] gumblex >>> 你 spec 需要给信息
[2018-07-22 23:14:52] LAX VPS [Re: 3161] >>> eeeeeeeeexperimental?
[2018-07-22 23:14:57] Mingcong Bai [Re: 3163] >>> 能不能多跑个实例?
[2018-07-22 23:15:03] Mingcong Bai >>> 比如直接针对 Stable 进行分析
[2018-07-22 23:15:09] gumblex >>> 现在开局一个 url,剩下全靠猜
[2018-07-22 23:15:16] gumblex >>> 你需要给更多信息
[2018-07-22 23:15:27] Mingcong Bai >>> 比如?
[2018-07-22 23:16:16] gumblex >>> 比如单双数问题,上游类型,用于版本检测的 url,stable 的版本前缀
[2018-07-22 23:16:36] Mingcong Bai >>> 不能直接读 VER 字符串进行分析吗
[2018-07-22 23:16:46] Mingcong Bai >>> 比如现在有个 Stable spec 里面 VER=3.28.1
[2018-07-22 23:16:55] Mingcong Bai >>> 那么限定 3.28 只找第三位更新?
[2018-07-22 23:17:43] gumblex [Re: 3136] >>> 算力我觉得其实没有太大问题)
[2018-07-22 23:17:45] Lion [Re: 3171] >>> 误报不少……现在大家说是 semver,但实际上都不少是 “大变样.新功能.修复漏洞”ver
[2018-07-22 23:18:00] Mingcong Bai >>> 这不假
[2018-07-22 23:18:10] 死 肥 宅 鹹魚 [Re: 3174] >>> 那些 test case 不是極度耗時嘛
[2018-07-22 23:18:11] Lion >>> 并不是基于兼容性的版本号
[2018-07-22 23:18:12] gumblex [Re: 3173] >>> 他不知道你要限定几位啊
[2018-07-22 23:18:21] Mingcong Bai >>> 那么实际 Stable 维护上还是需要一些知识基础……
[2018-07-22 23:18:25] Mingcong Bai >>> 虽然可以整理下
[2018-07-22 23:18:37] gumblex [Re: 3177] >>> 默认不进行 unit test,但进行「能运行」的测试
[2018-07-22 23:18:50] Zero King [Re: 3180] >>> 比如单双数的
[2018-07-22 23:19:04] 死 肥 宅 鹹魚 [Re: 3182] >>> 那資辭
[2018-07-22 23:19:09] Mingcong Bai [Re: 3183] >>> GNOME, MATE, XFCE, LXDE, LxQt 都有很明显的界定
[2018-07-22 23:19:17] Mingcong Bai >>> 但是独立项目确实需要谨慎
[2018-07-22 23:19:21] Mingcong Bai >>> 或者用这个思路?
[2018-07-22 23:19:23] 死 肥 宅 鹹魚 >>> 反正至少要保證打出來的東西能運行(上次那個 mpv 嚇死我了
[2018-07-22 23:19:27] Mingcong Bai >>> Stable 只更新“可以确定的”
[2018-07-22 23:19:42] gumblex >>> 对于版本检测工具来说这些都是不知道的信息
[2018-07-22 23:19:52] Zero King [Re: 2987] >>> $ git ls-remote git@github.com:AOSC-Dev/aosc-os-abbs.git
506c9d2e47b093757d6048a47da060dfae02e206 HEAD
[2018-07-22 23:19:54] Mingcong Bai [Re: 3190] >>> 嗯之前想得太天真了
[2018-07-22 23:20:30] Lion [Re: 3191] >>> 噢
[2018-07-22 23:20:51] Mingcong Bai [Re: 3189] >>> 这个各位怎么看?
[2018-07-22 23:21:04] Mingcong Bai >>> 除非是已经记录在案已知更新和维护规则的,不允许在 Stable 更新
[2018-07-22 23:22:06] Lion [Re: 3192] >>> 我经常说咱们的判断太经验了……缺很多信息,如果不是人工智能机器学习,我们要加很多硬性规则信息(这个是我们缺乏的)
[2018-07-22 23:22:19] Lion >>> 另外就是这些规则记录去哪里
[2018-07-22 23:22:23] Mingcong Bai >>> Wiki
[2018-07-22 23:22:37] Mingcong Bai >>> 除非可以实现到工具里面作为判定规则……
[2018-07-22 23:22:39] Lion [Re: 3198] >>> 非程序可读,尽管也是一个进步
[2018-07-22 23:22:50] Zero King >>> 说到wiki我们需要加认证(
[2018-07-22 23:23:01] Mingcong Bai [Re: 3201] >>> (敲碗
[2018-07-22 23:23:02] Zero King [Re: 3200] >>> 其实是Git和Markdown,程序可读
[2018-07-22 23:23:07] gumblex [Re: 3162] >>> 现在的实现是这样,1.猜上游类型,2.获取对应上游的版本列表,3.版本排序,去除不太可能的版本,取最高的版本输出,4.啥都检测不出外包给 release-monitoring.org
[2018-07-22 23:23:23] Mingcong Bai [Re: 3204] >>> 了解
[2018-07-22 23:23:25] Lion [Re: 3203] >>> ………可说到底那是文学,不是程序数据
[2018-07-22 23:23:37] Zero King >>> 规定格式(
[2018-07-22 23:23:52] Lion >>> 那就和写程序数据没两样了
[2018-07-22 23:24:08] Zero King [Re: 3208] >>> 可读性(对人)
[2018-07-22 23:24:32] gumblex [Re: 3199] >>> 搞个 ini 啊
[2018-07-22 23:24:40] Mingcong Bai >>> Hmm
[2018-07-22 23:25:11] Zero King >>> 剩余时间5分钟
[2018-07-22 23:25:12] Lion [Re: 3209] >>> 比如你不能写 “xxx 软件使用单数第二节版本为不稳定”,而要写 "xxx: unstable: minor=odd" 之类的
[2018-07-22 23:25:25] Mingcong Bai [Re: 3212] >>> 如果各位不介意熬夜我们可以继续
[2018-07-22 23:25:26] Lion >>> 到头来还是很不可读…
[2018-07-22 23:25:28] Mingcong Bai >>> 否则得下周继续了
[2018-07-22 23:25:30] 御坂0x4e21 看到她灌水一律赶她下线 [Re: 3213] >>> 这很可读(×
[2018-07-22 23:25:32] gumblex >>> 这一版的版本检测是重写了两年前的版本检测,以前是基于有人写配置文件、输出 rss feed 这么一个假设
[2018-07-22 23:25:47] Zero King [Re: 3032] >>> 我还想讨论一下这个(逆向merge)
[2018-07-22 23:25:48] 御坂0x4e21 看到她灌水一律赶她下线 >>> 或者为什么一定要可读呢
[2018-07-22 23:25:59] Lion [Re: 3220] >>> 这尼玛…是 wiki
[2018-07-22 23:26:05] Mingcong Bai [Re: 3220] >>> 打包者培训?
[2018-07-22 23:26:08] 御坂0x4e21 看到她灌水一律赶她下线 >>> 转换成人类可读的
[2018-07-22 23:26:17] gumblex >>> 这一版的版本检测定死了最好只访问一次网络,最多访问两次
[2018-07-22 23:26:19] Mingcong Bai [Re: 3219] >>> 能简短描述下吗
[2018-07-22 23:26:23] Lion >>> 要是什么鬼程序数据都往 wiki 放,理论上说 TREE 也可以放到 wiki 上
[2018-07-22 23:26:28] Lion >>> 🌚
[2018-07-22 23:26:52] 御坂0x4e21 看到她灌水一律赶她下线 [Re: 3226] >>> Template?
[2018-07-22 23:27:05] 御坂0x4e21 看到她灌水一律赶她下线 >>> 如果放 wiki 上
[2018-07-22 23:27:16] Lion >>> 得…将来就成了面向 Wiki 编程了……
[2018-07-22 23:27:19] gumblex >>> 🌚写解析器很爽吗
[2018-07-22 23:27:21] Lion >>> 我反对的
[2018-07-22 23:27:22] Zero King [Re: 3225] >>> 就是从稳定分支往开发分支merge,与正常的merge开发分支到稳定分支相反。
[2018-07-22 23:27:43] Mingcong Bai [Re: 3233] >>> 但是我们还是需要从开发分支拉更改
[2018-07-22 23:27:58] Zero King [Re: 3234] >>> 是,拉完之后再逆向merge
[2018-07-22 23:28:19] 御坂0x4e21 看到她灌水一律赶她下线 [Re: 3230] >>> 或者写在别的地方,然后转换成人读格式并同步到 wiki 上?
[2018-07-22 23:28:21] Mingcong Bai >>> 不是不可以…… 但是我们需要文档来描述具体的程序
[2018-07-22 23:28:31] Lion [Re: 3236] >>> 哭了,这才是正常思路啊😿
[2018-07-22 23:28:35] Mingcong Bai >>> 各位我稍微打断一下
[2018-07-22 23:28:36] Lion >>> qwq
[2018-07-22 23:28:40] Mingcong Bai >>> 一个小时了,我先整理下
[2018-07-22 23:28:47] Lion >>> 吼吼
[2018-07-22 23:28:52] Mingcong Bai >>> (需要点时间
[2018-07-22 23:29:44] gumblex [Re: 3238] >>> 立即编写 jinja2 模板
[2018-07-22 23:32:40] Mingcong Bai >>> — 任何从稳定分支做的版本更新外更改必须 cherry-pick 到稳定性较低的分支,除非无法或无须合并(或者使用逆向合并?)
— Git 标准分支间操作从 rebase 改为 merge
— Chimera 不应成为工作重点,因为工作主要内容是自动探测版本更新并进行最小化测试(比如只需要保证构建成功)
— Testing 和 Stable 作为 Chimera 的消费者,开发者应该集中工作于这两个分支
— Autobuild3 应实现基本的自动测试流程,暂时不考虑引入和要求单元测试
— Stable 更新时,除非可以确定是 patch release(需要利用文档记录已知规则和例子),否则不允许更新
[2018-07-22 23:33:10] Mingcong Bai [Re: 3245] >>> @gumblex @Lionium @l2dy0 @Icenowy @lilyayta @TheSaltedFish @sakiiily 可否确定?
[2018-07-22 23:33:32] 死 肥 宅 鹹魚 >>> 資辭
[2018-07-22 23:33:46] 冰淇琳 >>> ok
[2018-07-22 23:34:14] LAX VPS >>> OK👌
[2018-07-22 23:34:18] Zero King >>> 我们的patch会变多了(
[2018-07-22 23:34:32] LAX VPS >>> oh patches
[2018-07-22 23:34:35] Zero King >>> 例如curl
[2018-07-22 23:34:41] LAX VPS >>> 血小板配图.PNG
[2018-07-22 23:34:47] Mingcong Bai [Re: 3252] >>> 能解释下吗
[2018-07-22 23:34:58] Junde Yhi [Re: 3253] >>> 🌚
[2018-07-22 23:35:07] Zero King >>> https://github.com/AOSC-Dev/aosc-os-abbs/issues?q=curl+label%3Asecurity [webpage]
[2018-07-22 23:35:14] 无聊怪 >>> ok
[2018-07-22 23:35:14] Zero King >>> 之前我们一直是直接更新minor的
[2018-07-22 23:35:42] Zero King [Re: 3250] >>> 不是反对
[2018-07-22 23:35:42] Mingcong Bai [Re: 3258] >>> 那就 patch 吧
[2018-07-22 23:35:53] Mingcong Bai >>> 我也不希望去再复杂化这个规则了
[2018-07-22 23:35:56] Mingcong Bai [Re: 3259] >>> K
[2018-07-22 23:35:56] Zero King >>> 只是工作量变大,请做好准备
[2018-07-22 23:35:57] Lion [Re: 3259] >>> 这个超出了 autobuild3 的设计范围(很不幸)
[2018-07-22 23:36:12] Lion >>> 交给另外的外部工具吧
[2018-07-22 23:36:25] Mingcong Bai [Re: 3264] >>> 如果你能指出来我就可以做
[2018-07-22 23:36:31] Mingcong Bai >>> 你也要辛苦一点了
[2018-07-22 23:36:46] Zero King >>> Indeed.
[2018-07-22 23:36:46] Mingcong Bai [Re: 3266] >>> Edited
[2018-07-22 23:36:58] Zero King [Re: 3245] >>> 推荐逆向合并
[2018-07-22 23:37:07] Mingcong Bai [Re: 3271] >>> Yep
[2018-07-22 23:37:08] Zero King >>> 保留完整历史
[2018-07-22 23:37:35] Mingcong Bai [Re: 3273] >>> 就是逆向 merge 难道不会把版本重新降下去吗
[2018-07-22 23:37:41] Mingcong Bai >>> 还是说要用什么策略?
[2018-07-22 23:38:01] Zero King [Re: 3274] >>> 会出现conflict
[2018-07-22 23:38:15] Mingcong Bai [Re: 3276] >>> 噢也就是说不用 theirs 或者 ours?
[2018-07-22 23:38:25] Mingcong Bai >>> 然后就直接 git merge foo?
[2018-07-22 23:38:27] Lion >>> 用啊
[2018-07-22 23:38:29] Lion >>> ours
[2018-07-22 23:38:42] Zero King >>> 用了可以解决部分conflict
[2018-07-22 23:38:48] Zero King >>> 当然用
[2018-07-22 23:38:49] Lion >>> 我觉得没法反过来搞啊……
[2018-07-22 23:39:00] Mingcong Bai >>> Right.
[2018-07-22 23:39:02] Lion >>> ours 来确保版本号往前走?
[2018-07-22 23:39:06] Mingcong Bai >>> 嗯
[2018-07-22 23:39:18] Mingcong Bai >>> 那么各位觉得直接用逆向合并,定时做
[2018-07-22 23:39:20] Mingcong Bai >>> 这样合适吗
[2018-07-22 23:39:26] Lion >>> 哦不行……会不会出现慢分支比快分支还提前的情况?
[2018-07-22 23:39:35] Mingcong Bai [Re: 3289] >>> 这个在 Day 1 就提到了
[2018-07-22 23:39:40] Zero King >>> 目的是HEAD(不稳定分支)能包含所有issue里引用的commit
[2018-07-22 23:39:44] Lion [Re: 3287] >>> (最好介绍一下这里面的技术背景)
[2018-07-22 23:39:52] Mingcong Bai >>> 那里提的是 cherry-pick
[2018-07-22 23:39:59] Lion [Re: 3293] >>> 可
[2018-07-22 23:40:09] Mingcong Bai >>> 具体的 Merge 操作我会在文档描述
[2018-07-22 23:40:17] Mingcong Bai >>> 那么定时逆向 merge 也作为我们的选择?
[2018-07-22 23:40:34] Lion >>> 还是没明白什么叫做逆向合并
[2018-07-22 23:40:56] Mingcong Bai >>> — 稳定分支(从 Stable 到 Testing;从 Testing 到 Chimera)每周(?)进行一次逆向合并(使用 ours 策略)
— Git 标准分支间操作从 rebase 改为 merge
— Chimera 不应成为工作重点,因为工作主要内容是自动探测版本更新并进行最小化测试(比如只需要保证构建成功和内容基本正确,比如没有明显大小变化;使用工具自动测试?)
— Testing 和 Stable 作为 Chimera 的消费者,开发者应该集中工作于这两个分支
— Autobuild3 应实现基本的自动测试流程,暂时不考虑引入和要求单元测试
— Stable 更新时,除非可以确定是 patch release(需要利用文档记录已知规则和例子),否则不允许更新