Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #17359 > unrolled thread

RFC: python-imgviz: Repository out of sync with Archive

Back to article view | Back to linux.debian.maint.python

Contents

  RFC: python-imgviz: Repository out of sync with Archive Arian Ott <arian.ott@ieee.org> - 2026-01-15 16:10 +0100
    Re: RFC: python-imgviz: Repository out of sync with Archive Soren Stoutner <soren@debian.org> - 2026-01-16 00:50 +0100
      Re: RFC: python-imgviz: Repository out of sync with Archive Arian Ott <arian.ott@ieee.org> - 2026-01-16 11:50 +0100
        Re: RFC: python-imgviz: Repository out of sync with Archive Carsten Schoenert <c.schoenert@t-online.de> - 2026-01-16 14:20 +0100
          Re: RFC: python-imgviz: Repository out of sync with Archive Arian Ott <arian.ott@ieee.org> - 2026-01-16 16:50 +0100
        Re: RFC: python-imgviz: Repository out of sync with Archive Soren Stoutner <soren@debian.org> - 2026-01-17 02:10 +0100
          Re: RFC: python-imgviz: Repository out of sync with Archive Arian Ott <arian.ott@ieee.org> - 2026-01-17 19:40 +0100
            Re: RFC: python-imgviz: Repository out of sync with Archive Soren Stoutner <soren@debian.org> - 2026-01-17 19:40 +0100
              Re: RFC: python-imgviz: Repository out of sync with Archive Arian Ott <arian.ott@ieee.org> - 2026-01-17 19:50 +0100
              Re: RFC: python-imgviz: Repository out of sync with Archive Arian Ott <arian.ott@ieee.org> - 2026-01-20 10:50 +0100

#17359 — RFC: python-imgviz: Repository out of sync with Archive

Hi Python Team,

I'm currently adopting python-imgviz, which has been orphaned (ITA:
#1124143). While preparing the package, I ran into an issue where I
would appreciate some advice:

The git repository on Salsa is at version 1.5.1, but the Debian
Tracker shows that 1.7.5+ds-2 is already in the archive.
It seems the previous maintainer uploaded without pushing the latest
commits to Salsa.

What would be the preferred way of handling this?

I intend to import the 1.7.5 .dsc from the archive to sync the
repository history before making my own changes.

https://salsa.debian.org/python-team/packages/python-imgviz/-/blob/master/debian/changelog?ref_type=heads

https://tracker.debian.org/pkg/python-imgviz

Thanks for your help!

-- 
Arian Ott
arian.ott@ieee.org

[toc] | [next] | [standalone]

#17361

[Multipart message — attachments visible in raw view] — view raw

On Thursday, January 15, 2026 8:06:56 AM Mountain Standard Time Arian Ott 
wrote:
> Hi Python Team,
> 
> I'm currently adopting python-imgviz, which has been orphaned (ITA:
> #1124143). While preparing the package, I ran into an issue where I
> would appreciate some advice:
> 
> The git repository on Salsa is at version 1.5.1, but the Debian
> Tracker shows that 1.7.5+ds-2 is already in the archive.
> It seems the previous maintainer uploaded without pushing the latest
> commits to Salsa.
> 
> What would be the preferred way of handling this?
> 
> I intend to import the 1.7.5 .dsc from the archive to sync the
> repository history before making my own changes.

Yes, that is what is typically done, unless you can contact the previous 
uploaders and get them to push their changes to the repository.  But, given 
that there has been no other response to your email, I would assume that 
whoever made these changes no longer subscribes to the Debian Python mailing 
list.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#17362

[Multipart message — attachments visible in raw view] — view raw

On Fri, 16 Jan 2026, 00:44 Soren Stoutner, <soren@debian.org> wrote:

> On Thursday, January 15, 2026 8:06:56 AM Mountain Standard Time Arian Ott
> wrote:
> > Hi Python Team,
> >
> > I'm currently adopting python-imgviz, which has been orphaned (ITA:
> > #1124143). While preparing the package, I ran into an issue where I
> > would appreciate some advice:
> >
> > The git repository on Salsa is at version 1.5.1, but the Debian
> > Tracker shows that 1.7.5+ds-2 is already in the archive.
> > It seems the previous maintainer uploaded without pushing the latest
> > commits to Salsa.
> >
> > What would be the preferred way of handling this?
> >
> > I intend to import the 1.7.5 .dsc from the archive to sync the
> > repository history before making my own changes.
>
> Yes, that is what is typically done, unless you can contact the previous
> uploaders and get them to push their changes to the repository.


Thanks for the pointers. How would I document it in d/changelog? There
would be a gap.

But, given
> that there has been no other response to your email, I would assume that
> whoever made these changes no longer subscribes to the Debian Python
> mailing
> list.
>
> Sounds good.

