Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix
Control: reassign -1 crun Control: retitle -1 Ship the crun-wasm runtime Control: severity -1 wishlist Control: forwarded -1 https://github.com/containers/crun/issues/1468 On Sun, May 12, 2024 at 03:34:42PM +0300, Faidon Liambotis wrote: > Perhaps it's worth bringing it up with both crun and podman upstreams, I > don't think we're going to be the only distro dealing with this. (I can > take care of that.) We have a little more clarity from Giuseppe. I'll work on shipping crun-wasm on the next crun upload. (Still debating whether I should ship it in a different package or not.) Faidon
Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix
On Sat, May 11, 2024 at 11:16:00AM -0400, Reinhard Tartler wrote: > > I see three paths forward: > > 1) We do the same, creating a new (almost) empty package. > > 2) We ship a /usr/bin/crun-wasm symlink in the crun package. > > 3) We patch podman to use /usr/bin/crun instead of, or in addition to, > > /usr/bin/crun-wasm. > > > I think we should do either 1 or 2 to minimize divergence with upstream. My > preference would be 2 to enable an out-of-the box experience. Well... divergence with _which_ upstream? I think that's basically the question here. Upstream crun has no notion of "crun-wasm", AFAIK. There is one "crun" binary that just dynamically loads libwasmedge with dlopen(), among a few other libraries we don't have in Debian yet, e.g. criu or krun. There is nothing in its autoconf/Makefiles to install a symlink, either. The RPM spec does that. Hence, the existence of "crun-wasm" is an RPM packaging detail that *is* a divergence by itself, I think. However, that detail is now encoded into podman upstream. (It's also unclear to me why they decided to generate and ship a symlink, rather than just a metapackage. Is it just for changing podman's error messages?) Perhaps it's worth bringing it up with both crun and podman upstreams, I don't think we're going to be the only distro dealing with this. (I can take care of that.) > Is there any reason to not have that symlink installed by default in the > `crun` package? Technically, not, that's not hard. It just feels... icky to ship a symlink just to cover a packaging decision made in a different package, by another distro, no? Faidon
Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix
Control: tags -1 confirmed On Wed, May 08, 2024 at 03:10:40AM +0300, Eugen Stan wrote: > I followed the guide to run wasm images on my system and it failed with > errors. > > I believe the issue is that podman looks for crun-wasm binary by default. > I failed to configure podman to use crun instead of crun-wasm. > I created a simbolic link named crun-wasm: > > sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm Ouch! You're right. This worked when I enabled WasmEdge in crun, but was changed upstream at some point since. Apparently Fedora/RedHat ship a "crun-wasm" package, which contains a) this symlink, b) a dependency on WasmEdge. In Debian, the main "crun" package has a Suggests on libwasmedge0. I see three paths forward: 1) We do the same, creating a new (almost) empty package. 2) We ship a /usr/bin/crun-wasm symlink in the crun package. 3) We patch podman to use /usr/bin/crun instead of, or in addition to, /usr/bin/crun-wasm. I don't particularly love option (1). I'm split between options (2) and (3), not loving either. Thoughts? Faidon
Bug#1068131: ITP: bootterm -- simple terminal to ease connections with SBCs
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bootterm Version : 0.4+git2023013 Upstream Contact: Willy Tarreau * URL : https://github.com/wtarreau/bootterm * License : Expat Programming Lang: C Description : simple terminal to ease connections with SBCs Bootterm is a simple, reliable and powerful terminal designed to ease connection to ephemeral serial ports as found on various SBCs, and typically USB-based ones. . Main features: * automatic port detection (uses the most recently registered one by default) * enumeration of available ports with detected drivers and descriptions * wait for a specific, a new, or any port to appear (convenient with USB ports) * support for non-standard baud rates (e.g. 74880 bauds for ESP8266) * can send a Break sequence and toggling RTS/DTR for various reset sequences, even on startup * fixed/timed captures to files (may be enabled at run time) * optionally time-stamped captures (relative/absolute dates) * reliable with proper error handling * single binary without annoying dependencies, builds out of the box * supports stdin/stdout to inject/download data * configurable escape character and visible character ranges Note that upstream has chosen /usr/bin/bt for the binary's name, but I'm trying to persuade them to use /usr/bin/bootterm instead, in order to avoid taking up a two-letter name in Debian's shared $PATH namespace, for what is intended to be a binary for a niche audience. At minimum I'd expect us to carry a Debian-specific patch.
Bug#1067238: Add support for man preprocessors, like tbl
On Sun, Mar 31, 2024 at 06:52:23PM +1100, Brendan O'Dea wrote: > > help2man does not output any tables by default (AIUI) but in case one > > adds text e.g. in their DESCRIPTION that includes tables, it won't work. > > help2man is intended to take `--help` output and massage it into a > manual page. The `--help` output still needs to be readable however, > since people do invoke `foo --help` from the command line. One option > would be to have help2man recognize markdown-format tables, which > would preserve the property of the `--help` output being readable. A > simpler option would be to add the table to an include file: > https://www.gnu.org/software/help2man/#Including-text Sorry I probably wasn't clear: that's exactly what I meant. I added a table in the DESCRIPTION through --include and a [DESCRIPTION] section, that includes a table. > > While my issue is specific to the "tbl" preprocessor, man(1) supports > > other preprocessors, including eqn (e), grap (g), pic (p), tbl (t), > > vgrind (v), refer (r). See the `-p` argument. Perhaps help2man should > > just gain an argument to support adding arbitrary preprocessors to its > > output? > > I will look into that. #1049968 may also be useful context, in particular G. Branden Robinson's comments. Thanks, Faidon
Bug#1055279: tox-current-env: potential bugs on armel
Hi Bo, Thanks for the short reaction time and for spending your time on this bug, much appreciated! On Fri, Mar 22, 2024 at 01:26:35PM +0800, Bo YU wrote: > Thanks your detailed analysis for it. I have uploaded -3 to unstable to > hope to unblock tox migrating. But these are some unexpected maybe. tox has migrated since. Honestly I'm not sure why, given the regression! So there isn't as much urgency as there was when I filed this bug, I'd say. > This will lead a autopkgtest on s390x[0] again from its tracker page[1] to > get the link(UTC+8 13:06 2024/03/22). > > But another retry on s390x it passed on s390x[2]. > > [0]: https://ci.debian.net/packages/t/tox-current-env/testing/s390x/44235641/ > [1]: https://tracker.debian.org/pkg/tox-current-env > [2]: https://ci.debian.net/packages/t/tox-current-env/ Yup, looks like the same bug all over the place, effectively a race. > Do you think I will need to upload it to unstable again with `sorted` > for `test_allenvs_print_deps_to_file` as I analyzed above? It's clearly a bug IMHO, so it'd be good to fix at some point. No urgency with regards to the tox migration as I said, but this will happen again on e.g. the next tox upload. If I were you I'd fix it in git, submit all of these fixes to upstream, wait a month or two so in case upstream releases a new version (hopefully with these), and then upload regardless. Thanks again, Faidon
Bug#1067238: Add support for man preprocessors, like tbl
Source: help2man Version: 1.49.3 Severity: wishlist In trixie and above, including tables in a manpage does not work anymore, unless the "tbl" preprocessor is added explicitly. This means tables are not rendered, and warnings of the following form are emitted: warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined) help2man does not output any tables by default (AIUI) but in case one adds text e.g. in their DESCRIPTION that includes tables, it won't work. Per [1][2] the fix is for the first line of the manpage to be: '\" t I did not find a way to inject this with help2man, and checking through the source, it just seems there is no support for that. (I can of course easily post-process the file, but this is not ideal.) 1: https://lists.debian.org/debian-devel/2023/08/msg00220.html 2: https://manpages.debian.org/bookworm/man-db/man.1.en.html#DEFAULTS To reproduce, you can generate a table with: $ cat
Bug#1018261: confmodule should be distributed separately from debconf
On Sun, Aug 28, 2022 at 08:56:18AM +0200, Gioele Barabucci wrote:
> could you please ship `/usr/share/debconf/confmodule{,.sh}` in a separate
> package, for example debconf-common?
In the same spirit, I think Debconf::Client::ConfModule should also be
split into its own package, as it seems entirely distinct from debconf
itself, and similar to e.g. python3-debconf in that sense.
Per established Perl conventions, perhaps something like
libdebconf-client-confmodule-perl?
The dependency transition is going to be an interesting challenge. I see
Giole has resorted to (Pre-)Depends, for the Shell part, which makes
sense given its size, and could work for Perl as well.
Debconf::Client::ConfModule is used by a tiny minority of packages
though, so perhaps something more creative can be used in the long-term,
like perhaps dh_installdebconf getting taught to add the appropriate
dependencies if necessary.
Faidon
Bug#1055279: tox-current-env: potential bugs on armel
Control: retitle -1 test_allenvs_print_extras tests are flaky
On Fri, Nov 03, 2023 at 08:57:57PM +0800, Bo YU wrote:
> The bug was opened to track a potential bugs on armel(or others slow
> archs, but it does not always happened).
>
> Fix from upstream[0] may take a long time so if you use the package please
> keep in mind about this unless the bug was closed.
I recently uploaded tox/4.14.1-1. tox-current-env autopkgtests fail on
s390x[1] with a similar error, which in turn is currently preventing tox
from migrating into testing[2]
1: https://ci.debian.net/packages/t/tox-current-env/testing/s390x/44050718/
2: https://qa.debian.org/excuses.php?package=tox
This bug was originally for test_allenvs_print_extras_to_file(); for
this I would imagine think the fix is something like:
- assert prep_tox_output(result.stdout) == expected
+ assert sorted(prep_tox_output(result.stdout)) == sorted(expected)
The s390x autopkgtest above fails on test_allenvs_print_extras(), which
is very similar. However, that one seems to have a sorted() already:
45s def test_allenvs_print_extras(print_extras_stdout_arg):
45s result = tox(print_extras_stdout_arg)
45s expected = []
45s for env in envs_from_tox_ini():
45s expected.extend(("dev", "full", f"{env}: OK"))
45s expected.pop() # The last "py310: OK" is not there
45s expected.append(tox_footer(spaces=0))
45s expected = ("\n".join(expected)).splitlines()
45s > assert sorted(prep_tox_output(result.stdout).splitlines()) ==
sorted(expected)
I don't fully grok what this is supposed to be doing (but I've looked at
it for only a couple of minutes). That .pop() does look suspicious
though, in the sense that it operates before the output is sorted.
Faidon
Bug#1066929: Package outdated, crippled, unfit for release
Source: bcachefs-tools Version: 24+really1.3.4-2 Severity: serious I don't think bcachefs-tools in its current state is fit for release. * The package is severely behind: Debian is currently at 1.3.4. Upstream is at 1.6.4. * Chronologically speaking, 1.3.4 was released in November 2023, so in theory, it's not that old. In practice, however, bcachefs is a fast-moving project, and in particular the past few months have been critical both in terms of pace, and in terms of stabilization: bcachefs was merged in the upstream Linux kernel, starting with v6.7, released in January 2024. Linux 6.8 was released this week as well, with even more fixes, including the ability to use the in-kernel fsck. * Linux v6.7 entered unstable this week, which opens up the user base for this package quite a bit. Especially with the recent hype, others may be inclined to try it, and be surprised by back-and-forth metadata migrations between kernel and userspace, as a concrete example of a problem. * Moreover, even the outdated version that we have in Debian is crippled, because large parts of its functionality are missing: all the Rust functionality included in this software, which is ever increasing (up to being required, in newer upstream releases). This has been reported previously as #1060256. * I'd also argue that the package lacks attentive maintainership, and would recommend to orphan and/or find one or more comaintainers: - There are various packaging issues: wrong version number, branches not pushed into git etc. etc. (most reported as #1054620) - There hasn't been any coordination/two-way street with upstream; I contributed a bunch of PRs to help with the Rust integration bits in Debian, and I know Steinar was in touch with them as well, but none of this was done by the package maintainer or in coordination with them. - No serious effort was made to package the Rust bits before. I worked on it and made it happen with only a few hours of work, as documented in that bug report above. - There hasn't been any coordinated system integration effort with other Debian packages like grub/initramfs-tools/etc. #1061525 describes issues that are across projects and up for us, the distributor, to really triage and coordinate fixes for. - Finally, while a bunch of work happened by others, like myself paving the road for the Rust bits to be enabled, and by Steinar to prepare fixed packages (and even an NMU), there hasn't been an appropriate level of response to our contributions IMHO, that would have included in an upload that includes all of these fixes. We are basically blocked. Now, I realize that the maintainer may be quite busy with other tasks, including what I can only image is a busy Debian workload due to some other, erm, duties (for which I'm thankful!). In an effort to be more collegial, I've even reached out in private, twice. But, I think we are at the point where weeks pass while the state of this package is simply not OK, a disservice to our users, and unfit for release, hence this RC bug. This is a filesystem we're talking about, so outdated/buggy software can even mean broader system-wide issues including data corruption. In terms of a path forward: I would recommend to upload the package as prepared by Steinar ASAP, and/or submit an RFH/O for the long-term maintainership of the package. Best, Faidon
Bug#1066908: lowdown FTCBFS: performs a native build
On Fri, Mar 15, 2024 at 07:23:04AM +0100, Helmut Grohne wrote:
> override_dh_auto_configure:
> + CC='$(CC)' \
> CFLAGS="${CFLAGS}" \
> ./configure \
> PREFIX=/usr \
One more thing: should we also pass AR=$(AR)? It did matter for
WebAssembly (which required the use of llvm-ar) and why I added support
for it to oconfigure¹, but I'm not sure if it makes a difference between
different binutils architectures when cross-building.
Thanks again,
Faidon
1: https://github.com/kristapsdz/oconfigure/pull/23
Bug#1066908: lowdown FTCBFS: performs a native build
> lowdown fails to cross build from source, because it performs a native
> build. Since there is a configure script, debhelper concludes that the
> autoconf build system should be used and that it thus should not pass
> cross tools to make, but it really should. Also since dh_auto_configure
> is overridden, passing cross flags there (CC in particular) is required.
> Last but not least, the pkg-config invocations also need to use the host
> tools. I'm attaching a patch for your convenience.
Thanks for this, Helmut!
> include /usr/share/dpkg/architecture.mk
> +-include /usr/share/dpkg/buildtools.mk
Why -include? Are there conditions under which buildtools.mk wouldn't
exist?
> +PKG_CONFIG ?= pkg-config
...and if we assume buildtools.mk always exist, can we drop this and
assume PKG_CONFIG is always going to be defined?
> # output every command that modifies files on the build system.
> #export DH_VERBOSE = 1
> @@ -10,17 +12,18 @@
> # Use libbsd for a system copy of the BSD functions, instead of upstream's
> # embedded compats.c coming from the oconfigure project.
> # Also see https://github.com/kristapsdz/oconfigure/issues/19
> -CFLAGS += $(shell pkg-config --cflags libmd libbsd-overlay)
> -LDFLAGS += $(shell pkg-config --libs libmd libbsd-overlay)
> +CFLAGS += $(shell $(PKG_CONFIG) --cflags libmd libbsd-overlay)
> +LDFLAGS += $(shell $(PKG_CONFIG) --libs libmd libbsd-overlay)
>
> # avoid symbol leakage; keep this in the package until merged upstream:
> # see https://github.com/kristapsdz/lowdown/issues/109
> LDFLAGS += -Wl,--version-script=debian/liblowdown.map
>
> %:
> - dh $@
> + dh $@ --buildsystem=makefile
>
> override_dh_auto_configure:
> + CC='$(CC)' \
> CFLAGS="${CFLAGS}" \
> ./configure \
> PREFIX=/usr \
LGTM. I'll commit those and upload once we resolve the (trivial)
question above :)
Best,
Faidon
Bug#1066139: podman: Cannot create a network with dns_enabled
Control: tags -1 + moreinfo On Wed, Mar 13, 2024 at 12:17:12AM +0100, Antoine Sirinelli wrote: > When I create a new custom network, the dns is not enabled: > > $ podman network create test > test > $ podman network inspect test > > [...] > > The outcome should have "dns_enabled" to true. Per podman-network(1): > Podman supports two network backends Netavark and CNI. Netavark is the > default network backend and was added in Podman version 4.0. CNI is > deprecated and will be removed in the next major Podman version 5.0, > in preference of Netavark. For DNS, you need to have installed: - golang-github-containernetworking-plugin-dnsname (CNI, deprecated) - aardvark-dns (Netavark) podman Depends on golang-github-containers-common which Recommends netavark, which Recommends aardvark-dns, so a clean install brings in Netavark by default (per upstream). I've verified that clean installs, with the exact commands you executed, with either Netavark (default install), or without Netavark but with golang-github-containernetworking-plugin-dnsname, and could not reproduce the issue. So I would guess that you don't have either of those packages installed. The question is why. 1) Perhaps you installed podman with apt install --no-install-recommends? In this case, I don't think this is a bug. Recommends is the appropriate package relationship here, and failure to install all the recommended dependencies can result in reduced, non-essential functionality. 2) Alternatively, perhaps you first set up podman without Netavark (e.g. before 4.0), and later upgraded to a newer version? (In this case, I wonder how the setup ended up without the "dnsname" plugin. But moot at this point regardless) I don't think an automatic transition from the old stack to the new stack exists. A "podman system reset" should fix it; I'm not sure if there is a less intrusive way to do that. Perhaps we'll know more about upgrade paths with the 5.0 release, which is imminent. 3) Some other reason that I can't imagine right now :) Would love to hear from you and some insight on how your setup ended up in the way it did. Perhaps we could figure out ways to avoid any further surprises. Best, Faidon
Bug#1065732: podman: Please "Recommends: containers-storage" so overlay driver is used by default
On Sat, Mar 09, 2024 at 06:44:56AM -0700, Anthony Fok wrote: > Package: podman > Version: 4.9.3+ds1-1 > Severity: normal > > [...] > > Eventually, I ran the following commands to remedy the situation: > > sudo apt install containers-storage > rm -rf ~/.local/share/containers > podman system reset > > After that, `podman info` shows: > > graphDriverName: overlay > > I propose promoting the dependency on the containers-storage package > from "Suggests" to "Recommends", or even to "Depends", so that > "overlay" is consistently chosen as the default storage driver > which provides a much better overall experience for end users. I believe this has been previously reported as #1062176. Are you experiencing this with 4.9.3 as the bug's metadata suggests, or did you perhaps set up podman e.g. on bullseye, and then later upgraded (without a system reset)? In other words, if you run the "system reset" commands, without having containers-storage installed, does it also address your issue? In my investigation in the aforementioned bug, I came into the conclusion that this has already been fixed (properly) upstream in versions that we already have in trixie, and that it's perhaps a bit too invasive to do as stable upload. Let me know if you think this is wrong and/or you disagree. Regards, Faidon
Bug#1043530: closed by Debian FTP Masters (reply to Yangfl ) (Bug#1043530: fixed in micropython 1.22.1+ds-1)
Control: reopen -1 Hi there, Thanks for including asyncio in the 1.22.1+ds-1 upload! That's already going to be extremely useful! The bug report was also requesting to ship the "mip" module as well, as evident from the Subject and this: On Sat, Feb 10, 2024 at 06:27:09PM +, Debian Bug Tracking System wrote: > On that matter, the build above also enabled "mip", the new package > manager and flagship feature of v1.20: >>>> import mip >>>> > (There are some mbedTLS DEBUG messages being emitted when fetching from > e.g. GitHub, that I haven't tracked down yet, but that's getting a > little offtopic.) I don't believe this has happened yet, so reopening the bug report. On a different note: I looked into git to check whether this was fixed there before I replied here. It was quite hard to understand the commit history: it seems like the entirety of the upload was pushed as one commit, including a re-export of debian/patches etc. I would recommend that you commit changes as you go, one commit per functional change etc. Thanks, Faidon
Bug#1060256: Please enable the Rust parts
On Tue, Jan 23, 2024 at 10:58:03AM +0200, Faidon Liambotis wrote: > > * The "udev" crate is required, and missing from the > > missing list. Note that it's distinctly different to > > librust-libudev-dev. debcargo generates a librust-udev-dev package > > that seems to build with minor modifications, and no other > > dependencies. > > Still required. I uploaded that last week, currently sitting in NEW. > > * bch_bindgen also depends on a custom fork of rust-bindgen, checked out > > from bcachefs' git. This seems to have only a patch compared to what's > > shipped in Debian, originating in an upstream issue: > > https://github.com/rust-lang/rust-bindgen/issues/2240 > > > This turned out to be more complicated. There's been some discussion on > the upstream bug tracker: > https://github.com/koverstreet/bcachefs-tools/issues/202 > including a proposed way forward, that Thomas Bertschinger kindly > implemented: > https://lore.kernel.org/linux-bcachefs/20240122201913.GA207770@fedora-laptop/T/#t This was merged, and bcachefs-tools could be built with Debian's bindgen for a short while. In the time since, a more generic fix went into bindgen 0.69.4, and backed out from bcachefs: https://lore.kernel.org/linux-bcachefs/pcj3od6gpxug7rwksamxfn2hnz2mrebrypa6ss67igmupeqvip@7r2s22ajvygg/T/#t This will mean one of two options: a) upgrade bindgen in Debian to 0.69.4, b) cherry-pick a revert of this patch. Faidon
Bug#1062598: libpod: Add support for LoongArch
On Mon, Feb 05, 2024 at 02:13:50PM +0800, 张家岭 wrote: > Hi, this can support loong64 build , Ｉ build this in my local . and I'll > submit to upstream . But is your patch necessary to build for loong64? Does the build fail without your patch? Faidon
Bug#1062598: libpod: Add support for LoongArch
Control: tags -1 upstream moreinfo On Fri, Feb 02, 2024 at 04:40:08AM +, JiaLing Zhang wrote: > Please help to add support for loong64.I have build it in my local > machine. Unless I'm missing something, both of your changes seem... unrelated to what we ship in Debian. Have you verified that this patch is needed? In any case, kindly also submit any patches upstream. Thanks! Faidon
Bug#1062176: podman: Package containers-storage should be recommended
Control: reassign -1 src:golang-github-containers-storage 1.43.0+ds1-8 Control: fixed -1 1.48.1+ds1-1 On Wed, Jan 31, 2024 at 03:45:35PM +0100, Holger Leskien wrote: > at the moment the dependency on the containers-storage package is "suggests" > only. However, this means that the package is not installed when podman is > installed and rootless (all?) containers are then started with the storage > driver vfs, even though overlay would be possible. This is slow, uses much > more > space and leads to a poor user experience. > > I only noticed that vfs was the cause with a large image with many layers and > looked for a solution. Installing containers-storage would have been so easy. > > Please change the dependency to Recommends. I understand how a VFS driver default makes for a poor out of the box experience. First of all, I can verify that bookworm rootless defaults to "vfs", as you established. bookworm rootful, and trixie/sid rootful as well as rootless default to "overlay". I don't think your proposed fix is correct. Installing containers-storage (and thus a storage.conf) may or may not be a good idea, I am not sure about that. However, the cause of your issue here is clear to me: the containers-storage code (which podman embeds, as it's Go code) up until v1.47 defaulted to "vfs". This was changed with: https://github.com/containers/storage/commit/e3b18ab721f02f801d93806ac789e958cbe6a050 and amended with: https://github.com/containers/storage/commit/9ef15e4d49b76a9af9f548e9415153009faa54d8 Both in >= 1.47. While we could backport these commits in a future stable upload, I am not sure if these are appropriate for a stable release. This means retroactively changing Debian's defaults in a stable update, and to a value that diverges from upstream for that particular combination of containers-storage and podman. Regards, Faidon
Bug#1030845: RFP: sbctl -- Secure Boot Manager
On Wed, Feb 08, 2023 at 11:32:50AM +0100, Marco d'Itri wrote: > Package: wnpp > Severity: wishlist > > * Package name: sbctl > Version : 0.10 > Upstream Contact: Morten Linderud > * URL : https://github.com/Foxboron/sbctl/ > * License : MIT > Programming Lang: Go > Description : Secure Boot Manager I've pushed: https://salsa.debian.org/go-team/packages/sbctl as well as the missing dependency: https://salsa.debian.org/go-team/packages/golang-github-foxboron-go-uefi Note that there are two debian/patches for sbctl: 1) First, to use FHS paths, diverging from upstream's locations (which is non-ideal). Upstream issue #57 is open upstream: https://github.com/Foxboron/sbctl/issues/57 2) Second, to disable TPM support. It requires a long dependency chain for Go-Attestation that it felt too overwhelming for me. YMMV :) This package builds and works for me. I'm not up for maintaining it in the long-run though, so I'm leaving this as an RFP and *not* uploading it to unstable. Hopefully this initial packaging work is useful to whoever decides to pick it up. If anyone else is up for it, I may be available to sponsor the uploads and/or provide code reviews. Best, Faidon
Bug#1060256: Please enable the Rust parts
A few updates:
On Mon, Jan 08, 2024 at 12:45:35PM +0200, Faidon Liambotis wrote:
> * librust-gag-dev is now in Debian.
Still true, but also now moot, as it the dependency has been removed
upstream:
https://github.com/koverstreet/bcachefs-tools/commit/5e224596cfdf9ad9413536482224e2fe79b9e387
> * I don't think librust-parse-display-dev is needed. Upstream indeed
> has parse-display in Cargo.toml, but as far as I can tell, it's not
> used anywhere and it's just a spurious dependency? Needs to be
> forwarded upstream, I think.
Did that, and more dependencies were removed as a result of that
subthread:
https://github.com/koverstreet/bcachefs-tools/commit/5ed0dcc00100c2f361e917760bd114a7af12394a
https://github.com/koverstreet/bcachefs-tools/commit/807cabc4c960347319b5f9566e4d24b28e0183b4
> * The "udev" crate is required, and missing from the
> missing list. Note that it's distinctly different to
> librust-libudev-dev. debcargo generates a librust-udev-dev package
> that seems to build with minor modifications, and no other
> dependencies.
Still required.
> * A bunch of these packages have mismatched versions. From a quick
> glance, everything compiled with the versions in Debian, except for
> rpassword that also required a patch to account for an API change:
> -rpassword::read_password_from_tty(Some("Enter passphrase: "))?
> +rpassword::prompt_password("Enter passphrase: ")?
Merged upstream with:
https://github.com/koverstreet/bcachefs-tools/commit/06ff8b55b70fda44d91b31b5511fafd1680a8934
> * bch_bindgen also depends on a custom fork of rust-bindgen, checked out
> from bcachefs' git. This seems to have only a patch compared to what's
> shipped in Debian, originating in an upstream issue:
> https://github.com/rust-lang/rust-bindgen/issues/2240
>
> This could perhaps be reported against the Debian package to backport
> in a debian/patches patch.
This turned out to be more complicated. There's been some discussion on
the upstream bug tracker:
https://github.com/koverstreet/bcachefs-tools/issues/202
including a proposed way forward, that Thomas Bertschinger kindly
implemented:
https://lore.kernel.org/linux-bcachefs/20240122201913.GA207770@fedora-laptop/T/#t
Finally, note that in the meantime main() was converted to Rust, so now
Rust is not just a nice to have, but a necessary dependency to newer
upstream versions:
https://github.com/koverstreet/bcachefs-tools/commit/0a284fc4ffcbb46f0a4b921415ef12a9c75fa05c
To summarize, the next upstream release will make the Rust parts
necessary, but (hopefully) much easier to package. But someone should
upload the only missing dependency, librust-libudev-dev, in the
meantime. (I'd prefer for that someone to not be me :)
Faidon
Bug#1061194: podman: cannot run rootful containers with many layers using overlay driver
Control: reassign -1 src:golang-github-containers-storage 1.43.0+ds1-8 Control: fixed -1 1.45.1+ds1-1 Control: affects -1 src:libpod On Sun, Jan 21, 2024 at 01:17:46AM +0800, Tee Hao Wei wrote: > Oh. I just noticed how Debian handles Go dependencies.. > > I guess this will actually need to be a cherry-pick to > golang-github-containers-storage-dev followed by a rebuild of podman. That's right, this is technically a golang-github-containers-storage-dev bug, so reassigning there. FWIW: $ git describe --contains 7c5964df95c892cfbdbce594cf5a8e2973c70fd7 v1.44.0~28^2 $ git describe --contains d232b36652d55b42a21f1713db7f7d455b837b3c v1.44.0~9^2 $ git checkout v1.43.0 HEAD is now at 04d8b90f9 Bump to v1.43.0 $ git cherry-pick 7c5964df95c892cfbdbce594cf5a8e2973c70fd7 d232b36652d55b42a21f1713db7f7d455b837b3c [...] $ $ git diff --stat v1.43.0.. drivers/overlay/mount.go | 97 - drivers/overlay/overlay.go | 50 tests/layers.bats | 40 +-- 3 files changed, 143 insertions(+), 44 deletions(-) I think that's big enough to make me at least a bit uncomfortable about a cherry-pick to stable. Could you elaborate on your use case? It sounds like this manifests only with a large number of layers, and I'm not sure how common this is. The alternative to a stable update is a backport of the latest podman version (currently 4.8.3), plus associated packages like containers/storage, of course. It's a moderate amount of work; Reinhard who's been doing the version updates in unstable could speak more to the work he's been putting into package updates etc. It would help with bringing in a lot of more fixes from what I'd consider a very active upstream. We also have #1059496, as another recent, concrete example. I'm still unsure and debating targeted s-p-u fixes vs. a backport. My concern is basically that we may start playing whack-a-mole. A quick peek at the upstream changelog reveals tons of fixed bugs in every release, and us trying to keep up by cherry-picking fixes to two years of upstream development may prove futile... Thoughts? Thanks, Faidon
Bug#1060440: llvm-toolchain-17: 1:17.0.6-4 FTBFS on i386, armel
On Thu, Jan 11, 2024 at 01:02:47PM +, Simon McVittie wrote: > It looks as though these are already known and already fixed in the > packaging git repo. Correct. I introduced these breakages with a couple of recent MRs, and hopefully fixed them with #130. I asked Sylvestre to hold off until we have build logs from all (official) architectures, so that's why these aren't fixed in unstable yet. (mips64el and risv64 are still building, although mips64el has never built LLVM 17, and my changes are not expected to fix that.) Faidon
Bug#1060256: Please enable the Rust parts
On Mon, Jan 08, 2024 at 12:45:35PM +0200, Faidon Liambotis wrote:
> * I don't think librust-parse-display-dev is needed. Upstream indeed
> has parse-display in Cargo.toml, but as far as I can tell, it's not
> used anywhere and it's just a spurious dependency? Needs to be
> forwarded upstream, I think.
>
> * A bunch of these packages have mismatched versions. From a quick
> glance, everything compiled with the versions in Debian, except for
> rpassword that also required a patch to account for an API change:
> -rpassword::read_password_from_tty(Some("Enter passphrase: "))?
> +rpassword::prompt_password("Enter passphrase: ")?
For posterity, I just reported these two issues to upstream, alongside a
few other comments:
https://github.com/koverstreet/bcachefs-tools/issues/202
Faidon
Bug#1060256: Please enable the Rust parts
Source: bcachefs-tools
Version: 24+really1.3.4-2
Severity: important
The bcachefs-tools package builds the C portion of the tarball, and not
the parts written in Rust (under rust-src/). This results in a crippled
functionality, such as the missing "mount" binary (#1057295).
There is a README.todo to that effect, that currently says:
> Dependencies available in Debian: librust-byteorder-dev librust-rpassword-dev
> librust-either-dev librust-errno-dev librust-itertools-dev librust-getset-dev
> librust-uuid-dev librust-libudev-dev librust-libc-dev librust-anyhow-dev
> librust-clap-dev librust-colored-dev librust-chrono-dev librust-log-dev
> librust-atty-dev
>
> Missing dependencies: librust-gag-dev librust-parse-display-dev
> librust-bch-bindgen-dev
This seems a bit inaccurate/outdated, in the following ways:
* librust-gag-dev is now in Debian.
* I don't think librust-parse-display-dev is needed. Upstream indeed
has parse-display in Cargo.toml, but as far as I can tell, it's not
used anywhere and it's just a spurious dependency? Needs to be
forwarded upstream, I think.
* The "udev" crate is required, and missing from the
missing list. Note that it's distinctly different to
librust-libudev-dev. debcargo generates a librust-udev-dev package
that seems to build with minor modifications, and no other
dependencies.
* A bunch of these packages have mismatched versions. From a quick
glance, everything compiled with the versions in Debian, except for
rpassword that also required a patch to account for an API change:
-rpassword::read_password_from_tty(Some("Enter passphrase: "))?
+rpassword::prompt_password("Enter passphrase: ")?
* librust-bch-bindgen-dev is not a package that's missing; that's from
the bcachefs-tools source tree, under rust-src/bch_bindgen/.
* In turn, rust-src/bch_bindgen/ requires librust-bitfield-dev and
librust-paste-dev, both already in Debian.
* bch_bindgen also depends on a custom fork of rust-bindgen, checked out
from bcachefs' git. This seems to have only a patch compared to what's
shipped in Debian, originating in an upstream issue:
https://github.com/rust-lang/rust-bindgen/issues/2240
This could perhaps be reported against the Debian package to backport
in a debian/patches patch.
All in all as far as I can tell the tally is: 1 new easy-to-package Rust
library, 1 patch to a third-party Debian package, 1 patch to
bcachefs-tools, a few Cargo.toml version bumps. That doesn't look too
bad, I guess?
Faidon
Bug#1054620: bcachefs-tools: Issues in packaging and git repo
On Thu, Oct 26, 2023 at 11:00:56PM +0200, Daniel Gröber wrote: > - gbp.conf doesn't disable pristine-tar but no pristine-tar branch is >available, making gbp export-orig fail In fact, it's *enabling it* (pristine-tar = True). > - debian/files was committed to the git repo when it shouldn't be. > > - The upstream version 24~really1.2 should likely have been s/~/+/ > 24+really1.2. Currently it compares as less than what's in unstable > "24". These seem to be fixed. > TBH it seems to me +really isn't appropriate here as it's never > going to go away. You should use an epoch instead, after posting on d-devel > obv. Agreed -- I understand wanting to avoid epochs but I think that ship has sailed. I don't think upstream is going to release v25 anytime soon :) On a related note, 1.3.4 is behind now; upstream has released v1.4.0 a couple of weeks ago. bcachefs is now in Linux 6.7 (released yesterday), so it'd be nice to have up-to-date userspace as well. Thanks, Faidon
Bug#984879: podman does not work on Debian with selinux loaded
Hi Laurent & Sam, On Thu, May 13, 2021 at 10:14:38AM +0200, Laurent Bigonville wrote: > I see that you reassigned this bug to the refpolicy package and FTR I don't > completely agree with that. > > Most of the other applications that manipulates SELinux objects are behaving > nicely when they are running in permissive and the policy is not including > the type they needed. > > So having the policy implement the needed types is good for a security > perspective, but podman shouldn't fail hard (and without a clear message). > > This was partially addressed upstream in > https://github.com/containers/storage/pull/879 (still need to test it) (I'm going through older bugs in the BTS that affect podman, and trying to verify if they're still present.) I read through this bug, plus the associated upstream ones. I know very little about SELinux, and the upstream bugs themselves do not provide a ton of extra clarity. It would help to list all steps needed to reproduce this bug. Guessing what the problem may be, I tried the following: 1. Use the Debian sid daily cloud image and boot with QEMU, fully up-to-date as of 2024-01-01 (happy new year ;) 2. adduser user 3. apt install --no-install-recommends podman slirp4netns uidmap dbus-user-session 4. Verify that "podman run --rm -it debian:sid" runs: a. as user "root" b. as user "user" (note: do not use sudo, login in another tty instead) 5. apt install --no-install-recommends selinux-basics selinux-policy-default auditd 6. selinux-activate 7. Reboot 8. Run "sestatus" and verify that SELinux status is "enabled" and in permissive mode. 9. "podman run ..." as users "root" & "user" again (cf. step 3). 10. setenforce 1; sestatus | grep mode 11. "podman run ..." as users "root" & "user" again (cf. step 3). In both steps (8) and (10), i.e. even with SELinux in enforcing mode, both rootful and rootless podman seemed to work for me. Note that if I install SELinux before podman (so steps 5-8 before 3-4), then a: restorecon -R /var/lib/containers # for rootful or restorecon -R $HOME/.local/share/containers # for rootless are required, but only *after* podman initializes its directory, i.e. after the first "podman run" invocation. I'm not sure what the SELinux best practice is for dealing with this, but I assume nothing podman-specific. So, should we consider this bug as fixed? Perhaps due to containers/storage#879 or some other fix? Regards, Faidon
Bug#1059677: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u5
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: lib...@packages.debian.org, siret...@tauware.de Control: affects -1 + src:libpod [ Reason ] This will address the no-dsa CVE-2022-2989. The vulnerability has been fixed upstream and has been in bookworm, trixie and sid for a long time now. [ Impact ] Absence of this patch, podman in bullseye will remain vulnerable to CVE-2022-2989, as detailed here: https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/ [ Changes ] bullseye has v3.0.1. The original fix was included in v4.3.0, and was: https://github.com/containers/podman/commit/d82a41687e614d9ac8b2d169dee47fe226835e4c However, upstream (which is mostly RedHat) maintains a separate "v3.0.1-rhel" branch, where they're backporting fixes to RHEL. The patch included in this upload is lifted directly from that branch, with no further changes: https://github.com/containers/podman/commit/a256d7188c9db64a00a37798e6a2f0f59b5d798f [ Tests ] Upstream has an extensive test suite, including unit and integration testing. Some of those tests running as part of the Debian build process. The fix has been presumably tested by RHEL users as well. Furthermore, I've verified that the current package is vulnerable, and the proposed package addresses the vulnerability, by testing both deb11u4 and deb11u5 with this PoC code: https://github.com/sjmurdoch/permission-experiment [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Risks ] Minimal: upstream has backported and tested this patch themselves, and versions including this exact patch have been deployed to end (RHEL) users for over a year now. [ Other info ] Thanks, Faidon diff -Nru libpod-3.0.1+dfsg1/debian/changelog libpod-3.0.1+dfsg1/debian/changelog --- libpod-3.0.1+dfsg1/debian/changelog 2023-04-17 01:16:11.0 +0300 +++ libpod-3.0.1+dfsg1/debian/changelog 2023-12-29 17:26:49.0 +0200 @@ -1,3 +1,12 @@ +libpod (3.0.1+dfsg1-3+deb11u5) bullseye; urgency=medium + + * CVE-2022-2989: Cherry-pick "Add container GID to additional groups" patch +from the v3.0.1-rhel upstream branch (itself a backport from v4.3.0), to +address an incorrect handling of supplementary groups. (Closes: #1019591) + * Add myself to Uploaders. + + -- Faidon Liambotis Fri, 29 Dec 2023 17:26:49 +0200 + libpod (3.0.1+dfsg1-3+deb11u4) bullseye; urgency=medium * Recompile to fix parsing of DBUS_SESSION_BUS_ADDRESS (Closes: #1018816) diff -Nru libpod-3.0.1+dfsg1/debian/control libpod-3.0.1+dfsg1/debian/control --- libpod-3.0.1+dfsg1/debian/control 2023-04-17 01:16:11.0 +0300 +++ libpod-3.0.1+dfsg1/debian/control 2023-12-29 17:26:49.0 +0200 @@ -3,7 +3,10 @@ Priority: optional Standards-Version: 4.5.0 Maintainer: Debian Go Packaging Team -Uploaders: Dmitry Smirnov , Reinhard Tartler +Uploaders: + Dmitry Smirnov , + Reinhard Tartler , + Faidon Liambotis , Build-Depends: debhelper-compat (= 12) ,bash-completion ,conmon diff -Nru libpod-3.0.1+dfsg1/debian/.gitlab-ci.yml libpod-3.0.1+dfsg1/debian/.gitlab-ci.yml --- libpod-3.0.1+dfsg1/debian/.gitlab-ci.yml2023-04-17 01:16:11.0 +0300 +++ libpod-3.0.1+dfsg1/debian/.gitlab-ci.yml1970-01-01 02:00:00.0 +0200 @@ -1,25 +0,0 @@ -# https://docs.gitlab.com/ce/ci/yaml/#include -include: - - remote: https://salsa.debian.org/onlyjob/ci/raw/master/onlyjob-ci.yml - -## "amd64-unstable" always runs by default followed by lintian. - -## Job to check Build-Depends versioning: -amd64-testing_unstable: - extends: .build - variables: -arch: amd64 -dist: testing_unstable - -i386-unstable: - extends: .build - variables: -arch: i386 -dist: unstable - -amd64-experimental: - extends: .build - variables: -arch: amd64 -dist: experimental diff -Nru libpod-3.0.1+dfsg1/debian/patches/CVE-2022-2989-Add-container-GID-to-additional-groups.patch libpod-3.0.1+dfsg1/debian/patches/CVE-2022-2989-Add-container-GID-to-additional-groups.patch --- libpod-3.0.1+dfsg1/debian/patches/CVE-2022-2989-Add-container-GID-to-additional-groups.patch 1970-01-01 02:00:00.0 +0200 +++ libpod-3.0.1+dfsg1/debian/patches/CVE-2022-2989-Add-container-GID-to-additional-groups.patch 2023-12-29 17:26:49.0 +0200 @@ -0,0 +1,89 @@ +From a256d7188c9db64a00a37798e6a2f0f59b5d798f Mon Sep 17 00:00:00 2001 +From: Matthew Heon +Date: Fri, 2 Sep 2022 13:40:29 -0400 +Subject: [PATCH] Add container GID to additional groups + +Mitigates a potential permissions issue. Mirrors Buildah PR #4200 +and CRI-O PR #6159. + +Cherry-pick conflicts for v3.0.1-rhel branch have been addressed. + +Signed-off-by: Matthew Heon +--- + libpod/container_
Bug#1021207: lintian: Please reconsider the type and size of field-too-long
On Mon, Oct 03, 2022 at 07:57:36PM +0200, Mathias Behrle wrote: > E: tryton-modules-all: field-too-long Depends (5604 chars > 5000) > > > > Looking at #942943 and #942487 it looks as if the issue with reprepro > should be mitigated with > https://salsa.debian.org/debian/reprepro/-/commit/7cb8fcf53c077467c4f38b5a48f706e7b5f75f4c > > So I am asking for re-evaluation and/or advice > > - if this limitation still stands? > - if the former is true this shouldn't be rather a warning than an > error? > - if the former is true the only way out is to split the Depends into > sub-packages? For what it's worth, we're seeing this error trigger in podman, for the Built-Using field (it's golang) Lintian already has exceptions for "package-list" and "description" (per #942493), and while we could also add "Built-Using" to the list, I kinda wonder if this is a game of a whack-a-mole and this heuristic should be revisited, especially in the light of the reprepro fix mentioned by Mathias above. Thanks, Faidon
Bug#1058090: oscrypto: FTBFS: ModuleNotFoundError: No module named 'imp'
Control: tags -1 + fixed-upstream
Dear maintainer,
On Tue, Dec 12, 2023 at 08:58:48AM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
>
> > File "/<>/tests/__init__.py", line 4, in
> > import imp
> > ModuleNotFoundError: No module named 'imp'
> >
This seems to have been fixed upstream by
https://github.com/wbond/oscrypto/commit/3865f5d528740aa1205d16ddbee84c5b48aeb078
("imp" was replaced by "importlib" in upstream Python.)
So hopefully it's just a matter of a simple backport. Do you have the
time to handle it, or would you like someone else from the Python team
(such as myself) to handle it instead?
Thanks,
Faidon
Bug#1057838: clang-17: c++ include dir from sysroot unexpectedly in include paths when in wasm c mode
Thanks, Sylvestre for the Cc and Israel for the bug report! On Fri, Dec 15, 2023 at 02:00:55PM +0100, Sylvestre Ledru wrote: > > The above lines are adding c++ include paths in the > > method (WebAssembly::AddClangSystemIncludeArgs) > > for adding only system/c include paths. > > I think the c++ include paths should only be added in the methods for > > adding > > libc++ (WebAssembly::addLibCxxIncludePaths) or libstdc++ > > (WebAssembly::addLibStdCXXIncludePaths) include > > paths. Israel, I can confirm that your interpetation is correct :) Can you confirm whether you're experiencing the same issue with clang-16? Sylvestre, from a cursory look I think the patch that I recently provided, the one that you applied and was included in the src:llvm-toolchain-16 1:16.0.6-19 upload, has not been carried over to at least the 17 branch. I think this will probably fix this bug as well. Thanks, Faidon
Bug#1036697: asterisk: CVE-2023-27585
Dear Jonas, On Mon, Aug 07, 2023 at 03:51:51PM +0300, Faidon Liambotis wrote: > Dear maintainer, security team, > > (See #1032092 for a similar bug with an almost equivalent response) I've seen that you've uploaded a couple new upstream releases of Asterisk in the time since my last response. Given these are severity: grave bugs, and I believe are most likely resolved, would it be possible for you to have a look here? Thanks, Faidon
Bug#897277: decrease e2fsprogs' Priority: required
Hi Ted, On Wed, Aug 18, 2021 at 01:41:36AM +0300, Faidon Liambotis wrote: > I haven't received a response for this. We are now at the beginning of > the aforementioned bookworm cycle, so I thought it may be a good > opportunity to bump this :) Do you have any thoughts? It's now been 2½ years since I last followed up on this bug, and 5½ since your last response where you said you'd "batch it with some other bug fixes in the next e2fsprogs minor release" and that would happen "by early June [2018] at the latest". Has this fallen through the cracks? Have you changed your mind? Would it be possible to get an update here? Thanks, Faidon
Bug#999664: Package severely outdated (unmaintained?)
Control: retitle -1 Package needs an active maintainer On Sun, Nov 14, 2021 at 02:46:41PM +0200, Faidon Liambotis wrote: > Debian is currently shipping ipv6calc 1.0.0. Upstream has released 12 > new upstream releases since, and is currently at 4.0.0. Upstream has been regularly making releases and is now at 4.1.0. I discussed this a bit in #debian-qa, and after a bit of encouragement, I decided to work a bit on this package, to bring it up to date. I uploaded 4.1.0-0.1 to the archive moments ago. This is definitely an unusual NMU for me, as I refactored the package almost entirely. I hope that's OK. I basically ran across into a number of issues and it would be much more difficult for me to debug them using so antiquated packaging standards and tooling (e.g. it wasn't even using dh), than it was to just bring it forward to 2023 and then work from there. I tried to be considerate and went with as much of a standard packaging as possible, and left a bunch of comments. I also filed a bunch of upstream issues¹ to raise everything that is an upstream issue, and left breadcrumbs across debian/ to point to these bugs. I'll monitor the BTS for any issues in the short-term, but not the long-term: I am not stepping up to (co)maintain this. This is also why I did not follow the salvaging process. Therefore, I'm leaving this bug open for either Luca or anyone else that decides to step up. Hopefully the work I did today is going to make this a much easier endeavour :) Regards, Faidon 1: https://github.com/pbiering/ipv6calc/issues/created_by/paravoid
Bug#1042609: sphinxcontrib-mermaid: FTBFS with Sphinx 7.1, docutils 0.20: Could not import sphinx.util.SphinxParallelError (exception: No module named 'sphinx.util.SphinxParallelError')
Hi, This is now RC, which means sphinxcontrib-mermaid has been marked for autoremoval, including its reverse dependencies (one of which I maintain). On Sun, Jul 30, 2023 at 08:30:07PM +0200, Lucas Nussbaum wrote: > sphinxcontrib-mermaid fails to build with Sphinx 7.1 and docutils 0.20, both > of which > are currently available in experimental. > > Relevant part (hopefully): > [...] > > [2Kreading sources... [ 50%] index > > > > Mermaid error: > > Could not import sphinx.util.SphinxParallelError (exception: No module > > named 'sphinx.util.SphinxParallelError') Upstream commit 6f8de39¹, the only commit since 0.9.2, replaces sphinx.util.SphinxParallelError by sphinx.util.DownloadFiles. I've verified that backporting this commit makes the package build successfully in unstable, with Sphinx 7.2.6-2. However, the very same commit changes requirements.txt from "Sphinx>=3.2.1" to "Sphinx<7". I'm not sure why. I'm not using, nor am I familiar with this plugin, so I was hoping someone else that is could perhaps validate whether besides being able to be built, the package actually works. Hope this helps, Faidon 1: https://github.com/mgaitan/sphinxcontrib-mermaid/commit/6f8de39a84fddc398542e9d4dc74ba55101e7d5e
Bug#1055864: Please recommend lowdown in addition to (or instead of) pandoc
Package: dh-make Version: 2.202301 Severity: wishlist X-Debbugs-Cc: ius...@debian.org A few years ago, a bug was filed against one of my packages, #956041, to report that build-depending on pandoc is a bit of a nuisance for ports architectures and bootstrapping, as it has a long depends of B-Ds itself, including the Haskell toolchain. My package was merely using pandoc to generate a manpage from a Markdown document, quite similar to dh-make's debian/manpage.md.ex template. The bug reporter's suggestion to use Build-Depends-Indep was also not a viable one, as the manpage had to be shipped with the binary itself, and a separate -doc package did not make sense for this use case. To resolve this request, I packaged "lowdown", which is a Markdown translator, including to the man format. It is a very small binary, depending only on libbsd (which is widely available). I've been maintaining it since bullseye, for a couple of years now, and upstream has been fairly responsive adding features such as Pandoc's metadata header. There are other translators such as go-md2man etc., but none as lightweight and comprehensive as lowdown, IMHO. It seems that most are not familiar with Pandoc alternatives. For example, from a recent thread on debian-devel: https://lists.debian.org/msgid-search/zswgm0nc9ax7u...@teal.hq.k1024.org I think it'd be helpful if the dh-make templates recommended lowdown in addition to, or even instead of, Pandoc. That way we'll be giving a lightweight option to fellow developers interested in writing a manpage using a modern markup language. The corresponding command-line syntax is: lowdown -s -Tman -o output.1 input.md Thanks, Faidon
Bug#1055826: bullseye-pu: package crun/0.17+dfsg-1+deb11u2 (bullseye regression)
On Sun, Nov 12, 2023 at 03:06:34PM +, Adam D. Barratt wrote: > On Sun, 2023-11-12 at 09:56 +0200, Faidon Liambotis wrote: > > A change merged into Linux v6.6 broke crun. The change was backported > > in the stable branch with v6.1.55, the version in bookworm. We fixed > > crun last week crun 1.8.1-1+deb12u1 (unblock request: #1055241). > > > > Salvatore Bonaccorso pointed out that the change was backported into > > all the stable branches, including v5.10.197, the version now in > > bullseye. bullseye's crun, v0.17, is also affected, therefore > > bullseye crun + bullseye Linux (or bullseye crun+bullseye-backports > > Linux etc.) are now broken as well. > > I guess you'd like that pushed via bullseye-updates, once it's ready, > as with the bookworm update? Yes please :) Thanks! Faidon
Bug#1055773: esptool: CVE-2023-46894
On Sat, Nov 11, 2023 at 08:51:30AM +0100, Salvatore Bonaccorso wrote: > The following vulnerability was published for esptool. > > CVE-2023-46894[0]: > | An issue discovered in esptool 4.6.2 allows attackers to view > | sensitive information via weak cryptographic algorithm. > > If I undestand the upstream discussion[1] correctly this is not > something hich is going to be fixed until the oldest earliest chips > are not supported anymore. So this bug is merely for documentation > purpose and can be closed once this support vanishes (or feel free to > aswer the above, we might then simply mark it as unimportant in the > security-tracker. I'd go one step further, and express that IMHO this is not a security vulnerability and that it shouldn't have been assigned a CVE in the first place. As you mentioned, based on upstream's comment above, old revisions of one of the supported chipsets were using AES ECB for secure boot and flash encryption, but newer ones have switched to newer cryptographic algorithms. esptool has kept support for the older algorithms, in order to keep the ability to work with older revisions of the hardware. Obviously software shouldn't default or recommend broken cryptographic ciphers, when it can be avoided. But I don't think it constitutes a vulnerability to merely implement them, when they are used to interface with the world as it exists outside of your software, such as for compatibility with hardware, network protocols etc. This is the equivalent of saying that coreutils is vulnerable because it ships md5sum, an implementation of a broken digest, or that browsers need a CVE for supporting older TLS ciphers, etc. Or perhaps even that python-cryptography itself needs a CVE because it ships an implementation of AES-ECB (or 3DES or whatever) :) Let me know if you disagree! Keeping the bug open until I hear from you. Thanks, Faidon
Bug#1055826: bullseye-pu: package crun/0.17+dfsg-1+deb11u2 (bullseye regression)
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: c...@packages.debian.org, car...@debian.org
Control: affects -1 + src:crun
A change merged into Linux v6.6 broke crun. The change was backported in
the stable branch with v6.1.55, the version in bookworm. We fixed crun
last week crun 1.8.1-1+deb12u1 (unblock request: #1055241).
Salvatore Bonaccorso pointed out that the change was backported into all
the stable branches, including v5.10.197, the version now in bullseye.
bullseye's crun, v0.17, is also affected, therefore bullseye crun +
bullseye Linux (or bullseye crun+bullseye-backports Linux etc.) are now
broken as well.
This upload just backports the same two patches that we backported to
bookworm and that are needed to address this issue. The patches apply
with minimal changes. There are no other changes included in this
upload.
See the bookworm-pu unblock request, #1055241, and SUA 243-1, for more
context.
[ Tests ]
Lightly tested on a bullseye VM.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
Thanks,
Faidon
diff -Nru crun-0.17+dfsg/debian/changelog crun-0.17+dfsg/debian/changelog
--- crun-0.17+dfsg/debian/changelog 2023-02-11 23:44:44.0 +0200
+++ crun-0.17+dfsg/debian/changelog 2023-11-02 18:52:46.0 +0200
@@ -1,3 +1,12 @@
+crun (0.17+dfsg-1+deb11u2) bullseye; urgency=medium
+
+ * Backport two commits from upstream ("ignore ENOTSUP when chmod a
+symlink"), that restore containers with systemd as their init system, when
+running under Linux >= v6.6, >= v6.1.55 and >= 5.10.197, i.e. bullseye's
+and bookworm's current stable kernels. (Closes: #1053821)
+
+ -- Faidon Liambotis Thu, 02 Nov 2023 18:52:46 +0200
+
crun (0.17+dfsg-1+deb11u1) bullseye; urgency=medium
* Backport upstream commits b847d14 ("spec: do not set inheritable
diff -Nru crun-0.17+dfsg/debian/patches/series
crun-0.17+dfsg/debian/patches/series
--- crun-0.17+dfsg/debian/patches/series2023-02-11 23:44:44.0
+0200
+++ crun-0.17+dfsg/debian/patches/series2023-11-02 18:52:46.0
+0200
@@ -1,2 +1,4 @@
CVE-2022-27650-b847d14.patch
CVE-2022-27650-1aeeed2.patch
+utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
+utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
diff -Nru
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
---
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
1970-01-01 02:00:00.0 +0200
+++
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
2023-11-02 18:52:46.0 +0200
@@ -0,0 +1,36 @@
+From 60296f112fddc74f4926f8ca6f6e1ef7a61ef5b9 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano
+Date: Tue, 26 Sep 2023 11:51:19 +0200
+Subject: [PATCH] utils: fix ignore ENOTSUP when chmod a symlink
+
+when ENOTSUP is encountered we must continue copying the other files,
+not doing an early return.
+
+commit 57262a2710c83fa08767f0ce3ba7a80993515bb2 introduced the
+regression with the Podman CI.
+
+Signed-off-by: Giuseppe Scrivano
+
+Origin: upstream,
https://github.com/containers/crun/commit/14afa8a46e2e83608a3a219402bce8ea8d071192
+Bug: https://github.com/containers/crun/issues/1308
+Bug-Debian: https://bugs.debian.org/1053821
+---
+ src/libcrun/utils.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/libcrun/utils.c b/src/libcrun/utils.c
+index 5c7f315..5306c5b 100644
+--- a/src/libcrun/utils.c
b/src/libcrun/utils.c
+@@ -1858,7 +1858,7 @@ copy_recursive_fd_to_fd (int srcdirfd, int dfd, const
char *srcname, const char
+ {
+ /* If the operation fails with ENOTSUP we are dealing with a
symlink, so ignore it. */
+ if (errno == ENOTSUP)
+-return 0;
++continue;
+
+ if (UNLIKELY (ret < 0))
+ return crun_make_error (err, errno, "chmod `%s/%s`", destname,
de->d_name);
+--
+2.39.2
+
diff -Nru
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
---
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
1970-01-01 02:00:00.0 +0200
+++
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
2023-11-02 18:52:46.0 +0200
@@ -0,0 +1,48 @@
+From 3bc67556e2f077337e574e4c3aaf18488410b2f5 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano
+Date: Fri, 22 Sep 2023 11:34:19 +0200
+Subject: [PATCH] utils: ignore ENOTSUP when chmod a symlink
+
+commit 5d1f903f75a80daa4dfb3d84e114ec8ecbf29956 in the kerne
Bug#1055392: wasmedge: autopkgtest regression: 'cstdint' file not found
Control: affects 1052002 - wasmedge Control: affects 1052002 + src:wasmedge On Thu, Nov 09, 2023 at 09:52:04AM +0100, Paul Gevers wrote: > > Hi Paul, > > Thank you for your report. This is caused #1052002, which I had marked > > as affects: wasmedge previously. > > Sorry for not checking that, but because you marked it as affecting the > *binary* package wasmedge, it doesn't show up looking for bugs in the source > package wasmedge (that may be a bts bug). Because this is a FTBFS issue, I > recommend you to mark it affects src:wasmedge instead of wasmedge. Alright, fair enough. Hopefully fixed above? > > Also, I'm not sure I understand how clang migrated to testing when it > > introduced an autopkgtest regression in another package. Isn't > > autopkgtest integration in britney supposed to prevent this kind of > > thing from happening? > > britney prevents this kind of things currently only for *direct* reverse > (test) dependencies. In this case we have: > > test/Depends: clang (from src:llvm-defaults) -> (Depends) clang-16 > > As I'm pretty sure you meant not clang, but one of the versioned clang > packages, britney didn't see the breakage. There are multiple ways to > improve this: > * britney should look at all transitive dependencies (we lack the resources > and also not environmentally friendly) > * britney could be taught to translate (automatically or via configuration) > "-defaults" packages to their real packages. This would be good for multiple > ecosystems, patches welcome. > * Individual packages that are sensitive could use the > `hint-testsuite-triggers` trick from the autopkgtest spec [1] and add the > current real packages. That's a PITA to maintain though, and adding versions > that you don't really test is wrong. Hrm, that's useful context and in hindsight makes a lot of sense. Thanks so much for spending the time to explain this to me! In the meantime, I'll mark the embed-cxx test as flaky in the next WasmEdge upload until the clang-16 bug gets fixed. Best, Faidon
Bug#1055392: wasmedge: autopkgtest regression: 'cstdint' file not found
Hi Paul, On Sun, Nov 05, 2023 at 01:45:34PM +0100, Paul Gevers wrote: > Source: wasmedge > Version: 0.13.4+dfsg-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainer(s), > > Your package has an autopkgtest, great. However, it fails. Can you please > investigate the situation and fix it? I copied some of the output at the > bottom of this report. > > The release team has announced [1] that failing autopkgtest on amd64 and > arm64 are considered RC in testing. > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > [...] > > 140s # `clang++ --target=wasm32-wasi -o fibonacci.wasm > -mexec-model=reactor script/fibonacci.cpp' failed > 140s # In file included from script/fibonacci.cpp:1: > 140s # script/fibonacci.h:3:10: fatal error: 'cstdint' file not found Thank you for your report. This is caused #1052002, which I had marked as affects: wasmedge previously. Basically, the autopkgtest compiles a piece of code (with Clang) and tries to run it (with WasmEdge). The Clang++ regression means the code cannot be built. I don't know how you'd like ot handle this w.r.t. the BTS, and testing migrations. I'm inclined to just reassign/merge it to the bug above, but I'll wait for your opinion first. Also, I'm not sure I understand how clang migrated to testing when it introduced an autopkgtest regression in another package. Isn't autopkgtest integration in britney supposed to prevent this kind of thing from happening? Looking for your guidance, Faidon
Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries
Control: reopen -1
Control: found -1 1:16.0.6-17
This is still not fixed :( Mike's findings still stand:
On Sat, Sep 16, 2023 at 05:53:55AM +0900, Mike Hommey wrote:
> This is a regression from the upgrade to clang 16.
>
> with clang 14:
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include/wasm32-wasi/c++/v1
> /usr/lib/llvm-14/lib/clang/14.0.6/include
> /usr/local/include
> /usr/include/wasm32-wasi
> /usr/include
> End of search list.
>
> with clang 16:
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/llvm-16/lib/clang/16/include
> /usr/local/include
> /usr/include/wasm32-wasi
> /usr/include
> End of search list.
>
> Note how /usr/include/wasm32-wasi/c++/v1 is missing.
Test case:
$ apt install clang lld libclang-rt-dev-wasm32 libc++-dev-wasm32
$ cat > hello.cpp <
int main() {
std::cout << "hello world" << std::endl;
return 0;
}
EOF
$ /usr/bin/clang++ -v --target=wasm32-wasi hello.cpp
Only C++ include paths are affected, not C. This almost certainly has to
do with the patch we carry for wasm include paths, that I have
contributed to. Unfortunately I have no time to look into it right now
:( I may find some time in a couple of weeks, but hoping someone else
can take care of it in the meantime :/
Best,
Faidon
Bug#1055241: bookworm-pu: package crun/1.8.1-1+deb12u1 (bookworm regression)
Package: release.debian.org
Severity: important
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: c...@packages.debian.org
Control: affects -1 + src:crun
[ Reason ]
Linux v6.6 blocked the mode change of symlinks, with commit
5d1f903f75a80daa4dfb3d84e114ec8ecbf29956 ("attr: block mode changes of
symlinks").
This was in turn backported to v6.1.55, with
6a84939cc7dd6f970c2621ded82c4d9ea0068b1b, and is part of src:linux
6.1.55-1, which is the version currently in bookworm.
This breaks crun 1.8.1, as found in bookworm, when running containers
with systemd as the init system.
The issue has been addressed upstream with commit
57262a2710c83fa08767f0ce3ba7a80993515bb2 ("ignore ENOTSUP when chmod a
symlink"), as well as 14afa8a46e2e83608a3a219402bce8ea8d071192 ("utils:
fix ignore ENOTSUP when chmod a symlink"), both part of crun 1.9.1.
[ Impact ]
Users are unable to start containers running systemd as their init
system. For example this now fails:
podman run --rm -d docker.io/jrei/systemd-debian:12
[ Tests ]
The manual test as mentioned above, as well as non-systemd images that
continue to work, like:
podman run --rm -it debian:sid
(Sadly we don't have any automated tests. crun in unstable now has
autopkgtests, but even these have the isolation-machine restriction and
are thus inoperable in Debian's CI, so I've elected to not backport them
here.)
[ Risks ]
The code is pretty trivial, I think, and has been part of upstream since
v1.9.1, released in September 26. trixie has v1.11, and sid has v1.11.1.
No alternatives that I know of.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
One change, effectively: to ignore ENOTSUP when chmod'ing a symlink,
/run/shm in the most popular broken case.
[ Other info ]
This has been reported by multiple users, cf. #1053821.
Given this constitutes a regression introduced by another package's
stable update, I consider this is an urgent issue, and ask for RMs to
copy this to stable-updates.
Thanks,
Faidon
diff -Nru crun-1.8.1/debian/changelog crun-1.8.1/debian/changelog
--- crun-1.8.1/debian/changelog 2023-02-27 22:01:38.0 +0200
+++ crun-1.8.1/debian/changelog 2023-11-02 18:52:46.0 +0200
@@ -1,3 +1,13 @@
+crun (1.8.1-1+deb12u1) bookworm; urgency=medium
+
+ * Backport two commits from upstream ("ignore ENOTSUP when chmod a
+symlink"), that restore containers with systemd as their init system, when
+running under Linux >= v6.6 and >= v6.1.55, i.e. bookworm's current stable
+kernel. (Closes: #1053821)
+ * Move myself to Maintainer, and Dmitry to Uploaders.
+
+ -- Faidon Liambotis Thu, 02 Nov 2023 18:52:46 +0200
+
crun (1.8.1-1) unstable; urgency=medium
* New bugfix upstream release.
diff -Nru crun-1.8.1/debian/control crun-1.8.1/debian/control
--- crun-1.8.1/debian/control 2023-02-27 22:01:38.0 +0200
+++ crun-1.8.1/debian/control 2023-11-02 18:52:46.0 +0200
@@ -2,9 +2,9 @@
Section: admin
Priority: optional
Standards-Version: 4.6.2
-Maintainer: Dmitry Smirnov
+Maintainer: Faidon Liambotis
Uploaders:
- Faidon Liambotis ,
+ Dmitry Smirnov ,
Reinhard Tartler ,
Build-Depends:
automake,
diff -Nru crun-1.8.1/debian/patches/series crun-1.8.1/debian/patches/series
--- crun-1.8.1/debian/patches/series1970-01-01 02:00:00.0 +0200
+++ crun-1.8.1/debian/patches/series2023-11-02 18:52:46.0 +0200
@@ -0,0 +1,2 @@
+utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
+utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
diff -Nru
crun-1.8.1/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
crun-1.8.1/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
---
crun-1.8.1/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
1970-01-01 02:00:00.0 +0200
+++
crun-1.8.1/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
2023-11-02 18:52:46.0 +0200
@@ -0,0 +1,36 @@
+From 60296f112fddc74f4926f8ca6f6e1ef7a61ef5b9 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano
+Date: Tue, 26 Sep 2023 11:51:19 +0200
+Subject: [PATCH] utils: fix ignore ENOTSUP when chmod a symlink
+
+when ENOTSUP is encountered we must continue copying the other files,
+not doing an early return.
+
+commit 57262a2710c83fa08767f0ce3ba7a80993515bb2 introduced the
+regression with the Podman CI.
+
+Signed-off-by: Giuseppe Scrivano
+
+Origin: upstream,
https://github.com/containers/crun/commit/14afa8a46e2e83608a3a219402bce8ea8d071192
+Bug: https://github.com/containers/crun/issues/1308
+Bug-Debian: https://bugs.debian.org/1053821
+---
+ src/libcrun/utils.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/libcrun/utils.c b/src/libcrun/utils.c
+index e5a82be..74bcf6
Bug#1053821: bookworm patch?
Control: severity -1 important On Thu, Nov 02, 2023 at 10:43:46AM -0500, Jesse Hathaway wrote: > Since this bug affects the current version in bookworm, v1.8.1, would > there be a possibility of adding the upstream patch to bookworm's > version? I tested applying the patches atop v1.8.1 and they apply > cleanly, and fix the issue as well. > > git checkout -b bookworm 1.8.1 > git cherry-pick 57262a2710c83fa08767f0ce3ba7a80993515bb2 > git cherry-pick 14afa8a46e2e83608a3a219402bce8ea8d071192 Despite Austin's description noting this, I had read the bug a bit in haste and thought this was only affecting crun 1.8.1 + Linux >= 6.6 (as crun's commit message mentioned). In other words, a combination of (crun from bookworm) + (Linux from sid), which, while not great, wasn't that big of an issue. However, after discussing this further with Jesse, I realized that the kernel commit in question (5d1f903f75a80daa4dfb3d84e114ec8ecbf29956, "attr: block mode changes of symlinks") has been backported as a stable upate to 6.1.55 (6a84939cc7dd6f970c2621ded82c4d9ea0068b1b), in turn part of src:linux 6.1.55-1, currently in bookworm. This means that bookworm's crun, combined with bookworm's current kernel, is broken when running containers with systemd as the init system. A simple test case is: podman run --rm -d docker.io/jrei/systemd-debian:12 I'm going to prepare a stable update backporting these two commits, hopefully resolving this incompatibility. Thanks all! Faidon
Bug#1052976: Update debian/copyright with upstream's 2.0.0 AGPL->MIT change
Source: mold Version: 2.2.0+dfsg-1 Severity: normal With mold 2.0.0 upstream relicensed the project from the AGPL v3.0, to the MIT (or as we call it in Debian, Expat) license. Given the restrictions of the AGPL, this is a major change which could open up mold to more users. debian/copyright (as of 2.2.0+dfsg-1) has not been updated to reflect this change, and is thus potentially misleading users. This should be easy to fix :) While looking into it, I noticed that a bunch of the code shipped in thirdparty/ is not documented in d/copyright -- namely, blake3, rust-demangle, xxhash, zlib, zstd. Given you're repacking the sources anyway, perhaps the appropriate move here is to just strip the ones shipped in Debian already (xxhash, zlib and zstd, I believe) from the source, and document the rest? Thanks, Faidon
Bug#1052387: geoipupdate: Please add dependency on ca-certificates
Control: tags -1 pending Hi Arnaud, On Thu, Sep 21, 2023 at 04:19:25PM +0700, Arnaud Rebillout wrote: > geoipupdates talks to MaxMind servers over HTTPS, so it needs the > package ca-certificates to be functional. Otherwise: Thanks so much for taking the time to report this! That's a good point. I pushed a commit in git that adds such a dependency. I'll work on a couple more issues, and wait for a few days to see if anything more accumulates, then upload a new version. Let me know if you find any more issues. I don't use this package much these days, so I could always hear more from users! Best, Faidon
Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68
Control: reassign -1 rustc 1.68.2+dfsg1-1 Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression) On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote: > The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with > both testing and unstable's versions of wasmedge, and with both testing and > unstable's versions of wasi-lib. Thanks for the report. Actually, I think the WasmEdge autopkgtests are catching a rustc 1.68 regression, whereas rustc compiles wasm32 binaries that do not work with neither WasmEdge, nor Wasmtime (the latter is not in Debian). Very simple test case: $ podman run --rm -it debian:sid # or bookworm to test with rustc 1.67 root@ad697f1c195f:~# apt install rustc libstd-rust-dev-wasm32 [...] root@ad697f1c195f:~# rustc -V rustc 1.68.2 root@ad697f1c195f:~# cat > hello.rs
Bug#1043415: netdata: Integrated web server displays "File does not exist, or is not accessible: "
Control: severity -1 grave On Thu, Aug 10, 2023 at 04:43:18PM +0200, Marc Riedel wrote: > When opening http://localhost:1, only "File does not exist, or is not > accessible: " is displayed. Maybe related to commit "Refreshing allow- > symlinks.patch." I just tried installing netdata to experiment with it, and I couldn't get the most basic out-of-the-box configuration to work due to this bug. Hence setting the severity to grave. I rebuilt with the allow-symlinks patch disabled and everything seemed to work, so I guess the fix may be easy enough :) (The package already has a couple more severity: serious bugs and is marked for autoremoval from testing, so it won't make a huge difference...) Faidon
Bug#1039958: autopkgtest-build-podman: Image creation fails with "sd-bus call: Permission denied"
On Fri, Jun 30, 2023 at 12:52:31PM +0200, Gioele Barabucci wrote: > autopkgtest-build-podman's failure is due to the issue reported in [1], i.e. > the Debian setup of podman requires `dbus-user-session`, but none of the > podman-related packages Depends on it. podman may not Depend on dbus-user-session, but it Recommends it. I believe that is because podman may be used in a number of different configurations some of which may require dbus-user-session, while others may not. Per Policy § 7.2, "The Recommends field should list packages that would be found together with this one in all but unusual installations". Basically, if you explicitly decide to not install a Recommends, it is expected that certain configurations or functionalities of the package break. Therefore I don't see how this is a bug, rather than a misconfiguration. Am I missing something? Thanks, Faidon
Bug#1043168: please include missing stub_flasher_32.json file
Control: block -1 by 868895 On Sun, Aug 06, 2023 at 10:12:30PM +0200, Piotr Ożarowski wrote: > I had to add stub_flasher_32.json file manually from upstream repo in > order to make my esphome (not yet in Debian, working on it) work with > ESP32 WROOM 32 board. > > Please include this file in the package. TIA Not sure if that's entirely clear to you (apologies if it is): that file isn't "just" a JSON data file that has been accidentally omitted from the package. It's in fact a (JSON-wrapped) binary, compiled from C sources bundled with the esptool source (and built with gcc, and a libc and everything). So it's not a matter of including the file, but rather rebuilding it. A lot of work has happened in Debian and with upstream over the years to build these binaries from unmodified sources, which culminated with Debian shipping the stubs for the ESP8266, as well as for the ESP32 RISC-V variants (ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2). See the 4.5.1+dfsg-0.1 and 4.6.2+dfsg-0.1 changelog entries, Debian bug #948096, as well as upstream issues #458, #499 and PRs #500, #501, #856, #858. The reason that the same has not happened yet for the ESP32, ESP32-S2 and ESP32-S3 stubs is that we lack the toolchain for them in Debian (gcc, binutils & picolibc). picolibc seems to have gained ESP32 support upstream in 1.7.9, and Keith Packard is both upstream and the Debian maintainer for it, so I suppose it won't be too hard to persuade him. gcc and binutils are more complicated. #868895 provides some context, and Jonathan McDowell, who maintains gcc-xtensa-lx106 and binutils-xtensa-lx106, is aware of the need. I think there is more of a backstory there, but he has the details. Note that the ESP-IDF is thankfully *not* needed anymore (see upstream #458). As an alternative, we could probably ship these three stubs as built by upstream separately in non-free, but I wasn't motivated enough, and I was hoping we'd get the toolchain in Debian at some point. (I'm not even the maintainer for esptool. If you're interested, I'm sure Milan will appreciate the help!). Finally, note that the stub isn't always necessary. --no-stub should work for some, but not all, operations, sometimes at slower speeds. Hope this helps! Faidon
Bug#1050439: Requires Sphinx >= v6.0 while unstable has v5.3
Source: furo
Version: 2023.08.19+dfsg-1
Severity: grave
furo 2023.08.19+dfsg-1 requires Sphinx v6.0:
$ grep -r 'require_sphinx(' /usr/lib/python3/dist-packages/furo
/usr/lib/python3/dist-packages/furo/__init__.py:app.require_sphinx("6.0")
However:
$ rmadison -s unstable python3-sphinx
python3-sphinx | 5.3.0-7 | unstable | all
This makes furo unusable:
$ python3 -m sphinx -N -bhtml docs/ build/html
Running Sphinx v5.3.0
making output directory... done
Sphinx version error:
The furo extension used by this project needs at least Sphinx v6.0; it
therefore cannot be built with this version.
...and breaks unrelated packages build-depending on it. I encountered
this while trying to upload a new version of tox. I'd expect the same
for the 29 packages Build-Depending on furo.
I don't know what to do at this point -- it's perhaps worth checking
with the Sphinx maintainer to see if they intend to upload a newer
version of Sphinx in the coming (very few) days, as 7.1 is already
staged in experimental.
Otherwise, backing out the commits that require the version bump, or the
version altogether, ASAP seems necessary given the impact crater.
In any case, I'd strongly suggest adding some kind of test (either at
build-time, or autopkgtests, ideally both) to avoid this kind of thing
from accidentally happening again. We're humans and bound to miss
something like that over time, so adding safeguards seems prudent :)
Regards,
Faidon
Bug#1047718: liblld-X-dev should probably depend on zlib1g-dev/libzstd-dev
Control: reopen -1 Control: severity -1 serious On Fri, Aug 18, 2023 at 07:21:05AM +, Debian Bug Tracking System wrote: >* Also build-depend on libzstd-dev (Closes: #1047718) Thanks for this, but the bug report was not about a Build-Depends, but rather for a (runtime) Depends from a -dev package to another -dev package, namely liblld-16-dev -> libzstd-dev, as well as liblld-16-dev -> zlib1g-dev. Therefore the bug is still present, as far as I can tell. I saw #1050071, where Sylvestre started planning the llvm-defaults 16 transition. With this bug open, the switch will make WasmEdge FTBFS, therefore I'm upping the severity to "serious". (I can of course add these two transitive B-Ds to the WasmEdge B-D to workaround this, but I don't think that's the right place for them. Let me know if you disagree). Thanks, Faidon
Bug#1049968: Warnings and tables not rendered with groff 1.23
Package: go-md2man Version: 2.0.2+ds1-1 Severity: important X-Debbugs-Cc: g.branden.robin...@gmail.com, cjwat...@debian.org Control: forwarded -1 https://github.com/cpuguy83/go-md2man/issues/99 go-md2man generates output that is invalid and with groff 1.23: 1) does not render tables, producing these warnings: "warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined)" 2) produces "warning: cannot select font 'C'" warnings I bumped into this with the package crun, that I maintain. Reproducing is as easy as trying to generate and display crun.1 from crun.1.md in that source package. Someone else reported this upstream as issue #99 2 days ago, and I just responded there, but filing it against Debian as this is affecting all of the go-md2man reverse build dependencies, and there are many. Cc'ing G. Branden Robinson and Colin Watson who have been super helpful in mailing lists and related bug reports dealing with the fallout of the groff 1.23.0 upload. For the former issue, https://lists.debian.org/debian-devel/2023/08/msg00220.html seems to include the fix. For the latter issue, which is relatively harmless, I guess an easy workaround is to remove \fC from the generated output. #1040975 (originally against perl/pod2man) #1041809 (against rst2man), #1043256 (against zip) seem to provide some additional context and solutions. Regards, Faidon
Bug#1047718: liblld-X-dev should probably depend on zlib1g-dev/libzstd-dev
Package: liblld-16-dev Version: 1:16.0.6-10 Severity: normal WasmEdge 0.13.3+dfsg-1 currently FTBFS on Ubuntu, but not Debian. It build-depends on liblld-dev, which apparently defaults to 16 in Ubuntu, but 14 (still) in Debian. An example build log is: https://launchpadlibrarian.net/681416533/buildlog_ubuntu-mantic-amd64.wasmedge_0.13.3+dfsg-1_BUILDING.txt.gz The relevant snippet seems to be: -- Found assembler: /usr/bin/as -- Configuring done (3.1s) CMake Error at /usr/lib/llvm-16/lib/cmake/lld/LLDTargets.cmake:88 (set_target_properties): The link interface of target "lldELF" contains: zstd::libzstd_shared but the target was not found. Possible reasons include: * There is a typo in the target name. * A find_package call is missing for an IMPORTED target. * An ALIAS target is missing. Call Stack (most recent call first): /usr/lib/llvm-16/lib/cmake/lld/LLDConfig.cmake:19 (include) lib/aot/CMakeLists.txt:11 (find_package) I think that's because of this: $ grep -B 1 zstd /usr/lib/llvm-16/lib/cmake/lld/LLDTargets.cmake set_target_properties(lldELF PROPERTIES INTERFACE_LINK_LIBRARIES "lldCommon;ZLIB::ZLIB;zstd::libzstd_shared;LLVM" While on 14: $ grep -A 1 "lldELF PROPERTIES" /usr/lib/llvm-14/lib/cmake/lld/LLDTargets.cmake set_target_properties(lldELF PROPERTIES INTERFACE_LINK_LIBRARIES "lldCommon;ZLIB::ZLIB;LLVM" I guess liblld-X-dev X >= 16 should depend on libzstd-dev, and while at it, liblld-Y-dev Y >= 14 should depend on zlib1g-dev? Thanks! Faidon
Bug#1043530: Please ship uasyncio and mip
Source: micropython Version: 1.19.1+ds-1 Severity: normal uasyncio is extremely useful in MicroPython programs in my experience, as it allows for concurrency in environments where there may be otherwise limited (no threads etc.). It's been supported by MicroPython for a while, and I see in upstream's git master that it's has been recently renamed to "asyncio", as it's considered close enough to CPython. While the upstream Unix port enables (u)asyncio by default, the Debian MicroPython builds do not ship with it. I also checked with 1.20.0+ds-1, as found in salsa. I believe this is because this is enabled by ports/unix/variants/standard/manifest.py Manifets are disabled in the Debian builds by building with FROZEN_MANIFEST=. Removing FROZEN_MANIFEST= from d/rules resulted in the build system complaining about the omission of micropython-lib. Extracting the official 1.20 micropython-lib tarball to lib/micropython-lib, however, made the build work: MicroPython v1.20.0+ds-1 on 2023-08-07; linux [GCC 13.2.0] version Use Ctrl-D to exit, Ctrl-E for paste mode >>> import uasyncio >>> So the solution here is a bit more involved: it requires shipping micropython-lib, for example leveraging multiple tarball support and gbp-import-orig's component support. On that matter, the build above also enabled "mip", the new package manager and flagship feature of v1.20: >>> import mip >>> (There are some mbedTLS DEBUG messages being emitted when fetching from e.g. GitHub, that I haven't tracked down yet, but that's getting a little offtopic.) Given the deviation from the upstream default, and how core these features are, I'm marking this as "normal", rather than "wishlist". But up to you :) Thanks for your work in maintaining MicroPython! Best, Faidon
Bug#1043330: tox: please make the build reproducible
Control: tags -1 pending Hi Chris, On Wed, Aug 09, 2023 at 09:16:05AM +0100, Chris Lamb wrote: > This is because: > > a) The documentation embeded the current build date via the copyright > year and a "last updated" timestamp. The attached patch changes this > to use SOURCE_DATE_EPOCH if available. I fixed this upstream a while ago: https://github.com/tox-dev/tox/pull/2941 > b) The default value for the --hashset argument (a random integer) was > encoded into the documentation. As this value was nondeterminstic, a > fresh value is inserted into the documentation on each build. This in > turn makes the package unreproducible. The attached patch changes this > to use the Pythonic "default=None … if default is None" pattern (NB. > this is distinct from the "notset" value, which, incidentally, is > typod in the --help text.) I've been working for this for a while, and we actually resolved it with upstream just this week! See: https://github.com/tox-dev/tox/issues/2942 https://github.com/tox-dev/tox/pull/3076 The history/current status is: I uploaded 4.4.6-1 to experimental before the freeze, as it's a major release breaking reverse dependencies. I noticed the FTBR and tried to fix them upstream in the meantime. 4.4.6 is quite a bit outdated by now. Stefano Rivera is kindly helping with bringing tox 4 to sid/trixie (see #1035635 for the thread with the release team) and while doing so (understandably) opted into not updating to a new upstream version. I have a new upstream release staged locally, building reproducibly, but not interfering with the tox 4 transition (as led by Stefano). Once the transition is over, I'll upload 4.7.0 (or later) to unstable, which should resolve this reproducibility issues -- and hopefully not introduce new ones :) Thanks! Faidon
Bug#1025165: No opus transcoding available after asterisk install
Hi Jonas, On Thu, May 04, 2023 at 01:43:33PM +0300, Faidon Liambotis wrote: > Control: found -1 1:20.2.1~dfsg+~cs6.13.40431413-1 > Control: tags -1 patch > > On Wed, Nov 30, 2022 at 04:18:24PM +0100, IB Development Team wrote: > > Package: asterisk > > Version: 1:16.28.0~dfsg-0+deb10u1 > > > > In clean Debian 10 after > > > > apt-get install asterisk > > > > internal opus codec seems to be available in 'core show codecs' but not in > > 'core show translation' and transcoding with opus does not work; same in > > Debian 11 and asterisk 1:16.28.0~dfsg-0+deb11u1. > > I believe the reason is that codec_opus_open_source.so is not shipped, > due to it not being built. > > Adding "ADDONS_ENABLE += codec_opus_open_source" to debian/rules (e.g. > near the other ADDONS_ENABLE lines) addresses this issue. I've verified > that "core show translation" shows opus in the matrix after that. I'm > not sure why menuselect doesn't enable it by default. > > Separately, it looks like there is a patch (2015_opus.patch) to add > libopusenc detection, used conditionally -if found- by the module > format_ogg_opus_open_source. However, libopusenc-dev is not in > Build-Depends. I've verified that the (already patched) build system > picks it up if I add it, and shlibs etc. are added. I saw you've made a couple of uploads since my response, so it looks like the package is maintained (which is great news - thanks for that!). It may not have been clear from the verbosity of my response, but the fix for this bug is one line in debian/rules, and optionally another one line (an addition to Build-Depends) for the related format_ogg issue. would it be possible for you to have a quick look at this and thus resolve this bug? Thanks! Faidon
Bug#1032092: asterisk: CVE-2022-23537 CVE-2022-23547 CVE-2022-39269
Dear maintainer, security team, (See #1036697 for a similar bug with an almost equivalent response) The changelog for the asterisk 1:20.4.0~dfsg+~cs6.13.40431414-1 upload dated 2023-08-04, currently in unstable, mentions: >+ fixate component pjproject at upstream release 2.13.1 The sources seem to indeed indicate that the version shipped for pjproject (aka PJSIP) is 2.13.1, which seems to have resolved the vulnerabilities listed below. Specifically: On Mon, Feb 27, 2023 at 08:48:36PM +0100, Moritz Mühlenhoff wrote: > CVE-2022-23537[0]: > | PJSIP is a free and open source multimedia communication library > | written in C language implementing standard based protocols such as > | SIP, SDP, RTP, STUN, TURN, and ICE. Buffer overread is possible when > | parsing a specially crafted STUN message with unknown attribute. The > | vulnerability affects applications that uses STUN including PJNATH and > | PJSUA-LIB. The patch is available as a commit in the master branch > | (2.13.1). > > https://github.com/pjsip/pjproject/security/advisories/GHSA-9pfh-r8x4-w26w > https://github.com/pjsip/pjproject/commit/d8440f4d711a654b511f50f79c0445b26f9dd1e1 Upstream says "Patched versions: 2.13.1" in the GitHub GHSA URL above. > CVE-2022-23547[1]: > | PJSIP is a free and open source multimedia communication library > | written in C language implementing standard based protocols such as > | SIP, SDP, RTP, STUN, TURN, and ICE. This issue is similar to > | GHSA-9pfh-r8x4-w26w. Possible buffer overread when parsing a certain > | STUN message. The vulnerability affects applications that uses STUN > | including PJNATH and PJSUA-LIB. The patch is available as commit in > | the master branch. > > https://github.com/pjsip/pjproject/security/advisories/GHSA-cxwq-5g9x-x7fr > https://github.com/pjsip/pjproject/commit/bc4812d31a67d5e2f973fbfaf950d6118226cf36 Upstream says "Patched versions: 2.13.1" in the GitHub GHSA URL above. > CVE-2022-39269[2]: > | PJSIP is a free and open source multimedia communication library > | written in C. When processing certain packets, PJSIP may incorrectly > | switch from using SRTP media transport to using basic RTP upon SRTP > | restart, causing the media to be sent insecurely. The vulnerability > | impacts all PJSIP users that use SRTP. The patch is available as > | commit d2acb9a in the master branch of the project and will be > | included in version 2.13. Users are advised to manually patch or to > | upgrade. There are no known workarounds for this vulnerability. > > https://github.com/pjsip/pjproject/security/advisories/GHSA-wx5m-cj97-4wwg > https://github.com/pjsip/pjproject/commit/d2acb9af4e27b5ba75d658690406cec9c274c5cc Upstream says "Patched versions: 2.13" in the GitHub GHSA URL above. > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > [...] > > Please adjust the affected versions in the BTS as needed. As I'm neither the maintainer nor in the security team, I'm leaving these actions to you. Hopefully simple enough, once you confirm my findings :) Regards, Faidon
Bug#1036697: asterisk: CVE-2023-27585
Dear maintainer, security team, (See #1032092 for a similar bug with an almost equivalent response) The changelog for the asterisk 1:20.4.0~dfsg+~cs6.13.40431414-1 upload dated 2023-08-04, currently in unstable, mentions: >+ fixate component pjproject at upstream release 2.13.1 The sources seem to indeed indicate that the version shipped for pjproject (aka PJSIP) is 2.13.1, which seems to have resolved the vulnerabilities listed below. Specifically: On Wed, May 24, 2023 at 02:51:41PM +0200, Moritz Mühlenhoff wrote: > CVE-2023-27585[0]: > | PJSIP is a free and open source multimedia communication library > | written in C. A buffer overflow vulnerability in versions 2.13 and > | prior affects applications that use PJSIP DNS resolver. It doesn't > | affect PJSIP users who do not utilise PJSIP DNS resolver. This > | vulnerability is related to CVE-2022-24793. The difference is that > | this issue is in parsing the query record `parse_query()`, while the > | issue in CVE-2022-24793 is in `parse_rr()`. A patch is available as > | commit `d1c5e4d` in the `master` branch. A workaround is to disable > | DNS resolution in PJSIP config (by setting `nameserver_count` to zero) > | or use an external resolver implementation instead. > > https://github.com/pjsip/pjproject/security/advisories/GHSA-q9cp-8wcq-7pfr > https://github.com/pjsip/pjproject/security/advisories/GHSA-p6g5-v97c-w5q4 > https://github.com/pjsip/pjproject/commit/d1c5e4da5bae7f220bc30719888bb389c905c0c5 Upstream says "Patched versions: 2.13.1" in the first GitHub GHSA URL above (for CVE-2023-27585), and "Patched versions: 2.12.1 or later" for the second one (for CVE-2022-24793). > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > [...] > > Please adjust the affected versions in the BTS as needed. As I'm neither the maintainer nor in the security team, I'm leaving these actions to you. Hopefully simple enough, once you confirm my findings :) Regards, Faidon
Bug#1042193: wasmedge: FTBFS: ld: ../../lib/api/libwasmedge.so.0.0.3: undefined reference to `WasmEdge::Fault::emitFault(WasmEdge::ErrCode)'
Control: forwarded -1 https://github.com/WasmEdge/WasmEdge/issues/2695 Control: tags -1 + patch On Wed, Jul 26, 2023 at 09:50:12PM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -Wl,--export-dynamic -rdynamic > > CMakeFiles/wasmedge.dir/wasmedge.cpp.o -o wasmedge > > -Wl,-rpath,"\$ORIGIN/../../lib/api::" > > ../../lib/api/libwasmedge.so.0.0.3 > > /usr/lib/x86_64-linux-gnu/libspdlog.so.1.10.0 > > /usr/lib/x86_64-linux-gnu/libfmt.so.9.1.0 > > /usr/bin/ld: ../../lib/api/libwasmedge.so.0.0.3: undefined reference to > > `WasmEdge::Fault::emitFault(WasmEdge::ErrCode)' > > collect2: error: ld returned 1 exit status Thanks Lucas, that's super helpful! I tracked down the trigger to the gcc-12 -> gcc-13 migration. I think I've tracked down the root cause as well, and reported a one-line fix to the upstream issue above. I'll give upstream a couple of days to validate my assumptions before I make an upload. Regards, Faidon
Bug#1042337: gdnsd: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Control: forwarded -1 https://github.com/gdnsd/gdnsd/issues/236 On Wed, Jul 26, 2023 at 10:20:11PM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. Thanks Lucas. I had noticed that already and have been trying to figure out a fix for it, as seen by the upstream issue above. FTR, this is caused by a recent upload of Net::DNS, which I had al Net::DNS minor releases breaking gdnsd's test suite has been a bit of a pattern. https://github.com/gdnsd/gdnsd/pull/229 was a similar issue that happened during the bookworm lifecycle. I'll give it another go; if I'm unable to track it down, I may just turn off "make check" entirely :( Thanks, Faidon
Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs
On Wed, Jul 19, 2023 at 06:41:54PM +0200, Jonas Smedegaard wrote: > > > This is a pseudo-ITP: The source package is already maintained for the > > > subset covering core Cranelift crates, since they are part of same > > > monorepo. The intent tracked here is extending that source package to > > > provide binary packages librust-wasmtime* which involves additional > > > dependencies unneeded for Cranelift. > > > > I'm not sure what you mean by that -- what is already maintained? > > Whoops, I had it in mind but evidently forgot to mention it: I mean the > packaging effort tracked as ITP bug#1041434 (and now in NEW queue). Ah! It makes sense now, thanks :) > > Also, are you planning to package wasmtime, as in the CLI, itself? I > > believe this exists on the same upstream/source tree as the language > > bindings that you're proposing here? > > I mean both the Rust crates and the command-line tool. > > You are right, both are part of same monorepo. Awesome! > > > Please shout if there is need for wasmtime, and especially if there is > > > interest in helping get the needed dependencies packaged. > > > > I don't have the bandwidth to help packaging wasmtime. However, I do > > maintain another popular WebAssembly runtime, WasmEdge, and last year I > > contributed a few changes to the Debian LLVM packages > > (src:llvm-project-14 and friends) with regards to WebAssembly support, > > and so you could say I'm interested with helping in bringing more parts > > of the WebAssembly ecosystem in Debian :) I'm also interested in > > opportunities to help each other, and in the relevant packages working > > well with each other and/or providing a unified experience. Let me know > > if you can think of any such ways. > > I don't have a special interest in WebAssembly (yet) - my packaging > efforts here is targeted packaging of swt (bug#991761). That work also > involves packaging (again only a subset of crates initially for) wasmer. Wasmer too? That's even better :) Good luck! Faidon
Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs
On Wed, Jul 19, 2023 at 10:56:32AM +0200, Jonas Smedegaard wrote: > rust-wasmtime is the Rust embedding API for the Wasmtime project: > a cross-platform engine for running WebAssembly programs. > > This is a pseudo-ITP: The source package is already maintained for the > subset covering core Cranelift crates, since they are part of same > monorepo. The intent tracked here is extending that source package to > provide binary packages librust-wasmtime* which involves additional > dependencies unneeded for Cranelift. I'm not sure what you mean by that -- what is already maintained? Also, are you planning to package wasmtime, as in the CLI, itself? I believe this exists on the same upstream/source tree as the language bindings that you're proposing here? > Please shout if there is need for wasmtime, and especially if there is > interest in helping get the needed dependencies packaged. I don't have the bandwidth to help packaging wasmtime. However, I do maintain another popular WebAssembly runtime, WasmEdge, and last year I contributed a few changes to the Debian LLVM packages (src:llvm-project-14 and friends) with regards to WebAssembly support, and so you could say I'm interested with helping in bringing more parts of the WebAssembly ecosystem in Debian :) I'm also interested in opportunities to help each other, and in the relevant packages working well with each other and/or providing a unified experience. Let me know if you can think of any such ways. On that note, you may be interested in (and/or subscribing to) #1033322. Regards, Faidon
Bug#1034590: precedence of /etc/containers/storage.conf should higher than /usr/share/containers/storage.conf
Control: tags -1 moreinfo On Wed, Apr 19, 2023 at 09:24:21AM +0800, 鐘翊修 wrote: > following man 5 containers-storage.conf, > when a system have both /etc/containers/storage.conf and > /usr/share/containers/storage.conf > > the values in /etc/containers/storage.conf overwrite the value in > /usr/share/containers/storage.conf > > But in 4.4.0+ds1-1. with both files, podman takes the config from > /usr/share/containers/stroage.conf > > To reproduce this > > Create podman graph database on podman 4.3.1 with btrfs (config in > /etc/containers/storage.conf) > > upgrade from 4.3.1 to 4.4.0 > > run the following command > > sudo podman info > > expected error message > > User-selected graph driver \"overlay\" overwritten by graph driver \"btrfs\" > from database I'm not sure I follow. Could you elaborate on the exact steps you took? Do you mean that you expected to get this error message but didn't, or that you got that error message even though you shouldn't have? Are you aware that you need to run "podman system reset" before changing storage.conf? See podman-system-reset(1). Thanks, Faidon
Bug#1037091: podman run fails because of missing ~/.config/docker/config.json
On Sun, Jun 04, 2023 at 02:52:56PM +0200, Felix Stupp wrote: > the current version of podman does not allow me to run any container due > to the following error message: > Error: stat /home/$USER/.config/docker/config.json: no such file or directory > > I can trigger this issue with a simple: podman run debian > However, what container I try to run seems not to matter. > > [...] > > However, it still seems at least weird to me, that podman requires (not > just reads optionally) a config file which is in Docker's config dir. That is indeed weird. Is there any config (either in your .config, or in /etc) that has been modified in your system? For example, do you perhaps have a registry configured, and one that requires a login? An unqualified "podman run debian" could try to resolve this to your local registry, which in turn may require a login, which implicitly calls "podman login", which in turn attempts to read from a variety of config paths, including $HOME/.docker/config.json. Regards, Faidon
Bug#1041050: Downgrade or remove fuse-overlayfs Recommends
Package: podman Version: 4.3.1+ds1-8+b1 Severity: minor Linux 5.13+ (so Debian stable+) added user namespace support to overlayfs. Podman can leverage that and use overlayfs in rootless containers, which results into performance benefits compared to fuse-overlayfs. See this older RedHat article for more: https://www.redhat.com/sysadmin/podman-rootless-overlay As such, I don't think it makes sense for podman to Recommends: fuse-overlayfs anymore. At best it should be a Suggests, if not dropped entirely. What do you think? Regards, Faidon
Bug#1025165: No opus transcoding available after asterisk install
Control: found -1 1:20.2.1~dfsg+~cs6.13.40431413-1 Control: tags -1 patch On Wed, Nov 30, 2022 at 04:18:24PM +0100, IB Development Team wrote: > Package: asterisk > Version: 1:16.28.0~dfsg-0+deb10u1 > > In clean Debian 10 after > > apt-get install asterisk > > internal opus codec seems to be available in 'core show codecs' but not in > 'core show translation' and transcoding with opus does not work; same in > Debian 11 and asterisk 1:16.28.0~dfsg-0+deb11u1. I believe the reason is that codec_opus_open_source.so is not shipped, due to it not being built. Adding "ADDONS_ENABLE += codec_opus_open_source" to debian/rules (e.g. near the other ADDONS_ENABLE lines) addresses this issue. I've verified that "core show translation" shows opus in the matrix after that. I'm not sure why menuselect doesn't enable it by default. Separately, it looks like there is a patch (2015_opus.patch) to add libopusenc detection, used conditionally -if found- by the module format_ogg_opus_open_source. However, libopusenc-dev is not in Build-Depends. I've verified that the (already patched) build system picks it up if I add it, and shlibs etc. are added. Thanks, Faidon
Bug#1001793: mate-terminal: Wrong context menu font when using libvte-2.91-0[-common] 0.66.1-1 or 0.66.2-1
On Thu, Apr 13, 2023 at 04:43:54PM +, Mike Gabriel wrote: > > This seems to be upstream bug #407 fixed with upstream git commit > > 52fa45d4ca35e6be11ddee818eac84b768f15e22: > > https://github.com/mate-desktop/mate-terminal/commit/52fa45d4ca35e6be11ddee818eac84b768f15e22 > > > > This was reported against Ubuntu with LP #1955505, and fixed in > > 1.26.0-1ubuntu2, with a backport of the aforementioned patch: > > https://git.launchpad.net/ubuntu/+source/mate-terminal/commit/?id=a0d6e4951b3443ba849be12397cc02136e62b8d6 > > > > The fix seems to be, thankfully, a trivial one-liner :) > > Tagging with patch tag. > > Thanks for this! Will do an upload soonish. Any news regarding this? The full freeze is approaching very quickly :) Thanks! Faidon
Bug#1001793: mate-terminal: Wrong context menu font when using libvte-2.91-0[-common] 0.66.1-1 or 0.66.2-1
Control: tags -1 upstream Control: forwarded -1 https://github.com/mate-desktop/mate-terminal/issues/407 On Wed, Apr 12, 2023 at 10:37:19AM +0300, Faidon Liambotis wrote: > On Thu, Dec 16, 2021 at 12:29:48PM +0100, Jasmin68k wrote: > > Using Debian sid, running apt-get upgrade, which installed > > libvte-2.91-0 and libvte-2.91-common 0.66.1-1. After that, the > > context (right-click) menu font in mate-terminal became monospace, > > probably the same system wide monospace font, mate-terminal is using > > for terminal output, instead of the regular system wide application > > font. > > This seems like a pretty serious UX issue. It also seems this was > reported against Ubuntu, and fixed there with 1.26.0-1ubuntu2. To add to this: This seems to be upstream bug #407 fixed with upstream git commit 52fa45d4ca35e6be11ddee818eac84b768f15e22: https://github.com/mate-desktop/mate-terminal/commit/52fa45d4ca35e6be11ddee818eac84b768f15e22 This was reported against Ubuntu with LP #1955505, and fixed in 1.26.0-1ubuntu2, with a backport of the aforementioned patch: https://git.launchpad.net/ubuntu/+source/mate-terminal/commit/?id=a0d6e4951b3443ba849be12397cc02136e62b8d6 The fix seems to be, thankfully, a trivial one-liner :) Faidon
Bug#1001793: mate-terminal: Wrong context menu font when using libvte-2.91-0[-common] 0.66.1-1 or 0.66.2-1
On Thu, Dec 16, 2021 at 12:29:48PM +0100, Jasmin68k wrote: > Using Debian sid, running apt-get upgrade, which installed > libvte-2.91-0 and libvte-2.91-common 0.66.1-1. After that, the > context (right-click) menu font in mate-terminal became monospace, > probably the same system wide monospace font, mate-terminal is using > for terminal output, instead of the regular system wide application > font. This seems like a pretty serious UX issue. It also seems this was reported against Ubuntu, and fixed there with 1.26.0-1ubuntu2. IMHO the fix for this should make it to bookworm. Happy to do an NMU with the Ubuntu patch if that's the maintainers lack the time or so desire. Thanks, Faidon
Bug#782007: criu: Split up binary packages
On Sun, Apr 09, 2023 at 09:08:09AM +0200, Salvatore Bonaccorso wrote: > > I submitted an MR implementing this: > > https://salsa.debian.org/debian/criu/-/merge_requests/3 > > > > Looking forward to your review! > > Thanks for doing the work, I will have a look but any such change will > happen only after the bookworm release. Of course! If you have some spare cycles to review this during the freeze, it'd be neat if we could stage it in experimental (and cross through NEW now that things are relatively quiet :). That way I could also move up the stack and test crun against libcriu in experimental as well. Thanks for the quick response regardless! Best, Faidon
Bug#1034118: unblock: lowdown/1.0.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lowdown, a key package, through:
bind9 -> libmaxminddb -> lowdown
[ Reason ]
lowdown is a Markdown to HTML/roff/LaTeX/etc. translator. A regression
was introduced at some point where the -Tman (manpage) output used a
roff macro that is not present in the "man" package but in the "ms"
package. I reported this upstream[1], and it was subsequently fixed[2].
This is a bookworm-targeted backport of that specific upstream commit,
that applies cleanly as-is.
1: https://github.com/kristapsdz/lowdown/issues/111
2:
https://github.com/kristapsdz/lowdown/commit/02491bf4ae2a39df2dfed10382512449a5b3262f
[ Impact ]
The output difference is minor from a visual standpoint, e.g.
OPTIONS
-batch_size __
- Maximum number of entries to request per call to
get-entries.
- You should not generally need to change this. Defaults to 1000.
+Maximum number of entries to request per call to get-entries.
You
+should not generally need to change this. Defaults to 1000.
However, the roff output is technically invalid.
In Debian, this manifests in reverse build-dependencies that are using
lowdown to generate their manpage to emit lintian warnings, e.g.:
W: certspotter: groff-message 29: warning: macro 'PI' not defined
[usr/share/man/man8/certspotter-script.8.gz:1]
W: certspotter: groff-message 56: warning: macro 'PI' not defined
[usr/share/man/man8/certspotter.8.gz:1]
There are three reverse build-dependencies in testing:
1) src:libmaxminddb
2) src:certspotter
3) src:nix
Only the first two are using -Tman. I am the maintainer for both.
src:libmaxminddb was built with an pre-regression version of lowdown and
is not affected. It can be binNMUed, although not strictly necessary.
src:certspotter is affected and should probably be binNMUed, although as
explained, the visual impact is relatively minor.
[ Tests ]
Upstream has a comprehensive test suite that runs as part of the build.
The package also has autopkgtests that pass.
[ Risks ]
The code for the fix is trivial. The package is technically a key
package, but only as a reverse build-dep of another package, and is only
a B-D for three packages in total.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
debdiff attached; you can also find the git diff at:
https://salsa.debian.org/debian/lowdown/-/commit/0e2160bb23e194edc5c15c7772042857fd18f2f7
unblock lowdown/1.0.0-2
Also probably:
nmu certspotter_0.16.0-1 . ANY . unstable . -m "Rebuild with lowdown 1.0.0-2"
(but no idea how to ensure the ordering of those two, not fluent in
wanna-build)
diff -Nru lowdown-1.0.0/debian/changelog lowdown-1.0.0/debian/changelog
--- lowdown-1.0.0/debian/changelog 2023-01-07 06:52:41.0 +0200
+++ lowdown-1.0.0/debian/changelog 2023-04-09 03:39:15.0 +0300
@@ -1,3 +1,13 @@
+lowdown (1.0.0-2) unstable; urgency=medium
+
+ * Backport upstream patch to avoid the use of an -ms macro, PI, in the -Tman
+output. This addresses a man warning ("macro 'PI' not defined") which in
+turn is a lintian warning for packages using lowdown to generate their
+manpage(s).
+ * Bump Standards-Version to 4.6.2, no changes needed.
+
+ -- Faidon Liambotis Sun, 09 Apr 2023 03:39:15 +0300
+
lowdown (1.0.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru lowdown-1.0.0/debian/control lowdown-1.0.0/debian/control
--- lowdown-1.0.0/debian/control2023-01-07 04:49:43.0 +0200
+++ lowdown-1.0.0/debian/control2023-04-09 03:39:15.0 +0300
@@ -6,7 +6,7 @@
libbsd-dev,
libmd-dev,
pkgconf | pkg-config,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
Section: text
Homepage: https://kristaps.bsd.lv/lowdown/
Vcs-Browser: https://salsa.debian.org/debian/lowdown
diff -Nru lowdown-1.0.0/debian/patches/dont-use-PI-for-tman.patch
lowdown-1.0.0/debian/patches/dont-use-PI-for-tman.patch
--- lowdown-1.0.0/debian/patches/dont-use-PI-for-tman.patch 1970-01-01
02:00:00.0 +0200
+++ lowdown-1.0.0/debian/patches/dont-use-PI-for-tman.patch 2023-04-09
03:38:19.0 +0300
@@ -0,0 +1,83 @@
+From: Kristaps Dz
+Subject: [PATCH] Don't use \(PI for -tman: it doesn't exist.
+
+The \(PI register only exists for -ms macros. Use the default value
+of 5n for this (for definition lists) when emitting for -tman.
+
+References #111
+
+Origin: upstream,
https://github.com/kristapsdz/lowdown/commit/02491bf4ae2a39df2dfed10382512449a5b3262f
+Bug: https://github.com/kristapsdz/lowdown/issues/111
+Last-Update: 2023-04-09
+
+--- a/nroff.c
b/nroff.c
+@@ -745,7 +745,8 @@ rndr_definition_title(struct bnodeq *obq
+ }
+
+ static int
+-rndr_definit
Bug#782007: criu: Split up binary packages
Control: tags -1 patch On Mon, Apr 06, 2015 at 02:00:46PM +0200, Salvatore Bonaccorso wrote: > I think it would make sense in meanwhile to split up the criu binary > package (although still small) into multiple binary packages: E.g. > criu, criu-dbg, libcriuX, libcriu-dev, python-criu. I submitted an MR implementing this: https://salsa.debian.org/debian/criu/-/merge_requests/3 Looking forward to your review! Thanks, Faidon
Bug#1009776: podman: Packages uidmap and slirp4netns should be full dependencies
On Fri, Aug 19, 2022 at 02:16:19PM +0200, Andrej Shadura wrote: > > I have to respectfully disagree here. In Debian, "Recommends" > > relationships are installed by default, and your message indicates to me > > that you have configured your system to not install them. It furthermore > > seems to me that this bug is asking for a convenience that is making > > your non-standard setup easier, while making other setups where podman > > is used only in 'root' mode, impossible to install without idmap and > > friends. > > I'm going to leave this bug open to remind myself to think about this > > from time to time, but I still wanted to document my thinking process > > here more clearly. > > There’s another thing, which I mentioned but I should have made more clear. > The upstream states the rootless mode is the main mode of operation, hence I > think it should be available regardless of Recommends, don’t you think? > > Also, from what I gathered talking to Debian and Ubuntu users of podman who > are not DDs, many of them are frustrated by papercuts like this one, so in > general I think the package should be made to work as effortlessly as > possible. So even if the user hasn’t got Recommends installation enabled, > podman should probably be packaged not to make them stumble upon this. It's months later and this is a drive-by comment but: First of all, I'd say that rootless is the main differentiator from Docker, but far from being a "main mode". Podman works equally well in rootless and rootful configurations, with the latter being the mode that one would use as a 1:1 Docker replacement, or in production environment scenarios where more performant or advanced network configurations are required. Second, according to Policy § 7.2, "The Recommends field should list packages that would be found together with this one in all but unusual installations". If folks explicitly pass --no-install-recommends to apt (or the equivalent preferences.d), then they get to keep the pieces when things break; I wouldn't call that a papercut. The installation /is/ effortless out of the box, unless one decides that they want to do something against the maintainer's recommendations, in which case they should be able to, but with (a bit of) a price to pay. Hard-Depending on dependencies that are not actually required in common modes of operation, in this case e.g. servers using podman for production services, doesn't serve our users -- it just forces unnecessary cruft on their system, for little benefit to others. Note that I'm not on a quest against rootless: a couple of years back, on #987207, I argued to downgrade iptables from Depends to Recommends, for the same reasosn but to the benefit of rootless users: to avoid the cruft in rootless configurations :) So I'm definitely +1 to mark this as wontfix, FWIW. Best, Faidon
Bug#1031109: bullseye-pu: package crun/0.17+dfsg-1+deb11u1
On Sat, Apr 01, 2023 at 08:24:57PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > Please go ahead; sorry for the delay. Thanks for the review! Tagged and uploaded last night, and it's currently in proposed-updates. Faidon
Bug#1031716: python3-protobuf: Do reverse dependencies need stricter version constraints?
On Tue, Feb 21, 2023 at 02:23:34PM +0200, Adrian Bunk wrote: > Looking at #1028371, should generated dependencies on python3-protobuf be > python3-protobuf (>= 3.21), python3-protobuf (<< 3.22) > to ensure that the binary package is used with the same version > as the protobuf-compiler used during the build? I'm not the maintainer, but a drive-by contributor. I looked a bit into this, given its RC severity. With my still somewhat limited understanding, a strict version alignment between protobuf-compiler and python3-protobuf would probably resolve this particular symptom, but the issues here seem to run deeper. Specifically: * The protobuf project provides three different versions of Python bindings: pure Python, C++, and libupb-based[1]. These are selectable using the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION environment variable. * Debian's python3-protobuf, from src:protobuf, ships the pure Python version, as well as the C++ bindings. The default implementation in Debian is "cpp". * The upb implementation is not included in src:protobuf, but in the upb upstream source[2], i.e. what is src:upb in Debian, even though the snapshot we have in Debian does not contain sources to Python bindings. * Upstream has switched the default implementation to "upb", and deprecated the "cpp" implementation. There is, in fact, no way for one to fetch the "cpp" version from PyPI. This is documented extensively in their May 2022 release notes[3]. However, Debian still ships, and defaults to, cpp, a major departure from upstream. * Relatedly, when they made that switch, they also made changes to their versioning scheme, disconnecting the Python library's version from the source version. As a result, the Python API (both upb, as well as pure Python), is now versioned at "4.21", rather than "3.21". The Debian binary package python3-protobuf is versioned as "3.21.12-1", which is not a version that exists, or will ever exist, upstream. That binary package in fact, is shipping an egg named protobuf-4.21.12.egg-info. (This is all also well documented in their release notes[3]). * Finally, in the same release notes document[3], they also state: "Python upb requires generated code that has been generated from protoc 3.19.0 or newer.". Indeed, if one fetches protobuf 4.21 from PyPI, and runs: python3 -c 'import bernhard' or PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=upb python3 -c 'import bernhard' ...a traceback message is emitted, but a much more informative one: > TypeError: Descriptors cannot not be created directly. > > If this call came from a _pb2.py file, your generated code is out of > date and must be regenerated with protoc >= 3.19.0. > > If you cannot immediately regenerate your protos, some other possible workarounds are: > 1. Downgrade the protobuf package to 3.20.x or lower. > 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will > use pure-Python parsing and will be much slower). > > More information: https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates * The release notes specifically mention "upb" requiring protoc (protobuf-compiler) >= 3.19, but not "cpp". However, as established above, "cpp" is deprecated and not used by anyone (but Debian), and therefore they either meant "the non-Pure-Python implementation" there, or did not pay as much attention to forward- and backwards-compatibility, or informative error messages for their deprecated backend. It's likely, but not entirely clear, that the protoc dependency requirement is >= 3.19 here as well. * Finally note that the 3.21.12-1+b2 Python implementation still works with python3-bernhard, Built-Using: protobuf-compiler (= 3.12.4-1+b3): PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python python3 -c 'import bernhard' All in all: it's almost certainly necessary to make the dependency tighter, to something like >= 3.19, if not tight to = 3.21. I still feel uneasy about Debian shipping a version of python3-protobuf that includes, and defaults to, an implementation that is deprecated upstream (and on top of it, is misversioned). I'm not sure what to make of this so late in the release cycle, though. For trixie the path forward is probably something along the lines of updating src:upb to a newer upstream, building the upb-based extension as python3-protobuf-upb, and then changing src:protobuf to not build the cpp extension, make python3-protobuf Arch: all, and then Recommend (or Depend) on python3-protobuf-upb as the native/fast implementation. Faidon 1: https://github.com/protocolbuffers/protobuf/tree/main/python 2: https://github.com/protocolbuffers/upb/tree/main/python 3: https://protobuf.dev/news/2022-05-06/
Bug#1033322: Please create a new WebAssembly section
Package: ftp.debian.org Severity: wishlist I'm about to upload WasmEdge (ITP #1003128), a WebAssembly runtime. The "wasmedge" binary package is the runtime (think JRE in Java terms), so Section: devel is not very appropriate. I've set the source package and the wasmedge package to Section: web for the time being, but that doesn't feel like a complete match either. WebAssembly[1] is an entire ecosystem, and especially with efforts such as WASI[2] it now operates outside the confines of browsers and the web. I think it'd be valuable to have a Section: webassembly, so that runtimes and other software that are not strictly for development purposes can fit in. Thanks for the consideration, Faidon 1: https://en.wikipedia.org/wiki/WebAssembly 2: https://wasi.dev/
Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa
Hi Helge, On Mon, Feb 27, 2023 at 11:08:23PM +0200, Faidon Liambotis wrote: > What would you like to do with this bug? Would you like to file a bug > against libev and mark this bug as blocked by the libev one? Or > alternatively I can mark as wontfix and resolve? Friendly bump on this! I'd just like to agree on next steps while we have this in our recent memory :) Thanks, Faidon
Bug#1033103: superficial-tests: false positive when both Testsuite + d/t/control are used
On Fri, Mar 17, 2023 at 01:53:00PM +0200, Faidon Liambotis wrote: > Indeed, autodep8 generates a file that has the manual tests combined > with a pybuild-autopkgtest one. The pybuild-autopkgtest one is *not* > marked as as superficial[1], as evident by the autodep8 output. > > 1: Debatable in this particular package, but besides the main point. In case you go looking at the package to reproduce, note that in the final upload to experimental I added extra_restrictions=superficial to debian/tests/autopkgtest-pkg-pybuild.conf, so the autodep8 test will now also be marked as superficial. In this case the lintian warning is appropriate. The bug however stands (it's present when autopkgtest-pkg-pybuild.conf is not present). It can be reproduced by: apt source esptool=4.5.1+dfsg-0.1 cd esptool* rm debian/tests/autopkgtest-pkg-pybuild.conf autodep8 # should list a d/t/control with a non-superficial test dpkg-buildpackage -S lintian ../esptool*dsc Faidon
Bug#1033103: superficial-tests: false positive when both Testsuite + d/t/control are used
Source: lintian Version: 2.116.3 Severity: normal In the experimental branch of src:esptool, I've defined the following: * Testsuite: autopkgtest-pkg-pybuild in debian/control, to test the Python module. * Three superficial tests in debian/tests/control to test the CLI tools using --help. TTBOMK this is valid configuration. autodep8(1) has a section titled "COMBINING AUTO-GENERATED TESTS WITH MANUALLY SPECIFIED ONES" to cover this use case. Indeed, autodep8 generates a file that has the manual tests combined with a pybuild-autopkgtest one. The pybuild-autopkgtest one is *not* marked as as superficial[1], as evident by the autodep8 output. As another piece of evidence, autopkgtest reports: autopkgtest [13:39:27]: summary smoke-esptoolPASS (superficial) smoke-espefuse PASS (superficial) smoke-espsecure PASS (superficial) pybuild-autopkgtest PASS However, lintian is warning about "superficial-tests", and says "The source package declares tests in the debian/tests/control file but provides only tests with a superficial restriction.". It looks to me like a lintian bug, but let me know if I've misunderstood something. Regards, Faidon 1: Debatable in this particular package, but besides the main point.
Bug#1032587: UDD's upstream_metadata table may contain stale data?
On Tue, Mar 14, 2023 at 06:42:36PM +0100, Andreas Tille wrote: > Thanks a lot for your bug report. I realised some cron job gathering > upstream metadata files (and other machine readable files) is crashing > at some point in time. I need to check this and can't promise anything > but its really good you filed this bug report since the crash seems to > happen later than those packages I'm watching closely and thus I did > not noticed. Thanks Andreas! Is the code and/or logs for this cronjob somewhere I can access myself? Perhaps I could have a look myself and help you out? Faidon
Bug#1032057: pyproject-api: please make the build reproducible
On Sat, Mar 04, 2023 at 01:17:55PM +0200, Faidon Liambotis wrote: > I checked the Sphinx source code, and it looks like the string is used > in prepare_writing() from builders/html/__init__.py, which in turn > passes it on as an argument to format_date() from util/i18n.py. It looks > like format_date() has support for SOURCE_DATE_EPOCH. > > So from what I can tell, a much simpler patch would be to set > html_last_updated_fmt to "%Y-%m-%dT%H:%M:%S.%f" for the equivalent ISO > 8601 string (or even something with less accuracy) -- no need to fiddle > with the datetime module, or SOURCE_DATE_EPOCH at all. I submitted a PR and fixed this issue upstream in both pyproject-api and tox. The former was included in the 1.5.1 release, which I'll upload shortly. Regards, Faidon
Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t
On Thu, Mar 09, 2023 at 08:09:38PM +0200, Faidon Liambotis wrote: > I pushed this as an MR against the 15 branch: > https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/113 > (I don't have access to push directly -- and that's totally fine :) > > I also kicked off a test build on barriere, which will take a few hours. > I'll let folks now if it succeeds. I cherry-picked MR #113 over 1:15.0.7-1, built it, and ran a few test cases, including Simon's steps at the beginning of this bug report. Everything worked as intended, addressing the issue at hand here. The source & binary packages are on barriere:~paravoid/llvm-1032317/ if anyone else wants to run any tests. Faidon
Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t
Control: tags -1 + patch On Wed, Mar 08, 2023 at 06:51:36PM +0100, Sylvestre Ledru wrote: > Le 08/03/2023 à 18:13, Simon McVittie a écrit : > > On Wed, 08 Mar 2023 at 17:46:11 +0200, Faidon Liambotis wrote: > > > I'm not submitting an MR because I noticed that "15" branch has > > > progressed further compared to 1-15.0.7-1, and I'm not sure how you'd > > > like to handle it; basically whether these changes are suitable for > > > bookworm at this point, or whether you'd like to to fork a branch for > > > bookworm. > > See also #1032316 which is exactly about whether 1%15.0.7-1 is intended > > for bookworm or not: the reason I started looking at this is that > > 1%15.0.7-1 not migrating is holding back fixes in src:mesa, at least > > one of which is RC. > > yeah, it is intended for bookworm > > sorry if i didn't state it clearly earlier. > > Faidon, would you like to push your fixes directly in the repo? I pushed this as an MR against the 15 branch: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/113 (I don't have access to push directly -- and that's totally fine :) I also kicked off a test build on barriere, which will take a few hours. I'll let folks now if it succeeds. Faidon
Bug#1032593: Automatically map intersphinx references to local packages
Source: sphinx
Version: 5.3.0-3
Severity: wishlist
Countless packages contain a stanza in their docs/conf.py like:
intersphinx_mapping = {
"python": ("https://docs.python.org/3;, None),
}
Given packages in Debian cannot use network access when being built, and
the dh_make Sphinx boilerplates suggest defining http_proxy to avoid
Sphinx resolving this through the internet, one of these two things
happens:
1) The maintainer patches the upstream source through debian/patches, to
point these references to the local filesystem. That's actually what
src:sphinx does as well for itself, through the intersphinx_local.diff
patch. A quick codesearch[1] reveals ~385 packages doing something
similar.
2) The maintainer does not patch the source, Sphinx attemps to fetch the
file from the network, fails due to http_proxy, and the generated docs
do not resolve these references. Build-time warnings are emitted of the
form:
WARNING: py:class reference target not found: pathlib.Path
I don't know of an easy way to grep through the build logs to generate
numbers. Anecdotally, I've seen quite a few packages in that category as
well. (Perhaps one could add a tag to the Buildd Log Scanner[2] to scan
for this?)
It'd be great if intersphinx in Debian was patched to map these
references to the local Debian package and also to generate the
necessary dependencies -- perhaps guarded by a environment variable or
command-line option that dh_sphinx would only pass, for example.
Beyond patching the Sphinx code itself, there is of course the matter of
generating these mappings, which is surprisingly non-trivial. From what
I can tell the mappings need to be created heuristically, since I
haven't seen of a way for a central Sphinx to document in metadata where
the generation documentation will be published.
I played around with a few ideas, and while I haven't settled on
something that I feel is not dirty yet, I tried to implement something
akin to what dh-python's pydist/generate_fallback_list.py does: have a
script in the source to be executed manually periodically to regenerate
the cache, which creates a mapping that is then committed to git, and
shipped in the binary.
So I implemented the attached proof of concept that:
* Scans Contents-all and Contents-amd64 to find objects.inv files
and maps them back to the binary packages;
* Queries UDD (through one query with joins) to:
- find the respective source packages for these binary packages
- find the upstream metadata[3] for these source package
* Prints a tab-separated intersphinx_mappings file that has:
\t\
It takes ~10s to run on my computer right now, which should be fine for
being executed periodically by the maintainer.
I'm sure there are many issues with this approach that I haven't thought
through, as well as a number of corner cases, but I wanted to have
something to kickstart this discussion beyond just wishful thinking!
I'd love any feedback! Note that I haven't looked at all at what it
would take to integrate this mapping to the Sphinx source (as well as
${sphinx:Depends}) as I thought it'd be good to validate the approach
before I do so.
Regards,
Faidon
1:
https://codesearch.debian.net/search?q=intersphinx_mapping+path%3Adebian%2F=1=1
2: https://qa.debian.org/bls/
3: I ran into stale data in that table, which is now tracked as #1032587
#!/usr/bin/python3
#
# Copyright © 2023 Faidon Liambotis
#
# Roughly based on dh-python/pydist/generate_fallback_list.py which is:
# Copyright © 2010-2015 Piotr Ożarowski
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
# THE SOFTWARE.
import re
import sys
try:
from distro_info import DistroInfo # python3-distro-info package
except ImportError:
DistroInfo = None
from gzip import decompress
from pathlib import Path
from urllib.parse import urlparse
from urllib.request import urlopen
import psycopg2
import psycopg2.extras
if "--ubuntu" in sys.argv and DistroInfo:
SOURCES
Bug#1032587: UDD's upstream_metadata table may contain stale data?
Package: qa.debian.org User: qa.debian@packages.debian.org Usertags: udd Severity: normal X-Debbugs-Cc: ti...@debian.org m trying to query UDD for upstream metadata, but upon running some SELECTs on public.upstream_metadata I've noticed that it doesn't have data for e.g. src:python-structlog, which I added to the package with the 22.3.0-1 upload on 18 Feb 2023. I asked about the refresh frequency in #debian-qa, to which Lucas responded that's not 100% sure of the status and encouraged me to file a bug here. He also noted there is no mention of upstream metadata in https://udd.debian.org/udd-status.cgi and that maybe [the updater] is no longer running. This is my first attempt to query this data, so I hope this isn't an operator error! Thanks in advance, Faidon
Bug#983719: esptool: Version 3.0 fixes critical bugs
On Thu, Feb 23, 2023 at 12:16:41PM +0200, Faidon Liambotis wrote: > I also have changes underway for 4.5, but currently looking into what it > would take dependency-wise to accomplish this, as there are 1-2 new > Python module dependencies that are not present in Debian yet. I'll > follow up once I have something; I expect this to be in the next week or > so. I packaged the two new dependencies mentioned above: * python-reedsolo, which entered unstable this week; and * python-pkcs11 (used only conditionally, for espsecure's HSM bits), which is waiting in NEW for about a week now. I moved the repository to the DEP-14 layout, rebased the feature/2.8-update branch, and then built on top of it in the new debian/experimental branch. This now has 4.5.1, with lots of other fixes and flasher stubs! I'd consider this a release candidate for an experimental upload once pkcs11 passes through NEW. Faidon
Bug#948096: Please build and ship flasher_stubs
Small update: On Tue, Feb 21, 2023 at 02:05:26PM +0200, Faidon Liambotis wrote: > Some good news: [...] I've staged a commit in the debian/experimental branch that takes care of all this, and builds stubs for ESP8266 and the RISC-V ESP32 chips. Hooray! > (There is a tiny warning about no debug support that is silenced by > removing "-g" from CFLAGS). That's a regression with GCC 12, and filed against gcc-xtensa-lx106 with #1032564. > 1. passing the right CROSS_ prefixes for every chip (configurable) > 2. passing -mabi=ilp32 to CFLAGS (upstreamable) > 3. passing -specs=picolibc.specs to CFLAGS (to use picolibc) These are now patched locally in d/patches in the debian/experimental branch, and upstreamed with PR #856: https://github.com/espressif/esptool/pull/856 Faidon
Bug#1032564: "warning: target system does not support debug output" regression
Package: gcc-xtensa-lx106 Version: 12.2.0-9+12 Severity: normal X-Debbugs-Cc: kei...@keithp.com When building with -g, I get warnings such as: xtensa-lx106-elf-gcc: warning: target system does not support debug output cc1: warning: target system does not support debug output I've noticed this while resuming work on this old project youy may remember: attempting to build the esptool ESP8266 stubs (#948096). However, it looks like Keith also experienced the same, and disabled debug mode with this picolibc commit: https://github.com/picolibc/picolibc/commit/711dbd24220a05693dc3711545d0a2e2cb7ff8e9 Going through snapshots.d.o, these warnings started being emitted with 12.2.0-9+12 and are still emitted with 12.2.0-14+12+b1. They were not with 11.3.0-4+11 and earlier (including bullseye's, 10.2.1-6+8+b1) Faidon
Bug#1029010: llvm-toolchain-15: autopkgtest regression
On Wed, Mar 08, 2023 at 09:41:21AM +, Simon McVittie wrote: > > there is a metapackage, libc++-dev-wasm32, which Depends on the > > default implementation, which is libc++-14-dev-wasm32 right now. That > > metapackage has at least one notable reverse B-D, firefox, using it to > > build certain security/sandboxing features (RLBox[1], AIUI). That is to > > say, this feature works (w/ 14) and does very useful things today. it > > (seemingly) broke when it was ported to llvm-toolchain-15, which > > src:firefox does not depend on directly. > > If I understand correctly, that doesn't *necessarily* have to be RC for > bookworm, because llvm-toolchain-15 is not (yet!) the default version > of LLVM provided by the metapackage, and is only used by Mesa? But it > would be a blocker for either moving the default forward from 14 to 15 > (as has already been done in experimental), or making Firefox use the > non-default 15 toolchain like Mesa does, presumably to get some new > feature or optimization that isn't in 14? At least as I also understand it, that's right. I think it'd be a pity to revert this for 15 and we should aim for feature parity between the two branches, but disabling it is, and can remain an option as a plan B given where we are in the bookworm release cycle. That's IMHO, with a biased view, as the wasm patches author, but ultimately up to the maintainer (which is definitely not me ;). I'm hopeful we can address the underlying issue quickly though, and I propose to put a hold to this conversation for the time being and see where we get with a proper resolution first. I just posted a patch in the other bug report. Fingers crossed. Faidon
Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t
On Wed, Mar 08, 2023 at 09:08:13AM +0100, Sylvestre Ledru wrote:
> > Specifically, it looks like the entire patching of the method
> > WebAssembly::AddClangCXXStdlibIncludeArgs isn't happening anymore. One
> > of these differences was exactly about this -- the comment says:
> >// don't include the host architecture's headers in the search path
> >
> > Sylvestre, I think you did the 14->15 porting, right? Do you
> > know/remember what happened there?
>
> Maybe i did a mistake in the merge?!
Upstream commit b5787a0 ("Support -stdlib=libstdc++ for WebAssembly")
reorganized the code a bit, which resulted in a merge conflict. It also
included half of what my patch did, namely the getDriver().SysRoot to
computeSysRoot() conversion, which probably resulted in you thinking
that this hunk isn't necessary anymore!
I'm attaching a diff that restores the second half of the diff, and I
believe should fix this bug. (LLVM is a pain to build and test, so I
haven't tested this at all yet; hoping that it's easier for Sylvestre to
test!). I'm also attaching the interdiff in case it helps anyone to
review.
I'm not submitting an MR because I noticed that "15" branch has
progressed further compared to 1-15.0.7-1, and I'm not sure how you'd
like to handle it; basically whether these changes are suitable for
bookworm at this point, or whether you'd like to to fork a branch for
bookworm.
Side-note unrelated to this bug, but confused me during its
investigation:
# this is a badly named duplicate of debian/1%15.0.7-1
git tag -d debian/1%15.0.71; git push origin :debian/1%15.0.71
# cruft left behind from the move to debian/patches/wasm/
git checkout 15; git rm debian/patches/wasm-*; git commit -m "Remove cruft"
git checkout snapshot; git rm debian/patches/wasm-*; git commit -m "Remove
cruft"
HTH!
Faidon
--- a/debian/patches/wasm/wasm-sysroot-usr.diff
+++ b/debian/patches/wasm/wasm-sysroot-usr.diff
@@ -57,6 +59,33 @@
void WebAssembly::addLibCxxIncludePaths(
const llvm::opt::ArgList ,
llvm::opt::ArgStringList ) const {
+@@ -499,7 +519,9 @@ void WebAssembly::addLibCxxIncludePaths(
+ }
+
+ // Second add the generic one.
+- addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
++ // don't include the host architecture's headers in the search path
++ if (!getDriver().SysRoot.empty())
++addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+ }
+
+ void WebAssembly::addLibStdCXXIncludePaths(
+@@ -546,8 +568,11 @@ void WebAssembly::addLibStdCXXIncludePat
+ addSystemInclude(DriverArgs, CC1Args, TargetDir);
+ }
+
+- // Second add the generic one.
+- addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+- // Third the backward one.
+- addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
++ // don't include the host architecture's headers in the search path
++ if (!getDriver().SysRoot.empty()) {
++// Second add the generic one.
++addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
++// Third the backward one.
++addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
++ }
+ }
--- a/clang/lib/Driver/ToolChains/WebAssembly.h
+++ b/clang/lib/Driver/ToolChains/WebAssembly.h
@@ -89,6 +89,8 @@ private:
diff -u b/clang/lib/Driver/ToolChains/WebAssembly.cpp b/clang/lib/Driver/ToolChains/WebAssembly.cpp
--- b/clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ b/clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -519,7 +519,9 @@
}
// Second add the generic one.
- addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+ // don't include the host architecture's headers in the search path
+ if (!getDriver().SysRoot.empty())
+addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
}
void WebAssembly::addLibStdCXXIncludePaths(
@@ -568,6 +570,9 @@
- // Second add the generic one.
- addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
- // Third the backward one.
- addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
+ // don't include the host architecture's headers in the search path
+ if (!getDriver().SysRoot.empty()) {
+// Second add the generic one.
+addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version);
+// Third the backward one.
+addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" + Version + "/backward");
+ }
}
Bug#1016183: RFH: crun -- lightweight OCI runtime for running containers
On Thu, Jul 28, 2022 at 06:39:21PM +0200, Bastian Germann wrote: > Package: wnpp > > The crun maintainer has requested help in #1014306. I've done a few uploads since (1.5+dfsg-1, 1.8-1 and 1.8.1-1), as well as prepared an upload for a bullseye-pu (#1031109). Reinhard also worked on the package a fair bit, and was added as a comaintainer with 1.8-1. We could always use more hands, but as far as wnpp goes, I think the maintainer got some help :) Faidon
Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t
On Fri, Mar 03, 2023 at 05:31:41PM +, Simon McVittie wrote: > # clang++-15 -c --target=wasi-wasm32 -ostddef-cpp.o stddef.cpp > # apt-get install --no-install-recommends libc++-15-dev > # clang++-15 -c --target=wasi-wasm32 -ostddef-cpp.o stddef.cpp > > Expected result: both clang++-15 calls succeed (stddef.h declares size_t) > > Actual result: the second clang++-15 call fails: (Super helpful bug report, thanks!) As I mentioned in #1029010 just now, this is a regression from 14->15. Retracing the same steps with clang-14 & libc++-14-dev-wasm32, there are no errors and everything works as intended. Looking at the differences of the include paths between the two by passing -v to clang, one can see: /usr/include/wasm32-wasi/c++/v1 - /usr/lib/llvm-14/lib/clang/14.0.6/include + /usr/include/c++/v1 + /usr/lib/llvm-15/lib/clang/15.0.7/include /usr/local/include /usr/include/wasm32-wasi /usr/include i.e. /usr/include/c++/v1 (i.e. libc++-15-dev) is included in the include path only with clang-15. It shouldn't be. Looking at the interdiff of d/patches/wasm/wasm-sysroot-usr.diff[1] patch between llvm-toolchain 1:14.0.6-12 and 1:15.0.7-1, it looks line there are a few hunks that are missing. Specifically, it looks like the entire patching of the method WebAssembly::AddClangCXXStdlibIncludeArgs isn't happening anymore. One of these differences was exactly about this -- the comment says: // don't include the host architecture's headers in the search path Sylvestre, I think you did the 14->15 porting, right? Do you know/remember what happened there? Regards, Faidon 1: Note that the git tree also has d/patches/wasm-sysroot-usr.diff (and d/patches/wasm-compiler-rt-default.diff) which are earlier versions of this patch, now unused (not in d/patches/series). I think what happened was that the files were copied, instead of moved, to d/patches/wasm/. Here I am talking exclusively about the versions in d/patches/wasm/. It'd be good to cleanup this cruft to avoid further confusion.
Bug#1029010: llvm-toolchain-15: autopkgtest regression
On Fri, Mar 03, 2023 at 05:46:15PM +, Simon McVittie wrote: > I've cut down what I think is the root cause of this compile failure to > a more minimal bug report: see #1032317. That's super helpful, thanks :) Spoiler alert: I have a suspicion on the root cause, I'll follow up there. > I don't think this is *really* a regression, because in the version in > bookworm, the autopkgtest didn't exercise compilation of C++ into > WebAssembly at all. This statement strictly speaking is true, but applies only if you look at LLVM 15 in isolation. It *is* a regression, in the sense that this works with llvm-toolchain-14, where the WebAssembly work was first pushed, today, in both bookworm and sid. For example, retracing your steps in #1032317 with s/15/14/ does not result into a failure. > If I understand correctly, when compared with bookworm, the version in > sid adds a new feature (the necessary -dev packages for compiling C++ into > WebAssembly) and also adds a smoke-test for that feature, but the feature > doesn't yet work as intended. Is that accurate? Kind of -- again, strictly speaking, true for libc++-15-dev-wasm32. However, there is a metapackage, libc++-dev-wasm32, which Depends on the default implementation, which is libc++-14-dev-wasm32 right now. That metapackage has at least one notable reverse B-D, firefox, using it to build certain security/sandboxing features (RLBox[1], AIUI). That is to say, this feature works (w/ 14) and does very useful things today. it (seemingly) broke when it was ported to llvm-toolchain-15, which src:firefox does not depend on directly. 1: https://rlbox.dev/ Regards, Faidon
Bug#1032057: pyproject-api: please make the build reproducible
Hi Chris!
On Mon, Feb 27, 2023 at 07:53:12AM +, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed
> that pyproject-api could not be built reproducibly.
That's unfortunate! Sorry for not realizing it before you did.
For what it's worth, this package was uploaded as a new dependency of
tox 4. It looks like tox 4.4.6-1 (uploaded to experimental last week)
suffers from the same issue as well. I will handle it there as soon as
we conclude our resolution of this one -- no need for a separate bug :)
> This is because the documentation embeds the current date in the
> build system's current timezone. A patch is attached that uses
> SOURCE_DATE_EPOCH [1] if available.
>
> ...
>
> + html_theme = "furo"
> +-html_title, html_last_updated_fmt = "pyproject-api docs",
> datetime.now().isoformat()
> ++build_date = datetime.utcfromtimestamp(
> ++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
> ++)
> ++html_title, html_last_updated_fmt = "pyproject-api docs",
> build_date.isoformat()
Looking at Sphinx's documentation, it looks like html_last_updated_fmt,
as the name hints, is supposed to be the format string, not the actual
date. (A literal date works as a format because anything that's not
percent-encoded is passed on unmodified. So I think that's just a happy
accident.)
I checked the Sphinx source code, and it looks like the string is used
in prepare_writing() from builders/html/__init__.py, which in turn
passes it on as an argument to format_date() from util/i18n.py. It looks
like format_date() has support for SOURCE_DATE_EPOCH.
So from what I can tell, a much simpler patch would be to set
html_last_updated_fmt to "%Y-%m-%dT%H:%M:%S.%f" for the equivalent ISO
8601 string (or even something with less accuracy) -- no need to fiddle
with the datetime module, or SOURCE_DATE_EPOCH at all.
I know you've gone to great lengths to make Sphinx docs reproducible
across the board, so I'm leaning on your experience to let me know if
I'm missing something here before I patch it locally and pass it on to
the two upstream projects. Looking forward to your feedback.
Best,
Faidon
Bug#1032143: ITP: python-pkcs11 -- high level PKCS#11 interface for Python
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-pkcs11 Version : 0.7.0 Upstream Author : Danielle Madeley * URL : https://github.com/danni/python-pkcs11/ * License : Expat Programming Lang: Python Description : high level PKCS#11 interface for Python A high level, "more Pythonic" interface to the PKCS#11 (Cryptoki) standard to support HSM and Smartcard devices in Python. . The interface is designed to follow the logical structure of a HSM, with useful defaults for obscurely documented parameters. Many APIs will optionally accept iterables and act as generators, allowing you to stream large data blocks for symmetric encryption. . It also includes numerous utility functions to convert between PKCS#11 data structures and common interchange formats including PKCS#1 and X.509. . The library is fully documented and has a full integration test suite for all features, with continuous integration against multiple HSM platforms including Entrust nShield, Opencryptoki TPM and OpenSC/Smartcard-HSM/Nitrokey HSM. New optional dependency for esptool, a package that I am trying to help with. I intend to maintain this package as part of the Debian Python Team. Co-maintainers/Uploaders more than welcome.
Bug#1032121: Please build and ship the packaging's documentation
Package: python3-packaging Version: 23.0-1 Severity: wishlist Upstream ships documentation in the docs/ directory, including a standard Sphinx Makefile that can be used to build it. Please build it and ship it as part of this package. My main use case is other packages (tox and friends) hat are trying to build their own documentation, and want to link to the packaging manual as a reference. Thanks! Faidon
Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa
On Mon, Feb 27, 2023 at 09:20:05PM +0100, Helge Deller wrote: > Yes, you seem to be right. I missed the stat() calls. > I wonder - do you know which files are monitored with the stat() calls? > Could it be that those are just files from /dev or /proc, or are other > standard files monitored too? They are configuration files in /etc/gdnsd, state files in /run, as well as user-configurable paths, as configured in /etc/gdnsd/config, cf. gdnsd-plugin-extfile(8). So I see where you were going with this, but I'm afraid that there's no shortcut here :/ What would you like to do with this bug? Would you like to file a bug against libev and mark this bug as blocked by the libev one? Or alternatively I can mark as wontfix and resolve? (Quite honestly I'm not sure if I were the libev maintainer if I'd bother with an ABI bump for this; but they might :) Regards, Faidon
Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa
Hi Helge, On Sun, Feb 26, 2023 at 01:06:16PM +0100, Helge Deller wrote: > > So, from what I can tell, this is not something that I can fix locally > > within gdnsd right now. AIUI what would need to happen is that libev > > would need to be build with LFS support first, which would mean > > rebuilding it with future=+lfs, breaking its ABI in the process, > > requiring an ABI bump, and in turn a transition during which all of its > > reverse dependencies will need sourceful uploads as to be modified to > > also pass future=+lfs/-D_FILE_OFFSET_BITS=64, and then to be rebuilt > > themselves (and possibly also affecting their reverse-dependency chains > > as well). > > Correct. Not something which is possible now. > > But I have another idea. > We don't need to touch libev for now. > Instead the only thing which currently may fail is the readdir() in > src/zsrc_rfc1035.c. If we get this call to use the 64-bit variant we > are done. > > Attached is a proposed patch. It just changes this specific readdir() > and is independend of libev. > I've sucessfully tested it on the hppa architecture, and I hope it > compiles the same way on all other platforms too. > Could you check? I don't think that's right. I think there are two independent LFS issues with current builds of gdnsd: 1) the readdir() call in the rfc1035 zonefile parser (src/zsrc_rfc1035.c) 2) the stat() calls, via ev_stat_init etc., in the mon and extfile plugins. These two issues are in different parts of gdnsd, and independent from each other. (1) is contained within gdnsd, and thus building with future=+lfs, as you originally suggested, addresses this issue. Your readdir64() patch also addresses this issue, and is functionally the same in that regard: AIUI with _FILE_OFFSET_BITS=64, glibc implements readdir() with a readdir64() system call. However, (2) is not self-contained, with stat structures crossing an ABI boundary (libev's). Hence why the test suite (legitimately) fails when building with future=+lfs. My understanding is that patching (1) with the patch you attached, but not building with future=+lfs, ill effectively still create a binary that does not have large file/inode support, as the stat() calls that the mon/extfile plugins make, will not work on 64-bit inode filesystems. Does this make sense? Faidon
Bug#983719: esptool: Version 3.0 fixes critical bugs
On Tue, Feb 21, 2023 at 02:16:40PM +0200, Faidon Liambotis wrote: > I should note that while the package seems to meet the criteria for > Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain > it properly in the long run either. I'm happy to do a one-off NMU to > bring it to a more decent shape, however. Update: I pushed a branch into the main repo, feature/2.8-update, that just brings up the packaging to modern standards and switches to using pybuild -- a step necessary given new upstream releases are now using Python modules etc. This is still tagged as a 2.8+dfsg-1.1 release that builds the package as-is with enhancements and no regressions. I also have changes underway for 4.5, but currently looking into what it would take dependency-wise to accomplish this, as there are 1-2 new Python module dependencies that are not present in Debian yet. I'll follow up once I have something; I expect this to be in the next week or so. Regards, Faidon
