Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Ximin Luo]

Russell Sim:
> [..]
> 
> Thanks, for doing all that.
> 
> I'm happy to lodge the bugs, I'll wait for the package to clear the new
> queue and then send out the emails.
> 
> I have had a look over the package build logs you posted, it appears that
> most of them have failed because the package defines a hard dependency on
> the libgit2 dev version.  Which makes sense.
> 

Welcome! I'd encourage you to send out the emails now, before the package 
clears NEW, to save some time.

The queue is the longest it's been for about 1.5 years [1], but these other 
packages can already experiment with building against libgit2 0.26 using the 
sbuild invocation I gave in a previous email, that links to my 
people.debian.org APT repo. So they can work on fixing the build errors now, at 
the same time as FTP masters are processing the NEW queue (eventually getting 
around to libgit2), there is no need to wait.

[1] https://ftp-master.debian.org/stat.html

I added some patches to the git repo to enable HTTPS support (which was lost 
when OpenSSL was de-linked), could you review them? This was necessary for 
cargo to work. I also filed it upstream here, feel free to add any comments:

https://github.com/libgit2/libgit2/pull/4325

> Enjoy DebConf :)
> 

Thank you!

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Russell Sim]

On 1 August 2017 at 14:47, Ximin Luo  wrote:

> Ximin Luo:
> > Russell Sim:
> >>> [..]
> >>>
> >>> $ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24
> ~rnative
> >>> !~e^libgit2$')
> >>> eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate
> >>> kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2
> libkf5texteditor5
> >>> lua-gall python-pygit2 python3-pygit2 ruby-rugged
> >>>
> >>> [..]
> >>
> >> Thanks for the info, I'll follow the document as described.
> >>
> >> I think i may get some time on Monday to start building and testing the
> >> rdepends.  In the meantime could you please upload 0.26.0+dfsg.1-1 to
> >> experimental, I've pushed it to the collab-maint git.
> >>
> >
> > I've uploaded that to experimental. I made a minor tweak in git which
> will take effect for the next version, you can revert it if you want, see
> the commit message for details.
> >
> > I can help with the rebuilds [..]
> >
>
> I've rebuilt the packages above (except eeshow which is only in
> experimental, and libgnucastro1 since it was replaced by *2). The following
> packages fail:
>
> fritzing_0.9.3b+dfsg-4.dsc
> gnome-builder_3.22.4-1.dsc
> gnuastro_0.3.33-1.dsc
> kate_16.08.3-1.dsc
> libgit2-glib_0.24.4-1.dsc
> python-pygit2_0.24.2-2.dsc
> ruby-rugged_0.24.0+ds1-3.dsc
>
> Build logs are here if you'd like to investigate:
> https://people.debian.org/~infinity0/libgit2/
>
> I'll file bugs to those packages in the next few days, or feel free to
> jump in ahead. (I'll be travelling tomorrow to go to DebConf, so it might
> be a while before I get around to it.)
>
> X
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
>

Thanks, for doing all that.

I'm happy to lodge the bugs, I'll wait for the package to clear the new
queue and then send out the emails.

I have had a look over the package build logs you posted, it appears that
most of them have failed because the package defines a hard dependency on
the libgit2 dev version.  Which makes sense.

Enjoy DebConf :)

-- 
Cheers,
Russell Sim

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Ximin Luo]

Ximin Luo:
> Russell Sim:
>>> [..]
>>>
>>> $ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24 ~rnative
>>> !~e^libgit2$')
>>> eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate
>>> kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2 libkf5texteditor5
>>> lua-gall python-pygit2 python3-pygit2 ruby-rugged
>>>
>>> [..]
>>
>> Thanks for the info, I'll follow the document as described.
>>
>> I think i may get some time on Monday to start building and testing the
>> rdepends.  In the meantime could you please upload 0.26.0+dfsg.1-1 to
>> experimental, I've pushed it to the collab-maint git.
>>
> 
> I've uploaded that to experimental. I made a minor tweak in git which will 
> take effect for the next version, you can revert it if you want, see the 
> commit message for details.
> 
> I can help with the rebuilds [..]
> 

I've rebuilt the packages above (except eeshow which is only in experimental, 
and libgnucastro1 since it was replaced by *2). The following packages fail:

