Bug#1061770: ipmitool: unsupported LAN parameter lookup command returns an error
control: severity -1 important > 2024年4月30日 13:37，Miao Wang 写道： > > Hi, all > > The ipmitool repo has been migrated to https://codeberg.org/IPMITool/ipmitool > and I have fixed this problem in the commit > https://codeberg.org/IPMITool/ipmitool/commit/137aeb > > I raised the severity because this bug makes ipmitool lan unusable on several > different platforms. I also hope maintainers can also backport this fix to the > current stable version. > > Cheers, > > Miao Wang
Bug#1061770: ipmitool: unsupported LAN parameter lookup command returns an error
Hi, all The ipmitool repo has been migrated to https://codeberg.org/IPMITool/ipmitool and I have fixed this problem in the commit https://codeberg.org/IPMITool/ipmitool/commit/137aeb I raised the severity because this bug makes ipmitool lan unusable on several different platforms. I also hope maintainers can also backport this fix to the current stable version. Cheers, Miao Wang
Bug#1068725: libnginx-mod-http-js contains unnecessary dependency
Package: libnginx-mod-http-js Version: 0.8.2-1+b1 Severity: normal Dear Maintainer, libnginx-mod-http-js contains a dependency on libnginx-mod-stream, which should be only necessary for libnginx-mod-stream-js. Cheers, Miao Wang
Bug#1028416: systemctl kexec doesn't shutdown system properly and corrupts mounted filesystems
Dear maintainer, I wonder if this fix can be backported to stable-pu and oldstable-pu, since this bug may lead to data corruption. A possible approach might be to mask the kexec init script in the systemd side, i.e. via `systemctl mask kexec.service`, so that systemd users can get rid of the kexec init script and other init system users can still enjoy the provided kexec init script. Cheers, Miao Wang
Bug#1055542: cannot build go packages with golang-github-containers-image-dev
Package: golang-github-containers-image-dev Version: 5.28.0-3 Severity: normal In 5.28.0-3 of golang-github-containers-image-dev, a patch is included to revert the upstream change updating x-exp-slices. However the package golang-golang-x-exp has been updated to 0.0~git20231006.7918f67-1 in debian recently, and as a result this package currently contains a function call which does not match the definition in golang-golang-x-exp and thus cannot be built. I suggest the patch `revert-x-exp-slices.patch` should be accordingly removed. Cheers, Miao Wang
Bug#1055285: libseccomp misbehave on loong64
Package: libseccomp2 Version: 2.5.4-1+loong64 Severity: normal Tags: patch libseccomp2 in debian ports lonng64 cannot work properly because it is using a wrong mapping between syscall numbers and names, which can be reproduced by first installing package seccomp and then execute: ``` scmp_sys_resolver accept ``` The syscall number in the output is not correct, which should be 202 on loong64 architecture. The root cause of this bug lies in the patch `add-loongarch64-support-from-libseccomp-upstream.patch` applied in the version 2.5.4-1+loong64: ``` --- libseccomp-2.5.4.orig/src/syscalls.csv +++ libseccomp-2.5.4/src/syscalls.csv @@ -1,4 +1,4 @@ -#syscall (v5.17.0 2022-04-05),x86,x86_64,x32,arm,aarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x +#syscall (v5.17.0 2022-04-05),x86,x86_64,x32,arm,aarch64,loongarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x accept,PNR,43,43,285,202,168,42,42,35,35,330,330,202,PNR,PNR accept4,364,288,288,366,242,334,293,297,320,320,344,344,242,364,364 access,33,21,21,33,PNR,33,20,20,33,33,33,33,PNR,33,33 ``` which only changes the header of the syscall table but fails to include syscall numbers for loong64 architecture. The result is that on loong64 architecture, the syscall number mapping for mips is actually in effect. All the mappings for architectures listed after mips are also wrong. Especially for s390x, when trying to convert between syscall names and numbers, memory overflow will happen and the output will be totally garbage. This issue prevents container manage applications such as Podman from working correctly on loong64 architecture. To fix this issue, correct syscall mapping should be introduced. The attached patch (on top of the original patch) should work. It also includes a fix for the tests so that the package can be built without nocheck. Cheers, Miao Wang Index: libseccomp-2.5.4/include/seccomp-syscalls.h === --- libseccomp-2.5.4.orig/include/seccomp-syscalls.h +++ libseccomp-2.5.4/include/seccomp-syscalls.h @@ -276,6 +276,7 @@ #define __PNR_renameat -10242 #define __PNR_riscv_flush_icache -10243 #define __PNR_memfd_secret -10244 +#define __PNR_fstat-10245 /* * libseccomp syscall definitions Index: libseccomp-2.5.4/src/syscalls.csv === --- libseccomp-2.5.4.orig/src/syscalls.csv +++ libseccomp-2.5.4/src/syscalls.csv @@ -1,482 +1,482 @@ #syscall (v5.17.0 2022-04-05),x86,x86_64,x32,arm,aarch64,loongarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x -accept,PNR,43,43,285,202,168,42,42,35,35,330,330,202,PNR,PNR -accept4,364,288,288,366,242,334,293,297,320,320,344,344,242,364,364 -access,33,21,21,33,PNR,33,20,20,33,33,33,33,PNR,33,33 -acct,51,163,163,51,89,51,158,158,51,51,51,51,89,51,51 -add_key,286,248,248,309,217,280,239,243,264,264,269,269,217,278,278 -adjtimex,124,159,159,124,171,124,154,154,124,124,124,124,171,124,124 -afs_syscall,137,183,183,PNR,PNR,137,176,176,PNR,PNR,137,137,PNR,137,137 -alarm,27,37,37,PNR,PNR,27,37,37,27,27,27,27,PNR,27,27 -arch_prctl,384,158,158,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR -arm_fadvise64_64,PNR,PNR,PNR,270,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR -arm_sync_file_range,PNR,PNR,PNR,341,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR -bdflush,134,PNR,PNR,134,PNR,134,PNR,PNR,134,134,134,134,PNR,134,134 -bind,361,49,49,282,200,169,48,48,22,22,327,327,200,361,361 -bpf,357,321,321,386,280,355,315,319,341,341,361,361,280,351,351 -break,17,PNR,PNR,PNR,PNR,17,PNR,PNR,PNR,PNR,17,17,PNR,PNR,PNR -breakpoint,PNR,PNR,PNR,983041,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR -brk,45,12,12,45,214,45,12,12,45,45,45,45,214,45,45 -cachectl,PNR,PNR,PNR,PNR,PNR,148,198,198,PNR,PNR,PNR,PNR,PNR,PNR,PNR -cacheflush,PNR,PNR,PNR,983042,PNR,147,197,197,PNR,PNR,PNR,PNR,PNR,PNR,PNR -capget,184,125,125,184,90,204,123,123,106,106,183,183,90,184,184 -capset,185,126,126,185,91,205,124,124,107,107,184,184,91,185,185 -chdir,12,80,80,12,49,12,78,78,12,12,12,12,49,12,12 -chmod,15,90,90,15,PNR,15,88,88,15,15,15,15,PNR,15,15 -chown,182,92,92,182,PNR,202,90,90,180,180,181,181,PNR,182,212 -chown32,212,PNR,PNR,212,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,212,PNR -chroot,61,161,161,61,51,61,156,156,61,61,61,61,51,61,61 -clock_adjtime,343,305,305,372,266,341,300,305,324,324,347,347,266,337,337 -clock_adjtime64,405,PNR,PNR,405,PNR,405,PNR,405,405,PNR,405,PNR,PNR,405,PNR -clock_getres,266,229,229,264,114,264,223,227,257,257,247,247,114,261,261 -clock_getres_time64,406,PNR,PNR,406,PNR,406,PNR,406,406,PNR,406,PNR,PNR,406,PNR -clock_gettime,265,228,228,263,113,263,222,226,256,256,246,246,113,260,260 -clock_gettime64,403,PNR,PNR,403,PNR,403,PNR,403,403,PNR,403,PNR,PNR,403,PNR -clock_nanosleep,267,230,230,265,115,265,224,228,258,258,248,248,115,262,262
Bug#1036533: Someone got really harmed by the moo
Package: iproute2 Version: 5.19.0-1 Severity: important I understand ip moo is added for fun by debian developers. However, in commit https://salsa.debian.org/kernel-team/iproute2/-/commit/4aace8c , an unexpected effect is introduced. Originally, ``moo" is listed at the end of the possible command list, which makes no difference on normal invocation. However, in this commit, ``moo" is listed after ``macsec", well before ``monitor". Those who use ``mo" as an abbreviation of ``monitor" are really harmed by this patch. I suggest ``moo" should be listed to the end, after ``help". Cheers, Miao Wang
Bug#973861: apt: http acquire method still failing with "Undetermined error" or "Data left in the buffer"
Hi, On Thu, 21 Jan 2021 15:27:40 + Witold Baryluk wrote: > Package: apt > Version: 2.1.18 > Followup-For: Bug #973861 > X-Debbugs-Cc: witold.bary...@gmail.com, mir...@init7.net > > I started getting this error recently too. > > To the point that using live-build (that downloads ~6100 package in one > go) is not possible, because some package will fail to download and fail > entire apt install request. > > > This is related to keepalive. > > For example most nginx server has keepalive_requests 100 by default. That > is, after serving 100 request, nginx server will close the connection. > This is because some dynamic memory allocated by nginx is allocated on > arenas that are tied to TCP connection, and they are never freed until > the connection is closed. This is a high performance design, but to > prevent leaks and abuse, the connection must be closed after some number > of requests. > > Most tools (wget), respect the response from the server, close the > existing connection and open a new one. It is easy to see with wget -i - > and feeding the same file 1 times. Every 100th request will start a > new TCP connection. > > > In apt this manifests as some XX00 request failing. > > Get:4500 http://mirror.init7.net/debian bullseye/main amd64 libplymouth5 > amd64 0.9.5-2 [108 kB] > Err:4500 http://mirror.init7.net/debian bullseye/main amd64 libplymouth5 > amd64 0.9.5-2 > Undetermined Error [IP: 2001:1620::1620 80] > > > Get:1600 http://mirror.init7.net/debian bullseye/main amd64 libastyle3 amd64 > 3.1-2+b1 [109 kB] > Err:1600 http://mirror.init7.net/debian bullseye/main amd64 libastyle3 amd64 > 3.1-2+b1] > Undetermined Error [IP: 2001:1620::1620 80] > > > > This is repeatable and reproducible. I can try 10 times doing the > download, and every time the same file and number will fail. (Sometimes I > might get lucky and one of them will succeed, but not ther other). > > I don't know why files 100, 200, 300, ... doesn't fail, but it looks like > some bug in apt in general. > > (The above files do exist and are served correctly by the server). > > > Does apt use maybe HTTP pipelining in addition to keepalive, that causes > issues? Or maybe in general the retry logic is broken somehow. > > I wasn't able to reproduce this issue with Fastly CDN or Apache 2.4, > probably because they use different keepalive request limit policy. It > might be a bug in nginx too. I am not sure. The server I was using > appears to be using nginx/1.14.2. I recently reported this issue to nginx developers and they have issued a fix for handling the close of pipelined connections. See: https://hg.nginx.org/nginx/rev/cffaf3f2eec8 > > Regards, Cheers, Miao Wang
Bug#1009313: RFS: nginx/1.18.0-10 -- small, powerful, scalable web/proxy server
> 2022年04月12日 15:33，Bastian Germann 写道： > > Am 12.04.22 um 05:00 schrieb Miao Wang: >> I intended to leave it UNRELEASED so it can serve as a request for comment. >> However, every time I upload an UNRELEASED package, it gets deleted >> automatically. As a result, I have to set the codename to unstable for >> successful uploading. > > You misunderstood. You left a -9 revision UNRELELEASED and skipped it while > publishing a -10 revision. Yes, it is intended, because currently the version number of nginx is -9 in https://salsa.debian.org/nginx-team/nginx/-/blob/master/debian/changelog . > > Do you say, you did not contact the nginx team upfront about this? If so, I > am going to close this and wait for you to get in contact with the team. I did contact nginx team via e-mail privately about 3 weeks ago and 3 days ago and hasn't received any reply. Cheers, Miao Wang
Bug#1009313: RFS: nginx/1.18.0-10 -- small, powerful, scalable web/proxy server
Hi, Thanks for your time on this package. I fully understand splitting the source package is a major change on the package scheme. I intended to leave it UNRELEASED so it can serve as a request for comment. However, every time I upload an UNRELEASED package, it gets deleted automatically. As a result, I have to set the codename to unstable for successful uploading. Cheers, Miao Wang > 2022年04月12日 04:24，Bastian Germann 写道： > > Control: tags -1 moreinfo > > Hi Miao, > > Please do not skip a version (or leave it UNRELEASED). If this is a team > upload (not in changelog...) and the team has confirmed splitting the > package, please reference the okay statement. Else, nobody will touch this > massive change. > > I am tagging moreinfo. When you have provided the requested info, please > untag. > > Thanks, > Bastian
Bug#1009313: RFS: nginx/1.18.0-10 -- small, powerful, scalable web/proxy server
urgency=medium . * Initial release. ngx-auth-pam (1:1.5.3-1) unstable; urgency=medium . * Initial release. ngx-ndk (1:0.3.1-1) unstable; urgency=medium . * Initial release. ngx-cache-purge (2.3-1) unstable; urgency=medium . * Initial release. ngx-subs-filter (1:0.6.4-1) unstable; urgency=medium . * Initial release. ngx-fancyindex (1:0.5.2-1) unstable; urgency=low . * Initial release. ngx-dav-ext (3.0.0-1) unstable; urgency=medium . * Initial release. ngx-lua (1:0.10.13-1) unstable; urgency=medium . * Initial release. Regards, Miao Wang
Bug#995567: Can't handle cross-signed Let's Encrypt CA
control: tag -1 + patch A fix has been merged by upstream. https://github.com/lavv17/lftp/commit/285c61c
Bug#992231: --delay-updates leaves stale partial data and causes files to never be updated
Package: rsync Version: 3.2.3-4 Severity: important Tags: patch, fixed-upstream Control: found -1 3.2.0-1 Dear Maintainer, I ran into a bug which prevents files in partial data directory from updated. I believe it is due to the upstream bug reported there: https://github.com/WayneD/rsync/issues/192 There have been fixes and backporting from upstream. I wonder if the patches can be applied to bullseye-pu and buster-backports? Cheers, Miao Wang
