Bug#1095753: ITP: golang-github-apache-arrow -- toolbox for data interchange and in-memory analytics
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-apache-arrow Version : 17.0.0-1 Upstream Author : The Apache Software Foundation * URL : https://github.com/apache/arrow * License : Apache-2.0 Programming Lang: Go Description : toolbox for data interchange and in-memory analytics Apache Arrow is a universal columnar format and multi-language toolbox for fast data interchange and in-memory analytics. It contains a set of technologies that enable data systems to efficiently store, process, and move data. There is already a RFP of this package in #970021, however I don't see anyone working on the Go part there. Upstream seems to use a mono-repo approach and the Go bindings (go/ sub-directory) is not part in the repository for upstreams recent tags, but instead one needs to use the go/v* tags to find the Arrow Go release suitable for Go packages (which is currently at the older 'v17'). The *.orig.tar.gz that is useful to use for probably most non-Go bindings are not relevant to use for Go Arrow packaging. Therefor I don't think there makes a lot of sense to use the same Debian source package for this project, since upstream seem to have different release policies for subset of this package. My suggestion is to put the Go part of Apache Arrow in a separate source package, like I do in my local package builds here: https://salsa.debian.org/go-team/packages/golang-github-apache-arrow https://salsa.debian.org/jas/golang-github-apache-arrow/-/pipelines/ Apache Arrow Go is needed by 'github.com/pdevine/tensor' which is needed by 'ollama'. /Simon signature.asc Description: PGP signature
Bug#1095754: ITP: django-webtest -- Instant integration of Ian Bicking's WebTest
Package: wnpp Severity: wishlist Owner: Kathara Sasikumar X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-webtest Version : 1.9.12 Upstream Contact: Mikhail Korobov * URL : https://github.com/django-webtest/django-webtest * License : Expat Programming Lang: Python Description : Instant integration of Ian Bicking's WebTest App for instant integration of Ian Bicking's WebTest (http://docs.pylonsproject.org/projects/webtest/) with Django's testing framework. Intent to package this within the DPT. - kathara
Bug#1095772: ITP: golang-github-compose-spec-compose-go -- Reference library for parsing and loading Compose YAML files
Package: wnpp Severity: wishlist Owner: Nicolas Peugnet * Package name: golang-github-compose-spec-compose-go Version : 2.4.7-1 Upstream Author : Compose Specification * URL : https://github.com/compose-spec/compose-go * License : Apache-2.0 Programming Lang: Go Description : Reference library for parsing and loading Compose YAML files Go reference library for parsing and loading Compose files as specified by the Compose specification (https://github.com/compose-spec/compose-spec). . Used by . * compose (https://github.com/docker/compose) * containerd/nerdctl (https://github.com/containerd/nerdctl) * compose-cli (https://github.com/docker/compose-cli) * tilt.dev (https://github.com/tilt-dev/tilt) * kompose (https://github.com/kubernetes/kompose) * kurtosis (https://github.com/kurtosis-tech/kurtosis/) * testcontainers-go's Compose module (https://github.com/testcontainers/testcontainers- go/tree/main/modules/compose) * compose2nix (https://github.com/aksiksi/compose2nix) * Defang (https://github.com/DefangLabs/defang) * score-compose (https://github.com/score-spec/score-compose) * CasaOS (https://github.com/IceWhaleTech/CasaOS) This is a dependency of docker-buildx (Bug#989917) and other docker related packages.
Re: Heimdal Bugs re update-alternatives
Le 10/02/2025 à 18:59, Russ Allbery a écrit : It's unfortunate that the commands have the same names in both Kerberos distributions, although it's understandable from a user UI perspective. I don't have a good solution. Either using alternatives or not using alternatives runs some risk of breaking things. I think I'd lean towards using alternatives for kadmin because I think anyone installing both kadmin client packages probably knows what they're doing and can cope, but technically it is a policy violation because the two commands do not implement the same interface. You might use alternatives with 3 implementations: a) one for Heimdal b) one for MIT kerberos c) one with a script that automatically calls Heimdal or MIT kerberos if only one of them is available but that fails if both are installed (or none) In the latter case (both installed), you might wish to add a way (envvar, config, extra parameter, etc) to let the user choose an implementation instead of failing. a and b would recommends c (that would have a higher priority in the alternative system) With such setup, installing only one implementation would be transparent (same behavior as before, kadmin referring to the only installed implementation). This can be archived with c installed or not. But with both installed (unusual but want-to-be-supported setup), with default setup (i.e. recommended packages installed), the user has to explicitly choose its implementation, either by calling directly the good binary (other name or in an other path), or by configuring the new script to run the explicitly chosen version. An admin would also be able to use the alternative system to choose (system-wide) the default kadmin implementation (with c installed or not) Regards Vincent
Re: Heimdal Bugs re update-alternatives
On Mon, Feb 10, 2025 at 09:59:26AM -0800, Russ Allbery wrote: > As someone who used to have to regularly deal with multi-implementation > Kerberos setups, I can confirm that there is a real need to be able to > install the Heimdal clients and the MIT clients (including kadmin) at the > same time. This is something that people have been asking for constantly > for over a decade and it would be great to accomplish it. Yes, on clients that's fine, and it should work (with all the caveats you mentioned). But the bug is about KDC packaging scripts failing if kadmin from the other implementation is installed. > I don't think anyone wants to mix implementations on the KDC itself. Exactly - that's why making the KDC package Conflicts: with the other implementation would be a quick fix. There aren't many KDC implementations, and I think Shishi does not use kadmin (I'm not sure, I never used it), so maintaining such Conflicts: does not sound like a big burden. Regards, Gabor
chroot-debianizer - Tool that automates routine work with Debian packages.
Hi, Dear Debian Engineers. I hope this message finds you well. Sorry for advertising my small project. I use this script often when working with Debian packages. I wrote a script called chroot-debianizer that automates routine tasks related to Debian package management. This tool is designed to facilitate a clean and isolated package building process in chroot environments specifically for the amd64 architecture. chroot-debianizer serves as a wrapper around existing tools like pbuilder, pdebuild, and debootstrap, streamlining them into a single workflow. After building a package, the tool runs various utilities such as lintian, blhc, lrc, duck, etc, to ensure that the package meets Debian Policy standards and is free from common issues. Personally, I'm too lazy to constantly launch them manually, so I wrote them into one script and made it more automated. I am reaching out to seek your feedback on whether this tool might be useful for maintainers like yourselves. Your insights would be invaluable in further refining its functionality and ensuring it meets the needs of the Debian community. Thank you for your time and consideration. I look forward to hearing your thoughts. Maybe there is already a cooler solution? but I don't know about it. Link: https://github.com/iikrllx/chroot-debianizer --- Regards, Kirill Rekhov GPG Fingerprint: 2640 769D FDA1 AAA0 F863 D1AE 5F2C 5905 519C E0A0 -BEGIN PGP SIGNATURE- iQIzBAABCgAdFiEEJkB2nf2hqqD4Y9GuXyxZBVGc4KAFAmerkDEACgkQXyxZBVGc 4KAY0RAAhHJmwksMo1hnoAXptaZUvMFDEdFDaV0CjB34gds1eLOrvBs7+511HbWf eCANboF1c5CDwHzTCyJAM5GajCWrqyng7LRbAZzzZHXcSE31XU+sd9mk9PRkzeOo 3kNRQYjGXFtEkkpJckBae4oUI4CQnWaoFA2+bDq6j9gSCmazXVq9U6AbOe6/AR1K i4C+Yn0EvsHSG/UBShu8QHCPTkye3z6ZBxnMzCClHG/pTTWwcb2+4Uc9Nlurwj60 zFTtpwYQ3T53SV0vtdT7V2Z3lbS/4igpcpSP/N8iCxKDScKquJUL5BaV5BWvVPOF PIQFXTok3CyYbtZe4dTzdsbOQqe2pGnPq1MPehCSItF71B3EVRQAO9tvYhkSF6o7 gWbIsAKN10Pt7KnuZvmqTuajIiRejj63O5016XENtLgx1Y3rdrFHt7Pj78Xd9XOc 2AmQqT/XllObklmn38ny1mdtd4jONWKlzLuzd1Bc+34OyyRRYNjXTA6uY4C2v3lM anrp2i0iqONHI+swdUSs+s5nGafvY0CwGmGJFxA/tGGPDD8qfakCfUYeuLk9bdUg K5IGa3oeutysPyrvkTqx2mG5qpTvIHl4Fz7qw5gJ0akbbBFn017hzZKbiBTjkHj4 YEeukfF7JRPtER3GSm7SSt2FNV7l3zJEfmLwz9MEjoqZpVrOdfc= =zZSY -END PGP SIGNATURE-
Bug#1095796: ITP: emacs-peg -- Parsing Expression Grammars for Emacs Lisp
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-peg Version : 1.0.1 Upstream Author : Helmut Eller * URL or Web page : https://elpa.gnu.org/packages/peg.html * License : GPL-3+ Programming lang: Emacs Lisp Description : Parsing Expression Grammars for Emacs Lisp This package implements Parsing Expression Grammars for Emacs Lisp. . Parsing Expression Grammars (PEG) are a formalism in the spirit of Context Free Grammars (CFG) with some simplifications which makes the implementation of PEGs as recursive descent parsers particularly simple and easy to understand [Ford, Baker]. PEGs are more expressive than regexps and potentially easier to use. This package is a dependency of newer emacs-pg-el versions. I intend to maintain this package under the Debian Emacsen team umbrella. I'll need a sponsor for the initial upload. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: What is going on with atomics?
Hi, On 2/10/25 18:48, Johannes Schauer Marin Rodrigues wrote: I understand from the other mails that this architecture-check is not even needed and that --as-needed will let the linker do the right thing. I still like to special-case the only arch where this seems to be needed. It's not needed on RISC-V? Whoa. I gave up on hoping that onetbb fixes it as neither upstream nor the Debian bug show any activity, so I'm patching my own package instead. FWIW if the offending code is inlined into your package, then there isn't much they can do to fix it. /usr/bin/ld: unrecognized option '--push-flags' You probably meant --push-state and --pop-state instead? Yes, indeed. Simon
Re: What is going on with atomics?
Quoting Johannes Schauer Marin Rodrigues (2025-02-10 10:48:35) > Quoting Simon Richter (2025-01-17 11:43:39) > > In my own packages, I check if libatomic exists, and if it does, I > > unconditionally link if I use any atomics. I also check if the linker > > accepts > > --push-flags, if it does I generate a > > -Wl,--push-flags,--as-needed,-latomic,--pop-flags sequence, if not, the > > unconditional link will generate dpkg-shlibdeps warnings about unnecessary > > linking on amd64, but that's better than failing on other platforms. > > thank you for your help! I now patched vcmi with snippets like this: > > if (CMAKE_LIBRARY_ARCHITECTURE STREQUAL "arm-linux-gnueabi") > target_link_options(vcmi PRIVATE > "-Wl,--push-flags,--as-needed,-latomic,--pop-flags") > endif() > > I understand from the other mails that this architecture-check is not even > needed and that --as-needed will let the linker do the right thing. I still > like to special-case the only arch where this seems to be needed. I gave up on > hoping that onetbb fixes it as neither upstream nor the Debian bug show any > activity, so I'm patching my own package instead. > > But then I get the complaint: > > /usr/bin/ld: unrecognized option '--push-flags' > > You probably meant --push-state and --pop-state instead? probably related to how to correctly link against atomic with CMake I have another follow-up question. Adding the above target_link_options() to the relevant shared libraries indeed does the trick. But for my package vcmi, I also seem to need it for an executable. Unfortunately, when I apply the same recipe, I get this: [100%] Linking CXX executable ../bin/vcmiclient cd /build/reproducible-path/vcmi-1.6.5+dfsg/obj-arm-linux-gnueabi/clientapp && /usr/bin/cmake -E cmake_link_script CMakeFiles/vcmiclient.dir/link.txt --verbose=1 /usr/bin/c++ -g -O2 -ffile-prefix-map=/build/reproducible-path/vcmi-1.6.5+dfsg=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wpointer-arith -Wuninitialized -Wmismatched-tags -Wno-unused-parameter -Wno-switch -Wno-reorder -Wno-sign-compare -Wno-varargs -Wl,-z,relro -Wl,-z,now -Wl,--push-state,--as-needed,-latomic,--pop-state -Wl,--dependency-file=CMakeFiles/vcmiclient.dir/link.d CMakeFiles/vcmiclient.dir/StdInc.cpp.o CMakeFiles/vcmiclient.dir/EntryPoint.cpp.o -o ../bin/vcmiclient -Wl,-rpath,"\$ORIGIN" ../bin/libvcmiclientcommon.a ../bin/libvcmiservercommon.a ../bin/libvcmi.so /usr/lib/arm-linux-gnueabi/libminizip.so /usr/lib/arm-linux-gnueabi/libz.so /usr/lib/arm-linux-gnueabi/libtbb.so.12.14 -ldl -lrt /usr/lib/arm-linux-gnueabi/libboost_filesystem.so.1.83.0 /usr/lib/arm-linux-gnueabi/libboost_program_options.so.1.83.0 /usr/lib/arm-linux-gnueabi/libboost_locale.so.1.83.0 /usr/lib/arm-linux-gnueabi/libboost_thread.so.1.83.0 /usr/lib/arm-linux-gnueabi/libboost_atomic.so.1.83.0 /usr/lib/arm-linux-gnueabi/libboost_chrono.so.1.83.0 /usr/lib/arm-linux-gnueabi/libboost_date_time.so.1.83.0 /usr/lib/arm-linux-gnueabi/libSDL2_image.so /usr/lib/arm-linux-gnueabi/libSDL2_mixer.so /usr/lib/arm-linux-gnueabi/libSDL2_ttf.so /usr/lib/arm-linux-gnueabi/libSDL2.so /usr/lib/arm-linux-gnueabi/libavutil.so /usr/lib/arm-linux-gnueabi/libswscale.so /usr/lib/arm-linux-gnueabi/libavformat.so /usr/lib/arm-linux-gnueabi/libavcodec.so /usr/lib/arm-linux-gnueabi/libswresample.so /usr/bin/ld: ../bin/libvcmiclientcommon.a(SDLImageScaler.cpp.o): undefined reference to symbol '__atomic_fetch_add_8@@LIBATOMIC_1.0' /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/14/libatomic.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status I suspect that the problem is the order in which the -latomic is added to the linker flags? Because if instead of target_link_options() with push and pop-state I just use target_link_libraries(vcmiclient PRIVATE atomic) Then that will add a -latomic right after ../bin/libvcmiclientcommon.a and then the build succeeds. Here is the relevant CMakeLists.txt: https://sources.debian.org/src/vcmi/1.6.5%2Bdfsg-1/clientapp/CMakeLists.txt/#L38 So what is the canonical way to achieve the desired result with CMake? Will I instead have to globally set LDFLAGS="-Wl,--as-needed"? Thanks! cheers, josch signature.asc Description: signature
Re: What is going on with atomics?
Hi, On 2/12/25 13:38, Johannes Schauer Marin Rodrigues wrote: ["DSO missing from command line"] I suspect that the problem is the order in which the -latomic is added to the linker flags? Yes. Because if instead of target_link_options() with push and pop-state I just use target_link_libraries(vcmiclient PRIVATE atomic) Then that will add a -latomic right after ../bin/libvcmiclientcommon.a and then the build succeeds. Yes, that is the correct approach -- that target is dependent on libatomic. So what is the canonical way to achieve the desired result with CMake? Will I instead have to globally set LDFLAGS="-Wl,--as-needed"? On Debian, that is default already, which is very annoying when working around #1002981 -- I need to add [[maybe_unused]] volatile int (*hack)(Display, char const *) = XMissingExtension; to force a symbol reference from my code to libXext and avoid unloading libXext before my program exits. The --push-state logic is more useful for sending upstream. Simon
Bug#1095775: ITP: libjwt14 -- The C JSON Web Token Library +JWK +JWKS
Package: wnpp Severity: wishlist Owner: Ben Collins X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libjwt14 Version : 3.0.0 Upstream Contact: Ben Collins * URL : https://libjwt.io * License : MPL-2.0 Programming Lang: C Description : The C JSON Web Token Library +JWK +JWKS libjwt is a library which allows you to encode and decode JSON Web Tokens (JWT). JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. It also included JSON Web Key and JSON Web Key Set support. -- Debian currently has libjwt-2.x. The v3 of LibJWT is incompatible with the API/ABI of previous versions, so it should be packaged separately. This will allow packages that use v2 to migrate to the new API. This new version also has more functionality with JSON Web Keys. -- I plan to package and maintain it myself. I have packaging completed that passes lintian. https://github.com/benmcollins/libjwt/tree/debian/unstable -- Ben Collins https://libjwt.io https://github.com/benmcollins -- 3EC9 7598 1672 961A 1139 173A 5D5A 57C7 242B 22CF signature.asc Description: PGP signature
Bug#1095781: ITP: golang-github-docker-cli-docs-tool -- Utilities to generate (reference) documentation for the docker CLI
Package: wnpp Severity: wishlist Owner: Nicolas Peugnet * Package name: golang-github-docker-cli-docs-tool Version : 0.8.0-1 Upstream Author : Docker * URL : https://github.com/docker/cli-docs-tool * License : Apache-2.0 Programming Lang: Go Description : Utilities to generate (reference) documentation for the docker CLI This is a library containing utilities to generate (reference) documentation for the docker CLI (https://github.com/docker/cli) on docs.docker.com (https://docs.docker.com/reference/). It is also capable of generating manual pages. It is a dependency of docker-buildx (Bug#989917), and docker-cli >= 27.0.
