Re: [Python-modules-team] python-xlib_0.26-1_source.changes ACCEPTED into unstable
On Wed, 22 Apr 2020 at 23:44, Sandro Tosi wrote: > Andrej, > can you please clarify why you're keep using pristine-lfs even when > prompted not to? this is just from 2 packages uploaded in the last > hour (ftr, pyopenssl is broken now..) Sandro, wasn’t it all about pristine-tar missing? You (and others) use pristine-tar, you need pristine-tar data. I don’t like it and don’t use it, but okay, I don’t want you to get annoyed by the inability to follow your workflow, I try and use pristine-tar every time. But what’s wrong with also publishing a pristine-lfs branch? It doesn’t prevent you in any way from doing things the way you were doing before. I will look at what happened with pyopenssl. > https://salsa.debian.org/python-team/modules/pyopenssl/-/tree/pristine-lfs > https://salsa.debian.org/python-team/modules/urwid/-/tree/pristine-lfs > On Sat, Mar 21, 2020 at 3:31 PM Scott Kitterman wrote: > > The way to get the policy changed is not to ignore it and then get > > aggressive > > when called on it. Scott, I didn’t get aggressive, or, at least, it was not my intention. I’m sorry if it came across as such. I genuinely believe that pristine-tar should be gradually moved away from to something better, as I had a misfortune to work with it on a large scale (hundreds of packages) and I know how unreliable it sometimes is. Not only it routinely generated tarballs with different checksums, it sometimes failed to generate anything at all. I developed pristine-lfs as a proper tool with the UI compatible with pristine-tar (instead of just a custom script) specifically to help others use it without changing workflows much. -- Cheers, Andrej
Re: [Python-modules-team] python-xlib_0.26-1_source.changes ACCEPTED into unstable
Andrej, can you please clarify why you're keep using pristine-lfs even when prompted not to? this is just from 2 packages uploaded in the last hour (ftr, pyopenssl is broken now..) https://salsa.debian.org/python-team/modules/pyopenssl/-/tree/pristine-lfs https://salsa.debian.org/python-team/modules/urwid/-/tree/pristine-lfs On Sat, Mar 21, 2020 at 3:31 PM Scott Kitterman wrote: > > On Saturday, March 21, 2020 3:02:27 PM EDT Andrej Shadura wrote: > > Hi, > > > > On Sat, 21 Mar 2020 at 19:39, Sandro Tosi wrote: > > > > On Sat, 21 Mar 2020 at 18:01, Sandro Tosi wrote: > > > > > Andrej, > > > > > why the pristine-tar information are now in a `pristine-lfs` branch? > > > > > where did the other pristine-tar deltas go? > > > > > > > > Because it’s simpler and better as it guarantees the tarballs are bit > > > > to bit identical, which pristine-tar so often fails to do. There was > > > > no pristine-tar or pristine-lfs information for earlier uploads. > > > > > > but our team policy requires to use pristine-tar: > > > https://salsa.debian.org/python-team/tools/python-modules/blob/master/poli > > > cy.rst > > > > > > please adjust, so that we can all use the same tools and procedures. > > > > I suggest we rather change the policy since at the moment this point > > lacks any rationale and isn’t providing any benefit since the > > pristine-tar data are only useful for minor updates of the package > > (e.g. when the upstream source hasn’t changed) and pristine-tar is > > known to be a huge hack and fail to provide correct tarballs, > > especially when xz is used. > > When you joined the team, you agreed to follow the team policies. Please do > so. > > The way to get the policy changed is not to ignore it and then get aggressive > when called on it. > > Personally, I use the pristine-tar branch routinely (I used it multiple times > just yesterday) and I've never had a problem with it. Personally, while I > know it's a hack, it's a working hack. > > Please do as you've been asked and then we can have a nice conversation about > if we should change the way the team works. > > Scott K > ___ > Python-modules-team mailing list > python-modules-t...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/22/20 6:23 AM, Valentin Vidić wrote: > On Tue, Apr 21, 2020 at 11:20:16PM +0200, Thomas Goirand wrote: >> You can remove all of the python-oslo* from the list. The versions in >> Experimental, which are the next version of OpenStack, are fixed. In 2 >> weeks of time, I'll upload all what I staged in Experimental to Sid >> (maybe 150 packages?) and that's going to fix it all. > > Will the new OpenStack version also fix this issue? > > #955116 python-murano-pkg-check: FTBFS with Sphinx 2.4: AttributeError: > 'Sphinx' object has no attribute 'info' Hopefully yes. As I understand, the issue is in oslo-sphinx, which is deprecated. I checked, and the master branch of murano-pkg-check doesn't use oslo-sphinx (and is therefore fixed). I'm waiting for it to be released, hopefully this week or the next one. Cheers, Thomas Goirand (zigo)
Re: Bug#952130: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
Hi, út 21. 4. 2020 v 23:24 odesílatel Thomas Goirand napsal: > > But that still leaves the question of what to do about the dependency of > > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > > it's reverse-dependencies in the same way that regular python2 modules > > were? how feasible is that? are pypy-* packages only useful with python2 > > pypy or are they also useful with python3 pypy? > > I really don't know about pypy. Probably the pypy-pytest should indeed > go away, as the initial plan was to switch to pypy3. Maybe tumbleweed > (Stefano Rivera) would be able to answer. I'm adding him as Cc. > I guess I can say something about pytest because I'm maintainer of pytest, right? :) I'm perfectly fine with removing pypy-pytest binary package and all other dependencies in chain. It's painfull to maintain it. -- Best regards Ondřej Nový
