[Adding Sjoerd in CC] Hello,
Missatge de Reinhard Tartler <siret...@gmail.com> del dia dc., 13 de febr. 2019 a les 13:22: > > > > On Wed, Jan 9, 2019 at 9:58 AM Alexandre Viau <av...@debian.org> wrote: >> >> On 2019-01-09 6:54 a.m., Reinhard Tartler wrote: >> > Hi Juan, >> > >> > are you still working on this ITP? I was looking at skopeo as well, >> > and stumpled upon this ITP. I noticed that you created a repository on >> > salsa: >> > >> > https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go >> > >> > This package never got uploaded. >> > >> > However, I also noticed that there is another packaging repo in salsa, >> > which contains a similar package that did get uploaded: >> > >> > https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go >> > https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go >> > >> > I wonder what the relationship between these two are. It seems that the >> > sjoerdsimons >> > version does declare it satisfies the import of the >> > github:ostreedev/ostree-go repo, >> > which makes me believe it is a fork. >> >> Looking at the upstream website will show you that yes it is a fork. >> (forked from ostreedev/ostree). >> > > > I'm slowly making progress towards to goal of packaging skopeo, and have arrived at packaging the containers/image package. It also requires compiling against the ostree-dev library (like containers/storage), but this time it fails to build: > > # github.com/sjoerdsimons/ostree-go/pkg/otbuiltin > In file included from /usr/include/glib-2.0/glib/glist.h:32, > from /usr/include/glib-2.0/glib/ghash.h:33, > from /usr/include/glib-2.0/glib.h:50, > from src/ github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go:16: > src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h: In function '_g_clear_object': > /usr/include/glib-2.0/glib/gmem.h:121:18: warning: passing argument 1 of 'g_object_unref' discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers] > (destroy) (_ptr); \ > ^~~~ > /usr/include/glib-2.0/gobject/gobject.h:672:36: note: in expansion of macro 'g_clear_pointer' > #define g_clear_object(object_ptr) g_clear_pointer ((object_ptr), g_object_unref) > ^~~~~~~~~~~~~~~ > src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h:51:3: note: in expansion of macro 'g_clear_object' > g_clear_object(object_ptr); > > ^~~~~~~~~~~~~~ > > > I noticed that a very similar error is mentioned in a commit message of the upstream fork (ostreedev/ostree-go): > > https://github.com/ostreedev/ostree-go/commit/7af23efc78cbcbf462ae58e30fc4b94e99f09436#diff-898ad6510d1fe82a218a36340e3b56ec > > > I strongly suspect that compiling against ostreedev/ostree-go would fix this issue. > > Given that https://github.com/sjoerdsimons/ostree-go/blob/master/README.md clearly states: > >> Temporary repository for patches not yet merged in upstream ostree-go. Please don't use this one but use https://github.com/ostreedev/ostree-go instead > > > I wonder why we are are using this fork in the first place. > > Hector, Andrej, Alex, can you please chime in? Can we avoid having two copies of this library in the archive or is that the best way to proceed for now? https://github.com/sjoerdsimons/ostree-go is used by `debos`, an OS image building tool. As you noticed Sjoerd attempted to work with upstream https://github.com/ostreedev/ostree-go, but upstream has not been responsive so far. Sjoerd has only been taking care of the bits he needed for `debos` and not committing to its upstream maintenance out of `debos` needs, therefore not recommending general use of github.com/sjoerdsimons/ostree-go. IMO, you should try to work with upstream and package that one for `skopeo`. If upstream ever takes Sjoerd patches we'll remove his version from Debian archive and switch to upstream copy for `debos` which to be honest I do not see happening any time soon. If upstream also fails for you, I am open to take patches to support your application into `golang-github-sjoerdsimons-ostree-go` Debian package and/or Sjoerd might be willing to queue those patches in his fork. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
