Bug#990389: ITP: deepin-anything -- A lightning-fast filename search feature, and provides offline search capabilities
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, luyan...@uniontech.com * Package name: deepin-anything Version : 5.0.8 Upstream Author : linux Deepin * URL : http://github.com/linuxdeepin/deepin-anything * License : GPL-2+ Programming Lang: C,C++ Description : A lightning-fast filename search feature, and provides offline search capabilities deepin-anything aims to provide Linux users with a lightning-fast filename search feature that does not rely on additional system calls and function calls and is highly efficient for finding files
Re: What are desired semantics for /etc/shells?
On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote: > It also means that on /usr-merged systems e.g. /bin/screen is not a > "valid" shell, but /usr/bin/screen is (even though they are the same > file), which may be fine in practice but seems counter-intuitive to > me. Valid concern. Do you think that I should include machinery specifically for handling the /usr merge in update-shells? Automatically adding /bin/screen on /usr-merged systems where shells.d contains /usr/bin/screen is feasible. I see little value though as /usr/bin/screen has always worked on Debian and why would anyone use /bin/screen now? > > * While the order of /etc/shells will not be sorted, it will be > >deterministic if update-shells is run after all packages have been > >unpacked. Installing two packages one after another will still cause > >their order in /etc/shells to differ, but changing the order of > >/etc/shells could break comments left by administrators. So this is a > >compromise that partially improves reproducibility without regressing > >maintainability of /etc/shells. I hope that it is sufficient in > >practice. > > Sorting /etc/shells if the only comment in it is the current > |# /etc/shells: valid login shells > on line 1 would seem acceptable to me. That seems reasonable initially, but it makes the semantics much harder to understand. You add a special case here. I think that what I proposed slightly improves reproducibility. It may not be the final solution, but it also does not make later sorting much harder. If it turns out that /etc/shells is insufficiently reproducible, we can fix update-shells and be done as it'll be run in postinst. For this reasons, I'm in favour of deferring the reproducibility aspect. I'm not making it any harder and possibly it actually becomes sufficiently reproducible for practical applications. > > for f in "$PKG_DIR/"*; do > > Would it make sense to set LC_COLLATE for deterministic ordering here? That's a good suggestion. I looked into this and things are complicated. For one thing, whether to set LC_COLLATE depends on where /bin/sh points to. When it happens to be dash, you run into #699177 and basically don't care. In any case, setting LC_COLLATE does not hurt. When it happens to be bash, LC_COLLATE doesn't have to be exported and is honoured immediately. Therefore, we should set LC_COLLATE prior to globbing even though the issue is mostly irrelevant (until #699177 is fixed). Thanks. I also confirm the typo spotted by Étienne Mollier. Thank you as well. Helmut
Bug#990420: ITP: django-cacheops -- Django app adding automatic or manual queryset caching
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-cacheops Version : 6.0 Upstream Author : Alexander Schepanovski * URL : https://github.com/Suor/django-cacheops * License : BSD-3-clause Programming Lang: Python Description : Django app adding automatic or manual queryset caching django-cacheops is a slick app that supports automatic or manual queryset caching and automatic granular event-driven invalidation. . It uses redis as backend for ORM cache and redis or filesystem for simple time-invalidated one. . And there is more to it: . * decorators to cache any user function or view as a queryset or by time * extensions for django and jinja2 templates * transparent transaction support * dog-pile prevention mechanism * a couple of hacks to make django faster This package is a dependency for netbox I consider to package. django-cacheops has build depenendency on python3-funcy which is currently waiting in the NEW queue (see ITP #989811). The package will get maintained within the Debian Python Team.
Bug#990425: ITP: notes -- Simple cli note taking utility
Package: wnpp Severity: wishlist Owner: Allison Sargente * Package name: notes Version : 1.0.0 Upstream Author : Tim Perry * URL : https://github.com/pimterry/notes * License : MIT Programming Lang: Bash Description : Simple cli note taking utility Notes is a lightweight application for creating, managing, and organizing your notes on the command line. It can be used with almost any text editor, is highly configurable, and can be used in a variety of ways to make your note taking easier. For reference: - I'm currently looking for a sponsor/mentor - I'm a maintainer of this project - I personally use this software, it solves a need for me and others.
Re: What are desired semantics for /etc/shells?
* Helmut Grohne [2021-06-28 14:46]: > On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote: > > It also means that on /usr-merged systems e.g. /bin/screen is not a > > "valid" shell, but /usr/bin/screen is (even though they are the same > > file), which may be fine in practice but seems counter-intuitive to > > me. > > Valid concern. Do you think that I should include machinery specifically > for handling the /usr merge in update-shells? Automatically adding > /bin/screen on /usr-merged systems where shells.d contains > /usr/bin/screen is feasible. I see little value though as > /usr/bin/screen has always worked on Debian and why would anyone use > /bin/screen now? Few people would probably *change* /usr/bin/screen to /bin/screen. But some people -- maybe new users -- might not know that /usr/bin/screen is more "traditional"/"canonical" than /bin/screen. I myself might be tempted to use /bin/screen when editing a file (and knowing that /bin = /usr/bin on the relevant system(s)) since it's shorter :) Also: there's no /usr/bin/sh. Now *I* would always type /bin/sh, but setting my shell to $(which sh) would currently result in an invalid shell: |$ which sh |/usr/bin/sh |$ grep $(which sh) /etc/shells || echo OOPS |OOPS Personally, I'd prefer some consistency at least. Either always provide both paths on merged /usr systems, or only provide the "canonical" path on all systems. Not some shells with both entries and some with only one. > #699177 I didn't know about that bug. Thanks. - Felix
