Bug#897516:
Control: severity -1 important On Thu, Jul 19, 2018 at 12:16:00PM +0200, JCF Ploemen wrote: > The original bug reported here - partial failure of cram's test suite - > seems to be triggered by python-coverage >= 4.5, first uploaded to > Debian in Februari of 2018 (i.e. roughly 2 years after cram 0.7-1). With > earlier versions of coverage, cram 0.7-1 builds fine. I don't know > whether the bug is in cram, its test suite, or coverage though. > > Any known examples of cram failing in packages using it for their test > suites? Otherwise, please consider doing an upload of cram that runs > the test suite but ignores the outcome until there's more definitive > info on the root cause of this bug. Uploaded with ignoring test result and bug severity set to important. Kind regards Andreas. -- http://fam-tille.de
Bug#897516:
The original bug reported here - partial failure of cram's test suite - seems to be triggered by python-coverage >= 4.5, first uploaded to Debian in Februari of 2018 (i.e. roughly 2 years after cram 0.7-1). With earlier versions of coverage, cram 0.7-1 builds fine. I don't know whether the bug is in cram, its test suite, or coverage though. Any known examples of cram failing in packages using it for their test suites? Otherwise, please consider doing an upload of cram that runs the test suite but ignores the outcome until there's more definitive info on the root cause of this bug. pgpeJQ7J7vZ7L.pgp Description: OpenPGP digital signature
Bug#897516: Question about python-cram/python3-cram Debian/Ubuntu packages
Hi all, On Wed, Jun 06, 2018 at 08:23:00AM +0200, László Böszörményi (GCS) wrote: > Hi Brodie, > > On Sun, Jun 3, 2018 at 10:34 AM Brodie Rao wrote: > > I'm the creator of Cram. On a whim, earlier today searched for "cram" > > in the Ubuntu package repository, and was surprised to find the > > python-cram and python3-cram packages. I see you're listed as the > > original maintainer. Would you be able to help make changes to the > > packages? > Please do note that Andreas Tille is the new maintainer, I no longer > take care of the package. That's not what the metadata of the package says. The maintainer is Maintainer: Debian Python Modules Team (team in CC) and you are listed as Uploaders: Laszlo Boszormenyi (GCS) As I wrote you before I moved the package to DPMT to give it a wider audience but I was not hijacking the package from you. If you do not plan to care for the package please declare so publicly. The reason why I was steping in to cram packaging was that due to bug #897516 [1] with severity serious is affecting three packages of the Debian Med team (Uploader Afif Elghraoui in CC) and I wanted to make sure that the packages remain in testing. I hope that Afif might volunteer to ad himself to Uploaders in case you will not be able to work on this package. > > I'm wondering if Cram can be deprecated or removed as Python 2/3 > > libraries, and instead be listed as a CLI program under the package > > name "cram"—one that installs into /usr/bin/cram, uses Python 3, and > > isn't in sys.path and isn't importable. This was my original intention > > for Cram. Do you know if it'd be possible to make those changes? > Sure, this is possible now. The original idea was to have separate > Cram for Python 2.x and Python 3.y so when someone needs only one > variant then s/he doesn't need to pull in the other Python module > variants as dependency. > Now Python 2.7 is deprecated and python-cram can be dropped while the > python3- prefix can be removed. Andreas can do it for you. He is > already looking for you about package maintenance. I need to discuss this issue with Afif who know the chain of dependencies better than me. Adding an additional CLI package using the python3-cram package would be the cheapest way to cope with your plane to make cram a command line application. However, if there is software out there that is using the python-cram (=Python2) interface we should probably keep it as long as it is needed. > > Or would it make more sense to have three packages? python-cram, > > python3-cram, and "cram"? As I said above I consider this the less invasive method for the moment. > > With the latter installing into > > /usr/bin/cram, and the former two making the program available as a > > library (to preserve backwards compatibility). > Sure, dependent packages will need to be updated for the name change > but there's no need for a metapackage. Of course, Andreas is the one > to decide, this is only my point of view. As I tried to express I do not really feel in the position to decide just since I tried to work on a bug of the package, but I'll do my best to sort this out and follow the wish of upstream. > > One thing I'm not sure about is how to deal with python-cram currently > > using /usr/bin/cram. I'd rather Cram not use Python 2 at all if > > possible (it's ancient and hard to support—I was hoping to remove > > Python 2 support in the future, That's perfectly sensible. Debian is also moving away from Python 2. > > and maybe even use a different > > implementation language at some point). Do you know how that issue > > could be dealt with? > Please see above. I agree that Python 2 support needs to be removed. ACK. However, we somehow need to care for reverse dependencies and as long as these are using Python 2 we try to keep this alife. > > If there's any way you could help, or if you could point me to the > > right person or in the right direction, I'd very much appreciate it. > I've added Andreas to this mail, you can continue with him on future matters. As said above, the maintainer is python-modules-t...@lists.alioth.debian.org and I'd prefer if Afif would take over the Uploaders role. > > PS: I do appreciate your involvement with the package. I'm sorry if I > > come across as unthankful of that—I don't mean any disrespect at all. > > Thanks again for any help you might be able to provide! > You are welcome. Debian is a non-profit group of volunteers and we > help when we are able to. > Unfortunately the company I work for make it even more harder (now > almost impossible) to use Linux as such my possibilities are degraded. Thanks for the clarification. Kind regards Andreas. [1] https://bugs.debian.org/897516 -- http://fam-tille.de
Bug#897516: Decreasing fail-under parameter helps passing the test
Hi László, On Mon, May 21, 2018 at 11:15:13AM +0200, László Böszörményi (GCS) wrote: > > > Laszlo, before I'll dive deeper into it I'd like to know what you think > > > about maintaining this package in Debian Python Modules Team. I'd > > > volunteer to create a Git repository on Salsa and try to fix this bug > > > if you agree to it. > > > Since you did not raised disagreement I uploaded on behalf of the > > DPMT and commited the package to Salsa[1]. > I didn't agreed either. I did not intended to tip on your toes. I simply experienced that people did not responded for a long time and since bug #897516 is now removing several packages in Debian Med maintenance out of testing, I felt some action would be needed. > Possibly due to that I was not online for some > days. But no problem, I see you maintain it. Unfortunately the issue is not yet solved. If you have some contact to upstream (which does not seem very active) or personal insight it would be really helpful. Kind regards Andreas. -- http://fam-tille.de
Bug#897516: Decreasing fail-under parameter helps passing the test
On Sun, May 20, 2018 at 2:00 PM Andreas Tille wrote: > On Thu, May 10, 2018 at 10:00:07AM +0200, Andreas Tille wrote: > I've uploaded a package with decreased fail-limit and hereby I'm > decreasing the severity of the bug. Further investigation about the > failure should be done - possibly by involving upstream. > > Laszlo, before I'll dive deeper into it I'd like to know what you think > > about maintaining this package in Debian Python Modules Team. I'd > > volunteer to create a Git repository on Salsa and try to fix this bug > > if you agree to it. > Since you did not raised disagreement I uploaded on behalf of the > DPMT and commited the package to Salsa[1]. I didn't agreed either. Possibly due to that I was not online for some days. But no problem, I see you maintain it. Thanks, Laszlo/GCS
Bug#897516: Decreasing fail-under parameter helps passing the test
Control: tags -1 help,upstream Control: forwarded -1 https://github.com/brodie/cram/issues/32
Bug#897516: Decreasing fail-under parameter helps passing the test
Control: severity -1 serious On Sun, May 20, 2018 at 01:56:57PM +0200, Andreas Tille wrote: > Control: severity -1 important >... 0.7-2 did FTBFS on the buildd, raising severity again: https://buildd.debian.org/status/package.php?p=cram > Kind regards > >Andreas. >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#897516: Decreasing fail-under parameter helps passing the test
Control: severity -1 important On Thu, May 10, 2018 at 10:00:07AM +0200, Andreas Tille wrote: > so it seems that fail-under is the percentage that is permitted > to fail. I'm not sure why _encoding.py and __main__.py are > contributing to the failure count (obviously since some point > in time). I've uploaded a package with decreased fail-limit and hereby I'm decreasing the severity of the bug. Further investigation about the failure should be done - possibly by involving upstream. > Laszlo, before I'll dive deeper into it I'd like to know what you think > about maintaining this package in Debian Python Modules Team. I'd > volunteer to create a Git repository on Salsa and try to fix this bug > if you agree to it. Since you did not raised disagreement I uploaded on behalf of the DPMT and commited the package to Salsa[1]. Kind regards Andreas. [1] https://salsa.debian.org/python-team/modules/cram -- http://fam-tille.de
Bug#897516: Decreasing fail-under parameter helps passing the test
Hi, I've checked this bug and found that root@sputnik:/build/cram-0.7# python-coverage report --fail-under=95 NameStmts Miss Cover --- cram/__init__.py3 0 100% cram/__main__.py6 6 0% cram/_cli.py 74 0 100% cram/_diff.py 89 0 100% cram/_encoding.py 67 3252% cram/_main.py 135 0 100% cram/_process.py 14 0 100% cram/_run.py 40 0 100% cram/_test.py 104 0 100% cram/_xunit.py 66 0 100% --- TOTAL 598 3894% root@sputnik:/build/cram-0.7# echo $? 2 root@sputnik:/build/cram-0.7# python-coverage report --fail-under=94 NameStmts Miss Cover --- cram/__init__.py3 0 100% cram/__main__.py6 6 0% cram/_cli.py 74 0 100% cram/_diff.py 89 0 100% cram/_encoding.py 67 3252% cram/_main.py 135 0 100% cram/_process.py 14 0 100% cram/_run.py 40 0 100% cram/_test.py 104 0 100% cram/_xunit.py 66 0 100% --- TOTAL 598 3894% root@sputnik:/build/cram-0.7# echo $? 0 so it seems that fail-under is the percentage that is permitted to fail. I'm not sure why _encoding.py and __main__.py are contributing to the failure count (obviously since some point in time). Laszlo, before I'll dive deeper into it I'd like to know what you think about maintaining this package in Debian Python Modules Team. I'd volunteer to create a Git repository on Salsa and try to fix this bug if you agree to it. Kind regards Andreas. -- http://fam-tille.de
Bug#897516: cram: FTBFS: tests failed
Source: cram Version: 0.7-1 Severity: serious Tags: buster sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20180502 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[2]: Entering directory '/<>' > python-coverage erase > COVERAGE=python-coverage PYTHON=python PYTHONPATH=`pwd` scripts/cram \ >tests > ..s...ss... > # Ran 11 tests, 3 skipped, 0 failed. > python-coverage report --fail-under=100 > NameStmts Miss Cover > --- > cram/__init__.py3 0 100% > cram/__main__.py6 6 0% > cram/_cli.py 74 0 100% > cram/_diff.py 89 0 100% > cram/_encoding.py 67 3252% > cram/_main.py 135 0 100% > cram/_process.py 14 0 100% > cram/_run.py 40 0 100% > cram/_test.py 104 0 100% > cram/_xunit.py 66 0 100% > --- > TOTAL 598 3894% > make[2]: *** [Makefile:35: test] Error 2 The full build log is available from: http://aws-logs.debian.net/2018/05/02/cram_0.7-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
