Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Wed, Mar 13, 2024 at 10:40:51AM +, Traut Manuel LCPF-CH wrote: > > On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote: > >> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > >>> On 7 Feb 2024, at 18:27, Dima Kogan wrote: > >>> > >>> Hi. Thanks for your contribution. I looked at the upstream code a tiny > >>> bit, and it looks like it might have portability bug, at least on > >>> big-endian architectures. For instance: > >>> > >>> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > >>> > >>> This assumes that sizeof(long)==4. Maybe this is benign, but it would be > >>> nice to fix. Are you upstream or do you know upstream? Can yall fix > >>> these? > >>> > >> The kernel expects a 4 byte write here, since unsigned long is defined as > >> at least 32 bit this shall work on all architectures. > >> > >> If your concern is about endianess this is not in the current scope of > >> libuio and needs to be addressed by a higher layer. > >> > >> I am very familiar with library and in close contact with upstream. > >> > > In the case of uio_disable_irq() the bug is nicely hidden by the fact > > that tmp is guaranteed to be all-zeroes. However, consider the previous > > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, > > then the "tmp" variable's value of 1 will be encoded in memory as > > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. > > When uio_enable_irq() calls write(..., , 4), it will only send > > the first four bytes to the kernel - and they are 0, 0, 0, and... 0. > > So it turns out that uio_disable_irq() and uio_enable_irq() do > > exactly the same - send a 32-bit zero value to the kernel. > > > > ...of course, this will only happen on a big-endian system, as > > Dima Kogan was concerned about. On a little-endian system, this > > will work by chance. > > > > Is this the expected behavior indeed? > > No it is not :) Thanks for the detailed explanation. > > Looks this fix sane to you? > https://github.com/manut/libuio/commit/1edcf262fbfaf0b7f8519875ed5b357964dd1e55 Yeah, after I sent the e-mails I realized that I forgot to mention that using uint32_t would be one of the best ways to fix that. Thanks for the fast reaction! > I am not sure if users also expect an automatic conversion for the read/write > functions: > https://github.com/manut/libuio/commit/d0319169359bffc73374f1011e942702e9bafb1e > > It will be somehow inconsistent since a user could also access the device > memory by pointer: > https://github.com/manut/libuio/blob/add-ci/mem.c#L93 > and than needs to take care on the endianess by its own anyway. ...and this part I have no opinion about. I don't have any realistic idea about how people actually use libuio (or how they will use it), and I do not think that I will use it soon, so this should be left for others to decide. Thanks again for paying attention to the comments! 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
Bug#1065669: ITP: raven -- A lightweight http file upload service used for penetration testing and incident response.
On Sat, Mar 09, 2024 at 01:12:06PM +0100, Salvo Tomaselli wrote: > > In data venerdì 8 marzo 2024 18:08:11 CET, aquilamac...@riseup.net ha scritto: > > Package: wnpp > > X-Debbugs-Cc: debian-de...@lists.debian.org > > Owner: Aquila Macedo Costa > > Severity: wishlist > > > > * Package name: raven > > Version : 1.0.1 > > Upstream Contact: Tristram > > * URL : https://github.com/gh0x0st/raven > > * License : MIT > > Programming Lang: Python3 > > Description : A lightweight http file upload service used for > > penetration testing and incident response. > > > > This package contains a Python tool that extends the capabilities of the > > http.server Python module by offering a self-contained file upload web > > server. > > While the common practice is to use python3 -m http.server 80 to serve > > files > > for remote client downloads, Raven addresses the need for a similar > > solution > > when you need the ability to receive files from remote clients. This > > becomes > > especially valuable in scenarios such as penetration testing and > > incident > > response procedures when protocols such as SMB may not be a viable > > option. > > > > I'm writing to submit an Intention to Package (ITP) for raven > > under the pkg-security team's umbrella. > > What's the problem with > > nc -lp 80 > file > > ? > > Does this provide some sort of browser interface? To start with, raven seems to allow uploading more than one file :) The description on the project homepage lists several features such as access control, organizing the uploaded files into subdirectories, etc. 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
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > Hi Dima, > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > bit, and it looks like it might have portability bug, at least on > > big-endian architectures. For instance: > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > these? > > The kernel expects a 4 byte write here, since unsigned long is defined as at > least 32 bit this shall work on all architectures. > > If your concern is about endianess this is not in the current scope of libuio > and needs to be addressed by a higher layer. > > I am very familiar with library and in close contact with upstream. In the case of uio_disable_irq() the bug is nicely hidden by the fact that tmp is guaranteed to be all-zeroes. However, consider the previous function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, then the "tmp" variable's value of 1 will be encoded in memory as 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. When uio_enable_irq() calls write(..., , 4), it will only send the first four bytes to the kernel - and they are 0, 0, 0, and... 0. So it turns out that uio_disable_irq() and uio_enable_irq() do exactly the same - send a 32-bit zero value to the kernel. Is this the expected behavior indeed? 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
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote: > On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > > Hi Dima, > > > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > > bit, and it looks like it might have portability bug, at least on > > > big-endian architectures. For instance: > > > > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > > these? > > > > The kernel expects a 4 byte write here, since unsigned long is defined as > > at least 32 bit this shall work on all architectures. > > > > If your concern is about endianess this is not in the current scope of > > libuio and needs to be addressed by a higher layer. > > > > I am very familiar with library and in close contact with upstream. > > In the case of uio_disable_irq() the bug is nicely hidden by the fact > that tmp is guaranteed to be all-zeroes. However, consider the previous > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, > then the "tmp" variable's value of 1 will be encoded in memory as > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. > When uio_enable_irq() calls write(..., , 4), it will only send > the first four bytes to the kernel - and they are 0, 0, 0, and... 0. > So it turns out that uio_disable_irq() and uio_enable_irq() do > exactly the same - send a 32-bit zero value to the kernel. ...of course, this will only happen on a big-endian system, as Dima Kogan was concerned about. On a little-endian system, this will work by chance. > Is this the expected behavior indeed? -- 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
Bug#1065230: ITA three more Python packages
package wnpp retitle 1065150 ITA: pymdown-extensions -- Extension pack for Python Markdown owner 1065150 ! retitle 1065230 ITA: python-regex -- alternative regular expression module (Python 3) owner 1065230 ! retitle 1065251 ITA: python-click -- Wrapper around optparse for command line utilities - documentation owner 1065251 ! thanks I intend to maintain these packages within the Debian Python packaging team. 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
Bug#1035747: ITP: cevomapgen -- External Map Generator for C-Evo
Now at upstream version 31 Changes since 26, cevomapgen (31) Warn when map size is over 9,600 Workaround for Qt5 SpinEdits broken in Lazarus 3.0 -- Wed, 28 Feb 2024 cevomapgen (30) Use Smart linking Use Makefile in Linux builds -- Tue, 27 Feb 2024 cevomapgen (29) Rework starting positions algorithm -- Sun, 8 Oct 2023 cevomapgen (28) fix bug in selection of starting positions -- Wed, 20 Sep 2023 cevomapgen (27) fix crash on repeating map load Show City estimate on loaded maps -- Sun, 18 Jun 2023
Bug#1065039: ITA mkdocs-material
package wnpp retitle 1065039 ITA: mkdocs-material -- Material Design theme for MkDocs owner 1065039 ! bye Hi, Thanks for your work on mkdocs-material over the years! I intend to adopt this package within the Debian Python team. 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
Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them
They appear to be very similar. The code base is completely different. I'll review the tmpreaper program closely and close this ITP if there is functional duplication. Thank you for pointing this out. On 2/13/24 16:39, gregor herrmann wrote: On Tue, 13 Feb 2024 16:21:46 -0600, Peter Hyman wrote: * Package name : tmpwatch Description : tmpwatch is a utility searches for files not accessed in a specific time and deletes them The tmpwatch utility recursively searches through specified directories and removes files which have not been accessed in a specified period of time. tmpwatch is normally used to clean up directories which are used for temporarily holding files (for example, /tmp). This sounds very much like tmpreaper: Description-en: cleans up files in directories based on their age This package provides a program that can be used to clean out temporary-file directories. It recursively searches the directory, refusing to chdir() across symlinks, and removes files that haven't been accessed in a user-specified amount of time. You can specify a set of files to protect from deletion with a shell pattern. It will not remove files owned by the process EUID that have the `w' bit clear, unless you ask it to, much like `rm -f'. `tmpreaper' will not remove symlinks, sockets, fifos, or special files unless given a command line option enabling it to. . WARNING: Please do not run `tmpreaper' on `/'. There are no protections against this written into the program, as that would prevent it from functioning the way you'd expect it to in a `chroot(8)' environment. . The daily tmpreaper run can be configured through /etc/tmpreaper.conf . Could you maybe say a bit about the differences? Cheers, gregor -- Peter Hyman
Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them
Package: wnpp Severity: wishlist Owner: Peter Hyman X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : tmpwatch Version : 2.12 * Upstream Contact: Peter Hyman URL : https://github.com/pete4abw/tmpwatch * License : GPL Programming Lang: C Description : tmpwatch is a utility searches for files not accessed in a specific time and deletes them The tmpwatch utility recursively searches through specified directories and removes files which have not been accessed in a specified period of time. tmpwatch is normally used to clean up directories which are used for temporarily holding files (for example, /tmp). - While Debian removes files in the /tmp directory, other files may have temporary files that needs to be cleaned periodically. tmpwatch is ideally used as a cron-job. - how do you plan to maintain it? tmpwatch has not had any activity for over 5 years. Originally written by Erik Troan , Preston Brown , Mike A. Harris , Miloslav Trmač , I have forked off and added some enhancements. However, packaging for Debian has been challenging since the autogen I wrote fetches a submodule which creates lots of files not in the source package. I would need a mentor to help me get this off the ground. Original project URL is at the Fedora project page: https://pagure.io/tmpwatch -- Peter Hyman
Bug#1062122: Usage information
Some usage and integration information. * On KDE, LD_PRELOAD can be set in a file in the .config/plasma-workspace/env directory. This will enable libtrash throughout the KDE session. * libtrash is not active in the Dolphin file manager which has its own trash can. * Some user defaults can be set. There are some system defaults and any settings in the user directory will override the system defaults. Here is what I have in my $HOME/.libtrash file $cat $HOME/.libtrash IGNORE_EXTENSIONS = o;log;aux;swp;bak;tmp;vmdk;out;lrz;file;h;lck - don't preserve files with these extensions. TEMPORARY_DIRS = /tmp;/var;/share/software/cache; - ignore these directories and don't preserve files in them IGNORE_RE = conftest.*;*cache;config.* - use regular expressions and don't preserve matching files REMOVABLE_MEDIA_MOUNT_POINTS = /run;/media;/mnt;/dev - ignore these removable directories USER_TEMPORARY_DIRS = mnt;tmp;temp - ignore user-owned temporary directories PRESERVE_FILES_LARGER_THAN = 1G - do not preserve files larger than... Here are the system defaults. TRASH_CAN = "Trash" - name of user trash can in $HOME IN_CASE_OF_FAILURE = PROTECT | ALLOW_DESTRUCTION - if there is some failure in calling the unlink() or other function, preserve the file SHOULD_WARN = NO - if libtrash is disabled (i,e, TRASH_OFF=YES) issue a warning on stderr PROTECT_TRASH = YES - do not delete files in the user trash can IGNORE_EXTENSIONS = "o;log;aux" - (see above) IGNORE_HIDDEN = YES - do not preserve hidden files IGNORE_EDITOR_BACKUP = YES - do not preserve editor backup files IGNORE_EDITOR_TEMPORARY = YES - ignore editor temporary files LIBTRASH_CONFIG_FILE_UNREMOVABLE = YES - protect user .libtrash file GLOBAL_PROTECTION = YES - IF the user has permission in a foreign directory, not excluded above, move files to ~/Trash/SYSTEM_ROOT/dir/file. (See SYSTEM_ROOT below) If GLOBAL_PROTECTION=NO, then the foreign file will be removed directly if the user has permission. TRASH_SYSTEM_ROOT = "SYSTEM_ROOT" - subdir that will contain foreign mount point files UNREMOVABLE_DIRS = "/bin;/boot;/dev;/etc;/lib;/lib64;/opt;/sbin;/usr" - do not remove these directories or files inside them. Ever. TEMPORARY_DIRS "/run;/tmp;/var" - (see above) REMOVABLE_MEDIA_MOUNT_POINTS "/cdrom;/media;/mnt/run" - (see above) EXCEPTIONS "/etc/mtab;/etc/resolv.conf;/etc/adjtime;/etc/upsstatus;/etc/dhcpc" - These files can be removed even if in an UNREMOVABLE_DIR USER_TEMPORARY_DIRS "" - (see above) IGNORE_RE = "files*" - ignore files matching anything listed using regular expressions -- Peter Hyman
Bug#1062122: TL;DR: Details on Libtrash
In 2002, libtrash was created by Manuel Arriaga, In the days before graphical file managers with their own trash collection, libtrash was a great little library that intercepted unlink(), open(), and rename() functions and moved deleted files to a user trash can. It accomplished this by being preloaded: LD_PRELOAD=/libpath/libtrash.so. But it also had a separate environment variable which could suspend trash collection, TRASH_OFF=NO|YES. TRASH_OFF=YES rm badfile would turn the trash off and really delete badfile. Since the user trash can was often in the user's home directory, I added functionality to specify a file size limit in what could be deleted. This prevented very large files from filling up the user trash can. Users can also specify file types to ignore, like C Object files, or compressed files with certain extensions. libtrash can also be configured to ignore whole directories, like /tmp or /var, and protect system files. In 2021, I migrated the awkward build system to autotools and it's been there since. The ROX desktop had a wrapper for libtrash, but I have found, that when preloaded, ROX passes all removed files to the user trash can. The last bit of code added improved the man pages, and also cleared out "ugly" macros and #define statements (Manuel's words, not mine!). I can't quite remember when I started using libtrash, but I'll guess it was in the mid 2000 decade. Manuel has "retired" from maintaining the program, and it is my responsibility now. It's a great little library and I look forward to having support to test and if appropriate, cross compiling for other platforms. /PH -- Peter Hyman
Bug#1056605: format output of man page
lrc parses a valid DEP-5 copyright file and notes the licenses of all files in the source tree. Licensecheck is then run, and the results compared. Differences between licenses in debian/copyright and the output of licensecheck are reported. It should be run in the top level of a cleaned Debian source tree, with a valid DEP-5 copyright file. The source tree should be clean, otherwise results may be contaminated by spurious reports on the build's generated files. It is advisable to run lintian first to ensure correct syntax of debian/copyright. The results are indicative only, and not a substitute for manual checking. It is intended to report obvious errors. The design intends to minimise false positives as much as is practical. However, false positives will occur if the spelling of the license short-string is not identical between the file and debian/copyright. This is quite likely with complex licensing such as 'and'/'or' constructs and specific exceptions. Only files with a copyright header are checked. False negatives may occur if licensecheck cannot determine a file's license. Files named copyright, copying, readme etc. are not checked as they often specify the licenses of other files rather than their own. (Reformating man page output for email)
Bug#1056605: Vcs moved
The Vcs has now moved to https://salsa.debian.org/debian/licenserecon
Bug#1056605: ITP: licenserecon -- Reconcile licenses from debian/copyright against license-check
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com * Package name : licenserecon Version : 1.0 Upstream Contact: Peter Blackman * URL : https://salsa.debian.org/PeterB/licenserecon * License : BSD-2-clause Programming Lang: Pascal Description : Reconcile debian/copyright licenses against licensecheck output Uses licensecheck to determine file licences and, if not 'UNKNOWN', checks them against Dep5 debian/copyright. Is intended as a partial replacement for license-reconcile (removed in 2019). I use this package for checking debian/copyright in other packages I maintain. Will need a sponsor. From the man page; === lrc DESCRIPTION Lrc parses a valid DEP-5 copyright file and notes the licenses of files in the source tree. Licensecheck is then run, and the results compared. Differences between licenses in debian/copyright and the output of licensecheck are reported. It should be run in the top level of a cleaned Debian source tree, with a valid DEP-5 copyright file. The source tree should be clean, otherwise results will be contaminated by spurious reports on the build's generated files. It is advisable to run lintian first to ensure correct syntax of debian/copyright. The results are indicative only, and not a substitute for manual checking. It is intended to report obvious errors. The design intends to minimise false positives as much as is practical. However, false positives will occur if the spelling of the license short-string is not identical between the file and debian/copyright. This is quite likely with complex licensing such as 'and'/'or' constructs and specific exceptions. Only files with a copyright header are checked. False negatives may occur if licensecheck cannot determine a file's license. Files named copyright, copying, readme etc. are not checked as they often specify the licenses of other files rather than their own. EXIT CODES 0: No differences found 1: Failure to run (no debian/copyright etc) 3: License differences found SAMPLE OUTPUT Sample output invoking lrc. SUCCESS: Parsing Source Tree Running licensecheck No differences found DIFFERENCES: Parsing Source Tree Running licensecheck d/copyright | licensecheck LGPL-2.1+ | GPL-2+ test/src/config/chan.c GPL-2+ | public-domain share/lua/int/dummy.lua GPL-2+ | LGPL-2.1+ modules/access/sr_common.h AUTHOR Peter Blackman SEE ALSO licensecheck (1) 2023-11-21 1 lrc(1) Manual page lrc(1) line 7/56 (END) (press h for help or q to quit)
Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Sat, Nov 04, 2023 at 06:05:41PM +0100, Andreas Henriksson wrote: > On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Tobias Heider > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: lzfse > > Version : 1.0 > > Upstream Authors: > > URL : https://github.com/lzfse/lzfse > > * License : BSD-3-Clause > > Description : LZFSE Compression library > > > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > > State Entropy coding. It targets similar compression rates at higher > > compression and decompression speed compared to deflate using zlib. > > > > I plan to maintain this as part of the bananas team. > > Calling all SO versioning experts! > > The upstream project does not have any shared object version set. > A downstream patch was introduced to set one: > https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch > > Upstream has seen no activity since 2017, so trying to interact is > assumed to not generate much. (sorry, I imagine you are already aware of what I am about to say, but still I think it's worth saying... Apologies if I'm lecturing, I think you may have been a DD longer than I have :)) This... may be a problem. This means that any fixes you have to make (security fixes, important bug fixes, or just improvements that really, really bug your sense of doing things right) will be specific to the Debian package, and unless the other packaging systems pick them up, with time things will diverge further and further. The best thing to do in this case is to - somehow - try to push things in a direction that ultimately leads to the library having active upstream developers. This may mean having you or somebody you know try to contact the current developers and ask to join them. In a close-to-the-extreme version of this, this may mean you (or somebody you know) taking over upstream development with the consent of the current developers. In a really, really extreme version, it may mean forking the project without the consent of the current developers and facing various kinds of weird things down the road, especially if they wake up one day and decide to carry on as usual, ignoring your fork. One thing to note that I have learned from bitter experience: you may feel that it would be fun and it would not be too difficult to take over upstream development, and doing this too many times may lead to a situation that you are the upstream developer for too many things and you cannot really give most of them enough attention. There is no single right answer here, but it would certainly be much, much, much better for everyone involved (including the end users of your Debian package, people who install something that uses this library) if there were an active upstream. > Also the ABI is unlikely to change (since > no changes are being made). Yeah... see above about the upstream developers waking up one day and deciding to carry on :) Also, it is possible that some packager from antoher packaging system decides to go ahead and fork the project... But still, those are all hypotheticals. > I've previously suggested that maybe it would be better to set a > debian-specific version (0d?), to avoid the theoretical situation > that upstream one day ships a different ABI under the 1 so version. > > I would welcome peoples input here on what you think is best from > the debian perspective. Obviously we're going to be incompatible with > everyone else[1], unless you install/runtime-depend-on the -dev package > for the unversioned so symlink. Please speak now before this is > submitted for NEW. When you say "incompatible with everyone else", how do other packaging systems handle this? Has this library been packaged somewhere else? It might be a good idea to do the same thing as some other packaging system... but it may also turn out that all of the current ones have chosen (possibly different) suboptimal ways to handle this, so being incompatible with them may turn out to be the best option for Debian itself. As above, there is no single right answer here. > FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS > containing embedded firmwares. See asahi-fwextract ITP: #1055206 > > Regards, > Andreas Henriksson > > > [1]: > https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch 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
Bug#1052135: ITP: check-build -- Check whether some example programs can be compiled and built
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team , r...@debian.org * Package name: check-build Version : 0.1.0 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/check-build * License : BSD-2-clause Programming Lang: Python Description : Check whether some example programs can be compiled and built The `check-build` tool can be used to build and test different programs in a temporary build directory. The programs are listed in a TOML configuration file, along with the commands to build and test them. A bundled copy of the check-build library is used in the libzstd autopkgtest to make sure that the C library's -dev package contains enough files so that a program that uses the library can be built. It will be removed in the next libzstd upload as soon as this package hits the archive. I will maintain this package as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#1050550: [Pkg-pascal-devel] RFA: winff -- graphical video and audio batch converter using ffmpeg or avconv
On Thu, 31 Aug 2023 16:37:30 +0200 Bastian Germann wrote: > Hi Peter, > > It would be helpful to maintain the git repo, so if you are not already > part of the Pascal Team, please consider joining. Otherwise, Paul might be > so kind to add you as a member only to that single repo. > > Thanks, > Bastian Agreed. It would be very helpful if I could update the VCS. I was about to mention this anyway. I'd be happy to join the team. Cheers, Peter
Bug#1050550: RFA: winff -- graphical video and audio batch converter using ffmpeg or avconv
I'd be happy to adopt winff Cheers, Peter
Bug#1050005: ITP: pdftopng -- Convert PDF to PNG
On Tue, Aug 22, 2023 at 01:24:42PM +0200, Mathieu Malaterre wrote: > On Fri, Aug 18, 2023 at 1:19 PM Marvin Renich wrote: > > > > * Elena Grandi [230818 05:27]: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Elena Grandi > > > > > > * Package name: pdftopng > > > Description : Convert PDF to PNG > > > > > > A command line tool and python library to convert PDFs to PNGs, based on > > > pdftoppm from poppler. > > uh ? > > % pdftoppm -h 2>&1| grep png > -png : generate a PNG file > > > > This is a dependency of camelot-py (#1049944) and I intend to maintain > > > it in the Python Team. > > > > Does pdftocairo from the poppler-utils package do what you need? If > > not, would it make sense to submit patches to add pdftopng to the > > poppler-utils package instead of creating a separate package for it? > > ...or at least document why pdftoppm is not suitable. I would imagine, since the original ITP also mentioned a Python project that requires this package, that the "Python library" part may be important: the upstream authors of the other project may have decided to use it, as a Python library, instead of fiddling with child process management by themselves. 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
Bug#1050212: [ITP]: python3-ajsonrpc -- Python JSON-RPC 2.0 implementation and asynchronous server powered by asyncio
Package: wnpp Severity: wishlist * Package name: python3-ajsonrpc Version : 1.2.0 Upstream Author : Kirill Pavlov * URL : https://github.com/pavlov99/ajsonrpc * License : MIT Programming Lang: Python salsa: https://salsa.debian.org/python-team/packages/ajsonrpc JSON-RPC 2.0 implementation and asynchronous server powered by asyncio ajsonrpc is Lightweight JSON-RPC 2.0 protocol implementation and asynchronous server powered by asyncio. This library is a successor of json-rpc and written by the same team. Features: - Full JSON-RPC 2.0 implementation - Async request manager that handles the protocol - Vanilla Python, no dependencies - API server setup in 1 min - Same development team as json-rpc, largely compatible code
Bug#1042088: Control and other related files for build
Here are the build files for review. Comments appreciated. -- Peter Hyman lrzip-next_0.12.0-1.debian.tar.xz Description: application/xz
Bug#1042088: ITP: lrzip-next -- lrzip-next is an enhanced version of the lrzip package with many new features.
Package: wnpp Severity: wishlist Owner: Peter Hyman X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : lrzip-next * Version : 0.12.0 * Upstream Contact: Peter Hyman * URL : https://github.com/pete4abw/lrzip-next * License : GPL * Programming Lang: C, C++, Assembler, Bash Shell * Description : lrzip-next is an enhanced version of the lrzip package with many new features. lrzip-next is the successor to Con Kolivas' lrzip program. It is a compression program that uses a two stage process. First, the file is pre-processed using Andrew Tridgell's rzip functions that hashes the source file over long range. Second, the hashed and data streams are compressed by user-selected compression backends. These are: bzip2, bzip3, gzip, lzo, lzma, zpaq, and zstd. Alternately, a pre-processing BCJ filter for multiple architectures can improve binary executable compressions. Finally, a Delta offset filter can be applied. Very useful for WAV or PCM files. lrzip-next is current with lzma SDK 23.01 and zpaq SDK 7.15. Archives can be hashed or compressed using any of thirteen hashes or two different encryption algorithms: AES-128 or AES-256. lrzip-next will coexist with lrzip as no installed filenames overlap. - why is this package useful/relevant? lrzip-next is under active development. it includes additional compression backends: bzip3, zstd. it can optionally use BCJ and Delta filters for pre-processing. it uses the upstream x86_64 Assembler code to improve decompression (up to 40% faster) and compression time. it uses libgcrypt for hashing and encryption functions. - Is it a dependency for another package? NO - Do you use it? YES - If there are other packages providing similar functionality, how does it compare? lrzip uses lzma SDK 9. lrzip-next uses lzma SDK 23.01. lrzip uses zpaq SDK 4, lrzip-next uses the last zpaq SDK 7.15. lrzip-next keeps current with all lzma upstream fixes and enhancements. (zpaq is no longer maintained). lrzip supports 32 bit systems. lrzip-next only support x64 systems. lrzip-next uses all 9 lzma compression levels, lrzip only 7. lrzip-next allows custom lzma dictionary, bzip3 and zpaq block sizes, zstd compression levels to 22. lrzip-next adds BCJ and Delta pre-filters from lzma SDK. lrzip-next allows for archive comments. lrzip-next has improved user output, man pages, and a full wiki. lrzip-next is under active development. lrzip has been on version 0.6xx since 2011. lrzip-next tracks lrzip development and any CVE or other critical fixes are imported where relevant. - How do you plan to maintain it? inside a packaging team? I have written a package for it, but would appreciate being part of a team. I would need support porting and testing lrzip-next to other 64-bit architectures. - Are you looking for co-maintainers? do you need a sponsor? Laszlo Boszormenyi (GCS) is the maintainer for lrzip. As I am new to Debian (Slackware since 1997), It makes sense that he could support me or others involved in compression applications. Thank you -- Peter Hyman
Bug#1039051: RFA: gforth -- GNU Forth Language Environment
Package: wnpp Severity: normal X-Debbugs-Cc: gfo...@packages.debian.org, r...@debian.org Control: affects -1 + src:gforth I request an adopter for the gforth package. Turns out that in the past couple of years I have not given it enough care and attention. There is a Git repository containing all my Debian packaging work at https://gitlab.com/gforth/pkg-debian-full The package was in good shape at the time of its last update, but things have moved on since then. Notably, I tried to bring in some new upstream beta versions every now and then, but they failed their build-time tests, and it would appear overly optimistic to keep pretending that I will track those test failures down. The package description is: This is the GNU'ish implementation of a Forth programming environment. . Forth, as a language, is best known for being stack-based, and completely extensible. Each Forth environment provides one or more dictionaries of pre-defined words, and programming in Forth consists of defining and executing new words that are combinations of previously defined words. It has been said that learning Forth changes forever the way you think about writing programs. . For more information about Forth, visit the Forth Interest Group web site at http://www.forth.org/fig.html. Thanks in advance to whomever picks this package up! signature.asc Description: PGP signature
Bug#1035759: ITA: sniproxy -- Transparent TLS and HTTP layer 4 proxy with SNI support
control: retitle -1 ITA: sniproxy -- Transparent TLS and HTTP layer 4 proxy with SNI support control: owner -1 ! Thanks for your work on sniproxy over the years! 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
Bug#1035747: ITP: cevomapgen -- External Map Generator for C-Evo
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com * Package name : cevomapgen Version : 26 Upstream Contact: * URL : https://sourceforge.net/projects/cevomapgen/ * License : GPL3+ Programming Lang: Lazarus/FPC Description : External Map Generator for C-Evo Generates more varied maps than the in-game generator, with greater control, and allows much faster generation of novel or extreme worlds than using the map editor. Intended for use with c-evo-dh and other versions of C-evo Regards, Peter
Bug#1035103: re : ITP: grimripper -- Graphical audio CD ripper and encoder
Upstream have now renamed the project to GrimRipper https://gitlab.gnome.org/Salamandar/GrimRipper
Bug#1035103: ITP: cdreaper -- Graphical audio CD ripper and encoder
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com * Package name : cdreaper Version : 3.0.0 Upstream Contact: Salamandar * URL : https://gitlab.gnome.org/Salamandar/Reaper * License : GPL2 Programming Lang: C Description : Graphical audio CD ripper and encoder Can be used to save tracks from Audio CDs. Main features: * Supports WAV, MP3, Ogg Vorbis, FLAC, and Wavpack audio files * Uses CDDB to name and tag each track * Can encode to multiple formats in one session * Creates M3U playlists * Allows for each track to be by a different artist * Does not require a specific desktop environment (just Gtk3) This is the Gtk3 fork of asunder (it now has its own name) I have called this package cdreaper, as the name reaper is already in use elsewhere; https://repology.org/project/reaper/versions I will maintain the package myself and need a sponsor. The package has been set up on the AUR and Open Build Service. https://aur.archlinux.org/packages/cdreaper https://build.opensuse.org/package/show/home:PeterBBB/cdreaper
Bug#1033413: ITP: profile-cleaner -- Reduces browser profile size by cleaning their sqlite databases
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com * Package name : profile-cleaner Version : 2.44 * URL : https://github.com/graysky2/profile-cleaner * License : Expat Programming Lang: Bash Description : Reduces browser profile size by cleaning their sqlite databases Reduces the size of browser profiles by organizing their sqlite databases using sqlite3's vacuum and reindex functions. The term "browser" is used loosely since profile-cleaner happily works on some email clients and newsreaders too. I will maintain the package myself, and will need a sponsor.
Bug#1030757: ITP: python-parse-stages -- Parse a mini-language for selecting objects by tag or name
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-parse-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/parse-stages * License : BSD-2-clause Programming Lang: Python Description : Parse a mini-language for selecting objects by tag or name This library is mostly useful for command-line parsing by other tools like `tox-stages` and `nox-stages`. It may be used to parse e.g. a command-line specification like `@check and not pylint` or `@tests or ruff` and then match it against a list of objects that have names and lists of tags. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#1030756: ITP: python-test-stages -- Run Tox, Nox, etc. tests in groups, stopping on errors
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-test-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/test-stages * License : BSD-2-clause Programming Lang: Python Description : Run Tox, Nox, etc. tests in groups, stopping on errors The `test-stages` library provides command-line tools that wrap Python test environment runners such as Tox or Nox, invoking them so as the various tests are run in parallel, in groups, as specified on the command line. This allows the fastest tests to be run first, and the slower ones to only be started if it makes sense (e.g. if tools like [ruff] or [flake8] did not uncover any trivial syntax errors). The `tox-stages` tool runs Tox with the specified groups of test environments, stopping if any of the tests in a group should fail. This allows quick static check tools like e.g. `ruff` to stop the testing process early, and also allows scenarios like running all the static check tools before the package's unit or functional tests to avoid unnecessary failures on simple errors. The syntax for grouping the test environments to be run is described in the `parse-stages` library's documentation. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#968495: ITP: c-evo-dh -- C-evo: Distant Horizon, Empire building game
New Upstream version Package name : c-evo-dh Version : 1.7-1 Upstream contact : Peter URL : https://sourceforge.net/projects/c-evo-eh/ License : CC-BY-3.0, CC-BY-SA-3.0-US, CC0-1.0, GPL-2+ Vcs : https://salsa.debian.org/PeterB/c-evo-dh Section : games Changes since 1.6 Update Tutorial doc Enlarge Buy button on City Screen Improve Spanish and Portuguese translations Fix regression in multi-buttons on Free Player Setup form. Remove writelns not in debug blocks Also, changes to packaging. Add .gitignore Update gbp.conf Removed conflicts/breaks & QT5 binary packages following FTP Master's reject.
Bug#1026975: ITP: python-toml -- library for parsing and creating TOML
On Sun, Dec 25, 2022 at 09:11:29AM -0300, Josenilson Ferreira da Silva wrote: > Package: wnpp > Severity: wishlist > Owner: Josenilson Ferreira da Silva > X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com > > * Package name: python-toml > Version : 0.10.2 > Upstream Author : William Pearson > * URL : https://github.com/uiri/toml > * License : MIT/expat > Programming Lang: Python > Description : library for parsing and creating TOML > > this package is a dependency for "dom-toml" > Where "dom-toml" is a required dependency for the "whey" package: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204 Er, is this not https://tracker.debian.org/pkg/python-toml already? 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
Bug#968495: ITP: c-evo-dh -- C-evo: Distant Horizon, Empire building game
New Upstream version * Package name : c-evo-dh Version : 1.6.0-1 Upstream contact : Peter * URL : https://sourceforge.net/projects/c-evo-eh/ * License : CC-BY-3.0, CC-BY-SA-3.0-US, CC0-1.0, GPL-2+ * Vcs : https://salsa.debian.org/PeterB/c-evo-dh Section : games Changes since 1.1 c-evo-dh (1.6) Restore CityType drag cursor (lost with Lazarus 2.2.0) Remove binary cursor files Change package & folder names from c-evo to c-evo-dh Update Docs -- Wed, 14 Dec 2022 c-evo-dh (1.5) More fixes to internationalisations (es, de, it, pt, ru) Update Appstream metadata Remove example maps that have missing special resources -- Mon, 12 Dec 2022 c-evo-dh (1.4) Fixes to internationalisation of in game help -- Sun, 11 Dec 2022 c-evo-dh (1.3) Fixes to Windows build Include Spanish and Portuguese translations -- Sun, 04 Dec 2022 c-evo-dh (1.2) Reduce Spaceship costs to 50% of original Support random resource placement by external map generators Include Windows build Remove example game (incompatible due to Spaceship costs) -- Tue, 27 Sep 2022
Bug#982140: ITP: fuzzel -- Wayland-native application launcher
On Mon, Nov 28, 2022 at 12:21:13PM -0500, Antoine Beaupré wrote: > So this is now in unstable, but blocked from migrating because it was a > binary upload. > > I'm happy to do a new source-only upload, but are there other changes > you have pending we could bundle up in there? Thanks, yes, I have pushed fuzzel 1.8.2-2 [1] which resolves a FTBFS due to a recent change in the fcft Debian package. There had already been a failed attempt [2] to rebuild on amd64. (Are these automatic after a new package enters the archive, or manually triggered?) [1] https://salsa.debian.org/swaywm-team/fuzzel/-/commit/c4885f626cdfb9ce2ca26afa46fdcce76f309b1c [2] https://buildd.debian.org/status/fetch.php?pkg=fuzzel=amd64=1.8.2-1%2Bb1=1669472282=0 Thanks, Peter
Bug#982140: ITP: fuzzel -- Wayland-native application launcher
Dear FTP Team, Regarding the embedded copy of nanosvg, please see the investigation into prior occurrences in the Debian archive [1], and the reasoning for why the use of nanosvg is preferable over librsvg [2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982145#74 [2] https://salsa.debian.org/swaywm-team/fuzzel/-/commit/9f111d2252e0047a14459254a77d3d04e5c1b57e Thanks, Peter
Bug#1020721: ITA microsocks
package wnpp retitle 1020721 ITA: microsocks -- tiny, portable SOCKS5 server owner 1020721 ! thanks Hi, Thanks for your work on the microsocks package. I will adopt it and update it to the new upstream version. G'luck, Peter signature.asc Description: PGP signature
Bug#968495: ITP: c-evo-dh -- C-evo: Distant Horizon, Empire building game
Rebranding as c-evo-dh (fork of c-evo-nh) * Package name : c-evo-dh Version : 1.1 Upstream Author : pe...@pblackman.plus.com * URL : http://www.c-evo.org/ https://sourceforge.net/projects/c-evo-eh/ * License : GPL-2+, CC-BY-3.0, CC0-1.0, CC-BY-SA-3.0-US Programming Lang: FPC / Lazarus Description : Empire Building Game
Bug#1016130: ITP: asdf -- multiple language runtime version manager
On Wed, Jul 27, 2022 at 02:24:36PM -0400, matt wrote: > Package: wnpp > Severity: wishlist > Owner: Matt Barry > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: asdf > Version : 0.10.2 > Upstream Author : Akash Manohar J > * URL : https://asdf-vm.org ITYM https://asdf-vm.com here. > * License : MIT > Programming Lang: Bash > Description : multiple language runtime version manager > > asdf is a CLI tool that can manage multiple language runtime > versions on a per-project basis. It is like gvm, nvm, rbenv > and pyenv (and more) all in one! Simply install your language's > plugin! 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
Bug#1015863: ITP: qt6ct -- Qt6 Configuration Tool
Fixed version 0.5-2 on Mentors here https://mentors.debian.net/package/qt6ct/
Bug#1015863: ITP: qt6ct -- Qt6 Configuration Tool
Please note, version 0.5-1 of qt6ct requires qt6-qpa-plugins to be installed Peter B
Bug#1015863: ITP: qt6ct -- Qt6 Configuration Tool
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com Owner: pe...@pblackman.plus.com * Package name : qt6ct Version : 0.5-1 Upstream Author : Ilya Kotov * URL : https://github.com/trialuser02/qt6ct * License : BSD-2-clause Programming Lang: C++ Description : Qt6 Configuration Tool qt6ct allows Qt6 program settings to be adjusted on desktops other than KDE. It provides the same features as qt5ct does for qt5 programs. See https://tracker.debian.org/pkg/qt5ct I'm packaging this program, as I found the fonts for qt6 programs on Xfce4 could not be adjusted without it.
Bug#913079: ITP: strawberry -- an audio player and music collection organizer fully based on Qt5
Updating the ITP as all recent comments went to the RFS https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010663 Strawberry is packaged here https://salsa.debian.org/debian/strawberry and is currently in the NEW queue https://ftp-master.debian.org/new/strawberry_1.0.5-1.html Cheers, Peter
Bug#1014096: RM: rust-common-failures -- ROM; needs removed rust-failure
I just uploaded new package rust-common-failures now sitting in NEW, but then realized that rust-failure which it depends on is removed from Debian (see bug#973298). Please drop rust-common-failures from NEW queue - it is useless. This is not entirely correct, rust-failure was indeed removed from unstable, but it was re-instated the next day.
Bug#913079: ITP: strawberry -- an audio player and music collection organizer fully based on Qt5
Hi, I'd like to see Strawberry make it into Debian for Bookworm, but there has been no visible progress for over a year. Assuming this ITP has been abandoned, I'll like to take it over, and will need a sponsor. @Tony, Louis Hoping you are still interested in Strawberry, I have packaged the latest version 1.0.4 and uploaded to Mentors. https://mentors.debian.net/package/strawberry/ Cheers, Peter https://qa.debian.org/developer.php?login=pe...@pblackman.plus.com
Bug#1006621: ITP: boofcv -- Real-time computer vision library
Hopefully a 1000 projects don't need to be updated from Gradle 4 to Gradle 7! > Debian does not do out-of-git builds (.git directory is removed from > sources prior to build), thus I guess this plugin would not be of much > use (but I may be wrong). > Still required since it creates a BoofVersion.java file that's needed. If it can't find Git information it fills in that field with blank or unknown. Cheers, - Peter
Bug#1006621: ITP: boofcv -- Real-time computer vision library
Instead of updating the "gradle" command could we just install a new "gradle7" command that points to Gradle 7 instead? I don't think Gradle is very backwards compatible so that might be the easiest solution. For Jars that BoofCV downloads, It doesn't download anything outside of Gradle. It uses a Gradle plugin i created called gversion to automatically generate version info and a set of tools to do other auto generation tasks: https://plugins.gradle.org/plugin/com.peterabeles.gversion https://github.com/lessthanoptimal/Auto64Fto32F Once the Gradle issue gets resolved we could then start adding these dependencies. Cheers, - Peter On Thu, Mar 24, 2022 at 5:06 AM Andrius Merkys wrote: > Dear Peter and Dima, > > Sorry for the delay. Somehow I did not receive any mails sent to > 1006...@bugs.debian.org (will subscribe), thus I only now noticed your > conversation after accidentally revisiting the bug page. > > Good to meet you too, Peter! > > First of all, regarding Cephis, my original reason to package BoofCV. It > depends on io, feature and visualize modules of BoofCV v0.17. AFAIK, > these should be static image analysis tools, thus stripping away more > complicated video and webcam support should make things much easier for > now. Of course, in the long run it would be nice to support video and > webcam parts of BoofCV in Debian as well. > > Regarding Gradle. Debian has 4.4.1 now and updating it is complicated. > It would be nice to ask its maintainers in Debian to understand what are > the current blockers. Gradle wrapper cannot be used as downloads in the > build time are not allowed in Debian. Even more generally, Debian builds > can only rely on software which is built from source on Debian build > machines. > > For now I see upgrading Gradle in Debian as the best solution to the > build issue. Simplifying/changing the build system is a viable solution > too, but I believe this would need much work and add maintenance burden > on Peter. Discussion in [1] gives me some hope Gradle will be updated > soon. I think it is worth pinging its participants. > > Peter, you mention BoofCV build system downloading some JARs. Maybe we > could build these JARs in Debian as separate packages and use them in > BoofCV build? If Gradle blocker goes away, these might be the next > blockers. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926714 > > Best wishes, > Andrius > -- "Now, now my good man, this is no time for making enemies."— Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan.
Bug#1008207: ITP: remrun -- copy a file to a remote host and execute it there
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@ringlet.net * Package name: remrun Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://gitlab.com/ppentchev/remrun/ * License : BSD-2-clause Programming Lang: POSIX shell Description : copy a file to a remote host and execute it there The remrun tool may be useful for one-off execution of a series of commands or a complicated command that does not easily lend itself to shell quoting and escaping via SSH. It copies the specified file to the remote host using SSH under a temporary filename, executes it on the remote side, then removes the temporary file. signature.asc Description: PGP signature
Bug#1006621: ITP: boofcv -- Real-time computer vision library
Based on Dima's comments. Is there any reason we can't just use the Gradle Wrapper? That way each project can use the version of Gradle it works with instead of single version for all projects. The only reason I see to not use Gradle wrapper is because it will download its dependencies and maybe for some reason that's not allowed. BoofCV does have a complex build system because it auto generates code. So you would need to download the jars the auto generate system needs then build a few classes. Now you're ready to create all the code you need for this library. At this point, you can in theory javac the entire project as Dima suggested. Assuming we don't care about mirroring the jar files that are published on Maven central. This would be equivalent of making one large .so instead of 15 little .so. If the end goal is some of the tools included with BoofCV (e.g. calibration and batch scanning of 2d barcodes) into Debian then that's perfectly fine. My preference is using gradle wrapper since that's the least amount of effort for me to do and it's easy to mangle the existing build system. Peter: if I do the build as described in the instructions, using the > "gradlew" commands, and I grep the log for "javac", would that give me > the bulk of the commands that are needed? What else is needed other than > the "javac" commands? > Hmm been a while since I've used javac directly. Probably the easiest way would be to get a file list using "find" and seeing if it blows up when you give it several hundred files or so. - Peter P.S. I'm going to be a bit erratic when I reply for the next couple of weeks at least. -- "Now, now my good man, this is no time for making enemies."— Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan.
Bug#1006621: ITP: boofcv -- Real-time computer vision library
Hi Andrius, Good to meet you and thanks for the first attempt at getting BoofCV in Debian. To keep things simple, that approach that I'm thinking of is to add "libboofcv-core" to Debian first, which has all the core functionality and can be added to a project now by referencing "boofcv-core" module, which just references several other modules in BoofCV. You might have already added all the required external dependencies. The end goal is to get "BoofCV Applications" into debian. If you strip away video and webcam support it would be much easier, but less functional. Also need to add some tooling to make it more user friendly from a command line. Code modifications will probably be needed to fail gracefully if something is missing. Question: Does your use case require anything outside of "core"? Now on to Gradle. How ancient is Gradle in Debian? BoofCV recently upgraded to Gradle 7 to fix IntelliJ integration issues. Downgrading to Gradle 5 is possible. The main reason it was updated was for support of automatic JDK downloading. Prior to that upgrade, there had been a lot of confusion where people would try building it with an ancient JDK and getting cryptic error messages. I'm hoping to stick with Gradle 7 on my projects for a while. Cheers, - Peter -- "Now, now my good man, this is no time for making enemies."— Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan.
Bug#1006606: ITP: python-cfg-diag -- common configuration-storage class with a .diag() method
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, r...@debian.org * Package name: python-cfg-diag Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://github.com/storpool/python-cfg_diag * License : BSD-2-clause Programming Lang: Python Description : common configuration-storage class with a .diag() method This module provides four classes that may be used as base classes for storing program runtime configuration with a `verbose` boolean field. The classes provide a `.diag(msg)` method that decides whether to output the provided message based on the value of the object's `verbose` field. I intend to maintain this package within the Python packaging team. signature.asc Description: PGP signature
Bug#1006483: ITP: python3-mergedeep -- A deep merge function for Python
On Sat, Feb 26, 2022 at 08:12:27AM +, Edward Betts wrote: > Package: wnpp > Severity: wishlist > Owner: Edward Betts > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org > > * Package name: python3-mergedeep > Version : 1.3.4 > Upstream Author : Travis Clarke > * URL : https://github.com/clarketm/mergedeep > * License : MIT > Programming Lang: Python > Description : A deep merge function for Python I think you may have seen this already, but Carsten Schoenert filed #1006479 just today for the same library :) Thanks to both of you for your work! 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
Bug#1006178: ITP: tox-delay -- run some Tox tests after others have completed
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org * Package name: tox-delay Version : 0.1.0 Upstream Author : Peter Pentchev * URL : https://devel.ringlet.net/devel/tox-delay/ * License : BSD-2-clause Programming Lang: POSIX shell Description : run some Tox tests after others have completed The tox-delay tool postpones the run of the specified Tox environments after the run of all the others has completed successfully. This may be useful if e.g. there are unit or functional test environments, which it would make no sense to run if the static checkers (pylint, mypy, etc) find problems. signature.asc Description: PGP signature
Bug#1005131: ITP: utf8-locale -- detect a UTF-8-capable locale for running child processes in
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org * Package name: utf8-locale Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://gitlab.com/ppentchev/utf8-locale * License : BSD-2 Programming Lang: Python, Rust Description : detect a UTF-8-capable locale for running child processes in Sometimes it is useful for a program to be able to run a child process and more or less depend on its output being valid UTF-8. This can usually be accomplished by setting one or more environment variables, but there is the question of what to set them to - what UTF-8-capable locale is present on this particular system? This is where the utf8_locale module comes in.
Bug#1003281: ITP: bakunbak -- Easily .bak a file or folder, then restore it.
On Fri, Jan 07, 2022 at 09:32:18AM -0500, Michael Webster wrote: > Package: wnpp > Severity: wishlist > Owner: Michael Webster > X-Debbugs-Cc: debian-de...@lists.debian.org, miketwebs...@gmail.com > > * Package name: bakunbak > Version : 1.0.0 > Upstream Author : Michael Webster > * URL : https://github.com/mtwebster/bakunbak > * License : GPL > Programming Lang: Python > Description : Easily .bak a file or folder, then restore it. > > This is a simple convenience tool for making temporary 'backup' > copies of files or folders, by adding and removing .bak to their > filenames. A limited number of options allow copying instead of > moving, and forcing overwrite of existing files. > > - why is this package useful/relevant? For people who do frequent >tests on packages that utilize configuration files or folders, >backing up and restoring previous configurations can become >tedious after a time. This reduces effort. > - is it a dependency for another package? It is standalone.. > - Do you use it? Yes frequently for testing browser package >updates. > - If there are other packages providing similar functionality, >how does it compare? I've found no other packages (though >it's possible something exists in utility/bin package >bundles that doesn't get mentioned in package descriptions. JFYI, are you aware of the "rename" package? I was going to ask whether you are aware of Perl's "prename" command-line utility, but it seems that it has been broken out some time ago... just goes to show my age, I guess :) Also, there are several packages (e.g. krename, gprename, mrename) that have a slightly different focus: rename a lot of files, usually as a one-time thing, with a graphical interface, but yeah, that's not exactly what your tool does. > - How do you plan to maintain it? It is a simple package, I >will maintain it myself. > - Are you looking for co-maintainers? No. > - Do you need a sponsor? I imagine so, as I've not previously >been involved in packaging for Debian. 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
Bug#1001612: ITP: deltarpm -- Tools to create and apply deltarpms
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org, team+pkg-...@tracker.debian.org * Package name: deltarpm Version : 3.6.3 Upstream Author : Michael Schroeder * URL : https://github.com/rpm-software-management/deltarpm * License : BSD-3-clause Programming Lang: C, Python Description : Tools to create and apply deltarpms This will bring the deltarpm package back into Debian. It was removed as part of the clean-up of the old Python-2-only createrepo-related tools; however, it is now possible to use deltarpm with the new set of createrepo-c/libmodulemd2/libdrpm0 packages, and it will help run the libdrpm upstream testsuite to its full extent. This is the long description of the package: A deltarpm contains the differences between an old and a new version of an RPM. This makes it possible to recreate the new RPM from the deltarpm and the old RPM. . On Debian and derived systems these tools may be useful for creating and maintaining repositories of RPM packages. I will maintain this package as part of the Debian RPM packaging team. signature.asc Description: PGP signature
Bug#990291: ITP: nftfw -- nftables firewall builder for Debian - updated info
Package: wnpp Severity: wishlist Owner: Peter Collinson mailto:supp...@nftfw.uk>> * Package name: nftfw Version : 0.9.4 Upstream Author : Peter Collinson mailto:supp...@nftfw.uk>> * URL : https://mentors.debian.net/package/nftfw/ <https://github.com/pcollinson/nftfw> * License : MIT/X Programming Lang: Python Description : nftables firewall builder for Debian DSC file: https://mentors.debian.net/debian/pool/main/n/nftfw/nftfw_0.9.4-1.dsc <https://mentors.debian.net/debian/pool/main/n/nftfw/nftfw_0.9.4-1.dsc> Introduction Here is the current text in the debian/control file: The nftfw package builds firewalls for nftables. Configuration is based on files stored in directories in /etc/nftfw. For example, adding a new IP address to the whitelist is done by creating a file named for the IP address in the whitelist.d directory. Adding a new rule permitting access to a port just takes the addition of a suitably named file in incoming.d. Blacklisting address ranges is done by adding a CIDR address to a file in blacknets.d. . nftfw can automatically maintain the blacklist by efficiently scanning log files using regular expressions and adding miscreant IP addresses into blacklist.d. It maintains a database of activity and will timeout the entries after a user-defined period. When an IP is blocked, nftfw allows for feedback from nftables to notice and maintain blocking for frequent attempts from unwanted visitors. . nftfw makes extensive use of nftables sets to maintain exclusion and inclusion lists. It tries to minimise changes to the live firewall by only updating sets that have changed. It adds its created statements to an nftables template that can be modified to extend the firewall setup if needed. . After installation, some configuration is needed to make the system active, see /usr/share/doc/nftfw/README.Debian . The package is written and developed in Python 3.7. More information can be found on Github, there are several documents in the 'docs' directory that I've written first for manual installation and recently Debian packaging. These are in .md, HTML and PDF formats. Once I have this bug number I will be uploading the binary package to github. What's the history of this project? --- nftfw is based on work done by Patrick Cherry for his hosting company in the UK, Bytemark. His system was written in Ruby and was part of a complete management system called Symbiosis for Debian servers. The firewall part drove iptables. The company was sold and the buyer wasn't really interested. Mythic Beasts forked Symbiosis into Sympl and I moved to this new company as a customer. At pretty much the same time, Debian Buster was released with the switch to nftables. I wanted to fix some of the problems that I saw in the original system and decided to start from scratch writing a new firewall system in Python and aiming it at nftables. What I liked about Patrick's approach was the use of what is perhaps the original UNIX philosophy - everything is done in files. This firewall is controlled by an nft template file, which is editable so it can be extended - and then a bunch of specifically named files controlling the firewall in known locations. nftfw makes extensive use of sets, and tries never to reload the complete firewall when a set is changed. There are problems in nftables with some types of set, (I've reported that upstream and they will eventually be fixed I understand) that mean that under some circumstances partial loading doesn't work - and the whole table needs reloading. The system includes a module to scrape log files for attacks, and injects the IP address into blacklist. It can also can scan kernel logs for nftables logging so that sites that keep repeatedly returning can be kept out until they stop. Feedback from the scanner is a big win, bots keep bashing at the door and they are kept out. Log scanning and blocking is also done by fail2ban of course. The nftfw system is implemented because it was part of the original system and I was looking for a drop-in alternative for the Symbiosis system. Also, starting with nftables as a target has meant a re-appraisal of how the system should work. Where is the project? I started nftfw because I was sick of my systems being under attack from all and sundry. It's been running on two different machines that I run for a little over 18 months, and also has been used by some others sys admins who are Mythic Beast customers. There are a few stars on Github, but I have no idea if these people are using it. nftfw was originally installed on these machines from github source. It didn't seem to fit the Python packaging model because it's part of a system and not an application or library. It was loaded into Github in April of 2020 and has been largely stable since then. There has been the odd coding error, or misunderstanding of
Bug#989842: ITA: alttab -- task switcher for minimalistic WMs or standalone X session
retitle 989842 ITA: alttab -- task switcher for minimalistic WMs or standalone X session owner 989842 ! thanks Hi, Thanks for taking care of alttab, both upstream and in Debian! I will prepare a targeted upload that fixes the RC bug without a full upgrade to the new upstream version, since this is a bit more likely to be accepted by the release team at this stage in the freeze, and then I'll upload the new version to experimental. Thanks again, and keep up the great work! 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
Bug#990291: ITP: nftfw -- an nftables firewall builder for Debian
Package: wnpp Severity: wishlist Owner: Peter Collinson * Package name: nftfw Version : 0.9.0 Upstream Author : Peter Collinson * URL : https://github.com/pcollinson/nftfw * License : MIT/X Programming Lang: Python Description : an nftables firewall builder for Debian Introduction Here is the current text in the debian/control file: The nftfw package builds firewalls for nftables. Configuration is based on files stored in directories in /etc/nftfw. For example, adding a new IP address to the whitelist is done by creating a file named for the IP address in the whitelist.d directory. Adding a new rule permitting access to a port just takes the addition of a suitably named file in incoming.d. Blacklisting address ranges is done by adding a CIDR address to a file in blacknets.d. . nftfw can automatically maintain the blacklist by efficiently scanning log files using regular expressions and adding miscreant IP addresses into blacklist.d. It maintains a database of activity and will timeout the entries after a user-defined period. When an IP is blocked, nftfw allows for feedback from nftables to notice and maintain blocking for frequent attempts from unwanted visitors. . nftfw makes extensive use of nftables sets to maintain exclusion and inclusion lists. It tries to minimise changes to the live firewall by only updating sets that have changed. It adds its created statements to an nftables template that can be modified to extend the firewall setup if needed. . After installation, some configuration is needed to make the system active, see /usr/share/doc/nftfw/README.Debian . The package is written and developed in Python 3.7. More information can be found on Github, there are several documents in the 'docs' directory that I've written first for manual installation and recently Debian packaging. These are in .md, HTML and PDF formats. Once I have this bug number I will be uploading the binary package to github. What's the history of this project? --- nftfw is based on work done by Patrick Cherry for his hosting company in the UK, Bytemark. His system was written in Ruby and was part of a complete management system called Symbiosis for Debian servers. The firewall part drove iptables. The company was sold and the buyer wasn't really interested. Mythic Beasts forked Symbiosis into Sympl and I moved to this new company as a customer. At pretty much the same time, Debian Buster was released with the switch to nftables. I wanted to fix some of the problems that I saw in the original system and decided to start from scratch writing a new firewall system in Python and aiming it at nftables. What I liked about Patrick's approach was the use of what is perhaps the original UNIX philosophy - everything is done in files. This firewall is controlled by an nft template file, which is editable so it can be extended - and then a bunch of specifically named files controlling the firewall in known locations. nftfw makes extensive use of sets, and tries never to reload the complete firewall when a set is changed. There are problems in nftables with some types of set, (I've reported that upstream and they will eventually be fixed I understand) that mean that under some circumstances partial loading doesn't work - and the whole table needs reloading. The system includes a module to scrape log files for attacks, and injects the IP address into blacklist. It can also can scan kernel logs for nftables logging so that sites that keep repeatedly returning can be kept out until they stop. Feedback from the scanner is a big win, bots keep bashing at the door and they are kept out. Log scanning and blocking is also done by fail2ban of course. The nftfw system is implemented because it was part of the original system and I was looking for a drop-in alternative for the Symbiosis system. Also, starting with nftables as a target has meant a re-appraisal of how the system should work. Where is the project? I started nftfw because I was sick of my systems being under attack from all and sundry. It's been running on two different machines that I run for a little over 18 months, and also has been used by some others sys admins who are Mythic Beast customers. There are a few stars on Github, but I have no idea if these people are using it. nftfw was originally installed on these machines from github source. It didn't seem to fit the Python packaging model because it's part of a system and not an application or library. It was loaded into Github in April of 2020 and has been largely stable since then. There has been the odd coding error, or misunderstanding of how to do things, but I would say that the code is well exercised now. Once it was in Github, it provoked significant attacks from all over the world, and mostly from CN. At one point on my public machine, where its website lives (https
Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.
Just done some reviewing/tweaking. I've pushed the following changes to the git repo, please tell me if you have any objections. I added a gpb.conf to make git-buildpackage actually use pristine tar and hence result in an orig tarball that was consistent with what is already in Ubuntu. I found the clean target was not cleaning up the "egg-info" so I added a command to do that. I added a closes: entry for the ITP bug. --- That leaves one issue that I think still needs to be sorted before I sponsor the package. The file "copyrights" has no license header and the git history says it was copied but not where from. Poking around I discovered a script of the same name in gpiozero, containing what appears to be the same code and committed by you with a commit message of "create copyright header", so I presume this script is entirely your work, assuming it is I would suggest adding a copyright header upstream and then picking the commit up as a Debian patch until there is another upstream release. Finally would you consider adding me as a co-maintainer.
Bug#988689: ITP: 7zip -- 7-Zip file archiver
Hi Hiroshi, On 18.05.21 02:07, YOKOTA Hiroshi wrote: * Package name: 7zip Version : 21.02 Upstream Author : Igor Pavlov * URL : https://www.7-zip.org/ * License : LGPL with "unRAR license restriction" ( https://www.7-zip.org/license.txt ) Programming Lang: C, C++, Asm Description : 7-Zip file archiver 7-Zip is a file archiver with a high compression ratio. is this different from https://tracker.debian.org/pkg/p7zip Best regards, Peter
Bug#986889: ITP: repopush -- safely rsync a package repository to another location
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: repopush Version : 0.1.0 Upstream Author : Peter Pentchev * URL : https://devel.ringlet.net/net/repopush/ * License : BSD-2-clause Programming Lang: POSIX shell Description : safely rsync a package repository to another location The *repopush* tool is yet another program that helps with copying the various package files and repository metadata from one OS package repository to another, taking care to copy and remove files in such a way as to never have the remote repository present an inconsistent view. This is done by first copying the new package files, then copying the new metadata files, then removing the outdated metadata files, and only then removing the outdated package files. . The *repopush* tool supports APT and YUM repositories and figures out which one to handle by analyzing the contents of the local repository. signature.asc Description: PGP signature
Bug#986288: ITP: poke -- GNU poke, an interactive, extensible binary editor
On Fri, Apr 02, 2021 at 03:18:40PM +0200, Hilko Bengen wrote: > Package: wnpp > Owner: Hilko Bengen > Severity: wishlist > > * Package name: poke > Version : 1.1 > Upstream Author : Jose E. Marchesi > * URL or Web page : https://www.jemarch.net/poke > * License : GPL-3+ > Description : GNU poke, an interactive, extensible binary editor This seems to be in experimental already, albeit with a different upstream site: https://tracker.debian.org/pkg/poke 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
Bug#983804: ITA ucspi-tcp and ucspi-unix
owner 983804 ! retitle 983804 ITA: ucspi-tcp -- command-line tools for building TCP client-server applications owner 983805 ! retitle 983805 ITA: ucspi-unix -- UNIX-domain socket client-server command-line tools thanks signature.asc Description: PGP signature
Bug#982140: ITP: fuzzel -- Wayland-native application launcher
Package: wnpp Severity: wishlist Owner: Peter Colberg X-Debbugs-Cc: debian-de...@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
Bug#980477: RFA: libzstd1 -- fast lossless compression algorithm
On Tue, Jan 19, 2021 at 04:04:16PM +0100, Alex Mestiashvili wrote: > Package: wnpp > Severity: normal > > I am looking for a new maintainer/co-maintainer for libzstd. > Initially it was packaged by the Debian-Med team as a dependency, but now > this library is also used in many other packages. > It doesn't fit Debian-Med namespace anymore and it would be better if > another team would adopt it. Hi, I'd be happy to step in as (co-)maintainer, or, if you prefer, we could move the package to the pkg-rpm team, where the recently packaged libdrpm and libzchunk depend on it. Thanks a lot for taking care of libzstd in Debian! 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
Bug#971279: ITP: sphinx-markdown-tables -- Sphinx extension for rendering markdown tables
Package: wnpp Severity: wishlist Owner: Peter Wienemann Package name: sphinx-markdown-tables Version : 0.0.15 Upstream Author : Ryan Fox URL : https://github.com/ryanfox/sphinx-markdown-tables License : GPL-3.0 Programming Lang: Python Description : Sphinx extension for rendering markdown tables While Sphinx supports markdown thanks to the recommonmark extension, the latter does not cover tables. The sphinx-markdown-tables extension remedies this shortcoming. This package will be team-maintained by the Debian Python Team.
Bug#969652: ITP: xbrzscale -- Intelligent graphics file upscaling tool
Package: wnpp Severity: wishlist Owner: Peter Blackman X-Debbugs-CC: debian-de...@lists.debian.org * Package name: xbrzscale Version : 1.8 Upstream Author : Przemysław Grzywacz Zenju * URL : https://github.com/atheros/xbrzscale https://sourceforge.net/projects/xbrz/ * License : GPL-3+ Programming Lang: C++ Description : Intelligent graphics file upscaling tool Scale graphics files with the xBRZ algorithm. . xBRZ by Zenju is a modified version of xBR. It uses the same basic idea as xBR's pattern recognition and interpolation, but with a different rule set designed to preserve fine image details as small as a few pixels. This makes it useful for scaling the details in faces, and in particular eyes. xBRZ is optimized for multi-core CPUs and 64-bit architectures and shows 40–60% better performance than HQx even when running on a single CPU core only. It supports scaling images with an alpha channel, and scaling by integer factors from 2× up to 6×.
Bug#763995: ITP: python-qutepart - Code editor component for PyQt and PySide
Control: retitle -1 ITP: python-qutepart - Code editor component for PyQt and PySide Owner: peter_...@yeah.net Dear Maintainer, I'm interested in this package and would like to pack and maintain it. thanks! Regards, Peter Ji
Bug#763999: ITP: Enki - a text editor for programmers
Control: retitle -1 ITP: Enki - a text editor for programmers Owner: peter_...@yeah.net Dear Maintainer, Enki is a text editor for programmers and It works very well on my computer. I'm interested in this package and would like to pack and maintain it. Regards, Peter Ji
Bug#968495: ITP: c-evo -- empire building game
Package: wnpp Severity: wishlist Owner: Peter Blackman X-Debbugs-CC: debian-de...@lists.debian.org * Package name : c-evo Version : 1.2.0 Upstream Author : Jiri Hajda * URL : http://www.c-evo.org/ https://app.zdechov.net/c-evo/ * License : GPL2+ Programming Lang: FPC / Lazarus Description : Empire Building Game A civilization style turn based strategy game, of the Civ2 era. C-evo has some similarities to FreeCiv, but substantial differences too. 1) City sprawl in C-evo is a losing strategy. You must build large cities to win. 2) Combat is completely deterministic, no random element. 3) Much tougher AI opponents. 4) Combat units must be designed, with chosen attack, defence & speed parameters. Cost is roughly the product of all three, so designs must specialise to keep costs reasonable. Peter signature.asc Description: OpenPGP digital signature
Bug#966584: RFP: electronic-wechat -- A better WeChat on macOS and Linux. Built with Electron.
Package: wnpp Severity: wishlist * Package name: electronic-wechat Version : 2.0.0 Upstream Author : Perter Ji * URL : https://github.com/huiji12321/electronic-wechat * License : MIT Programming Lang: electron,JavaScript,HTML Description : A better WeChat on macOS and Linux. Built with Electron. I found that there was no WeChat.deb to install in Debian, and the web version didn't work very well.This package can works on my Debian Linux, And I used the Electron-Installer debian tool to make a DEB package, but I don't know if it meets the Debian software requirements:https://github.com/huiji12321/electronic-wechat/releases/download/2.0.1/electronic-wechat_2.0.0_mips64el.deb Hope someone else can help with the packing or uploading Regards, Peter Ji
Bug#934419: ITA: dhcpdump -- Parse DHCP packets from tcpdump
X-Debbugs-CC: Pierre-Elliott Bécue Control: retitle -1 ITA: dhcpdump -- Parse DHCP packets from tcpdump Owner: peter_...@yeah.net Dear Maintainer, I'm interested in this package and would like to start my own Debian contribution with it. I’ll change this to an ITA on my behalf for now, to signal that I am taking care of the package. The package description is: This package provides a tool for visualization of DHCP packets as recorded and output by tcpdump to analyze DHCP server responses. Regards, Peter Ji
Bug#965964: ITP: geant4 -- physics simulation toolit from CERN
Hi Stephan, On 24.07.20 15:11, Stephan Lachnit wrote: > The relevant part of the license [1] mentioned on the wiki page is: > >> 5. You may not include this software in whole or in part in any patent >> or patent application in respect of any modification of this software >> developed by you. > > I don't see how this doesn't comply with the DFSG. > It doesn't limit derived works, it doesn't discriminate anyone, > and it isn't specific to Debian or any other software product. in my layperson's view this is a violation of DFSG clause 6: "The license must not restrict anyone from making use of the program in a specific field of endeavor." Best regards Peter
Bug#965964: ITP: geant4 -- physics simulation toolit from CERN
Hi Stephan, On 21.07.20 16:42, Stephan Lachnit wrote: > Package name: geant4 > Version : 10.6.2 > Upstream Author : CERN > URL : http://geant4.web.cern.ch/ > License : a custom (MIT-like) license but looks DFSG compliant according to [0] the Geant4 license is not DFSG compliant. Peter [0] https://wiki.debian.org/DebianScience/Geant4
Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver
Hi Anthony, On Mon, Jun 08, 2020 at 11:06:29AM +0100, Anthony Perkins wrote: > > There have some fixes since the 0.2 release, so if it helps I could tag > > a new version. > > That would be very useful. At the moment I've pulled in a few patches > that looked like bug fixes since the 0.2 release, but if you could tag a > new version I can just include all the changes and fixes. I have just released 0.3 with some additional fixes. Most notably, support for listing and pairing new devices for a certain Nano receiver. The v0.3 git tag is signed with my PGP key, key ID AF74F895D8467CE9050B2B876F256F687D2DF7BB -- Kind regards, Peter Wu https://lekensteyn.nl
Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver
Hi all, Peter here, author of ltunify. Thank you for your interest :-) Regarding Solaar vs ltunify, I have contributed to both projects, but continue to use ltunify because it is a small program with no external dependencies. This makes it perfect for pairing or listing devices on a minimal point-of-sales system for example, or copying over the binary and run it over SSH. For those looking for more features such as the ability to control settings such as swapping the Fn buttons on keyboards, or a GUI/CLI to control new or existing devices, Solaar offers this. While it was dormant for a while, it has gained new maintainers, so it will continue to be a great alternative. In the future, Solaar might offload some of its protocol stuff to a separate daemon, but this development has not completed yet. See these references: https://github.com/pwr-Solaar/Solaar/issues/654 https://github.com/FFY00/logitechd For those interested in battery status, Solaar offers this functionality, but so does UPower (as integrated with the Plasma and GNOME desktops, and possibly others). A point to note, both Solaar and ltunify have a udev rule that grants the seated user rights to directly control the receiver by making the hidraw node accessible to non-root users. I still use this rule myself for usability, but more cautious users should note that this also allows those users to directly read events such as keystrokes, potentially bypassing additional security measures put in place by Wayland for example. For most users this should not be a problem, if arbitrary code is running as your user, you have more problems to worry about. There have some fixes since the 0.2 release, so if it helps I could tag a new version. -- Kind regards, Peter Wu https://lekensteyn.nl P.S. hoi Geert!
Bug#711285: 711285 ITA: flam3
Package: flam3 Retitle: 711285 ITA: flam3 -- render and animate FLAM3s and manipulate their genomes Owner: 711285 !
Bug#961806: ITP: libmodulemd -- C Library for manipulating module metadata files
Package: wnpp Severity: wishlist Owner: Peter Pentchev Control: block 912338 by -1 * Package name: libmodulemd Version : 2.9.4 Upstream Author : Stephen Gallagher , Igor Gnatenko * URL : https://github.com/fedora-modularity/libmodulemd * License : Expat Programming Lang: C Description : C Library for manipulating module metadata files The libmodulemd API provides an interface for handling metadata files describing the modular repositories introduced in the Fedora project and RedHat Enterprise Linux. This library is required by the createrepo-c library and set of tools (https://bugs.debian.org/912338). Both will be maintained as part of the RPM packaging team. signature.asc Description: PGP signature
Bug#961801: ITP: zchunk -- compress a file into independent chunks
Package: wnpp Severity: wishlist Owner: Peter Pentchev Control: block 912338 by -1 * Package name: zchunk Version : 1.1.5 Upstream Author : Jonathan Dieter * URL : https://github.com/zchunk/zchunk * License : BSD-2-clause Programming Lang: C Description : compress a file into independent chunks zchunk is a compressed file format that splits the file into independent chunks. This allows you to only download changed chunks when downloading a new version of the file, and also makes zchunk files efficient over rsync. zchunk files are protected with strong checksums to verify that the file you downloaded is, in fact, the file you wanted. This library is required by the createrepo-c library and set of tools (https://bugs.debian.org/912338). Both will be maintained as part of the RPM packaging team. signature.asc Description: PGP signature
Bug#961799: ITP: libdrpm -- library for making, reading and applying deltarpm packages
Package: wnpp Severity: wishlist Owner: Peter Pentchev Control: block 912338 by -1 * Package name: libdrpm Version : 0.4.1 Upstream Author : Matej Chalk * URL : https://github.com/rpm-software-management/drpm * License : BSD-3-clause Programming Lang: C Description : library for making, reading and applying deltarpm packages The drpm package provides a library for making, reading and applying deltarpms, compatible with the original deltarpm packages. This library is required by the createrepo-c library and set of tools (https://bugs.debian.org/912338). Both will be maintained as part of the RPM packaging team. signature.asc Description: PGP signature
Bug#912338: ITP: createrepo-c -- tool to create RPM repository metadata (C implementation)
On Mon, May 04, 2020 at 10:17:49AM +0200, Sebastiaan Couwenberg wrote: > Hi Peter, > > On Wed, 15 Jan 2020 16:03:38 +0200 Peter Pentchev wrote: > > The real reason I have not gone forward with the packaging of > > createrepo-c is an IMHO severe licensing problem upstream as you can see > > at https://github.com/rpm-software-management/createrepo_c/issues/106 - > > and so far there has been no response from upstream, and the only change > > in the cmake/Modules/ directory between the then-current version 0.11.1 > > and the now-current 0.15.5 is the addition of a new file with proper > > licensing information, but none of the problematic ones have been > > touched in any way. > > Have you considered pushing your work to Salsa under the pkg-rpm-team > namespace? > > https://salsa.debian.org/pkg-rpm-team > > I've packaged createrepo_c for $DAYJOB so we can keep updating the repos > for our CentOS system. It has some patches that may be useful to your > packaging as well. > > The cmake license issues are not a showstopper in my opinion, and can be > relatively easily patched. Hi, Thanks to you and to everyone else for the offers to help! I have restarted my work on packaging createrepo-c after a bit of a hiatus, mostly because of the licenses (IMHO they are indeed a showstopper, since the Debian archive should not contain files with unclear licensing), but now that has been resolved, I've made some progress packaging the newer versions. Joining the RPM packaging team on Salsa does indeed seem reasonable; I'll upload my work there in the next couple of days. 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
Bug#955803: ITP: bemenu -- Dynamic menu inspired by dmenu
Package: wnpp Severity: wishlist Owner: Peter Colberg * Package name: bemenu Version : 0.3.0-1 Upstream Author : Jari Vetoniemi * URL : https://github.com/Cloudef/bemenu * License : GPL-3+, LGPL-3+ Programming Lang: C Description : Dynamic menu inspired by dmenu bemenu is a dynamic menu for tty (using ncurses), X11 and/or Wayland, inspired by dmenu. It reads a list of newline-separated items from standard input. When the user selects an item and presses Return, their choice is printed to standard output and bemenu terminates. Entering text will narrow the items to those matching the tokens in the input.
Bug#948237: RFS: dnstwist
Dear DDs, I prepared packaging for the domain name permutation engine "dnstwist" (ITP bug #948237). The git repository is currently available at https://salsa.debian.org/wiene-guest/dnstwist It would be great if someone could review the code, provide feedback and - once everything looks fine - transfer the repository to the security tools team area and upload the package. Thanks, Peter
Bug#950523: ITP: golang-gopkg-hlandau-acmeapi.v2 -- ACME v2 (RFC 8555) client library for Go
Package: wnpp Severity: wishlist Owner: Peter Colberg * Package name: golang-gopkg-hlandau-acmeapi.v2 Version : 2.0.1-1 Upstream Author : Hugo Landau * URL : https://github.com/hlandau/acmeapi * License : Expat Programming Lang: Go Description : ACME v2 (RFC 8555) client library for Go This library implements the final version of the ACME specification. https://tools.ietf.org/html/rfc8555
Bug#912338: ITP: createrepo-c -- tool to create RPM repository metadata (C implementation)
On Wed, Jan 15, 2020 at 09:46:16PM +0800, YunQiang Su wrote:
> On Thu, 5 Sep 2019 09:33:33 -0700 Mike Miller
> wrote:
> > On Tue, Oct 30, 2018 at 16:40:18 +0200, Peter Pentchev wrote:
> > > I intend to package this tool since it seems to be the preferred
> > > alternative to the already packaged createrepo Python tool (and
> many
> > > thanks to Mike Miller for maintaining that package!) in at least
> > > the Fedora RPM packaging community. Thus it might be useful for
> people
> > > maintaining their own repositories of RPM-packaged software; there
> is
> > > no reason not to be able to do that on a Debian system :)
> >
> > Hey Peter,
> >
> > How is your work on this package going? Do you need any help? I am
> > interested in seeing this completed so that createrepo can be cleanly
> > removed from the archive.
>
> Mike, I think that you can take control of it now.
Hi,
Mike, really, really sorry that I didn't reply to this... it somehow
slipped through and I only noticed it now :(
The real reason I have not gone forward with the packaging of
createrepo-c is an IMHO severe licensing problem upstream as you can see
at https://github.com/rpm-software-management/createrepo_c/issues/106 -
and so far there has been no response from upstream, and the only change
in the cmake/Modules/ directory between the then-current version 0.11.1
and the now-current 0.15.5 is the addition of a new file with proper
licensing information, but none of the problematic ones have been
touched in any way.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.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
Bug#948237: ITP: dnstwist -- domain name permutation engine
Hi Scott, On 05.01.20 21:17, Scott Kitterman wrote: > Upstream contains an embedded copy of the Public Suffix List (PSL): > > https://github.com/elceef/dnstwist/blob/master/database/effective_tld_names.dat > > In Debian, this is provided in the publicsuffix package: > > https://salsa.debian.org/debian/publicsuffix/blob/debian/master/public_suffix_list.dat > > Although renamed, it's the same file. Please use the PSL from publicsuffix > rather than the embedded copy. It'll be more up to date. thanks for your hint. I wasn't aware of this. I guess the same holds for the GeoIP.dat file which seems to be provided by the geoip-database package in Debian. Peter
Bug#948237: ITP: dnstwist -- domain name permutation engine
Package: wnpp Severity: wishlist Owner: Peter Wienemann Package name: dnstwist Version : 20190706 Upstream Author : Marcin Ulikowski URL : https://github.com/elceef/dnstwist License : Apache-2.0 Programming Lang: Python Description : Domain name permutation engine For a given domain name, dnstwist generates a list of similarly looking domains and performs DNS queries for each of them (A, , NS and MX). For MX records it checks whether there is an active mail server which could intercept misdirected emails. Moreover it estimates webpage similarity based on fuzzy hashes. This functionality might be helpful in discovering typosquatters, phishing sites or otherwise fraudulent services and corporate espionage. This package will be team-maintained by the Debian Security Tools Team.
Bug#945145: O: docbook-dsssl -- modular DocBook DSSSL stylesheets, for print and HTML
On 2019-12-29 22:29, Chris Hofstaedtler wrote: * Peter Eisentraut [191229 21:26]: I'm not sure if anyone or anything is still using this. Certainly a few reverse (Build-)Depends: Checking reverse dependencies... # Broken Depends: docbook-utils: docbook-utils ldp-docbook-stylesheets: ldp-docbook-dsssl sgmltools-lite: sgmltools-lite # Broken Build-Depends: bochs: docbook-dsssl dictionaries-common: docbook-dsssl docbook-utils: docbook-dsssl hugs98: docbook-dsssl idzebra: docbook-dsssl installation-guide: docbook-dsssl kannel: docbook-dsssl kannel-sqlbox: docbook-dsssl libdbi: docbook-dsssl libdbi-drivers: docbook-dsssl libetpan: docbook-dsssl libopenusb: docbook-dsssl libusb: docbook-dsssl lprng-doc: docbook-dsssl opensp: docbook-dsssl pgpool2: docbook-dsssl privoxy: docbook-dsssl sgml2x: docbook-dsssl slony1-2: docbook-dsssl yaz: docbook-dsssl Yeah, about half of these are wrapper tools or something of the sort, half are very old software packages that should update their documentation build process upstream (or should be removed from Debian). While investigating this - knowing nothing about docbook myself -, I discovered that docbook.org recommends using pandoc instead of the openjade/xmlto/... zoo. Maybe other maintainers might find this useful. I'm not aware of this recommendation and I couldn't find it. The most straightforward change would be to change to docbook-xsl. But that would be an upstream decision.
Bug#948230: RFA: source-highlight -- convert source code to syntax highlighted document
Package: wnpp Severity: normal I'm looking for a new maintainer. There is a new upstream release to be packaged and some technical packaging cleanup work to be done. Everything works well, it's a useful package, it just needs a bit of attention.
Bug#948229: RFA: cmark -- CommonMark parsing and rendering program
Package: wnpp Severity: normal I'm looking for a new maintainer. The first job would be to update to the new upstream release. The shared library does not have a track record of compatibility, so updating it might require some care. Perhaps there is a way to collaborate better with the cmark-gfm package.
Bug#941657: RFS: python-lark
Dear DDs, I prepared packaging for the parsing library python-lark (ITP bug #941657). It is needed to bump the versions of prewikka [0] and charliecloud [1]. The git repository is available on https://salsa.debian.org/python-team/modules/python-lark It would be great if someone could review the code, provide feedback and - once everything looks fine - upload it. Thanks, Peter [0] https://tracker.debian.org/pkg/prewikka [1] https://tracker.debian.org/pkg/charliecloud
Bug#941657: name change: python-lark-parser -> python-lark
Hi Simon, thanks for your helpful input. On 30.12.19 18:04, Simon McVittie wrote: > There are two options: > > * If "lark" on PyPI is a dead project, or otherwise something that is never > going to be useful to package in Debian for some reason, then perhaps it's > safe for the lark parser to claim the python3-lark name. The last commit happened six years ago. It might be dead but I am not sure. > * Otherwise, if its PyPI name is lark-parser, then I would personally > recommend asking the upstream developer to rename the module you import > to lark_parser (or maybe larkparser if that's preferred), and packaging > it as python3-lark-parser (or python3-larkparser), optionally with > compatibility glue to make "import lark" continue to work (which might not > get packaged in Debian). I opened a corresponding issue: https://github.com/lark-parser/lark/issues/505 Peter
Bug#941657: name change: python-lark-parser -> python-lark
Hi Thomas, I am including the Python team to tap their expertise. For those not familiar with the topic: We are referring to https://github.com/lark-parser/lark which is not in the Debian archive yet (packaging work is still ongoing). On 29.12.19 23:10, Thomas Andrejak wrote: > Why changing the name ? it's named lark-parser in pypi. >From the beginning I felt uncertain how to call the source package: python-lark-parser or python-lark. > Moreover, in pypi, there already is a "lark" module which is not lark-parser When filing the ITP bug I decided to choose python-lark-parser for exactly this reason although upstream seems to call its software simply "Lark" in most places. Later I became aware of https://bugs.debian.org/945823 which says: "use the name you import in preference to the name from the PKG-INFO". That is why I decided to change the name to python-lark. But given the PyPI name clash this is certainly not optimal either. So this seems to be a particular unfortunate case. Any advice is welcome! Peter > Le sam. 28 déc. 2019 à 05:03, Peter Wienemann <mailto:foss...@posteo.de>> a écrit : > > Following the suggestions in > > https://bugs.debian.org/945823 > > I have changed the name from python-lark-parser to python-lark. > > The new repository URL is > > https://salsa.debian.org/python-team/modules/python-lark > > Peter
Bug#941657: name change: python-lark-parser -> python-lark
Following the suggestions in https://bugs.debian.org/945823 I have changed the name from python-lark-parser to python-lark. The new repository URL is https://salsa.debian.org/python-team/modules/python-lark Peter
Bug#941657: python-lark-parser -- Change of plans?
Hi Thomas, On 30.10.19 21:07, Peter Wienemann wrote: > Getting lark-parser into Debian requires more work than packaging > lark-parser itself. That is why this bug is blocked by #943783 which in > turn is blocked by #943785. > > Progress on #943785 can be tracked here: > > https://salsa.debian.org/python-team/modules/python-pyjsparser > > My work on #943783 is presently slowed down by a problem with a js2py > unit test error [0]. After some necessary clean-up I will push my js2py > packaging work in progress to > > https://salsa.debian.org/python-team/modules/python-js2py > > Peter > > [0] https://github.com/PiotrDabkowski/Js2Py/issues/185 after a discussion with upstream [0] and a lack of feedback on the js2py issue [1] I tend to go forward without the Nearley conversions in lark-parser and consequently stop the efforts to get pyjsparser and js2py into Debian. Would that be fine for your use case, too? Best regards, Peter [0] https://github.com/lark-parser/lark/issues/501 [1] https://github.com/PiotrDabkowski/Js2Py/issues/185
Bug#947175: O: sgml-spell-checker -- spell checker for SGML documents
Package: wnpp Severity: normal I am the upstream maintainer of this package, but I don't really maintain it any longer. It's really more of a private tool at this point. If no one is interested in this package, I will ask for its removal.
Bug#946757: O: lzop -- fast compression program
Package: wnpp Severity: normal Most sensibly maintained together with its underlying library lzo2 (see #946756), but the two source packages are released separately upstream.
Bug#946756: O: lzo2 -- data compression library
Package: wnpp Severity: normal Looking for new maintainer. Requires some care, source has some assembly code, had some portability issues in the past. Upstream releases are rare but appear to still happen.
Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, have you already found time to look into the revised packaging described in [0] and [1]? Cheers, Peter [0] https://lists.debian.org/debian-python/2019/11/msg00048.html [1] https://lists.debian.org/debian-python/2019/11/msg00106.html
Bug#946410: O: libtap-formatter-junit-perl -- Perl module for converting TAP output to JUnit XML output
Package: wnpp Severity: normal This was once useful for use with Jenkins, before Jenkins had a plugin for TAP results. Nowadays, I think it's obsolete. Perhaps it should be removed.
