Re: Backport of python-lockfile and suggested team maintenance
My bafflement at the particulars of your complaint have not been resolved, Andreas. I can only think you're confused about ‘python-lockfile’; much of your latest message just doesn't match the facts. Andreas Tille writes: > You decided to use github instead of git.debian.org. Is your complaint that the Debian packaging for ‘python-lockfile’ is on GitHub? This is the first time it's been raised in this thread. If so, please look to the VCS-Git and VCS-Browser fields for the package; that assertion isn't true. > IMHO that is not following good practice for Debian team maintenance As you have pointed out, the package is not currently team maintained, so “good practice for Debian team maintenance” doesn't bear on the issues you've expressed for this package. This thread started with your polite request (thank you!) that the package *should* become team maintained, and we don't even seem to have got to addressing that yet :-) > since [hosting at GitHub] makes contributions (admitedly slightly!) > harder. Agreed – I think the barriers are significant – which is one reason the packaging is not hosted at GitHub. > > As a maintainer of the package, I remain open to pull requests. > > The pull request would force me to create my own clone on Github Since the Debian packaging work is not hosted at GitHub, no that would not be necessary. Even if it were hosted at GitHub, that assertion is not true: Git can pull from *any* published repository. I've already pointed out that two published repositories can share full change information *without* being hosted at the same provider. Even one hosted in a Debian developer's personal Alioth space works fine https://wiki.debian.org/Alioth/Git#Personal_Git_repositories>. So, I'm open to pull requests (whether created with ‘git request-pull’ or otherwise) from a published repository that I can point Git to. Nothing about this requires anyone to host a repository at the same provider. > > Are you now expressing the separate position that you consider it > > *not* sensible to name an individual as package maintainer? On what > > basis? I would still like an answer to this, because I must admit I am now baffled as to what your complaint is and on what you base it. Does it help address your complaint that I've hopefully cleared up some incorrect assumptions? I hope so. If you'd like to discuss on OFTC my nick is ‘bignose’. -- \ “If I held you any closer I would be on the other side of you.” | `\ —Groucho Marx | _o__) | Ben Finney
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On Thu, 2017-03-09 at 21:13 +1100, Brian May wrote: > Brian May writes: > > > git read-tree --reset -u upstream > > git reset -- debian > > git checkout debian > > git rm debian/.git-dpm > > I have tried these steps on python-mkdocs in the debian/experimental > branch, and then upgraded to the latest upstream (using instructions on > wiki). Works perfectly[1]. > > The only unexpected problem I had is that "gbp import-orig --uscan", by > default, switches to the master branch and attempts to merge the new > upstream there. Which wasn't going to work, because master still is the > patches-applied git-dpm version. I had assumed that it would work on the > current branch; it doesn't. You can override the target debian / upstream branches with `gbp import-orig --debian-branch=debian/experimental --upstream- branch=upstream/latest`. Long-term you'd want to write your DEP-14 compliant configuration in debian/gbp.conf indeed. Ghis
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
❦ 9 mars 2017 21:13 +1100, Brian May : > The above also assumes that upstream==origin/upstream==latest > upstream. Which means you need to have done a git pull recently on the > upstream branch. Depending on the circumstances, using origin/upstream > might be a better choice rather then upstream. Only if everyone names the origin branch origin. The alternative is to use "gbp pull" instead of "git pull". -- Make sure every module hides something. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Under which umbrella should I package my Python IDE for beginners (Thonny)?
[Ghislain Vaillant, 2017-03-09] > You can use git with PAPT too. not yet -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Brian May writes: > git read-tree --reset -u upstream > git reset -- debian > git checkout debian > git rm debian/.git-dpm I have tried these steps on python-mkdocs in the debian/experimental branch, and then upgraded to the latest upstream (using instructions on wiki). Works perfectly[1]. The only unexpected problem I had is that "gbp import-orig --uscan", by default, switches to the master branch and attempts to merge the new upstream there. Which wasn't going to work, because master still is the patches-applied git-dpm version. I had assumed that it would work on the current branch; it doesn't. The wiki should be ammended with instructions on how to edit debian/gbp.conf at the appropriate steps. Writing a new default to debian/gbp.conf does fix this. The above also assumes that upstream==origin/upstream==latest upstream. Which means you need to have done a git pull recently on the upstream branch. Depending on the circumstances, using origin/upstream might be a better choice rather then upstream. Notes: [1] Well apart from a new "source-is-missing" lintian warning, probably from the new upstream. So probably not ready for upload just yet. -- Brian May
Re: Under which umbrella should I package my Python IDE for beginners (Thonny)?
On Thu, 2017-03-09 at 09:58 +0200, Aivar Annamaa wrote: > Hi! > > I've developed a Python IDE for beginners, Thonny (http://thonny.org) > and I intend to package it for Debian > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857042). Nice. > The application would consist of a Python 3 package named "thonny" > (https://pypi.python.org/pypi/thonny), a simple launch script (python3 > -m thonny), desktop file and icon. It depends only on Python 3.4 or > later with Tkinter. You've got the dependency chain covered. > For the needs of the main application, the Python package could be > private for the application, but as 3rd party Thonny plugins may need to > import something from there, it makes sense to treat it as a shared > Python package. Ack. > By the example of similar app Spyder > (https://packages.debian.org/sid/spyder3), I thought that it makes sense > to create two binary packages: "python3-thonny" for the Python package > and "thonny" for providing end user facilities. Would you agree with > this plan? Sounds ok. > If I want to publish Thonny under one of the Python teams, which one > should I choose? (My own preference would be Python Modules, because I'm > more comfortable with git than with svn). You can use git with PAPT too. > If it's good idea to publish it under Python Modules Team, can you > please add me to the team (my Alioth user is aivarannamaa-guest)? I've > read the policy document and agree with it. > > Is anyone willing to sponsor the package? You can start working on the packaging on a private repository whilst waiting for being accepted to a team (PAPT, DPMT or others). You will need a functional package before seeking sponsorship. Cheers, Ghis
Under which umbrella should I package my Python IDE for beginners (Thonny)?
Hi! I've developed a Python IDE for beginners, Thonny (http://thonny.org) and I intend to package it for Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857042). The application would consist of a Python 3 package named "thonny" (https://pypi.python.org/pypi/thonny), a simple launch script (python3 -m thonny), desktop file and icon. It depends only on Python 3.4 or later with Tkinter. For the needs of the main application, the Python package could be private for the application, but as 3rd party Thonny plugins may need to import something from there, it makes sense to treat it as a shared Python package. By the example of similar app Spyder (https://packages.debian.org/sid/spyder3), I thought that it makes sense to create two binary packages: "python3-thonny" for the Python package and "thonny" for providing end user facilities. Would you agree with this plan? If I want to publish Thonny under one of the Python teams, which one should I choose? (My own preference would be Python Modules, because I'm more comfortable with git than with svn). If it's good idea to publish it under Python Modules Team, can you please add me to the team (my Alioth user is aivarannamaa-guest)? I've read the policy document and agree with it. Is anyone willing to sponsor the package? best regards, Aivar Annamaa
