Bug#929666: #929666 ITP: conmon -- An OCI container runtime monitor
Hi, On 6/21/19 4:06 AM, Dmitry Smirnov wrote: > Birger, let's move the repository to "debian" group please, shall we? Feel free to do so- I'm neither a DD nor a DM, so I can't move it there. I've added you and siretart as maintainers, if thats needed. cheers, Birger
Processed: your mail
Processing commands for cont...@bugs.debian.org: > owner 930806 ! Bug #930806 [wnpp] ITP: urlextractor -- Information gathering and website reconnaissance Owner recorded as jo...@debian.org. > End of message, stopping processing here. Please contact me if you need assistance. -- 930806: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930806 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930309: ITA: libtomcrypt
signature.asc Description: OpenPGP digital signature
Bug#929666: #929666 ITP: conmon -- An OCI container runtime monitor
Birger, let's move the repository to "debian" group please, shall we? https://salsa.debian.org/debian Thanks. -- Regards, Dmitry Smirnov --- A wise man proportions his belief to the evidence. -- David Hume, "An Inquiry Concerning Human Understanding" signature.asc Description: This is a digitally signed message part.
Processed (with 1 error): your mail
Processing commands for cont...@bugs.debian.org: > retitle 930137 ITA: nicotine -- graphical client for the SoulSeek Bug #930137 [wnpp] O: nicotine -- graphical client for the SoulSeek peer-to-peer system Changed Bug title to 'ITA: nicotine -- graphical client for the SoulSeek' from 'O: nicotine -- graphical client for the SoulSeek peer-to-peer system'. > peer-to-peer Unknown command or malformed arguments to command. > End of message, stopping processing here. Please contact me if you need assistance. -- 930137: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930137 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed (with 1 error): ITA: nicotine -- graphical client for the SoulSeek peer-to-peer system
Processing commands for cont...@bugs.debian.org: > rename 930137 ITA: nicotine -- graphical client for the SoulSeek peer-to-peer Unknown command or malformed arguments to command. > owner 930137 ! Bug #930137 [wnpp] O: nicotine -- graphical client for the SoulSeek peer-to-peer system Owner recorded as Josue Ortega . > End of message, stopping processing here. Please contact me if you need assistance. -- 930137: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930137 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930806: ITP: urlextractor -- Information gathering and website reconnaissance
Package: wnpp Severity: wishlist * Package name : urlexractor Version : 0.2.0 Upstream Author : eschultze * URL : https://github.com/eschultze/URLextractor * License : MIT Description : Information gathering and website reconnaissance urlextractor gathers information from the specified URL and prints it to STDOUT The following information is gathered: - IP and hosting info like city and country (using FreegeoIP) - DNS servers (using dig) - ASN, Network range, ISP name (using RISwhois) - Load balancer test - Whois for abuse mail (using Spamcop) - PAC (Proxy Auto Configuration) file - Compares hashes to diff code - robots.txt (recursively looking for hidden stuff) - Source code (looking for passwords and users) - External links (frames from other websites) - Directory FUZZ (like Dirbuster and Wfuzz - using Dirbuster) directory list) - URLvoid API - checks Google page rank, Alexa rank and possible blacklists - Provides useful links at other websites to correlate with IP/ASN - Option to open ALL results in browser at the end signature.asc Description: PGP signature
[bts-link] source package wnpp
# # bts-link upstream status pull for source package wnpp # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #856595 (http://bugs.debian.org/856595) # Bug title: ITP: kiwix-tools -- Kiwix (http://www.kiwix.org) command line tools # * https://github.com/kiwix/kiwix-tools/issues/10 # * remote status changed: (?) -> open usertags 856595 + status-open thanks
Processed: block 930440 with 928083 921949 922842 923300 898689
Processing commands for cont...@bugs.debian.org: > block 930440 with 928083 921949 922842 923300 898689 Bug #930440 [wnpp] ITP: podman -- Library and tool for running OCI-based containers in Pods 930440 was blocked by: 929666 930440 was not blocking any bugs. Added blocking bug(s) of 930440: 921949, 922842, 898689, 923300, and 928083 > thanks Stopping processing here. Please contact me if you need assistance. -- 930440: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930440 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: block 930440 with 929666
Processing commands for cont...@bugs.debian.org: > block 930440 with 929666 Bug #930440 [wnpp] ITP: podman -- Library and tool for running OCI-based containers in Pods 930440 was not blocked by any bugs. 930440 was not blocking any bugs. Added blocking bug(s) of 930440: 929666 > thanks Stopping processing here. Please contact me if you need assistance. -- 930440: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930440 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: O: dunst -- dmenu-ish notification-daemon
Processing control commands: > retitle -1 ITA: dunst -- dmenu-ish notification-daemon Bug #930310 [wnpp] O: dunst -- dmenu-ish notification-daemon Changed Bug title to 'ITA: dunst -- dmenu-ish notification-daemon' from 'O: dunst -- dmenu-ish notification-daemon'. > owner -1 ! Bug #930310 [wnpp] ITA: dunst -- dmenu-ish notification-daemon Owner recorded as Nikos Tsipinakis . -- 930310: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930310 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930310: O: dunst -- dmenu-ish notification-daemon
Control: retitle -1 ITA: dunst -- dmenu-ish notification-daemon Control: owner -1 ! I intend to adopt this package, I am not a DM however so I'm going to need someone to sponsor my uploads. Full disclosure: I am also the upstream maintainer
Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
Hi Sean, Quoting Sean Whitton (2019-06-20 07:28:12) > [updating CC to point to the newly-filed RFP] thank you! > Thank you again for looking into this. Incidentally I'm currently writing a tool that needs PyMuPDF so I'll probably spend a bit more time on this. ;) > On Sat 08 Jun 2019 at 09:52pm +0200, Johannes Schauer wrote: > > after my struggles in #930212 I now figured out how to compile stuff > > against the static library in libmupdf-dev. As a result I managed to > > package PyMuPDF. You can see the result here: > > > > https://salsa.debian.org/python-team/modules/pymupdf > > > > It's mostly Lintian-clean and just waiting for somebody who feels like > > maintaining it in the future. :) > I've had a look at your repo. I've got a few questions and comments > (relevant to whomever wants to take ownership of the ITP and upload this to > NEW). > > A tool called SWIG, with which I'm unfamiliar, was used to generate > fitz/fitz.py from the files fitz/*.i, but this tool does not get run > during the package build. There could be updates to SWIG, including > security updates, which would change fitz.py. It seems to me that we > want to run SWIG during the package build to ensure that fitz.py > reflects all improvements made to SWIG since pymupdf upstream ran that > tool when releasing pymupdf. Agreed. https://github.com/pymupdf/PyMuPDF/issues/312 > Secondly, how do you foresee us triggering binNMUs to rebuild this package > when the static library in libmupdf-dev changes? We would need to be sure > that this package gets rebuilt if a security update was made to libmupdf-dev, > for example, or the vulnerable version of mupdf would still be present in > this package. PDF libraries tend to get CVEs, to put it mildly. I'm worried > we've the same sort of problem as discussed in #928227. We have a similar issue but a less severe one because this is only one package and not a whole ecosystem of them. Since the required tooling is currently missing, I guess any maintainer of PyMuPDF would need to closely follow mupdf development and trigger binNMUs as necessary. > Finally, I noticed that the project looks to be GPL-3 not GPL-3+, though I > haven't looked through every file in the source. Indeed there seem to be some files in it that are just GPL-3 and not GPL-3+, namely in the demo and examples directories. d/copyright has to be adjusted accordingly. > I also haven't thought carefully about the implications of statically linking > a project that's under the AGPL. I think that we can do it, but I'm not sure > quite what license the binary package will end up with, and quite how to > document that in d/copyright. d/copyright only documents the contents of the source package. As far as I know we do not yet have means to also document the inferred license of any generated binary artifacts? Thanks! cheers, josch signature.asc Description: signature
Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
I should mention that ocrmypdf no longer has an immediate use for PyMuPDF - I went the route of creating pikepdf, Python bindings for qpdf, and this is library is now in Debian thanks to Sean's work on packaging it. I don't think I would use PyMuPDF if it were available. pikepdf overlaps the core of PyMuPDF but is not a competing library, offering low level PDF manipulation and much in the less way of content generation. As such the original basis for this ticket is gone. I just want to make sure people aren't putting effort into this ticket for ocrmypdf alone. If other people want to see PyMuPDF added to Debian for their own reasons, that's quite fine. -James On Wed, Jun 19, 2019 at 10:28 PM Sean Whitton wrote: > [updating CC to point to the newly-filed RFP] > > Hello Johannes, > > Thank you again for looking into this. > > On Sat 08 Jun 2019 at 09:52pm +0200, Johannes Schauer wrote: > > > after my struggles in #930212 I now figured out how to compile stuff > against > > the static library in libmupdf-dev. As a result I managed to package > PyMuPDF. > > You can see the result here: > > > > https://salsa.debian.org/python-team/modules/pymupdf > > > > It's mostly Lintian-clean and just waiting for somebody who feels like > > maintaining it in the future. :) > > I've had a look at your repo. I've got a few questions and comments > (relevant to whomever wants to take ownership of the ITP and upload this > to NEW). > > A tool called SWIG, with which I'm unfamiliar, was used to generate > fitz/fitz.py from the files fitz/*.i, but this tool does not get run > during the package build. There could be updates to SWIG, including > security updates, which would change fitz.py. It seems to me that we > want to run SWIG during the package build to ensure that fitz.py > reflects all improvements made to SWIG since pymupdf upstream ran that > tool when releasing pymupdf. > > Secondly, how do you foresee us triggering binNMUs to rebuild this > package when the static library in libmupdf-dev changes? We would need > to be sure that this package gets rebuilt if a security update was made > to libmupdf-dev, for example, or the vulnerable version of mupdf would > still be present in this package. PDF libraries tend to get CVEs, to > put it mildly. I'm worried we've the same sort of problem as discussed > in #928227. > > Finally, I noticed that the project looks to be GPL-3 not GPL-3+, though > I haven't looked through every file in the source. I also haven't > thought carefully about the implications of statically linking a project > that's under the AGPL. I think that we can do it, but I'm not sure > quite what license the binary package will end up with, and quite how to > document that in d/copyright. > > -- > Sean Whitton >