fritzing_0.9.3b+dfsg-4.dsc
gnome-builder_3.22.4-1.dsc
gnuastro_0.3.33-1.dsc
kate_16.08.3-1.dsc
libgit2-glib_0.24.4-1.dsc
python-pygit2_0.24.2-2.dsc
ruby-rugged_0.24.0+ds1-3.dsc

Build logs are here if you'd like to investigate: 
https://people.debian.org/~infinity0/libgit2/

I'll file bugs to those packages in the next few days, or feel free to jump in 
ahead. (I'll be travelling tomorrow to go to DebConf, so it might be a while 
before I get around to it.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Ximin Luo]

Russell Sim:
>> [..]
>>
>> $ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24 ~rnative
>> !~e^libgit2$')
>> eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate
>> kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2 libkf5texteditor5
>> lua-gall python-pygit2 python3-pygit2 ruby-rugged
>>
>> [..]
> 
> Thanks for the info, I'll follow the document as described.
> 
> I think i may get some time on Monday to start building and testing the
> rdepends.  In the meantime could you please upload 0.26.0+dfsg.1-1 to
> experimental, I've pushed it to the collab-maint git.
> 

I've uploaded that to experimental. I made a minor tweak in git which will take 
effect for the next version, you can revert it if you want, see the commit 
message for details.

I can help with the rebuilds, using sbuild(1) it should just be a case of 
running, e.g.:

$ apt-get source libgit2-glib-1.0-0
$ sbuild --build-dep-resolver=aspcud \
--add-conflicts=libgit2-24 \
--chroot-setup-commands='apt-get install -y apt-transport-https' \
--extra-repository-key=/path/to/my/key/Ximin_Luo.pub.asc \
--extra-repository="deb https://people.debian.org/~infinity0/apt/ 
experimental main" \
libgit2-glib_0.24.4-1.dsc

for each of the packages I mentioned above.

You can set up an sbuild schroot by following the instructions here: 
https://wiki.debian.org/sbuild#Create_the_chroot

You can also replace the "extra-repository" arguments above to point to your 
own local copies instead if you need to; there is also a --extra-package to 
point directly to individual local .debs, in case setting up a local APT 
archive is too much work.

(In fact libgit2-glib 0.24 FTBFS against libgit2 0.26 so we'll have to file a 
bug report to them, etc. I'll try other packages later and keep you updated.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Russell Sim]

On 27 July 2017 at 14:01, Ximin Luo  wrote:

> Russell Sim:
> > [..]
> >
> > Thank you for the in depth description it was very helpful.  I was
> thinking
> > the same, but just wanted to clarify.
> >
> > I have tried to upload a new version, but was blocked because of the same
> > FTP ACL as before.  I think I should probably look at beginning the DD
> > process.  In the meantime it would be great if you could sponsor my
> upload
> > I have pushed it to git [0].
> >
> > 0. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/
> >
>
> In d/changelog you said this is for unstable, but since other packages in
> Debian still link against libgit2 0.24 I think we are supposed to do a
> transition:
>
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>
> which means I should upload this to experimental first. However I also
> notice you already did that previously - did you also already check that
> the reverse dependencies also build correctly against 0.25? i.e. these
> packages:
>
> $ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24 ~rnative
> !~e^libgit2$')
> eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate
> kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2 libkf5texteditor5
> lua-gall python-pygit2 python3-pygit2 ruby-rugged
>
> If you did the check already, we might be able to upload directly to
> unstable, otherwise I think we are supposed to upload to experimental first
> and go through the process listed in the "Transitions" page I linked.
>
> This somewhat lengthy process, is also why I suggested to just package
> 0.26 directly and skip 0.25. Sorry, perhaps I should have explained it
> earlier.
>
> (I am fairly new to this process as well, despite me being a DD for
> several years I have not maintained a library package myself, that needs
> these sorts of rebuilds.)
>
> X
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
>


Thanks for the info, I'll follow the document as described.

I think i may get some time on Monday to start building and testing the
rdepends.  In the meantime could you please upload 0.26.0+dfsg.1-1 to
experimental, I've pushed it to the collab-maint git.

-- 
Cheers,
Russell Sim

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Ximin Luo]

