[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python3-scanpy 1.6.0 patched, could you take a look?



On 3/22/21 4:24 PM, Andreas Tille wrote:
Hi Robbi,

thanks for looking into scanpy.
You are welcome, this package I choose during Debian med online sprint and make me packaging it dependencies which is python-stdlib-list[1] and python-sinfo[2], which I so happy and glad to be able packaging two package on my first Debian packaging contribution, so I hope to help scanpy fixed and uploaded too :)


At first we should consider the name of the source package.  If this
software is just a Python module (and thus we only create python3-scanpy
binary package and no additional scanpy package) I'd recommend to rename
the source package to python-scanpy (and move the repository accordingly
to python-scanpy).  Steffen, you seem to know that software - so what do
you think?
I let the seniors on Debian med decide on this


* blocker 1.6.0-1 removed
* add missing dependencies
* fixed (patched) test file failure during execution

Your changes are sensible - but please do not create another changelog
entry for this.  The file debian/changelog is to record changes compared
to the previous Debian package upload.  If there was no previous package
we stick to

    scanpy (1.6.0-1) UNRELEASED; urgency=medium

and for the first upload the only entry here should be

   * Initial release (Closes: #970887)iff --git a/debian/changelog b/debian/changelog
index 9afc630..a346380 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-scanpy (1.6.0-2) UNRELEASED; urgency=medium
+scanpy (1.7.1-1) UNRELEASED; urgency=medium


(nothing else).  Speaking about this:  We should not leave anything that
has target distribution UNRELEASED inside the changelog.  Please always
edit inside the UNRELEASED changelog entry - and it will be set to
unstable once the package will be uploaded.  Users might read only the
latest changelog entry and will miss changes "hidden" under UNRELEASED.
In other words: The UNRELEASED "target distribution" is just for the
team members to know that a package is unreleased - not for the users.


It should be like this:

change log A
------------------------------------------------------------------------
scanpy (1.6.0-1) unstable; urgency=medium

  [ Robbi Nespu ]
* add pythons anndata, sinfo, setuptools-scm, legacy-api-wrap as dependencies
  * fixing test module which failed during execution

 -- Robbi Nespu <robbinespu@gmail.com>  Fri, 19 Mar 2021 23:05:47 +0800

  [ Steffen Moeller ]
  * Initial release (Closes: #970887)

    BLOCKER: ModuleNotFoundError: No module named 'sinfo'
 -- Steffen Moeller <moeller@debian.org>  Fri, 25 Sep 2020 01:33:40 +0200
------------------------------------------------------------------------

or

change log B
------------------------------------------------------------------------
scanpy (1.6.0-1) unstable; urgency=medium

  [ Robbi Nespu ]
  * Initial release (Closes: #970887)
* add pythons anndata, sinfo, setuptools-scm, legacy-api-wrap as dependencies
  * fixing test module which failed during execution

 -- Robbi Nespu <robbinespu@gmail.com>  Fri, 19 Mar 2021 23:05:47 +0800

  [ Steffen Moeller ]

    BLOCKER: ModuleNotFoundError: No module named 'sinfo'
 -- Steffen Moeller <moeller@debian.org>  Fri, 25 Sep 2020 01:33:40 +0200
------------------------------------------------------------------------

or

change log C
------------------------------------------------------------------------
scanpy (1.6.0-1) unstable; urgency=medium

  [ Steffen Moeller, Robbi Nespu ]
  * Initial release (Closes: #970887)

 -- Steffen Moeller <moeller@debian.org>  Fri, 25 Sep 2020 01:33:40 +0200
 -- Robbi Nespu <robbinespu@gmail.com>  Fri, 19 Mar 2021 23:05:47 +0800
------------------------------------------------------------------------

I think it should be like "change log C"? Correct me if I wrong.


I think you interpreted Diane correctly (from what I can read in the
attached text).
Yes the Diane are the maintainer. I assume it on-going-process to be upload by ftpmaster and take time time to be available.


IMHO we should always upload the latest upstream version - except if we
have very good reasons to stick to some older version.  So I'd recommend
you run

     routine-update

on this repository ... and afterwards strip down debian/changelog as I
described above.

Hope this helps


Yes this is very helpful. Thanks god there is "routine-update", but when I ran it, I get error

$ routine-update
gbp:info: Fetching from default remote for each branch
gbp:info: Branch 'pristine-tar' is already up to date.
gbp:info: Branch 'upstream' is already up to date.
gbp:info: Branch 'master' is already up to date.
ba1b19b3b63c6e635dc7a8b0f5e2581d9d5f2d15
uupdate: PACKAGE     = "scanpy" is in the top of debian/changelog
uupdate: VERSION     = "1.6.0-2" is in the top of debian/changelog
uupdate: EPOCH       = "" is epoch part of $VERSION
uupdate: SVERSION    = "1.6.0-2" is w/o-epoch part of $VERSION
uupdate: UVERSION    = "1.6.0" the upstream portion w/o-epoch of $VERSION
uupdate: ../scanpy-1.7.1 directory exists.
uupdate: remove ../scanpy-1.7.1 directory.
uupdate: -> Overwrite to scanpy_1.7.1-1.debian.tar.xz
[master aa68601] routine-update: New upstream version
 1 file changed, 1 insertion(+), 1 deletion(-)
gbp:error: More than one archive specified. Try --help.

$ git status -v
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

So I curious to check what file committed

$ git reset --soft HEAD^

$ git status -v
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   debian/changelog

Seem just only 1 file. Doesn't look correct on my view


[1] https://tracker.debian.org/pkg/python-stdlib-list
[2] https://tracker.debian.org/pkg/python-sinfo

--
Email : Robbi Nespu <robbinespu AT SPAMFREE gmail DOT com>
PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
PGP key : https://keybase.io/robbinespu/pgp_keys.asc


Reply to: