Sign me up Login

Details about package "soscleaner"

Name: soscleaner
Uploader: Eric Desrochers <slashd@ubuntu.com> (Debian QA page)
Description: soscleaner - Python application to clean sensitive and un-wanted data from an existing sosreport

Package versions

Version 0.4.4-1

Information

Version: 0.4.4-1
Uploaded: 2019-07-02 16:23
Source package: https://mentors.debian.net/debian/pool/main/s/soscleaner/soscleaner_0.4.4-1.dsc
Distribution: unstable
Section: admin
Priority: optional
Closes bugs: 928604

QA information

Comments

  1. Overall this looks like straightforward packaging and is fine.
    
    Showstopper
    
    This appears to be Python 2 only? Is Python 3 supported upstream? If not, what are the plans for this package when Python 2 support is dropped from the distribution? Considering Scott's comment in the ITP bug, I don't think it makes sense to upload a Python 2 only package now - you're only creating work for the Python maintainer teams.
    
    Ugly things that could do with cleaning up
    
    debian/control:
    
    VCS fields need fixing. I understand that you might be waiting for upload first, but in that case I'd leave out the comments and omit the fields, since from a source package perspective they say nothing.
    
    The short description is too long (lintian: description-too-long). Is it really necessary to point out that it's a "Python application"? un-wanted is usually not hyphenated.
    
    Maybe make the long description refer to the already packaged sosreport
    package? "sosreports" doesn't exist as a package. The reference to Red Hat seems like an odd choice too - the typical use in Debian would to use with the Debian sosreport package, rather than "Red Hat sosreports", right?
    
    See https://www.debian.org/doc/debian-policy/ch-binary.html#the-description-of-a-package - perhaps the description needs a rethink from the perspective of Debian users.
    
    Consider "Enhances: sosreport", and should this be a recommends (or a reverse recommends?) If a reverse recommends is the plan, then of course this can only be resolved after an upload as-is.
    
    debian/changelog:
    
      * "upload of..." is redundant: evident from version string
      * "(ITP)" is redundant: evident from being the first changelog entry
      * I suggest you use the dh-make default example exactly, since there's no
        reason to deviate here.
    
    debian/rules: export PYBUILD_NAME is not required as we're only building a single binary package.
    
    Advisory things
    
    debian/copyright: this is between you and your employer, but usually your employer owns the copyright on what you create, not you.
    
    Needs work Robie Basak at 2019-08-06 13:47:40.928281