Bug#1095833: ITP: ctre -- Compile Time Regular Expression library in C++
Package: wnpp Severity: wishlist Owner: ha...@debian.org X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ctre Version : 3.9.0 * URL : https://github.com/hanickadot/compile-time-regular-expressions * License : Apache-2.0 Programming Lang: C++ Description : Compile Time Regular Expression library in C++ ctre is a fast compile-time regular expressions C++ library with support for matching/searching/capturing during compile-time or runtime. It is currently used by reflect-cpp. -- Thanks, Shengqi Chen
Re: Towards DEP-14 acceptance and recently proposed changes
Good morning, Le 2025-01-07 09:41, Julien Plissonneau Duquène a écrit : The MR above has additional links and descriptions of current practices. I do not have a strong preference for a choice yet so feedback would be appreciated. I've updated the merge request at [1] to replace the initial `//` proposal with a more flexible `[/][/]/` scheme that was suggested in the discussion on Salsa, e.g. instead of `debian/2/unstable` as per the initial proposal we may now have `foo2/debian/unstable` or just `2/debian/unstable`. Pros: marginally less awkward (the package version is not sandwiched anymore between the vendor and suite), suitable for transition cases where a source package is cloned (renamed), suitable for the uncommon but real cases where source packages are merged (to import histories in the merged repository). Cons: current usage is not as common as the initial proposal. Your comments are welcome, either on this list or on the MR discussion on Salsa. Cheers, [1]: https://salsa.debian.org/dep-team/deps/-/merge_requests/16 -- Julien Plissonneau Duquène
Bug#1095840: ITP: golang-github-prometheus-sigv4 -- A Go http.RoundTripper for signing requests using AWS SigV4
Package: wnpp Severity: wishlist Owner: Daniel Swarbrick X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-prometheus-sigv4 Version : 0.1.2-1 Upstream Contact: The Prometheus Authors * URL : https://github.com/prometheus/sigv4 * License : Apache-2.0 Programming Lang: Go Description : Go http.RoundTripper for signing requests using AWS SigV4 sigv4 provides an http.RoundTripper that will sign requests using Amazon Web Service's (AWS) Signature Version 4, using credentials from the default AWS credential chain. This previously existed as part of github.com/prometheus/common, but has recently been split out to its own repo. Packages which depend on this include prometheus and prometheus-alertmanager (and possibly others). I will co-maintain this package as a member of the Debian Go Packaging Team.
Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?
Hi All, Bálint Réczey ezt írta (időpont: 2025. jan. 1., Sze, 21:37): > > Hi, > > Marc Haber ezt írta (időpont: 2024. > dec. 31., K, 18:44): > > > > On Tue, Dec 31, 2024 at 10:32:09AM -0700, Soren Stoutner wrote: > > > On my system, which has a Western Digital Black SN850X NVMe (PCIe 4) > > > formatted > > > ext4, dpkg runs really fast (and feels like it runs faster than it did a > > > few > > > years ago on similar hardware). There has been much talk on this list > > > about > > > performance penalties with dpkg’s current configuration, and some > > > requests for > > > actual benchmark data showing those performance penalties. > > > > Doing fsyncs to often after tiny writes will also cause write > > amplification on the SSD. > > > > I should use eatmydata more often. > > I also use eatmydata time to time where it is safe, but sometimes I > forget, this is why I packaged the snippet to make all apt runs use > eatmydata automatically: > https://salsa.debian.org/debian/apt-eatmydata/-/blob/master/debian/control?ref_type=heads > > I'll upload it when apt also gets a necessary fix to make removing the > snippet safe: > https://salsa.debian.org/apt-team/apt/-/merge_requests/419 > > There is an equivalent simple solution for GitHub Actions as well: > https://github.com/marketplace/actions/apt-eatmydata > > I'll write a short blog post about those when apt-eatmydata gets > accepted to the archive. I could not make it for New Year's Eve, buth thanks to FTP Masters kindly accepting the package it arrived for Valentine's day. :-) https://balintreczey.hu/blog/supercharge-your-installs-with-apt-eatmydata-because-who-needs-crash-safety-anyway/ It really shines with pure data packages not triggering any extra work at install time, especially on Ubuntu, where zstd saves extraction time, too. Cheers, Balint
Re: chroot-debianizer - Tool that automates routine work with Debian packages.
On Wednesday, February 12, 2025 10:51:13 AM MST Raphael Hertzog wrote: > That sounds like what the "debian_pipeline" workflow can do in > https://debusine.debian.net, except that it is able to do it on multiple > architectures and also run reverse dependencies autopkgtest (however it > doesn't support duck nor lrc, I don't even know what lrc is...). lrc is the binary executable for licenserecon. https://tracker.debian.org/pkg/licenserecon -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1095850: ITP: ergochat -- Modern IRC server (daemon/ircd) written in Go
Package: wnpp Severity: wishlist Owner: Martina Ferrari * Package name: ergochat Version : 2.15.0+ds1-1 Upstream Author : Shivaram Lingamneni * URL : https://github.com/ergochat/ergo * License : Expat Programming Lang: Go Description : Modern IRC server (daemon/ircd) written in Go Ergo (formerly known as Oragono) is a modern IRC server written in Go. Its core design principles are: . * Being simple to set up and use * Combining the features of an ircd, a services framework, and a bouncer (integrated account management, history storage, and bouncer functionality) * Bleeding-edge IRCv3 support (https://ircv3.net/software/servers.html), suitable for use as an IRCv3 reference implementation * High customizability via a rehashable (i.e., reloadable at runtime) YAML config
Re: chroot-debianizer - Tool that automates routine work with Debian packages.
Hi, On Tue, 11 Feb 2025, Kirill Rekhov wrote: > 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. That sounds like what the "debian_pipeline" workflow can do in https://debusine.debian.net, except that it is able to do it on multiple architectures and also run reverse dependencies autopkgtest (however it doesn't support duck nor lrc, I don't even know what lrc is...). https://freexian-team.pages.debian.net/debusine/reference/workflows/specs/debian-pipeline.html We don't have any user-friendly documentation yet, i.e. tutorial-like, to show how to run those workflows but the feature is basically there already and workflows have been run: https://debusine.debian.net/debusine/System/work-request/70965/ https://debusine.debian.net/debusine/System/work-request/72260/ https://debusine.debian.net/debusine/System/workflow/?workflow_templates=build-pipeline Feel free to hang out in #debusine on IRC and ask questions if you want to try it out. Though at this point, debusine.debian.net is only usable by DD, we are considering to open it up a bit more broadly in the not too distant future. > 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. Hopefully you will find debusine cool :-) being a web service, it also means that the build happen remotely. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#1095852: ITP: golang-github-hashicorp-go-cty-funcs -- go-cty specific functions; mainly used in HCL2 templates
Package: wnpp Severity: wishlist Owner: Nicolas Peugnet * Package name: golang-github-hashicorp-go-cty-funcs Version : 0.0~git20250210.dda7798-1 Upstream Author : HashiCorp * URL : https://github.com/hashicorp/go-cty-funcs * License : MPL-2.0 Programming Lang: Go Description : go-cty specific functions; mainly used in HCL2 templates go-cty is a dynamic type system for applications written in Go that need to represent user-supplied values without losing type information. The primary intended use is for implementing configuration languages . This package provides go-cty specific functions mainly used in HashiCorp configuration language (HCL2) tamplates. This is a dependency of docker-buildx (Bug #989917).
Need advice on coordinating libkdumpfile update and introducing pykdumpfile
Dear all, libkdumpfile has recently released version 0.5.5, which despite the version number, actually contains an soname bump from 0.5.4 https://github.com/ptesarik/libkdumpfile/releases/tag/v0.5.5 See e.g. the relevant Fedora packaging change https://src.fedoraproject.org/rpms/libkdumpfile/c/c0097ea1c69462b6bb151d186ff4856663c5b7e4?branch=rawhide The soname bump is fine in itself - I'll change the name of the binary subpackage containing the shared library files, and the upload will need to be done by a full Debian Developer and subject to FTP master review (IIRC, please correct me if I'm wrong). *But* upstream also decided to drop the legacy Python bindings right after 0.5.5 is out, and instead recommending the separate pykdumpfile (which they also maintain) https://github.com/ptesarik/pykdumpfile https://src.fedoraproject.org/rpms/python-pykdumpfile So rather than keeping the Python bindings in 0.5.5 I figured might as well drop the Python bindings immediately and package the new one. This needs to be built against the correct libkdumpfile, so I'm a bit unsure about the sequencing - in Fedora my sequence was: - package the new libkdumpfile, make it obsolete the old Python subpackage so upgrades work but result in the Python subpackage being removed - then package pykdumpfile I could have done both in a side tag and avoided having a time where the Python bindings are not available, but the way Python packages are generated in Fedora, if the package name changes the virtual provides they generate change anyway, so pykdumpfile won't be a drop in replacement even though it ships exactly the same Python module names. For Debian - since we already require FTP master review for the soname bump, it seems to make even more sense to also drop the old Python bindings and avoid requiring a re-review when 0.5.6 comes out. The question is - is it OK to have unstable temporarily miss the Python bindings? And should I preserve the upgrade path or let people keep the old Python bindings? (so apt-upgrade will skip updating libkdumpfile)? Or is there a way, say build the new libkdumpfile in experimental with the Python bindings disabled, get the new pykdumpfile reviewed and also built in experimental, then get them both promoted to unstable? Thanks in advance, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README signature.asc Description: PGP signature
Bug#1095857: ITP: golang-github-xuanwo-go-locale -- Cross platform locale detection for Golang
Package: wnpp Severity: wishlist Owner: Nick Morrott X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-xuanwo-go-locale Version : 1.1.3 Upstream Contact: Xuanwo * URL : https://github.com/Xuanwo/go-locale * License : Apache-2.0 Programming Lang: Go Description : Cross platform locale detection for Golang go-locale supports looking up a number of locale environment variables and files on POSIX-compatible systems. It can lookup the following locale variables: - LANGUAGE - LC_ALL - LC_MESSAGES - LANG and can read the following locale files: - $XDG_CONFIG_HOME/locale.conf - $HOME/.config/locale.conf - /etc/locale.conf This package is a new dependency of lf (#1095599) and will be maintained within the Debian Go Packaging Team. -- Kind regards, Nick Morrott
