Bug#982079: ITP: fonts-yuseki-magic -- handwritten letters written with permanent marker
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-devel@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-yuseki-magic Version : 1.000 Upstream Author : Tanukizamurai (Kumiko Yoshida) * URL : https://github.com/tanukifont/YuseiMagic * License : OFL-1.1 Programming Lang: python Description : handwritten letters written with permanent marker Yusei Magic is a font based on handwritten letters written with permanent marker. It has thick vertical strokes and thin horizontal strokes, so it is highly visible. The design of the letters has both the strength of bold lines and the softness of spaciousness. Highly recommended for handwriting on blackboards and pop art designs. . This font includes Google Latin Core, Hiragana, Katakana, JIS level 1, level 2 and IBM Extended Kanji (Han) glyphs. . See https://github.com/tanukifont/YuseiMagic
autopkgtest dependency irritiation
Hi,
I have a rather difficult set of packages that need to be updated
somehow together. I puzzled out the breakages and declared them. Namely,
this is the binary package starlink-utils-java, that breaks the old
version of starlink-ttools-java. This is properly mentioned in
d/control:
Package: starlink-util-java
Architecture: all
Depends: ${java:Depends},
${misc:Depends}
Breaks: starlink-topcat-java (<< 4.8~),
starlink-ttools-java (<< 3.4~),
starlink-vo-java (<< 0.2+2019.09.18~),
When I however look into a CI log, I see a failure in combination of
these two packages:
https://ci.debian.net/data/autopkgtest/testing/armhf/s/starjava-ttools/10234315/log.gz
The failure is in principle OK, however the test is just useless since
it tests a combination that is broken. The log tells me the following
about it:
--8<---
Correcting dependencies...Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) autopkgtest-satdep:armhf < 0 @iU mK Nb Ib >
Broken autopkgtest-satdep:armhf Depends on starlink-ttools-java:armhf < none
@un H >
Considering starlink-ttools-java:armhf 1 as a solution to
autopkgtest-satdep:armhf -2
Removing autopkgtest-satdep:armhf rather than change
starlink-ttools-java:armhf
Done
Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
ca-certificates openssl
The following packages will be REMOVED:
autopkgtest-satdep
The following NEW packages will be installed:
ca-certificates openssl
0 upgraded, 2 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 983 kB of archives.
--8<---
which I do not understand. Why does the resolver remove the helper
package instead of giving up? How can I avoud this, and (since this is
listed as a cause preventing migration) and let my package migrate?
And why does this happen only on armhf?
Cheers
Ole
Bug#982087: ITP: timg -- terminal image and video viewer
Package: wnpp Severity: wishlist Owner: Tobias Frost X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: timg Version : 0.9.9 Upstream Author : Henner Zeller * URL : https://github.com/hzeller/timg * License : GPL-2 Programming Lang: C++ Description : terminal image and video viewer timg is a viewer that uses 24-Bit color capabilities and unicode character blocks to display images in the terminal. It displays regular images, plays animated gifs, scrolls static images and plays videos. Very useful if you want to have a quick visual check without starting a bulky image viewer ... and don't care about resolution.
Proposal: plocate as standard for bookworm
Hi, mlocate used to be Priority: standard; for some reason that I haven't been able to unearth (despite the efforts of several people), there is now an override for buster, so that it's no longer installed by default (and mlocate now has an override disparity). I do wonder if this was intentional or not, but it's a bit beside the point: Now, there is plocate (written and maintained by myself). It is orders of magnitude faster than mlocate (both on SSDs and HDDs alike), has the same security model, a smaller database (typically half the size), and fixes a few long-standing mlocate bugs. It is nearly fully command-line compatible with mlocate, so most users should feel right at home. It builds on all release and non-release architectures. The only non-Essential dependencies are liburing1 (33 kB) and libzstd1 (670 kB). I believe a good, fast locate is something that we should have in our base install; it is fine to keep it out of the cloud image (as today), but it is genuinely useful for both desktops and servers, and with a low cost. Thoughts? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C
Package: wnpp Severity: wishlist Owner: Jan Mojzis * Package name: bearssl Version : 0.6 Upstream Author : Thomas Pornin * URL : https://bearssl.org * License : MIT Programming Lang: C Description : BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C. It aims at offering the following features: - Be correct and secure. In particular, insecure protocol versions and choices of algorithms are not supported, by design; cryptographic algorithm implementations are constant-time by default. - Be small, both in RAM and code footprint. For instance, a minimal server implementation may fit in about 20 kilobytes of compiled code and 25 kilobytes of RAM. - Be highly portable. BearSSL targets not only “big” operating systems like Linux and Windows, but also small embedded systems and even special contexts like bootstrap code. - Be feature-rich and extensible. SSL/TLS has many defined cipher suites and extensions; BearSSL should implement most of them, and allow extra algorithm implementations to be added afterwards, possibly from third parties Library doesn't have compatible API with mainstream OpenSSL. And it's not intended as an OpenSSL 1-1 replacement. I'm using this software and I'm going to maintain using https://salsa.debian.org/. I need sponsor.
Re: Proposal: plocate as standard for bookworm
On 2/6/21 6:10 PM, Steinar H. Gunderson wrote: > I believe a good, fast locate is something that we should have in our base > install; it is fine to keep it out of the cloud image (as today), but it is > genuinely useful for both desktops and servers, and with a low cost. seconded, thanks for writing plocate! > Thoughts? I think plocate should have a Conflicts: mlocate. There is no need to install two locate implementations in parallel, it will just create useless IO. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#982140: ITP: fuzzel -- Wayland-native application launcher
Package: wnpp Severity: wishlist Owner: Peter Colberg X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fuzzel Version : 1.5.1 Upstream Author : Daniel Eklöf * URL : https://codeberg.org/dnkl/fuzzel * License : Expat Programming Lang: C Description : Application launcher for wlroots based Wayland compositors Fuzzel is a Wayland-native application launcher, similar to rofi's drun mode. Features: * Wayland native * Rofi drun-like mode of operation * dmenu mode where newline separated entries are read from stdin * Emacs key bindings * Icons! * Remembers frequently launched applications This package will be maintained under the umbrella of the swaywm team [1]. [1] https://salsa.debian.org/swaywm-team/fuzzel
Re: Proposal: plocate as standard for bookworm
On Sat, Feb 06, 2021 at 10:18:45PM +0100, Bernd Zeimetz wrote: >> Thoughts? > I think plocate should have a Conflicts: mlocate. There is no need to > install two locate implementations in parallel, it will just create > useless IO. It's a pretty thin use-case, but someone could have scripts that call mlocate explicitly (not through the locate symlink). Or have something that is capable of reading mlocate's database. Or wish to have both to benchmark against each other :-) Unfortunately, we don't have an “Anti-Recommends”. /* Steinar */ -- Homepage: https://www.sesse.net/
Re: Proposal: plocate as standard for bookworm
On Sun, Feb 7, 2021 at 12:05 AM Steinar H. Gunderson wrote: > It's a pretty thin use-case, but someone could have scripts that call mlocate > explicitly (not through the locate symlink). Or have something that is > capable of reading mlocate's database. Or wish to have both to benchmark > against each other :-) Unfortunately, we don't have an “Anti-Recommends”. Or wish to transition from mlocate to plocate without doing a full updatedb run by using the plocate-build script, which reads the mlocate database and generates a plocate database. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Proposal: plocate as standard for bookworm
On Sat, Feb 6, 2021 at 5:29 PM Steinar H. Gunderson wrote: > I believe a good, fast locate is something that we should have in our base > install; it is fine to keep it out of the cloud image (as today), but it is > genuinely useful for both desktops and servers, and with a low cost. I support having locate in the base install, but I don't think that the cost of daily walking the entire filesystem is low; especially with HDDs and older storage or computers that can be a lot of I/O. I guess it also alters the Linux kernel block/filesystem caches? A daemon monitoring filesystem changes using fanotify or similar and then updating the database on a configured schedule would mitigate this cost, but I guess would be harder to implement. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#982165: ITP: emacs-org-d20 -- Emacs minor mode for d20 tabletop roleplaying games
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: emacs-org-d20 Version : 0.4 Upstream Author : Sean Whitton * URL : https://spwhitton.name/tech/code/org-d20/ * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs minor mode for d20 tabletop roleplaying games A minor mode intended for use in an Org-mode file in which you are keeping your GM notes for a tabletop roleplaying game that uses a d20. I wrote this for my own use, and did not expect to upload it to Debian, but reddit and MELPA download statistics suggest that other people are using it too, so seems worth adding it to our archive. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal: plocate as standard for bookworm
Steinar H. Gunderson wrote: > Now, there is plocate (written and maintained by myself). It is orders of > magnitude faster than mlocate (both on SSDs and HDDs alike), has the same > security model, a smaller database (typically half the size), and fixes > a few long-standing mlocate bugs. It is nearly fully command-line compatible > with mlocate, so most users should feel right at home. It builds on all > release and non-release architectures. The only non-Essential dependencies > are liburing1 (33 kB) and libzstd1 (670 kB). > > I believe a good, fast locate is something that we should have in our base > install I absolutely think that plocate makes sense as the "default" locate; it seems like an improvement on mlocate in every way. However, I don't think *any* locate should be in the base install, as long as that entails having any kind of regularly scheduled task that indexes the filesystem, even if that task has been made relatively cheaper than other implementations. locate is a purely user-facing tool, not really usable for portable scripting, since neither its presence nor its functioning can be assumed. Many users won't even know it exists (locate has far fewer users than find), and for all of those non-users, the effort spent building the database will go entirely to waste. On top of that, several desktop environments (including a default "desktop" installation) have their own entirely separate mechanism for indexing files, typically based on a change-watching API (e.g. inotify) rather than a regularly scheduled update. For any users who have and use such a mechanism, they'd then have *two* mechanisms indexing the filesystem rather than just one, and they're likely to only use one of those. Furthermore, any mechanism they use to configure one of them (e.g. for privacy or performance reasons) will not control the other, and again they may well be unaware of the existence of the other one. We should absolutely have a locate implementation available for any who want to install and use it, but we shouldn't make all users pay the cost of locate's database update to satisfy the subset of users who ever invoke locate. - Josh Triplett
Bug#982176: ITP: flask-oidc -- OpenID Connect support for Flask
Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior * Package name: flask-oidc Version : 1.4.0 Upstream Author : Patrick Uiterwijk * URL : https://github.com/puiterwijk/flask-oidc * License : BSD-2-clause Programming Lang: Python Description : OpenID Connect support for Flask This library should work with any standards compliant OpenID Connect provider. It has been tested with: . * Google+ login * Ipsilon This package is a dependency for Pagure. .I will maintain it with the Python Team. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
