Bug#975369: ITP: faiss -- library for efficient similarity search and clustering of dense vectors
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: faiss Version : 1.6.4 Upstream Author : facebook research * URL : http://www.example.org/ * License : MIT Programming Lang: C++, Python Description : library for efficient similarity search and clustering of dense vectors Will be maintained by deep learning team.
Re: move to merged-usr-only?
On Sat, 2020-11-21 at 02:01 +, Paul Wise wrote: > On Fri, Nov 20, 2020 at 7:35 PM Simon McVittie wrote: > > > Package-by-package migration touches a large number of packages > > By my count there are 1712 binary packages from X source packages > installing things outside /etc /usr /var The goal is to have /bin and /usr/bin to have identical contents. If one wishes to achieve that via symlinks for every single binaries, you not only need symlinks in /bin for binaries previously there, but moved to /usr/bin, but also for binaries that already are in /usr/bin. So one would need a new /bin/python3 -> /usr/bin/python3 symlinks in addition to the /bin/bash -> /usr/bin/bash symlink discussed here. This affects many more packages. Starting a 10-year[1] migration for the small part (move bash to /usr/bin, add /bin/bash -> /usr/bin/bash) symlink, then maybe[2] start *another* *multi-year) migration after that, and then getting there isn't a great outlook for me. (At that time migration to merged-/usr for the remaining systems would no longer be a worry either way as presumably only very few installations without merged-/usr would exist anyway and no migration would be needed, i.e., like the i386 -> amd64 cross-upgrade nobody really worries about any more.) Ansgar [1]: https://lists.debian.org/debian-devel/2018/11/msg00354.html [2]: cf. OpenSuSE or suggestions to never do that and instead wait until nobody uses /bin/sh any longer. If you suggest to do package-by-package migrations, please at least argue why Debian wouldn't end in the same in-between state as SuSE.
Bug#975366: ITP: golang-github-mendersoftware-progressbar -- Minimal progressbar used in Mender projects
Package: wnpp Severity: wishlist Owner: Lluis Campos * Package name: golang-github-mendersoftware-progressbar Version : 0.0.2-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/progressbar * License : Apache-2.0 Programming Lang: Go Description : Minimal progressbar used in Mender projects Minimal progressbar used in Mender projects. Required for the upcoming upstream update of mender-client and mender-artifact.
Re: move to merged-usr-only?
On Sat, Nov 21, 2020 at 10:33 AM Ansgar wrote: > The goal is to have /bin and /usr/bin to have identical contents. > So one would need a new /bin/python3 -> /usr/bin/python3 symlinks Those seem unnecessary to me, since we have $PATH and nothing should be using /bin/python3 at this stage. -- bye, pabs https://wiki.debian.org/PaulWise
Re: move to merged-usr-only?
On Sat, 2020-11-21 at 11:07 +, Paul Wise wrote: > On Sat, Nov 21, 2020 at 10:33 AM Ansgar wrote: > > > The goal is to have /bin and /usr/bin to have identical contents. > > So one would need a new /bin/python3 -> /usr/bin/python3 symlinks > > Those seem unnecessary to me, since we have $PATH and nothing should > be using /bin/python3 at this stage. We have $PATH, yet there are bugs that come from using `/usr/bin/rm` as mentioned in my inital mail. There is no reason to assume that the same doesn't happen in the other direction. I've already seen people using `#!/bin/python` as interpreter a long time ago (before Debian had merged-/usr by default). One can try to educate people that this is wrong because some binaries were historically only available in /usr (due to too small root disk, but a larger disk for /home), but why bother when we can just get rid of the problem and even already have done so partly? Or you can say we ignore that error class for a few more years and only address half of it and then the other half in X years. Ansgar
Bug#975404: ITP: annotation-detector -- scan class path for annotated classes, methods, or instance variables
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: annotation-detector Version : 3.0.5 Upstream Author : XIAM Solutions B.V. (http://www.xiam.nl) * URL : https://github.com/rmuller/infomas-asl * License : Apache Programming Lang: Java Description : scan class path for annotated classes, methods, or instance variables This library can be used to scan (part of) the class path for annotated classes, methods or instance variables. Main advantages of this library compared with similar solutions are: light weight (no dependencies, simple API, 20 kb jar file) and very fast (fastest annotation detection library as far as I know). I'm packaging this because it's a build dependency for openrocket, which I would like to move back from being a "jar installer" in contrib to a real build from source in main. Bdale
ik wil meedoen en een antwoord van een menselijke e-mail accoutn ?
Haloo Debian, Ik heb wat e-mails verstuur den wil nu eindelijjk meedoen maar dan moet iemand wel reageren op mijn e-mails? Groeten, Richard Waterbeek Nederland
Re: move to merged-usr-only?
On 2020-11-20 Ansgar wrote: > I would like to propose to plan to move to support merged-usr-only over > the following releases. The motivation is bugs like [1] where upstream > developers just use `/usr/bin/rm` (or other binaries, or user scripts > using /usr/bin/bash, or ...) unconditionally; this was already a > motivation to adopt merged-/usr as a default for me. > As far as I know nothing broke catastrophically over the last releases > with merged-/usr. > Alternatively, a team could form that preemptively looks at such issues > and fixes them, ideally upstream. > So a possible idea would be to: > - For Debian 12 (bookworm): make it mandatory to migrate old systems to >merged-/usr on upgrade. Possibly by allowing the existing usrmerge >program to run from the initramfs. > - For Debian 13 (trixie): packages should no longer install to /bin, >/sbin, /lib, but to the respective locations under /usr. Hello Ansgar, I am all for declaring a cutoff date (and release) which makes usrmerge mandatory and the only supported setup. (Or alternatively make usrmerge an unsupported setup.) The current state where we are trying to support both and end up dealing with fallout and cannot make real progress to the clean state (bash being shipped as /usr/bin/bash and therefore dpkg knowing about it) is a waste of developer time. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