Furthermore, upstream's latest release is 2.0.0 alpha and introduces
breaking changes.
Is it generally a good practice to package the latest stable release or can
I package the alpha version?


--
Arian Ott
arian.ott@ieee.org

[toc] | [prev] | [next] | [standalone]

#17365

Am 16.01.26 um 12:45 schrieb Arian Ott:

>     Yes, that is what is typically done, unless you can contact the
>     previous
>     uploaders and get them to push their changes to the repository. 
> 
> 
> Thanks for the pointers. How would I document it in d/changelog? There 
> would be a gap.

By usually importing every version (by using gpg import-dsc e.g.) that 
was uploaded to the Debian archive.

> $ gbp import-dscs --debsnap python-imgviz
> gbp:info: Downloading snapshots of 'python-imgviz' to '/tmp/tmp_zat7ku8'...
> /tmp/tmp_zat7ku8/python-imgviz_1.7.6+ds-2.dsc:
>       Good signature found
>    validating python-imgviz_1.7.6+ds.orig.tar.xz
>    validating python-imgviz_1.7.6+ds-2.debian.tar.xz
> All files validated successfully.
> ...
> /tmp/tmp_zat7ku8/python-imgviz_1.1.0+ds-1.dsc:
> dscverify: /tmp/tmp_zat7ku8/python-imgviz_1.1.0+ds-1.dsc failed signature check:
> gpg: Signature made Tue Jun 16 01:06:18 2020 SAST
> gpg:                using RSA key 9236557B170C87F8821C0AC3C1E0D92E986F7C7E
> gpg: Can't check signature: No public key
> Validation FAILED!!
> gbp:warning: Version 1.1.0+ds-1 already imported.
> gbp:warning: Version 1.2.3+ds-1 already imported.
> gbp:warning: Version 1.2.4+ds-1 already imported.
> gbp:warning: Version 1.2.5+ds-1 already imported.
> gbp:warning: Version 1.2.6+ds-1 already imported.
> gbp:warning: Version 1.3.0+ds-1 already imported.
> gbp:warning: Version 1.4.0+ds-1 already imported.
> gbp:warning: Version 1.4.1+ds-1 already imported.
> gbp:warning: Version 1.5.0+ds-1 already imported.
> gbp:warning: Version 1.5.1+ds-1 already imported.
> gbp:info: Version '1.7.5+ds-1' imported under '/home/carsten/tmp/python-imgviz'
> gbp:info: Version '1.7.5+ds-2' imported under '/home/carsten/tmp/python-imgviz'
> gbp:info: Version '1.7.6+ds-1' imported under '/home/carsten/tmp/python-imgviz'
> gbp:info: Version '1.7.6+ds-2' imported under '/home/carsten/tmp/python-imgviz'
> gbp:info: Everything imported under /home/carsten/tmp/python-imgviz

The advantage doing it that way is you can later see the delta changes 
done in every upload. Sometime that is important.

Also your "issue" with the gap of changelog entries isn't existing after 
these imports.

-- 
Regards
Carsten

[toc] | [prev] | [next] | [standalone]

#17366

[Multipart message — attachments visible in raw view] — view raw

On Fri, 16 Jan 2026, 14:17 Carsten Schoenert, <c.schoenert@t-online.de>
wrote:

> Am 16.01.26 um 12:45 schrieb Arian Ott:
>
> >     Yes, that is what is typically done, unless you can contact the
> >     previous
> >     uploaders and get them to push their changes to the repository.
> >
> >
> > Thanks for the pointers. How would I document it in d/changelog? There
> > would be a gap.
>
> By usually importing every version (by using gpg import-dsc e.g.) that
> was uploaded to the Debian archive.
>

That helps a lot. Thanks. I haven't had that case before.



> The advantage doing it that way is you can later see the delta changes
> done in every upload. Sometime that is important.


Thats good to know.


> Also your "issue" with the gap of changelog entries isn't existing after
> these imports.


Fantastic, I was worried the changelog was broken.


Cheers,

--
Arian Ott
arian.ott@ieee.org

[toc] | [prev] | [next] | [standalone]

#17367

[Multipart message — attachments visible in raw view] — view raw

On Friday, January 16, 2026 3:45:48 AM Mountain Standard Time Arian Ott wrote:
> On Fri, 16 Jan 2026, 00:44 Soren Stoutner, <soren@debian.org> wrote:
> > On Thursday, January 15, 2026 8:06:56 AM Mountain Standard Time Arian Ott
> > 
> > wrote:
> > > Hi Python Team,
> > > 
> > > I'm currently adopting python-imgviz, which has been orphaned (ITA:
> > > #1124143). While preparing the package, I ran into an issue where I
> > > would appreciate some advice:
> > > 
> > > The git repository on Salsa is at version 1.5.1, but the Debian
> > > Tracker shows that 1.7.5+ds-2 is already in the archive.
> > > It seems the previous maintainer uploaded without pushing the latest
> > > commits to Salsa.
> > > 
> > > What would be the preferred way of handling this?
> > > 
> > > I intend to import the 1.7.5 .dsc from the archive to sync the
> > > repository history before making my own changes.
> > 
> > Yes, that is what is typically done, unless you can contact the previous
> > uploaders and get them to push their changes to the repository.
> 
> Thanks for the pointers. How would I document it in d/changelog? There
> would be a gap.

