Bug#1011557: ITP: pagmo -- library for massively parallel optimisation
Package: wnpp Severity: wishlist Owner: Pierre Gruet User: debian-scie...@lists.debian.org Usertags: field..science X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: pagmo Version : 2.18.0 Upstream Author : Francesco Biscani * URL : https://github.com/esa2/pagmo * License : GPL-3+ or LGPL-3+ Programming Lang: C++ Description : library for massively parallel optimisation pagmo is a C++ scientific library built around the idea of providing an unified interface to optimization algorithms and to optimization problems and to make their deployment in massively parallel environments easy. This package is needed as a dependency of openturns, which is maintained in the Debian science team -- which I also plan to do with pagmo.
Bug#1011552: ITP: python-exceptiongroup -- backport of the BaseExceptionGroup and ExceptionGroup classes from Python 3.11
Package: wnpp Severity: wishlist Owner: Agathe Porte X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, deb...@microjoe.org * Package name: python-exceptiongroup Version : 1.0.0~rc7 Upstream Author : Alex Grönholm * URL : https://github.com/agronholm/exceptiongroup * License : MIT + PSFLv2 Programming Lang: Python Description : backport of the BaseExceptionGroup and ExceptionGroup classes from Python 3.11 This library contains backport of BaseException for Python versions before 3.11. Since 3.11 is not released yet and that new software [1] is already using this compat layer, I think we should package it even in release-candidate form. [1] It is required for python-cattrs source package update. I intent to maintain this package under the umbrella of the Debian Python Team.
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Hi, On 24-05-2022 20:07, M. Zhou wrote: I wonder why an irrelevant package suddenly triggered autoremoval of a very large portion of packages from testing. https://udd.debian.org/cgi-bin/autoremovals.cgi Searched for keyword nvidia-graphics-drivers-tesla-470, and I got 68866 entries. There must be something wrong. https://bugs.debian.org/1011268 (but apparently my first assumption was wrong and it's another bug, most likely Simon was right. Paul OpenPGP_signature Description: OpenPGP digital signature
questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
I wonder why an irrelevant package suddenly triggered autoremoval of a very large portion of packages from testing. https://udd.debian.org/cgi-bin/autoremovals.cgi Searched for keyword nvidia-graphics-drivers-tesla-470, and I got 68866 entries. There must be something wrong. https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=nvidia-graphics-drivers-tesla-470 Looking at the bug report of the package itself, and it does not look like glibc package is made broken by it. Any idea?
Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
On 2022-05-24 21:52:55, SZ Lin (林上智) wrote: > Hi, > > Antoine Beaupré 於 2022年5月19日 週四 下午10:11寫道： >> [...] >> SZ, do you agree with removing the `gh` binary from the `gitsome` binary >> package? I'd be happy to send a NMU to do this if you agree, which would >> unblock `gh` from migrating into testing. > > Yes, please go ahead :-) Great, that's really good to hear. I'm going to make a NMU and MR this very morning to solve this. Thanks for doing the right thing! -- Premature optimization is the root of all evil - Donald Knuth
Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi, Antoine Beaupré 於 2022年5月19日 週四 下午10:11寫道： > > On 2022-02-27 10:09:32, Paul Wise wrote: > > Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 > > > > On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > > > >> The "gitsome" has used "gh" since 2017, and thus would you mind renaming > >> the "gh" in your package to avoid the conflict issue? > > > > Since gh is the official GitHub client, probably it should retain "gh" > > and gitsome should move to "git some" or similar, as I have suggested > > in the above upstream issue. The only commentor there agreed with me. > > And I agree with you. The gitsome package already installs two binaries: > one is called "gh" and the other is called "gitsome". It seems to me it > could simply drop the "gh" alias and none would be the worse. > > SZ, in your February 26 message[1], you explicitly asked the gh package > maintainers to rename their package, which was refused. It seems the > concensus that has developped in the following thread is that it is > instead your package, gitsome, that should have its binary renamed. > > Pabs suggested `gitsome` could also be renamed to `git-some` which would > make it visible as a `git some` subcommand, from what I understand. It > seems like the `gh` alias is kind of an alias unrelated with the main > functionality of the package. > > SZ, do you agree with removing the `gh` binary from the `gitsome` binary > package? I'd be happy to send a NMU to do this if you agree, which would > unblock `gh` from migrating into testing. Yes, please go ahead :-) > > Otherwise, how can we reach consensus on this? The policy says that if > we can't reach consensus, *both* packages need to be renamed, and that > seems like a situation where we would all lose. > > I'll also point out that the upstream issue hasn't seen any activity > since pabs commented on it in February, so it doesn't seem like we can > count on upstream to fix this for us. The issue has been open for 2 > years now. Yeah, it seems like the upstream is inactive somehow. SZ > > Thank you for your time! > > [1]: > https://lists.debian.org/msgid-search/CAFk6z8Mw0kFHehm_a7=0bmdt6mzff03sewx+y93xy42bkq7...@mail.gmail.com > > -- > Tu connaîtras la vérité de ton chemin à ce qui te rend heureux. > - Aristote >
