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

Soren Stoutner <[email protected]> Fri, 16 Jan 2026 18:01:16 -0700

Newsgroups	gmane.linux.debian.devel.python
Organization	Debian
Message-ID	<2090539.lxTPI1ogt6@soren-desktop>

On Friday, January 16, 2026 3:45:48 AM Mountain Standard Time Arian Ott wrote:
> On Fri, 16 Jan 2026, 00:44 Soren Stoutner, <[email protected]> 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
[email protected]

signature.asc (application/pgp-signature, 833 B)