Russell Sim:
> [..]
> 
> Thank you for the in depth description it was very helpful.  I was thinking
> the same, but just wanted to clarify.
> 
> I have tried to upload a new version, but was blocked because of the same
> FTP ACL as before.  I think I should probably look at beginning the DD
> process.  In the meantime it would be great if you could sponsor my upload
> I have pushed it to git [0].
> 
> 0. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/
> 

In d/changelog you said this is for unstable, but since other packages in 
Debian still link against libgit2 0.24 I think we are supposed to do a 
transition:

https://wiki.debian.org/Teams/ReleaseTeam/Transitions

which means I should upload this to experimental first. However I also notice 
you already did that previously - did you also already check that the reverse 
dependencies also build correctly against 0.25? i.e. these packages:

$ echo $(aptitude search --disable-columns -F "%p" '~Dlibgit2-24 ~rnative 
!~e^libgit2$')
eeshow fritzing geany-plugin-git-changebar gnome-builder gnuastro kate 
kup-backup libgit2-glib-1.0-0 libgnuastro1 libgnuastro2 libkf5texteditor5 
lua-gall python-pygit2 python3-pygit2 ruby-rugged

If you did the check already, we might be able to upload directly to unstable, 
otherwise I think we are supposed to upload to experimental first and go 
through the process listed in the "Transitions" page I linked.

This somewhat lengthy process, is also why I suggested to just package 0.26 
directly and skip 0.25. Sorry, perhaps I should have explained it earlier.

(I am fairly new to this process as well, despite me being a DD for several 
years I have not maintained a library package myself, that needs these sorts of 
rebuilds.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Russell Sim]

On 27 July 2017 at 02:40, Ximin Luo  wrote:

> Russell Sim:
> > Hey,
> >
> > I'm about to do an upload and I was wondering if you thought it would
> make
> > sense to start shipping this package with a versioned -dev package.  At
> the
> > moment the dev package is un-versioned, and the upstream API can change
> > quite significantly with each release.  So I'm a bit worried that this
> will
> > cause package build failures if any rebuilds occur.  Does that make sense
> > to do this, or is that over complicating things?  I couldn't find any
> good
> > documentation about when it is appropriate to version a dev package.
> >
> > I won't let this stop me uploading 0.25.1.0, but I'm curious about what
> > your opinion is?
> >
>
> Hey, I'd suggest *not* to have the -dev package be versioned.
>
> Despite the fact that the API changes quite a lot, I would guess that most
> (say ballpark 80%) dependants would still build fine with both 0.25 and
> 0.26. If you start renaming the -dev packages, you would have to edit the
> source code of all of the dependant packages to say Build-Depends:
> libgit2-26-dev etc. That is more work than doing binary-only NMU rebuilds,
> using the latest version of libgit2-dev.
>
> Also there would be extra trips through the NEW queue. Also it does not
> really help build failures - since you are maintaining 1 source package, if
> you upload libgit2-26-dev then the older libgit2-25-dev would go away
> anyways and be unavailable for future builds.
>
> Usually the only appropriate time to do versioned -dev packages is if you
> are going to maintain both those versions separately for a long period of
> time, and usually this would only be because of very major API changes
> (like GTK 2 vs 3) rather than relatively minor changes from 0.25 to 0.26.
>
> If upstream keeps changing API very significantly then yes, one would have
> to make a tradeoff on whether it's more-or-less effort to (a) upgrade
> packages to use the newer API or (b) maintain multiple source packages of
> these different versions. However, having reviewed the 0.26 release notes,
> I think keeping 1 source package (and an unversioned -dev package) is the
> better solution for this case.
>
> X
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
>

Thank you for the in depth description it was very helpful.  I was thinking
the same, but just wanted to clarify.

I have tried to upload a new version, but was blocked because of the same
FTP ACL as before.  I think I should probably look at beginning the DD
process.  In the meantime it would be great if you could sponsor my upload
I have pushed it to git [0].

0. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/

-- 
Thanks again,
Russell Sim

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Ximin Luo]

Russell Sim:
> Hey,
> 
> I'm about to do an upload and I was wondering if you thought it would make
> sense to start shipping this package with a versioned -dev package.  At the
> moment the dev package is un-versioned, and the upstream API can change
> quite significantly with each release.  So I'm a bit worried that this will
> cause package build failures if any rebuilds occur.  Does that make sense
> to do this, or is that over complicating things?  I couldn't find any good
> documentation about when it is appropriate to version a dev package.
> 
> I won't let this stop me uploading 0.25.1.0, but I'm curious about what
> your opinion is?
>

