Bug#1049944: ITP: camelot-py -- extract tables from PDF
Package: wnpp Severity: wishlist Owner: Elena Grandi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: camelot Version : 0.11.0 Upstream Contact: Vinayak Mehta * URL : http://camelot-py.readthedocs.io/ * License : MIT/X Programming Lang: Python Description : extract tables from PDF A python library and command line program to extract tables from PDF data. This package is a build-depend of fpdf2, used to run some of the tests. I plan to maintain this package in the Python Team.
Bug#1049960: ITP: half -- C++ library for half precision floating point arithmetics
Package: wnpp Severity: wishlist Owner: Christian Kastner X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: half Version : 2.2.0 Upstream Author : Christian Rau * URL : https://sourceforge.net/projects/half/ * License : MIT Programming Lang: C++ Description : C++ library for half precision floating point arithmetics This is a C++ header-only library to provide an IEEE-754 conformant half-precision floating point type along with corresponding arithmetic operators, type conversions and common mathematical functions. It aims for both efficiency and ease of use, trying to accurately mimic the behaviour of the builtin floating point types at the best performance possible. It automatically uses and provides C++11 features when possible, but stays completely C++98-compatible when neccessary. This is needed by MIOpen, which is also in the process of being packaged. This will be maintained by the Debian ROCm Team.
Bug#1049961: ITP: composable-kernel -- library for writing performance critical kernels for ML workloads
Package: wnpp Severity: wishlist Owner: Christian Kastner X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: composable-kernel Version : 0+git20230816 Upstream Author : Advanced Micro Devices, Inc. * URL : https://github.com/ROCmSoftwarePlatform/composable_kernel * License : MIT Programming Lang: C++ Description : library for writing performance critical kernels for ML workloads Composable Kernel (CK) library aims to provide a programming model for writing performance critical kernels for machine learning workloads across multiple architectures including GPUs, CPUs, etc, through general purpose kernel languages, like HIP C++. CK utilizes two concepts to achieve performance portability and code maintainability: * A tile-based programming model * Algorithm complexity reduction for complex ML operators, using innovative technique we call "Tensor Coordinate Transformation". This is needed by MIOpen, which is also in the process of being packaged. This will be maintained by the Debian ROCm Team.
Re: groff warning: TE macro called with TW register undefined
On Thu, 17 Aug 2023 at 09:10, Colin Watson wrote: > > Your problem is that you need this line as the very first line of the > page to instruct man(1) to run the tbl preprocessor: > > '\" t > > See https://manpages.debian.org/bookworm/man-db/man.1.en.html#DEFAULTS That does the trick. Thank you! I knew there had to be a simple solution, but I didn't know man(1) could be instructed to call a preprocessor.
Re: groff warning: TE macro called with TW register undefined
Hi Branden, On Thu, 17 Aug 2023 at 10:08, G. Branden Robinson wrote: > > Hi Hugh, > > [...] > So whether the man page is hand-crafted or generated from some other > format at build time is not relevant. In fact, it's _meta_ irrelevant > (if that's even a thing) because the only reason (apart from the > validation Lintian's doing) for a source project to run groff at build > time on a man page is to generate a PDF, "cat page", or other > _formatted_ version of the man page.[1] Examples of these are rare, but > Bash and NetHack generate cat pages, and groff itself generates a PDF > compilation of all its man pages.[2] Thanks for the explanation. While my research indicated that tbl was not being called, I couldn't find any way of calling it, short of `groff -t`. > > > What exact check is failing here (is it lintian, or something else)? > > > Could you please give us a pointer to the man page in question? > > > > Lintian issues the warning when checking for man-page issues using > > groff (via man). This particular warning has only appeared since the > > recent groff 1.23.0 upload. > > The warning is new to groff 1.23.0.[3] > > > The Lintian tag is 'groff-message'. The tag description helpfully > > provides the exact command used during the check: > > > > LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \ > > man --warnings -E UTF-8 -l -Tutf8 -Z >/dev/null > > > > The man page in question -- ftlint.1 -- is in the freetype2-demos > > package [1], or you can get an online copy from [2]. > > In the course of composing this message, I see that Colin covered this > point.[4] Yes. I had no idea preprocessors could be invoked via man(1). > I would also note that you can use the grog(1) command (new and improved > in groff 1.23.0![5]) to help you figure out which preprocessors (and > macro package) a *roff document needs.[6] > > Let me know if this helps, or does not. It does help, yes. I ran grog(1) on the man page in question and the output immediately indicated that `tbl` was needed. Thank you for your help. > Regards, > Branden > > [1] Another use case is to produce non-man-page manuals from *roff > sources using a macro package like "ms", "me", or "mm". groff > supports all of these and it was commonly done in pre-Web days, but > it's now sadly close to a lost art. The _Unix Time-Sharing System > Programmer's Manual Seventh Edition Volume 2_ (1979) remains > valuable reading and an example of high-quality technical writing > apply *roff to ends other than man pages. > > > https://archive.org/details/bitsavers_attunix7thersManualSeventhEditionVol21983_34117955/ > > It's particularly valuable for learning "classical Unix" tools in > their early and more easily grasped forms. I've found that GNU > manuals, in spite of the advantages touted for Texinfo for > preparation of book-length works over mere reference guides (a.k.a. > man pages), are nevertheless often written in the style of man pages > with little effort made to give the reader a perspective from which > to integrate knowledge of the (nearly always) larger interface and > feature list of GNU replacements for Unix tools. In other words, > they too often suffer from the same defects that the GNU Coding > Standards attribute to man pages. > > > https://web.archive.org/web/20041029120203/http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals > > (To be fair, more recent versions of the GNU Coding Standards have > moved--slightly--in the direction of acknowledging that the > quality of the technical writing, not the formatting language used > to compose it, that is the predominant factor in production of > useful manuals.) > > [2] https://www.gnu.org/software/groff/manual/groff-man-pages.pdf > [3] > https://git.savannah.gnu.org/cgit/groff.git/commit/?id=80ee140eb0616b794b853bbad623263cbea06abc > [4] https://lists.debian.org/debian-devel/2023/08/msg00220.html > [5] Yes, I can feel my eternal soul tumbling down several rungs in Hell > for engaging in promotion. > > [6] https://man.cx/grog > > I was going to link to > https://manpages.debian.org/unstable/groff/grof.1.en.html here, but > the man page is missing! groff definitely ships it. Any advice?
Bug#1049970: ITP: cliphist -- wayland clipboard manager
Package: wnpp Severity: wishlist Owner: Ricardo Marliere * Package name: cliphist Version : 0.4.0-1 Upstream Author : Senan Kelly * URL : https://github.com/sentriz/cliphist * License : GPL-3.0 Programming Lang: Go Description : wayland clipboard manager cliphist . *clipboard history “manager” for wayland* . * write clipboard changes to a history file * recall history with **dmenu** / **rofi** / **wofi** (or whatever other picker you like) * both **text** and **images** are supported * clipboard is preserved **byte-for-byte** * leading / trailing whitespace / no whitespace or newlines are preserved * won’t break fancy editor selections like vim wordwise, linewise, block mode * no concept of a picker, only pipes I am a user of the program and would like to package it as my first contribution to Debian. signature.asc Description: PGP signature
Bug#1049986: ITP: filtermail -- Filtermail filters incoming e-mail as accepted, spam, or ignored
Package: wnpp Severity: wishlist Owner: Frank Brokken X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: filtermail Version : 1.02.00 Upstream Contact: Frank B. Brokken * URL : https://fbb-git.gitlab.io/filtermail * License : GPL Programming Lang: C++ Description : Filtermail filters incoming e-mail as accepted, spam, or ignored Filtermail filters incoming e-mail as either accepted, spam, or ignored e-mail. It uses rule files, which are inspected in sequence until the incoming e-mail matches a rule. Once that happens the rule's associated action (accept, spam, or ignore) is executed. If the e-mail is not matched by any rule then the e-mail is accepted. Accepted e-mail normally is appended to the mail file which is used by the incoming mail server when receiving mail for the current user. E.g., if the user's username is frank then incoming mail is appended to the file /var/mail/frank. Users may also define directories to contain saved e-mails (e.g., ~/Mail), and filtermail can be configured to append e-mail considered as spam to, e.g., ~/Mail/spam. Likewise, e-mail matching the 'ignore' criteria could be appended to ~/Mail/ignore. Instead of appending the complete e-mail to its destination file the received e-mail's From: and Subject: headers can be appended to its destination file. Alternatively, such e-mail can also be ignored, losing it completely. Filtermail uses three types of files: * The configuration file contains values of options with are generally used (covered in the man-page's sections CONFIGURATION and OPTIONS); * Mail filtering rules are hierarchically ordered in the rules file: incoming mail is sequentially matched against the patterns defined in files specified in the rules file until a match is found. Once a match has been found the rule's action (accept, ignore or spam) is executed, ending the filtering process; * Each file specified in the rules file defines matching patterns, which are tested sequentially. Testing those patterns ends once the incoming mail matches a pattern. In addition to the filtermail program itself a small support program 'inspect' is part of filtermail: inspect expects a received e-mail file at its standard input. Mail handling programs (e.g., mutt(1)) allow its users to pipe an e-mail file to a program, inspecting the received e-mail. Depending on the content of the Received: headers inspect's output shows the domain name of the sender, its IP address, its country of origin and the cidr-range containing the received IP address. If the received e-mail is considered conspicuous (e.g., spam or mail to ignore) then the mail's details, e.g. its cidr range. could be added to the file recognizing spam-rated e-mail. - why is this package useful/relevant? The main reason for developing filtermail was the fact that I frequently receive mail which is either spam or which is completely irrelevant and annoying. Previously I used a bash-script to filter such mail, but that script eventually was hard to maintain. A compilable program offers, IMHO, better facilities for maintenance and modifications so I wrote filtermail. Over the past three months it performed its job as expected. E.g., of the about 300 e-mails I received in the category 'igored' were all correctly categorized. - it a dependency for another package? No, it's a stand-alone program - do you use it? Yes, I do - if there are other packages providing similar functionality, how does it compare? There exists a program 'mailfilter' focusing on handling pop-accounts and also offering ways to recognize e-mail as spam. Filtermail, on the other hand, uses the 'ignore' category in addition to the 'spam' category and primarily aims at categorizing (in various forms) incoming e-mail. - how do you plan to maintain it? I have a long history of building and maintaining programs, many of them are also registered as Debian packages. I handle the maintenance of the programs myself, and almost all my direct contact with Debian is via Tony Mancill (tmanc...@debian.org) who is a Debian developer. When there's a new version of one of my Debian provided programs I prepare the required update, upload it to salsa, and send Tony an e-mail asking him to verify the latest update. Filtermail's website is at https://fbb-git.gitlab.io/filtermail/ where you also find links to the man-pages, to its repository, and to a list of programs I developed, most of them are available as Debian packages. - do you need a sponsor? If I'm correct then the 'sponsor' is a Debian maintainer who's willing to adopt a program for Debian. If so, then yes, I do. I hope you like filtermail!
