Bug#1061936: ITP: libhitaki -- Library to operate ALSA HwDep device for ALSA firewire stack
Package: wnpp Severity: wishlist Owner: Takashi Sakamoto X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libhitaki Version : 0.2.0 Upstream Contact: Takashi Sakamoto * URL : https://github.com/alsa-project/libhitaki * License : LGPL-3+ Programming Lang: C Description : Library to operate ALSA HwDep device for ALSA firewire stack Libhitaki is a shared library to operate ALSA HwDep character device for audio and music unit in IEEE 1394 bus. The recent version of libhinawa delegated some features to libhitaki, and the latest version dropped them after the long term of deprecation. The features are required to continue maintaining hinawa-utils package. The lack of libhitaki package blocks the migration of hinawa-utils to the new libhinawa package. For the reasons, I would like to put libhitaki package to Debian repository.
Bug#1061940: ITP: libudis86 -- Disassembler for the x86 and x86-64 class of instructions set
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: libudis86 Version : #5336633 Upstream Contact: https://github.com/canihavesomecoffee/udis86/issues * URL : https://github.com/canihavesomecoffee/udis86 * License : BSD 2-Clause Programming Lang: C, Python Description : Disassembler for the x86 and x86-64 class of instructions set Udis86 is a disassembler for the x86 and x86-64 class of instruction set architectures. It consists of a C library called libudis86 which provides a clean and simple interface to decode and inspect a stream of raw binary data as disassembled instructions in a structured manner, and a command line tool called udcli that incorporates the library. canihavesomecoffee/udis86 is a dependency for Hyprland[1][2] that I am interested in packaging. This project is a fork of another of similar name[3][4] with fixes and additions merged from other forks[6]. It looks like there was an ITP created for the original[7] which was later abandoned. @werdahias has prepared initial packaging here[8]. My attempt[9] is based on this. [1] https://github.com/hyprwm/Hyprland [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [3] https://github.com/vmt/udis86 [4] https://sourceforge.net/projects/udis86/ [6] https://github.com/canihavesomecoffee/udis86?tab=readme-ov-file#author-and-contributors [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893807 [8] https://salsa.debian.org/werdahias/udis86-wip/ [9] https://salsa.debian.org/NyxTrail/udis86
Bug#1061946: ITP: iraf-st4gem -- Selected tools from the Space Telescope Science Data Analysis System
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-as...@lists.debian.org, debian-devel@lists.debian.org * Package name: iraf-st4gem Version : 1.0 Upstream Author : STScI, NOIRLAB * URL : https://gitlab.com/nsf-noirlab/csdc/usngo/iraf/st4gem * License : BSD-3-Clause Programming Lang: IRAF SPP Description : Selected tools from the Space Telescope Science Data Analysis System The Space Telescope Science Data Analysis System (STSDAS) is software for calibrating and analyzing data from the Hubble Space Telescope (HST). STSDAS includes the same calibration routines as are used in the routine data processing pipeline, as well as general-purpose tools and enhancements to the Image Analysis and Reduction Facility (IRAF). The original STSDAS package contained non-free code and was 32-bit only. For the Gemini legacy data reduction pipeline, selected tasks of STSDAS were ported to 64 bit and non-free code was replaced. These tasks are also useful outside of the Gemini data reduction context. I will maintain it within the Debian Astro team. A git repository was created at https://salsa.debian.org/debian-astro-team/iraf-st4gem Best regards Ole
Bug#1061999: ITP: mistserver -- Streaming media toolkit
Package: wnpp Severity: wishlist Owner: Alex Henrie X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mistserver Version : 3.3 Upstream Contact: https://mistserver.org/contact * URL : https://mistserver.org/ * License : Unlicense Programming Lang: C++ Description : Streaming media toolkit MistServer is a full-featured, next-generation streaming media toolkit for OTT (internet streaming), designed to be ideal for developers and system integrators. This is the first time that I have submitted a package to Debian. It's a neat piece of software that can be used to serve an RTP video stream with DVR features. Packaging MistServer is a little tricky because it must be statically linked to its own specific fork of libmbedtls, which is distributed separately. These are the commands I'm using to get the source: wget https://github.com/DDVTECH/mistserver/archive/refs/tags/3.3.tar.gz -O mistserver_3.3.orig.tar.gz wget https://api.github.com/repos/livepeer/mbedtls/tarball/dtls_srtp_support -O mistserver_3.3.orig-mbedtls.tar.gz
Proper handling of Lintian warnings due to other packages
While building a package preparing for a possible upload, I am getting a large number of warnings from groff-message due to invalid fonts for C and CB in the manpages that are generated from Markdown with pandoc. From what I understand, this is a known issue with how pandoc generates nroff man pages and more recent versions of groff have started complaining about the issue. Here is an example warning I am getting: groff-message troff::89: warning: cannot select font 'C' And it seems to match the issue documented here: https://github.com/jgm/pandoc/issues/9020 My question is how to handle this. Should I just ignore it for now and upload anyways since it's only a warning or should I add an override to suppress it as it doesn't seem to be causing any breaking issues at the moment? Have other developers dealt with this warning before? -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Re: Proper handling of Lintian warnings due to other packages
Hi Loren, At 2024-01-30T19:55:07-0800, Loren M. Lang wrote: > While building a package preparing for a possible upload, I am getting > a large number of warnings from groff-message due to invalid fonts for > C and CB in the manpages that are generated from Markdown with pandoc. > From what I understand, this is a known issue with how pandoc > generates nroff man pages and more recent versions of groff have > started complaining about the issue. Here is an example warning I am > getting: > > groff-message troff::89: warning: cannot select font 'C' > > And it seems to match the issue documented here: > > https://github.com/jgm/pandoc/issues/9020 Yes. I work on groff upstream (and at rare intervals make minor contributions to the Debian package), and you've accurately summarized the situation. > My question is how to handle this. Should I just ignore it for now and > upload anyways since it's only a warning or should I add an override > to suppress it as it doesn't seem to be causing any breaking issues at > the moment? Have other developers dealt with this warning before? Well, the version of pandoc that resolved the issue was 3.1.7, released in August 2023.[1] But the version in Debian unstable is still 3.1.3, and the package is team-maintained.[2] Unless it's release-critical to have these Lintian warnings, I would disregard them in hope that the pandoc package in unstable will catch up at some point soon. Those warnings from groff can arise under other circumstances, and they do mean that a font change requested by the document has not been honored,[3] so I do not recommend masking them in general. Regards, Branden [1] https://pandoc.org/releases.html [2] https://tracker.debian.org/pkg/pandoc [3] From technical writing and accessibility perspectives, it is not wise to stake important semantic differences to changes in font style, but a lot of documentation gets written with that coupling nevertheless. signature.asc Description: PGP signature
Re: Proper handling of Lintian warnings due to other packages
@Lauren Because of an earlier post by you, I assume you prepare a package which eventually requires a sponsorship by a DD. If this were true, the upload to https://mentors.debian.net/ would allow you to share an intermediate version to document your current progress -- both to replicate potential problems, as well as to hopefully identify ways how to improve it. Later, a DD then can use and promote your best upload to the mentors page for an upload to Debian's repositories. Best regards, Norwid
Re: Proper handling of Lintian warnings due to other packages
On Wed, Jan 31, 2024 at 07:38:52AM +0100, Norwid Behrnd wrote: > @Lauren Because of an earlier post by you, I assume you prepare a package > which eventually requires a sponsorship by a DD. If this were true, the > upload > to https://mentors.debian.net/ would allow you to share an intermediate > version > to document your current progress -- both to replicate potential problems, as > well as to hopefully identify ways how to improve it. Later, a DD then can > use and promote your best upload to the mentors page for an upload to Debian's > repositories. In general, your advice is very good and useful, thanks! In this particular case, Lauren is working on a package maintained by the RPM packaging team, and the work is visible in a salsa.debian.org repository fork; this is another way in which one's work can be reviewed by other developers (and in this particular case, Lauren, I *will* get around to taking a look at yours soon, honest!) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Proper handling of Lintian warnings due to other packages
Quoting G. Branden Robinson (2024-01-31 05:49:00) > At 2024-01-30T19:55:07-0800, Loren M. Lang wrote: > > While building a package preparing for a possible upload, I am getting > > a large number of warnings from groff-message due to invalid fonts for > > C and CB in the manpages that are generated from Markdown with pandoc. > > From what I understand, this is a known issue with how pandoc > > generates nroff man pages and more recent versions of groff have > > started complaining about the issue. Here is an example warning I am > > getting: > > > > groff-message troff::89: warning: cannot select font 'C' > > > > And it seems to match the issue documented here: > > > > https://github.com/jgm/pandoc/issues/9020 > > Yes. I work on groff upstream (and at rare intervals make minor > contributions to the Debian package), and you've accurately summarized > the situation. > > > My question is how to handle this. Should I just ignore it for now and > > upload anyways since it's only a warning or should I add an override > > to suppress it as it doesn't seem to be causing any breaking issues at > > the moment? Have other developers dealt with this warning before? > > Well, the version of pandoc that resolved the issue was 3.1.7, released > in August 2023.[1] But the version in Debian unstable is still 3.1.3, > and the package is team-maintained.[2] This particular bug is tracked in Debian as well: https://bugs.debian.org/1053777 > Unless it's release-critical to have these Lintian warnings, I would > disregard them in hope that the pandoc package in unstable will catch > up at some point soon. Unfortunately it is not likely that the package will be catch up soon, because the Haskell team upgrade most Haskell libraries only as a whole. That issue is not tracked in debbugs, because those vocal in the Haskell team actively discourages the use of debbugs: https://lists.debian.org/debian-haskell/2024/01/msg00012.html - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
