如果是 upload mentor，需要做以下内容： 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 = .*
DM 的操作可以参考这里 DM
[ftp-master]
fqdn = ftp.upload.debian.org
incoming = /pub/UploadQueue/
login = anonymous
allow_dcut = 1
method = ftp
Source only upload:
debsign -k 0xE2521CB8175736A97052B2F8954E6A70100598A2 xdoctest_1.1.2-1_source.changes
dput ftp-master xdoctest_1.1.2-1_source.changes
在正式 upload 之前，请确保以下内容:
autopkgtest 是根据DEP8制定的，本文简单记录下这块的相关用法。
或者还可以参考这个教程 https://hackmd.io/@fourdollars/By26b5au8
为了与线上的环境一致，推荐使用 debci的方式。
使用qemu创建相关的镜像:
sudo autopkgtest-build-qemu unstable autopkgtest-unstable.img --mirror=https://mirror.iscas.ac.cn/debian/
--mirror是根据自己的情况指定相关的mirror,加快速度。那么使用的时候：
autopkgtest gdk-pixbuf -- qemu autopkgtest-unstable.img
其中，gdk-pixbuf是你想测试的package。
sudo autopkgtest --apt-upgrade ./xx.dsc -- schroot sid-riscv64-sbuild
1. $ sudo apt install debci autopkgtest lxc lxc-templates
2. sudo adduser YOUR_USERNAME debci
3. sudo debci setup 或者
sudo env debci_mirror=https://mirrors.tuna.tsinghua.edu.cn/debian debci setup(可选)
# 更新源，加速
其中， lxc-templates 尤为关键，否则会报找不到 debian template的错误。
还有一个快速验证 autopkgtest 的 命令:
sudo autopkgtest-build-lxc debian testing riscv64
sudo autopkgtest file_5.38-4.dsc -- lxc autopkgtest-unstable-riscv64
running:
$ autopkgtest --user debci --output-dir /tmp/output-dir . \
-- lxc --sudo autopkgtest-unstable-amd64
其中.代表源代码的位置。
autopkgtest --user debci --output-dir /tmp/output-dir \
/path/to/PACKAGE_x.y-z_amd64.changes \
-- lxc --sudo autopkgtest-unstable-amd64
可选 --add-apt-source='deb https://mirror.iscas.ac.cn/debian/ sid main '
sudo lxc-destory autopkgtest-unstable-riscv64
ls /var/lib/lxc/
autopkgtest-unstable-riscv64
在autopkgtest中，原生的warning会被认为FAIL,所以我们在处理这样的情况时(没有warning最好)，可以使用
Restrictions: allow-stderr
进行约束解除。
这里有一个页面展示了 experimential 的 autopkgtest 的情况 ： https://release.debian.org/britney/pseudo-excuses-experimental.html
sudo lxc-destroy -n autopkgtest-unstable-riscv64
好多东西都放在了#debian-riscv下面，为了自己查找方便，暂且这样吧。
transitions是debian为了减少或者为了阻止因为library 版本变化而引起依赖这个lib其他debian 包构建失败的情况，故有这么个transitions的机制。
第一点就是一个巨大的难点对于新手来说，这个后面还需要更进一步总结。
the message是一个很好的学习case：
The old libwmf0.2-7 package contains the same SONAMEs as the combination of the new libwmf-0.2-7 and libwmflite-0.2-7 packages.If the new library is genuinely compatible with the old library, then I think a better way to do this would be to introduce an empty, transitional package with the old name libwmf0.2-7. This shouldn’t require going through the NEW queue again, because libwmf0.2-7 still exists in unstable.
Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: transition
Hello,
I would like to request a transition slot for openmm
(experimental -> unstable) due to soname bump. Current ben tracker [1]
is OK, all reverse dependencies build fine.
Thanks,
Andrius
[1] https://release.debian.org/transitions/html/auto-openmm.html
具体讲一下我自己的事例就行： 我在Debian中首先维护的一个package就做 jimtcl
看到没， 他还有一个-dev的package。 dev就是我们所谓的开发SDk，这种情况一般都是让外部package使用的。
所以，如果我由0.79直接升级到0.81是不行的，因为这里面可能会涉及到api的改变，那么，所有依赖jimtcl的package能不能编译成功还真不一定保证。而包的维护者一定要注意这个情况可能发生的情况，要坚决避免或者把所有的问题close掉才可以。
exp;auto-yourpackage 时，你最好使用ratt这个package把所有依赖你的包的包都使用你上传到exp的package进行构建，如果没有问题，则可以向release team发送请求了:补充说明: 1 步应该是可以这样的， 如果依赖你这个包比较少的情况下， 甚至可以提前自己在本地local build， 然后分别性的针对每一个反向依赖进行rebuild， 有问题的话发 issue 通知 maintainer; 没有问题的话最好。
直接上传到 exp也好， 有问题的话可以让对应的 maintainer 随时查看.
如上文所示即可
From: Debian testing watch <[email protected]>
To: [email protected]
Subject: jimtcl 0.81+dfsg0-2 MIGRATED to testing
FYI: The status of the jimtcl source package
in Debian's testing distribution has changed.
Previous version: 0.79+dfsg0-3
Current version: 0.81+dfsg0-2
这就可以了。
当然，我维护这个jimtcl还是有一定曲折的。
我们根据这个 1011630来复盘一下这个已经完成的 transiton.
接下来不用管， 等一两天的话， 他的反向依赖会自动 rebuild, 等一切ok， 要注意跟踪构建结果。
我觉得是得你的包 transate into testing后， 就可以告诉 release team
因为项目需要，目前需要让大佬能够登录自己的unmatched board，但是呢，目前没有一个公网ip。后来pabs提议说可以尝试一下ipv6.所以，我就看了一下ipv6，说实在的，这还是我第一次接触ipv6. Lol
我目前的情况是： 光猫接过来的ip是自带ipv6地址的，也就是电脑直接接上光猫后就可以看见ipv6的地址。但是路由器接过来的地址就检测不到。网上有消息说，路由器这端需要pppoe拨号入网，但是我给中国移动打电话，他们说pppoe的方式已经不支持了….也就是路由器这边我暂时用不了ipv6.
相关的几个帖子：
现在的一个问题是：
尽管我使能了ipv6，但是国外的ipv6进不来。上面的帖子也说了：
1.
所有的家用网关都默认屏蔽了入站流量，不论 v4 还是 v6 ，不然你暴露在公网天天被人黑么？
防火墙打开 wan 侧访问就可以了。
2.
7
FstarKing
OP
143 天前
@Remember 这个入站流量，是在路由器上屏蔽了吗？我的是小米路由器，比较老的一个了，好像没有看到可以做这个配置的地方
Remember 8
Remember 143 天前
@FstarKing 那就是他家固件没开放给你自定义，看看能不能刷个 openwrt ，就有了。 或者看看有没有 dmz ，不过 dmz 似乎时针对 v4 设置的，我不确定 v6 能不能生效。
FstarKing 9
FstarKing
OP
143 天前
@Remember 小米 ax1200 usb 口都没有，openwrt 是搞不了了，dmz 好像有，不过 dmz 配置的时候输入的确实是 v4 地址
Remember 10
Remember 143 天前
一般运营商会给你路由器本身一个 /64 地址,再给一个 /56 的地址供路由器往下分，这两个地址是不同的，所以你端口转发，dmz 这些应该都应用不到 v6 上面，还是得在固件里打开 ipv6 防火墙，或者用 ip6tables 手动设置。
@FstarKing 你搜 openwrt ipv6 防火墙 , 恩山一堆帖子，或者类似这帖子 https://rongrongbq.moe/2021/08/firewall-and-DDNS-settings-for-IPv6/，也是跟你一样的需求, 总之需要一个可以打开 v6 防火墙的固件, 然后不论是 web 里面或者是 ip6tables 设置好就可以。
至于 /64 /56 那是 ipv6 地址分配方式，你想研究就 Google 运营商 ipv6 分配 类似的关键词.
log中提到的链接在这里. 以上log所有权归原网站所有。
很明显，我的ipv6入站流量被移动关闭了.
这里有几个非常棒的帖子. 不过对于我这种小白需要几个概念搞明白。 这里更是有一份巨精彩的中文教程.
光纤到户（英语：Fiber To The Home，缩写：FTTH）是一种光纤通信的传输方法,来自维基百科
不知道为什么我这里的安装师傅说不支持pppoe的接入方式(他们也不懂的)。再次看了一下我家的光猫，是吉比特无源光纤接入设备,是有一个usb的口，但是不知道怎么用。
连接名称 连接状态 IP地址 IPv6默认网关
2_INTERNET_R_VID_38 已连接 2409:8a20:2e0e:7e89:2ad1:b7ff:fefe:c8eb/64 fe80::427c:7dff:fed8:6b03
连接名称 前缀获取方式 IP获取方式
2_INTERNET_R_VID_38 自动 PPPoE
连接名称 VLAN/优先级 MAC地址
2_INTERNET_R_VID_38 38/0 28:d1:b7:fe:c8:e6
连接名称 IPv6首选DNS IPv6备用DNS 前缀
2_INTERNET_R_VID_38 2409:8020:2000::8 2409:8020:2000::88 2409:8a20:2ee7:15a0::/60
目前 阿里云那边也是巨坑： 使能IPV6居然另外收费。
2023年7月23日 riscv64 在Debian成为官方支持的架构，这将会大大降低使用 riscv64 硬件的门槛。
如果你依然有装 Debian 到 Unmatched 的需求，请参看
Unmatched Debian Prebuilt images
按照该 repo 的 README 操作即可。
有任何问题请联系我, 谢谢~
On July 23, 2023, riscv64 became an officially supported architecture in Debian, which will greatly lower the threshold for using riscv64 hardware.
If you still need to install Debian to Unmatched, please see
Unmatched Debian Prebuilt images
Just follow the README of the repo.
If you have any questions, please let me know, thank you~
目前，firefox局部升级确实遇到一些困难，不过，好消息是，社区目前正式承认这个问题。
以下内容是我打包过程中遇到的一些raw data，供后面学习、复盘时使用。
===========>&==========
the right way to update is cargo update -p nix, then ./mach vendor rust But since nix is probably used by some other dependency, you probably need to update that as well It seems nix is used by alsa and midir So you’d need to update it in those crates
for reference, the minimal patch to update nix locally would be this: 0001-Update-nix…patch (1004.5 KB) vimer: ^, that’s on central, but the important changes are in the top level Cargo.toml then in the individual crates that use nix vimer: but the right thing to do is to send PRs to the relevant crates and then update them in Gecko That is, send a PR updating nix in https://github.com/mozilla/midir, https://github.com/mozilla/alsa and https://github.com/msirringhaus/minidump_writer_linux
Oh, that is cool. thank you very!!!
emilio
You can probably do the local thing for now, and send the PR so that when we update those crates we update nix as well
vimer
I will send PR as you said
emilio
Sweet, thanks!
msirringhaus
vimer
I will send PR as you said
For the record: minidump_writer_linux is already on nix 0.23, but it’s not yet vendored in the FF-tree.
vimer
msirringhaus: Ok, will notice it.
BTW, Where is FF-tree source code pubilc? I google a lot but nothing :-(
msirringhaus
vimer
msirringhaus: Ok, will notice it.
There has been some changes to it lately that need proper testing. I have handed over ownership of the crate to a newly created rust-minidump org (but I’m still involved). If you want to vendor it with the nix-dependency, either open an issue there (the link above will redirect correctly) and/or hop over to #crashreporting:mozilla.org
vimer
BTW, Where is FF-tree source code pubilc? I google a lot but nothing :-(
https://hg.mozilla.org/
hg.mozilla.org index
hg.mozilla.org repository index
emilio
also https://searchfox.org for a searchable version
vimer
The url it reports: ERR_CONNECTION_CLOSED from hg
emilio
The trunk repo is https://hg.mozilla.org/mozilla-central/
mozilla-central summary
A summary of repository state for mozilla-central
See https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#clone-the-sources
Firefox Contributors’ Quick Reference — Firefox Source Docs documentation
» Working on Firefox » Firefox Contributors’ Quick Reference Report an issue / View page source Firefox Contributors’ Quick Reference¶ Some parts of this process, including cloning and
vimer
Ok, will look into. Thank all again
=========&>========
build/moz.configure/toolchain.configure.
../../../../../config/nsinstall -R -m 644 'libipcclientcerts.so' '../../../../../dist/bin'
make[5]: Leaving directory '/home/vimer/build/firefox/build-browser/security/manager/ssl/ipcclientcerts/dynamic-library'
^[[B^[[B
clang: error: unable to execute command: Killed
clang: error: linker command failed due to signal (use -v to see invocation)
make[5]: *** [/home/vimer/build/firefox/config/rules.mk:531: libxul.so] Error 254
make[5]: Leaving directory '/home/vimer/build/firefox/build-browser/toolkit/library/build'
make[4]: *** [/home/vimer/build/firefox/config/recurse.mk:72: toolkit/library/build/target] Error 2
make[4]: Leaving directory '/home/vimer/build/firefox/build-browser'
make[3]: *** [/home/vimer/build/firefox/config/recurse.mk:34: compile] Error 2
make[3]: Leaving directory '/home/vimer/build/firefox/build-browser'
make[2]: *** [/home/vimer/build/firefox/config/rules.mk:352: default] Error 2
make[2]: Leaving directory '/home/vimer/build/firefox/build-browser'
dh_auto_build: error: cd build-browser && make -j16 LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code 2
make[1]: *** [debian/rules:256: stamps/build-browser] Error 255
make[1]: Leaving directory '/home/vimer/build/firefox'
make: *** [debian/rules:351: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2