Bug#1076564: pahole BTF processing seems flaky on powerpc
On Sat, Jul 20, 2024 at 09:16:24AM +0200, John Paul Adrian Glaubitz wrote: > Hi Domenico, Hi! > On Fri, 2024-07-19 at 23:20 +0200, Domenico Andreoli wrote: > > > > Is there anything I can do to help? > > > > > > From the 6.10-1~exp1: > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1 > > > file: > > > > > > + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j > > > --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func > > > --lang_exclude=rust .tmp_vmlinux.btf > > > > > > Can I have access to that .tmp_vmlinux.btf file so that I can try to > > > reproduce it here? > > > > I don't have access to the build host (blaauw2) and I've some doubts > > it would still have that file. > > > > Maybe our kernel team and powerpc porters have suggestions? > > I have root access to all powerpc/ppc64 machines (buildds and porterbox). > > I'm cleaning up the porterbox now, disk is quite full, then you can try > to build the kernel package on perotto.debian.net or I can try it myself. > > I have seen the bug myself and I wanted to debug it, but the attempt was > foiled by the fact that the disk on perotto is full (again). > > Will take care of it and let you know when it's (some hours). That's great, thank you. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1076564: pahole BTF processing seems flaky on powerpc
CCing debian-kernel and debian-powerpc On Fri, Jul 19, 2024 at 04:13:00PM -0300, Arnaldo Carvalho de Melo wrote: > Adding Alan and Jiri to the CC list. > > On Fri, Jul 19, 2024 at 08:53:24AM +0200, Domenico Andreoli wrote: > > Hi Arnaldo, > > > > On Thu, Jul 18, 2024 at 11:56:09PM +0200, Ben Hutchings wrote: > > > Package: pahole > > > Version: 1.27-1 > > > Severity: normal > > > X-Debbugs-Cc: debian-ker...@lists.debian.org > > > > > > Several kernel builds on powerpc have failed recently: > > > > > > 6.8.12-1: > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717234422&raw=1 > > > 6.9.9-1: > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.9-1&stamp=1720906547&raw=1 > > > 6.10-1~exp1: > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1 > > > > > > Note, these log files are up to 270 MB in size and should be > > > downloaded; at least Firefox becomes unresponsive when trying to > > > display them. > > > > > > For each of these, the failure seems to start with an error from > > > pahole such as: > > > > > > [102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 > > > Error emitting BTF type > > > Encountered error while encoding BTF. > > > > Does the above error ring any bell? > > Nope > > > Is there anything I can do to help? > > From the 6.10-1~exp1: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1 > file: > > + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j > --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func > --lang_exclude=rust .tmp_vmlinux.btf > > Can I have access to that .tmp_vmlinux.btf file so that I can try to > reproduce it here? I don't have access to the build host (blaauw2) and I've some doubts it would still have that file. Maybe our kernel team and powerpc porters have suggestions? Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1076564: pahole BTF processing seems flaky on powerpc
On Fri, Jul 19, 2024 at 08:53:24AM +0200, Domenico Andreoli wrote: > Hi Arnaldo, > > On Thu, Jul 18, 2024 at 11:56:09PM +0200, Ben Hutchings wrote: > > Package: pahole > > Version: 1.27-1 > > Severity: normal > > X-Debbugs-Cc: debian-ker...@lists.debian.org > > > > Several kernel builds on powerpc have failed recently: > > > > 6.8.12-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717234422&raw=1 > > 6.9.9-1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.9-1&stamp=1720906547&raw=1 > > 6.10-1~exp1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1 > > > > Note, these log files are up to 270 MB in size and should be > > downloaded; at least Firefox becomes unresponsive when trying to > > display them. > > > > For each of these, the failure seems to start with an error from > > pahole such as: > > > > [102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 Error > > emitting BTF type > > Encountered error while encoding BTF. > > Does the above error ring any bell? > > Is there anything I can do to help? > Additional info Debian package 1.26-1 has no patches applied, 1.27-1 instead has the following backports: https://salsa.debian.org/debian/dwarves/-/blob/debian/1.27-1/debian/patches/00-core-Initialize-cu_node-with-INIT_LIST_HEAD.patch https://salsa.debian.org/debian/dwarves/-/blob/debian/1.27-1/debian/patches/01-dwarf_loader-Add-missing-cus__add-to-cus__merge_and_process_cu.patch Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Arnaldo, On Thu, Jul 18, 2024 at 11:56:09PM +0200, Ben Hutchings wrote: > Package: pahole > Version: 1.27-1 > Severity: normal > X-Debbugs-Cc: debian-ker...@lists.debian.org > > Several kernel builds on powerpc have failed recently: > > 6.8.12-1: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717234422&raw=1 > 6.9.9-1: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.9-1&stamp=1720906547&raw=1 > 6.10-1~exp1: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1 > > Note, these log files are up to 270 MB in size and should be > downloaded; at least Firefox becomes unresponsive when trying to > display them. > > For each of these, the failure seems to start with an error from > pahole such as: > > [102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 Error > emitting BTF type > Encountered error while encoding BTF. Does the above error ring any bell? Is there anything I can do to help? > > This does *not* happen consistently. Compare these successful > builds: > > 6.8.12-1: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717278092&raw=1 > - This same version failed to build on the first try. > 6.9.7-1: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.7-1&stamp=1719538806&raw=1 > - Earlier and later 6.9.x versions failed to build. > > Both pahole versions 1.26-1 and 1.27-1 have been used in both > successful and failing builds. > > Ben. > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, > 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), > (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), > (500, 'stable'), (500, 'oldstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.9.9-amd64 (SMP w/12 CPU threads; PREEMPT) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages pahole depends on: > ii libbpf1 1:1.4.3-1 > ii libc6 2.39-4 > ii libdw1t64 0.191-2 > ii libelf1t64 0.191-2 > ii zlib1g 1:1.3.dfsg+really1.3.1-1 > > pahole recommends no packages. > > pahole suggests no packages. > > -- debconf-show failed -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1071963: RM: oci-seccomp-bpf-hook [ppc64el] -- RoQA; FTBFS on ppc64el
Package: ftp.debian.org Severity: normal X-Debbugs-CC: team+pkg...@tracker.debian.org As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070768, bpfcc/0.29.1+ds-1.1 recently dropped support for ppc64el. I uploaded a new version of oci-seccomp-bpf-hook too soon and it was built also for ppc64el. Now this is preventing the migration to testing. Please remove the oci-seccomp-bpf-hook ppc64el. Thanks, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1065134: Packaging of pahole
Somehow this email did not reach the destinations, trying once more... On Tue, Mar 05, 2024 at 06:04:37PM +0100, Domenico Andreoli wrote: > Hi, > > I'm eventually acknowledging that I'm poorly suited as maintainer > of the dwarves package. I don't follow its development and don't use > it either. > > Thomas as well is asking to be removed from the uploaders, pending > signed request. [0] > > Before opening an RFA, is this team interested in taking over the > maintenance? I think it's mostly used by the kernel build, I'm not > aware of any other users. > > Regards, > Domenico > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065134#15 -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1065134: dwarves: Please package new upstream release and confirm contact info
On Mon, Mar 04, 2024 at 05:39:38PM +0100, Thomas Girard wrote: > Hello, Hi, > Could you please remove me from Uploaders? I don't have time for Debian at > the moment. Ok for me but could you send this again with a proper signature please? Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1065134: dwarves: Please package new upstream release and confirm contact info
On Thu, Feb 29, 2024 at 10:38:45PM -0500, Boyuan Yang wrote: > Source: dwarves > Version: 1.24-4.1 > Severity: normal > X-Debbugs-CC: ca...@debian.org thomas.g.gir...@free.fr > Tags: sid trixie > > Dear Debian dwarves (pahole) package maintainer, Hi, > The pahole upstream is releasing a new upstream release (1.26). > Please consider packaging it in Debian. Thanks for the heads up. I've accumulated a bit of backlog Debian activity, I'll handle this in the coming days. > Besides, upstream is introducing a PKG-MAINTAINERS file to > indicate the package maintainers in different distros. According to > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=554c5e6a2736e0b6108077c7697637f6542dd2ed > , > Domenico Andreoli is added as the person of contact. Please review > the info and confirm with upstream if needed. I will. Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1055876: lastpass-cli: lpass login fails with "Error: SSL peer certificate or SSH remote key was not OK."
Control: reopen 1055876 Control: found 1.3.4-1 Control: fixed 1.3.7-1 Hi, As far as I can see the version in Bookworm is still severely broken and unusable; it deserves at least a bug to document its state. Thanks! Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
On Mon, Nov 13, 2023 at 03:09:57PM +0100, Nicolas Schier wrote: > Hi Domenico, Hi Nicolas, > do you still plan to finish the packaging of golang-k8s-apimachinery > shortly? To be honest I'm far from working at this package. > In order to update glab package to v1.35.0 the package is needed; may we > offer help or would it be ok for you if someone else takes-over your > ITP? Please go ahead and hijack the ITP. Thanks! Domenico > Kind regards, > Nicolas > > > On Sun, Jun 12, 2022 at 09:51:03PM +0200, Domenico Andreoli wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Domenico Andreoli > > > > * Package name: golang-k8s-apimachinery > > Version : 1.25.0~alpha0-1 > > Upstream Author : Kubernetes > > * URL : https://github.com/kubernetes/apimachinery > > * License : Apache-2.0 > > Programming Lang: Go > > Description : Handle Kubernetes-like API objects. > > > > This library is a shared dependency for servers and clients to work with > > Kubernetes API infrastructure without direct type dependencies. Its > > first consumers are k8s.io/kubernetes, k8s.io/client-go, and > > k8s.io/apiserver. -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1055876: lastpass-cli: lpass login fails with "Error: SSL peer certificate or SSH remote key was not OK."
Package: lastpass-cli Version: 1.3.4-1 Severity: important Hi, On Bookworm I cannot log in to Lastpass any more, I get the following error: Error: SSL peer certificate or SSH remote key was not OK. Upstream issues: https://github.com/lastpass/lastpass-cli/issues/540 https://github.com/lastpass/lastpass-cli/issues/653 Thanks, Domenico -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.6.0-arm64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lastpass-cli depends on: ii binutils 2.40-2 ii ca-certificates 20230311 ii libc62.36-9+deb12u3 ii libcurl4 7.88.1-10+deb12u4 ii libssl3 3.0.11-1~deb12u2 ii libxml2 2.9.14+dfsg-1.3~deb12u1 Versions of packages lastpass-cli recommends: ii pinentry-curses 1.2.1-1 Versions of packages lastpass-cli suggests: pn xclip | xsel
Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail
On 29 April 2023 11:56:19 CEST, Salvatore Bonaccorso wrote: >Hi Aurelien, > >On Sat, Apr 29, 2023 at 09:50:57AM +0200, Aurelien Jarno wrote: >> control: reassign -1 pahole/1.24-4 >> control: retitle -1 pahole: BTF deduplication issues causing arm64 kernel >> size increase >> control: tag -1 + fixed-upstream >> control: tag -1 + patch >> control: affects -1 u-boot-rpi src:linux >> >> Hi, >> >> On 2023-03-21 23:11, Aurelien Jarno wrote: >> > Source: linux >> > Version: 6.1.15-1 >> > Severity: important >> > Tags: upstream >> > X-Debbugs-Cc: vagr...@debian.org >> > Control: affects -1 + u-boot-rpi >> > >> > Hi, >> > >> > Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a >> > Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed >> > to boot with: >> > >> > | 40175552 bytes read in 1695 ms (23 MiB/s) >> > | 43794863 bytes read in 1817 ms (23 MiB/s) >> > | Moving Image from 0x8 to 0x20, end=299 >> > | ERROR: RD image overlaps OS image (OS=0x20..0x299) >> > >> > I tracked the issue to a significant increase of the kernel size between >> > version 6.1.12-1 and 6.15-1: >> > >> > | 31492 /boot/vmlinuz-6.1.0-5-arm64 >> > | 39236 /boot/vmlinuz-6.1.0-6-arm64 >> > >> > This is more than the 36MB that is allowed by u-boot with the default >> > load addresses. A workaround is to shift the load addresses at the >> > u-boot level as in the attached patch. >> > >> > I have tracked issue on the upstream kernel side to the following commit >> > on the stable tree: >> > >> > | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef >> > | Author: Masahiro Yamada >> > | Date: Thu Oct 13 08:35:00 2022 +0900 >> > | >> > | arm64: remove special treatment for the link order of head.o >> > | >> > | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream. >> > | >> > | In the previous discussion (see the Link tag), Ard pointed out that >> > | arm/arm64/kernel/head.o does not need any special treatment - the >> > only >> > | piece that must appear right at the start of the binary image is the >> > | image header which is emitted into .head.text. >> > | >> > | The linker script does the right thing to do. The build system does >> > | not need to manipulate the link order of head.o. >> > | >> > | Link: >> > https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/ >> > | Suggested-by: Ard Biesheuvel >> > | Signed-off-by: Masahiro Yamada >> > | Reviewed-by: Nicolas Schier >> > | Link: >> > https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org >> > | Signed-off-by: Will Deacon >> > | Signed-off-by: Tom Saeger >> > | Signed-off-by: Greg Kroah-Hartman >> > >> > The problem is still reproducible on Linus' master. >> > >> > I am reporting the bug to the linux package as I believed there is no >> > real reason for such an increase in the kernel size. In case I missed >> > something and this is actually wanted, the bug can be reassigned to the >> > u-boot package. >> >> This has been discussed upstream, and it appears that the issue is not >> reproducible with pahole 1.25. Looking at the part that needs to be >> backported to the Debian package, I have found that the issue is caused >> by the following patch backported in version 1.24-4: >> >> 02-encode-DW_TAG_unspecified_type-returning-routines-as-void.patch >> >> This patch has an issue, and memory is not initialized after allocation, >> so garbage values are used instead. A one-liner fix has been committed >> upstream not so long after the initial patch: >> >> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=b72f5188856df0abf45e1a707856bb4e4e86153c >> >> I am therefore reassigning the bug to pahole where the bug should be >> fixed. Even if Bookworm is now fully frozen, I personally believe this >> bug should still be fixed before the release. That said, this has to be >> discussed with the release team, and as pahole is a key package you need >> a pre-approval *before* the upload to sid. > >Thanks for tracking this down! > >Domenico, I would say, it would eben be good to have this in in the >archive for bookworm before the next (last?) linux upload for bookworm >ideally. This is not yet planned but, the last one should probably be >latest in the week of 15th May. > >Regards, >Salvatore Hi, Apologies for not having sent a VAC message but I'm unable to handle this in a timely manner. Please proceed with a NMU. Thanks, Dom
Bug#1016963: Please test u-boot for nanopi_neo2
On Wed, Dec 28, 2022 at 04:16:13PM -0800, Vagrant Cascadian wrote: > On 2022-12-28, Vagrant Cascadian wrote: > > On 2022-12-22, Vagrant Cascadian wrote: > >> On 2022-08-20, Vagrant Cascadian wrote: > >>> On 2022-08-10, Vagrant Cascadian wrote: > This bug is just to delay migration to testing while more platforms get > tested. If you have a relevent board, please consider testing and > reporting the status: > > https://wiki.debian.org/U-boot/Status > > > > I have not received many test results for current or even remotely > > recent u-boot platforms in Debian, and u-boot has been blocked from > > migration to testing partly because of this. > > > > As the bookworm freeze approaches, this is getting to be... worrysome! > > > > If you have access to any of these boards, please consider testing > > u-boot versions as packaged in debian for versions from debian stable > > (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental > > (2023.01-rc*) and updating the wiki page if successful and/or replying > > to 1016...@bugs.debian.org with a positive confirmation... > > > > ...and if not successful, filing bugs against the relevent u-boot-* > > packages and marking them as blocking 1016963. > > nanopi_neo2 Done for all my boards, both with unstable and experimental versions. Thanks. Dom > > live well, > vagrant -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1021562: pahole: Update for building Linux kernel with newer toolchains
On Sun, Dec 11, 2022 at 08:22:38AM +0100, Salvatore Bonaccorso wrote: > Hi Domenico, > > On Sat, Dec 10, 2022 at 09:01:06PM +0100, Salvatore Bonaccorso wrote: > > Hi Domenico, > > > > On Sat, Dec 10, 2022 at 04:32:33PM +, Domenico Andreoli wrote: > > > On Sat, Dec 10, 2022 at 10:27 AM Domenico Andreoli > > > wrote: > > > > > > > On Fri, Dec 09, 2022 at 11:24:23PM +0100, Salvatore Bonaccorso wrote: > > > > > Hi Domenico, > > > > > > > > Hi Salvatore, > > > > > > > > > On Tue, Oct 11, 2022 at 01:41:23PM +0200, Domenico Andreoli wrote: > > > > > > On Mon, Oct 10, 2022 at 08:51:48PM +0200, Jan-Benedict Glaw wrote: > > > > > > > Package: pahole > > > > > > > Distribution: sid > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > Hi Jan-Benedict! > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > I think that's caused wrt. this thread: > > > > > > > https://www.spinics.net/lists/dwarves/msg01719.html, it would be > > > > nice > > > > > > > to have this fixed in Debian's `pahole`. > > > > > > > > > > > > Agreed, it's time for a new upload. I'll try to prepare it in the > > > > coming days. > > > > > > > > > > Did you found time to work on a update including the required changes > > > > > for pahole? > > > > > > > > No but I looked at it right now. > > > > > > > > > > > > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=bcc648a10cbcd0b96b84ff7c737d56ce70f7b501 > > > > > > > > This is not enough, other commits are also needed. I'll try to finish > > > > it this afternoon. > > > > > > > > > The last uploads for src:linux FTBFS on arm64 for both 6.0.12-1 and > > > > > 6.1~rc8-1~exp1, with > > > > > > > > > > > > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.0.12-1&stamp=1670586537&raw=0 > > > > > > > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.1%7Erc8-1%7Eexp1&stamp=1670583119&raw=0 > > > > > > > > By EOB you either will have an RFS (my sub-key expired, the new one > > > > will not be usable soon enough) or will be free to proceed on your own. > > > > > > > > > > I managed to prepare a new upload, I tested it on both amd64 and arm64, > > > where I was able to reproduce the problem. > > > > > > As anticipated, here is my upload at > > > https://mentors.debian.net/package/dwarves/ signed with a subkey not yet > > > in > > > the keyring. Please review before uploading. > > > > Thanks for your time on it! I just have uploaded your package. > > And confirming linux/6.0.12-1 on arm64 did now built sucessfully: > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.0.12-1&stamp=1670742711&raw=0 That's good, thank you for the update. Dom > > Regards, > Salvatore -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1021562: pahole: Update for building Linux kernel with newer toolchains
On Sat, Dec 10, 2022 at 10:27 AM Domenico Andreoli wrote: > On Fri, Dec 09, 2022 at 11:24:23PM +0100, Salvatore Bonaccorso wrote: > > Hi Domenico, > > Hi Salvatore, > > > On Tue, Oct 11, 2022 at 01:41:23PM +0200, Domenico Andreoli wrote: > > > On Mon, Oct 10, 2022 at 08:51:48PM +0200, Jan-Benedict Glaw wrote: > > > > Package: pahole > > > > Distribution: sid > > > > > > > > Hi! > > > > > > Hi Jan-Benedict! > > > > > > > > > > > [...] > > > > > > > > I think that's caused wrt. this thread: > > > > https://www.spinics.net/lists/dwarves/msg01719.html, it would be > nice > > > > to have this fixed in Debian's `pahole`. > > > > > > Agreed, it's time for a new upload. I'll try to prepare it in the > coming days. > > > > Did you found time to work on a update including the required changes > > for pahole? > > No but I looked at it right now. > > > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=bcc648a10cbcd0b96b84ff7c737d56ce70f7b501 > > This is not enough, other commits are also needed. I'll try to finish > it this afternoon. > > > The last uploads for src:linux FTBFS on arm64 for both 6.0.12-1 and > > 6.1~rc8-1~exp1, with > > > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.0.12-1&stamp=1670586537&raw=0 > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.1%7Erc8-1%7Eexp1&stamp=1670583119&raw=0 > > By EOB you either will have an RFS (my sub-key expired, the new one > will not be usable soon enough) or will be free to proceed on your own. > I managed to prepare a new upload, I tested it on both amd64 and arm64, where I was able to reproduce the problem. As anticipated, here is my upload at https://mentors.debian.net/package/dwarves/ signed with a subkey not yet in the keyring. Please review before uploading. Dom > > Regards, > > Salvatore > > Thanks, > Dom > > -- > rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 > ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 >
Bug#1021562: pahole: Update for building Linux kernel with newer toolchains
On Fri, Dec 09, 2022 at 11:24:23PM +0100, Salvatore Bonaccorso wrote: > Hi Domenico, Hi Salvatore, > On Tue, Oct 11, 2022 at 01:41:23PM +0200, Domenico Andreoli wrote: > > On Mon, Oct 10, 2022 at 08:51:48PM +0200, Jan-Benedict Glaw wrote: > > > Package: pahole > > > Distribution: sid > > > > > > Hi! > > > > Hi Jan-Benedict! > > > > > > > > [...] > > > > > > I think that's caused wrt. this thread: > > > https://www.spinics.net/lists/dwarves/msg01719.html, it would be nice > > > to have this fixed in Debian's `pahole`. > > > > Agreed, it's time for a new upload. I'll try to prepare it in the coming > > days. > > Did you found time to work on a update including the required changes > for pahole? No but I looked at it right now. > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=bcc648a10cbcd0b96b84ff7c737d56ce70f7b501 This is not enough, other commits are also needed. I'll try to finish it this afternoon. > The last uploads for src:linux FTBFS on arm64 for both 6.0.12-1 and > 6.1~rc8-1~exp1, with > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.0.12-1&stamp=1670586537&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.1%7Erc8-1%7Eexp1&stamp=1670583119&raw=0 By EOB you either will have an RFS (my sub-key expired, the new one will not be usable soon enough) or will be free to proceed on your own. > Regards, > Salvatore Thanks, Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1024839: ITP: python3-setuptools-golang -- Build Python extensions written in Go
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-pyt...@lists.debian.org * Package name: python3-setuptools-golang Version : 2.7.0 Upstream Author : Anthony Sottile * URL : https://github.com/asottile/setuptools-golang * License : Expat License Programming Lang: Python Description : Build Python extensions written in Go This is a plugin for setuptools, use it to build and package modules written in Go as you do for regular Python modules and C extensions. signature.asc Description: PGP signature
Bug#1017440: pahole: Several tools just segfault
severity -1 important thanks On Tue, Aug 16, 2022 at 01:12:55PM +0200, Guillem Jover wrote: > Package: pahole > Version: 1.23-2 > Severity: serious > > Hi! Hi Guillem! > Many of the tools simply segfault when executed. On a shared library > with debugging symbols: > > $ codiff libsysfs.so.2.0.1 libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ dtagnames libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ prefcnt libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ scncopy -s data -o output libsysfs.so.2.0.1 > Segmentation fault (core dumped) > $ syscse libsysfs.so.2.0.1 > Segmentation fault (core dumped) > > On a stripped library: > > $ codiff /usr/lib/x86_64-linux-gnu/libbsd.so.0 \ >/usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ dtagnames /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ prefcnt /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ scncopy -s data -o output /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > $ syscse /usr/lib/x86_64-linux-gnu/libbsd.so.0 > Segmentation fault (core dumped) > > Some even with no arguments: > > $ dtagnames > Segmentation fault (core dumped) > $ prefcnt > Segmentation fault (core dumped) Thank you for reporting, I added a smoke test that tries to use all these tools and can be used to track the overall state. I've not the time to dig into these failures but I'll report them to the upstream developers. Given that the package is far from being unusable, I'm reducing its severity to important. > > Thanks, > Guillem > Regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1021562: pahole: Update for building Linux kernel with newer toolchains
On Mon, Oct 10, 2022 at 08:51:48PM +0200, Jan-Benedict Glaw wrote: > Package: pahole > Distribution: sid > > Hi! Hi Jan-Benedict! > > [...] > > I think that's caused wrt. this thread: > https://www.spinics.net/lists/dwarves/msg01719.html, it would be nice > to have this fixed in Debian's `pahole`. Agreed, it's time for a new upload. I'll try to prepare it in the coming days. Thanks! Dom > > Thanks a lot, > Jan-Benedict Glaw > -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1018906: dwarves: FTBFS with libbpf 1.0.0
On Tue, Sep 06, 2022 at 10:47:44AM +0100, Sudip Mukherjee wrote: > Hi Dom, > > On Sun, Sep 4, 2022 at 5:54 PM Domenico Andreoli wrote: > > > > On Thu, Sep 01, 2022 at 08:57:21PM +0100, Sudip Mukherjee wrote: > > > > > > Dear Maintainer, > > > > Hi Sudip, > > > > > > > > dwarves FTBFS with libbpf 1.0.0 (available in experimental). > > > Hopefully this is the error from the build log: > > > > > > In file included from /home/sudip/test/dwarves-1.23/btf_encoder.c:18: > > > /usr/include/bpf/btf.h: In function 'btf_enum64_value': > > > /usr/include/bpf/btf.h:496:25: error: invalid use of undefined type > > > 'const struct btf_enum64' > > > 496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32; > > > | ^~ > > > /usr/include/bpf/btf.h:496:46: error: invalid use of undefined type > > > 'const struct btf_enum64' > > > 496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32; > > > | ^~ > > > > Which version of linux-libc-dev are you using? I see that struct > > btf_enum64 is introduced only in kernel 6.0, not yet packaged. > > It does look like libbpf has now added a hard dependency on v6.0+ > kernel even though they said it will have "transparent handling of > older kernels". > I have mentioned it in > https://github.com/libbpf/libbpf/issues/562#issuecomment-1237299951. > So, we either need to wait for some fix from libbpf upstream or wait > for the Debian kernel team to update to v6.0 after its released next > month. This already happened in the past, I solved it by adding linux-libc-dev to dwarves' build depends. It's not obvious why this is visible only when building dwarves and not libbpf itself. I nevertheless think it should be libbpf to depend on the right linux-libc-dev, not the packages using it. What do you think? -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1018906: dwarves: FTBFS with libbpf 1.0.0
On Thu, Sep 01, 2022 at 08:57:21PM +0100, Sudip Mukherjee wrote:
>
> Dear Maintainer,
Hi Sudip,
>
> dwarves FTBFS with libbpf 1.0.0 (available in experimental).
> Hopefully this is the error from the build log:
>
> In file included from /home/sudip/test/dwarves-1.23/btf_encoder.c:18:
> /usr/include/bpf/btf.h: In function 'btf_enum64_value':
> /usr/include/bpf/btf.h:496:25: error: invalid use of undefined type 'const
> struct btf_enum64'
> 496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
> | ^~
> /usr/include/bpf/btf.h:496:46: error: invalid use of undefined type 'const
> struct btf_enum64'
> 496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
> | ^~
Which version of linux-libc-dev are you using? I see that struct
btf_enum64 is introduced only in kernel 6.0, not yet packaged.
> /home/sudip/test/dwarves-1.23/btf_encoder.c: In function 'btf__log_err':
> /home/sudip/test/dwarves-1.23/btf_encoder.c:175:39: warning: implicit
> declaration of function 'btf__get_nr_types' [-Wimplicit-function-declaration]
> 175 | fprintf(stderr, "[%u] %s %s", btf__get_nr_types(btf) + 1,
> | ^
> /home/sudip/test/dwarves-1.23/btf_encoder.c: In function
> 'btf_encoder__encode':
> /home/sudip/test/dwarves-1.23/btf_encoder.c:1049:13: error: too many
> arguments to function 'btf__dedup'
> 1049 | if (btf__dedup(encoder->btf, NULL, NULL)) {
> | ^~
> /usr/include/bpf/btf.h:232:16: note: declared here
> 232 | LIBBPF_API int btf__dedup(struct btf *btf, const struct
> btf_dedup_opts *opts);
> |^~
>
These probably require the new dwarves 1.24.
Thanks,
Dom
--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
signature.asc
Description: PGP signature
Bug#846050: libvirt-daemon-system: Cannot create VM - cannot load AppArmor profile
Hi, Today I solved a similar issue on my machine, or at least something that was manifesting with the same error message. The original problem is that my VM was referring to a file missing from disk, the XML definition was valid but the VM was not. This made some libvirtd child process die and, for reasons I ignore, failed the AppArmor profile validation. This is from syslog: Jul 21 12:36:55 r9 libvirtd[1129]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u libvirt-ae75c26b-557a-4772-afe0-f820cfcdf410) unexpected exit status 1: virt-aa-helper: warning: path does not exist, skipping file type checks#012virt-aa-helper: error: /usr/share/AAVMF/AAVMF_VARS.fd#012virt-aa-helper: error: skipped restricted file#012virt-aa-helper: error: invalid VM definition Jul 21 12:36:55 r9 libvirtd[1129]: internal error: cannot load AppArmor profile 'libvirt-ae75c26b-557a-4772-afe0-f820cfcdf410' Therefore if you get this "cannot load AppArmor profile" error, look for the actual error in /var/log/syslog. I also suggest to close this bug, it's of the kind catch-all and cannot be solved in any way. Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1014634: ITP: golang-github-iovisor-gobpf -- Go bindings for creating BPF programs.
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: golang-github-iovisor-gobpf Version : 0.2.0-1 Upstream Author : IO Visor Project * URL : https://github.com/iovisor/gobpf * License : Apache-2.0 Programming Lang: Go Description : Go bindings for creating BPF programs. This repository provides go bindings for the bcc framework as well as low-level routines to load and use eBPF programs from .elf files.
Bug#929458: ITP: trivy -- A Simple and Comprehensive Vulnerability Scanner for Containers, Suitable for CI
Hi Nobuhiro, Any updates on this? Blocked on anything? Do you need any help? Thanks, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1014406: ITP: oci-seccomp-bpf-hook -- OCI hook to trace syscalls and generate a seccomp profile
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: oci-seccomp-bpf-hook Version : 1.2.5-1 Upstream Author : Valentin Rothberg, Daniel J. Walsh, et al. * URL : https://github.com/containers/oci-seccomp-bpf-hook * License : Apache-2.0 Programming Lang: Go Description : OCI hook to trace syscalls and generate a seccomp profile This project provides an OCI hook to generate seccomp profiles by tracing the syscalls made by the container. The generated profile would allow all the syscalls made and deny every other syscall. -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#1012724: gnostic: new upstream version 0.6.9
Package: golang-github-google-gnostic-dev Severity: wishlist Dear Dmitry and Anthony, I was wandering in the dependencies of the kind tool (which I'm attempting to package), in the need of the gnostic module. Therefore I packaged it (not uploaded) from scratch [0]. It's only later that I noticed we already have a previous version in the archive with name `golang-github-googleapis-gnostic-dev` but it's too old for my purposes and needs a good refresh of paths and name. The old path is /usr/share/gocode/src/github.com/googleapis/gnostic The new path is /usr/share/gocode/src/github.com/google/gnostic As a consequence, the binary package should be renamed to `golang-github-google-gnostic-dev`. Because some CLI tools have been added, a new binary pacage is also needed with, I guess, name `gnostic`. I light of this, I think the source package should be renamed to `gnostic` as well. Essentially upgrading your golang-github-googleapis-gnostic-dev is equivalent to upload my new - almost ready to go - package modulo history and uploaders. How do you prefer to proceeed? I'm open to any option as long it can be uploaded sooner than later. Regards, Domenico [0] https://salsa.debian.org/go-team/packages/gnostic/-/merge_requests/1 -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: golang-k8s-apimachinery Version : 1.25.0~alpha0-1 Upstream Author : Kubernetes * URL : https://github.com/kubernetes/apimachinery * License : Apache-2.0 Programming Lang: Go Description : Handle Kubernetes-like API objects. This library is a shared dependency for servers and clients to work with Kubernetes API infrastructure without direct type dependencies. Its first consumers are k8s.io/kubernetes, k8s.io/client-go, and k8s.io/apiserver.
Bug#1012317: ITP: golang-github-flowstack-go-jsonschema -- Go JSON Schema parser and validator
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: golang-github-flowstack-go-jsonschema Version : 0.1.1-1 Upstream Author : FlowStack * URL : https://github.com/flowstack/go-jsonschema * License : Expat Programming Lang: Go Description : Go JSON Schema parser and validator The very nice gojsonschema was missing some features and we needed some internal functionality, that was hard to build on top of gojsonschema. . This module uses the excellent jsonparser, which is wy faster than Go's builtin parser.
Bug#1008492: ITP: jh7100-bootloader-recovery -- StarFive JH7100 recovery bootloader
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: jh7100-bootloader-recovery Version : 2021-07-14 Upstream Author : StarFive Tech. * URL : https://github.com/starfive-tech/bootloader_recovery * License : GPL Programming Lang: C Description : StarFive JH7100 recovery bootloader This firmware brings up the board enough to program all the boot stages onto the boot flash. It recovers an otherwise unbootable system.
Bug#1008475: ITP: jh71xx-tools -- StarFive JH71xx bootloader recovery and updater tool
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: jh71xx-tools Version : 2021-07-16 Upstream Author : Kali Prasad * URL : https://github.com/kprasadvnsi/JH71xx-tools * License : MIT Programming Lang: C Description : StarFive JH71xx bootloader recovery and updater tool This utility is used to download the bootloader recovery firmware, the second stage bootloader and the ddrinit firmware to the CPU via UART. It uses the xmodem protocol over UART, as expected by the JH71xx when the boot flash is blank.
Bug#1008473: ITP: jh7100-ddrinit -- StarFive JH7100 DDR initialization stage
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: jh7100-ddrinit Version : 2021-11-02 Upstream Author : StarFive Tech. * URL : https://github.com/starfive-tech/JH7100_ddrinit * License : GPL Programming Lang: C Description : StarFive JH7100 DDR initialization stage This firmware is loaded early by the boot loader, its purpose is to configure the DDR controller before any later stage is executed. Depending on your board, it might be needed to build a bootable media or just be programmed in an internal flash.
Bug#1008472: ITP: jh7100-second-boot -- StarFive JH7100 boot loader
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: jh7100-second-boot Version : 2021-11-02 Upstream Author : StarFive Tech. * URL : https://github.com/starfive-tech/JH7100_secondBoot * License : GPL Programming Lang: C Description : StarFive JH7100 boot loader This is the very first piece of software loaded by the CPU during boot. Its purpose is to prepare the HW for the execution of OpenSBI and all the subsequent stages of the boot, like U-Boot and Linux. Depending on your board, it might be needed to build a bootable media or just be programmed in an internal flash.
Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: solo1 Version : 0.1.1 Upstream Author : he...@solokeys.com * URL : https://github.com/solokeys/solo1-cli * License : Apache 2.0 and MIT Programming Lang: Python Description : Python module and CLI for SoloKeys Solo 1 devices With this package you get a command-line interface to manage your SoloKeys and a Python module to interface them with your applications. Some of the operations you can do: - set or change the PIN - read the firmware version - update the firmware - wipe all your credentials - verify whether your device is a Solo Secure or Solo Hacker
Bug#1005014: dwarves: autopkgtest fails on ppc64el
Another relevant thread on powerpc porters list [0]. [0] https://lists.debian.org/debian-powerpc/2022/01/msg00039.html -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#1005014: dwarves: autopkgtest fails on ppc64el
Package: src:dwarves
Version: 1.22-5
Starting with 1.22-5, a minimal kernel is built as part of the
autopkgtest tests suite.
Such test fails on ppc64el with the following error:
...
AR fs/notify/fanotify/built-in.a
AR fs/notify/built-in.a
AR fs/iomap/built-in.a
AR fs/quota/built-in.a
AR fs/devpts/built-in.a
CC fs/ramfs/inode.o
CC mm/mmap.o
CC kernel/notifier.o
CC fs/ramfs/file-mmu.o
CC kernel/ksysfs.o
AR fs/ramfs/built-in.a
CC fs/open.o
{standard input}: Assembler messages:
{standard input}:4494: Error: unrecognized opcode: `ptesync'
make[2]: *** [scripts/Makefile.build:282: arch/powerpc/lib/sstep.o] Error 1
make[1]: *** [scripts/Makefile.build:545: arch/powerpc/lib] Error 2
make: *** [Makefile:1892: arch/powerpc] Error 2
make: *** Waiting for unfinished jobs
...
Bug #885245 [0] is related although does not suggest a solution.
Full log is attached [1].
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885245
[1]
https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/dwarves/18953887/log.gz
--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
log.gz
Description: application/gzip
Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities
On October 25, 2021 8:58:57 PM UTC, Luca Boccassi wrote: >On Mon, 2021-10-25 at 22:28 +0200, Domenico Andreoli wrote: >> Hi Adam, Luca and Theodore, >> >> On Thu, Oct 21, 2021 at 04:50:36PM +0200, Domenico Andreoli wrote: >> > Package: sponsorship-requests >> > Severity: normal >> > >> > Dear all, >> > >> > I'm looking for a sponsor for this package: >> >> Could any of you please review this upload? >> >> Thanks! >> Dom > >Looks good to me, uploaded. Thanks! >Just a minor thing for the next time you prepare an upload: the build- >dep on libbpf-dev needs to be bumped, this version requires >= 0.4. I'll fix with the next upload. Thank you. Dom rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities
Hi Adam, Luca and Theodore, On Thu, Oct 21, 2021 at 04:50:36PM +0200, Domenico Andreoli wrote: > Package: sponsorship-requests > Severity: normal > > Dear all, > > I'm looking for a sponsor for this package: Could any of you please review this upload? Thanks! Dom > > * Package name: dwarves > Version : 1.22-1 > Upstream Author : Arnaldo Carvalho de Melo > * URL : https://git.kernel.org/pub/scm/devel/pahole/pahole.git > * License : GPLv2 > Section : utils > > It builds these binary packages: > > dwarves - set of advanced DWARF utilities - transitional package > pahole- set of advanced DWARF utilities > pahole-dbgsym - debug symbols for pahole > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/dwarves > > Alternatively, you can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/d/dwarves/dwarves_1.22-1.dsc > > More information can be obtained from > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ > > Changes since the last upload: > > dwarves (1.22-1) unstable; urgency=low > > * New upstream release. > Changes since 1.20: > > pahole: > - Allow encoding BTF to a separate BTF file (detached) instead of to a new > ".BTF" ELF section in the file being encoded (vmlinux usually). > - Introduce -j/--jobs option to specify the number of threads to > use. Without arguments means one thread per CPU. So far used for > the DWARF loader, will be used as well for the BTF encoder. > - Show all different types with the same name, not just the first one > found. > - Introduce sorted type output (--sort), needed with multithreaded > DWARF loading, to use with things like 'btfdiff' that expects > the output from DWARF and BTF types to be comparable using 'diff'. > - Stop assuming that reading from stdin means pretty printing as this > broke > pre-existing scripts, introduce a explicit --prettify command line > option. > - Improve type resolution for the --header command line option. > - Disable incomplete CTF encoder, this needs to be done using the external > libctf library. > - Do not consider the ftrace filter when encoding BTF for kernel > functions. > - Add --kabi_prefix to avoid deduplication woes when using > _RH_KABI_REPLACE() > - Add --with_flexible_array to show just types with flexible arrays. > > DWARF Loader: > - Multithreaded loading, requires elfutils >= 0.178. > - Lock calls to non-thread safe elfutils' libdw functions > (dwarf_decl_file() > and dwarf_decl_line()) > - Change hash table size to one that performs better with current typical > vmlinux files. > - Allow tweaking the hash table size from the command line. > - Stop allocating memory for strings obtained from libdw, just defer > freeing > the Dwfl handler so that references to its strings can be safely kept. > - Use a frontend cache for the latest lookup result. > - Allow ignoring some DWARF tags when loading for encoding > BTF, as BTF doesn't have equivalents for things like > DW_TAG_inline_expansion and DW_TAG_label. > - Allow ignoring some DWARF tag attributes, such as DW_AT_alignment, > not used when encoding BTF. > - Do not query for non-C attributes when loading a C language CU > (compilation unit). > > BTF encoder: > - Preparatory work for multithreaded encoding, the focus for 1.23. > > btfdiff: > - Support diffing against a detached BTF file, > e.g.: 'btfdiff vmlinux vmlinux.btf' > - Support multithreaded DWARF loading, using the new pahole --sort > option to have the output from both BTF and DWARF sorted and thus > comparable via 'diff'. > > Build: > - Support building with libc libraries lacking either obstacks or argp, > such > as Alpine Linux's musl libc. > - Support systems without getconf() to obtain the data cacheline size, > such > as musl libc. > - Add a buildcmd.sh for test builds, tested using the same set of > containers > used for testing the Linux kernel perf tools. > - Enable selecting building with a shared libdwarves library or > statically. > - Allow one to use the libbpf package found in distributions instead > of with the accompanying libbpf git submodule. > > Cleanups: > - Address lots of compiler warning
Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves Version : 1.22-1 Upstream Author : Arnaldo Carvalho de Melo * URL : https://git.kernel.org/pub/scm/devel/pahole/pahole.git * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities - transitional package pahole- set of advanced DWARF utilities pahole-dbgsym - debug symbols for pahole To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves/dwarves_1.22-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves (1.22-1) unstable; urgency=low * New upstream release. Changes since 1.20: pahole: - Allow encoding BTF to a separate BTF file (detached) instead of to a new ".BTF" ELF section in the file being encoded (vmlinux usually). - Introduce -j/--jobs option to specify the number of threads to use. Without arguments means one thread per CPU. So far used for the DWARF loader, will be used as well for the BTF encoder. - Show all different types with the same name, not just the first one found. - Introduce sorted type output (--sort), needed with multithreaded DWARF loading, to use with things like 'btfdiff' that expects the output from DWARF and BTF types to be comparable using 'diff'. - Stop assuming that reading from stdin means pretty printing as this broke pre-existing scripts, introduce a explicit --prettify command line option. - Improve type resolution for the --header command line option. - Disable incomplete CTF encoder, this needs to be done using the external libctf library. - Do not consider the ftrace filter when encoding BTF for kernel functions. - Add --kabi_prefix to avoid deduplication woes when using _RH_KABI_REPLACE() - Add --with_flexible_array to show just types with flexible arrays. DWARF Loader: - Multithreaded loading, requires elfutils >= 0.178. - Lock calls to non-thread safe elfutils' libdw functions (dwarf_decl_file() and dwarf_decl_line()) - Change hash table size to one that performs better with current typical vmlinux files. - Allow tweaking the hash table size from the command line. - Stop allocating memory for strings obtained from libdw, just defer freeing the Dwfl handler so that references to its strings can be safely kept. - Use a frontend cache for the latest lookup result. - Allow ignoring some DWARF tags when loading for encoding BTF, as BTF doesn't have equivalents for things like DW_TAG_inline_expansion and DW_TAG_label. - Allow ignoring some DWARF tag attributes, such as DW_AT_alignment, not used when encoding BTF. - Do not query for non-C attributes when loading a C language CU (compilation unit). BTF encoder: - Preparatory work for multithreaded encoding, the focus for 1.23. btfdiff: - Support diffing against a detached BTF file, e.g.: 'btfdiff vmlinux vmlinux.btf' - Support multithreaded DWARF loading, using the new pahole --sort option to have the output from both BTF and DWARF sorted and thus comparable via 'diff'. Build: - Support building with libc libraries lacking either obstacks or argp, such as Alpine Linux's musl libc. - Support systems without getconf() to obtain the data cacheline size, such as musl libc. - Add a buildcmd.sh for test builds, tested using the same set of containers used for testing the Linux kernel perf tools. - Enable selecting building with a shared libdwarves library or statically. - Allow one to use the libbpf package found in distributions instead of with the accompanying libbpf git submodule. Cleanups: - Address lots of compiler warnings accumulated by not using -Wextra, it'll be added in the next release after allowing not to use it to build libbpf. - Address covscan report issues. Documentation: - Improve the --nr_methods/-m pahole man page entry. - Clarify that currently --nr_methods doesn't work together witn -C. * Refresh patches. * Drop patch no_shared_no_ebl, can do without it. * Build-Depends on linux-libc-dev (>= 5.14) for BTF_KIND_FLOAT. * Rename source package to dwarves. Closes: #705969. * Rename binary package to pahole and add a transitional dummy package. * Patch pahole manpage to fix groff's warning. * Configure gbp to sign tags by default. * Remove superfluous file patter
Bug#705969: ANNOUNCE: pahole v1.20 (gcc11 DWARF5's default, lots of ELF sections, BTF)
On Mon, Feb 08, 2021 at 09:32:53AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 08, 2021 at 03:44:54AM +0100, Sedat Dilek escreveu:
> > On Thu, Feb 4, 2021 at 11:07 PM Arnaldo Carvalho de Melo
> > wrote:
> > >
> > > Hi,
> > >
> > > The v1.20 release of pahole and its friends is out, mostly
> > > addressing problems related to gcc 11 defaulting to DWARF5 for -g,
> > > available at the usual places:
> > >
> > > Main git repo:
> > >
> > >git://git.kernel.org/pub/scm/devel/pahole/pahole.git
> > >
> > > Mirror git repo:
> > >
> > >https://github.com/acmel/dwarves.git
> > >
> > > tarball + gpg signature:
> > >
> > >https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.xz
> > >https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.bz2
> > >https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.sign
> > >
> >
> > FYI:
> > Debian now ships dwarves package version 1.20-1 in unstable.
> >
> > Just a small nit to this release and its tagging:
> >
> > You did:
> > commit 0d415f68c468b77c5bf8e71965cd08c6efd25fc4 ("pahole: Prep 1.20")
> >
> > Is this new?
> >
> > The release before:
> > commit dd15aa4b0a6421295cbb7c3913429142fef8abe0 ("dwarves: Prep v1.19")
>
> Its minor but intentional, pahole is by far the most well known tool in
> dwarves, so using that name more frequently (the git repo is pahole.git
> , for instance) may help more quickly associate with the tool needed for
> BTF encoding, data analysis, etc. And since its not about only DWARF,
> perhaps transitioning to using 'pahole' more widely is interesting.
Any plan to switch also the release tarball name?
We are planning to rename the Debian package once the Bullseye is
released, currently it's dwarves-dfsg for legacy/unclear reasons.
Would it be a good idea to switch directly to pahole then?
Dom
>
> - Arnaldo
>
> > - Sedat -
> >
> > > Best Regards,
> > >
> > > - Arnaldo
> > >
> > > v1.20:
> > >
> > > BTF encoder:
> > >
> > > - Improve ELF error reporting using elf_errmsg(elf_errno()).
> > >
> > > - Improve objcopy error handling.
> > >
> > > - Fix handling of 'restrict' qualifier, that was being treated as a
> > > 'const'.
> > >
> > > - Support SHN_XINDEX in st_shndx symbol indexes, to handle ELF objects
> > > with
> > > more than 65534 sections, for instance, which happens with kernels
> > > built
> > > with 'KCFLAGS="-ffunction-sections -fdata-sections", Other cases may
> > > include when using FG-ASLR, LTO.
> > >
> > > - Cope with functions without a name, as seen sometimes when building
> > > kernel
> > > images with some versions of clang, when a SEGFAULT was taking place.
> > >
> > > - Fix BTF variable generation for kernel modules, not skipping
> > > variables at
> > > offset zero.
> > >
> > > - Fix address size to match what is in the ELF file being processed, to
> > > fix using
> > > a 64-bit pahole binary to generate BTF for a 32-bit vmlinux image.
> > >
> > > - Use kernel module ftrace addresses when finding which functions to
> > > encode,
> > > which increases the number of functions encoded.
> > >
> > > libbpf:
> > >
> > > - Allow use of packaged version, for distros wanting to dynamically
> > > link with
> > > the system's libbpf package instead of using the libbpf git submodule
> > > shipped
> > > in pahole's source code.
> > >
> > > DWARF loader:
> > >
> > > - Support DW_AT_data_bit_offset
> > >
> > > This appeared in DWARF4 but is supported only in gcc's -gdwarf-5,
> > > support it in a way that makes the output be the same for both cases.
> > >
> > > $ gcc -gdwarf-5 -c examples/dwarf5/bf.c
> > > $ pahole bf.o
> > > struct pea {
> > > long int a:1; /* 0: 0
> > > 8 */
> > > long int b:1; /* 0: 1
> > > 8 */
> > > long int c:1; /* 0: 2
> > > 8 */
> > >
> > > /* XXX 29 bits hole, try to pack */
> > > /* Bitfield combined with next fields */
> > >
> > > intafter_bitfield; /* 4
> > > 4 */
> > >
> > > /* size: 8, cachelines: 1, members: 4 */
> > > /* sum members: 4 */
> > > /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes:
> > > 29 bits */
> > > /* last cacheline: 8 bytes */
> > > };
> > >
> > > - DW_FORM_implicit_const in attr_numeric() and attr_offset()
> > >
> > > - Support DW_TAG_GNU_call_site, its the standardized rename of the
> > > previously supported
> > > DW_TAG_GNU_call_site.
> > >
> > > build:
> > >
> > > - Fix compilation on 32-bit architectures.
> > >
> > > Signed-off-by: Arnaldo Carvalho de Melo
>
> --
>
> - Arnaldo
--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
signature.asc
Description: PGP signa
Bug#981068: [arm64] ldconfig segfaults inside a qemu-aarch64-static chroot
On Tue, Jan 26, 2021 at 09:31:58PM +0100, Aurelien Jarno wrote: > On 2021-01-25 23:13, Domenico Andreoli wrote: ... > > > > The issue is introduced with --enable-static-pie on -7, downgrading to > > -6 or rebuilding -9 without --enable-static-pie makes the problem go away. > > PIE support on arm64 requires at least qemu version 5.0. Please upgrade > your qemu version. Indeed I had just verified that also a basic hello world with static PIE was failing when I read your email. I confirm that with newer qemu everything is fine. Thanks! > > Aurelien > Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#981068: [arm64] ldconfig segfaults inside a qemu-aarch64-static chroot
Package: libc-bin Version: 2.31-7 The issue is reproducible inside a arm64 chroot, on a amd64 host, via qemu-aarch64-static. No problems on a native arm64. Package upgrade fails with segmentation fault on post-installation, it's ldconfig: # dpkg -i libc-bin_2.31-7_arm64.deb Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 (Reading database ... 50524 files and directories currently installed.) Preparing to unpack libc-bin_2.31-7_arm64.deb ... Unpacking libc-bin (2.31-7) over (2.31-6) ... Setting up libc-bin (2.31-7) ... qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault dpkg: error processing package libc-bin (--install): installed libc-bin package post-installation script subprocess returned error exit status 139 Processing triggers for man-db (2.9.3-2) ... Errors were encountered while processing: libc-bin # # ldconfig -v Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 Unknown host QEMU_IFLA type: 50 Unknown host QEMU_IFLA type: 51 qemu: uncaught target signal 11 (Segmentation fault) - core dumped qemu: uncaught target signal 11 (Segmentation fault) - core dumped zsh: segmentation fault ldconfig -v # The issue is introduced with --enable-static-pie on -7, downgrading to -6 or rebuilding -9 without --enable-static-pie makes the problem go away. qemu writes a coredump but I'm not yet able to make gdb digest it. Thanks, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978691: dwarves-dfsg: New upstream version available (1.19)
On Sat, Jan 09, 2021 at 02:34:26PM +, Luca Boccassi wrote: > On Sat, 9 Jan 2021 at 13:18, Domenico Andreoli wrote: > > > > On Sat, Jan 09, 2021 at 11:49:28AM +, Luca Boccassi wrote: > > > On Sat, 9 Jan 2021 at 11:38, Domenico Andreoli wrote: > > > > > > > > Ciao Luca e Salvatore, > > > > > > > > Could any of you please sponsor my new dwarves-dfsg 1.19-1 upload? > > > > > > > > https://mentors.debian.net/package/dwarves-dfsg/ > > > > > > > > Thanks! > > > > > > > > Kind regards, > > > > Domenico > > > > > > > > -- > > > > rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 > > > > ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 > > > > > > Hello, > > > > > > Sure, I will do that later this afternoon. > > > > Thanks! > > > > > Please push the changes to https://salsa.debian.org/debian/dwarves as > > > it's still at 1.18-1. > > > > Pushed now. > > > > > > > > Kind regards, > > > Luca Boccassi > > > > Dom > > > > -- > > rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 > > ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 > > Hi, > > The refresh of the libbpf patch misses a couple of headers, fixed here: > > https://salsa.debian.org/debian/dwarves/-/merge_requests/3 > > No need to do a -2, just delete the tag and push it to the new commit > after merge. I merged, re-tagged and re-uploaded. Thanks! https://mentors.debian.net/package/dwarves-dfsg/ > > Kind regards, > Luca Boccassi Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978691: dwarves-dfsg: New upstream version available (1.19)
On Sat, Jan 09, 2021 at 11:49:28AM +, Luca Boccassi wrote: > On Sat, 9 Jan 2021 at 11:38, Domenico Andreoli wrote: > > > > Ciao Luca e Salvatore, > > > > Could any of you please sponsor my new dwarves-dfsg 1.19-1 upload? > > > > https://mentors.debian.net/package/dwarves-dfsg/ > > > > Thanks! > > > > Kind regards, > > Domenico > > > > -- > > rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 > > ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 > > Hello, > > Sure, I will do that later this afternoon. Thanks! > Please push the changes to https://salsa.debian.org/debian/dwarves as > it's still at 1.18-1. Pushed now. > > Kind regards, > Luca Boccassi Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978691: dwarves-dfsg: New upstream version available (1.19)
Ciao Luca e Salvatore, Could any of you please sponsor my new dwarves-dfsg 1.19-1 upload? https://mentors.debian.net/package/dwarves-dfsg/ Thanks! Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#979155: RFS: dwarves-dfsg/1.18-1 -- set of advanced DWARF utilities
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.18-1 Upstream Author : Arnaldo Carvalho de Melo * URL : https://git.kernel.org/pub/scm/devel/pahole/pahole.git * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.18-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.18-1) unstable; urgency=medium [ Domenico Andreoli ] * New upstream release (changes since 1.17): - Use type information to pretty print raw data from stdin, all documented in the man pages, further information in the csets. - Store percpu variables in vmlinux BTF. This can be disabled when debugging kernel features being developed to use it. - pahole now should be segfault free when handling gdb test suit DWARF files, including ADA, FORTRAN, rust and dwp compressed files, the later being just flatly refused, that got left for v1.19. - Bail out on partial units for now, avoiding segfaults and providing warning to user, hopefully will be addressed in v1.19. Closes: #977715. * Update Homepage link. Closes: #978708. * Drop debian/compat in favor of Build-Depends: debhelper-compat. * Fix typo in pahole manual page. * Fix escaping in pahole manual page. * Fix debian/copyright lintian errors. * Revert test to a superficial pahole --version until partial units become supported. [ Luca Boccassi ] * Use packaged libbpf instead of the statically linked. Closes: #979105. -- Domenico Andreoli Sun, 03 Jan 2021 13:41:31 +0100 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#978708: (no subject)
tags -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978681: Ignore my previous message, sent by mistake
Hi, Please ignore my previous message, was sent by mistake. Apologies for the spam. Regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978708: (no subject)
tags -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978708: (no subject)
tags -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978708: +pending
set -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978681: +pending
set -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#952905: dfu-util 0.10 has been released today
Hi, Today the new 0.10 has been released. Please update the package. Thanks, Domenico rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#972879: tor: fail to start if the ipv6 addr is not yet assigned
Package: tor A friend of mine has a relay that receives the ipv6 address from the router but needs to specify it in the torrc file, they are not aware of any other way of configuring an ipv6 relay. There is a window of time during boot when the ipv6 address is not assigned yet, if tor is started in such window it then fails to bind to the configured ipv6 address and the execution is aborted. Almost every time they reboot the relay they then need to restart the tor daemon manually in order to bind and announce properly on the net. It should be possible to configure systemd so that the tor daemon is started only after the ipv6 address has been assigned. -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#970276: New upstream version: 2020-07-27
Package: urjtag Severity: wishlist Please update to the latest release at https://sourceforge.net/projects/urjtag Thanks, Domenico rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#928863: Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
Hi all, It seems I missed some messages here and yesterday I realized it, I apologize for the delay. I prepared a MR to add the last bits for NanoPI NEO Air inclusion in the installer [0]. Please merge. Kind regards, Domenico [0] https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/15 -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#961303: Please add an entry for Turris MOX
Package: flash-kernel Version: 3.100 Severity: wishlist Tags: patch Dear Maintainer, please add the new entry for supporting Turris MOX [0]. Patch is attached but also MR is available on Salsa: https://salsa.debian.org/installer-team/flash-kernel/merge_requests/20 This is the entry: +Machine: CZ.NIC Turris Mox Board +Kernel-Flavors: arm64 +Boot-Script-Path: /boot/boot.scr +DTB-Id: marvell/armada-3720-turris-mox.dtb +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + I tested it as local override in /etc/flash-kernel/db on a manually booted Turris MOX after a Bullseye Alpha 2 install, for which only minor dts tweaks are needed. Regards, Domenico [0] https://www.turris.cz/en/mox/overview/ -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#961086: linux: Add armada_37xx_wdt.ko to the arm64 installer
On Tue, 19 May 2020 23:51:17 +0200, I wrote: > Package: src:linux > Version: 5.6.7-1 > Severity: wishlist > > Hi, > > in order to install Debian on Turris MOX [0] it's necessary to kick > the watchdog, which is started by u-boot. > > Please see MR #241 [1] in order to add the needed module to the D-I > kernel package. I rebased this on the sid branch. Is there any chance that it can be merged before the next upload? Or is it something I can marge myself? I'm not familiar with the process and would prefer to avoid waiting for myself without knowing ;) Thanks! Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#961086: linux: Add armada_37xx_wdt.ko to the arm64 installer
Package: src:linux Version: 5.6.7-1 Severity: wishlist Hi, in order to install Debian on Turris MOX [0] it's necessary to kick the watchdog, which is started by u-boot. Please see MR #241 [1] in order to add the needed module to the D-I kernel package. Regards, Domenico [0] https://www.turris.cz/en/mox/overview/ [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/241 -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#959711: u-boot-mvebu: enable support for turris_mox board
Package: u-boot-mvebu Version: 2020.04+dfsg-2 Severity: wishlist Hi, Salsa MR #10 enables support for Turris MOX [0], it's pre-requisite for adding support to the Debian Installer. Thanks, Domenico [0] https://www.turris.cz/en/mox/overview/ -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#958212: RFS: dwarves-dfsg/1.17-1 -- set of advanced DWARF utilities
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.17-1 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.17-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.17-1) unstable; urgency=low * New upstream release (changes since 1.16): BTF loader: - Support raw BTF as available in /sys/kernel/btf/vmlinux. pahole: - When the sole argument passed isn't a file, take it as a class name: - Do not require a class name to operate without a file name. - Make --find_pointers_to consider unions: - Make --contains and --find_pointers_to honour --unions - Add support for finding pointers to void: - Make --contains and --find_pointers_to to work with base types: - Make --contains look for more than just unions, structs: - Consider unions when looking for classes containing some class: - Introduce --unions to consider just unions: - Fix -m/--nr_methods - Number of functions operating on a type pointer man-pages: - Add section about --hex + -E to locate offsets deep into sub structs. - Add more information about BTF. - Add some examples. * Update to Standards-Version 4.5.0: - Drop get-orig-source rules target - Add Rules-Requires-Root: no * Update debhelper compat to 12. -- Domenico Andreoli Sun, 19 Apr 2020 20:25:33 +0200 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#949182: RFS: dwarves-dfsg 1.16-1
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.16-1 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.16-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.16-1) unstable; urgency=low * New upstream release (changes since 1.15): - Preserve and encode exported functions as BTF_KIND_FUNC - Add support for BTF_KIND_FUNC - Account inline type __aligned__ member types for spacing - Fix alignment of class members that are structs/enums/unions - Fixup handling classes with no members, solving a NULL deref - Avoid infinite loop trying to determine type with static data member of its own type. - type->type == 0 is void, fix --compile for that - Print DW_TAG_subroutine_type as well - Fix ptr_table__add_with_id() handling of pt->nr_entries, covering how BTF variables IDs are encoded - Allow passing the format path specifier, to use with BTF - Fixup issues pointed out by various coverity reports -- Domenico Andreoli Wed, 15 Jan 2020 18:02:11 +0100 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#914769: Closing, rust-bindgen is already packaged
Control: close -1 Hi Daniel, rust-bindgen is already packaged as cbindgen. Closing the bug. Thanks, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#941606: RFS: dwarves/1.15-2
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.15-2 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.15-2.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.15-2) unstable; urgency=low * Fix hardening-no-bindnow. * Fix debian-watch-uses-insecure-uri. * Fix debian-watch-does-not-check-gpg-signature. * Fix priority-extra-is-replaced-by-priority-optional. * Revert to dwarves-dbgsym for tests execution but skip the test if it's not installable (i.e. on transition to testing). -- Domenico Andreoli Mon, 23 Sep 2019 18:21:35 +0200 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#923717: closed by Domenico Andreoli (Bug#923717: fixed in dwarves-dfsg 1.15-1)
On Tue, Sep 03, 2019 at 10:16:50PM +0200, Paul Gevers wrote: > Hi Domencio, Hi Paul, > On 08-08-2019 21:40, Domenico Andreoli wrote: > >> So this libc-bin-dbgsym has no relation with dwarves? Than I guess it > > > > Indeed it has not any. > > > >> will work as you can always install the version from testing and no > >> relation will pull in the version from unstable. If that's the case, > >> just close the bug again. Otherwise, skip-not-installable *on top of* > >> other improvements will just mean that *if* any package is unsatisfiable > >> than the test is marked as skipped and as such adds a neutral result to > >> the final outcome. > > > > Thanks, I'll consider it. > > We overlooked one thing. Because your autopkgtest now depends on > libc-bin-dbgsym, when that package is updated, our migration software > will trigger a test for it. Due to the unfixed issue with debci, the > required version of libc-bin-dbgsym will not be available, and the test > will fail, blocking migration of glibc to testing. A glibc transition is > pending, this will be an issue. > > You can see that this is happening on, the test triggered with > "glibc/2.29-0experimental1 orafce/3.8.0-1 postgresql-12/12~beta3-1 > tracker/2.2.1-1": > https://ci.debian.net/packages/d/dwarves-dfsg/unstable/amd64/ I understand, I'm then reverting to dwarves-dbgsym and adding skip-not-installable. Thanks, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#923717: closed by Domenico Andreoli (Bug#923717: fixed in dwarves-dfsg 1.15-1)
Control: close -1 On Thu, Aug 08, 2019 at 09:33:18PM +0200, Paul Gevers wrote: > Hi Domenico, [also in To: to prevent the time lag] > > On 08-08-2019 00:35, Domenico Andreoli wrote: > >> On 30-07-2019 19:09, Debian Bug Tracking System wrote: > >>>* Autopkgtest on libc-bin-dbgsym instead of dwarves-dbgsym. Closes: > >>> #923717. > >> > >> Unless I am very much mistaken, this is not really fixing the issue. The > >> problem is that the unstable debug archive isn't available during > >> migration testing (that's bug #917528, to be fixed in debci). Hence, the > >> test will still fail if it needs the libc-bin-dbgsym package from > >> unstable. Please add the skip-not-installable restriction as I > >> recommended in my initial bug report. > > > > The "test" (much to be improved) just needs debug symbols for trying > > to analyze some binary. It's very simple test to prove that pahole does > > not die badly like when DWARF-4 has been introduced. > > > > At the moment does not really matter if such symbols are coming from > > testing or unstable as long as they match the version of the binary > > being analyzed. > > > > I thought to untangle a little bit the situation in using some binary > > different from dwarves itself, in that: > > > > dwarves/unstable + dwarves-dbgsym/testing => unsatisfiable > > > > Do you still think that skip-not-installable is better? Why? > > So this libc-bin-dbgsym has no relation with dwarves? Than I guess it Indeed it has not any. > will work as you can always install the version from testing and no > relation will pull in the version from unstable. If that's the case, > just close the bug again. Otherwise, skip-not-installable *on top of* > other improvements will just mean that *if* any package is unsatisfiable > than the test is marked as skipped and as such adds a neutral result to > the final outcome. Thanks, I'll consider it. Dom -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#923717: closed by Domenico Andreoli (Bug#923717: fixed in dwarves-dfsg 1.15-1)
On Tue, Jul 30, 2019 at 07:49:27PM +0200, Paul Gevers wrote: > Control: reopen -1 > > Hi Domenico, Hi Paul, hmm.. I'm not receiving messages from the bts in my mailbox, hence the late reply. > On 30-07-2019 19:09, Debian Bug Tracking System wrote: > >* Autopkgtest on libc-bin-dbgsym instead of dwarves-dbgsym. Closes: > > #923717. > > Unless I am very much mistaken, this is not really fixing the issue. The > problem is that the unstable debug archive isn't available during > migration testing (that's bug #917528, to be fixed in debci). Hence, the > test will still fail if it needs the libc-bin-dbgsym package from > unstable. Please add the skip-not-installable restriction as I > recommended in my initial bug report. The "test" (much to be improved) just needs debug symbols for trying to analyze some binary. It's very simple test to prove that pahole does not die badly like when DWARF-4 has been introduced. At the moment does not really matter if such symbols are coming from testing or unstable as long as they match the version of the binary being analyzed. I thought to untangle a little bit the situation in using some binary different from dwarves itself, in that: dwarves/unstable + dwarves-dbgsym/testing => unsatisfiable Do you still think that skip-not-installable is better? Why? thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#931142: Bts#931142: dwarves: New upstream version should be packaged
On Mon, Jul 29, 2019 at 10:32:38AM -0400, Theodore Y. Ts'o wrote: > On Mon, Jul 29, 2019 at 02:51:49PM +0200, Domenico Andreoli wrote: > > > > Here it is: https://mentors.debian.net/package/dwarves-dfsg > > > > I found not useful to reuse your git history as-is, although I could > > not drop your changelog entry ;) > > It looks like you did merge in my git changes, though? Hopefully it > *was* useful. :-) > > Did you take a look at the lintian reports on the mentors page? The > Warnings and Info reports all look pretty simple to resolve. Any > chance you could fix them up? Edited history again, just fixed the typo in the only patch. I could not find any other low hanging fruit, anything else requires some investigation (included the warnings on debian/copyright) I'd like to upload this first 1.15-1 so to not block anybody else playing with recent kernels on unstable. Thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#931142: Bts#931142: dwarves: New upstream version should be packaged
On Thu, Jul 25, 2019 at 01:29:50PM -0400, Theodore Y. Ts'o wrote: > On Thu, Jul 25, 2019 at 07:03:50PM +0200, Domenico Andreoli wrote: > > Hi Theodore, > > > > apologies, I'll prepare a new upload. Would you mind sponsoring it? > > Sure, I'd be happy to sponsor it. Here it is: https://mentors.debian.net/package/dwarves-dfsg I found not useful to reuse your git history as-is, although I could not drop your changelog entry ;) Thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#931142: Bts#931142: dwarves: New upstream version should be packaged
Hi Theodore, apologies, I'll prepare a new upload. Would you mind sponsoring it? Thank you for the contribution. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#930013: u-boot-sunxi: enable support for nanopi_neo_air board
Package: u-boot-sunxi Version: 2019.01+dfsg-7 Severity: wishlist Hi, Salsa MR #7 enables support for NanoPi NEO Air. I don't have the board but Philip may be available to do some testing. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
Hi, On Thu, May 23, 2019 at 09:18:26AM +0200, Domenico Andreoli wrote: > On Tue, May 14, 2019 at 11:22:14PM -0700, Vagrant Cascadian wrote: > > > ... > > I'm thinking we should just merge the flash-kernel support, which will > > make it much easier to test properly, and can be reverted if need be... > > Vagrant, can we merge it or do you want me to do some other test before? After flash-kernel 3.99 migrated to testing I could try the new d-i nightly build. I created the sdcard using the firmware+partitions approach and successfully installed and booted the new system. I'll send a complete installation report once RC2 is out. Now NanoPi Neo2 is supported out of the box, thanks everybody for the support :) Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On Tue, May 14, 2019 at 11:22:14PM -0700, Vagrant Cascadian wrote: > ... > I'm thinking we should just merge the flash-kernel support, which will > make it much easier to test properly, and can be reverted if need be... Vagrant, can we merge it or do you want me to do some other test before? I've the feeling that situation stalled but I don't see what could be the reason and what else I could do to unblock it. I see a glowing green button "Merge" on Salsa, and I could even press it, but is there any planned upload of the package? > > Since kibi merged the NanoPI NEO 2 debian-installer support, and I just > added support for SD-card-images, it should be much easier to test. > When the daily images for 20190516 are generated they should include > "netboot/SD-card-images" for several allwinner arm64 boards: > > https://d-i.debian.org/daily-images/arm64/ > > Then, as long as you don't rewrite the partition table, you should be > able to install to microSD and it won't create a GPT partition table and > won't use grub-efi... and it should use the flash-kernel boot.scr! As reported in [0], the installer worked nicely except that it did not create any boot.scr, I did not make any tweak during the installation. > > live well, > vagrant thanks, Domenico [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928863 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928863: debian-installer: Add support for NanoPi NEO2
On Tue, May 14, 2019 at 07:08:31PM +0200, Cyril Brulebois wrote: > Hi, Hi Cyril, > Domenico Andreoli (2019-05-14): > > > I suppose we could merge this and let you test and report what > > > happens with daily builds. Would that be fine with you? > > > > Of course it's fine with me. > > Great! Just pushed an updated master; you should find updated images in > a couple of hours here: > https://d-i.debian.org/daily-images/daily-build-overview.html > https://d-i.debian.org/daily-images/arm64/daily/ > I've just verified that the build of today works perfectly on my board. I assembled the sdcard image as per instructions [0] and installed the system without any issue. Fantastic! flash-kernel support is not yet merged [1] so I could not boot the newly installed system but after the installation u-boot is still in place and I expect that as soon [1] is merged everything would be fine. I'd be delighted to see it in RC2... ;) Thanks, Domenico [0] https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/README.concatenateable_images [1] https://salsa.debian.org/installer-team/flash-kernel/merge_requests/5 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On Wed, May 15, 2019 at 08:06:53AM -0700, Vagrant Cascadian wrote: > On 2019-05-15, Domenico Andreoli wrote: > > Scanning mmc 0:2... > > Found /boot/extlinux/extlinux.conf > > Retrieving file: /boot/extlinux/extlinux.conf > > 753 bytes read in 12 ms (60.5 KiB/s) > > U-Boot menu > > 1: Debian GNU/Linux kernel 4.19.0-4-arm64 > > 2: Debian GNU/Linux kernel 4.19.0-4-arm64 (rescue target) > > Enter choice: 1:Debian GNU/Linux kernel 4.19.0-4-arm64 > > To test flash-kernel's boot.scr, you'll need to remove or disable > checking for extlinux.conf, since that comes before loading the boot.scr > that flash-kernel produces. Right, sharp eye! > > From the u-boot prompt unset the the variable that checks for extlinux: > > setenv scan_dev_for_extlinux false > > Alternately, remove /boot/extlinux/extlinux.conf and reboot. Ok, uninstalled u-boot-menu and grub packages (and all the related config & co files). Emptied the first partition and moved /boot into it. Now the system boots without manual intervention, no user/grub clutters the bootlog any more ;) U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) DRAM: 1024 MiB Trying to boot from MMC1 NOTICE: BL31: v2.0(debug): NOTICE: BL31: Built : 23:33:29, Nov 27 2018 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: Found U-Boot DTB at 0x407f100, model: FriendlyARM NanoPi NEO 2 INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design. INFO:BL31: Platform setup done INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x4a00 INFO:SPSR = 0x3c9 U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... Unable to use mmc 0:1... In:serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c3 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 2228 bytes read in 5 ms (434.6 KiB/s) ## Executing script at 4fc0 18558832 bytes read in 824 ms (21.5 MiB/s) 16815 bytes read in 10 ms (1.6 MiB/s) 24721329 bytes read in 1092 ms (21.6 MiB/s) Booting Debian 4.19.0-4-arm64 from mmc 0:1... ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Ramdisk to 4886c000, end 49fff7b1 ... OK Loading Device Tree to 48864000, end 4886b1ae ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] [0.00] Linux version 4.19.0-4-arm64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15) [0.00] Machine model: FriendlyARM NanoPi NEO 2 [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 64 MiB at 0x7c00 [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x7fff] [0.00] NUMA: NODE_DATA [mem 0x7bfdd5c0-0x7bfded7f] [0.00] Zone ranges: [0.00] DMA32[mem 0x4000-0x7fff] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x4000-0x7fff] [0.00] Initmem setup node 0 [mem 0x4000-0x7fff] [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.1 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: MIGRATE_INFO_TYPE not supported. [0.00] psci: SMC Calling Convention v1.1 [0.00] random: get_random_bytes called from start_kernel+0x9c/0x4c0 with crng_init=0 [0.00] percpu: Embedded 24 pages/cpu @(ptrval) s60120 r8192 d29992 u98304 [0.00] Detected VIPT I-cache on CPU0 [0.00] CPU features: enabling workaround for ARM erratum 845719 [0.00] Speculative Store Bypass Disable mitigation not required [0.00] CPU features: detected: Kernel page table isolation (KPTI) [0.00] Built 1 zonelists, mobility grouping on. Total pages: 258048 [0.00] Policy zone: DMA32
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On Tue, May 14, 2019 at 11:02:14AM -0700, Vagrant Cascadian wrote:
> On 2019-05-14, Domenico Andreoli wrote:
> >
...
> u-boot will look for a partition marked bootable, which is different for
> GPT partition tables, and falls back to the first partition if neither
> an msdos bootable partition nor a gpt bootable partition is found.
>
> You can interrupt the boot process at the u-boot prompt and change...:
>
> editenv scan_dev_for_boot_part
>
> change:
>
> ... env exists devplist || setenv devplist 1 ...
>
> to:
>
> ... env exists devplist ; setenv devplist 3 ...
>
> Assuming partition 3 is where /boot/boot.scr resides.
editenv.. nice, I did not know it. Anyway, here is the bootlog:
U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.0(debug):
NOTICE: BL31: Built : 23:33:29, Nov 27 2018
NOTICE: BL31: Detected Allwinner H5 SoC (1718)
NOTICE: BL31: Found U-Boot DTB at 0x407f100, model: FriendlyARM NanoPi NEO 2
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design.
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9
U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology
CPU: Allwinner H5 (SUN50I)
Model: FriendlyARM NanoPi NEO 2
DRAM: 1 GiB
MMC: SUNXI SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: phy interface7
eth0: ethernet@1c3
starting USB...
USB0: USB EHCI 1.00
USB1: USB OHCI 1.0
USB2: USB EHCI 1.00
USB3: USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
=>
=>
=>
=>
=>
=>
=>
=> editenv scan_dev_for_boot_part
edit: part list ${devtype} ${devnum} -bootable devplist; env exists devplist;
setenv devplist 2; for distro_bootpart
=>
=>
=>
=> boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:2...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
753 bytes read in 12 ms (60.5 KiB/s)
U-Boot menu
1: Debian GNU/Linux kernel 4.19.0-4-arm64
2: Debian GNU/Linux kernel 4.19.0-4-arm64 (rescue target)
Enter choice: 1:Debian GNU/Linux kernel 4.19.0-4-arm64
Retrieving file: /boot/initrd.img-4.19.0-4-arm64
24721329 bytes read in 1119 ms (21.1 MiB/s)
Retrieving file: /boot/vmlinuz-4.19.0-4-arm64
18558832 bytes read in 839 ms (21.1 MiB/s)
append: root=UUID=ffb5c903-632b-49c7-a435-885cc2490423 ro panic=7
Retrieving file:
/usr/lib/linux-image-4.19.0-4-arm64/allwinner/sun50i-h5-nanopi-neo2.dtb
16815 bytes read in 32 ms (512.7 KiB/s)
## Flattened Device Tree blob at 4fa0
Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
Loading Ramdisk to 4886c000, end 49fff7b1 ... OK
Loading Device Tree to 48864000, end 4886b1ae ... OK
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 4.19.0-4-arm64 (debian-ker...@lists.debian.org)
(gcc version 8.3.0 (Debian 8.3.0-2)) #1SMP Debian 4.19.28-2 (2019-03-15)
[0.00] Machine model: FriendlyARM NanoPi NEO 2
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 64 MiB at 0x7c00
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem
0x-0x7fff]
[0.00] NUMA: NODE_DATA [mem 0x7bfdd5c0-0x7bfded7f]
[0.00] Zone ranges:
[0.00] DMA32[mem 0x4000-0x7fff]
[0.00] Normal empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x4000-0x7fff]
[0.00] Initmem setup node 0 [mem 0x4000-0x7fff]
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] psci: SMC Calling Convention v1.1
[0.00] random: get_random_bytes called from start_kernel+0x9c/0x4c0
with crng_init=0
[0.00] percpu: Embedded 24 pages/cpu @(ptrval) s60120 r8192
d29992 u98304
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: enabling workaround for ARM erratum 845719
[0.00
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On Sun, May 12, 2019 at 10:13:50AM -0700, Vagrant Cascadian wrote: > On 2019-05-12, Karsten Merker wrote: > > On Sun, May 12, 2019 at 10:40:39AM +0200, Domenico Andreoli wrote: > > > ... > > > > > > Please mind that the NanoPi NEO 2 target for u-boot has just been merged > > > in sid so it's not yet in Buster. > ... > > while the change looks ok to me, I'd very much prefer if it was > > actually tested before committing it (the same is true for > > bug#928863). > > Would it be ok to test it in-place on an installed system by adding the > entry to /etc/flash-kernel/db? That's how I usually test boards I've > added. Or do you not have an installed system? Yes, I've a running system and the locally built flash-kernel now creates a nice boot.scr in /boot. Now the problem is that my first partition is for EFI (I installed with regular Buster RC1 installer) and so u-boot does not find the newly created boot.scr and just goes with grub. If I put the boot.scr in the EFI partition, grub is still used. I'm a bit struggling to understand why. I'll try to manually boot with boot.scr, just to validate it. > > It's a bit difficult to fully test within debian-installer, as the > installer typically pulls in .udebs from the archive, and you have a bit > of chicken-and-egg problem to require testing from d-i, or a lot of > manual fiddling within the installer. You could also patch > /target/etc/flash-kernel/db or /target/usr/share/flash-kernel/db from > within the install at just the right moment ... Thanks for the trick but you don't say when it's the right moment :) Aside from that, a few other things are not clear to me: * is it true that Debian arm64 implies UEFI+grub? if not, how does e.g. Pine64 handle bare u-boot vs u-boot + grub? * is the partition table label (msdos vs. gpt) dependent on the board? if not, how does e.g. Pine64 handle GPT + spl? Is an updated flash-kernel-installer udeb going to automagically solve all the above issues or am I missing some other moving part here? I'm definitively impressed by the evolution reached to handle all the specially crafted variants supported out of the box. Thanks for the support. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928863: debian-installer: Add support for NanoPi NEO2
On Tue, May 14, 2019 at 02:42:01PM +0200, Cyril Brulebois wrote: > Hi Domenico, Hi Cyril, > Domenico Andreoli (2019-05-12): > > please consider adding the generation of the installer image file > > for FriendlyArm NanoPi NEO 2. MR is available on Salsa: > > > > https://salsa.debian.org/installer-team/debian-installer/merge_requests/9 > > At first glance, that looks good to me. > > > I was not able to cross-build the arm64 installer from amd64 so the > > patch is not tested. > > I suppose we could merge this and let you test and report what happens > with daily builds. Would that be fine with you? Of course it's fine with me. > > > Please mind that the NanoPi NEO 2 target for u-boot has just been > > merged in sid so it's not yet in Buster. > > I see that Vagrant already spotted the needed bump to Build-Depends. :) I already fixed it, the MR is updated. > > That shouldn't stop us from merging your work right now, I can always > hint u-boot into buster, should we need it; but thanks for mentioning it > anyway! Thanks a lot :) Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2
On Thu, May 09, 2019 at 10:08:07AM +0300, Andrei POPESCU wrote: > On Jo, 09 mai 19, 07:58:39, Domenico Andreoli wrote: > > > > I aim at the most streamlined installation with the most support out > > of the box and least divergence from a standard setup. I've got a fully > > reproducible and, I hope, maintainable installation. > > See https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64 for a > general outline of my steps. I was missing the flash-kernel support, I've just created a MR for it [0]. Would expect grub is not be needed on nanopi_neo2 then. > > For devices without a pre-made image with u-boot there are two > additional steps required: create the partition table (easy) and install > u-boot (undocumented). I also made the MR for adding the pre-made image [1]. I hope it will be included in next RC2 ;) > > For sunxi devices there is u-boot-install-sunxi64, but it only supports > a handful of devices. Vagrant has just merged support nanopi_neo2 there [2]. > > Hope this helps, > Andrei Thanks, Domenico [0] https://salsa.debian.org/installer-team/flash-kernel/merge_requests/5 [1] https://salsa.debian.org/installer-team/debian-installer/merge_requests/9 [2] https://salsa.debian.org/debian/u-boot/merge_requests/5 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928863: debian-installer: Add support for NanoPi NEO2
Package: debian-installer Version: 20190410 Severity: wishlist Tags: patch Dear Maintainer, please consider adding the generation of the installer image file for FriendlyArm NanoPi NEO 2. MR is available on Salsa: https://salsa.debian.org/installer-team/debian-installer/merge_requests/9 I was not able to cross-build the arm64 installer from amd64 so the patch is not tested. Please mind that the NanoPi NEO 2 target for u-boot has just been merged in sid so it's not yet in Buster. Thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
Package: flash-kernel Version: 3.98 Severity: wishlist Tags: patch Dear Maintainer, please add the new entry for supporting FriendlyArm NanoPi NEO 2. Patch is attached but also MR is available on Salsa: https://salsa.debian.org/installer-team/flash-kernel/merge_requests/5 This is the entry: +Machine: FriendlyARM NanoPi NEO 2 +Kernel-Flavors: arm64 +Boot-Script-Path: /boot/boot.scr +DTB-Id: allwinner/sun50i-h5-nanopi-neo2.dtb +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + I was not able to cross-build the arm64 installer from amd64 so the patch is not tested. Please mind that the NanoPi NEO 2 target for u-boot has just been merged in sid so it's not yet in Buster. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 commit 6ccf67adb6b44e7b7173420840b7d564f328020e Author: Domenico Andreoli Date: Sun May 12 09:49:10 2019 +0200 Add support for NanoPi NEO2 diff --git a/db/all.db b/db/all.db index 0839d50..fe740ae 100644 --- a/db/all.db +++ b/db/all.db @@ -481,6 +481,13 @@ DTB-Id: sun8i-h3-nanopi-neo-air.dtb U-Boot-Script-Name: bootscr.sunxi Required-Packages: u-boot-tools +Machine: FriendlyARM NanoPi NEO 2 +Kernel-Flavors: arm64 +Boot-Script-Path: /boot/boot.scr +DTB-Id: allwinner/sun50i-h5-nanopi-neo2.dtb +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Gemei G9 Tablet Kernel-Flavors: armmp Boot-Script-Path: /boot/boot.scr signature.asc Description: PGP signature
Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2
On Wed, May 08, 2019 at 06:28:28PM +0200, Domenico Andreoli wrote: > On Tue, May 07, 2019 at 09:50:58AM -0700, Vagrant Cascadian wrote: > > On 2019-05-07, Domenico Andreoli wrote: > > > Salsa MR #5 enables support for NanoPi NEO 2. I tested it with Buster > > > RC1 installer, althought it resulted in a non-bootable system u-boot > > > worked well enough. > > > > Just for clarity, you're saying the non-bootability was unrelated to > > u-boot, but u-boot was able to boot a kernel + initrd + dtb? [...] > Need to further investigate why u-boot cannot continue the boot. I > don't know how a properly working arm64 world looks like and what's > missing from my installation, if it's not just grub. > > I am not able to quickly hack a boot, the kernel is not just a familiar > zImage and bootz is not even available. It must have something to do > with all this UEFI order of things for which I need grub (or not?) ;) > Last minute update is that I run the Buster RC1 installer in rescue mode and installed grub as removable device. Now u-boot loads grub nicely and from there the system is booted flawlessly. The normal method of installing grub fails because no UEFI is there to handle the configuration of the new entry: Installing for arm64-efi platform. grub-install: warning: Cannot set EFI variable Boot. grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: Input/output error. grub-install: warning: efivarfs_set_variable: failed to unlink /sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c: Invalid argument. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Input/output error. grub-install: error: failed to register the EFI boot entry: Input/output error. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#928612: u-boot-sunxi: Enable support for NanoPi NEO2
Hi, On Tue, May 07, 2019 at 09:50:58AM -0700, Vagrant Cascadian wrote: > On 2019-05-07, Domenico Andreoli wrote: > > Salsa MR #5 enables support for NanoPi NEO 2. I tested it with Buster > > RC1 installer, althought it resulted in a non-bootable system u-boot > > worked well enough. > > Just for clarity, you're saying the non-bootability was unrelated to > u-boot, but u-boot was able to boot a kernel + initrd + dtb? u-boot is able to find the USB stick with the Buster RC1 installer and boot it. I made many cycles, this happens reliably. The first road block is the partitioner, if let alone it creates a regular GPT (don't know if it could be instructed to create a legacy MBR instead) and so overwrites the spl+u-boot leaving the board completely unbootable. To work around this, I prepare the GPT manually with the famous 4 entries (see the extra menu in fdisk) and configure the partitions at my wish, then the installer can reuse them preserving my hand crafted GPT and the bootability up to u-boot. The installation process goes nicely but grub installation fails, as it seems to be expected [0]. The board is left unbootable. This is where I am, so booting kernel+initrd+dtb: yes (the installer from USB), no (the just installed system). To be fair, I should check that the installer can be executed via tftp and via partition on the sdcard before claiming it's all fine with u-boot on this board. Need to further investigate why u-boot cannot continue the boot. I don't know how a properly working arm64 world looks like and what's missing from my installation, if it's not just grub. I am not able to quickly hack a boot, the kernel is not just a familiar zImage and bootz is not even available. It must have something to do with all this UEFI order of things for which I need grub (or not?) ;) > > I made some comments on the merge request to reduce the diff so it would > be possible to get into buster. I think I addressed all your comments, MR #5 is updated for sid while #6 is ready for master. > > Thanks! > > live well, > vagrant thanks, Domenico [0] https://wiki.debian.org/InstallingDebianOn/Allwinner -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#928643: u-boot-sunsi: Allow u-boot-install-sunxi64 on GPT with up to 4 entries
Package: u-boot-sunxi Severity: wishlist Hi, Salsa MR #6 adds support for GPT partition tables with up to 4 entries to u-boot-install-sunxi64. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#928612: u-boot-sunxi: enable support for nanopi_neo2 board
Package: u-boot-sunxi Version: 2019.01+dfsg-5 Severity: wishlist Hi, Salsa MR #5 enables support for NanoPi NEO 2. I tested it with Buster RC1 installer, althought it resulted in a non-bootable system u-boot worked well enough. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
On Wed, Feb 27, 2019 at 02:10:06PM +0100, Adam Borowski wrote: > On Wed, Feb 27, 2019 at 09:33:43AM +0100, Domenico Andreoli wrote: > > On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote: > > > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote: > > > > * Package name: dwarves-dfsg > > > > Version : 1.12-2 > > > > > * Update copyright to copyright-format/1.0. Closes: #919356. > > > > The new copyright file contains references to GPL-2.0-only and > > > GPL-2.0-or-later without defining them. > > > > According to https://spdx.org/licenses/ they are defined and supersede > > GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm > > reading that as long as copyright-format is not updated, new ones should > > not be used. > > SPDX has nothing to the copyright-format. The latter doesn't care about > short names at all, merely that 1. every file has a license, and 2. every > license is defined. > > Thus, "GPL-2", "GPL-2+", "GPL-2.0-only", "GPL-2.0-or-later", "Meow-meow" > and "Cthulhu-fhtagn" have exactly the same meaning: they're merely > identifiers that need to be defined elsewhere in the file. Obviously, > for human readers we still want GPL to mean GPL -- but it's a syntax vs > content distinction. Got it, in my mind the two things were related. There is even a paragraph that says "For SPDX compatibility, versions with trailing dot-zeroes are considered to be equivalent to versions without (e.g., “2.0.0” is considered equal to “2.0” and “2”)." but I cannot ignore the one saying: "Use of a standard short name does not override the Debian Policy requirement to include the full license text in debian/copyright, nor any requirements in the license of the work regarding reproduction of legal notices. This information must still be included in the License field, either in a stand-alone License paragraph or in the relevant files paragraph." > > I spent quite some time in trying to understand what lintian tries > > to tell me here. I verified that reshuffling the file does not help > > either, these errors stay in a similar location, as if lintian had some > > bug somewhere. > > "references a license, for which no standalone license paragraph exists" I evidently read too little and assumed too much. > > I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly. > > I don't see it on mentors yet... I rewrote history and pushed a new 1.12-2 release to mentors. Thanks again for the feedback. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote: > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote: > > * Package name: dwarves-dfsg > > Version : 1.12-2 > > > Changes since the last upload: > > > > dwarves-dfsg (1.12-2) unstable; urgency=medium > > > > * Convert to dh. > > * Fix Homepage and Vcs-Git. > > * Fix depends on debhelper >= 10. > > * Remove trailing spaces from the Debian changelog. > > * Update copyright to copyright-format/1.0. Closes: #919356. > > Hi! Hi, > The new copyright file contains references to GPL-2.0-only and > GPL-2.0-or-later without defining them. According to https://spdx.org/licenses/ they are defined and supersede GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm reading that as long as copyright-format is not updated, new ones should not be used. Anyway, this is what I get if I switch to GPL-2 and GPL-2+ everywhere: W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2+ (paragraph at line 102) N: N:The files paragraph in the machine readable copyright file references a N:license, for which no standalone license paragraph exists. N: N:Refer to N:https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for N:details. N: N:Severity: normal, Certainty: possible N: N:Check: source-copyright, Type: source N: W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2 (paragraph at line 94) I spent quite some time in trying to understand what lintian tries to tell me here. I verified that reshuffling the file does not help either, these errors stay in a similar location, as if lintian had some bug somewhere. I also expected they to be repeated as many times as in the files (yes, I'm using --no-tag-display-limit -i) but they are not and so at certain point I gave up. I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly. Thanks for reviewing. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
Package: sponsorship-requests Severity: important Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.12-2 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.12-2.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.12-2) unstable; urgency=medium * Convert to dh. * Fix Homepage and Vcs-Git. * Fix depends on debhelper >= 10. * Remove trailing spaces from the Debian changelog. * Update copyright to copyright-format/1.0. Closes: #919356. -- Domenico Andreoli Wed, 26 Dec 2018 17:40:31 +0100 Kind regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#922112: Add the SPDX header to include/linux/hash.h
From: Domenico Andreoli It is unlikely that who contributes to this file is unaware of the kernel licensing but bringing the license statement into the file itself makes it properly reusable in different contexts. CC: Daniel Borkmann CC: Francesco Fusco CC: George Spelvin CC: Hannes Frederic Sowa CC: Ian Campbell CC: Jay Vosburgh CC: Jens Axboe CC: Linus Torvalds CC: Masami Hiramatsu CC: Matthew Wilcox CC: Nadia Yvette Chambers CC: Pavel Emelyanov Signed-off-by: Domenico Andreoli --- include/linux/hash.h |2 ++ 1 file changed, 2 insertions(+) Index: b/include/linux/hash.h === --- a/include/linux/hash.h +++ b/include/linux/hash.h @@ -1,3 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + #ifndef _LINUX_HASH_H #define _LINUX_HASH_H /* Fast hashing routine for ints, longs and pointers.
Bug#922112: fio: hash.h is not DFSG compliant
Package: fio Severity: grave According to debian/copyright, hash.h is licensed as GPL-2+ but this is not true. There is not any mention of license attribution in its verifiable history, not by its copyright holder or anybody else on their behalf. Thanks to Ulrich Mueller for the relevant research [0]. Similar bug is reported to package dwarves [1], which includes on older copy of this same file. Regards, Domenico [0] https://lkml.org/lkml/2019/2/11/773 [1] https://bugs.debian.org/919356 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Licensing of include/linux/hash.h
On Mon, Feb 11, 2019 at 12:08:32AM +0100, Kristian Fiskerstrand wrote: > On 1/23/19 9:50 AM, Domenico Andreoli wrote: > > Ben Finney writes: > >> Domenico Andreoli writes: [...] > >>> the only knot left is now the license of hash.h > >>> > >>> This file is also present in the kernel [0] with an updated copyright > >>> but still without license. [...] > >> To know that work (that file) is free software, we need a clear grant of > >> some specific license, for that work. > >> > >> If the work is not free, it would be incorrect to have the work in Debian. > > > > Is it possible that for the kernel it is instead correct because it is, > > as whole, covered by its COPYING? > > > >> Alternatives, for complying with the Debian Free Software Guidelines with > >> this package, include: > >> > >> * Find a credible grant of license under some GPL-compatible free > >> license to that exact file. Document that explicit grant in the Debian > >> package. This demonstrates the work is DFSG-free. > >> > >> * Convince ???dwarves-dfsg??? upstream to replace that file with a > >> different > >> implementation (I don't know whether such an implementation exists) > >> under a license compatible with the same version of GNU GPL. Document > >> that explicit grant in the Debian package. This demonstrates the > >> modified work is DFSG-free. > >> > >> * Replace that file in Debian only, with a different implementation as > >> above. Document that explicit grant in the Debian package. This > >> demonstrates the modified Debian package is DFSG-free. > >> > >> * Move the work to the ???non-free??? area. > >> > >> * Remove the work altogether. > >> > >> Those are in descending order of (my recommended) preference. [...] > It was [pointed out] by one of our license group that [hash.h] is the > same that has a GPL-2+ in [fio] which has a signed-off-by. > > References: > [pointed out] > https://bugs.gentoo.org/677586#c1 > > [hash.h] > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c Yes, the Signed-off-by is from Jens Axboe (in CC) but he's not the original author, I guess he just copied the file as Arnaldo did. The file he committed has not any reference to the license. > [fio] > https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright I'm afraid that this entry in wrong. I'll seek confirmation with Martin Steigerwald. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Licensing of include/linux/hash.h
Ben Finney writes: > Domenico Andreoli writes: > > > the situation of dwarves-dfsg improved a lot over the weekend > > That's good to hear. What is the event you're referring to? Can you give > a URL to something that describes this change? Upstream (in CC) reacted to my request of clarification and patches have been applied upstream and on Salsa. See bug 919356 [0] (please keep in CC). > > the only knot left is now the license of hash.h > > > > This file is also present in the kernel [0] with an updated copyright > > but still without license. > > The file you show (in the Linux code base) seems likely to have an > equivalent implementation under a different license, from some other > code base. This will require research and work unlikely to be done before Buster release. Are we going to drop this package for now? > > I received a private email from somebody in the kernel community who > > already tried to contact Nadia in the past but did not get any reply. > > Thank you also for contacting the Linux developers forum to ask > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1900588.html>. (also in CC now) > > I think that pushing it to non-free is formally the right thing but I > > actually feel it's not the right thing. > > To know that work (that file) is free software, we need a clear grant of > some specific license, for that work. > > If the work is not free, it would be incorrect to have the work in Debian. Is it possible that for the kernel it is instead correct because it is, as whole, covered by its COPYING? > Alternatives, for complying with the Debian Free Software Guidelines with > this package, include: > > * Find a credible grant of license under some GPL-compatible free > license to that exact file. Document that explicit grant in the Debian > package. This demonstrates the work is DFSG-free. > > * Convince ‘dwarves-dfsg’ upstream to replace that file with a different > implementation (I don't know whether such an implementation exists) > under a license compatible with the same version of GNU GPL. Document > that explicit grant in the Debian package. This demonstrates the > modified work is DFSG-free. Arnaldo, what priority would you give to this task? > > * Replace that file in Debian only, with a different implementation as > above. Document that explicit grant in the Debian package. This > demonstrates the modified Debian package is DFSG-free. > > * Move the work to the ‘non-free’ area. > > * Remove the work altogether. > > Those are in descending order of (my recommended) preference. Thanks, Domenico [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919356 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Fw: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
[need to re-CC debian-legal again, sorry.] On Tue, Jan 22, 2019 at 06:05:37PM +0100, Domenico Andreoli wrote: > On Mon, Jan 21, 2019 at 03:58:19PM +, MJ Ray wrote: > > Missed the bug off the CC for this. Sorry. > > It seems it did not arrive to debian-legal either. > > > Begin forwarded message: > > > > Date: Mon, 21 Jan 2019 13:34:13 + > > From: MJ Ray > > To: debian-le...@lists.debian.org > > Subject: Re: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear > > > > > > Domenico Andreoli skribis: > > > > > the situation of dwarves-dfsg improved a lot over the weekend, the > > > only knot left is now the license of hash.h > > > > > > This file is also present in the kernel [0] with an updated copyright > > > but still without license. > > > > > > I received a private email from somebody in the kernel community who > > > already tried to contact Nadia in the past but did not get any reply. > > > [...] > > > [0] > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h > > > > > > > One of the commits to that file is from Nadia. Sorry if I'm being > > dense, but where does the doubt that it is under the kernel's licence > > arise? > > The file does not mention any license. While the kernel has its blanket > license, dwarves has not any. > > Can I simply claim it's a GPL-2.0-only? I mean, I think it's reasonable > and, as you said, it's unlikely that Nadia did not notice it was in > the kernel but I wanted a second opinion. > > Do you thin I could even add the SPDX? > > Thanks, > Domenico > > -- > 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: Fw: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
On Mon, Jan 21, 2019 at 03:58:19PM +, MJ Ray wrote: > Missed the bug off the CC for this. Sorry. It seems it did not arrive to debian-legal either. > Begin forwarded message: > > Date: Mon, 21 Jan 2019 13:34:13 + > From: MJ Ray > To: debian-le...@lists.debian.org > Subject: Re: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear > > > Domenico Andreoli skribis: > > > the situation of dwarves-dfsg improved a lot over the weekend, the > > only knot left is now the license of hash.h > > > > This file is also present in the kernel [0] with an updated copyright > > but still without license. > > > > I received a private email from somebody in the kernel community who > > already tried to contact Nadia in the past but did not get any reply. > > [...] > > [0] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h > > > > One of the commits to that file is from Nadia. Sorry if I'm being > dense, but where does the doubt that it is under the kernel's licence > arise? The file does not mention any license. While the kernel has its blanket license, dwarves has not any. Can I simply claim it's a GPL-2.0-only? I mean, I think it's reasonable and, as you said, it's unlikely that Nadia did not notice it was in the kernel but I wanted a second opinion. Do you thin I could even add the SPDX? Thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
Hallo d-l, the situation of dwarves-dfsg improved a lot over the weekend, the only knot left is now the license of hash.h This file is also present in the kernel [0] with an updated copyright but still without license. I received a private email from somebody in the kernel community who already tried to contact Nadia in the past but did not get any reply. I need advice on how to handle the package, it is all GPL 2.0 with just this exception. I think that pushing it to non-free is formally the right thing but I actually feel it's not the right thing. Regards, Domenico [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 03:45:03PM -0200, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 18, 2019 at 06:30:38PM +0100, Domenico Andreoli escreveu: > > From: Domenico Andreoli > > > > Hi Arnaldo, > > > > I noticed that some files of pahole come without licensing and > > copyright information, this makes Debian struggle with the redistribution > > and, unfortunately, puts the inclusion of pahole into coming release > > at risk. > > > > For your convenience, I attached a patch that adds the info where > > missing and also adopts the SPDX notation. > > Thanks, I've added the fb team involved in recent changes to this > package so that they are aware of it and can voice any concern, folks > anything to say about this? Is everything okay? > > I'm tentatively adding this to my repo, hope to tag 1.13 soon. Excellent! Would be also nice to have the COPYING file to cover every other file without explicit copyright. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 03:34:04PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 18, 2019 at 03:33:25PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu: > > > On Fri, Jan 18, 2019 at 03:45:03PM -0200, Arnaldo Carvalho de Melo wrote: > > > > Em Fri, Jan 18, 2019 at 06:30:38PM +0100, Domenico Andreoli escreveu: > > > > > From: Domenico Andreoli > > > > > > > > > > Hi Arnaldo, > > > > > > > > > > I noticed that some files of pahole come without licensing and > > > > > copyright information, this makes Debian struggle with the > > > > > redistribution > > > > > and, unfortunately, puts the inclusion of pahole into coming release > > > > > at risk. > > > > > > > > > > For your convenience, I attached a patch that adds the info where > > > > > missing and also adopts the SPDX notation. > > > > > > > > Thanks, I've added the fb team involved in recent changes to this > > > > Hey, is that I problem for me to take your GPG signature as an indicator > > I can add a: > > > > Signed-off-by: Domenico Andreoli > > Or better: > > Signed-off-by: Domenico Andreoli yes, as in my original patch ;) > since that is the one you used in the From: line, ok? > > > ? > > > > > > package so that they are aware of it and can voice any concern, folks > > > > anything to say about this? Is everything okay? > > > No concern on adding the SPDX notation. > > > I would like to add my employer to a few btf files: > > > > > > + Copyright (c) 2018 Facebook > > > > > > > > btf_encoder.c| 6 ++ > > > > > btf_encoder.h| 5 + > > > > > libbtf.c | 6 ++ > > > > > libbtf.h | 6 ++ > > > > > libctf.c | 6 ++ > > > > > > Thanks! > > > Martin > > > > -- > > > > - Arnaldo > > -- > > - Arnaldo -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 08:02:40PM +0100, Domenico Andreoli wrote: > On Fri, Jan 18, 2019 at 03:44:27PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jan 18, 2019 at 03:41:33PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Fri, Jan 18, 2019 at 03:28:33PM -0300, Arnaldo Carvalho de Melo > > > escreveu: > > > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu: > > > > > No concern on adding the SPDX notation. > > > > > I would like to add my employer to a few btf files: > > > > > > > + Copyright (c) 2018 Facebook > > > > > > Sure, I'll add a patch, authored by you, with a signed-off-by you, etc, > > > > CC the group and signed by me as well, just like the kernel process. On > > > > top of Domenico's patch. > > > > > > Now I noticed that the patch adds Copyright entries as well, so I'm > > > fixing it up, as libbtf.[ch] I haven't authored, and btf_encoder.[ch] > > > where authored by Facebook engineers based on ctf_encoder.[ch] that I'm > > > the author, so I'm just fixing these things up in Martin's follow up > > > patch. > > > > End result, ok? > > yes, thanks! > > > > > commit 1610b9b4327d14589800606fc4d31229eb8f1daf > > Author: Martin Lau > > Date: Fri Jan 18 15:42:37 2019 -0300 > > > > Fixup copyright notices for BTF files authored by Facebook engineers > > > > Cc: Andrii Nakryiko > > Cc: Domenico Andreoli > > Cc: Yonghong Song > > Signed-off-by: Martin Lau > > Signed-off-by: Arnaldo Carvalho de Melo > > could please add also mine? well, only to my original patch obviously, not this. > Signed-off-by: Domenico Andreoli > -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#919356: [PATCH] Add missing licensing info
On Fri, Jan 18, 2019 at 03:44:27PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 18, 2019 at 03:41:33PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Jan 18, 2019 at 03:28:33PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Fri, Jan 18, 2019 at 06:24:52PM +, Martin Lau escreveu: > > > > No concern on adding the SPDX notation. > > > > I would like to add my employer to a few btf files: > > > > > + Copyright (c) 2018 Facebook > > > > Sure, I'll add a patch, authored by you, with a signed-off-by you, etc, > > > CC the group and signed by me as well, just like the kernel process. On > > > top of Domenico's patch. > > > > Now I noticed that the patch adds Copyright entries as well, so I'm > > fixing it up, as libbtf.[ch] I haven't authored, and btf_encoder.[ch] > > where authored by Facebook engineers based on ctf_encoder.[ch] that I'm > > the author, so I'm just fixing these things up in Martin's follow up > > patch. > > End result, ok? yes, thanks! > > commit 1610b9b4327d14589800606fc4d31229eb8f1daf > Author: Martin Lau > Date: Fri Jan 18 15:42:37 2019 -0300 > > Fixup copyright notices for BTF files authored by Facebook engineers > > Cc: Andrii Nakryiko > Cc: Domenico Andreoli > Cc: Yonghong Song > Signed-off-by: Martin Lau > Signed-off-by: Arnaldo Carvalho de Melo could please add also mine? Signed-off-by: Domenico Andreoli > > diff --git a/btf_encoder.c b/btf_encoder.c > index 613e7e9a6d43..7aed9b454c1f 100644 > --- a/btf_encoder.c > +++ b/btf_encoder.c > @@ -1,7 +1,12 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > + > + Derived from ctf_encoder.c, which is: > + > + Copyright (C) Arnaldo Carvalho de Melo > + Copyright (C) Red Hat Inc > */ > > #include "dwarves.h" > diff --git a/btf_encoder.h b/btf_encoder.h > index daf5d372986a..80237bb4ca61 100644 > --- a/btf_encoder.h > +++ b/btf_encoder.h > @@ -3,7 +3,10 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > + > + Derived from ctf_encoder.h, which is: > + Copyright (C) Arnaldo Carvalho de Melo > */ > > struct cu; > diff --git a/libbtf.c b/libbtf.c > index 64437f3bd2d9..c6ece9d84de5 100644 > --- a/libbtf.c > +++ b/libbtf.c > @@ -1,7 +1,7 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > */ > > #include > diff --git a/libbtf.h b/libbtf.h > index ef1c49804a20..780f3ec888d7 100644 > --- a/libbtf.h > +++ b/libbtf.h > @@ -1,7 +1,7 @@ > /* >SPDX-License-Identifier: GPL-2.0-only > > - Copyright (C) 2019 Arnaldo Carvalho de Melo > + Copyright (C) 2019 Facebook > */ > > #ifndef _LIBBTF_H -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Bug#919356: [PATCH] Add missing licensing info
From: Domenico Andreoli Hi Arnaldo, I noticed that some files of pahole come without licensing and copyright information, this makes Debian struggle with the redistribution and, unfortunately, puts the inclusion of pahole into coming release at risk. For your convenience, I attached a patch that adds the info where missing and also adopts the SPDX notation. I presumed to match your intentions in fact copyright/licensing but please comment back so that I can adapt and hopefully converge quickly. Kind regards, Domenico Signed-off-by: Domenico Andreoli --- btf_encoder.c| 6 ++ btf_encoder.h| 5 + codiff.c | 6 ++ ctf.h| 5 + ctf_encoder.c| 6 ++ ctf_encoder.h| 6 ++ ctracer.c| 6 ++ dtagnames.c | 6 ++ dutil.c | 6 ++ dutil.h | 6 ++ dwarf_loader.c | 6 ++ dwarves.c| 6 ++ dwarves.h| 6 ++ dwarves_emit.c | 6 ++ dwarves_emit.h | 6 ++ dwarves_fprintf.c| 6 ++ dwarves_reorganize.c | 6 ++ dwarves_reorganize.h | 6 ++ elf_symtab.c | 6 ++ elf_symtab.h | 6 ++ elfcreator.c | 6 ++ elfcreator.h | 6 ++ gobuffer.c | 6 ++ gobuffer.h | 6 ++ libbtf.c | 6 ++ libbtf.h | 6 ++ libctf.c | 6 ++ libctf.h | 6 ++ list.h | 6 ++ pahole.c | 6 ++ pdwtags.c| 6 ++ pfunct.c | 6 ++ pglobal.c| 5 + prefcnt.c| 6 ++ rbtree.c | 16 ++-- rbtree.h | 16 ++-- scncopy.c| 6 ++ strings.c| 6 ++ strings.h| 6 ++ syscse.c | 6 ++ 40 files changed, 105 insertions(+), 152 deletions(-) diff --git a/btf_encoder.c b/btf_encoder.c index bfdab27..854434c 100644 --- a/btf_encoder.c +++ b/btf_encoder.c @@ -1,3 +1,9 @@ +/* + SPDX-License-Identifier: GPL-2.0-only + + Copyright (C) 2019 Arnaldo Carvalho de Melo + */ + #include "dwarves.h" #include "libbtf.h" #include "btf.h" diff --git a/btf_encoder.h b/btf_encoder.h index a9d622f..62409f8 100644 --- a/btf_encoder.h +++ b/btf_encoder.h @@ -1,5 +1,10 @@ #ifndef _BTF_ENCODER_H_ #define _BTF_ENCODER_H_ 1 +/* + SPDX-License-Identifier: GPL-2.0-only + + Copyright (C) 2019 Arnaldo Carvalho de Melo + */ struct cu; diff --git a/codiff.c b/codiff.c index a3bee05..8bbc32a 100644 --- a/codiff.c +++ b/codiff.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2006 Mandriva Conectiva S.A. Copyright (C) 2006 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ #include diff --git a/ctf.h b/ctf.h index 6233f6f..25b7989 100644 --- a/ctf.h +++ b/ctf.h @@ -1,5 +1,10 @@ #ifndef _CTF_H #define _CTF_H +/* + SPDX-License-Identifier: GPL-2.0-only + + Copyright (C) 2019 Arnaldo Carvalho de Melo + */ #include diff --git a/ctf_encoder.c b/ctf_encoder.c index ab70254..8f1c0be 100644 --- a/ctf_encoder.c +++ b/ctf_encoder.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2009 Red Hat Inc. Copyright (C) 2009 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ #include "dwarves.h" diff --git a/ctf_encoder.h b/ctf_encoder.h index 91c43d9..16e76e2 100644 --- a/ctf_encoder.h +++ b/ctf_encoder.h @@ -1,12 +1,10 @@ #ifndef _CTF_ENCODER_H_ #define _CTF_ENCODER_H_ 1 /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2009 Red Hat Inc. Copyright (C) 2009 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ struct cu; diff --git a/ctracer.c b/ctracer.c index 710bdab..e4bd5e0 100644 --- a/ctracer.c +++ b/ctracer.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2006 Mandriva Conectiva S.A. Copyright (C) 2006 Arnaldo Carvalho de Melo - - This program is free software; you can redistribute it and/or modify it - under the terms of version 2 of the GNU General Public License as - published by the Free Software Foundation. */ #include diff --git a/dtagnames.c b/dtagnames.c index 16b9987..0ffcbf7 100644 --- a/dtagnames.c +++ b/dtagnames.c @@ -1,10 +1,8 @@ /* + SPDX-License-Identifier: GPL-2.0-only + Copyright (C) 2006
Bug#919356: Licensing of include/linux/hash.h
Hi Nadia, As part of the licensing assessment on pahole [0] that I am making for Debian, I realized that file hash.h in both pahole [1] and the kernel [2] comes without any licensing specification. Could you please make an explicit choice and maybe provide patches? Kind regards, Domenico [0] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ [1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/tree/hash.h [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
