Re: Orphaning mu-editor, firmware-microbit-micropython, and their (build)-deps

[Hans-Christoph Steiner]

Hey Nick,

Thanks for maintaining mu-editor, my kids are just getting started with it.  So 
I might be interested in taking it over.  Are the updates a lot of work?  I see 
the tarball is tagged with dfsg so there's that...


.hc

Nick Morrott:

Dear team,

I intend to orphan two of my team maintained packages, and their
several (build)-dependencies, that I originally packaged and have
maintained (to varying degrees, it can be argued) since 2018. Thank
you to team members who have contributed bug fixes and patches during
this time. I've really appreciated it \o/.

I don't have (and have not had for a while) the time to maintain all
of these, so to free them up for more active development following new
releases I would like to offer these to other members of the team to
pick up if interested. Apologies for holding up any progress; I should
have done this a while ago...

I am the only Uploader on all of the packages below. If anyone is
interested, please take over and replace me as the Uploader.

If no one has added themselves as an uploader in Salsa within two
weeks to any of the packages below, I will formally orphan them:

mu-editor (new 1.2.0 version to be packaged)
python-uflash (build dep, dep, new version to be packaged with mu-editor)
python-nudatus (build dep, dep, up to date)
python-pytest-random-order (build dep, up to date)
python-guizero (dep, up to date)

firmware-microbit-micropython (new 1.1.1 version to be packaged)
yotta (build dep, up to date)
valinor (build dep, up to date)
python-project-generator (build dep, up to date)
python-project-generator-definitions (build dep, up to date)
mbed-test-wrapper (build dep, up to date)
python-mbed-host-tests (build dep, up to date)
python-mbed-ls (build dep, up to date)
python-hgapi (build dep, up to date)

I will also remove myself as an uploader on pytest-xvfb (leaving one
other), which is a build-dep of python-guizero.

With all thanks,
Nick

uploading paramiko 3.0.0

[Hans-Christoph Steiner]

paramiko 3.0.0 was released two weeks ago.  Any reason to not upload it now?  It 
would be nice to get into bookworm.


.hc

Re: Ask for reviewing

[Hans-Christoph Steiner]

Andrey Rahmatullin:

On Sat, May 28, 2022 at 06:39:56PM +0430, Danial Behzadi wrote:

Hey folks,

I recently uploaded my python app to deb-expo. As this is my first
packaging experience in Debian, I would love to get some feedback on my
packaging to make it better.

Here is my package: https://mentors.debian.net/package/tractor/

You shouldn't make this a native package or keep an upstream changelog in
debian/changelog.


Hey Danial,

Good to see you in Debian also!  Did you intend to make this a native Debian 
package?  That means that the version in Debian is considered the canonical one, 
and the Debian git repo is the canonical source repo.  Based on pypi, it seems 
that framagit is the canonical repo, so it probably makes more sense to convert 
this to a "source package" as Andrey suggested.


.hc

Re: The python command in Debian

[Hans-Christoph Steiner]

Piotr Ożarowski:
> FTR: I didn't change my mind. /usr/bin/python is still used outside
> Debian packages, in /usr/local/bin scripts and applications and I
> strongly disagree to touch it.

Sometimes breaking things can be helpful.  If someone is not aware that
something still requires Python 2.x, having that script start failing
can often be helpful.  As long as Debian provides a way to make
/usr/bin/python point to 2.x, I think this kind of breakage will be
useful since it makes it clear that the user is relying on totally
unmaintained software.

Arch has been using /usr/bin/python for Python 3.x for a while now.

.hc

Re: The python command in Debian

[Hans-Christoph Steiner]

Ondrej Novy:
> Hi,
> 
> čt 9. 7. 2020 v 15:27 odesílatel Matthias Klose  napsal:
> 
>> Describing here a solution which is implemented for Ubuntu focal (20.04
>> LTS).  A
>> new source package what-is-python (-perl-dont-hurt-me) ships binary
>> packages
>> python-is-python2, python-dev-is-python2, python-is-python3 and
>> python-dev-is-python3.  The python-is-python2 package provides the python
>> package, such that packages that still depend on python are not removed on
>> a
>> distro upgrade.  On new installs, python-is-python3 is not installed by
>> default,
>> but the user gets a hint from command-not-found to install the package if
>> he
>> tries to run python.  Package dependencies on the new four binary packages
>> have
>> to be disallowed in the Python policy.  Note that such a package including
>> the
>> Provides should only be uploaded once all dependencies on the unversioned
>> python
>> packages are gone.
>>
> 
> I like this solution in Ubuntu and I have:
> onovy@jupiter:~$ dpkg -l | grep python-is-python3
> ii  python-is-python3  3.8.2-4
>   all  symlinks /usr/bin/python to python3
> 
> What I think is good idea:
> * keep "python" command pointing to python2.7 if I'm upgrading
> buster->bullseye with python2.7 installed. We are going to keep python2.7
> interpreter for bullseye, so don't break old "python" command for
> third-parties apps/scripts/etc. (install python-is-python2 during
> buster->bullseye upgrade)
> * allow users to choose if they want python=python3 (apt install
> python-is-python3)
> * (maybe?) python=python3 in new installs, because why not? (install
> python-is-python3 by default in clean install)
> 

I like this overall plan as laid out by Matthias.  And the above points
seem good, except I think it is a bad idea to keep 'python' pointing to
python2.7 on upgrade.  Python 2.7 is no longer maintained, and as
Matthias said, it should only be used as a Build-Depends for very
specific cases.  I think users should either be prompted with a
question, or should have to manually install python-is-python2.  We want
to help users leave Python 2.x behind, not pretend its still OK to use it.

.hc

Re: joining the PAPT

[Hans-Christoph Steiner]

