Re: RFS: mwic 0.7.4-1
On 18-03-25 11:05:25, Paul Wise wrote: > On Wed, Mar 21, 2018 at 8:43 PM, Paul Wise wrote: > > I'll take a look, probably on Friday. > > Uploaded to NEW, thanks for your contribution. Thanks a lot, will tag accordingly once it hits unstable. > If you are so inclined, I would appreciated a commit (or patch) adding > mwic support to check-all-the-things: Will do. Cheers, Georg signature.asc Description: Digital signature
Re: RFS: mwic 0.7.4-1
On Wed, Mar 21, 2018 at 8:43 PM, Paul Wise wrote: > I'll take a look, probably on Friday. Uploaded to NEW, thanks for your contribution. If you are so inclined, I would appreciated a commit (or patch) adding mwic support to check-all-the-things: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/english.ini https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/doc/README -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
On Wed, Mar 21, 2018 at 6:02 PM, Georg Faerber wrote: > To put it differently, especially regarding this upstream metadata > check: If someone opens a bug against lintian to add a new check, does > "this new check" needs to be backed up by some general consensus within > the project? Is there some "formal process" around this, besides opening > a new bug? Just the new bug and the judgement of the lintian maintainers. > Changes pushed to git, package on m.d.n updated. I'll take a look, probably on Friday. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
Hi, On 18-03-21 11:36:58, Paul Wise wrote: > On Wed, Mar 21, 2018 at 1:11 AM, Georg Faerber wrote: > >> doc/mwic.1 and tests/coverage are generated files, they should be > >> removed from the upstream VCS and tarballs and be always built from > >> source. If upstream refuses, you should remove them in > >> `debian/rules clean` and very early in `debian/rules build` so that > >> the package will never depend on the existing upstream files. > > > > I've searched quite a bit on the Internets how to do this, and > > leverage, for now, dh_clean. I hope that this is an acceptable > > method for this, I didn't found any "official" source. I'll approach > > upstream regarding these files. > > It needs to be done in both debian/rules clean and build, otherwise > building the package without the clean step will use the prebuilt > file. dh_clean is fine for the first one, but you need to override > dh_auto_configure or dh_auto_build for the second one. Fixed. I've used dh_auto_build to limit the needed override targets. > > Also, the man page is now generated during dh_auto_install. I've > > added a build dependency on python3-docutils for this. > > That is the wrong time to generate it, please change that to > dh_auto_build. Fixed. > > See above. (Personally, I really dislike the trailing comma.) > > The reason for the trailing comma option is that when you add a new > item to the end of a list of dependencies, you don't also have to > modify the line before it, making the diff easier to read, which is > most of the point of the wrap-and-sort tool. I see, thanks for the explanation, makes sense. > > I'm aware that this was recently added to lintian, and reading the > > bug, again, makes me wonder what's the process of getting a new > > check into lintian. > > The process for adding a check is to file a bug on lintian and wait a > day, lamby is incredibly active on incoming lintian requests. lamby does a great job, I didn't referred to him personally above. To put it differently, especially regarding this upstream metadata check: If someone opens a bug against lintian to add a new check, does "this new check" needs to be backed up by some general consensus within the project? Is there some "formal process" around this, besides opening a new bug? > > Correct. Still, my question stands: How do I enable autopkgtests for > > this package? > > I haven't yet dealt with autopkgtests so I'm not sure. This is fixed as well, see 20180321010428.GJ8754@debian. > > The texts are the same, there are only differences in special chars > > like ", so I guess this is a false positive. > > You may want to file a bug on license-reconcile about these false > positives re Expat vs MIT/X11. Will do, once mwic hits the archive, to serve as a proof of concept. Changes pushed to git, package on m.d.n updated. Thanks! Cheers, Georg signature.asc Description: Digital signature
Re: RFS: mwic 0.7.4-1
On Wed, Mar 21, 2018 at 1:11 AM, Georg Faerber wrote: > Thanks a lot for your review, and sorry for not responding earlier, too > much stuff on my table: There is no need to apologise for being busy :) > On 18-03-18 11:33:59, Paul Wise wrote: >> The copyright years are missing 2012, I'm not sure if the ftp-masters >> would reject the package on that basis. > > I've referred to the upstream git history, instead of the licence file. > Fixed. I found the missing copyright year in one of the test files, not the license file. >> doc/mwic.1 and tests/coverage are generated files, they should be >> removed from the upstream VCS and tarballs and be always built from >> source. If upstream refuses, you should remove them in `debian/rules >> clean` and very early in `debian/rules build` so that the package will >> never depend on the existing upstream files. > > I've searched quite a bit on the Internets how to do this, and leverage, > for now, dh_clean. I hope that this is an acceptable method for this, I > didn't found any "official" source. I'll approach upstream regarding > these files. It needs to be done in both debian/rules clean and build, otherwise building the package without the clean step will use the prebuilt file. dh_clean is fine for the first one, but you need to override dh_auto_configure or dh_auto_build for the second one. > Also, the man page is now generated during dh_auto_install. I've added a > build dependency on python3-docutils for this. That is the wrong time to generate it, please change that to dh_auto_build. > After reading your mail I debugged this again: It's not about the top > level directory, at least if using gbp buildpackage, but about > 'export-dir'. Placing a symlink inside there which points to the actual > signature makes this work! :) ... > For now, I've wrote a wrapper script just for personal use, but I'll > work on [2] and [3] to get this implemented in a proper way. Great. > See above. (Personally, I really dislike the trailing comma.) The reason for the trailing comma option is that when you add a new item to the end of a list of dependencies, you don't also have to modify the line before it, making the diff easier to read, which is most of the point of the wrap-and-sort tool. > There is no man page currently, and also, more importantly, out of the > box this doesn't run in a non-interactive way. I guess, at least some > people, might run mwic via a CI pipeline, that's why I don't ship this. > I'll approach upstream regarding this. Fair enough. > I'm aware that this was recently added to lintian, and reading > the bug, again, makes me wonder what's the process of getting a new > check into lintian. The process for adding a check is to file a bug on lintian and wait a day, lamby is incredibly active on incoming lintian requests. > Correct. Still, my question stands: How do I enable autopkgtests for > this package? I haven't yet dealt with autopkgtests so I'm not sure. > The texts are the same, there are only differences in special chars like > ", so I guess this is a false positive. You may want to file a bug on license-reconcile about these false positives re Expat vs MIT/X11. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
Hi, On 18-03-20 18:11:50, Georg Faerber wrote: > > > Yeah, I've used this as well, but in this case it's not that > > > helpful as it finds the code defining the error [2]. > > > > I'd guess this is the source of the line you quoted: > > > > https://sources.debian.org/src/autopkgtest/5.1/runner/autopkgtest/?hl=144#L138 > > Correct. Still, my question stands: How do I enable autopkgtests for > this package? After reading the emails of Dimitry I've now integrated this. Changes pushed to git, package on m.d.n updated. Cheers, Georg signature.asc Description: Digital signature
Re: RFS: mwic 0.7.4-1
On 18-03-20 20:21:20, Dmitry Shachnev wrote: > On Mon, Mar 19, 2018 at 11:31:07PM +0100, Georg Faerber wrote: > > On 18-03-20 00:46:16, Dmitry Shachnev wrote: > > > On Sat, Mar 17, 2018 at 10:49:26AM +0100, Georg Faerber wrote: > > > > Also, AFAIK, debian/tests/control is obsolete nowadays if > > > > debian/control contains Testsuite:. > > > > > > This is not true. With autodep8 you can test only whether a package > > > can be imported. If you want to run some actual unit tests, you still > > > need debian/tests/control. > > > > In case you're referring to unit tests shipped upstream, that's not > > true. See this [1] and that [2] for an example. The tests are executed, > > but there is no debian/tests/control file. > > > > [1] > > https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-gettext-setup/20180313_122311/log.gz > > [2] https://salsa.debian.org/puppet-team/ruby-gettext-setup > > This is a Ruby package. AFAIK autodep8 can run the unit tests for Ruby > packages and maybe for some other languages, but for Python it can > only test importability. I believe this is due to Python having (too) > many different test frameworks and ways to run them. > > See https://salsa.debian.org/ci-team/autodep8/blob/master/examples.md > which shows how the generated tests look like for different languages. Thanks for the insight and the pointer - I stand corrected. Cheers, Georg (No need to Cc: me, I'm subscribed to the list.) signature.asc Description: Digital signature
Re: RFS: mwic 0.7.4-1
On Mon, Mar 19, 2018 at 11:31:07PM +0100, Georg Faerber wrote: > On 18-03-20 00:46:16, Dmitry Shachnev wrote: > > On Sat, Mar 17, 2018 at 10:49:26AM +0100, Georg Faerber wrote: > > > Also, AFAIK, debian/tests/control is obsolete nowadays if > > > debian/control contains Testsuite:. > > > > This is not true. With autodep8 you can test only whether a package > > can be imported. If you want to run some actual unit tests, you still > > need debian/tests/control. > > In case you're referring to unit tests shipped upstream, that's not > true. See this [1] and that [2] for an example. The tests are executed, > but there is no debian/tests/control file. > > [1] > https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-gettext-setup/20180313_122311/log.gz > [2] https://salsa.debian.org/puppet-team/ruby-gettext-setup This is a Ruby package. AFAIK autodep8 can run the unit tests for Ruby packages and maybe for some other languages, but for Python it can only test importability. I believe this is due to Python having (too) many different test frameworks and ways to run them. See https://salsa.debian.org/ci-team/autodep8/blob/master/examples.md which shows how the generated tests look like for different languages. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: RFS: mwic 0.7.4-1
Hi pabs, Thanks a lot for your review, and sorry for not responding earlier, too much stuff on my table: On 18-03-18 11:33:59, Paul Wise wrote: > The copyright years are missing 2012, I'm not sure if the ftp-masters > would reject the package on that basis. I've referred to the upstream git history, instead of the licence file. Fixed. > I require these things to be fixed before I would sponsor the package: > > doc/mwic.1 and tests/coverage are generated files, they should be > removed from the upstream VCS and tarballs and be always built from > source. If upstream refuses, you should remove them in `debian/rules > clean` and very early in `debian/rules build` so that the package will > never depend on the existing upstream files. I've searched quite a bit on the Internets how to do this, and leverage, for now, dh_clean. I hope that this is an acceptable method for this, I didn't found any "official" source. I'll approach upstream regarding these files. Also, the man page is now generated during dh_auto_install. I've added a build dependency on python3-docutils for this. > Some things that you may want to improve at some point: > > Please include the upstream signature in the source package. uscan > does the right thing these days, or you can rename it to > mwic_0.7.4.orig.tar.gz.asc and place it alongside the orig.tar.gz file > and rebuild the source package. Thanks for this pointer -- highly appreciated! Actually, I've debugged this for quite some time during the last year, and exchanged mails regarding this with Holger Levsen and Guido Günther seeking a way to include the upstream signature. Back then, I've read [1], and the man pages as well, but still couldn't figure it out - dropping the .asc into the top level directory didn't made a difference. After quite some time, I finally gave up. Up until yesterday I thought the tooling is currently limited. After reading your mail I debugged this again: It's not about the top level directory, at least if using gbp buildpackage, but about 'export-dir'. Placing a symlink inside there which points to the actual signature makes this work! :) The new upload should look better now in this regard. For now, I've wrote a wrapper script just for personal use, but I'll work on [2] and [3] to get this implemented in a proper way. > I like to wrap each of the fields in debian/watch on new lines. Although I think this is a matter of personal taste: fixed. > I like to use these wrap-and-sort parameters: > > wrap-and-sort --short-indent --wrap-always --sort-binary-packages > --trailing-comma See above. (Personally, I really dislike the trailing comma.) > misc/mwic4po seems like it would be worth installing in the package? There is no man page currently, and also, more importantly, out of the box this doesn't run in a non-interactive way. I guess, at least some people, might run mwic via a CI pipeline, that's why I don't ship this. I'll approach upstream regarding this. > Please add some upstream metadata: > > https://wiki.debian.org/UpstreamMetadata I've did this as well, although I'm unsure why this isn't defined in the policy. I'm aware that this was recently added to lintian, and reading the bug, again, makes me wonder what's the process of getting a new check into lintian. As it stands currently, some people take care of this, and some don't. This is of course not set in stone, but...well, not sure. > Output from automated checks is available at the very end of this > email. Thanks! > > Could you move the repo as well, or create a new one within the > > Python team? > > I'll leave that to someone who knows how to do that, I haven't dealt > with salsa yet. Alright! > > Yeah, I've used this as well, but in this case it's not that helpful > > as it finds the code defining the error [2]. > > I'd guess this is the source of the line you quoted: > > https://sources.debian.org/src/autopkgtest/5.1/runner/autopkgtest/?hl=144#L138 Correct. Still, my question stands: How do I enable autopkgtests for this package? > X: mwic source: upstream-metadata-file-is-missing Fixed. > check-all-the-things > > $ env PERL5OPT=-m-lib=. cme check dpkg > ... > Warning in 'control source Build-Depends:0' value 'debhelper (>= > 11~)': should be (>= 11) not (>= 11~) because compat is 11 > Warning in 'control source Build-Depends:1' value 'python3 (>= 3.2)': > unnecessary greater-than versioned dependency: python3 (>= 3.2). > Debian has oldoldstable -> 3.2.3-6; oldstable -> 3.4.2-2; > oldstable-kfreebsd -> 3.4.2-2; stable -> 3.5.3-1; unstable -> 3.6.3-2; > testing -> 3.6.4-1; unstable -> 3.6.4-1; > Warning in 'control binary:mwic Depends:0' value 'python3 (>= 3.2)': > unnecessary greater-than versioned dependency: python3 (>= 3.2). > Debian has oldoldstable -> 3.2.3-6; oldstable -> 3.4.2-2; > oldstable-kfreebsd -> 3.4.2-2; stable -> 3.5.3-1; unstable -> 3.6.3-2; > testing -> 3.6.4-1; unstable -> 3.6.4-1; Fixed. > $ doc8 > Scanning... > Validating... >
Re: RFS: mwic 0.7.4-1
> autopkgtest (debian/tests/) is a form of as-installed testing, which takes > the packages that were built, installs them in a relatively complete and > realistic environment (typically a lxc container or a qemu/kvm virtual > machine) and runs further tests there. Sometimes these tests just repeat > the build-time test coverage, but often they can make use of the ability > to do things that wouldn't work at build-time, like contacting Internet > services, running things as root, or relying on system services. This > often gives them better test coverage. Wow, that's even better! Thanks for the clarification. I guess I should use this feature more. :) signature.asc Description: OpenPGP digital signature
Re: RFS: mwic 0.7.4-1
On Tue, 20 Mar 2018 at 12:18:39 +0100, Gregor Riepl wrote: > > In case I've misunderstood you, and you're referring to unit tests > > shipped debian/tests/*, than yes, I agree. :) > > As far as I understand, these tests are executed by the package builder after > the upstream build script has finished. They're meant as a sort of integration > test, i.e. "does this package run on Debian". > > There's even a Lintian tag for them: > https://lintian.debian.org/tags/testsuite-autopkgtest-missing.html (which, I > think, is a bit overzealous) I think you're slightly confusing build-time tests with as-installed autopkgtests, but you have the right idea. Build-time tests (dh_auto_test or similar) run the upstream "make check" or equivalent, in the same environment as the build itself (typically an autobuilder). For simple libraries, build-time tests are enough. However, for more complex packages, the autobuilder environment is too artificial or too restricted for build-time tests to give full coverage: - can't run tests as root (system-level packages like dbus often need this for good coverage) - can't contact the Internet (even if in practice you usually can, Policy says you must not, for good reasons) - can't rely on a reasonable/realistic environment, like system services running, being in a systemd-logind login session on systems that have it, or even having a home directory - can't rely on the packages being "properly installed" so that hard-coded paths can work, and have to rely on overrides like PYTHONPATH to make newly-built code visible autopkgtest (debian/tests/) is a form of as-installed testing, which takes the packages that were built, installs them in a relatively complete and realistic environment (typically a lxc container or a qemu/kvm virtual machine) and runs further tests there. Sometimes these tests just repeat the build-time test coverage, but often they can make use of the ability to do things that wouldn't work at build-time, like contacting Internet services, running things as root, or relying on system services. This often gives them better test coverage. https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests is an example of an upstream project that is doing similar things. Because the autopkgtest container or VM is thrown away after running one package's tests in it, the tests can do things that would be unacceptable in an autobuilder environment, which again increases coverage. In Debian, autopkgtests are run separately, by different infrastructure (ci.debian.net), long after the package was built. The same package will usually be tested multiple times against newer versions of its dependencies, to look for regressions caused by a dependency change. The normal package upload/autobuild workflow does not typically run autopkgtests, although it could. Vectis, which is a personal package building tool that I'm working on, builds the package in sbuild in a virtual machine then immediately puts it through autopkgtests and piuparts testing in separate VMs, so that test failures can be checked (and either used as a reason not to upload, or ignored, based on the maintainer's judgement about the severity of the failure and the urgency of the upload - the same way the maintainer would triage Lintian errors). smcv
Re: RFS: mwic 0.7.4-1
> In case I've misunderstood you, and you're referring to unit tests > shipped debian/tests/*, than yes, I agree. :) As far as I understand, these tests are executed by the package builder after the upstream build script has finished. They're meant as a sort of integration test, i.e. "does this package run on Debian". There's even a Lintian tag for them: https://lintian.debian.org/tags/testsuite-autopkgtest-missing.html (which, I think, is a bit overzealous) signature.asc Description: OpenPGP digital signature
Re: RFS: mwic 0.7.4-1
Hi Dimitry, On 18-03-20 00:46:16, Dmitry Shachnev wrote: > On Sat, Mar 17, 2018 at 10:49:26AM +0100, Georg Faerber wrote: > > Also, AFAIK, debian/tests/control is obsolete nowadays if > > debian/control contains Testsuite:. > > This is not true. With autodep8 you can test only whether a package > can be imported. If you want to run some actual unit tests, you still > need debian/tests/control. In case you're referring to unit tests shipped upstream, that's not true. See this [1] and that [2] for an example. The tests are executed, but there is no debian/tests/control file. In case I've misunderstood you, and you're referring to unit tests shipped debian/tests/*, than yes, I agree. :) Cheers, Georg [1] https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-gettext-setup/20180313_122311/log.gz [2] https://salsa.debian.org/puppet-team/ruby-gettext-setup signature.asc Description: Digital signature
Re: RFS: mwic 0.7.4-1
On Sat, Mar 17, 2018 at 10:49:26AM +0100, Georg Faerber wrote: > Also, AFAIK, debian/tests/control is obsolete nowadays if debian/control > contains Testsuite:. This is not true. With autodep8 you can test only whether a package can be imported. If you want to run some actual unit tests, you still need debian/tests/control. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: RFS: mwic 0.7.4-1
On Sat, Mar 17, 2018 at 5:49 PM, Georg Faerber wrote:
> Thanks a lot; sure, see [1].
These things block the upload:
The copyright years are missing 2012, I'm not sure if the ftp-masters
would reject the package on that basis.
I require these things to be fixed before I would sponsor the package:
doc/mwic.1 and tests/coverage are generated files, they should be
removed from the upstream VCS and tarballs and be always built from
source. If upstream refuses, you should remove them in `debian/rules
clean` and very early in `debian/rules build` so that the package will
never depend on the existing upstream files.
Some things that you may want to improve at some point:
Please include the upstream signature in the source package. uscan
does the right thing these days, or you can rename it to
mwic_0.7.4.orig.tar.gz.asc and place it alongside the orig.tar.gz file
and rebuild the source package.
I like to wrap each of the fields in debian/watch on new lines.
I like to use these wrap-and-sort parameters:
wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma
misc/mwic4po seems like it would be worth installing in the package?
Please add some upstream metadata:
https://wiki.debian.org/UpstreamMetadata
Output from automated checks is available at the very end of this email.
> Could you move the repo as well, or create a new one within the Python
> team?
I'll leave that to someone who knows how to do that, I haven't dealt
with salsa yet.
> Yeah, I've used this as well, but in this case it's not that helpful as
> it finds the code defining the error [2].
I'd guess this is the source of the line you quoted:
https://sources.debian.org/src/autopkgtest/5.1/runner/autopkgtest/?hl=144#L138
lintian
X: mwic source: upstream-metadata-file-is-missing
check-all-the-things
$ env PERL5OPT=-m-lib=. cme check dpkg
...
Warning in 'control source Build-Depends:0' value 'debhelper (>=
11~)': should be (>= 11) not (>= 11~) because compat is 11
Warning in 'control source Build-Depends:1' value 'python3 (>= 3.2)':
unnecessary greater-than versioned dependency: python3 (>= 3.2).
Debian has oldoldstable -> 3.2.3-6; oldstable -> 3.4.2-2;
oldstable-kfreebsd -> 3.4.2-2; stable -> 3.5.3-1; unstable -> 3.6.3-2;
testing -> 3.6.4-1; unstable -> 3.6.4-1;
Warning in 'control binary:mwic Depends:0' value 'python3 (>= 3.2)':
unnecessary greater-than versioned dependency: python3 (>= 3.2).
Debian has oldoldstable -> 3.2.3-6; oldstable -> 3.4.2-2;
oldstable-kfreebsd -> 3.4.2-2; stable -> 3.5.3-1; unstable -> 3.6.3-2;
testing -> 3.6.4-1; unstable -> 3.6.4-1;
$ doc8
Scanning...
Validating...
.../mwic-0.7.4/doc/manpage.rst:19: D001 Line too long
.../mwic-0.7.4/doc/manpage.rst:20: D001 Line too long
.../mwic-0.7.4/doc/manpage.rst:53: D001 Line too long
# You may want to file a bug on license-reconcile
# about these false positives re Expat vs MIT/X11
$ env PERL5OPT=-m-lib=. license-reconcile
...
License mismatch: File private/check-rst has license MIT/X11 (BSD
like) which does not match Expat. at
/usr/share/perl5/Debian/LicenseReconcile/App.pm line 222, line
3.
# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ find . -type f -iname '*.py' -exec pycodestyle --ignore W191 {} +
# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ pydocstyle .
$ find . -type f -iname '*.py' -exec pylint3 --rcfile=/dev/null
--msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}:
{msg}' --reports=n {} +
$ python3-bandit -r .
$ grep -nHriE 'fixme|todo|hack|xxx+|broken' .
./tests/multiword-t-he.txt:6:# FIXME:
./tests/test_extdict.py:121:t({'aasumes'}, {'assumes'}) # FIXME? 'assumes'
./tests/test_extdict.py:122:t({'Addtional'}, {'Additional'}) #
FIXME? 'addtional'
./tests/multiword-t-he.exp:17:FIXME:
./tests/multiword-t-he.exp:18:| # FIXME:
./private/run-pylint:32:log=$(mktemp -t pylint.XX)
./.pylintrc:5:fixme,
$ vulture .
lib/cli.py:54: Unused variable 'namespace'
lib/cli.py:54: Unused variable 'option_string'
lib/cli.py:187: Unused variable 'ch'
lib/cli.py:192: Unused variable 'ch'
lib/cli.py:310: Unused variable 'args'
lib/colors.py:32: Unused variable 'warn'
lib/colors.py:35: Unused variable 'unreverse'
tests/test_blackbox.py:35: Unused attribute 'maxDiff'
tests/test_blackbox.py:85: Unused attribute 'redundant'
tests/test_blackbox.py:90: Unused variable 'enabled'
tests/test_blackbox.py:101: Unused function 'loadTestsFromFile'
tests/test_blackbox.py:105: Unused function 'wantFunction'
tests/test_blackbox.py:115: Unused function '_test'
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
Hi Paul, On 18-03-17 11:28:51, Paul Wise wrote: > On Sat, Mar 17, 2018 at 5:29 AM, Georg Faerber wrote: > > I'm searching a sponsor for the initial upload of mwic. > > I'll be happy to sponsor this, but I will need you to upload the > source package to mentors.d.n first. Thanks a lot; sure, see [1]. Could you move the repo as well, or create a new one within the Python team? > > - Running autopkgtest gives "SKIP no tests in this package". I've > > searched the Internets regarding this, but didn't found anything > > useful. I appreciate input and feedback regarding this. > > In general, codesearch.d.n is a better place to find error strings > than web search engines. Yeah, I've used this as well, but in this case it's not that helpful as it finds the code defining the error [2]. > This is probably due to autodep8. Hm.. the manpage reads: "If a known package type is detected, autodep8 exits with 0 and prints the suggested contents of debian/tests/control to the standard output." Running it exits with 0 but there is no output. Not sure how to proceed here. Also, AFAIK, debian/tests/control is obsolete nowadays if debian/control contains Testsuite:. Thanks, Georg [1] https://mentors.debian.net/debian/pool/main/m/mwic/mwic_0.7.4-1.dsc [2] https://codesearch.debian.net/search?q=SKIP+no+tests+in+this+package signature.asc Description: Digital signature
Re: RFS: mwic 0.7.4-1
On Sat, Mar 17, 2018 at 5:29 AM, Georg Faerber wrote: > I'm searching a sponsor for the initial upload of mwic. I'll be happy to sponsor this, but I will need you to upload the source package to mentors.d.n first. > - Running autopkgtest gives "SKIP no tests in this package". I've > searched the Internets regarding this, but didn't found anything > useful. I appreciate input and feedback regarding this. In general, codesearch.d.n is a better place to find error strings than web search engines. This is probably due to autodep8. -- bye, pabs https://wiki.debian.org/PaulWise
