Bug#1070257: cryptsetup: cryptroot-unlock re licensed
Package: cryptsetup Severity: wishlist Dear Maintainer, I noticed that cryptroot-unlock was re licensed as GPL-3 in https://salsa.debian.org/cryptsetup- team/cryptsetup/-/commit/c350f3afc95048eb793f82ee10b02782b8129659 but from the commit message it seems that there is no strong opinion about the license. This change can affect the usability of this tool in some scenarios, specially for projects with strong license policies like Apertis [1]. Also, since the package is L/GPL-2, probably it is better to keep the main license as default, unless there is some particular reason against that. For these reasons I felt it could be useful to re-license back to it original license. Similar comments apply to the cryptsetup-suspend, but since that is a new tool it is a bit different. Thanks in advance, Walter [1] https://www.apertis.org/policies/license-expectations/ -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.5.0-28-generic root=UUID=b7f43638-7a6b-4524-8486-6b422b4a42d9 ro cryptdevice=UUID=be594949-8a07-41d8-8368-81df6b982eb8 root=/dev/mapper/nvme0n1p3_crypt ro quiet splash vt.handoff=7 -- /etc/crypttab # nvme0n1p3_crypt UUID=be594949-8a07-41d8-8368-81df6b982eb8 noneluks -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/nvme0n1p2 during installation /dev/mapper/nvme0n1p3_crypt / ext4errors=remount-ro 0 1 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=09A4-7167 /boot/efi vfatumask=0077 0 1 /swapfile noneswapsw 0 0 -- lsmod Module Size Used by cdc_acm45056 0 nhpoly1305_avx212288 0 nhpoly1305_sse212288 0 nhpoly1305 16384 2 nhpoly1305_avx2,nhpoly1305_sse2 adiantum 12288 0 libpoly130512288 2 adiantum,nhpoly1305 camellia_generic 45056 0 camellia_aesni_avx228672 0 camellia_aesni_avx_x86_6428672 1 camellia_aesni_avx2 camellia_x86_6461440 2 camellia_aesni_avx_x86_64,camellia_aesni_avx2 cast5_avx_x86_64 53248 0 cast5_generic 24576 1 cast5_avx_x86_64 cast_common12288 2 cast5_generic,cast5_avx_x86_64 des_generic12288 0 des3_ede_x86_6449152 0 libdes 36864 2 des_generic,des3_ede_x86_64 blowfish_generic 12288 0 blowfish_x86_6424576 0 blowfish_common16384 2 blowfish_generic,blowfish_x86_64 serpent_avx2 45056 0 serpent_avx_x86_64 49152 1 serpent_avx2 serpent_sse2_x86_6449152 0 serpent_generic24576 3 serpent_avx2,serpent_sse2_x86_64,serpent_avx_x86_64 twofish_generic20480 0 twofish_avx_x86_64 49152 0 twofish_x86_64_3way32768 1 twofish_avx_x86_64 twofish_x86_64 16384 2 twofish_x86_64_3way,twofish_avx_x86_64 twofish_common 94208 4 twofish_x86_64,twofish_generic,twofish_x86_64_3way,twofish_avx_x86_64 lrw12288 0 wireguard 114688 0 curve25519_x86_64 36864 1 wireguard libchacha20poly130516384 1 wireguard chacha_x86_64 32768 1 libchacha20poly1305 poly1305_x86_6428672 1 libchacha20poly1305 libcurve25519_generic49152 2 curve25519_x86_64,wireguard libchacha 12288 1 chacha_x86_64 ip6_udp_tunnel 12288 1 wireguard udp_tunnel 28672 1 wireguard vboxnetadp 28672 0 vboxnetflt 36864 0 nft_masq 12288 1 vboxdrv 741376 2 vboxnetadp,vboxnetflt ccm20480 3 vhost_vsock24576 0 vmw_vsock_virtio_transport_common57344 1 vhost_vsock vhost 65536 1 vhost_vsock vhost_iotlb16384 1 vhost vsock 61440 2 vmw_vsock_virtio_transport_common,vhost_vsock r8153_ecm 12288 0 cdc_ether 24576 1 r8153_ecm usbnet 61440 2 r8153_ecm,cdc_ether rfcomm 98304 4 snd_seq_dummy 12288 0 snd_hrtimer12288 1 r8152 143360 1 r8153_ecm mii20480 2 usbnet,r8152 snd_usb_audio 450560 2 snd_usbmidi_lib53248 1 snd_usb_audio snd_ump45056 1 snd_usb_audio xt_CHECKSUM12288 1 xt_MASQUERADE 16384 3 xt_conntrack 12288 1 ipt_REJECT 12288 2 nf_reject_ipv4 16384 1 ipt_REJECT xt_tcpudp 16384 0 nft_compat 20480 7 nft_chain_nat 12288 3 nf_nat 61440 3 nft_masq,nft_chain_nat,xt_MASQUERADE nf_conntrack 208896 4 xt_conntrack,nf_nat,nft_masq,xt_MASQUERADE nf_defrag_ipv6 24576 1
Bug#1069304: daciti: Fix incorrect work when using default_factory
Package: daciti Version: 1.8.0-1 Severity: important Dear Maintainer, The version or daciti 1.8.0-1 ships an upstream bug which was fixed in 1.8.1 as it is rather important. In particular this is the only major difference between the version Bookworm (1.8.0-1) and Trixie (1.8.1-2), so probably it can be backported. As reference https://github.com/konradhalas/dacite/pull/216 Thanks in advance, Walter -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-27-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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) LSM: AppArmor: enabled
Bug#1033406: licensecheck: scan-copyrights fails to create copyright file for texlive-extra
On Thu, 18 May 2023 15:24:03 +0530 Vignesh Raman wrote: On Wed, 03 May 2023 18:45:07 +0200 Dominique Dumont wrote: > > This problem concerns a zone that I've rewritten these past months to ease its > maintenance. > > Running the new scan-copyright on texlive proves to be quite challenging from > a performance point of view, so please be patient. > Sure. Thank you for the update I think this issue is fixed by https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/merge_requests/6 Regards, Walter -- Walter Lozano Collabora Ltd.
Bug#1033071: nodejs: Build errors on node-js packages due to support for tsc 3.6
Package: nodejs Version: 12.22.12~dfsg-1~deb11u3 Severity: important Dear Maintainer, In commit [1] a symlink to @types/node/tsc3.6 was included to mitigate regression introduced in 12.22.12 which dropped support for tsc 3.6 (Closes: #1014914) With this fix, other packages start to experience build errors, as example $ docker run -it --rm debian:bullseye-slim sh -c 'cat /etc/apt/sources.list | sed s/^deb/deb-src/ > /etc/apt/sources.list.d/srcs.list && apt update && apt install --no-install-recommends -y apt-src && apt-src install node-babel7 && apt-src build node-babel7' ... cp -rL /usr/share/nodejs/\@types/node ./node_modules/\@types cp: cannot copy cyclic symbolic link '/usr/share/nodejs/@types/node/tsc3.6' dh_auto_configure: error: cp -rL /usr/share/nodejs/\@types/node ./node_modules/\@types returned exit code 1 make: *** [debian/rules:15: binary] Error 255 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 E: Building failed I cannot confirm how many packages are affected but an initial list is: - node-babel7 - node-domutils - node-follow-redirects - node-htmlparser2 - node-jschardet - node-recast [1] https://salsa.debian.org/js- team/nodejs/-/commit/c7b5bc3fb81df93b194bd9caa46bea6f226a9f7a Thanks in advance! Walter -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-35-generic (SMP w/8 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) LSM: AppArmor: enabled Versions of packages nodejs depends on: ii libc6 2.35-0ubuntu3.1 ii libnode72 12.22.9~dfsg-1ubuntu3 Versions of packages nodejs recommends: ii ca-certificates 20211016ubuntu0.22.04.1 ii nodejs-doc 12.22.9~dfsg-1ubuntu3 Versions of packages nodejs suggests: pn npm -- no debconf information
Bug#1016963: Please test u-boot for rock-pi-4-rk3399
Hi Christopher and Vagrant On 1/5/23 12:10, Christopher Obbard wrote: On Wed, 2022-12-28 at 15:53 -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. rock-pi-4-rk3399 Hi Walter, Hi Vagrant, I tested this board and updated the wiki. All looks fine to me. - rock-pi-4-rk3399, on rock-pi-4b, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - rock-pi-4-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: correctly derived from serial number Thank you for your help here! I also did some testing, and everything looks OK. The only thing to mention is that the the script u-boot-install-rockchip does not auto detect my board. The case statement is ``` "Radxa ROCK Pi 4") TARGET="/usr/lib/u-boot/rock-pi-4-rk3399" ``` fails since the string in my case is only "ROCK Pi 4". Of course, by setting TARGET variable I can upgrade it without problems. I don't consider this an issue and it is probably related to the kernel I am using, since I have used as starting point the images from Radxa [1]. Regards, Walter [1] https://wiki.radxa.com/Rockpi4/downloads -- Walter Lozano Collabora Ltd.
Bug#1016963: Please test u-boot for rock-pi-4-rk3399
On 12/28/22 20:53, 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. rock-pi-4-rk3399 Sorry for the late reply, let me run some tests and confirm the status. Regards, -- Walter Lozano Collabora Ltd.
Bug#1021781: apt: Fix error handling with getline
Package: apt Version: 2.4.8 Severity: important Dear Maintainer, While working building images using debos[1] with Apertis [2] I noticed strange behaviors with apt. After debugging the issue, I found what I understand is a bug and submitted a MR to try to fix it. https://salsa.debian.org/apt-team/apt/-/merge_requests/265/ As as summary I consider that in some cases the error handling after calling getline is not correct since it only takes into account errno but not the return value. Thanks is advance, Walter [1] https://github.com/go-debos/debos [2] https://www.apertis.org/ -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (no /etc/apt/preferences.d/* present) -- -- /etc/apt/sources.list -- # deb cdrom:[Ubuntu 19.10 _Eoan Ermine_ - Release amd64 (20191017)]/ eoan main restricted # See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to # newer versions of the distribution. deb http://ar.archive.ubuntu.com/ubuntu/ jammy main restricted deb-src http://ar.archive.ubuntu.com/ubuntu/ jammy main restricted ## Major bug fix updates produced after the final release of the ## distribution. deb http://ar.archive.ubuntu.com/ubuntu/ jammy-updates main restricted # deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-updates main restricted ## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu ## team. Also, please note that software in universe WILL NOT receive any ## review or updates from the Ubuntu security team. deb http://ar.archive.ubuntu.com/ubuntu/ jammy universe # deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan universe deb http://ar.archive.ubuntu.com/ubuntu/ jammy-updates universe # deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-updates universe ## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu ## team, and may not be under a free licence. Please satisfy yourself as to ## your rights to use the software. Also, please note that software in ## multiverse WILL NOT receive any review or updates from the Ubuntu ## security team. deb http://ar.archive.ubuntu.com/ubuntu/ jammy multiverse # deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan multiverse deb http://ar.archive.ubuntu.com/ubuntu/ jammy-updates multiverse # deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-updates multiverse ## N.B. software from this repository may not have been tested as ## extensively as that contained in the main release, although it includes ## newer versions of some applications which may provide useful features. ## Also, please note that software in backports WILL NOT receive any review ## or updates from the Ubuntu security team. deb http://ar.archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse # deb-src http://ar.archive.ubuntu.com/ubuntu/ eoan-backports main restricted universe multiverse deb http://security.ubuntu.com/ubuntu jammy-security main restricted # deb-src http://security.ubuntu.com/ubuntu eoan-security main restricted deb http://security.ubuntu.com/ubuntu jammy-security universe # deb-src http://security.ubuntu.com/ubuntu eoan-security universe deb http://security.ubuntu.com/ubuntu jammy-security multiverse # deb-src http://security.ubuntu.com/ubuntu eoan-security multiverse # This system was installed using small removable media # (e.g. netinst, live or single CD). The matching "deb cdrom" # entries were disabled at the end of the installation process. # For information about how to configure apt package sources, # see the sources.list(5) manual. -- (/etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list present, but not submitted) -- -- /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list.distUpgrade -- deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04/ / -- (/etc/apt/sources.list.d/google-chrome.list present, but not submitted) -- -- /etc/apt/sources.list.d/google-chrome.list.distUpgrade -- ### THIS FILE IS AUTOMATICALLY CONFIGURED ### # You may comment out this entry, but any other modifications may be lost. deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main -- (/etc/apt/sources.list.d/google-chrome.list.save present, but not submitted) -- -- /etc/apt/sources.list.d/katharaframework-ubuntu-kathara-eoan.list -- # deb http://ppa.launchpad.net/katharaframework/kathara/ubuntu focal main # disabled on upgrade to focal # deb-src http://ppa.launchpad.net/katharaframework/kathara/ubuntu eoan main -- (/etc/apt/sources.list.d/katharaframework-ubuntu-kathara-eoan.list.distUpgrade present, but not submitted) -- -- /etc/apt/sources.list.d/oem-somerville-three-eyed-raven-meta.list -- deb http://dell.archive.canonical.com/ jammy somerville # deb-src http://dell.archive.canonical.com/ focal somerville deb http://dell.archive.canonical.com/ jammy somerville-three-eyed-raven # deb-src http://dell.archive.canonical.com/ focal somerville-three-eyed-raven --
Bug#1004759: user-mode-linux hangs randomly on Linux 5.15
Package: user-mode-linux Severity: normal Dear Maintainer, After upgrading to Linux 5.15 random hangs have been reported. After debugging the issue seems to be related to VMAP_STACK so a bug report upstream was created. http://lists.infradead.org/pipermail/linux-um/2022-January/002024.html After disabling VMAP_STACK and testing for more than two weeks no hangs were reported, so I propose the following fix https://salsa.debian.org/uml-team/user-mode-linux/-/merge_requests/9 -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.11.0-46-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1000659: kmod: Use short -s option instead of --quiet
Hi Marco, Thank you for your prompt reply. On 11/26/21 12:49, Marco d'Itri wrote: On Nov 26, Walter Lozano wrote: I think that a nice improvement would be to use short options for those GNU tools that have different implementations. Specifically in this case I'm referring to cmp, which currently uses "--quiet". In this way this scripts will work with implementations like busybox. Can you explain exactly who should care about using busybox for postinst? Debian is an Universal operating system, from which some other distributions derive, which have different objectives, for instance Apertis [1]. In the context of embedded devices the use of busybox is quite common, since it provides the basic support for several GNU tools, with lower footprint and much friendlier license. Under this context, and since it the change I mention should not cause any issue in Debian, is that I think it could be beneficial for also other users/downstream distributions. Thanks in advance! Walter [1] www.apertis.org -- Walter Lozano Collabora Ltd.
Bug#1000659: kmod: Use short -s option instead of --quiet
Package: kmod Version: 27-1ubuntu2 Severity: normal Dear Maintainer, I think that a nice improvement would be to use short options for those GNU tools that have different implementations. Specifically in this case I'm referring to cmp, which currently uses "--quiet". In this way this scripts will work with implementations like busybox. I have submitted a MR which can be found in: https://salsa.debian.org/md/kmod/-/merge_requests/4 Thanks in advance, Walter -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.11.0-40-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kmod depends on: ii libc6 2.31-0ubuntu9.2 ii libkmod2 27-1ubuntu2 ii liblzma5 5.2.4-1ubuntu1 ii libssl1.1 1.1.1f-1ubuntu2.8 ii lsb-base 11.1.0ubuntu2 kmod recommends no packages. kmod suggests no packages. -- no debconf information
Bug#1000657: apt: Use short options for cmp
Package: apt Version: 2.0.6 Severity: normal Dear Maintainer, I think a nice improvement for apt is to use short options for cmp. Currently, in general apt scripts used short options, but this is not consistent. Also, in this way scripts will be friendlier to different implementations of cmp, like busybox one. I have submitted a MR which can be found in: https://salsa.debian.org/apt-team/apt/-/merge_requests/203 Thanks in advance, Walter -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (no /etc/apt/preferences.d/* present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- (/etc/apt/sources.list.d/google-chrome.list present, but not submitted) -- -- (/etc/apt/sources.list.d/google-chrome.list.distUpgrade present, but not submitted) -- -- (/etc/apt/sources.list.d/google-chrome.list.save present, but not submitted) -- -- (/etc/apt/sources.list.d/katharaframework-ubuntu-kathara-eoan.list present, but not submitted) -- -- (/etc/apt/sources.list.d/katharaframework-ubuntu-kathara-eoan.list.distUpgrade present, but not submitted) -- -- (/etc/apt/sources.list.d/oem-somerville-three-eyed-raven-meta.list present, but not submitted) -- -- (/etc/apt/sources.list.d/teams.list present, but not submitted) -- -- (/etc/apt/sources.list.d/teamviewer.list present, but not submitted) -- -- (/etc/apt/sources.list.d/teamviewer.list.distUpgrade present, but not submitted) -- -- (/etc/apt/sources.list.d/teamviewer.list.dpkg-old present, but not submitted) -- -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.11.0-40-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.118ubuntu2 ii gpgv2.2.19-3ubuntu2.1 ii libapt-pkg6.0 2.0.6 ii libc6 2.31-0ubuntu9.2 ii libgcc-s1 10.3.0-1ubuntu1~20.04 ii libgnutls30 3.6.13-2ubuntu1.6 ii libseccomp2 2.5.1-1ubuntu1~20.04.1 ii libstdc++6 10.3.0-1ubuntu1~20.04 ii libsystemd0 245.4-4ubuntu3.13 ii ubuntu-keyring 2020.02.11.4 Versions of packages apt recommends: ii ca-certificates 20210119~20.04.2 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.12-1ubuntu4 ii dpkg-dev1.19.7ubuntu3 ii gnupg 2.2.19-3ubuntu2.1 ii powermgmt-base 1.36 -- no debconf information
Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided
Hi Jonas, On 6/22/21 4:57 PM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-22 20:55:10) On 6/22/21 2:10 PM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-22 18:56:05) I'm really happy that this report was helpful. Certainly was. Hope you find interest in doing more of that - to Licensecheck or to other projects :-) Sure, I will love to contribute if I can, most probably by filling bug reports, hopefully useful. But who knows, maybe I will eventually improve my Perl skills... You need not write a single line of perl to help with Licensecheck - Regexp::Pattern::License is a collection of metadata and regular expressions for licenses, and there is a need for both refining those regular expressions and for extending to cover more licenses, both free and non-free. Thanks, after debugging a little this issue now I have a better understanding of how it works, I hope I can contribute in future, since I will be using licensecheck and scan-copyrights. If interested, then these commands should provide you a JSON serialization: apt install libregexp-pattern-license cpanminus cpanm App::RegexpPatternUtils PATH="$HOME/perl5/bin:$PATH" PERL5LIB="$HOME/perl5/lib/perl5" show-regexp-pattern-module --name=License --json Beware that the cpanm command may take a while, as it pulls in quite a few perl libraries - that's the reason I have not bothered to package it for Debian yet. A non-Perl but also non-JSON dump of the dataset is simpler and faster: apt install libregexp-pattern-license libdata-printer-perl perl -CS -MRegexp::Pattern::License -MDDP -e 'p %Regexp::Pattern::License::RE, fulldump => 1' Thank you for the tips, I will use them. BTW, you already know this but I have been testing the new version and so far everything seems to work as expected. Thanks again for the quick response. Regards, Walter
Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided
Hi Jonas, On 6/22/21 2:10 PM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-22 18:56:05) Thank you for your detailed explanation. I cannot completely follow you but I can follow the high level idea. I was completely sure that the issue was related to how license versioning was handled, but my limited experience in perl and in these particular modules make it impossible for me to go deeper. So I establish a personal goal of at least make a bug report which were really useful for you and provide a basement for your investigation, mainly by pointing to what was more evident for me, the non deterministic output. I suspect that it is not so much your lack of experience that make the code difficult to follow, but to a larger degree the odd evolution of Licensecheck from a single-file quick hack and my no doubt unconventional programming style (I never formally studied programming, just fumbled with Perl on my own for 20+ years). You are definitely over estimating my Perl skills, which are very limited, however it is a language which connects me with one of professors who inspired me (when I was a student, long time ago). Although he never taught me Perl I remember he was always carrying a book about Perl. I'm really happy that this report was helpful. Certainly was. Hope you find interest in doing more of that - to Licensecheck or to other projects :-) Sure, I will love to contribute if I can, most probably by filling bug reports, hopefully useful. But who knows, maybe I will eventually improve my Perl skills... I notice your Collabora email, and hope you get lots of joyful challenges there. Yes, lot of fun here! Nice people, many challenges, so I'm having a good time. See you around Regards, Walter
Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided
Hi Jonas, On 6/22/21 5:22 AM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-16 14:44:01) On 6/16/21 2:50 AM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-16 04:12:23) On 6/15/21 9:17 PM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-15 20:42:53) As as user of licensecheck I found it does not provide deterministic results on some circumstances. And example of this is gnutls28/m4/ax_code_coverage.m4 which is detected as UNKNOWN or LGPL. After some debugging I found that the root cause could be in libregexp-pattern-license-perl, I have proposed a fix which you can find in https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license- perl/-/merge_requests/1 I hope you can help me to clarify this issue. Great - thanks a lot! I suspect that this might be bug#982849. Yes, it looks exactly the same issue I faced. I hope you can confirm and fix it I will certainly do that. In relation to this, I find that the problem is more evident at least after these commits, which are related to versioning * eddc64dd1f0e6f9bd1769ef580a217aa4be762b8 (synthesize subject pattern name: optimize version matching) * cd75d77da201260bc9deef4631d5c4d3a42fa41d (add license patterns lgpl_2 lgpl-2_1 lgpl-3) I hope this information is useful. Thanks. You are right that those commits are directly related to the issue - but not the cause, it turned out: At build-time, the library composes regular expressions from metadata (what I call "synthesizing"). If done right, the order of stepping through and synthesize objects should not matter - but the synthesizing logic was buggy at three places: a) Synthesizing metadata from single-version object (e.g. "lgpl_2_1") as regex patterns in versioned object (e.g. "lgpl") cannot be fully random, but must wait till after the single-version object has been synthesized. Now fixed in commit 2ec7af9eb0fdf72711eeb2689a6726b5ff30f82d b) Only a subset of metadata from single-version object was synthesized. Now fixed in commit bfd071032a88fd2d56e20b3a7ef092524dc3491a With those two underlying bugs fixed, the library should now build its DefHash structure deterministically. ...but the structure now has more rich versioned objects, which revealed another bug in Licensecheck: Licensecheck looks for more specific objects first - first singleversion objects with optional trailer (e.g. "lgpl_2_1" + "version 2.1" + "or any later"), and then versioned object with optional trailer (e.g. "lgpl" + "version 2.1" + "or any later"). Notice the bug? For singleversion objects it should skip the version part of a trailer (i.e. only e.g. "lgpl_2_1" + "or any later"). So Licensecheck would fail to detect "or later" for singleversion objects because it bogusly looked for double version, and would then succeed in detecting "or later" with the more general versioned object - as long as that was crippled to miss the version on its own, so that version was part of the trailer. If you are still with me in all this (I am not good at describing this, I realize that), you can imagine how frustrated I have been to try figure out what was really failing - until you pointed out the one place I could make the build-time (still wrong but at least) deterministic. Thanks a lot! Thank you for your detailed explanation. I cannot completely follow you but I can follow the high level idea. I was completely sure that the issue was related to how license versioning was handled, but my limited experience in perl and in these particular modules make it impossible for me to go deeper. So I establish a personal goal of at least make a bug report which were really useful for you and provide a basement for your investigation, mainly by pointing to what was more evident for me, the non deterministic output. I'm really happy that this report was helpful. New releases went out upstream to CPAN last night, and I expect to release packages for Debian today. Unfortunately too late to be included with the upcoming Bullseye release of Debian. Thanks again! Regards, Walter
Bug#990034: libconfig-model-dpkg-perl: scan-copyrights does not handle non ASCII chars in package.json
Package: libconfig-model-dpkg-perl Version: 2.132 Severity: normal Dear Maintainer, During my work I noticed that scan-copyrights does not handle non ASCII chars in package.json, which leads to the following error "malformed UTF-8 character in JSON string" A proposed fix can be found in https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg- perl/-/merge_requests/5 I hope you can check the issue and help me to fix it. Thanks in advance, Walter -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-55-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libconfig-model-dpkg-perl depends on: ii debhelper 12.10ubuntu1 ii libapt-pkg-perl0.1.36build3 ii libarray-intspan-perl 2.003-1 ii libconfig-model-backend-yaml-perl 2.133-2 ii libconfig-model-perl 2.138-2 ii libexporter-lite-perl 0.08-1 ii liblog-log4perl-perl 1.49-1 ii libmouse-perl 2.5.9-1 ii libparse-recdescent-perl 1.967015+dfsg-2 ii libsoftware-licensemoreutils-perl 1.004-1 ii libsort-versions-perl 1.62-1 ii libtext-autoformat-perl1.75-1 ii libtext-levenshtein-damerau-perl 0.41-1 ii liburi-perl1.76-2 ii libwww-perl6.43-1 ii libyaml-libyaml-perl 0.81+repack-1 ii licensecheck 3.0.45-1 ii lintian2.62.0 ii perl [libmodule-corelist-perl] 5.30.0-9ubuntu0.2 Versions of packages libconfig-model-dpkg-perl recommends: ii libconfig-model-tkui-perl 1.371-2 libconfig-model-dpkg-perl suggests no packages. -- no debconf information
Bug#989950: libconfig-model-dpkg-perl: Add support for output without wild cards
Package: libconfig-model-dpkg-perl Version: 2.132 Severity: wishlist Dear Maintainer, I would like to have the option to generate a report without using wildcards, since that makes it self-contained. This is useful in cases where the report is consumed by other systems. To allow it, I proposed a MR to add the support for optional argument "long" which avoid squashing copyright_id. https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg- perl/-/merge_requests/4 -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-55-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libconfig-model-dpkg-perl depends on: ii debhelper 12.10ubuntu1 ii libapt-pkg-perl0.1.36build3 ii libarray-intspan-perl 2.003-1 ii libconfig-model-backend-yaml-perl 2.133-2 ii libconfig-model-perl 2.138-2 ii libexporter-lite-perl 0.08-1 ii liblog-log4perl-perl 1.49-1 ii libmouse-perl 2.5.9-1 ii libparse-recdescent-perl 1.967015+dfsg-2 ii libsoftware-licensemoreutils-perl 1.004-1 ii libsort-versions-perl 1.62-1 ii libtext-autoformat-perl1.75-1 ii libtext-levenshtein-damerau-perl 0.41-1 ii liburi-perl1.76-2 ii libwww-perl6.43-1 ii libyaml-libyaml-perl 0.81+repack-1 ii licensecheck 3.0.45-1 ii lintian2.62.0 ii perl [libmodule-corelist-perl] 5.30.0-9ubuntu0.2 Versions of packages libconfig-model-dpkg-perl recommends: ii libconfig-model-tkui-perl 1.371-2 libconfig-model-dpkg-perl suggests no packages. -- no debconf information
Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided
Hi Jonas, On 6/16/21 2:50 AM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-16 04:12:23) On 6/15/21 9:17 PM, Jonas Smedegaard wrote: Quoting Walter Lozano (2021-06-15 20:42:53) As as user of licensecheck I found it does not provide deterministic results on some circumstances. And example of this is gnutls28/m4/ax_code_coverage.m4 which is detected as UNKNOWN or LGPL. After some debugging I found that the root cause could be in libregexp-pattern-license-perl, I have proposed a fix which you can find in https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license- perl/-/merge_requests/1 I hope you can help me to clarify this issue. Great - thanks a lot! I suspect that this might be bug#982849. Yes, it looks exactly the same issue I faced. I hope you can confirm and fix it I will certainly do that. In relation to this, I find that the problem is more evident at least after these commits, which are related to versioning * eddc64dd1f0e6f9bd1769ef580a217aa4be762b8 (synthesize subject pattern name: optimize version matching) * cd75d77da201260bc9deef4631d5c4d3a42fa41d (add license patterns lgpl_2 lgpl-2_1 lgpl-3) I hope this information is useful. Please keep all conversation about the bug here - *not* at salsa. Perfect, I will do that. To be honest I was not sure how to submit the proposed fix, I also tried to submitted directly to https://salsa.debian.org/build-common-team/regexp-pattern-license but I was not able to see a way to send a MR. Please advice what is the best way to contribute. Sorry, I am aware that reporting issues can be confusing, and am happy that you figured out _some_ way to get your findings across. I use salsa.debian.org as a place to publicly store the git repo but *not* to track issues or negotiate change proposals or run continuous integration tests or any other of the many things that Gitlab can do. I use bugs.debian.org to track issues. Best way to report and discuss issues is to use bugs.debian.org, and best way to propose a change is to attach a patch to an email sent to an issue tracked in bugs.debian.org. As you are already aware, some parts of Licensecheck is maintained in other libraries. Git repos exist separately for Debian packaging and upstream development of these libraries, but that should not matter for issue tracking. E.g. https://metacpan.org/dist/App-Licensecheck/view/bin/licensecheck and https://metacpan.org/dist/App-Licensecheck links to https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=licensecheck for issue reporting, and https://www.debian.org/Bugs/Reporting covers issue reporting in Debian. I find it unhelpful that salsa.debian.org by default enables duplicate issue tracking services, and I disable those to limit the risk of confusion - but sometimes I forget that, and also sometimes others that I collaborate with may disagree and (re)enable them. If you have suggestions for ways I could maybe improve communicating how to best report issues, then please do share. Thanks for clarifying, and for taking the time to investigate the issue. Next time I will send you a patch as an attachment. Regards, Walter
Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided
Hi Jonas, On 6/15/21 9:17 PM, Jonas Smedegaard wrote: Hi Walter, Quoting Walter Lozano (2021-06-15 20:42:53) Package: libregexp-pattern-license-perl Version: 3.2.0-1 Severity: normal Dear Maintainer, As as user of licensecheck I found it does not provide deterministic results on some circumstances. And example of this is gnutls28/m4/ax_code_coverage.m4 which is detected as UNKNOWN or LGPL. After some debugging I found that the root cause could be in libregexp-pattern- license-perl, I have proposed a fix which you can find in https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license- perl/-/merge_requests/1 I hope you can help me to clarify this issue. Great - thanks a lot! I suspect that this might be bug#982849. Yes, it looks exactly the same issue I faced. I hope you can confirm and fix it Please keep all conversation about the bug here - *not* at salsa. Perfect, I will do that. To be honest I was not sure how to submit the proposed fix, I also tried to submitted directly to https://salsa.debian.org/build-common-team/regexp-pattern-license but I was not able to see a way to send a MR. Please advice what is the best way to contribute. Thanks in advance. Regards, Walter
Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided
Package: libregexp-pattern-license-perl Version: 3.2.0-1 Severity: normal Dear Maintainer, As as user of licensecheck I found it does not provide deterministic results on some circumstances. And example of this is gnutls28/m4/ax_code_coverage.m4 which is detected as UNKNOWN or LGPL. After some debugging I found that the root cause could be in libregexp-pattern- license-perl, I have proposed a fix which you can find in https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license- perl/-/merge_requests/1 I hope you can help me to clarify this issue. Thanks in advance. -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-53-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libregexp-pattern-license-perl depends on: ii libre-engine-re2-perl 0.13-5 ii perl 5.30.0-9ubuntu0.2 libregexp-pattern-license-perl recommends no packages. libregexp-pattern-license-perl suggests no packages. -- no debconf information
Bug#986235: libconfig-model-dpkg-perl: Need to support "author" as object in package.json
Package: libconfig-model-dpkg-perl
Version: 2.132
Severity: normal
Dear Maintainer,
While getting "author" from package.json the expected values are string or
lists. However some packages like less.js present an object as value.
As an example here is how "author" is declared in less.js
"author": {
"name": "Alexis Sellier",
"email": "s...@cloudhead.net"
},
So I think it is a good idea to support this by retrieving the value of key
"name" in that case.
I have sent a MR but my perl skills are limited
https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-
perl/-/merge_requests/3
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-70-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libconfig-model-dpkg-perl depends on:
ii debhelper 12.10ubuntu1
ii libapt-pkg-perl0.1.36build3
ii libarray-intspan-perl 2.003-1
ii libconfig-model-backend-yaml-perl 2.133-2
ii libconfig-model-perl 2.138-2
ii libexporter-lite-perl 0.08-1
ii liblog-log4perl-perl 1.49-1
ii libmouse-perl 2.5.9-1
ii libparse-recdescent-perl 1.967015+dfsg-2
ii libsoftware-licensemoreutils-perl 1.004-1
ii libsort-versions-perl 1.62-1
ii libtext-autoformat-perl1.75-1
ii libtext-levenshtein-damerau-perl 0.41-1
ii liburi-perl1.76-2
ii libwww-perl6.43-1
ii libyaml-libyaml-perl 0.81+repack-1
ii licensecheck 3.0.45-1
ii lintian2.62.0
ii perl [libmodule-corelist-perl] 5.30.0-9ubuntu0.2
Versions of packages libconfig-model-dpkg-perl recommends:
ii libconfig-model-tkui-perl 1.371-2
libconfig-model-dpkg-perl suggests no packages.
-- no debconf information
Bug#968253: linux-image-armmp: Enable NVMEM_IMX_OCOTP
Package: linux-image-armmp Version: 5.7.10-1 Severity: normal Dear Maintainer, Please take a look to Merge Request https://salsa.debian.org/kernel-team/linux/-/merge_requests/254 On iMX6Q boards, when probing cpufreq, it tries to read efuse settings, however, as NVMEM_IMX_OCOTP is not enabled this can't be done. In this situation the probe fails with -EPROBE_DEFER, and cpufreq is not available. To avoid all the mentioned issues, while these issues are fixed in the upstream kernel (patch already sent), enable NVMEM_IMX_OCOTP as builtin driver. -- System Information: Debian Release: buster/sid APT prefers eoan-updates APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), (100, 'eoan-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-64-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956298: arm-trusted-firmware: Re enable support for rk3399 based on Merge Request
Package: arm-trusted-firmware Severity: wishlist Dear Maintainer, Currently the support for target rk3399 was removed due to build errors in systems newer than Debian Stretch. In order to fix it, a Merge Request has been submitted https://salsa.debian.org/debian/arm-trusted-firmware/-/merge_requests/1 The proposed solution in the MR is to override CFLAGS used by Debian build system as the -O2 flag causes the issue. Further information is in the MR. Please consider this solution in order to fix the issue. Thanks in advance. Walter -- System Information: Debian Release: buster/sid APT prefers eoan-updates APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), (100, 'eoan-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-46-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
