Bug#1107401: ITP: python-pyinstrument -- Call stack profiler for Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyinstrument Version : 5.0.2 Upstream Contact: Joe Rickerby * URL : https://github.com/joerick/pyinstrument * License : BSD-2, BSD-3, MIT/X Programming Lang: Python Description : Call stack profiler for Python Pyinstrument is a Python profiler. A profiler is a tool to help you optimize your code - make it faster. To get the biggest speed increase you should focus on the slowest part of your program. Pyinstrument helps you find it! This package is a dependency for the test suite within src:strawberry-graphl (no ITP created yet). But also independenly from that a usefull addition to the Debain archive. strawberry-graphql is a dependency for strawberry-graphql-django that is then a dependency for NetBox >= 4.x. I plan to maintain this package within the DPT. Regards Carsten
Re: New contributor experience
On Wed, 4 Jun 2025, Marc Haber wrote: Hi, On Wed, Jun 04, 2025 at 06:22:49PM +0200, Jonas Smedegaard wrote: I suggest to instead more narrowly guide them towards *recent* *RFP* bugreports rather than WNPP bugreports in general. It will not surprise me if some newcomers find recent RFP bugreports a total waste of their time, but I know from experience that some do not. Maintaining a package is a significant commitment. I'd prefer newcomers to fix bugs instead. There it doesnt hurt when they vanish after a few months. And, when you "just" fix bugs, you don't have to the next frustrating threadmill that we offer: looking for a sponsor. Although just fixing bugs has its own frustrations. I mostly used to write "works for me" fixes and now I look to submitting to upstream first and go to the BTS if I can't quickly see how to open a bug/MR upstream. There's a patch for apt-cacher-ng for a multi-year old bug that I know is in use in at least three large deployments due to private emails. The patch could do with some TLC, the comments in particular reflect my journey of understanding rather than the final state, and had I got prompt feedback I'd have done that work but a year plus later I'd have to spend time reminding myself just what was going on - at this point anyone is as well placed as me to do that cleanup - and I'm not sure I'd bother, if there's ever a new release I'll get an alert and if there isn't well "it works for me". The BTS doesn't help either, that bug I was subscribed to, but I never got any notification of the most recent comments (which turned out to be noise anyway) A while back I fixed a number of FTBFS and usr-merge bugs in packages I care about. Those were merged, but as NMU which I found out by accident when I went looking at what was going on months later. TBH I was thinking "why bother?" although actually it should have been a positive experience. I'm not sure if I would want to be a Debian Developer. There's another package that now has fixes of mine I need upstream and the temptation to "fix" the debian package with a silent maintainer would be difficult to resist but spending hours reading documentation on how to do this officially would feel annoying when I already have a working and deployed package locally. I do have dreams of winding down my paid work and having more time for open source, and maybe I'll hope to be more than a drive-by contributor, but most of my 'Debian' time right now is making sure I'm not dependent on debian for fixes while still taking advantage of all the great work that does happen.
Re: New contributor experience
On Sat, Jun 07, 2025 at 03:46:48PM +, Tim Woodall wrote: Maintaining a package is a significant commitment. I'd prefer newcomers to fix bugs instead. There it doesnt hurt when they vanish after a few months. And, when you "just" fix bugs, you don't have to the next frustrating threadmill that we offer: looking for a sponsor. Although just fixing bugs has its own frustrations. I mostly used to write "works for me" fixes and now I look to submitting to upstream first and go to the BTS if I can't quickly see how to open a bug/MR upstream. Good, sending patches for upstream bugs upstream is always encouraged by Debian. There's a patch for apt-cacher-ng for a multi-year old bug that I know is in use in at least three large deployments due to private emails. The patch could do with some TLC, the comments in particular reflect my journey of understanding rather than the final state, and had I got prompt feedback I'd have done that work but a year plus later I'd have to spend time reminding myself just what was going on - at this point anyone is as well placed as me to do that cleanup - and I'm not sure I'd bother, if there's ever a new release I'll get an alert and if there isn't well "it works for me". apt-cacher-ng is simply almost dead upstream/unmaintained, having just one release/maintainer upload since 2021 and many open bugs, including several very well known problems affecting many people. A while back I fixed a number of FTBFS and usr-merge bugs in packages I care about. Those were merged, but as NMU which I found out by accident when I went looking at what was going on months later. TBH I was thinking "why bother?" although actually it should have been a positive experience. Not sure if this describes some problem or not. spending hours reading documentation on how to do this officially would feel annoying when I already have a working and deployed package locally. Makes sense. -- WBR, wRAR signature.asc Description: PGP signature
apt-cacher-ng (Was Re: New contributor experience)
Hi, On Sat, Jun 07, 2025 at 09:08:50PM +0500, Andrey Rakhmatullin wrote: > apt-cacher-ng is simply almost dead upstream/unmaintained, having just one > release/maintainer upload since 2021 and many open bugs, including several > very well known problems affecting many people. What are people using instead of apt-cacher-ng if I may ask? I've been using it for more than 10 years but the problems I have encountered since upgrading to its bookworm version have got a lot worse, including memory leaks, segfaults and clients that get stuck endlessly after doing an "apt update". I too had got the impression that it was basically dead and have been wondering what to replace it with. Just a general purpose caching HTTP proxy? Thanks, Andy
Re: apt-cacher-ng (Was Re: New contributor experience)
Hi, On Sat Jun 7, 2025 at 10:38 PM CEST, Andy Smith wrote: On Sat, Jun 07, 2025 at 09:08:50PM +0500, Andrey Rakhmatullin wrote: apt-cacher-ng is simply almost dead upstream/unmaintained, having just one release/maintainer upload since 2021 and many open bugs, including several very well known problems affecting many people. What are people using instead of apt-cacher-ng if I may ask? I've started using squid-deb-proxy [1] after seeing it mentioned in the apt documentation [2]. Unfortunately, it got removed from the archive a while back [3]. It still works better then apt-cacher-ng for me :) [1]: https://tracker.debian.org/pkg/squid-deb-proxy [2]: https://manpages.debian.org/testing/apt/apt-transport-http.1.en.html [3]: https://bugs.debian.org/1081589
Re: apt-cacher-ng (Was Re: New contributor experience)
Hi, I became Fedora/Redhat maintainer for this to revive it a bit and have a more efficient to feed the Debian nodes. It annoys our "security" team at work who sees plain http traffic. (No they don't know what gpg means) In https mode from my understanding there is no caching at all which defeats the purpose. I m tempted to put an nginx in front of it or drop the ball and go for the company-approved Nexus. Nexus has an open core model and maybe they are trying to do too much (.rpm, .deb, pypi...) without enough depth. Greetings Alexandre Le sam. 7 juin 2025, 22:55, Andy Smith a écrit : > Hi, > > What are people using instead of apt-cacher-ng if I may ask? > > Just a general purpose caching HTTP proxy? > > Thanks, > Andy > >
Re: apt-cacher-ng (Was Re: New contributor experience)
On Sat, Jun 07, 2025 at 08:38:09PM +, Andy Smith wrote: > Hi, > > On Sat, Jun 07, 2025 at 09:08:50PM +0500, Andrey Rakhmatullin wrote: > > apt-cacher-ng is simply almost dead upstream/unmaintained, having just one > > release/maintainer upload since 2021 and many open bugs, including several > > very well known problems affecting many people. > > What are people using instead of apt-cacher-ng if I may ask? > > I've been using it for more than 10 years but the problems I have > encountered since upgrading to its bookworm version have got a lot > worse, including memory leaks, segfaults and clients that get stuck > endlessly after doing an "apt update". I too had got the impression that > it was basically dead and have been wondering what to replace it with. > > Just a general purpose caching HTTP proxy? I've been using approx for... I don't know, maybe fifteen years or something? It has always worked mostly fine for me, and its files layout makes it easy for me to remove a file or two when I've pushed something to one of my own repos so that the clients will notice at once. The only problem I've had with it in the past years was that the approx-gc tool went away at some point; actually it was just about a week ago that I finally decided to go ahead and write my own tool for doing that; it has not been released yet (I'm still working out a couple of kinks in a couple of other Rust crates that I wrote specifically for it), but if anyone with a recent Rust compiler (yeah, sorry, even the one in Trixie-to-be won't quite do) wants to give it a go, it's at https://gitlab.com/ppentchev/unref-files I still have to write some usage documentation, but generally `unref-files [-d] [-v] approx find [--delete]` is all that is supported for now. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Need help with ITP bug#1107258 needing to vendor source code
X-Debbugs-Cc: rust-deb...@lists.debian.org Hi, i am the the author of https://bugs.debian.org/1107258 When trying to package the project, i noticed the project has to vendor a dedicated dependency (magpie) which has to vendor nvtop v3.2.0 and apply application specifc patches to try to make an api for nvtop sobit can be used as a libary. The location for the patches are in https://gitlab.com/mission-center-devs/gng/-/tree/main/platform-linux/3rdparty/nvtop/patches?ref_type=heads How should i go about this?
Bug#1107475: libasyncns: How to continue maintenance of libasyncns in Debian
Source: libasyncns Version: 0.8-6 Severity: important X-Debbugs-Cc: Tanguy Ortolo , Tanguy Ortolo , debian-devel@lists.debian.org, 862...@bugs.debian.org, 862...@bugs.debian.org, Package Salvaging Team Hi Tanguy, Your package libasyncns was highlighted in the Bug of the Day[1] initiative, which aims to introduce newcomers to manageable tasks and guide them through the workflow to solve them. The focus of this initiative is on migrating packages to Salsa, as it's a great way to familiarize newcomers with a consistent Git-based workflow. First of all, thank you for your past work on the Debian package libasyncns. According to popcon[2], usage of the package is not only steady but even increasing, which is quite remarkable for software that has not seen an upstream release in some time. I noticed that the Debian package was last uploaded in 2016, and although it has no open release-critical bugs, two bugs were reported in 2017, both with patches attached. These patches were also forwarded upstream, but given upstream appears inactive, Debian may now be the primary place where users can expect fixes. Since I haven't seen any uploads from you since 2018 and there hasn't been a response to these bug reports, I wanted to kindly ask whether you are still interested in maintaining this package. I fully understand that priorities and availability change over time — especially for volunteer work — and I don’t want to assume anything. I just want to clarify how we might ensure the package continues to get the attention it needs. As is common practice in the Bug of the Day initiative, I created a Git repository on Salsa[3] to demonstrate how the package could be modernised and the existing bugs addressed. I’ve included the suggested patches from the open bugs, though I’ve not added them in debian/patches/series to allow for further review. Please note: I do not consider this repository under the Salvage Team namespace to be the final or rightful place for ongoing maintenance. If the package continues to be maintained, I believe it should ideally move either to your preferred location or perhaps under Debian team if that seems appropriate. I'm happy to help move or remove the repository depending on your wishes. I’m also sending this message to debian-devel to raise awareness and possibly find new contributors interested in the package. If you feel that you no longer have the time or interest to maintain it, it might be helpful to mark this bug as a Request for Adoption (RFA) by retitling it accordingly. That would make the situation clearer and help with the search for a new maintainer. Alternatively, if you’re fine with someone doing a QA upload[4], that could also be a practical next step. If you are still interested in maintaining it, that’s great — and if you’d prefer to hand it over or co-maintain it, I’d be happy to help find someone willing to assist. Many thanks again for your past efforts, and looking forward to your thoughts. Kind regards Andreas. [1] https://salsa.debian.org/qa/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://qa.debian.org/popcon-graph.php?packages=libasyncns0&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 [3] https://salsa.debian.org/salvage-team/libasyncns [4] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmus-vs-qa-uploads -- System Information: Debian Release: 13.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