Louis-Philippe Véronneau:
> On 20-05-11 17 h 02, Louis-Philippe Véronneau wrote:
>> On 20-05-11 16 h 48, Utkarsh Gupta wrote:
>>> Hi Hans,
>>>
>>> On Tue, May 12, 2020 at 2:03 AM Hans-Christoph Steiner  
>>> wrote:
>>>> Ok, this has become a bit more urgent since someone has moved my package
>>>> fdroidserver into PAPT without asking me.  Now I cannot push commits to
>>>> it.  So either someone needs to grant me PAPT access or put my package
>>>> back where it was in salsa.  I'm fine with fdroidserver being in PAPT,
>>>> I'm not fine with being locked out of my package.
>>>
>>> I am sorry this happened (though I've no idea who did it).
>>> Whilst I don't have the right permissions/access to add you to PAPT
>>> officially, I have given you maintainer access to fdroidserver so this
>>> won't be a blocker to you.
>>
>> Hi,
>>
>> That was I, and I documented the process in bug #946105 [1]. As stated
>> on the BTS, the package was already in the PAPT but wasn't respecting
>> the policy, thus making team work harder.
>>
>> Looking at the package, it seems I forgot to push a patch to d/control
>> to change the VCS. Sorry for overlooking that, I did a bunch in a row
>> and must have skipped fdroidserver by mistake.
>>
>> I'll do that in a few minutes.
>>
>> Sorry if the changes to the repository path I made caused you problems.
>>
>> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946105
>>
> 
> Hmm, re-reading the BTS entry, it seems I went a little fast and didn't
> take in account you put the PAPT in the "Uploaders" field instead of the
> "Maintainer" one. I shouldn't have touched the package.
> 
> I guess that's why I didn't originally push a patch. Somehow
> fdroidserver ended up in the list I gave to the Salsa team when I asked
> them to migrate a bunch of repositories for us.
> 
> Again, sorry for the screw up :(


All's well that ends well.  I've got access now and I'm happy to have
the package in PAPT.  I put this package as Uploaders: since I'm also
upstream on fdroidserver, and we generally try to sync the release
process with Debian, so new upstream releases should be handled accordingly.

.hc

Re: joining the PAPT

[Hans-Christoph Steiner]

Ok, this has become a bit more urgent since someone has moved my package
fdroidserver into PAPT without asking me.  Now I cannot push commits to
it.  So either someone needs to grant me PAPT access or put my package
back where it was in salsa.  I'm fine with fdroidserver being in PAPT,
I'm not fine with being locked out of my package.

.hc

Hans-Christoph Steiner:
> 
> Hey all,
> 
> I'm a DD and a long time member of PMPT  I would like to join the PAPT.
>  I am packaging https://github.com/cryptax/droidlysis and I think it
> fits best in PAPT.  I am also willing to be a sponsor for packages I
> know something about or are simple enough that I can understand them.
> 
> I have read and accept the PAPT policy at
> https://salsa.debian.org/python-team/tools/python-apps/-/blob/c0eb83b9/policy.rst
> 
> My salsa username is eighthave, same as PMPT.
> 
> .hc
> 
> 

joining the PAPT

[Hans-Christoph Steiner]

Hey all,

I'm a DD and a long time member of PMPT  I would like to join the PAPT.
 I am packaging https://github.com/cryptax/droidlysis and I think it
fits best in PAPT.  I am also willing to be a sponsor for packages I
know something about or are simple enough that I can understand them.

I have read and accept the PAPT policy at
https://salsa.debian.org/python-team/tools/python-apps/-/blob/c0eb83b9/policy.rst

My salsa username is eighthave, same as PMPT.

.hc




signature.asc
Description: OpenPGP digital signature

Re: Streamlining the use of Salsa CI on team packages

[Hans-Christoph Steiner]

Raphael Hertzog:
> Hi,
> 
> On Sun, 15 Sep 2019, Louis-Philippe Véronneau wrote:
>> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is
>> the most mature solution, has more contributors and has more features
>> (including reprotest and piuparts). This option seems to have had the
>> most support so far.
> 
> Ack. I also deployed this pipeline on 500 Kali packages at
> https://gitlab.com/kalilinux/packages/
> and it has been working relatively well. There are a couple
> of remaining issues but the project is evolving quickly and I'm
> confident that we can get past them.
> 
> One of the issue is related to the fact that the CI build does not bump
> the version and it can conflict with the version in the archive and it
> will often confuse piuparts.
> https://salsa.debian.org/salsa-ci-team/pipeline/issues/78
> 
> The project is a bit lacking in terms of leadership/guidance and there are
> pending issues that should have been resolved more quickly to avoid
> confusion and better define the rules:
> https://salsa.debian.org/salsa-ci-team/pipeline/issues/84
> https://salsa.debian.org/salsa-ci-team/pipeline/issues/76
> https://salsa.debian.org/salsa-ci-team/pipeline/issues/86
> 
>> For step 2, so far people seemed to agree that:
>>
>> * having a standardised CI pipeline is a good idea
>> * the CI should be used as a tool to help us improve our packages, and
>> not be required to pass
> 
> On this, I disagree. The CI should pass, but it's perfectly OK to
> disable some of the failing tests to make it pass. We want merge requests
> to run the CI and we want them to succeed to prove that they are not
> making the package regress compared to the current situation.
> 
> Consider that the package tracker is likely to display the CI status at
> some point.
> 
> Note that for merge request, it won't really work until 
> https://gitlab.com/gitlab-org/gitlab/issues/30242 gets fixed in GitLab.

That's a good point. The tests that are there should be required to
pass, otherwise they can be removed, run manually, run in dev branches,
or set to "allow_failure: true" in a specific job.

That reminds me of a related topic I've been thinking about:  should
salsa's GitLab-CI setup be considered its own test tool, or just purely
a conduit for the other standard Debian test methods (lintian,
autopkgtest, piuparts, reprotest, etc).  I'm on the fence about this, so
I opened this discussion:
https://salsa.debian.org/salsa-ci-team/pipeline/issues/111

.hc

Re: Streamlining the use of Salsa CI on team packages

[Hans-Christoph Steiner]

Louis-Philippe Véronneau:
> On 19-09-05 01 h 40, Louis-Philippe Véronneau wrote:
>> Hello folks!
>>
>> I'd like to propose we start using Salsa CI for all the team packages. I
>> think using a good CI for all our packages will help us find packaging
>> bugs and fix errors before uploads :)
>>
>> I also think that when possible, we should be using the same CI jobs for
>> our packages. The Salsa CI Team's default pipeline [1] is a good common
>> ground, as currently it:
>>
>> * builds the package
>> * runs piuparts
>> * runs autopkgtest
>> * runs lintian
>> * runs reprotest
>> * and does more!
>>
>> I don't think a failing CI should be a blocker for an upload, but I
>> think it's a good red flag and should be taken in account.

Sounds good.

>> I know the Ruby team also decided to use debian/salsa-ci.yml instead of
>> debian/gitlab-ci.yml [2]. I guess we should also do the same.

This is still an open question:
https://salsa.debian.org/salsa-ci-team/pipeline/issues/86

Debian has a bad habit of customizing things that do not need to be
customizing.  That raises the barrier for contributors ever higher, in a
"death by a thousand papercuts" kind of way.  I think we should stick to
the standard file name for GitLab CI.


>> Thoughts? If we decide to go ahead with this, I guess we should modify
>> the policy accordingly and contact the Salsa Team to see if adding this
>> additional load is OK with them.

I think people should add these manually as they see a need.  Then only
if the Salsa Team says they really have the capacity, add it to all
packages.


>> [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
>> [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245
> These are the steps I see going forward with this:
> 
> --
> 1. Agree on a default pipeline we should be using on the DPMT & PAPT
> packages.
> 
> 2. Draft a proposed modification to the DPMT and the PAPT policies
> 
> 3. Adopt that proposed modification once we reach consensus
> 
> 4. Wait for the "All Clear" from the Salsa Team
> 
> 5. Commit the previously agreed upon CI pipeline to all the DPMT & PAPT
> packages, while making sure the CI isn't ran on that push ("-o ci.skip")
> --
> 
> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is
> the most mature solution, has more contributors and has more features
> (including reprotest and piuparts). This option seems to have had the
> most support so far.

I just checked out salsa-pipelines' piuparts support, it should take me
a couple hours to port it, if its needed.

I think reprotest and piuparts are going to be too heavy for gitlab-ci,
unless their use is manually triggered, or only on releases.  For
example, this salsa-pipeline piuparts-only job timed out after 2 hours
without having completed:
https://salsa.debian.org/debian/dpdk/-/jobs/221036
The reprotest failed after 30 minutes:
https://salsa.debian.org/debian/dpdk/-/jobs/221032

For ruby-fog-aws, these were much shorter:
https://salsa.debian.org/ruby-team/ruby-fog-aws/pipelines/63361
piuparts: ~5 minutes
reprotest: ~10 minutes

The whole libcloud job (build, package, lintian, autopkgtest) takes <10
minutes:
https://salsa.debian.org/python-team/modules/libcloud/-/jobs/248526

The whole androguard took ~13 minutes:
https://salsa.debian.org/python-team/modules/androguard/pipelines

Seems like there needs to be some load testing before pushing heavy
processes like reprotest and piuparts.


> Hans-Christoph Steiner proposed we use "ci-image-git-buidpackage"
> instead [2]. The code behind it is simpler and the way it's built makes
> it possible for maintainers to modify the CI for their packages.
> 
> For step 2, so far people seemed to agree that:
> 
> * having a standardised CI pipeline is a good idea
> * the CI should be used as a tool to help us improve our packages, and
> not be required to pass
> 
> Please contribute to this discussion if you care about this issue! I'll
> try to draft something more concrete in the next few days.
> 
> [1] https://salsa.debian.org/salsa-ci-team/pipeline
> [2] https://salsa.debian.org/salsa-ci-team/ci-image-git-buildpackage

Thanks for keeping this moving!

.hc

Re: Streamlining the use of Salsa CI on team packages

[Hans-Christoph Steiner]

Gregor Riepl:
> 
>> I am not a fan of pointing to a moving target with the "include" statement:
>>
>> include:
>>   - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
>>   -
>> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
>>
>> "master" will change, and that can break CI jobs where nothing in the
>> local repo has changed.
> 
> It does have pros and cons.
> 
> The good: Additional build/verification steps or even automatic deployment can
> be added by the Salsa team at some point without requiring changes to each
> repository.
> 
> The bad: As you mentioned, a moving target can be bad and cause inadvertent
> build failures and other issues that are out of the hands of maintainers.
> 
> The ugly: Pulling in external scripts always bears a certain risk. They may go
> away at some point or cause potentially dangerous side effects.
> 
> However, I do think that a standardised CI pipeline is very useful. Consider
> that the buildd infrastructure also uses a standardised build process that
> packages cannot simply get away from. If this process is replicated on Salsa,
> with an external script or not, people will quickly get a "glimpse" of what
> would happen on buildd. The need to manually adapt the CI script every time
> something changes in the buildd process is a heavy burden to bear and will
> easily lead to people "forgetting" to update their scripts. That kind of
> defeats the purpose.
> 
> Also, consider that the Salsa CI pipeline is not an absolute source of truth,
> but a tool for developers and maintainers to quickly spot issues with their
> packages. If an autobuild fails, it's not the end of the world. It just means
> you have to go check what's going on.
> 

I totally agree about having a standardized build process and CI
pipeline.  And I agree that the CI builds are a tool, not the final
release build process. As for updating that config, in Debian we already
have a well known update mechanism: `apt-get upgrade`.  The CI builds
can use that same process, we don't need to introduce a new one just for
CI builds (e.g. dynamic links to files in gitlab).

These CI environment configs can be included in a Debian package.  This
has been my goal with ci-image-git-buildpackage.  The bits are all shell
scripts which can easily be included in a Debian package.  The mechanism
used in salsa-ci-team/pipeline is a mystery, even to me, and I've been
using GitLab-CI since the beginning (2015), and setting up CI systems
since 2006 (bash scripts!).  There is obviously a lot of great work in
salsa-ci-team/pipeline, I just question the interface between it and the
Debian Developer: how its specified in the .gitlab-ci.yml file.

.hc

Re: Streamlining the use of Salsa CI on team packages

[Hans-Christoph Steiner]

I think we should definitely use Gitlab-CI!  The
'salsa-ci-team/pipeline' project does have good coverage, with reprotest
and piuparts.  I'm the lead dev on another approach, also part of the
salsa-ci-team, called 'ci-image-git-buildpackage':
https://wiki.debian.org/Salsa/Doc#Running_Continuous_Integration_.28CI.29_tests

It has lintian, autopkgtest and more, but lacks piuparts and reprotest.
 It does have "aptly" support where it will automatically build and
deploy binary packages to a apt repo.  Then other CI builds can add
those repos for CI runs.  This is very helpful for complex suites of
packages that depend on each other.  We use it in the Android Tools Team
(click on any "pipeline" button to see it in action):
https://salsa.debian.org/android-tools-team/admin

'salsa-ci-team/pipeline' is quite simple for packages with simple
requirements.  One limitation with it is that you can't include a bash
script directly in the debian/.gitlab-ci.yml file, which is the normal
way of working with GitLab-CI.  That was a central requirement for
ci-image-git-buildpackage.  The automation is just bash commands, so you
can use them in a bash script as needed.  Or easily add multiple jobs,
or do anything you would normally do in GitLab-CI.  For example:
https://salsa.debian.org/android-tools-team/android-platform-system-core/blob/master/debian/.gitlab-ci.yml

I am not a fan of pointing to a moving target with the "include" statement:

include:
  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
  -
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml

"master" will change, and that can break CI jobs where nothing in the
local repo has changed.


Louis-Philippe Véronneau:
> Hello folks!
> 
> I'd like to propose we start using Salsa CI for all the team packages. I
> think using a good CI for all our packages will help us find packaging
> bugs and fix errors before uploads :)
> 
> I also think that when possible, we should be using the same CI jobs for
> our packages. The Salsa CI Team's default pipeline [1] is a good common
> ground, as currently it:
> 
> * builds the package
> * runs piuparts
> * runs autopkgtest
> * runs lintian
> * runs reprotest
> * and does more!
> 
> I don't think a failing CI should be a blocker for an upload, but I
> think it's a good red flag and should be taken in account.
> 
> I know the Ruby team also decided to use debian/salsa-ci.yml instead of
> debian/gitlab-ci.yml [2]. I guess we should also do the same.
> 
> Thoughts? If we decide to go ahead with this, I guess we should modify
> the policy accordingly and contact the Salsa Team to see if adding this
> additional load is OK with them.
> 
> [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
> [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245
> 

Re: GitLab CI on salsa.debian.org

[Hans-Christoph Steiner]

Diane Trout:
> Can you trigger test on dependencies changing?

You can cron test runs, that would then check the deps.

> Does CI run on architectures other than amd64?

That depends on the gitlab-ci-runners that are registered.  Anyone can
register CI-runners for their own projects, and CI runners can be any
Debian box or VM.  It works easiest with Docker setups.  CI runners can
be tagged, the jobs can be marked for the required tags.  So the CI
runners could be tagged based on arch.

I hope that salsa.debian.org will also have some shared CI runners for
other arches.

> (I was thinking of complex packages with many dependencies like dask,
> or with fiddly bit manipulation like pandas)
> 
> So this would get tests on each commit instead of the current
> autopkgtests which run on each build?

It runs on each new push to git, so if you push commits one at a time,
it'll run per commit.

.hc

> On Wed, 2018-03-21 at 15:27 +0100, Hans-Christoph Steiner wrote:
>> Since I got only crickets on this email, let me elaborate:  gitlab-ci
>> lets you run whatever you want as root via Docker images.  That means
>> its easy to run full builds, installs, and tests in gitlab-ci.  It
>> also
>> makes it easy to add CI tests for various releases, like to support
>> backports.
> 

Re: Buildbot maintenance by PAPT

[Hans-Christoph Steiner]

* Create an account on salsa and click "request to join" on the team page:
https://salsa.debian.org/python-team/applications

* Change the Vcs-* tags in debian/control to point to:
https://salsa.debian.org/python-team/applications/buildbot


* set the Maintainer or Uploaders in debian/control to:
Python Applications Packaging Team


Setting PAPT as Maintainer means anyone on the team can upload, etc.
directly.  Setting PAPT as Uploader and yourself as Maintainer: means
that you want people to check in with you before making changes.

.hc

Robin Jarry:
> Hi all,
> 
> after some discussions on https://bugs.debian.org/883529, Martin Borgert
> suggested that buildbot becomes maintained by the Python Applications
> Packaging Team.
> 
> That sounds like a good thing to have more than one person able to work
> on this package.
> 
> I am currently working on buildbot (both upstream dev and Debian
> packaging), I have read the Debian Python Policy and I'm not sure how to
> proceed for joining the PAPT.
> 
> Thanks for your guidance.
> 

Re: Help proposed for migration of PAPT repos to Salsa

[Hans-Christoph Steiner]

Joseph Herlant:
> Hi,
> 
> I've seen that there are some SVN repositories for PAPT on alioth and
> I was wondering if you'd want help to move them to Salsa.
> 
> I'm familiar with the procedure to transfert a repo from svn to git
> without loosing the tags, commits, branches, etc and I can do some on
> my spare time if it helps.
> 
> Best,
> Joseph
> 

Thanks for stepping up!  I'm excited to see all this motion towards
gitlab in Debian.  I'm one of the main devs of F-Droid.  A couple of
years ago, F-Droid moved to gitlab.  gitlab-ci has been a hugely
valuable tool, and the visibility and comfort of the github/gitlab user
experience to so many devs seems to have made F-Droid a lot more
visible, and we get a lot more contributions now.

.hc

GitLab CI on salsa.debian.org

[Hans-Christoph Steiner]

One great addition that GitLab gives us is CI builds with custom Docker
images, which will run the whole build/test process for each merge
request.  For example:

https://salsa.debian.org/eighthave/python-vagrant/-/jobs/4005

I have set up a prototype Docker image for running git-buildpackage
builds automatically.  This Docker image is built and deployed using
Gitlab CI (albeit on gitlab.com):

https://gitlab.com/eighthave/ci-image-git-buildpackage

Then any git-buildpackage package can be built by doing this:

* put git project on salsa
* In Settings -> CI/CD -> General pipelines settings ->
  Custom CI config path, set it to:  debian/.gitlab-ci.yml
* include debian/.gitlab-ci.yml in the git repo with this contents:



image: registry.gitlab.com/eighthave/ci-image-git-buildpackage:latest

build:
  artifacts:
paths:
- *.deb
expire_in: 1 day
  script:
- /gitlab-ci-git-buildpackage
- dpkg -i ../*.deb || apt-get install -f
- mv ../*.deb .



I think we can do a lot of automation in the Docker image, like some of
the stuff I've already done in ci-image-git-buildpackage.  If someone
knows how to get ENTRYPOINT and/or CMD working with GitLab CI, then
/gitlab-ci-git-buildpackage could be run automatically.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556

Re: GnuPG signatures on PyPI: why so few?

[Hans-Christoph Steiner]

Donald Stufft:
> 
>> On Mar 12, 2017, at 10:35 PM, Paul Wise  wrote:
>>
>> On Mon, Mar 13, 2017 at 4:28 AM, Jeremy Stanley wrote:
>>
>>> upload them to PyPI since the authors of the coming Warehouse
>>> replacement for the current CheeseShop PyPI have already indicated
>>> that they intend to drop support for signatures entirely.
>>
>> Did they give any reasoning for this decision?
>>
> 
> 
> https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html 
> 
> 
> —
> Donald Stufft

Your analysis makes sense: the hardest part of this problem is managing
_who_ is the trusted signer of a given package.  TOFU
(Trust-On-First-Use) is the easy case here: the first person to sign the
release is the one to trust.  Android's APK signature verification for
updates is entirely based on that principal.

It seems that so many Python and Java library developers (mavenCentral
is in a similar boat to PyPi) just want to ignore the signing key
management because its annoying.  Yes, it is annoying, I do a lot of it.
 Android forces all devs to manage a signing key: unsigned APKs are not
installable, and Google Play even rejects APKs signed by debug keys.

I think the Android/Google Play model would work quite well for PyPI,
but the social problem of getting python devs to take responsibility
would be the hard part.  I manages the transition of F-Droid app repos
to only signed, which is a small example.  There were some complaints,
but nothing so bad when we pointed them to the fdroid tool that
automatically generated the signing key for them.  pip can easily
generate and use a signing key (GPG, TUF, whatever) automatically.  Then
devs just need to learn out to safely manage them.  Android Studio's key
generation is pretty new, and has kind of shitty security
recommendations.  Android devs are still learning, but I think overall,
its working out well there.

As for TUF (The Update Framework), I know the concepts well.  I've
looked into it while implementing the F-Droid security model
(https://f-droid.org/wiki/page/Security_Model).  It does not deal with
the issue of managing identity of package uploaders at all, it assumes
you already have all the software in place, and just deals with
distributing updates.  Also, with TUF, you'll be in the exact same boat
here: signing keys are required per package stream, so each developer
will need to managing signing keys.

.hc

Re: #850098 subliminal: change of upstream structure

[Hans-Christoph Steiner]

I don't work on any of those packages, but I think your logic makes sense.

.hc

Carl Suster:
> I see that subliminal is currently using the tarballs from PyPI and then
> patching in the source for the nautilus extension which is of course
> absent from there. Also the Github-hosted tarballs include a test suite
> which is not in the PyPI tarballs.
> 
> It seems that the upstream nautilus extension has now moved to a
> different dedicated upstream repo:
> 
>   https://github.com/Diaoul/nautilus-subliminal
> 
> Unfortunately this repository does not seem to have versioned releases,
> and has not seen an update in several months. My thinking is that if we
> continue to provide the nautilus extension at all, it should be built by
> a new source package src:subliminal-nautilus (which could potentially
> also build the nemo extension provided in a different branch of the
> upstream repo) tracking snapshots of the upstream git.
> 
> I am happy to work on this as part of packaging the latest upstream
> release, but I just wanted to check before I do so that:
> 
>   1) the source split I proposed is sensible (if so I'll probably just
> drop the nautilus extension for now and reopen
> https://bugs.debian.org/821455 until I repackage the extension in its
> new home), and
> 
>   2) if the split is ok, which if either Python packaging team would
> make a good home for the nautilus extension, and
> 
>   3) it's ok to change the tarballs to the Github ones and update the
> d/watch accordingly. The point of this would be to be able to run the
> test suite.
> 
> Cheers,
> Carl
> 

Re: pip for stretch

[Hans-Christoph Steiner]

Donald Stufft:
>>
>> On Nov 21, 2016, at 6:33 PM, Barry Warsaw  wrote:
>>
>> I have not started to look at what if anything needs to be done to transition
>> to pip 9, but if you have a strong opinion one way or the other, please weigh
>> in.
>>
> 
> 
> As one might expect, I would prefer it if folks got 9.0.1 as quickly as 
> possible. In particular the feature that makes it easier for upstreams to drop
> Python 2 support is one that is really only effective when people can consider
> pip 9 a "minimum" version of pip to support. Getting it into the hands of 
> folks
> as quickly as possible would be a big boon to that.
> 
> —
> Donald Stufft

I'm with Donald here.  It'll help both the Debian ecosystem to be more
closely aligned with the current tools as well as the Python ecosystem
since it'll help speed up the transition to Python3.  The more people
see the Debian Python packages as a viable option for deployment and
development, the better Python in Debian will be maintained since there
will be more people relying on the packages.

But of course, this decision also depends on how much work it would be.
I don't think pip 9 is an absolute requirement, but I do think its worth
some effort.

.hc

Re: Source package name with python- or without?

[Hans-Christoph Steiner]

Scott Kitterman:
 On June 9, 2015 9:08:06 AM EDT, Thomas Goirand z...@debian.org wrote:
 On 06/08/2015 08:13 AM, Piotr Ożarowski wrote:
 [Tim Landscheidt, 2015-06-08]
 Should source package names (Source: in debian/control) be
 prefixed with python-?

 no.

 I use python- prefix for source package name only if the name is
 not unique enough.

 I have the opposite view, and I very much prefer to prefix with
 python- all of the source packages I upload, when that's a python
 module (I don't do that for applications).

 One very good reason for this is sorting the files when you do ls, or
 in your QA page, on gitweb/cgit, etc. Also, not polluting the general
 namespace is a good idea.
 
 If the upstream name isn't python-*, then the namespace is already polluted.  
 Personally, I think upstream name for the source package is best unless it's 
 really generic. 
 
 Scott K

I see this two ways:

* if the source package only produces a single python- and python3- package,
then I make the source package name with python- so that there are fewer names
to keep track off, and it is easy to find the source package

* if the source package produces more than one python- package and/or more
than one python3- package, then I use the source name.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557aec5d.70...@at.or.at

Re: Resources/best practices for making a .deb out of a virtualenv

[Hans-Christoph Steiner]

I've used python-stdeb to make Debian packages out of standard projects, then
you can upload those packages to a PPA like on launchpad.net, and it is also
easy to get them into Debian-proper.

https://packages.debian.org/python-stdeb

Try py2deb or pypi-install from that package.

.hc


Tim Chase:
 I've got a Python project where the dependencies are
 isolated in a virtualenv and would like to package it up as a .deb
 the purposes of sharing.  Normally I'd include the additional
 libraries as straight-forward dependencies of the Debian package
 itself, but some of the required package-versions conflict with the
 stock Stable or Installation packages (e.g. Django 1.4 in Stable vs.
 1.6 or 1.7 which are more current versions).
 
 Are there any good resources on how to package up a virtualenv for
 distribution so that it can use more recent libraries?
 
 (I'm not currently subscribed to the mailing list, but will if that's
 easer than just CC'ing me or Reply-All'ing me).
 
 Thanks,
 
 -Tim
 
 
 
 


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ad28c1.5060...@at.or.at

Re: Keeping upstream commits separate from Debian packaging commits

[Hans-Christoph Steiner]

Barry Warsaw wrote:
 On Oct 16, 2014, at 09:26 AM, Tristan Seligmann wrote:
 
 I would expect it to make merging / rebasing Debian patches on top of
 a new upstream version easier, since you have the granular history of
 changes to the source tree, not one massive single commit which may
 not be accurate (eg. renames of change files may not be detected
 etc.). On the flip side, if there are few or no patches to the
 upstream source, then it probably doesn't matter much at all.
 
 Yep.  I get that, although it ought not to be *too* hard usually to just clone
 upstream separately and generate patches from there.  But agreed that if there
 are a lot of those such things, it can be less convenient.

Having the upstream commits in the packaging repo is also quite useful if you
need to make a release that is not an official one, like based on a specific
commit rather than a tag.  It also makes it easier to manage generating an
orig tarball if upstream does not make one.  If the upstream git is very
active, then it can be annoying to follow the packaging commits.


 I do think the benefits of team maintenance are diminshed quite a lot
 when packages need to have such specialized instructions, so aiming
 for a standardized workflow / configuration (*whatever* that might
 be!) is valuable.
 
 Fully agreed.  I feel strongly that we want to preserve the current team
 default where you can essentially just debcheckout any team package and not
 have to guess about its workflow.
 
 Cheers,
 -Barry

I also agree, a standard, documented workflow is very valuable.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543fdc14.4040...@at.or.at

Re: Keeping upstream commits separate from Debian packaging commits

[Hans-Christoph Steiner]

Thomas Goirand wrote:
 On 10/12/2014 05:15 PM, Tristan Seligmann wrote:
 I wasn't at Debconf, maybe this is why I'm a bit confused by what you
 wrote here. pristine-tar and upstream VCS merge are in no way mutually
 exclusive, but you seem to be implying that they are
 
 Using pristine-tar and pulling from upstream VCS is silly. If you do
 like this, then why not just doing tag-based packaging? That's a lot
 safer than just re-tagging on top of what upstream does (ie: no risk to
 introduce any difference).

 Using upstream tags
 *without* using pristine-tar would seem to be inadvisable
 
 For what reason exactly? In what way pristine-tar helps when basing your
 packaging on upstream Git tags?

I think its quite useful since it will show you differences between the
upstream git repo, and the upstream orig tarballs.  From my experience, they
are different most of the time, and I have caught bugs in upstream's tarballs
by doing this.

.hc




 I haven't seen anyone write importing upstream VCS into the Alioth
 repo is forbidden anywhere; if this is the intent, then perhaps it
 should be clearly spelled out somewhere. (Or perhaps it already is,
 and I just missed it? In which case, whoops)
 
 Hum... Then maybe we should talk again.
 
 On 10/13/2014 06:19 AM, Barry Warsaw wrote:
 Does upstream vcs add value?
 
 Of course! Lots of value. One of them is that you'd be downloading tiny
 deltas, instead of constantly downloading a tarball, doing
 git-import-orig, etc. Another one is doing cherry-picking of changes.
 Another one is being able to do a Debian package based on any commit
 from upstream, if you do need that. Finally, it makes it easier for you
 to send a patch upstream based on your debian-specific patch (just grab
 it from your debian/patches folder, apply to the master branch, then
 git review or git push to github/bitbucket/git-cafe/you-name-it...).
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544008a4.9060...@at.or.at

Re: Keeping upstream commits separate from Debian packaging commits

[Hans-Christoph Steiner]

Thomas Goirand wrote:
 On 10/12/2014 05:15 PM, Tristan Seligmann wrote:
 I wasn't at Debconf, maybe this is why I'm a bit confused by what you
 wrote here. pristine-tar and upstream VCS merge are in no way mutually
 exclusive, but you seem to be implying that they are
 
 Using pristine-tar and pulling from upstream VCS is silly. If you do
 like this, then why not just doing tag-based packaging? That's a lot
 safer than just re-tagging on top of what upstream does (ie: no risk to
 introduce any difference).

 Using upstream tags
 *without* using pristine-tar would seem to be inadvisable
 
 For what reason exactly? In what way pristine-tar helps when basing your
 packaging on upstream Git tags?

I think its quite useful since it will show you differences between the
upstream git repo, and the upstream orig tarballs.  From my experience, they
are different most of the time, and I have caught bugs in upstream's tarballs
by doing this.

.hc




 I haven't seen anyone write importing upstream VCS into the Alioth
 repo is forbidden anywhere; if this is the intent, then perhaps it
 should be clearly spelled out somewhere. (Or perhaps it already is,
 and I just missed it? In which case, whoops)
 
 Hum... Then maybe we should talk again.
 
 On 10/13/2014 06:19 AM, Barry Warsaw wrote:
 Does upstream vcs add value?
 
 Of course! Lots of value. One of them is that you'd be downloading tiny
 deltas, instead of constantly downloading a tarball, doing
 git-import-orig, etc. Another one is doing cherry-picking of changes.
 Another one is being able to do a Debian package based on any commit
 from upstream, if you do need that. Finally, it makes it easier for you
 to send a patch upstream based on your debian-specific patch (just grab
 it from your debian/patches folder, apply to the master branch, then
 git review or git push to github/bitbucket/git-cafe/you-name-it...).
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54400a96.7090...@at.or.at

Re: Keeping upstream commits separate from Debian packaging commits

[Hans-Christoph Steiner]

Tristan Seligmann wrote:
 On 16 October 2014 18:01, Thomas Goirand z...@debian.org wrote:
 Using pristine-tar and pulling from upstream VCS is silly. If you do
 like this, then why not just doing tag-based packaging? That's a lot
 safer than just re-tagging on top of what upstream does (ie: no risk to
 introduce any difference).
 
 If you are fetching the upstream revisions / tags into your packaging
 repository, you can use the upstream tag exactly as-is, no need to
 re-tag (and indeed re-tagging would generally be a bad idea).

I think there is a lot of value to always including the Debian upstream/v1.0
tag.  It provides a standard way to access the upstream version across all
repos.  There is no such standard out there in the wild.  There are tags
like v1.0, 1.0, release-1.0, the-real-1.0, etc. etc.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54400a98.3010...@at.or.at

Re: Proposed git migration plan

[Hans-Christoph Steiner]

I think this plan makes a lot of sense.  I'll just throw in my two bits for a
couple of other points:


* the git-buildpackage workflow is really quite wonderful and reasonably
flexible, I highly recommend it, and I think it will improve the productivity
of this team.


* Vcs-Git and Vcs-Browser should use the HTTPS link by default.  This helps
protect the privacy of people who might want to contribute.  Perhaps where you
are this is not a concern, but there are many parts of the world where the
government actively monitors all internet traffic, and Debian should be aware
that trivial changes like this can be quite helpful for people in such
situations. HTTPS is fully supported on alioth and the HTTPS Vcs-Git link is
included at the bottom of every cgit page:

For example, see the bottom of this:
https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/
You'll find this:
https://anonscm.debian.org/git/python-modules/packages/python-django.git


* please don't ban mirrors or pull requests from other services.  I agree that
non-free services should not be encouraged, but banning them is
counter-productive since they have the vast majority of the mindshare of free
software developers.


.hc

Barry Warsaw wrote:
 Here's the page I mentioned regarding a *proposed* transition plan to using
 git for team packages.  It's more or less a brain dump right now, and don't
 feel like you need to read it before the DC14 session.
 
 https://wiki.debian.org/Python/GitPackaging
 
 Food for thought and discussion.
 -Barry
 


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fcd3ab.9000...@at.or.at

Re: policy for source package names

[Hans-Christoph Steiner]

Barry Warsaw wrote:
 On Aug 05, 2014, at 04:09 PM, Hans-Christoph Steiner wrote:
 
 I think it is a good practice to make the source package name the same as the
 binary package name as long is there isn't a good reason to do otherwise.  So
 with any source package that produces one binary package, those names should
 match.  That keeps the Debian namespace smaller and more easy to understand.

 If a source package produces more than one binary package, then I think it
 makes the most sense to name the source package using the upstream name,
 barring name conflicts, too general a name, etc.
 
 In the context of Python libraries, please try to be pro-active, especially if
 you know that the upstream is or will be supporting both Python 2 and 3.
 
 plan-for-success-ly y'rs,
 -Barry

I suppose I was being too general.  For python packages, I generally use the
python- form for both the source and python2 package.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e23e74.3060...@at.or.at

Re: policy for source package names

[Hans-Christoph Steiner]

olivier.sal...@codeless.fr wrote:
 
 On 08/05/2014 12:04 AM, Vincent Cheng wrote:
 On Mon, Aug 4, 2014 at 2:17 PM, Antonio Valentino
 antonio.valent...@tiscali.it wrote:
 Hi list,
 I read in [1] and [2] that binary packages with public modules should
 have the python- (or python3-) prefix in the name.
 I'm wondering if the same naming rules should be used for source packages.

 I'm preparing some new packages so I would like to be sure I'm using the
 correct naming before the first upload.

 AFAIK, no, there aren't any hard and fast rules regarding source
 package names. In fact, I don't think there are any rules at all; just
 don't pick a source package name that's already taken, and pick one
 that is relevant to your package (if you take a look at existing DPMT
 packages [1], most of them either use their module name, or prefix it
 with python-).
 We have discussed some times about this in different groups (DebianMed
 Debian Java ).
 I think that usual way is to use for source package the name of the
 upstream software (if not already taken of course and matching general
 name rules).
 
 Olivier
 Regards,
 Vincent

I think it is a good practice to make the source package name the same as the
binary package name as long is there isn't a good reason to do otherwise.  So
with any source package that produces one binary package, those names should
match.  That keeps the Debian namespace smaller and more easy to understand.

If a source package produces more than one binary package, then I think it
makes the most sense to name the source package using the upstream name,
barring name conflicts, too general a name, etc.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e139e0.7060...@at.or.at

upgrading python-libcloud to latest upstream

[Hans-Christoph Steiner]

I'd like to update python-libcloud to the latest (0.14.1) or at least a newer
one.  In the package's SVN, there is already an 0.10 update in it.

Anyone know the status of this? Are there any blockers or shall I just commit
and upload?

http://packages.qa.debian.org/libc/libcloud.html

.hc



signature.asc
Description: OpenPGP digital signature

Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

[Hans-Christoph Steiner]

On 01/14/2014 09:31 AM, Barry Warsaw wrote:
 On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote:
 
 I've used git-buildpackage with git-svn on submodules of the DPMT SVN
 repo without too many difficulties so far.
 
 I need to spend more time playing with git-bp, but last time I looked at it
 (cannot remember which package), I had a lot of trouble unless the package
 repo was organized Just Right.  One nice thing about svn-bp is that it pretty
 much just works with a checked out working directory, even when you have local
 uncommitted changes (--svn-ignore-new).
 
 git-bp OTOH required a specific set of branches inside the repo to stitch
 everything together and if those were missing, it failed miserably.  I could
 be totally wrong about that, or I could have just been using the tool
 incorrectly.
 
 I've mostly made my peace with git, so in theory I wouldn't be opposed to the
 team switching, but I still think it's not a good idea to have some team
 packages in git and the bulk in svn.  I value the ability to use the same
 tools and workflows for all team maintained packages.
 
 I'm not motivated enough to do any work on such a transition itself, so I
 think those who really want to switch to git need to work out a plan.  That
 would include test repos, documentation updates, transition plans, educating
 team members, fielding questions, fixing problems, etc.  I would personally be
 supportive, and would be willing to review material and test out recipes.  But
 I think this is going to require a few committed people to do some heavily
 lifting over an extended period of time to make sure such a transition was
 smooth and so that everyone on this team was comfortable with the new way of
 doing things.
 
 That's just my opinion, of course.
 -Barry

I know what you mean about it having a brittle setup, but git-buildpackage has
improved a lot over the past couple of years.  One key thing that helps when
using git-buildpackage in a team setting (pkg-multimedia is a good example) is
having a standard debian/gbp.conf that configures everything in a standard way
for that team.

For example, it would be great to include a debian/gbp.conf that sets up the
git-svn stuff and check that into svn projects.  Then people can easily use
git-buildpackage and still commit to svn repos.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d55426.6030...@at.or.at

Re: Joining the DPMT and git.debian.org access

[Hans-Christoph Steiner]

On 01/14/2014 08:24 AM, Alexandre Rossi wrote:
 Hi,
 
 My goal is to maintain sockjs-twisted (#735154).

 the problem is... we don't use git, not yet at least (nobody had time to
 propose a transition)
 
 The Wiki page[1] suggests there are some git repositories, but I
 cannot find/see them. I also found out that some packages maintained
 by the team are hosted on alioth in collab-maint (src: bugz,
 dajaxice).
 
 Regarding the transition, the Java packaging team has both git and svn
 repositories. Maybe the DPMT can do the same starting with my package
 in the path suggested by the Wiki.
 
 Advice?
 
 Alex
 
 [1] https://wiki.debian.org/Teams/PythonModulesTeam/

I'm a fan of a gradual transition like this, with people switching or setting
up git repos as they can.

.hc


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d55342.5060...@at.or.at

Re: RFR: python-qrcode -- native python module to generate QR codes

[Hans-Christoph Steiner]

On 04/14/2013 03:10 AM, Cornelius Kölbel wrote:
 Am 13.04.2013 05:46, schrieb Hans-Christoph Steiner:
 On 02/21/2013 03:34 PM, Cornelius Kölbel wrote:
 Am 21.02.2013 20:42, schrieb Jakub Wilk:
 * Cornelius Kölbel cornelius.koel...@lsexperts.de, 2013-02-21, 20:14:
 http://mentors.debian.net/debian/pool/main/q/qrcode/qrcode_2.4.2-1.dsc
 Great. The mentors site suddenly gives me lintian warnings, that were
 not there earlier and that did give the linitan on my debian
 experimental. :-(
 There's only one lintian warning:

 W: qrcode source: debhelper-overrides-need-versioned-build-depends (=
 7.0.50~)

 This tag was been retired in Lintian 2.5.11, because stable has a
 newer debhelper version, and oldstable is not supported anymore. (I
 would have preferred if the tag was made pedantic rather than removed,
 but oh well...)

 The remaining tags are informative:

 I: qrcode source: quilt-patch-missing-description add-man-page
 I: python-qrcode: hyphen-used-as-minus-sign usr/share/man/man1/qr.1.gz:7
 I: python-qrcode: hyphen-used-as-minus-sign usr/share/man/man1/qr.1.gz:13
 I: python-qrcode: hyphen-used-as-minus-sign usr/share/man/man1/qr.1.gz:19

 Anyway.
 ...and again I upload a hopefully again nicer version.
 I hope the next package will be less complicated...
 I'm interesting in sponsoring this package and uploading it, if no one else
 has claimed it.  Cornelius, do you have a git or svn repo for this package
 yet?  If not, I can set up a git repo on collab-maint.

 .hc

 Hello Hans-Christoph,

 to my knowledge till now noone has claimed the package.
 So I would very much appreciate, if you would sponsor this package.

 There is the git repo of the upstream package, which is located here:

 https://github.com/lincolnloop/python-qrcode

 As part of an internal git I have my addons (Makefile to download, patch
 and build the package) in this repository.
 So if this should be in a public git, we should move it there, yes, thanks!

 There is one thing for me to do:
 The upstream was updated to 2.5.1, and I would have to build a new
 package from this.

 Thanks a lot and kind regards
 Cornelius

There is a new style of organizing git repos for packages that have upstream
git repos that I want to try.  It allows you to have the upstream history, the
tarball/release history, and the debian packaging history all in one repo, all
while being easily buildable using git-buildpackage.

http://www.eyrie.org/~eagle/journal/2013-04/001.html
http://www.eyrie.org/%7Eeagle/journal/2013-04/001.html

So if you don't mind, I'd like to merge in the commits from your git into a
new repo that I build up.

.hc


signature.asc
Description: OpenPGP digital signature

Re: RFR: python-qrcode -- native python module to generate QR codes

[Hans-Christoph Steiner]

On 02/21/2013 03:34 PM, Cornelius Kölbel wrote:
 
 Am 21.02.2013 20:42, schrieb Jakub Wilk:
 * Cornelius Kölbel cornelius.koel...@lsexperts.de, 2013-02-21, 20:14:
 http://mentors.debian.net/debian/pool/main/q/qrcode/qrcode_2.4.2-1.dsc
 Great. The mentors site suddenly gives me lintian warnings, that were
 not there earlier and that did give the linitan on my debian
 experimental. :-(

 There's only one lintian warning:

 W: qrcode source: debhelper-overrides-need-versioned-build-depends (=
 7.0.50~)

 This tag was been retired in Lintian 2.5.11, because stable has a
 newer debhelper version, and oldstable is not supported anymore. (I
 would have preferred if the tag was made pedantic rather than removed,
 but oh well...)

 The remaining tags are informative:

 I: qrcode source: quilt-patch-missing-description add-man-page
 I: python-qrcode: hyphen-used-as-minus-sign usr/share/man/man1/qr.1.gz:7
 I: python-qrcode: hyphen-used-as-minus-sign usr/share/man/man1/qr.1.gz:13
 I: python-qrcode: hyphen-used-as-minus-sign usr/share/man/man1/qr.1.gz:19

 Anyway.
 ...and again I upload a hopefully again nicer version.
 I hope the next package will be less complicated...

I'm interesting in sponsoring this package and uploading it, if no one else
has claimed it.  Cornelius, do you have a git or svn repo for this package
yet?  If not, I can set up a git repo on collab-maint.

.hc



signature.asc
Description: OpenPGP digital signature

Re: DD requesting to join python-modules-team

[Hans-Christoph Steiner]

On Oct 9, 2012, at 4:48 AM, Jakub Wilk wrote:

 * Hans-Christoph Steiner h...@eds.org, 2012-10-08, 20:14:
 I'm a DD that is working on a couple python module packages.  I have 
 'pyjavaproperties' already in wheezy/unstable and python-pure-otr in the 
 works, packaged as 'python-potr' since that was the original name and the 
 library is still called 'potr', i.e. import potr
 
 Welcome to the team! :)
 
 Please note that we use Subversion as VCS:
 https://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowTo (but replace 
 apps with modules).

For a team package, is git-buildpackage out of the question?  If so, I can 
convert.

.hc


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/110c41fb-accb-49f1-830b-c0d3dfa4e...@at.or.at

DD requiesting to join python-modules-team

[Hans-Christoph Steiner]

hey all,

I'm a DD that is working on a couple python module packages.  I have
'pyjavaproperties' already in wheezy/unstable and python-pure-otr in the
works, packaged as 'python-potr' since that was the original name and
the library is still called 'potr', i.e. import potr

I'm putting the python-modules-team as the Maintainer, if I'm slow to
respond, please feel free to fix and upload issues.

My alioth name is eighthave.

.hc



signature.asc
Description: OpenPGP digital signature