When you import the currently shipping version from the .dsc, it should import 
the current changelog as well.  Did it not do so?  If not, what procedure did 
you use to import the current .dsc?

> But, given
> 
> > that there has been no other response to your email, I would assume that
> > whoever made these changes no longer subscribes to the Debian Python
> > mailing
> > list.
> > 
> > Sounds good.
> 
> Furthermore, upstream's latest release is 2.0.0 alpha and introduces
> breaking changes.
> Is it generally a good practice to package the latest stable release or can
> I package the alpha version?

Typically, if there are breaking changes, they should be uploaded to 
experimental first, and only moved to unstable once all dependent packages are 
compatible.  If you find it helpful, you can package alpha versions, 
especially in experimental.  However, my personal preference is not to ship 
alpha versions in unstable unless they resolve a particularly nasty bug and it 
is not feasible to cherry pick the change to the current version in unstable.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#17368

[Multipart message — attachments visible in raw view] — view raw

>
> When you import the currently shipping version from the .dsc, it should
> import
> the current changelog as well.  Did it not do so?  If not, what procedure
> did
> you use to import the current .dsc?
>

I am in Cologne so I haven't really tried it yet. Will do tomorrow once I'm
back home.


Typically, if there are breaking changes, they should be uploaded to
> experimental first, and only moved to unstable once all dependent packages
> are
> compatible.


Can I do both? Packaging the alpha in experimental and the last stable
release in unstable? That way a new stable version is already in the repos.


If you find it helpful, you can package alpha versions,
> especially in experimental.  However, my personal preference is not to
> ship
> alpha versions in unstable unless they resolve a particularly nasty bug
> and it
> is not feasible to cherry pick the change to the current version in
> unstable
>

Totally agree. Software must be stable if it's being packaged for Debian.
Having an alpha in unstable is risky.

I'll check if there are nasty bugs being
resolved in the current alpha.

If there is no particular reason for shipping the alpha I will proceed with
the latest stable.

Best,

---
Arian
arian.ott@ieee.org

[toc] | [prev] | [next] | [standalone]

#17369

[Multipart message — attachments visible in raw view] — view raw

On Saturday, January 17, 2026 11:34:37 AM Mountain Standard Time Arian Ott 
wrote:
> > experimental first, and only moved to unstable once all dependent packages
> > are
> > compatible.
> 
> Can I do both? Packaging the alpha in experimental and the last stable
> release in unstable? That way a new stable version is already in the repos.

Yes, that is quite common.  You can create debian/unstable and debian/
experimental branches in your Salsa repository and release from both.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#17370

[Multipart message — attachments visible in raw view] — view raw

>
>
>
> Yes, that is quite common.  You can create debian/unstable and debian/
> experimental branches in your Salsa repository and release from both.
>

Ah that makes sense. Thanks for telling me.

Cheers,

--
Arian Ott
arian.ott@ieee.org

[toc] | [prev] | [next] | [standalone]

#17375

[Multipart message — attachments visible in raw view] — view raw

> Yes, that is quite common.  You can create debian/unstable and debian/
> experimental branches in your Salsa repository and release from both.
> 

I began the implementation in that regard and modernised the package 
according to current standards. Everything seems very promising.

However, I came across a different issue with python-imgviz. In newer 
versions, imgviz depends on the package cmap.

Cmap was released in 2023 to provide a minimal library which gives 
access to the colour maps of large ecosystems such as matplotlib.

At the moment cmap only depends on numpy but has heavy dependency groups 
[1].

Cmap itself is released under the BSD-3 license but includes 10 
different licenses. [2]

The documentation clearly states that cmap can provide "[...] all of the 
colormaps in matplotlib, [...] (and more), with no dependencies beyond 
numpy".[3]

My next step is to validate the licenses of cmap and the code to verify 
if potential licensing issues arise.

If no issues arise I will file an ITP, package cmap first, where 
possible exclude all of the dependency groups, and then continue my work 
with python-imgviz.

If there are issues, I will approach the maintainers of imgviz to 
resolve those concerns.


Best,

--
Arian Ott
arian.ott@ieee.org


References:

[1] https://github.com/pyapp-kit/cmap/blob/main/pyproject.toml#L29-L76
[2] https://github.com/pyapp-kit/cmap/tree/main/LICENSE
[3] https://cmap-docs.readthedocs.io/en/stable/#overview

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web