Bug#1103876: ITP: golang-github-natefinch-atomic -- atomic is a go package for atomic file writing
Package: wnpp Severity: wishlist Owner: Taavi Väänänen * Package name: golang-github-natefinch-atomic Version : 1.0.1-1 Upstream Author : Nate Finch * URL : https://github.com/natefinch/atomic * License : Expat Programming Lang: Go Description : atomic is a go package for atomic file writing atomic is a go package for atomic file writing . By default, writing to a file in go (and generally any language) can fail partway through... you then have a partially written file, which probably was truncated when the write began, and bam, now you've lost data. . This go package avoids this problem, by writing first to a temp file, and then overwriting the target file in an atomic way. This is easy on linux, os.Rename just is atomic. However, on Windows, os.Rename is not atomic, and so bad things can happen. By wrapping the windows API moveFileEx, we can ensure that the move is atomic, and we can be safe in knowing that either the move succeeds entirely, or neither file will be modified. This is an indirect dependency of anubis (ITP #1102132). I plan to maintain this under the Go team umbrella.
Re: Explicitly depending on Essential packages (was: Dropping awk?)
On Sun Apr 20, 2025 at 11:34 PM BST, Adrian Bunk wrote: While this might sound good in theory, in practice it would be horrible. As an example, libc6 It's a good example of something that could be a problem and would need careful attention, but an essential library, and in particular libc6, doesn't likely reflect the experience that we'd have for the vast majority of packages. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Bug#1103875: ITP: golang-github-a-h-templ -- A language for writing HTML user interfaces in Go.
Package: wnpp Severity: wishlist Owner: Taavi Väänänen Control: block 1102132 by -1 * Package name: golang-github-a-h-templ Version : 0.3.857-1 Upstream Author : Adrian Hesketh * URL : https://github.com/a-h/templ * License : Expat Programming Lang: Go Description : A language for writing HTML user interfaces in Go. An HTML templating language for Go that has great developer tooling. This is a dependency of anubis (ITP #1102132). I plan to maintain this under the Go team umbrella.
Bug#1101932: RFP: python-odfdo -- library and scripts for manipulating OpenDocument format (ODF) files
Package: wnpp Followup-For: Bug #1101932 Owner: broder X-Debbugs-Cc: debian-devel@lists.debian.org
Bug#1101932: RFP: python-odfdo -- library and scripts for manipulating OpenDocument format (ODF) files
Package: wnpp Followup-For: Bug #1101932 Owner: broder X-Debbugs-Cc: debian-devel@lists.debian.org I would like to pack this
Bug#1103880: ITP: python-django-pgbulk -- Django functions for doing native PostgreSQL bulk upserts
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-django-pgbulk Version : 3.2.2 Upstream Contact: Wes Kendall * URL : https://github.com/AmbitionEng/django-pgbulk * License : BSD-3-clause Programming Lang: Python Description : Django functions for doing native PostgreSQL bulk upserts django-pgbulk provides functions for doing native Postgres bulk upserts (i.e. UPDATE ON CONFLICT), bulk updates, and COPY FROM. Bulk upserts can distinguish between updated/created rows and ignore unchanged updates. Bulk updates are true bulk updates, unlike Django's bulk_update which can still suffer from O(N) queries and can create poor locking scenarios. Bulk copies can significantly speed-up bulk inserts, sometimes by an order of magnitude over Django's bulk_create. I intend to package this because it's a dependency of new versions of python-django-pgtrigger, which we use in debusine; but it seems like a useful thing to have anyway. I'll maintain it within the Debian Python Team. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1103884: ITP: python-mcstasscript -- Python API for creating and running McStas/McXtrace instruments
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team Owner: Roland Mas Severity: wishlist * Package name: python-mcstasscript Version : 0.0.46 Upstream Contact: Mads Bertelsen * URL : https://github.com/PaNOSC-ViNYL/McStasScript * License : BSD-3-Clause Programming Lang: Python Description : Python API for creating and running McStas/McXtrace instruments This is a prototype for an API that allow interaction with McStas through an interface like Jupyter Notebooks created under WP5 of PaNOSC.
Bug#1103886: ITP: python-libpyvinyl -- python APIs for Virtual Neutron and x-raY Laboratory
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team Owner: Roland Mas Severity: wishlist * Package name: python-libpyvinyl Version : 1.2.0 Upstream Contact: Mads Bertelsen * URL : https://github.com/PaNOSC-ViNYL/libpyvinyl * License : LGPL-3+ Programming Lang: Python Description : python APIs for Virtual Neutron and x-raY Laboratory The aim of _libpyvinyl_ is to provide a high level neutron and X-ray simulation API. With this harmonized user interface we achieve seamless interoperability of individual simulations thereby facilitating the concatenation of simulation steps into a simulation pipeline. The vast differences with respect to parameter names, unit conventions, configuration syntax, i.e. the user interface, is, hence, overcome creating a libpyvinyl compliant API for each simulation software.
Bug#1103904: ITP: pwvucontrol -- pipewire volume control
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org, debian-gtk-gn...@lists.debian.org, werdah...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pwvucontrol Version : 0.4.9 Upstream Contact: saivert * URL : https://github.com/saivert/pwvucontrol * License : GPL-3+ Programming Lang: Rust Description : pipewire volume control pwvucontrol is a GUI application to control pipewire sinks/sources (similar to pavucontrol). It features volume control, mute, media name display, card profile selection, port selection for sinks and sources and more. Currently, this is blocked by https://github.com/arcnmx/wireplumber.rs/issues/35 unfortunately. best, werdahias -BEGIN PGP SIGNATURE- iIsEARYKADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCaAfQpxUcd2VyZGFoaWFz QGRlYmlhbi5vcmcACgkQ7L7btge5sr52pQEAmaxWmMtXRidlKYGFRnwK5eP2ZJ2j YY9zlwZk/RHgVaQA/3lIXj1PknYcmZRKBkg6kxw1H+Ja6ryifVwUqVhJMpgD =20d/ -END PGP SIGNATURE-
Re: Troubleshooting experimental build - how to replicate the sbuild?
On Monday, April 21, 2025 2:46:27 a.m. Central Daylight Saving Time Johannes Schauer Marin Rodrigues wrote: > > I also can't figure out how to examine the chroot after a failure: > > using "-- > > purge=successful" doesn't work with unshare. > > I usually use --anything-failed-commands=%s which gives you a shell that > you can use to investigate the build independent of the chroot backend. That was the hint I needed, many thanks. I was able to confirm that the cmake configuration was identical when using the unshare backend. So I started looking at the sources. I have managed to solve this by adding an #include in one of the files. To me, this looks like a true bug in ITK so I am completely baffled by why it works in a regular build -- or with the schroot backend of sbuild. I also confirmed that the previously uploaded version of ITK does build with both schroot and unshare backends of sbuild. I looked at the diffs and none of the changes looked suspicious -- indeed the code that was failing wasn't even changed. So I'll take the win of a successful build, but I have no idea what the root cause was. As ever - very grateful for the suggestions received here! Regards, -Steve signature.asc Description: This is a digitally signed message part.
Bug#1103933: ITP: paper-clip -- PDF metadata editor for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:paper-clip Owner: jeremy.bi...@canonical.com Package Name: paper-clip Version: 5.5.1 Upstream Author: Diego Iván License: GPL-3+ Programming Lang: Vala Description: PDF metadata editor for GNOME Paper Clip is a simple GNOME app for editing metadata in PDF documents. It can edit the Title, Author, Creation Software, Keywords, and more. . Paper Clip is a GNOME Circle app. Other Info -- This package will be maintained by the Debian GNOME team. Packaging will be at https://salsa.debian.org/gnome-team/paper-clip The upstream source is at https://github.com/Diego-Ivan/Paper-Clip See https://circle.gnome.org/ for more information about GNOME Circle. Thanks, Jeremy Bícha
Re: POSIX sh compatibility (Re: Dropping awk?)
Hello, On Sat 19 Apr 2025 at 11:42am -04, Michael Stone wrote: > You happened to pick two of the most compatible OSs--it's not hard to > be portable between linux & freebsd *by accident* as there's a long > history of cross-pollination between them. (E.g., coreutils routinely > looks to see what parameters freebsd used when implementing a new > feature.) Fair point, though, I also use these programs on some NetBSD systems, and my experience was that until I started paying attention to POSIX I was continually using various features that weren't present over there. > Expand the problem set to include running on SunOS and AIX and OSX and > QNX and ... and the problem becomes much harder. But if you don't care > about all those oddballs, why limit yourself to POSIX--whose point was > to try to enable that degree of cross-platform interoperability? > [...] > It's just one of those things where regardless of what standard you > are writing to, you still need to check to see how reality matches the > standard. The nature of these particular programs is that I might want to be able to run them on those platforms in the future. If I've already stuck to POSIX when writing them, then porting them to those more difficult platforms should be much easier. I'm a big fan of not putting up barriers to making programs portable in the future, even if you haven't gone to the effort of really making sure they're portable yet. Also, I have to admit, I found it a lot of fun trying to figure out how to make these programd performant enough with only POSIX facilities. -- Sean Whitton signature.asc Description: PGP signature
