Bug#1077244: ITP: rust-trawld -- Daemon for storing and managing configuration resources
Package: wnpp Severity: wishlist Owner: Soumya Ranjan Patniak X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-trawld Version : 0.2.7 Upstream Author : Soumya Ranjan Patnaik * URL : https://github.com/regolith-linux/trawl * License : Apache-2.0 Programming Lang: Rust Description : Daemon for storing and managing configuration resources Trawl is the resource manager the Regolith Desktop Environment uses to manage configurations on the Wayland session. It is supposed to be an independent session replacement for xrdb. trawld is a simple daemon that stores these configuration resources and provides a DBus interface which allows clients (notably trawldb and trawlcat) to manage these resources. I intend to package rust-trawld. This package will be maintained within the debian rust team. Thanks, Soumya Ranjan Patniak
Bug#1077245: ITP: python-fnv-hash-fast -- fast version of fnv1a
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-fnv-hash-fast Version : 0.5.0 Upstream Contact: J. Nick Koston * URL : https://github.com/bdraco/fnv-hash-fast * License : Expat Programming Lang: Python Description : fast version of fnv1a This package provides a Python library which is a fast version of fnv1a. It use a CPP implementation of fnv1a (32) if cython is available, and will fallback to pure python from the fnvhash package if it is not. I intend to maintain this package in the Home Assistant team.
Bug#1077280: ITP: dotmap -- Dot access dictionary with dynamic hierarchy creation and ordered iteration
Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: dotmap Version : 1.3.8 Upstream Authors: Chris Redford URL : https://github.com/drgrib/dotmap * License : MIT Description : Dot access dictionary with dynamic hierarchy creation and ordered iteration This is a dot-access dict subclass that - has dynamic hierarchy creation (autovivification) - can be initialized with keys - easily initializes from dict - easily converts to dict - is ordered by insertion . This package installs the library for Python 3.
Bug#1077283: ITP: surge-xt -- Subtractive hybrid synthesizer
Package: wnpp Severity: wishlist Owner: Tiago Bortoletto Vaz X-Debbugs-Cc: debian-devel@lists.debian.org, ti...@debian.org * Package name: surge-xt Version : 1.3.2 Upstream Contact: Paul Walker et al. * URL : https://surge-synthesizer.github.io/ * License : GPL3 Programming Lang: C, C++ Description : Subtractive hybrid synthesizer Featuring many synthesis techniques, a great selection of filters, a flexible modulation engine, a smorgasbord of effects, and modern features like MPE, microtuning (with MTS-ESP support!), and comprehensive Open Sound Control (OSC) support. 3 oscillators per scene, with 12 versatile oscillator algorithms: Classic, Modern, Wavetable, Window, Sine, FM2, FM3, String, Twist, Alias, S&H Noise and Audio Input. Two filter units in 8 different configurations, with feedback loop available in 7 of them. 12 LFO units available, 6 are per voice and 6 are global for the whole scene. 16 effect units arranged as 4 inserts per scene, 4 sends and 4 master effects.
Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi all, I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages". Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn This would have been a great topic to discuss in person at DebConf, but unfortunately I can't attend this year, so I'll just kick this off on the mailing list. This is continuation to the 'single maintainership' discussions earlier this year. I also think that more unified and open collaboration processes could help decrease maintainer burnout, lower barrier for existing and new maintainers to help with multiple packages, and overall perhaps also improve quality of uploads by having more attention on the source code prior to upload. If you think this proposal makes sense, please press the thumbs up button. If you have comments, please share them here or on the draft itself. Thanks, Otto
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi Otto, Quoting Otto Kekäläinen (2024-07-28 00:38:40) > Hi all, > > I have drafted a new DEP at > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > Enable true open collaboration on all Debian packages". > > Direct link to raw text: > https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn > > This would have been a great topic to discuss in person at DebConf, but > unfortunately I can't attend this year, so I'll just kick this off on the > mailing list. > > This is continuation to the 'single maintainership' discussions earlier > this year. I also think that more unified and open collaboration processes > could help decrease maintainer burnout, lower barrier for existing and new > maintainers to help with multiple packages, and overall perhaps also > improve quality of uploads by having more attention on the source code > prior to upload. > > If you think this proposal makes sense, please press the thumbs up button. > > If you have comments, please share them here or on the draft itself. I like how Debian discussions are email-based. It means less work depends on being online. I can read conversations without worrying about tolls on network activities, and can search my private archive of historical conversations however I want to set that up (e.g. using notmuch). DEP-18 mandates (or more accurately it "should-ifies") web-based conversations. Not for bugs, specifically, but for other conversations where I consider Debbugs and mailinglists as reasonable alternatives. (yes, I understand that some disagree with me, and find email clumsy and Salsa web interfaces far better). In section 4, we "should" enable discussion and review of merge requests as web-based Salsa conversations, which means those conversations will not happen on mailinglists or in Debbugs. That section also says that there is no pressure on the maintainer to engage in those conversations, it is all about letting others contribute, but it is in the best case confusing for contributors if their contributions are ignored, and more likely that is perceived as quite rude behaviour of the maintainer. To not accidentally come across as rude, I have consistently enabled only the ability to *fork* but disabled all other more "chatty" features because while I *do* want "true collaboration", I dislike the web-based conversation platform offered as part of Salsa, and unfortunately Salsa cannot be told to redirect to anywhere else, so the best I can do to signal "I am not hanging out here, please look for me elsewhere" is to turn those features off. Sorry, but I disagree that the only true collaboration is Salsa-rich collaboration. Where are my options to mirror the data at Salsa, as I can do with mailinglists and Debbugs, to work with it also offline? Regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1077297: ITP: golang-github-catppuccin-go -- Soothing pastel library for Go
Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name: golang-github-catppuccin-go Version : 0.2.0-1 Upstream Author : Catppuccin * URL : https://github.com/catppuccin/go * License : Expat Programming Lang: Go Description : Soothing pastel library for Go Pastel-themed color scheme tailored for Go developers. It features a soft color palette to reduce eye strain, consistent design across platforms, and customization options to fit individual preferences.
Bug#1077300: ITP: golang-github-charmbracelet-huh -- Build interactive forms and prompts in the terminal
Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name: golang-github-charmbracelet-huh Version : 0.5.2-1 Upstream Author : Charm * URL : https://github.com/charmbracelet/huh * License : Expat Programming Lang: Go Description : Build interactive forms and prompts in the terminal The huh library features different input types like single line, multi-line text, selectable options, and confirm actions. The tool is also accessible, offering a special mode for screen readers that replaces text-based user interfaces with standard prompts, enhancing usability for visually impaired users. . Additionally, it supports a theming system, allowing users to choose from predefined themes like Charm, Dracula, Catppuccin, Base 16, or create their own.
Bug#1077301: ITP: fyi -- FYI (for your information) is a command line utility to send desktop notifications to the user via a notification daemon implementing XDG desktop notifications.
Package: wnpp Severity: wishlist Owner: Birger Schacht X-Debbugs-Cc: debian-devel@lists.debian.org, bir...@debian.org * Package name: fyi Version : 1.0.1 Upstream Contact: Daniel Eklöf * URL : https://codeberg.org/dnkl/fyi * License : MIT Programming Lang: C Description : FYI (for your information) is a command line utility to send desktop notifications to the user via a notification daemon implementing XDG desktop notifications. FYI (for your information) is a command line utility to send desktop notifications to the user via a notification daemon implementing XDG desktop notifications. It is a almost a notify-send clone, with the following differences: * notify-send does not implement --close. * notify-send does not expose activation tokens (needed for window focus/activation) in any meaningful way. It prints it as a debug message when G_MESSAGES_DEBUG=all; fyi prints it when you use --print-token. * fyi has consistent syntax in its --action and --hintoptions. * fyi can print the reason a notification was closed, with --print-reason. * fyi can query the notification daemon for its name and version information. * fyi can query the notification daemon for its capabilities. * fyi has shell completions (though only fish for now). * fyi has a single run-time dependency: dbus (the original D-Bus implementation).
