Re: Bug#1050891: sccache - update for new addr2line.
Quoting Peter Michael Green (2023-08-31 02:01:53) > Package: sccache > Version: 0.5.4-11 > Severity: serious > Tags: patch > > I just updated addr2line to version 0.20.0, sccache builds succesfully > with the new version after bumping the dependency. > > Debdiff attatched. Please, pretty please, DO NOT BREAK REVERSE DEPENDENCIES uncoordinated. Cc'ing debian-devel, to raise awareness of this ongoing pattern. It is stressful. You cannot expect to to always react quickly, and it is not acceptable to use NMUs to paper over too sloppy coordination. Possibly you did your homework and your assessment about the magnitude of the damage is correct, but it is a risky game, and it is unfair: Allow those responsible for maintaining packages to actually do that. All that said, thanks for your bugreport, and for your tests. Please in future coordinate *before* doing breaking changes (unless it happens accidentally, of course). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#1021292: Enabling branch protection on amd64 and arm64
Hi Guillem, On 2023-08-31 02:12, Guillem Jover wrote: > So this happened, and Johannes reported that this seems to be breaking > cross-building. :( > > The problem, which is in fact not new, but is made way more evident > now, is that the flags used are accepted only per arch, so when > passing for example CFLAGS (the host ones) into CC_FOR_BUILD, then > that one will not know about them and fail. [...] > I'm thinking about uploading later today a workaround to disable these > flags for now when cross-building. Yeah this sounds like a good idea, thanks very much for taking care of the issue.
Re: Enabling branch protection on amd64 and arm64
Hi Guillem, On Thu, Aug 31, 2023 at 02:12:51AM +0200, Guillem Jover wrote: > So this happened, and Johannes reported that this seems to be breaking > cross-building. :( > > The problem, which is in fact not new, but is made way more evident > now, is that the flags used are accepted only per arch, so when > passing for example CFLAGS (the host ones) into CC_FOR_BUILD, then > that one will not know about them and fail. (We have had this problem > up to now as we set flags per arch as some are broken in some arches, > but it being a problem depends on the host and build arches involved.) I agree that the problem is not new. In general, stuff we compile with the build architecture compiler is not installed into any .deb. We only build such things for running them during build. Most flags do not influence the behaviour of the resulting executables. tim64 may be a notable exception here. So for a lot of cases, you can just pretend that for build tools you don't need any Debian-specified compiler flags. All you need to do here is deleting the flags when invoking build tools. I've hit such cases in the past and done just that. > I'm thinking about uploading later today a workaround to disable these > flags for now when cross-building. And then for the next release after > that support for _FOR_BUILD which can then take into account > these arch differences. I think some upstream code can already make > use of these, but this might need going over packaging or upstream > build systems to adapt/fix stuff. :/ I'd rather not. These have always been bugs and some of them have patches or have been uploaded. I don't expect them to be that many. It's rather few packages that use the build architecture compiler at all. Of those, a portion manages to keep host flags out. Let's just fix the others. In case you really want to pass the correct flags, you may use CFLAGS_FOR_BUILD=$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CFLAGS) Guillem pointed out that these are still affected by DEB__MAINT_ and DEB__, so we should eventually rely on dpkg providing more support here, but I don't see the lack of such support as a blocker here. > And until that's done I don't think the workaround can be lifted, > and cross-compiling will generate different binaries than > non-cross-compiling. Another option would be to revert this change > until we can add it safely, but that would also be unfortunate. > OTOH, upstream code that uses stuff like CFLAGS with things like > CC_FOR_BUILD are already broken in regards cross-building, so perhaps > this can be an opportunity to flush them out? Such cross vs native differences are very bad from my point of view, because we have very little tools to detect them. It's an area where we lack QA. Let's not make that worse. In the grand scheme of things breaking cross builds, I think this is a drop in the bucket. Helmut
Bug#1050941: ITP: golang-github-muesli-mango -- mango is a man-page generator for the Go flag, pflag, cobra, coral, and kong packages
Package: wnpp Severity: wishlist Owner: Scarlett Moore X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-muesli-mango Version : 0.2.0 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/mango * License : Expat Programming Lang: Go-lang Description : mango is a man-page generator for the Go flag, pflag, cobra, coral, and kong packages mango is a man-page generator for the Go flag, pflag, cobra, coral, and kong packages. It extracts commands, flags, and arguments from your program and enables it to self-document. This is a dependency for mango-kong I will maintain the package under the golang packaging team.
Bug#1050968: ITP: rkbin -- Pre-built Rockchip bootloader firmware binaries (for embedded targets)
Package: wnpp Severity: wishlist Owner: Christopher Obbard X-Debbugs-Cc: debian-devel@lists.debian.org, chris.obb...@collabora.com Package name: rkbin Version : 0.0.0~git20230726.b4558da Upstream Contact: Kever Yang URL : https://github.com/rockchip-linux/rkbin License : Copyright © 2017-2023，Rockchip Electronics Co., Ltd. All rights reserved. Programming Lang: n/a; prebuilt firmware binaries Description : Pre-built Rockchip bootloader firmware binaries (for embedded targets) This package contains the Rockchip bootloader firmware binaries, primarily used for targets where no open-source versions is yet released. The pre-built firmware consists of builds of Arm Trusted Firmware, OP-TEE and U-Boot. There are also some closed-source tools in this repo, build for amd64. These will be stripped from the upstream source package as I do not (yet) see a need for these. This package is required to build U-Boot for some embedded targets such as rk3588, rk3566, rk3568. All of these will eventually have open-source firmware, but it is still useful for new processors in the future where U-Boot support will be merged long before the initial DRAM bringup and trusted firmware. I expect this package will go into non-free-firmware. If anyone rejects having this kind of package in Debian, please do reply to this message. I don't have any immediate plans to package this.
Bug#1050969: ITP: v-i -- An alternative Debian installer using vmdb2 and ansible
Package: wnpp Severity: wishlist Owner: Christopher Obbard X-Debbugs-Cc: debian-devel@lists.debian.org, chris.obb...@collabora.com Package name: v-i Version : 0.4 Upstream Contact: Lars Wirzenius URL : https://gitlab.com/larswirzenius/v-i License : GPL-3 Programming Lang: Python, YAML Description : An alternative Debian installer using vmdb2 and ansible v-i installs a very basic Debian onto a PC. It's entirely non-interactive and unhelpful. The author wrote it so that repeated installations would be less of a chore than using the official Debian installer. v-i uses vmdb2 to install onto bare metal hardware. vmdb2 is a program to create a disk image virtual machines with Debian, by the same author. It "installs Debian" to a file representing a hard drive. It's basically debootstrap, except the target is a disk image instead of a directory. It's used to create Debian images for Raspberry Pis. I'd like to package this as part of the installer-team, but I haven't yet asked their permission or had any grace from them.
Bug#1050971: ITP: u-root-cpu -- cpu command in Go, inspired by the Plan 9 cpu command
Package: wnpp Severity: wishlist Owner: Raul Cheleguini X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: u-root-cpu Version : 0.0 Upstream Contact: Ron Minnich * URL : https://github.com/u-root/cpu * License : BSD-3-clause Programming Lang: Go Description : cpu command in Go, inspired by the Plan 9 cpu command The cpu command lets you log in from a local system to a remote system and see some or all of the files (how much is up to you) from the local system. This is wonderfully convenient for embedded systems programmers. Because some or all the files can come from your local machine, including binaries, the only thing you need installed on the remote machine is the cpu daemon itself.
Work-needing packages report for Sep 1, 2023
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1196 (new: 6) Total number of packages offered up for adoption: 148 (new: 0) Total number of packages requested help for: 55 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: debianutils (#1050806), orphaned 2 days ago Description: Essential utilities specific to Debian Reverse Depends: 9base autoconf autoconf2.13 autoconf2.64 autoconf2.69 bash bash-static binstats bitlbee bitlbee-libpurple (28 more omitted) Installations reported by Popcon: 220645 Bug Report URL: https://bugs.debian.org/1050806 dt-utils (#1050494), orphaned 6 days ago Description: Device tree and barebox related tools Reverse Depends: dt-utils libdt-utils-dev Installations reported by Popcon: 7 Bug Report URL: https://bugs.debian.org/1050494 golang-github-hashicorp-go-azure-helpers (#1050948), orphaned today Description: various helpers and wrappers for working with Azure Reverse Depends: golang-github-tombuildsstuff-giovanni-dev Installations reported by Popcon: 1 Bug Report URL: https://bugs.debian.org/1050948 golang-github-hashicorp-terraform-svchost (#1050947), orphaned today Description: handling of friendly hostnames for terraform Reverse Depends: golang-github-hashicorp-terraform-registry-address-dev Installations reported by Popcon: 1 Bug Report URL: https://bugs.debian.org/1050947 notmuch-addrlookup (#1050895), orphaned today Description: Address lookup tool for Notmuch Installations reported by Popcon: 41 Bug Report URL: https://bugs.debian.org/1050895 zemberek-ooo (#1050736), orphaned 3 days ago Description: Turkish spell checker extension for LibreOffice Installations reported by Popcon: 6 Bug Report URL: https://bugs.debian.org/1050736 1190 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 148 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1783 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web debian-edu-router-deployserver (126 more omitted) Installations reported by Popcon: 102623 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 542 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core (24 more omitted) Installations reported by Popcon: 205770 Bug Report URL: https://bugs.debian.org/1006872 autopkgtest (#846328), requested 2465 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1178 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 4358 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 206 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 2333 days ago Description: Rust package manager Reverse Depends: dh-cargo python3-setuptools-rust rust-all Installations reported by Popcon: 3059 Bug Report URL: https://bugs.debian.org/860116 chromium (#1016047), requested 401 days ago Description: web browser Reverse Depends: chromium chromium-driver chromium-l10n chromium-shell node-puppeteer qunit-selenium x2gothinclient-minidesktop Installations reported by Popcon: 23943 Bug Report URL: https://bugs.debian.org/1016047 courier (#978755), requested 973 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 748 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 907 days ago Description: new maintainer need Reverse Depe
Verify upstream PGP signed sha256sums file
Hello, I add PGP verification to my debian/watch files wherever possible so that if upstream has a signature on their tarball, it can be verified. I've seen a few projects now that choose to include a clearsigned file that contains the sha256sums of all their tarballs and binaries instead of providing signatures for each file separately. Does Debian have any way to verify the tarball using this signed checksum file without some sort of custom script needed? Attached is an example of one such file. -- Ben Westover-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Name: p2pool-v3.6-freebsd-x64.tar.gz Size: 797854 bytes (779 KiB) SHA256: 872623a4df19e9fe5a6d710c7b8706d3804b29d24a7b6857e98617569ff2ab51 Name: p2pool-v3.6-linux-aarch64.tar.gz Size: 1073032 bytes (1047 KiB) SHA256: f4f009058b50a4a6ea42e941542d33e6cedb9d5d8102862df6282a5e30078d49 Name: p2pool-v3.6-linux-x64.tar.gz Size: 1104203 bytes (1078 KiB) SHA256: ef11e7f28ea6b529d4e35b3e844484c5160d9d4dfe99fae32b6df8229a859cb4 Name: p2pool-v3.6-macos-aarch64.tar.gz Size: 729764 bytes (712 KiB) SHA256: a8cdc3670f8c078451f305907d2e05894a23821d6f09bf370676d86b20b6479f Name: p2pool-v3.6-macos-x64.tar.gz Size: 768937 bytes (750 KiB) SHA256: bfe999ec706c89c8c050d52e6af7a89b32fff5233bc3526c8801f40396ae92d6 Name: p2pool-v3.6-windows-x64.zip Size: 966831 bytes (944 KiB) SHA256: 2ba27f5796e27b6ca77652b972848585e11e415fa4f0369008ba53fbf810170c Name: p2pool_source.tar.xz Size: 52889504 bytes (50 MiB) SHA256: 52f9e99761b5f005448fc382c983161b9b0f5f2e0310a7dcaefad1eaf93e6398 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEH8qrTT3DMQ0Wy9UIxH+CtU2oet8FAmTwYukACgkQxH+CtU2o et8VjA//T1ni/dppy59Brk5hv/OSeonUiiA7djxwpS8BNaQ6ygiZgJCe2PyZVaiJ XfSLGuE7u+tX/LsmDxHK31Z1cmUM937owM8w4nKrdMQsa1uzgYXUH9AFTipckApf TCE7ITyul1kYdNdhKHnROSex10YGoN/YyVsAlzZ9foIa7d9EPTxZDtRJwl3i/cbh Zws3Hd9/AZqFkVCeaf/LsjrHQXrFMPUATYvzLe5XcmxWvIIWVzb4GY600WB4f+q3 r/cSmq8cLlvwMp3HIPwoZCcaTB/V/IiBncSNUUNC62r1F+wHzCQtA3eRJfX7lW2J pJ86d7lDKg8AtMJlDi+v9MpH1496z7Vt9q4ccgJrKHt6pAs3enOpP75CV9OGJdQr xo/AX4Cnx1tTX1nQSmTc5fEAOWZjCAd7obvO8du+HBS/x8KzHlN0QKSE5EzR0Omk AM/0Q+DjC6Y3ueC+geLPy7T/mJSyvvZcqovhvFZmd5zTS6WmaKww4jirkC0bOeaN FYEqr1/OJEx9ZAmFGS099ed/IFDdDaobKaAgYps5Vz5YxC6wg+59xp6R69NT/I6i DzgNFNvRwE0A1KnLG2v7Kn5l12cTydvmRZCfvsV6e7WwUsZiclowLiLeAZ/hwv6L uGX/JzAwTGyyPLCrqimoVp81YaCDbvun9bXoKF4iDK461LZHM34= =HPT4 -END PGP SIGNATURE-
Re: Verify upstream PGP signed sha256sums file
On 9/1/23 08:10, Ben Westover wrote: Hello, I add PGP verification to my debian/watch files wherever possible so that if upstream has a signature on their tarball, it can be verified. I've seen a few projects now that choose to include a clearsigned file that contains the sha256sums of all their tarballs and binaries instead of providing signatures for each file separately. Does Debian have any way to verify the tarball using this signed checksum file without some sort of custom script needed? Attached is an example of one such file. -- Ben Westover Hi, there is an issue opened for that (#1014333), contributions welcome !
