最近需要做一个img文件，来源于这个 wiki
借一下code来说明问题:
# create image file
dd if=/dev/zero of=debian-sid-risc-v-sifive-unmatched.img bs=1M count=4096
# Partition image with correct disk IDs
sudo sgdisk -g --clear --set-alignment=1 \
--new=1:34:+1M: --change-name=1:'u-boot-spl' --typecode=1:5b193300-fc78-40cd-8002-e86c45580b47 \
--new=2:2082:+4M: --change-name=2:'opensbi-uboot' --typecode=2:2e54b353-1271-4842-806f-e436d6af6985 \
--new=3:16384:+130M: --change-name=3:'boot' --typecode=3:0x0700 --attributes=3:set:2 \
--new=4:286720:-0 --change-name=4:'rootfs' --typecode=4:0x8300 \
debian-sid-risc-v-sifive-unmatched.img
首先创建一个 4G 的rootfs(raw),然后再使用sgdisk对整个img文件进行分区。这里的数值与wiki的数值是不一致的，因为wiki的数值是我修改后的，这个才是wiki修改之前的。
第三分区的boot分区，原始值给了130MB，这个值太小了，导致不能在后面的步骤中执行update boot image。所以，我们得把 boot分区扩大，但是这个值可不是随意扩展的，否则会报错的，执行不下去的。
sgdisk的具体用法不是这篇文章的本意，我们主要关注这些offset是怎么计算的来的。
我们再来看另一篇文章：
Command (? for help): p
Disk /dev/disk1: 15634432 sectors, 7.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 70D5FAFF-4AC9-42C6-A552-0603CE032B8D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15634398
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 8390655 4.0 GiB 0700 Microsoft basic data
2 8390656 12584959 2.0 GiB 8300 Linux filesystem
3 12584960 15634398 1.5 GiB A503 FreeBSD UFS
如果我们能把这里搞明白了，
容量 = (end - start + 1) * 512 /某个值
上面就是 (8390655-2048 + 1)512=8388608512=4294967296 bytes（是不是很眼熟,另外很多人忘记加1），这里还有一点就是： 这个加1是分条件的，这里是end，所以头减尾加1就可以了。但是如果你的end是下一分区的start，就没必要加1了。也就是， 前一分区加1就是下一分区的start(不知道有没有特例)
剩下的就是单位转换了：
bytes/1024=xKB
kB/1024=MB
MB/1024=GB
所以， 4294967296/1024/1024/1024=4GB。所以有这个公式计算就很简单了.
再来看上面的例子:
--new=1:34:+1M: --change-name=1:'u-boot-spl' --typecode=1:5b193300-fc78-40cd-8002-e86c45580b47 \
--new=2:2082:+4M: --change-name=2:'opensbi-uboot' --typecode=2:2e54b353-1271-4842-806f-e436d6af6985 \
--new=3:16384:+130M: --change-name=3:'boot' --typecode=3:0x0700 --attributes=3:set:2 \ # 原始值
--new=4:286720:-0 --change-name=4:'rootfs' --typecode=4:0x8300 \ # 原始值
假设我们把 boot 扩大为 400MB（因为我们是打算扩大的3分区，也就是2分区的结尾不用动，扩大3就是改动了4分区的起始位置）, 则有：
(start(下一分区开始)-16384)*512/1024/1024=400
则end为835584.
我们验证一下分区1的offset: (2082-34)*512/1024/1024=1M。 但是分区2的下一分区起始地址放的有点大，不知道为什么。
一直对 git tag不是了解的特别深入，现在有时间坐下来仔细写一写它了。
主要参考这篇文章.
tag就是一个标签，方便开发者在某个时刻查看内容，对，是静态的。可以想象成时间线上的flag。
tag对应某系commit， branch对应一串commits,有一个HEAD 指针，是可以依靠 HEAD 指针移动的。所以，改动代码用branch，查看代码用tag。
tag和branch可以配合使用。比如，已经发布了 v0.1 v0.2 v0.3三个版本，这个时候，如果想在v0.2的基础上(也就是不改动源代码当前)修改代码后发布v0.4，就可以检出v0.2作为branch然后作为开发分支，等功能完成后再次打上一个v0.4的tag发布。
git tag <tagName> # 经常以版本号
git push origin <tagName> //推送到远程仓库
git push origin --tags #一次推送本地多条微推送的tags
以上是基于本地最后一次commit创建的tag，如果想以某次特定的 commmit 创建tag，则需如下:
git tag -a <tagName> <commitId>
查看某个tag的详细情况：
git show <tagName>
查看本地所有的tag：
git tag
git tag -l
查看远程所有的tag：
git ls-remote --tags origin
git tag -d <tagName> # 本地tag的删除
git push origin :<tagName> # 删除远程tag
本意其实就是先删除旧的tag，然后创建新的tag.
如果只存在于本地，在首先删除tag，然后新建tag就可以。
git tag -d <oldTag>
git tag <newTag>
git push origin <newTag> # 推送到远程tag
如果已经推送到远程了，则不仅需要删除本地的tag，则还需要删除远程的tag，再重新创建和推送：
git tag -d <oldTag> # 删除本地的tag
git push origin :<oldTag> # 删除远程的tag
git tag <newTag> #创建新的tag
git push origin <newtag> # 推送到远程仓库
git checkout -b <branchName> <tagName>
如果打包完成后，需要在本地进行测试ok后再上传ftp，那么，需要做哪些check呢？
Copy:
Run lintian over the package. You can run lintian as follows: lintian -v package-version.changes. This will check the source package as well as the binary package. If you don’t understand the output that lintian generates, try adding the -i switch, which will cause lintian to output a very verbose description of the problem.Normally, a package should not be uploaded if it causes lintian to emit errors (they will start with E).For more information on lintian, see lintian.
Optionally run debdiff (see debdiff) to analyze changes from an older version, if one exists.
Install the package and make sure the software works in an up-to-date unstable system.
Upgrade the package from an older version to your new version.
Remove the package, then reinstall it.
Installing, upgrading and removal of packages can either be tested manually or by using the piuparts tool.
Copy the source package in a different directory and try unpacking it and rebuilding it. This tests if the package relies on existing files outside of it, or if it relies on permissions being preserved on the files shipped inside the .diff.gz file.
最大的得到lintian的输出:
Try lintian -I -E -v --pedantic
or set up .lintianrc file with these option enabled
Two kinds of lintian:
1.
iirc the format was d/
2.
source
d/source/xx.lintian-overrides
Correctly format:
bisect-ppx source: source-contains-prebuilt-javascript-object [src/vendor/highlight.js/highlight.pack.js]
jimtcl是我第一个ITP的package，目前的spononer已经被拒绝，我得重新整理一下才能进行upload。
就是在salsa上直接fork到自己下面来。
请注意，所有打包相关的提交不得修改除debian/目录以外的任何文件和文件夹。如果有必要进行修改，请将其作为补丁存放在debian/patches目录下面，具体格式请参阅前文提及的新维护人员手册中有关quilt的内容、DEP-3以及下文提到的gbp pq的使用
vimer@debian-local:~/git/jimtcl/jimtcl$ git branch
* debian/main
然后按照提示建立分支，如果远程分支已经有的，可以使用 git checkout 直接branch出来。
因为这些文件涉及到升级了，所以得手动修改。
打tag的时机也非常关键，下面是推送特定的tag:
首先checkout到你想打tag的分支，然后:
git tag debian/0.81
推送:
git push origin upstream/0.81
gbp pq使用一个特殊的 Git 分支管理补丁：patch-queue/[base-branch-name]。它存储名字为[base-branch-name]的打包分支对应的补丁。请看下面几个应用实例：
最简单滴是使用如下命令创建:
gbp pq import
场景一: 如果以前没有补丁，这句话会创建一个与当前工作分支完全等效的分支，其名称为patch-queue/[base-branch-name]。如果以前有补丁，这些补丁会自动形成 Git 提交。不放心的话，检查一下 Git 提交历史，确认一下以前的补丁已经成功导入。
我必须在这里说一句，如果你已经有了patch-queue/[base-branch-name]这样名称的分支的话——gbp pq import这句命令是不行的，你也许要用到gbp pq rebase。但是这样会大大复杂化工作流程。我的建议是：初始化之前，干掉patch-queue分支，稍后重建也不迟。嗯，一切为了优雅和简单。
嗯？下面该干什么？下面就是开发补丁的时间！修改你想要修改的东西，在这个特殊的分支上像日常开发那样做 Git 提交，无论是自己修改做新的提交还是cherry-pick已经存在的提交都可以。注意事项有以下几点：
场景二：在patch-queue上开发完成，导出补丁至原打包工作分支 接着上面的工作，我们仍然位于patch-queue/[base-branch-name]这个特殊 Git 分支上。运行一行命令：
gbp pq export 即可。这样会自动回到打包工作分支上，同时将刚才的工作成果自动导出，debian/patches目录下的文件得到了自动的修改。大功告成！
如果因为种种原因，暂时无法使用sbuild去构建，那么只能使用下面的命令暂时规避下：
dpkg-buildpackage -us -uc
lintian -i
debsign jimtcl_0.81+dfsg0-1_amd64.changes // 还有一个source.changes
然后就需要输入密码了，一定不要忘记gpg的密码。
debsign的设置需要去看看tools的gpg使用方法。debsign的配置文件在 ~/.devscripts文件中，具体配置如下：
DEBSIGN_KEYID="long id"
dput mentors jimtcl_0.81+dfsg0-1_amd64.changes
这两步一定是同时进行的。需要完整的写一篇有关于dput的文章。
这里有一个配置文件需要注意的:
vimer@debian:~/build_test/jimtcl$ cat ~/.dput.cf
[mentors]
fqdn = mentors.debian.net
incoming = /upload
method = https
allow_unsigned_uploads = 0
progress_indicator = 2
# Allow uploads for UNRELEASED packages
allowed_distributions = .*
然后再去mentors网站就可以看见你上传的包了。
Requestion for Sponsorship
reportbug sponsorship-request --mutt
可以加mutt使用mutt client。
jimtcl我这里有个问题，就是0.81.orig.tar.gz 必须先从 ftp.deb.org上获取到。
jimtcl_0.81+dfsg0.orig.tar.gz
rvboards@d1-1:~$ free -m
total used free shared buff/cache available
Mem: 996 253 612 0 129 726
Swap: 3023 219 2803
查看swap信息，包括文件和分区的详细信息 swapon -s或者cat /proc/swaps 如果都没有，我们就需要手动添加交换分区。注意，OPENVZ架构的VPS是不支持手动添加交换分区的。 添加交换空间有两种选择：添加一个交换分区或添加一个交换文件。推荐你添加一个交换分区；不过，若你没有多少空闲空间可用， 则添加交换文件。
增加swap交换文件 1.使用dd命令创建一个swap交换文件 dd if=/dev/zero of=/home/swap bs=1024 count=1024000 这样就建立一个/home/swap的分区文件，大小为1G。
2.制作为swap格式文件： mkswap /home/swap
3.再用swapon命令把这个文件分区挂载swap分区 swapon /home/swap 我们用free -m命令看一下，发现已经有交换分区了。 但是重启系统后，swap分区又变成0了。
4.为防止重启后swap分区变成0，要修改/etc/fstab文件 vi /etc/fstab 在文件末尾（最后一行）加上 /home/swap swap swap default 0 0 这样就算重启系统，swap分区还是有值。
5.删除swap交换文件 1、先停止swap分区 /sbin/swapoff /home/swap
2、删除swap分区文件 rm -rf /home/swap
3、删除自动挂载配置命令 vi /etc/fstab 这行删除
在邮箱里突然发现一个RFP 1007025:
发现这又是一个python包，果断直接找 Debian python packaging wiki：
为了Debian中的python包容易维护(不只是python，还有其他)，Debian创建了多个语言或者框架相关的team，尽管每个包都是自己owner,但是统一都放到 https://salsa.debian.org/python-team/packages/ 下面，这样做的好处:
注意一点: debian python team不使用 git-gdm,这一点尤其注意。
Set up a new repository visit https://salsa.debian.org/python-team/packages/ and follow the ‘new project’ link (the link will not be accessible unless you have joined the team). Enter the source package name as the project name and leave the visibility set to public.
但是需要python team给你加权限才可以幺。
$ uscan # Download your package's upstream original tarball
$ tar -xvf srcpkgname_1.0.orig.tar.gz
$ cd srcpkgname_1.0
$ git init
$ git checkout -b upstream
$ git add .
$ git commit -m "import srcpkgname_1.0.orig.tar.gz"
$ git tag -s upstream/1.0
$ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream ##
$ git checkout -b debian/master
这里重点介绍下 pristine-tar命令： pristine-tar commit tarball [upstream] pristine-tar commit generates a pristine-tar delta file for the specified tarball, and commits it to version control.
The upstream parameter specifies the tag or branch that contains the same content that is present in the tarball。
python team自己维护了一套tool，叫做 git-dpm,需要安装一下。
git branch -D foo # make sure there is no branch foo
git-dpm import-tar ../foo_0.0.0.orig.tar.gz
git checkout -b upstream-foo # 会创建一个upstream的分支
git-dpm init ../foo_0.0.0.orig.tar.gz # 创建一个master 分支，有debian目录，然而upstream是没有的。
</del>
首先使用 dch --create去创建一个changelog文件，然后再通过dch -i或者dch -e去编辑相关的信息，可以去看看别的package怎么写的。
这儿我的例子如下：
git-multimail (0.15-1) unstable; urgency=medium
* Initial release of git-multimail to Debian. (Closes: #1007025)
-- Add myself as Maintainer.
-- Bo YU <[email protected]> Thu, 31 Mar 2022 10:58:24 +0800
这个命令可以让你从头开始创建打包所需的原料脚本。refer to
The debmake command is the helper script for the Debian packaging.
我们使用debmake命令看一下：
(sid-amd64-sbuild)root@debian-local:/home/vimer/git/git-multimail/git-multimail# debmake
I: set parameters
I: sanity check of parameters
I: pkg="git-multimail", ver="1.5.0", rev="1"
I: *** start packaging in "git-multimail". ***
W: parent directory should be "git-multimail-1.5.0". (If you use pbuilder, this may be OK.)
I: provide git-multimail_1.5.0.orig.tar.gz for non-native Debian package
I: pwd = "/home/vimer/git/git-multimail"
I: Use existing "git-multimail_1.5.0.orig.tar.gz" as upstream tarball
I: pwd = "/home/vimer/git/git-multimail/git-multimail"
I: parse binary package settings:
I: binary package=git-multimail Type=bin / Arch=any M-A=foreign
I: analyze the source tree
I: build_type = Python distutils
I: scan source for copyright+license text and file extensions
...
I: check_all_licenses
I: ........................................................................W: Non-UTF-8 char found, using latin-1: t/email-content.d/accent-python2
...........
I: check_all_licenses completed for 83 files.
I: bunch_all_licenses
I: format_all_licenses
I: make debian/* template files
I: found "debian/changelog"
I: debmake -x "0" ...
I: creating => debian/control
I: creating => debian/copyright
I: substituting => /usr/share/debmake/extra0/rules
I: creating => debian/rules
I: substituting => /usr/share/debmake/extra0/changelog
I: skipping :: debian/changelog (file exists)
I: run "debmake -x1" to get more template files
I: $ wrap-and-sort
这个时候，已经自动为你创建了一些debian/目录下的文件(之前已有的文件不会覆盖)。
主要是看一下d/rules文件:
#!/usr/bin/make -f
# You must remove unused comment lines for the released package.
#export DH_VERBOSE = 1
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all
#export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
%:
dh $@ --with python2
下面是 d/control 文件：
(sid-amd64-sbuild)root@debian-local:/home/vimer/git/git-multimail/git-multimail/debian# cat control
Source: git-multimail
Section: unknown
Priority: optional
Maintainer: root <>
Build-Depends: debhelper-compat (= 12),
dh-python,
python-all,
python-setuptools,
python3-all
Standards-Version: 4.5.0
Homepage: <insert the upstream URL, if relevant>
X-Python-Version: >= 2.6
Package: git-multimail
Architecture: any
Multi-Arch: foreign
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: auto-generated package by debmake
This Debian binary package was auto-generated by the
debmake(1) command provided by the debmake package.
这里有几项是最关键的，比如，section maintainer什么的，这块需要根据自己的实际情况来，当然，我这里是python package，那就先抄一个 control .
这里有一个比较棘手的文件是 d/copyright文件，不太清楚如何去修改它。可以参考这里copyright-format
这里应该对每一个文件的copyright进行检查并说明，Files, Copyright, License为一组，最后是lisence的解释说明。
如果使用deb_make命令的话。可以直接使用那个模板不是问题的。对于python的包来说，这应该是是注意python2和3版本的区别。 还有就是支持rst格式的doc支持。这个上面的链接都有提及。
#!/usr/bin/make -f
export DH_VERBOSE = 1
export PYBUILD_NAME=git-multimail
%:
dh $@ --with python3 --buildsystem=pybuild
使用 d/watch文件可以用来监控upstream有无更新的release,使用下面的命令可以解决大部分github的监控。
version=4
opts=\
repacksuffix=+ds,\
repack,compression=xz,\
dversionmangle=s/\+(debian|dfsg|ds|deb)(\.?\d+)?$//,\
filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%<project>-$1.tar.gz% \
https://github.com/git-multimail/git-multimail/tags \
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
在主目录中可以使用uscan命令进行测试。
uscan --no-download --verbose
这里有一些需要fix的问题对于新的itp包：
Dsc failed to parse
dsc is missing from changes Make sure you include the full source (if you are using sbuild make sure to use the –source option or the equivalent configuration item; if you are using dpkg-buildpackage directly use the default flags or -S for a source only upload)
方案说的也很清楚哈。
gbp buildpackage --git-upstream-tree=upstream/1.5.0 --git-upstream-branch=upstream/1.5.0 --git-builder=sbuild -d unstable --git-debian-branch=debian/main --git-export-dir=../build-area/ --git-ignore-new --verbose
#!/usr/bin/make -f
export DH_VERBOSE = 1
export PYBUILD_NAME=git-multimail
%:
dh $@ --with python3 --buildsystem=pybuild
override_dh_auto_clean:
rm -rf .pytest_cache
dh_auto_clean
override_dh_auto_build:
PYTHONPATH=. http_proxy='127.0.0.1:9' python3 -m sphinx -N -bhtml doc/ build/html
override_dh_auto_test:
ifeq ($(filter nocheck,$(DEB_BUILD_PROFILES)),)
dh_auto_test
endif
https://sources.debian.org/src/util-linux/2.38-4/debian/rules/?hl=77#L77
TBD
export DH_VERBOSE = 1
export PYBUILD_SYSTEM=flit
# 使用与 setup.py不同的打包方式
%:
dh $@ --with python3 --buildsystem=pybuild
TBD