Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On Jan 23, 2017, at 02:41 AM, Scott Kitterman wrote: >Which would be horrible. single-debian-patch means that to understand the >upstream modifications, access to the packaging VCS is required. I think >that would be a huge step backwards. Agreed. -Barry
Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On January 22, 2017 8:11:26 PM EST, Nikolaus Rath wrote: >On Jan 23 2017, Brian May wrote: >[ Convert from git-dpm to gbp ] >> Or would dgit be a better option? I confuse I don't really understand >> dgit. > >dgit can be used with both git-dpm and gbp. Moving to dgit-only would >mean to use a single-debian-patch. Which would be horrible. single-debian-patch means that to understand the upstream modifications, access to the packaging VCS is required. I think that would be a huge step backwards. Downstream consumers of our packages, like the security team and derivatives, should be able to consume the source package as a complete, non-obfuscated representation of the source. I'm not sure it's even DFSG free since it's not the preferred form of modification for the packaging (we need to ship source for that too). This is not saying we shouldn't change. We probably either need to adopt git-dpm or switch to something else. Let's just make sure it's not something that uses single-debian-patch. Scott K
Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On Jan 23 2017, Brian May wrote: > I don't particular care what we move to, however it seems to me that we > really should be dropping git-dpm. I think git-dpm works very nice as long as the package doesn't get too complex. I think it would be overreaction to convert all packages, just because git-dpm is unsuitable for some of them. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On Jan 23 2017, Brian May wrote: [ Convert from git-dpm to gbp ] > Or would dgit be a better option? I confuse I don't really understand > dgit. dgit can be used with both git-dpm and gbp. Moving to dgit-only would mean to use a single-debian-patch. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
Barry Warsaw writes: > We've talked about eventually dropping git-dpm and just using gbp (with gbp-pq > for patch management). There are some packages (I won't mention names) that have already started doing this. Would it be worth creating a concrete proposal to phase out usage of git-dpm in favour of gbp-pq? e.g. leave packages as-is, however on next update remove the debian/.git-dpm config file and unapply all patches. This could also wait until after the stretch release, however not sure if that matters. Or would dgit be a better option? I confuse I don't really understand dgit. I don't particular care what we move to, however it seems to me that we really should be dropping git-dpm. -- Brian May
Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On Jan 22, 2017, at 03:00 PM, Dmitry Shachnev wrote: >On Sat, Jan 21, 2017 at 11:54:13AM +, Ghislain Vaillant wrote: >> "Drop DPMT from Uploaders (due to problems with multiple tarballs in >> git-dpm)" >> >> Then, the package is no longer team-maintained? > >Personally I think we could allow such packages to remain in team, even if >they are not able to use git-dpm. In the past, we've discussed the status of git-dpm and team maintained packages. I believe I'm accurate in saying: * git-dpm is no longer actively maintained * even so, in the majority of cases it Just Works for us The main thing that git-dpm gives us is patch management with usually good enough integration with quilt. FWIW, I use straight-up gbp for most of my actual package building tasks, but I use git-dpm for pulling in a new upstream, managing patches, and tagging. We've talked about eventually dropping git-dpm and just using gbp (with gbp-pq for patch management). I think the fact that git-dpm pretty much works fine in most cases reduces the pressure to drop it. And it is true that we want consistency across the team packages so that we can document how you maintain them in one place (e.g. the wiki[1]), and there's no guesswork when you walk up to a repository and want to contribute. But we do have an "out" for team maintained packages where the standard workflow isn't appropriate. This can include packages for which git-dpm doesn't work, for packages which need a different branch naming scheme, etc. This requires you to document the differences in your debian/README.source file. You should be judicious about deviation from our standard team workflow. Be kind to your fellow maintainers and really try to work within the standard team policies and procedures. But in cases where you must deviate, you can still be part of the team! Please discuss your issues on this mailing list, come to some agreement among the active uploaders, and document your differences in d/README.source. Cheers, -Barry [1] https://wiki.debian.org/Python/GitPackaging pgpIs_UFixE1p.pgp Description: OpenPGP digital signature
Re: Team upload for python-jedi
Hi Ghislain, On Sat, Jan 21, 2017 at 11:54:13AM +, Ghislain Vaillant wrote: > "Drop DPMT from Uploaders (due to problems with multiple tarballs in > git-dpm)" > > Then, the package is no longer team-maintained? Personally I think we could allow such packages to remain in team, even if they are not able to use git-dpm. But Piotr is an administrator, so his opinion is more important here. On Thu, Jan 19, 2017 at 05:57:17PM +, Ghislain Vaillant wrote: > > For now you can just forget about git-dpm, get the sources manually and > > copy the Debian directory from Git on top of them. > > Just to be sure, do you mean I should leave the repository alone and > merge my work in a fresh import-dsc of the current package? I did not mean it. You could just (I think) remove debian/.git-dpm and work with plain git-buildpackage. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Team upload for python-jedi
[Piotr Ożarowski]
FYI: I uploaded 0.10.0~git1+f05c071-1 (without running tests during
build for now)
Great. Too bad for the wasted efforts on my end then. *sigh*
As far as testing is concerned, I am forwarding the set of patches
which were necessary to get the tests working on top of 0.9.0.
I'll let you verify whether they still apply on the snapshot you
uploaded regardless.
Also:
"Drop DPMT from Uploaders (due to problems with multiple tarballs in
git-dpm)"
Then, the package is no longer team-maintained?
Regards,
GhisFrom 4f2f807ca86b2102f720fe383e323bb613e18189 Mon Sep 17 00:00:00 2001
From: Dave Halter
Date: Sat, 9 Jul 2016 17:27:57 +0200
Subject: An empty path given to Jedi should not raise errors. Fixes #577.
---
test/test_integration_import.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/test/test_integration_import.py b/test/test_integration_import.py
index 6b5ad73a..d961666c 100644
--- a/test/test_integration_import.py
+++ b/test/test_integration_import.py
@@ -18,17 +18,17 @@ def test_goto_definition_on_import():
def test_complete_on_empty_import():
assert Script("from datetime import").completions()[0].name == 'import'
# should just list the files in the directory
-assert 10 < len(Script("from .", path='').completions()) < 30
+assert 10 < len(Script("from .", path='whatever.py').completions()) < 30
# Global import
-assert len(Script("from . import", 1, 5, '').completions()) > 30
+assert len(Script("from . import", 1, 5, 'whatever.py').completions()) > 30
# relative import
-assert 10 < len(Script("from . import", 1, 6, '').completions()) < 30
+assert 10 < len(Script("from . import", 1, 6, 'whatever.py').completions()) < 30
# Global import
-assert len(Script("from . import classes", 1, 5, '').completions()) > 30
+assert len(Script("from . import classes", 1, 5, 'whatever.py').completions()) > 30
# relative import
-assert 10 < len(Script("from . import classes", 1, 6, '').completions()) < 30
+assert 10 < len(Script("from . import classes", 1, 6, 'whatever.py').completions()) < 30
wanted = set(['ImportError', 'import', 'ImportWarning'])
assert set([c.name for c in Script("import").completions()]) == wanted
From faf18bdf335da4384f321886dfa2167525d65e51 Mon Sep 17 00:00:00 2001
From: Sid Shanker
Date: Sun, 17 May 2015 23:11:02 -0700
Subject: Fixed utf-8 decoding error in build.
---
test/run.py | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/test/run.py b/test/run.py
index a48e1fb2..d7309143 100755
--- a/test/run.py
+++ b/test/run.py
@@ -290,9 +290,12 @@ def collect_dir_tests(base_dir, test_files, check_thirdparty=False):
skip = 'Thirdparty-Library %s not found.' % lib
path = os.path.join(base_dir, f_name)
-source = open(path).read()
-if not is_py3:
-source = unicode(source, 'UTF-8')
+
+if is_py3:
+source = open(path, encoding='utf-8').read()
+else:
+source = unicode(open(path).read(), 'UTF-8')
+
for case in collect_file_tests(StringIO(source),
lines_to_execute):
case.path = path
Re: Team upload for python-jedi
FYI: I uploaded 0.10.0~git1+f05c071-1 (without running tests during build for now) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Team upload for python-jedi
On Thu, 2017-01-19 at 20:45 +0300, Dmitry Shachnev wrote: > Hi Ghislain, > > On Wed, Jan 18, 2017 at 05:53:05PM +, Ghislain Vaillant wrote: > > Ok, I have got a working package fixing the RC. However, whoever did > > the migration from svn to git forgot that the source tree was made of > > multiple tarballs (one for jedi, one for jedi-vim) and now the vim > > plugin package cannot be produced because of the missing sources [1]. > > > > How I should proceed now? > > > > We could just drop the vim plugin package for now (it does not work > > anyway due to #841043), and consider introducing a new source package > > for it later. Afterall, they are separate projects on GitHub [2, 3]. > > > > Otherwise, I guess the svn migration would have to be re-run? I have no > > idea how to do it, nor setting up git-dpm to use multiple tarballs. > > The SVN to Git migration was done automatically. I think the script was > just not too smart to deal with multiple tarballs properly. Ok. > For now you can just forget about git-dpm, get the sources manually and > copy the Debian directory from Git on top of them. Just to be sure, do you mean I should leave the repository alone and merge my work in a fresh import-dsc of the current package? > Now it is too late to fix the DPMT migration script, but it may be not > too late to make sure the problem does not appear with PAPT. Possibly. Ghis
Re: Team upload for python-jedi
Hi Ghislain, On Wed, Jan 18, 2017 at 05:53:05PM +, Ghislain Vaillant wrote: > Ok, I have got a working package fixing the RC. However, whoever did > the migration from svn to git forgot that the source tree was made of > multiple tarballs (one for jedi, one for jedi-vim) and now the vim > plugin package cannot be produced because of the missing sources [1]. > > How I should proceed now? > > We could just drop the vim plugin package for now (it does not work > anyway due to #841043), and consider introducing a new source package > for it later. Afterall, they are separate projects on GitHub [2, 3]. > > Otherwise, I guess the svn migration would have to be re-run? I have no > idea how to do it, nor setting up git-dpm to use multiple tarballs. The SVN to Git migration was done automatically. I think the script was just not too smart to deal with multiple tarballs properly. For now you can just forget about git-dpm, get the sources manually and copy the Debian directory from Git on top of them. Now it is too late to fix the DPMT migration script, but it may be not too late to make sure the problem does not appear with PAPT. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Team upload for python-jedi
I apologize for insisting here, but I need this RC fixed ASAP for another package relying on it and have no idea what to do now. Thanks, Ghis On Wed, 2017-01-18 at 17:53 +, Ghislain Vaillant wrote: > On Wed, 2017-01-18 at 13:37 +0100, Piotr Ożarowski wrote: > > Hi, > > > > [Ghislain Vaillant, 2017-01-18] > > > Would you be ok if I push the changes required to fix #830399 and > > > #841043 for src:python-jedi and prepare a team-upload? > > > > > > I need the RC fixed for the packaging of spyder. > > > > go ahead. I have almost working package with latest changes from upstream > > git repo but some tests still fail and I don't have time to work on it > > right now. > > Ok, I have got a working package fixing the RC. However, whoever did > the migration from svn to git forgot that the source tree was made of > multiple tarballs (one for jedi, one for jedi-vim) and now the vim > plugin package cannot be produced because of the missing sources [1]. > > [1] > https://anonscm.debian.org/cgit/python-modules/packages/python-jedi.git/tree/ > > > How I should proceed now? > > We could just drop the vim plugin package for now (it does not work > anyway due to #841043), and consider introducing a new source package > for it later. Afterall, they are separate projects on GitHub [2, 3]. > > Otherwise, I guess the svn migration would have to be re-run? I have no > idea how to do it, nor setting up git-dpm to use multiple tarballs. > > [2] https://github.com/davidhalter/jedi > [3] https://github.com/davidhalter/jedi-vim > > > Cheers, > Ghis
Re: Team upload for python-jedi
On Wed, 2017-01-18 at 13:37 +0100, Piotr Ożarowski wrote: > Hi, > > [Ghislain Vaillant, 2017-01-18] > > Would you be ok if I push the changes required to fix #830399 and > > #841043 for src:python-jedi and prepare a team-upload? > > > > I need the RC fixed for the packaging of spyder. > > go ahead. I have almost working package with latest changes from upstream > git repo but some tests still fail and I don't have time to work on it > right now. Ok, I have got a working package fixing the RC. However, whoever did the migration from svn to git forgot that the source tree was made of multiple tarballs (one for jedi, one for jedi-vim) and now the vim plugin package cannot be produced because of the missing sources [1]. [1] https://anonscm.debian.org/cgit/python-modules/packages/python-jedi.git/tree/ How I should proceed now? We could just drop the vim plugin package for now (it does not work anyway due to #841043), and consider introducing a new source package for it later. Afterall, they are separate projects on GitHub [2, 3]. Otherwise, I guess the svn migration would have to be re-run? I have no idea how to do it, nor setting up git-dpm to use multiple tarballs. [2] https://github.com/davidhalter/jedi [3] https://github.com/davidhalter/jedi-vim Cheers, Ghis
Team upload for python-jedi
Hi Piotr, Would you be ok if I push the changes required to fix #830399 and #841043 for src:python-jedi and prepare a team-upload? I need the RC fixed for the packaging of spyder. Cheers, Ghis
Re: Team upload for python-jedi
Hi, [Ghislain Vaillant, 2017-01-18] > Would you be ok if I push the changes required to fix #830399 and > #841043 for src:python-jedi and prepare a team-upload? > > I need the RC fixed for the packaging of spyder. go ahead. I have almost working package with latest changes from upstream git repo but some tests still fail and I don't have time to work on it right now. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