Hey, I'd suggest *not* to have the -dev package be versioned.

Despite the fact that the API changes quite a lot, I would guess that most (say 
ballpark 80%) dependants would still build fine with both 0.25 and 0.26. If you 
start renaming the -dev packages, you would have to edit the source code of all 
of the dependant packages to say Build-Depends: libgit2-26-dev etc. That is 
more work than doing binary-only NMU rebuilds, using the latest version of 
libgit2-dev.

Also there would be extra trips through the NEW queue. Also it does not really 
help build failures - since you are maintaining 1 source package, if you upload 
libgit2-26-dev then the older libgit2-25-dev would go away anyways and be 
unavailable for future builds.

Usually the only appropriate time to do versioned -dev packages is if you are 
going to maintain both those versions separately for a long period of time, and 
usually this would only be because of very major API changes (like GTK 2 vs 3) 
rather than relatively minor changes from 0.25 to 0.26.

If upstream keeps changing API very significantly then yes, one would have to 
make a tradeoff on whether it's more-or-less effort to (a) upgrade packages to 
use the newer API or (b) maintain multiple source packages of these different 
versions. However, having reviewed the 0.26 release notes, I think keeping 1 
source package (and an unversioned -dev package) is the better solution for 
this case.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Russell Sim]

Hey,

I'm about to do an upload and I was wondering if you thought it would make
sense to start shipping this package with a versioned -dev package.  At the
moment the dev package is un-versioned, and the upstream API can change
quite significantly with each release.  So I'm a bit worried that this will
cause package build failures if any rebuilds occur.  Does that make sense
to do this, or is that over complicating things?  I couldn't find any good
documentation about when it is appropriate to version a dev package.

I won't let this stop me uploading 0.25.1.0, but I'm curious about what
your opinion is?


On 25 July 2017 at 15:13, Ximin Luo  wrote:

> Package: libgit2-dev
> Version: 0.25.1.0-1
> Severity: normal
>
> Dear Maintainer,
>
> Now that the stretch freeze is over, please could you update libgit to
> 0.25.1
> (or 0.26 even) and do a library transition?
>
> We'd like to update rustc and cargo soon, without the embedded libraries. I
> took a brief look at the cargo source code and believe it ought to work
> with
> either 0.25.1 or 0.26, there is one breaking change [1] but cargo does not
> use
> that functionality.
>
> If you want to upload 0.25.1, I'd suggest the version "0.25.1.0" so that it
> sorts ahead of the current version "0.25.1+really0.24.6-1".
>
> X
>
> [1] https://github.com/libgit2/libgit2/releases/tag/v0.26.0
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
> 'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100,
> 'experimental'), (1, 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libgit2-dev depends on:
> ii  libcurl4-gnutls-dev7.52.1-5
> ii  libgit2-25 0.25.1.0-1
> ii  libhttp-parser-dev 2.1-2
> ii  libssh2-1-dev  1.8.0-1
> ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-5
>
> libgit2-dev recommends no packages.
>
> libgit2-dev suggests no packages.
>
> -- no debconf information
>



-- 
Cheers,
Russell Sim

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Ximin Luo]

Package: libgit2-dev
Version: 0.25.1.0-1
Severity: normal

Dear Maintainer,

Now that the stretch freeze is over, please could you update libgit to 0.25.1
(or 0.26 even) and do a library transition?

We'd like to update rustc and cargo soon, without the embedded libraries. I
took a brief look at the cargo source code and believe it ought to work with
either 0.25.1 or 0.26, there is one breaking change [1] but cargo does not use
that functionality.

If you want to upload 0.25.1, I'd suggest the version "0.25.1.0" so that it
sorts ahead of the current version "0.25.1+really0.24.6-1".

X

[1] https://github.com/libgit2/libgit2/releases/tag/v0.26.0

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgit2-dev depends on:
ii  libcurl4-gnutls-dev7.52.1-5
ii  libgit2-25 0.25.1.0-1
ii  libhttp-parser-dev 2.1-2
ii  libssh2-1-dev  1.8.0-1
ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-5

libgit2-dev recommends no packages.

libgit2-dev suggests no packages.

-- no debconf information