Bug#1074409: ITP: jeolib-miallib -- JRC morphological and image processing library
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: jeolib-miallib Version : 1.1.3 Upstream Contact: Pieter Kempeneers * URL : https://github.com/ec-jrc/jeolib-miallib * License : GPL Programming Lang: C Description : JRC morphological and image processing library Miallib is a C library including image processing and mathematical morphology algorithms used by Join Research Center in their Big Data Analytics Platform, with binding for Python provided. . This is the first component of the JRC PyJeo C++ and Python library, but can be used as a standalone library too. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Re: Builds that pass locally but fail on sbuild? (Re: Reviving schroot as used by sbuild)
On Thu, 27 Jun 2024 at 19:56:43 -0700, Otto Kekäläinen wrote:
> Could you point me to some Debian Bug # or otherwise share examples of
> cases when a build succeeded locally but failed on official Debian
> builders due to something that is specific for sbuild/schroot?
I can't easily point you to a Debian bug number, because I try to only
upload packages that live up to Debian's quality standards, which means
I've been routinely building packages for upload in sbuild/schroot for
several years; so if a package fails in that situation, I do not upload,
and retry as many times as it takes to get it right.
(I'm sure I've failed to do that several times, but I'm sorry, I mostly
can't remember specific instances or bug numbers; I generally try to fix
the regression as quickly as I can.)
But, some examples of packages and the reasons they fail:
- bubblewrap, repeatedly. Its test suite wants to create new user
and filesystem namespaces, which is unconditionally not allowed by
the kernel while inside a chroot (because the kernel doesn't want to
allow filesystem namespaces to be used to escape from a chroot). The
relevant tests have to be skipped in situations where they can't work.
"Real" container managers that use pivot_root() instead of chroot(),
such as Docker and Podman, sometimes allow creation of nested user
namespaces (like bwrap by default, and docker --privileged), sometimes
deny it (like bwrap --disable-userns, and Docker by default), and
sometimes cannot allow it because some larger factor forces their hand:
it's non-obvious what will work.
The conditions for not being allowed to create new namespaces are
relatively complicated and poorly-documented, and the error reporting is
minimal (two or three errno values have to cover every possible failure
mode), so this is something that has to be done by trial and error.
Until recently, DSA'd machines all used
/proc/sys/kernel/unprivileged_userns_clone to disable unprivileged
creation of user namespaces anyway. This restriction has presumably
been lifted for the buildds that use sbuild in unshare mode.
- xdg-desktop-portal, repeatedly. Its test suite uses FUSE, which is
disabled (the module is prevented from loading) on official Debian
buildds as a security hardening mechanism, even though on typical
end-user or server Debian systems it works fine.
This is one that I did have to find out via FTBFS, because I don't yet
have a local build environment that replicates this restriction. I know
that I should, and it's on my list.
- ostree, at least once. The test suite historically assumed that /var/tmp
supports extended attributes, which is not true on all buildds (ordinary
on-disk filesystems usually do support them, but tmpfs doesn't or didn't
until recently, and some buildds with plenty of RAM operate in a tmpfs
root filesystem to speed up their builds).
- flatpak, repeatedly. Same as bubblewrap, ostree and x-d-p, combined.
- dbus, historically. For a long time, when using the non-default
DBUS_COOKIE_SHA1 authentication mechanism, libdbus ignored $HOME and
instead used the "official" home directory from /etc/passwd
(the equivalent of `getent passwd $(id -u) | cut -d: -f6`). Official
buildds set the user's home directory to /nonexistent, so this fails.
In production use, dbus normally uses EXTERNAL over AF_UNIX (and doesn't
even allow DBUS_COOKIE_SHA1, as a piece of security hardening), but in
its build-time tests it specifically exercises each auth mechanism and
each transport, including DBUS_COOKIE_SHA1 over TCP (which is a
terrible idea on Unix but is unfortunately necessary on Windows).
- GLib, ongoing (#972151). When the GLib test suite tests interoperability
with libdbus, it (IMO reasonably!) expects ("localhost", AF_INET) to
resolve to 127.0.0.1, but that doesn't work on IPv6-only buildds for
relatively complicated reasons involving subtleties of glibc resolver
behaviour (#952740). My local build environment still doesn't have code
to reproduce this, and I'm sorry that I haven't provided workarounds or
fixes in the GLib test suite or in libdbus' discouraged TCP code paths.
If someone wants to work on this, skipping the interop tests for TCP on
IPV6-only buildds would probably be more proportionate than adjusting
libdbus' name-resolution behaviour for a feature nobody should be
using in production anyway.
- Any package that assumes that if $XDG_RUNTIME_DIR is set, then it is
set to a usable value (because historically schroot would set it to
a value that exists/works on the host system, but does not exist and
cannot be created inside the container). This is worked around by
individual packages unsetting XDG_RUNTIME_DIR or setting it to a more
useful value, or automatically by recent debhelper in a sufficiently
high compat level (#942111).
> I have never run in such a situation despite doing Debian packaging
> for 10 years with fairly compl
How does lintian use groff to validate man pages?
Hello, from the past I do remember that lintian do use "groff" to validate/lint man pages and their syntax. I would like to know the exact call including options that lintian use to execute groff on a man page file. I don't get it using the man page of groff. It alwas output a lot of man page syntax. And my man page can not be that shitty. ;) Thanks, Christian
Re: How does lintian use groff to validate man pages?
Hi Christian, c.bu...@posteo.jp, on 2024-06-28: > from the past I do remember that lintian do use "groff" to validate/lint man > pages and their syntax. > I would like to know the exact call including options that lintian use to > execute groff on a man page file. lintian-explain-tags can provide you with extensive information about issues lintian may report. In your particular case, it even should answer your question: $ lintian-explain-tags groff-message […] N: You can see the warnings yourself by running the command used by Lintian: N: N: LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \ N: man --warnings -E UTF-8 -l -Tutf8 -Z >/dev/null […] Hope this helps, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Re: How does lintian use groff to validate man pages?
Hello Étienne, thanks for the reply. Am 28.06.2024 13:00 schrieb Étienne Mollier: lintian-explain-tags can provide you with extensive information ... N: LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \ N: man --warnings -E UTF-8 -l -Tutf8 -Z >/dev/null Do I do something wrong? It is not working in my case (running on Debian 12): groff LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 -Z ./backintime.1 >/dev/null groff: unrecognized option '--warnings' Best, Christian
Re: How does lintian use groff to validate man pages?
On Fri, Jun 28, 2024 at 11:38:50AM +, c.bu...@posteo.jp wrote: > > lintian-explain-tags can provide you with extensive information > > ... > > N: LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \ > > N: man --warnings -E UTF-8 -l -Tutf8 -Z >/dev/null > > Do I do something wrong? It is not working in my case (running on Debian > 12): > > groff LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l > -Tutf8 -Z ./backintime.1 >/dev/null > groff: unrecognized option '--warnings' You prepended "groff" to the command. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1074420: ITP: python-yubihsm -- Python library for the YubiHSM 2
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-yubihsm Version : 3.0.0 Upstream Contact: Dain Nilsson * URL : https://github.com/Yubico/python-yubihsm * License : Apache-2.0 Programming Lang: Python Description : Python library for the YubiHSM 2 The YubiHSM 2 is a USB-attached device for managing cryptographic keys. This package contains a Python interface to it, communicating via yubihsm-connector. We're in the process of starting to use a YubiHSM in Freexian, and I have hardware that I can use to test this. For some purposes (signing using keys that are already loaded into the HSM) it's possible to just interact with the HSM over PKCS#11, but for others we need finer control over things like capabilities, and to do this from Python code it's more pleasant to have a proper module rather than having to drive yubihsm-shell from Python. This package could reasonably live under either pkg-security-team or the Python team, but I think I'll go with pkg-security-team since it's pretty closely linked with the other YubiHSM packages I've uploaded recently. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Reviving schroot as used by sbuild
> "Helmut" == Helmut Grohne writes: Helmut> In this work, limitations with --chroot-mode=unshare became Helmut> apparent and that lead to Johannes, Jochen and me sitting Helmut> down in Berlin pondering ideas on how to improve the Helmut> situation. That is a longer story, but eventually Timo Helmut> Röhling asked the innocuous question of why we cannot just Helmut> use schroot and make it work with namespaces. I'll be honest, I think building a new container backend makes no sense at all. There's a lot of work that has gone into systemd-nspawn, podman, docker, crun, runc, and the related ecosystems. I think an approach that allowed sbuild to actually use a real container backend would be long-term more maintainable and would allow Debian's DevOps practices to better align with the rest of the world. I have some work I've been doing in this space which won't be useful to you because it is not built on top of sbuild. (Although I'd be happy to share under LGPL-3 for anyone interested.) But I find that I disagree with the idea of writing a new container runtime for sbuild so strongly that I can no longer use sbuild for Debian work, so I started working on my own package building solution. I realize that I have not done a good job of being constructive here. I intended to write some blog posts on this topic, but got sucked into work and tag2upload. In terms of constructive feedback: * I think your intuition that sbuild --chroot=unshare is limiting is good. * I would move toward a persistent namespace approach because it is more similar to broadly used container backends. * overlayfs/fuse-overlayfs are how the rest of the world is solving these problems (or snapshots and the like). Directories are kind of a Debian-specific artifact that I find more and more awward to deal with as the rest of my work uses containers for CI/CD. signature.asc Description: PGP signature
Packaging Gecode twice to have newer snapshot for Minizinc
I have an unhappy situation with Gecode and Minizinc. Gecode offers two things: A shared C++ library, and a flatzinc programming language implementation. Minizinc is a programming language as well, whose implementation works by turning minizinc programs to flatzinc and uses an implementation to execute it. Much like the numerous languages outputting C or JS. Minizinc also requires Gecode library to compile itself, but that's an independent use from invoking a flatzinc executable. Indeed, flatzinc has multiple implementations and minizinc has support for picking one among them. Gecode's is just the default one and the one minizinc is bundled with in their upstream binaries. Debian has two others packaged, chuffed and ortools. Unfortunately chuffed is only a partial implementation and ortools is currently uninstallable and updating it is pending on absl library upgrade (which is no mean feat). Gecode has last had a release in 2019 and the flatzinc implementation offered by it is not sufficient to run current minizinc programs. A new Gecode release would be ideal but unfortunately prodding upstream is unlikely to have any quick results as the person who used to do them has passed away since. Minizinc is actively developed and has frequent releases. The current release of Gecode is still sufficient for Minizinc's use of it as a library and I expect it's going to remain that way. Just packaging a Gecode snapshot would solve the issues, but it would imply taking over the SONAME and I'm not willing to do that. ABI changes are upstream's call. I'm considering packaging Gecode again as gecode-snapshot and also keep the original gecode package. I'd remove the flatzinc executable from the original and only offer flatzinc from gecode-snapshot. Alternatively I could pick another flatzinc as a default. None of the currently packaged options are up to the task and I'd have to pick yet another one to package. There are options, some of which are free software. Another option would be to update to the snapshot and still offer a library but move it to some private directories and tell minizinc to use it from there and users to not touch it. There are no current rdepends on it other than minizinc. It wouldn't serve well any users who would be using the library and it'd feel making an even more of a special case of this compared to just going with gecode-snapshot. If nobody objects I'll proceed with an ITP on gecode-snapshot. If and when upstream makes a release I'll retire the package. This all relates to #1073819. I looked at it but there's a limit to what I can do to enable minizinc's features without touching the ABI.
Bug#1074463: ITP: bashbro -- A Bash-based web file browser.
Package: wnpp Severity: wishlist Owner: Adam Danischewski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bashbro Version : 1.04.1 Upstream Contact: Adam Danischewski * URL : https://github.com/victrixsoft/bashbro * License : GPL Programming Lang: Shell/Bash Description : A Bash-based web file browser. A Bash-based web file browser - allowing you to remotely browse, stream, view documents and save files via your web browser. To start bashbro locally on port : $> bashbro -s -p -or- (condensed syntax) $> bashbro -sp Bashbro is a rework of bashttpd (https://github.com/avleen/bashttpd) It is rewritten, self-contained, simplified and enhanced - allowing for streaming of binary files including movies/music/pdf's.
Re: Mini-DebConf in Cambridge, UK - October 10-13 2024
Roberto C. Sánchez dijo [Tue, Jun 25, 2024 at 06:14:54AM -0400]: > On Tue, Jun 25, 2024 at 08:39:51AM +0530, Nilesh Patra wrote: > > On Mon, Jun 24, 2024 at 12:32:59PM +0100, Steve McIntyre wrote: > > > On Mon, Jun 24, 2024 at 12:18:56PM +0200, somebody *claiming* to be Luna > > > Jernberg wrote: > > > > > > > > > > > > Just to be 100% clear, that mail didn't come from Luna's normal gmail > > > account but was instead spoofed and sent via emkei.cz, a "free online > > > fake mailer". It's now blocked from Debian lists. > > > > If what you're saying is correct (based on headers that make sense), it's a > > bit > > concerning since someone is launching targeted spoofing attacks with the > > name > > of actual Debian contributors. > > > > The style of writing mail - everything in one line, CCing several lists is > > similar to how Luna writes it too. Freaky. Sadly, we do have our resident, established, well-known favorite troll. And the project has quite recently made an announcement involving him: https://lists.debian.org/debian-news/2024/msg0.html So, given no evidence otherwise, I point my finger to said troll's general direction. > AI can already generate audio and video that convincingly imitate real > people. Why not the same with email? Though, the implications are rather > serious. > > Perhaps our policies need to evolve to expect (or require?) > cryptographic signatures from DDs in mailing list discussion. We may > eventually reach a point where AI can fabricate those as well, but that > seems to not be possible yet. This time around we don't need to overcomplicate things given we know it is his establihed pattern to come up with false identities trying to smear sh*t on DD's noses.
Re: Mini-DebConf in Cambridge, UK - October 10-13 2024
On Fri, Jun 28, 2024 at 11:23:57PM -0600, Gunnar Wolf wrote: > Roberto C. Sánchez dijo [Tue, Jun 25, 2024 at 06:14:54AM -0400]: > > On Tue, Jun 25, 2024 at 08:39:51AM +0530, Nilesh Patra wrote: > > > On Mon, Jun 24, 2024 at 12:32:59PM +0100, Steve McIntyre wrote: > > > > On Mon, Jun 24, 2024 at 12:18:56PM +0200, somebody *claiming* to be > > > > Luna Jernberg wrote: > > > > > > > > > > > > > > > > Just to be 100% clear, that mail didn't come from Luna's normal gmail > > > > account but was instead spoofed and sent via emkei.cz, a "free online > > > > fake mailer". It's now blocked from Debian lists. > > > > > > If what you're saying is correct (based on headers that make sense), it's > > > a bit > > > concerning since someone is launching targeted spoofing attacks with the > > > name > > > of actual Debian contributors. > > > > > > The style of writing mail - everything in one line, CCing several lists is > > > similar to how Luna writes it too. Freaky. > > Sadly, we do have our resident, established, well-known favorite > troll. And the project has quite recently made an announcement > involving him: > > https://lists.debian.org/debian-news/2024/msg0.html > > So, given no evidence otherwise, I point my finger to said troll's > general direction. > > > AI can already generate audio and video that convincingly imitate real > > people. Why not the same with email? Though, the implications are rather > > serious. > > > > Perhaps our policies need to evolve to expect (or require?) > > cryptographic signatures from DDs in mailing list discussion. We may > > eventually reach a point where AI can fabricate those as well, but that > > seems to not be possible yet. > > This time around we don't need to overcomplicate things given we know > it is his establihed pattern to come up with false identities trying > to smear sh*t on DD's noses. > Advice for those who are unaware of trolls: Do known that such energy sucking creatures exist and avoid them. Groeten Geert Stappers -- Silence is hard to parse signature.asc Description: PGP signature
