Re: ponyorm v0.7.15rc1, python3.10 and github releases
Hi Louis-Philippe, Yeah, that sounds good to me - thanks for working on ponyorm! Jelmer On Mon, Jan 10, 2022 at 06:05:06PM -0500, Louis-Philippe Véronneau wrote: > Hello! > > Upstream ponyorm released v0.7.15rc1, which adds python3.10 support and > thus fixes #1000716. I ran a quick sbuild and the testsuite passes and > everything seems good. > > Since it is team maintained, I'd have updated the package in unstable, > but the latest pypi tarball changes the default carriage return, and > creates a huge diff on the upstream branch. This causes some patches to > fail to apply, etc. > > Would you mind if I migrated ponyorm to the github releases, using > uscan's git mode? I've made a quick test and it does solves this issue :) > > Asking, since I'd be pretty upset if someone were to do the opposite on > a package I team maintain :P > > Cheers, > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau > ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org > ⠈⠳⣄
Re: Packages depending on python-testtools are now RC: is bzr still a thing?
It's not just bzr, it's also a bunch of plugins for bzr that we'd have to disable the testsuite for - as well as a bunch of other non-bzr-related packages - python-subunit, python-fixtures, python-testscenarios, python-daemon, python-fastimport. Jelmer On 15 September 2019 14:26:35 CEST, Mattia Rizzolo wrote: >Considering that this is bzr we are talking about, a package that is >already entering the graveyard, I think it would be easiest to just >disable >the test suite and move on. > >But I would be happier it Thomas at least checked the rdeps before >dropping >packages, at least evaluating if breaking things is alrightif he really >likes to break packages :/ > > >On Sun, 15 Sep 2019, 11:09 am Jelmer Vernooij, >wrote: > >> >> >> On 15 September 2019 01:15:11 CEST, Scott Kitterman > >> wrote: >> >On Saturday, September 14, 2019 6:43:13 PM EDT Thomas Goirand wrote: >> >> Hi, >> >> >> >> As I wrongly thought python-extras was used only by OpenStack >stuff, >> >I >> >> removed Python 2 support for it. Then someone filed a bug against >> >> python-testtools (ScottK, I believe) saying that it became RC. >> >> Therefore, I went ahead and removed Python 2 support for >testtools, >> >but >> >> now, this implies that a few packages which I didn't wish to >impact >> >are >> >> also RC: >> >> >> >> * bzr-builddeb >> >> * bzr-email >> >> * bzr-fastimport >> >> * bzr-git >> >> * bzr-stats >> >> * bzr-upload >> >> * loggerhead >> >> >> >> So, basically, unfortunately, Bazaar has lost some of its build >> >> dependencies. >> >> >> >> So, I went ahead, and looked what I could do for Bazaar. >> >Unfortunately, >> >> when looking at: >> >> https://launchpad.net/bzr >> >> >> >> I can see no release since January 2016, no daily archive. The >last >> >> commit in the bzr repository of bzr is from 2017-03-17. >> >> >> >> Then I went to see how much Python 3 effort would be needed, and I >> >> quickly gave up. It'd be A LOT of work, but nobody seems doing ANY >> >work >> >> on bzr anymore. >> >> >> >> So I wonder: is it time to remove bazaar from Debian? Or is there >any >> >> vague plan to make it work with Python 3? If we are to remove it >from >> >> Debian, then we'd better do it ASAP. >> > >> >As I understand it, bazaar (bzr) is dead and being replaced by >breezy >> >(brz), >> >which is python3 compatible. >> > >> >https://www.breezy-vcs.org/ >> > >> >My inference is that anything bzr specific can go, but I'm not >involved >> >in >> >either project. >> >> Bzr maintainer / breezy upstream here. >> >> I'm planning to upload transitional packages to trigger upgrades from >bzr >> to Breezy. >> >> The packages for that are not ready yet though. Can we undo the >dropping >> of python-testtools in the meantime? >> >> Jelmer >> >>
Re: Packages depending on python-testtools are now RC: is bzr still a thing?
On 15 September 2019 01:15:11 CEST, Scott Kitterman wrote: >On Saturday, September 14, 2019 6:43:13 PM EDT Thomas Goirand wrote: >> Hi, >> >> As I wrongly thought python-extras was used only by OpenStack stuff, >I >> removed Python 2 support for it. Then someone filed a bug against >> python-testtools (ScottK, I believe) saying that it became RC. >> Therefore, I went ahead and removed Python 2 support for testtools, >but >> now, this implies that a few packages which I didn't wish to impact >are >> also RC: >> >> * bzr-builddeb >> * bzr-email >> * bzr-fastimport >> * bzr-git >> * bzr-stats >> * bzr-upload >> * loggerhead >> >> So, basically, unfortunately, Bazaar has lost some of its build >> dependencies. >> >> So, I went ahead, and looked what I could do for Bazaar. >Unfortunately, >> when looking at: >> https://launchpad.net/bzr >> >> I can see no release since January 2016, no daily archive. The last >> commit in the bzr repository of bzr is from 2017-03-17. >> >> Then I went to see how much Python 3 effort would be needed, and I >> quickly gave up. It'd be A LOT of work, but nobody seems doing ANY >work >> on bzr anymore. >> >> So I wonder: is it time to remove bazaar from Debian? Or is there any >> vague plan to make it work with Python 3? If we are to remove it from >> Debian, then we'd better do it ASAP. > >As I understand it, bazaar (bzr) is dead and being replaced by breezy >(brz), >which is python3 compatible. > >https://www.breezy-vcs.org/ > >My inference is that anything bzr specific can go, but I'm not involved >in >either project. Bzr maintainer / breezy upstream here. I'm planning to upload transitional packages to trigger upgrades from bzr to Breezy. The packages for that are not ready yet though. Can we undo the dropping of python-testtools in the meantime? Jelmer
Re: Python 2, Python 3, Stretch Buster
On Thu, Apr 23, 2015 at 02:52:33PM +0200, Enrico Zini wrote: On Mon, Apr 20, 2015 at 11:14:28AM -0400, Paul Tagliamonte wrote: So, round one of all of this is getting the critical path *under* each of our services ready, so that when we need to migrate, we don't need to scramble. There is another constraint that I forgot: the production environment is Debian Stable, which will soon mean Jessie. If a python2-only module gets ported to python3 in jessie+1, to use it for debian.org services the python3 version also needs to be maintained in backports. For example, I am about to add python-git as a dependency to nm.debian.org, as I need it to parse the stream of changes that I get via the keyring.debian.org git changelog, and python-git is python2-only in Jessie[1]. Having python3-git in jessie+1 won't be enough to make nm.debian.org deployable with python3: python3-git will also need to be in jessie-backports, and with a commitment to keep it up to date with security uploads, because I'm going to run it every night to parse git logs that are obtained via potentially insecure network connections. Enrico [1] I've recently been really sad to figure out that python-git is python2-only, and so is dulwich. As a personal policy, if I start a new python project now I start it with python 3.4. I had to start a new project with python2 because of that, and I felt dirty. FWIW, Dulwich supports Python3 these days [1]. We haven't actually put out a release with Python3 support yet, but that should happen shortly - along with an upload to unstable. experimental already has a `python3-dulwich` package, built from an upstream snapshot. Cheers, Jelmer [1] With the exception of `dulwich.web`, the HTTP serverside implementation. signature.asc Description: Digital signature
Re: pbs python
On Mon, Mar 31, 2014 at 04:20:42PM +1100, Ben Finney wrote: Brian May br...@microcomaustralia.com.au writes: Hello, *If* I wanted to get the following package into Debian: https://oss.trac.surfsara.nl/pbs_python What should I do? First step: submit a Request For Package bug report against the special “wnpp” package URL:https://www.debian.org/devel/wnpp/. It is highly recommended to di this with the ‘reportbug’ tool:: $ reportbug --mua mutt --severity wishlist wnpp because it will prompt you for what kind of WNPP bug report this is (answer: RFP), and then present a template for you to provide information about the prospective package. Note that Brian is also a DD and maintainer of various packages. He should be aware of the process. :) http://qa.debian.org/developer.php?login=bam It seems to clash with a package of the same name There are means of dealing with this: using a more specific name for the source package, renaming the resulting binary package and library, etc. But this is best done after submitting the RFP bug report and finding an interested Debian maintainer for the package. Even if the source and binary packages were renamed, this would result in packages that are unrelated and can not be installed together (what would import pbs do?) Ideally, one or more of the upstreams should be renamed. Have you checked if they are open to this? Cheers, Jelmer signature.asc Description: Digital signature
Re: Help with conversion to dh_python2 needed
On Thu, 2011-04-07 at 16:26 +0200, Sandro Tosi wrote: On Thu, Apr 7, 2011 at 16:14, Stefano Rivera stefa...@debian.org wrote: Hi Sandro (2011.04.07_14:07:59_+0200) (like done in unittest2[1] repo to exec tests). [1] svn://svn.debian.org/svn/python-modules/packages/unittest2/trunk As this is being used as an example: * There should probably be a set -e for that loop, or it won't fail if the tests only fail for the first python version. if someone is not so afraid to file bugs I probably would have remembered to fix it :) * The whole loop should be inside a check for DEB_BUILD_OPTIONS's nocheck option. well, I can expect dh not to call dh_auto_test (and its override) if DEB_BUILD_OPTIONS has 'nocheck' (no I didn't check for existing bugs against dh). debhelper expects the command or override to look at DEB_BUILD_OPTIONS. dh_auto_test does this as of debhelper 7.2.6. Any overrides will have to do it manually, see this wontfix bug for the details: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568897 Cheers, Jelmer signature.asc Description: This is a digitally signed message part
