Re: Mass bugs filing: autopkgtest should be marked superficial
On Fri, Sep 4, 2020 at 6:53 PM Sudip Mukherjee wrote: > If the test done in the autopkgtest does not provide significant test > coverage then it should be marked with "Restrictions: superficial". ... > I am still trying to figure out a generalized method to find them but > an initial script has found 83 packages. Attached is the dd-list. This sort of thing seems like something that will be an ongoing problem so a more efficient way to solve it would be a lintian warning, which should hopefully help prevent new occurrences. OTOH it would be pretty hard to automatically check for these without a robust shell parser. Perhaps morbig from Project CoLiS could be used for the shell parsing and then a script could process the morbig output. ShellCheck might be another option but it doesn't yet output parse trees. https://bugs.debian.org/932862 https://bugs.debian.org/629247 https://www.irif.fr/~treinen/colis/ https://github.com/colis-anr/morbig https://www.shellcheck.net/ -- bye, pabs https://wiki.debian.org/PaulWise
Mass bugs filing: autopkgtest should be marked superficial
Hi All, If the test done in the autopkgtest does not provide significant test coverage then it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" I am still trying to figure out a generalized method to find them but an initial script has found 83 packages. Attached is the dd-list. I intend to open the bug reports on them next week. -- Regards Sudip dd-list Description: Binary data
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 2020-09-04 at 11:42, Raphael Hertzog wrote: > So here's my counter proposal: > > --- a/web/deps/dep14.mdwn > +++ b/web/deps/dep14.mdwn > @@ -201,12 +201,16 @@ Native packages > > The above conventions mainly cater to the case where the upstream > developers and the package maintainers are not the same set of persons. > - > -When upstream is Debian (or one of its derivative), the upstream vendor > -should not use the usual `/` prefix (but all others vendors should > -do so). The main development branch does not have to be named after > -the codename of the target distribution (although you are free to still > -use the codename if you wish so). > +By contrast, this section applies to native packages where upstream is > +Debian (or one of its derivatives) and where the packaging and upstream > +source code are managed in the same branch(es). > + > +In that specific situation, the upstream vendor should not use the usual > +`/` prefix for their branches and tags (but all others vendors > +should do so) As long as this is being patched anyway, how about fixing the "others vendors" duplicate pluralization? I'd suggest either "but all other vendors should do so" or "as all others should do", but other variations are possible and I don't have a strong preference. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
Raphael Hertzog wrote on 04/09/2020: Hi, On Fri, 04 Sep 2020, Paride Legovini wrote: As the name of the development branch is not specified anymore, should dep14 ask for it to be the repository default branch? Otherwise there's no safe I took this as granted. But maybe we should make it explicit, yes. I also clarified that those recommandations are really for the cases where you mix upstream development and Debian packaging in the same branch. I can imagine someone picking 3.0 (native) packaging but keeping a separate "main" branch with only upstream code and hosting packaging in debian/latest... So here's my counter proposal: --- a/web/deps/dep14.mdwn +++ b/web/deps/dep14.mdwn @@ -201,12 +201,16 @@ Native packages The above conventions mainly cater to the case where the upstream developers and the package maintainers are not the same set of persons. - -When upstream is Debian (or one of its derivative), the upstream vendor -should not use the usual `/` prefix (but all others vendors should -do so). The main development branch does not have to be named after -the codename of the target distribution (although you are free to still -use the codename if you wish so). +By contrast, this section applies to native packages where upstream is +Debian (or one of its derivatives) and where the packaging and upstream +source code are managed in the same branch(es). + +In that specific situation, the upstream vendor should not use the usual +`/` prefix for their branches and tags (but all others vendors +should do so) and they also don't have to follow the usual naming +conventions for packaging branches (although they are free to do +so if they wish). However the default branch of the repository (as pointed +by the HEAD reference) should be a development branch. When the package is shipped as a native source package (i.e. a single tarball with no differentiation of the upstream sources and of the +1, thanks! Paride
Re: RFC: Final update of DEP-14 on naming of git packaging branches
Hi, On Fri, 04 Sep 2020, Paride Legovini wrote: > As the name of the development branch is not specified anymore, should dep14 > ask for it to be the repository default branch? Otherwise there's no safe I took this as granted. But maybe we should make it explicit, yes. I also clarified that those recommandations are really for the cases where you mix upstream development and Debian packaging in the same branch. I can imagine someone picking 3.0 (native) packaging but keeping a separate "main" branch with only upstream code and hosting packaging in debian/latest... So here's my counter proposal: --- a/web/deps/dep14.mdwn +++ b/web/deps/dep14.mdwn @@ -201,12 +201,16 @@ Native packages The above conventions mainly cater to the case where the upstream developers and the package maintainers are not the same set of persons. - -When upstream is Debian (or one of its derivative), the upstream vendor -should not use the usual `/` prefix (but all others vendors should -do so). The main development branch does not have to be named after -the codename of the target distribution (although you are free to still -use the codename if you wish so). +By contrast, this section applies to native packages where upstream is +Debian (or one of its derivatives) and where the packaging and upstream +source code are managed in the same branch(es). + +In that specific situation, the upstream vendor should not use the usual +`/` prefix for their branches and tags (but all others vendors +should do so) and they also don't have to follow the usual naming +conventions for packaging branches (although they are free to do +so if they wish). However the default branch of the repository (as pointed +by the HEAD reference) should be a development branch. When the package is shipped as a native source package (i.e. a single tarball with no differentiation of the upstream sources and of the Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#969539: ITP: golang-github-rakyll-magicmime -- Go bindings for libmagic to detect MIME types
Package: wnpp Severity: wishlist Owner: Jai Flack * Package name: golang-github-rakyll-magicmime Version : 0.1.0-1 Upstream Author : Jaana Dogan * URL : https://github.com/rakyll/magicmime * License : Apache-2.0 Programming Lang: Go Description : Go bindings for libmagic to detect MIME types golang-github-rakyll-magicmime-dev is a Go package which allows you to discover a file's mimetype by looking for magic numbers in its content. It could be used as a supplementary for Go's mime (http://golang.org/pkg/mime/) package which only interprets the file extension to detect mimetypes. Internally, it implements libmagic(3) (http://linux.die.net/man/3/libmagic) bindings. I intend to maintain this under the umbrella of the Go packaging team
Re: RFC: Final update of DEP-14 on naming of git packaging branches
Raphael Hertzog wrote on 29/08/2020: @@ -200,7 +204,7 @@ developers and the package maintainers are not the same set of persons. When upstream is Debian (or one of its derivative), the upstream vendor should not use the usual `/` prefix (but all others vendors should -do so). The main development branch can be named `master` instead of +do so). The main development branch does not have to be named after the codename of the target distribution (although you are free to still use the codename if you wish so). As the name of the development branch is not specified anymore, should dep14 ask for it to be the repository default branch? Otherwise there's no safe way to tell what the devel branch is for native packages. Proposal: --- The main development branch does not have to follow the naming conventions of non-native packages (although you are free to still do if you wish so), but it has to be the repository default branch. --- I refer to the "naming conventions" instead of "codename of the target distribution" because "latest" in /latest is not a target distribution but an arbitrary name. Paride
Re: [External] Re: Lenovo discount portal update (and a few other things)
On 2020/09/04 11:23, Philip Rinn wrote: >> Why do we need to make this 100% accurate in the first place? Everyone >> who got access to a debian.org email address has been an OSS contributor >> of sorts. Which leaves those who opted out of the email address entirely >> (rather than not using it) - but they are free to reactivate it. It >> feels like just checking for @debian.org is good enough, IMO. > > Well, DMs don't have debian.org email addresses. The benefit is currently just for DDs. Maybe that could change in the future, but that is how it is now. For people who don't usually use their debian.org addresses, it seems like a small issue? All they need to do is temporarily enable the forwarder to their usual address in db.debian.org, so no big deal? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: [External] Re: Lenovo discount portal update (and a few other things)
On 04.09.20 11:23, Philip Rinn wrote: >> Why do we need to make this 100% accurate in the first place? Everyone >> who got access to a debian.org email address has been an OSS contributor >> of sorts. Which leaves those who opted out of the email address entirely >> (rather than not using it) - but they are free to reactivate it. It >> feels like just checking for @debian.org is good enough, IMO. > > Well, DMs don't have debian.org email addresses. Sure, but I'd expect that state to be temporary, no? Kind regards Philipp Kern
Re: [External] Re: Lenovo discount portal update (and a few other things)
> Why do we need to make this 100% accurate in the first place? Everyone > who got access to a debian.org email address has been an OSS contributor > of sorts. Which leaves those who opted out of the email address entirely > (rather than not using it) - but they are free to reactivate it. It > feels like just checking for @debian.org is good enough, IMO. Well, DMs don't have debian.org email addresses. Best Philip
Re: [External] Re: Lenovo discount portal update (and a few other things)
On 04.09.20 03:39, Paul Wise wrote: > On Thu, 2020-09-03 at 15:18 -0400, Mark Pearson wrote: > >> For DSA - I'm assuming all role addresses have members behind it with >> debian addresses? "Please don't register on the portal with role >> addresses" would seem a sensible guideline to me. > > I just took a look at the aliases repo and most of them are solely > Debian members but some have folks who are not yet Debian members and > at least one has no Debian members on it. > >> If there is a group missing that it makes sense to add we can look at >> that - let me know. Using the debian.org email as a filter seemed like a >> neat and simple solution when I discussed it with Jonathan originally. >> I'd rather avoid having to manage lists of individual email addresses. >> That's a real pain and IMO will only break in the long term. >> Open to other suggestions if what we have implemented doesn't work but >> it has to be balanced with the amount of effort involved. > > If you are able to regularly automatically load and process a file, > there is one containing a list of Debian Maintainers, including an > email address that they use in their Debian work. IIRC this list is > regularly pruned by Debian when folks stop contributing. Probably > updating your copy of it daily would be regular enough. Why do we need to make this 100% accurate in the first place? Everyone who got access to a debian.org email address has been an OSS contributor of sorts. Which leaves those who opted out of the email address entirely (rather than not using it) - but they are free to reactivate it. It feels like just checking for @debian.org is good enough, IMO. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#969519: ITP: libshell-utils-clojure -- shell execution common to Puppet clojure projects
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: libshell-utils-clojure Version : 1.0.2 Upstream Author : Puppet Labs Inc * URL : https://github.com/puppetlabs/clj-shell-utils * License : Apache-2.0 Programming Lang: Clojure Description : shell execution common to Puppet clojure projects This package contains a library for shell execution common to Puppet clojure projects. Note: This is yet another dependency for Puppet 6.
