[Adding Sjoerd in CC]
Hello,
Missatge de Reinhard Tartler <
siretart@gmail.com> del dia dc., 13 de febr. 2019 a les 13:22:
>
>
>
> On Wed, Jan 9, 2019 at 9:58 AM Alexandre Viau <
aviau@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?
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 -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.