Processed: Re: Bug#1021911: mailto:sub...@bugs.debian.org
Processing control commands: > block 1021911 by 502580 970827 Bug #1021911 [obfs4proxy] mailto:sub...@bugs.debian.org 1021911 was not blocked by any bugs. 1021911 was not blocking any bugs. Added blocking bug(s) of 1021911: 970827, 662845, and 502580 > retitle 1021911 obfs4proxy: preserve user capability overrides on upgrade Bug #1021911 [obfs4proxy] mailto:sub...@bugs.debian.org Changed Bug title to 'obfs4proxy: preserve user capability overrides on upgrade' from 'mailto:sub...@bugs.debian.org'. -- 1021911: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021911 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi Guillem, On 2022-11-13 11:04, Aurelien Jarno wrote: > Hi, > > On 2022-11-13 02:00, Guillem Jover wrote: > > Hi! > > > > On Sun, 2022-11-13 at 00:17:36 +0100, Aurelien Jarno wrote: > > > On 2022-11-12 22:28, Guillem Jover wrote: > > > > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo > > > > wrote: > > > > > Package: dpkg > > > > > Version: 1.21.9 > > > > > Severity: normal > > > > > X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org > > > > > > > > > After some investigation by aurel32 and myself, this was traced back > > > > > to the > > > > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > > > > calculation of > > > > > the memory that can be used, to determine the number of threads to > > > > > use, was > > > > > changed from half of the physical mem to be based on the memory > > > > > available. > > > > > > > > Ah, thanks for tracking this down! I think the problem is the usual > > > > "available" memory does not really mean what people think it means. :/ > > > > And I unfortunately missed that (even thought I was aware of it) when > > > > reviewing the patch. > > > > > > > > Attached is something I just quickly prepared, which I'll clean up and > > > > merge for the upcoming 1.21.10. Let me know if that solves the issue > > > > for you, otherwise we'd need to look for further changes. > > > > > > Thanks for providing a patch. I have not been able yet to try it for the > > > case where we have found the issue, i.e. building linux. However I have > > > tried to setup a similar environment: > > > > > - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and > > > very few > > > things running on it. > > > - I filled the tmpfs with 4 GB of random data, which means that after > > > moving the content of the tmpfs to the swap, 4 GB could still be used > > > without issue. > > > - I ended up with the following /proc/meminfo: > > > MemTotal:3951508 kB > > > MemFree: 130976 kB > > > MemAvailable: 10584 kB > > > Buffers:2448 kB > > > Cached: 3694676 kB > > > SwapCached:12936 kB > > > Active: 3111920 kB > > > Inactive: 610376 kB > > > Active(anon):3102668 kB > > > Inactive(anon): 606952 kB > > > Active(file): 9252 kB > > > Inactive(file): 3424 kB > > > Unevictable: 0 kB > > > Mlocked: 0 kB > > > SwapTotal: 4194300 kB > > > SwapFree:3777400 kB > > > Zswap: 0 kB > > > Zswapped: 0 kB > > > Dirty: 0 kB > > > Writeback: 0 kB > > > AnonPages: 12960 kB > > > Mapped: 6700 kB > > > Shmem: 3684416 kB > > > KReclaimable: 27616 kB > > > Slab: 54652 kB > > > SReclaimable: 27616 kB > > > SUnreclaim:27036 kB > > > KernelStack:2496 kB > > > PageTables: 1516 kB > > > NFS_Unstable: 0 kB > > > Bounce:0 kB > > > WritebackTmp: 0 kB > > > CommitLimit: 6170052 kB > > > Committed_AS:4212940 kB > > > VmallocTotal: 34359738367 kB > > > VmallocUsed: 16116 kB > > > VmallocChunk: 0 kB > > > Percpu: 2288 kB > > > HardwareCorrupted: 0 kB > > > AnonHugePages: 0 kB > > > ShmemHugePages:0 kB > > > ShmemPmdMapped:0 kB > > > FileHugePages: 0 kB > > > FilePmdMapped: 0 kB > > > HugePages_Total: 0 > > > HugePages_Free:0 > > > HugePages_Rsvd:0 > > > HugePages_Surp:0 > > > Hugepagesize: 2048 kB > > > Hugetlb: 0 kB > > > DirectMap4k: 110452 kB > > > DirectMap2M: 5132288 kB > > > DirectMap1G: 5242880 kB > > > > > With the current version of dpkg, it means it consider 10584 kB are > > > available > > > (not however that there is 130976 kB of unused physical RAM). With your > > > patch, > > > it's a bit better, as it would be 123408 kB. Still far less that one the > > > VM is > > > capable of. > > > > Err sorry, the patch was computing the used memory and not the truly > > available one! The updated patch should do better. :) > > Thanks for the updated patch. Computing the available memory manually > from the above values sounds like it should work, so I'll give it a try. I have run a build of the linux package on a buildd with your patch, and I confirm it fixes the issue. Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages
On Mon, 2022-11-14 at 13:38:30 +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Guillem Jover (2022-11-14 13:17:34) > > On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote: > > > The way I chopped dpkg-checkbuilddeps was a first approximation. Given > > > that now we have `apt-get satisfy`, my next step would be to have my > > > hacked version print a list of arguments for it, which can include > > > "Conflicts:", but which can already be preprocessed to reduce some noise > > > like packages required or not required from the target architecture. > > > > Ah, so from this I gather that in essence what we need is a way to map > > from build-dependencies into run-time dependencies, removing/filtering > > them from anything that is not accepted in the latter. That makes > > sense and does not seem to have the concerns of the previously filed > > bug request, as that required performing decisions in a layer too low > > where that required information was not available. > > > > I could see gathering any build-dependency fields as restricted by > > (-A/-B/-I), remapping them based on current arch/profile, then > > outputting them as a pair of Depends/Conflicts fields (perhaps even > > an Architecture field if there was arch-restrictions applied?). For > > «apt satisfy» you might need to trim the «Depends: » part though. > > > > Would that work for you? I think it would work for pbuilder. > > > > > More generally, I'd like Debian to have, as a standard, something > > > similar to `rpmspec --parse filename.spec | grep BuildRequires` > > > because I see it reimplemented so many times (pbuilder, sbuild, and so > > > on) that my instincts screams invoking the rule of three and > > > refactor[2]. > > > > I think the above would solve your problem, and potentially could > > substantially reduce the code in pbuilder-satisfydepends. For sbuild > > and mk-build-deps (devscripts), which are already in perl, that would > > only potentially help if this is included as part of a public module. > > So I'll be going that way in case they want to (eventually) switch. > > As far as I can see, this additional feature will not break anything in > sbuild, > so I think I was CC-ed because the question is whether sbuild can use this? In > an earlier mail, Enrico writes: Sorry, probably the phrasing and placement of my reply made this unclear, with above I meant my previous reply, where I was referring to adding new code in a module to handle this mapping, the bulk of that mapping is already being done by deps_parse(), so I was thinking something a bit more higher-level, but I've not checked the various implementations (including the ones within dpkg-dev), whether they'd benefit from something more higher-level than deps_parse(). I'd imagine something taking a source deb822 control stanza from debian/control or the entire thing, and then mapping build-dependencies in there into Depends and Conflicts (according to some selectable criteria or similar). Thanks, Guillem
Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages
Hello everybody! :) Quoting Guillem Jover (2022-11-14 13:17:34) > [ CCing devscripts, pbuilder and sbuild, as this is about some > potential functionality refactoring. ] thank you! > On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote: > > On Sat, Nov 12, 2022 at 09:30:43PM +0100, Guillem Jover wrote: > > > There was a bug filed requesting adding custom output format support > > > (#214566) but it was closed “recently”. I think there might be some > > > value in that, but not for the intended use the submitters seemed > > > to want it. > > > > > > I'd be interested to know how you'd want to use this new output/option > > > as from the PoC script you provide it is not obvious to me, as it > > > prints both build-depends and build-conflicts in an indistinguishable > > > way, and it includes version constraints and alternative dependencies. > > > > My specific use case at the moment is setting up a container > > *description* (not a container) with all the dependencies I need to do > > development on a package[1]. > > > > I could run apt-get build-dep inside the container and get the > > development environment installed, but then I lose the ability of being > > able to describe it in a terse way, and I can only do something along > > the lines of listing all installed packages in the container and their > > versions, which is too noisy for an average bug report. > > Ok, so basing this description on .buildinfo would not seem to be > satisfactory then. > > > The way I chopped dpkg-checkbuilddeps was a first approximation. Given > > that now we have `apt-get satisfy`, my next step would be to have my > > hacked version print a list of arguments for it, which can include > > "Conflicts:", but which can already be preprocessed to reduce some noise > > like packages required or not required from the target architecture. > > Ah, so from this I gather that in essence what we need is a way to map > from build-dependencies into run-time dependencies, removing/filtering > them from anything that is not accepted in the latter. That makes > sense and does not seem to have the concerns of the previously filed > bug request, as that required performing decisions in a layer too low > where that required information was not available. > > I could see gathering any build-dependency fields as restricted by > (-A/-B/-I), remapping them based on current arch/profile, then > outputting them as a pair of Depends/Conflicts fields (perhaps even > an Architecture field if there was arch-restrictions applied?). For > «apt satisfy» you might need to trim the «Depends: » part though. > > Would that work for you? I think it would work for pbuilder. > > > More generally, I'd like Debian to have, as a standard, something > > similar to `rpmspec --parse filename.spec | grep BuildRequires` > > because I see it reimplemented so many times (pbuilder, sbuild, and so > > on) that my instincts screams invoking the rule of three and > > refactor[2]. > > I think the above would solve your problem, and potentially could > substantially reduce the code in pbuilder-satisfydepends. For sbuild > and mk-build-deps (devscripts), which are already in perl, that would > only potentially help if this is included as part of a public module. > So I'll be going that way in case they want to (eventually) switch. As far as I can see, this additional feature will not break anything in sbuild, so I think I was CC-ed because the question is whether sbuild can use this? In an earlier mail, Enrico writes: > More generally, I'd like Debian to have, as a standard, something > similar to `rpmspec --parse filename.spec | grep BuildRequires` > because I see it reimplemented so many times (pbuilder, sbuild, and so > on) that my instincts screams invoking the rule of three and > refactor[2]. I like to remove code so that I don't have to care about it anymore. But I don't understand which part of sbuild can be replaced by this. Enrico, can you explain? Thanks! cheers, josch signature.asc Description: signature
Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages
Hi! [ CCing devscripts, pbuilder and sbuild, as this is about some potential functionality refactoring. ] On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote: > On Sat, Nov 12, 2022 at 09:30:43PM +0100, Guillem Jover wrote: > > There was a bug filed requesting adding custom output format support > > (#214566) but it was closed “recently”. I think there might be some > > value in that, but not for the intended use the submitters seemed > > to want it. > > > > I'd be interested to know how you'd want to use this new output/option > > as from the PoC script you provide it is not obvious to me, as it > > prints both build-depends and build-conflicts in an indistinguishable > > way, and it includes version constraints and alternative dependencies. > > My specific use case at the moment is setting up a container > *description* (not a container) with all the dependencies I need to do > development on a package[1]. > > I could run apt-get build-dep inside the container and get the > development environment installed, but then I lose the ability of being > able to describe it in a terse way, and I can only do something along > the lines of listing all installed packages in the container and their > versions, which is too noisy for an average bug report. Ok, so basing this description on .buildinfo would not seem to be satisfactory then. > The way I chopped dpkg-checkbuilddeps was a first approximation. Given > that now we have `apt-get satisfy`, my next step would be to have my > hacked version print a list of arguments for it, which can include > "Conflicts:", but which can already be preprocessed to reduce some noise > like packages required or not required from the target architecture. Ah, so from this I gather that in essence what we need is a way to map from build-dependencies into run-time dependencies, removing/filtering them from anything that is not accepted in the latter. That makes sense and does not seem to have the concerns of the previously filed bug request, as that required performing decisions in a layer too low where that required information was not available. I could see gathering any build-dependency fields as restricted by (-A/-B/-I), remapping them based on current arch/profile, then outputting them as a pair of Depends/Conflicts fields (perhaps even an Architecture field if there was arch-restrictions applied?). For «apt satisfy» you might need to trim the «Depends: » part though. Would that work for you? I think it would work for pbuilder. > More generally, I'd like Debian to have, as a standard, something > similar to `rpmspec --parse filename.spec | grep BuildRequires` > because I see it reimplemented so many times (pbuilder, sbuild, and so > on) that my instincts screams invoking the rule of three and > refactor[2]. I think the above would solve your problem, and potentially could substantially reduce the code in pbuilder-satisfydepends. For sbuild and mk-build-deps (devscripts), which are already in perl, that would only potentially help if this is included as part of a public module. So I'll be going that way in case they want to (eventually) switch. I've pondered for a while to add a dpkg-deb822 to parse and manipulate control data, but perhaps something more specific to source packages would be helpful too, where people want to query the list of binary packages to build (dh_listpackages) and similar stuff, but that's for later. :) Thanks, Guillem
Bug#1023486: Re: Bug#1023486: Please add loong64 support to dpkg
Dear Guillem, > I think the part that was missing, which was asked on the list, and a > rather important part of this! :) Is the ABI this conforms to. > > I'm attaching a patch that updates the test suite so that it passes, > and adds what I think (but I don't know as I didn't check deeper) might > change the ABI for built objects, which ties into the ABI this > architecture is intended to conform to. > > I guess the main question is whether objects with these different > EF_LOONGARCH_* flags can be mixed when linking or they are ABI > incompatible, as the code in the patch now assume. 1、The value of ELF_FLAGS_LOONGARCH_* flags (you provided) conform to the loongarch ABI standard. 2、After confirmation, the following three ELF_FLAG_LOONGARCH_* can not be mixed when linking，Because of different ABIs do not allow linking, otherwise an error will occur. As follows, ELF_FLAG_LOONGARCH_SOFT_FLOAT => 0x0001, // soft float ELF_FLAG_LOONGARCH_SINGLE_FLOAT => 0x0002, // single float ELF_FLAG_LOONGARCH_DOUBLE_FLOAT => 0x0003, // double float thanks, Dandan Zhang > -原始邮件- > 发件人: "Guillem Jover" > 发送时间:2022-11-11 19:51:54 (星期五) > 收件人: "张丹丹" , 1023...@bugs.debian.org > 抄送: > 主题: Re: Bug#1023486: Please add loong64 support to dpkg > > Hi! > > On Sat, 2022-11-05 at 18:08:03 +0800, 张丹丹 wrote: > > Package: dpkg > > Version: 1.21.10 > > Severity: wishlist > > Tags: patch > > User: debian-de...@lists.debian.org > > Usertags: loongarch64 > > > According to the result of disscussion from > > debian-d...@lists.debian.org(https://lists.debian.org/debian-dpkg/2022/11/msg1.html), > > guil...@debian.org, hel...@subdivi.de, *@loongson.cn and so on. > > Dpkg architecture of loong64 just determine the name of the software > > packages. > > Should add loong64 architecture to dpkg package? > > > > - Add support for loongarch64 CPU. > > Here is a simple patch to dpkg for the loongarch64. > > Please download from attachment. > > > > - Have an official GNU triplet in the GNU config project. > > https://git.savannah.gnu.org/cgit/config.git/commit/?id=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f > > > > - GNU binutils, gcc, and the respective libc project have merged by > > upstream. > > Binutils: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch > > Gcc: https://gcc.gnu.org/gcc-12/changes.html > > Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html > > > > > > - Please tell me if I've missed something. > > I think the part that was missing, which was asked on the list, and a > rather important part of this! :) Is the ABI this conforms to. > > I'm attaching a patch that updates the test suite so that it passes, > and adds what I think (but I don't know as I didn't check deeper) might > change the ABI for built objects, which ties into the ABI this > architecture is intended to conform to. > > I guess the main question is whether objects with these different > EF_LOONGARCH_* flags can be mixed when linking or they are ABI > incompatible, as the code in the patch now assume. > > Thanks, > Guillem 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. From bd0462298d5cf833ab47b0124ca470d0e156d902 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Fri, 11 Nov 2022 12:43:38 +0100 Subject: [PATCH] arch: Add support for loong64 CPU MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is based on the LoongArch 64-bit little-endian hard-float ISA. Closes: #1023486 Based-on-patch-by: å¼ ä¸¹ä¸¹ --- data/cputable | 1 + scripts/Dpkg/Shlibs/Objdump.pm | 9 + scripts/t/Dpkg_Arch.t | 4 ++-- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/data/cputable b/data/cputable index 172cea3f5..7b1ee2c58 100644 --- a/data/cputable +++ b/data/cputable @@ -26,6 +26,7 @@ arm arm arm.* 32 little arm64 aarch64 aarch64 64 little avr32 avr32 avr32 32 big hppa hppa hppa.* 32 big +loong64 loongarch64 loongarch64 64 little i386 i686 (i[34567]86|pentium) 32 little ia64 ia64 ia64 64 little m32r m32r m32r 32 big diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm index baeb8bb5c..9deedb4b4 100644 --- a/scripts/Dpkg/Shlibs/Objdump.pm +++ b/scripts/Dpkg/Shlibs/Objdump.pm @@ -101,6
